Базы данных: общие понятия. SA для самых маленьких

Lyosik | Ведущий системный аналитик (SA Lead)

Добро пожаловать в блок статей для начинающих системных/бизнес аналитиков. Здесь мы готовимся к получению заветного оффера вместе

Пожалуй, начнем с самого базового и примитивного — определения.

База данных (БД) — это набор данных, хранящихся в структурированном виде.

Вторым ключевым понятием является СУБД.

Система управления базами данных (СУБД) — это системы (или программы), позволяющие создавать базы данных и манипулировать сведениями из них.

Схема ниже представляет собой упрощенный процесс взаимодействия с БД.

Пояснение к схеме:

Когда мы, как пользователи, хотим получить данные, хранящиеся в базе данных (БД), мы формируем запрос на языке SQL. Система управления базами данных (СУБД) принимает этот запрос и обращается к БД для поиска нужной информации. После того как данные найдены, СУБД возвращает их нам, и мы можем их просмотреть.

Типы БД

Реляционные;
Нереляционные (NoSQL);
Объектно-ориентированные;
Иерархические;
Сетевые;
NewSQL.

В основном мы будем работать с реляционными базами данных, которые организуют данные в виде таблиц. Однако существуют и другие типы баз данных, о существовании которых также стоит знать.

Вторыми по приоритету идут нереляционные (NoSQL) БД.

Давайте попробуем их сравнить по основным критериям.

Особенности Реляционной БД

Жесткая структура (данные записаны в отдельных ячейках и, таким образом, структурированы);

Вертикальное масштабирование;

SQL-запросы;

Простые и удобные;

Популярные.

Особенности Нереляционной БД

Нет требований к структуре;

Вертикальное и горизонтальное масштабирование;

Различные алгоритмы запросов;

Высокая защита;

Высокий порог входа.

Вероятнее всего у вас возник вопрос касательно масштабирования. Если говорить в двух словах, не сильно углубляясь в подробности:

Вертикальное масштабирование – это по сути увеличение мощности одного конкретного сервера, где развернута БД. В случае горизонтального масштабирования мы пытаемся разделить нашу БД на несколько серверов, подключая балансировщики для равномерного распределения нагрузки.

Небольшой экскурс в сравнение двух типов БД провели. Напомню, далее (в рамках данной статьи) мы будем говорить именно про реляционные БД.

Реляционная модель данных

Реляционная модель – это модель, которая ориентирована на организацию данных в виде двумерных таблиц

Свойства реляционной таблицы

Каждый элемент таблицы – один элемент данных (т.е в каждой ячейке таблицы хранится только одно значение);
Все элементы в столбце имеют одинаковый тип;
Каждый столбец имеет уникальное имя;
У каждой записи есть свой идентификатор (ключ);
Порядок следования строк и столбцов определяют правила сортировки данных;
Отношения представлены в виде таблиц, где указывается связь и дополнительные параметры.

Здесь мы затронули такое понятие, как ключ. Его понимание важно, поэтому разберем подробнее.

Ключи

Ключ – это столбец или набор столбцов (составной ключ). Ключ идентифицирует каждую строку таблицы. С помощью него мы можем обратиться к конкретной строке данных в таблице

Виды ключей

Первичный ключ (primary key);
Внешний ключ (foreign key).

Попробуйте самостоятельно ответить, в чем ключевая разница между этими двумя видами ключей?

Подсказка

В моем тг канале уже есть разбор этого вопроса, кому интересно — welcome 🙂

IT Hub | Войти в айти — легко!

t.me

Итак, погружаемся в определения.

Первичный ключ

Первичный ключ – это уникальный идентификатор записи в таблице базы данных.

Может быть двух видов:

Простой ключ

Состоит из одного поля, который уникально идентифицирует запись в таблице.

Например, поле «Номер сотрудника» в таблице «Сотрудники».

Составной ключ

Состоит из двух или более полей, которые вместе уникально идентифицируют запись.

Например, в таблице «Отделы» составным ключом может быть комбинация полей «Код департамента» и «Номер отдела», которая вместе определяет уникальность записи об отделе.

Внешний ключ

Внешний ключ – это атрибут или набор атрибутов, которые ссылаются на первичный ключ или уникальный ключ другой таблицы. Другими словами, это что-то вроде указателя на строку другой таблицы.

Так, с ключами в БД более-менее разобрались. Переходим к следующей части нашей темы.

Связи между таблицами

Основная информация отображена на схеме ниже, поэтому внимательно читаем и запоминаем:

Важно!

В случае построения БД связь многие — ко — многим реализуется через промежуточную таблицу, которая содержит связи между ними.

При выстраивании связи многие — ко — многим у нас по сути есть две таблицы, являющиеся источниками данных. Например таблицы «Заказ» и «Товар». Промежуточная же таблица будет содержать в себе коды заказа и товара.

Пример связи многие - ко - многим — Пример связи многие — ко — многим

Теперь предлагаю закрепить данную информацию и выполнить небольшое задание для тренировки.

Определение связей

Определите тип связи между таблицами «Продукты» и «Цены», если в таблице «Продукты» есть поля для уникального идентификатора продукта, названия продукта, веса продукта и цены продукта, а в таблице «Цены» есть поля для уникального идентификатора продукта и цены.
Определите тип связи между таблицами «Фильмы» и «Актеры», если в таблице «Фильмы» содержится информация о каждом фильме, включая его название, год выпуска и уникальный идентификатор фильма, а в таблице «Актеры» содержится информация об актерах, включая их имена, даты рождения и уникальный идентификатор актера, а также поле для уникального идентификатора фильма, в котором актер принимал участие.
Определите тип связи между таблицами «Студенты», «Курсы» и «Регистрация», если известно следующие: каждая запись в таблице «Регистрация» содержит уникальный идентификатор студента и уникальный идентификатор курса.
Укажите тип связи между таблицами «Сотрудники» и «Отделы», если в таблице «Сотрудники» есть поля для уникального идентификатора сотрудника, имени сотрудника, должности сотрудника и уникального идентификатора отдела, а в таблице «Отделы» есть поля для уникального идентификатора отдела и названия отдела.

Правильные ответы уже есть в моем тг-канале (ссылка в конце статьи)

Давайте посмотрим, как могут выглядеть ER — диаграммы на практике:

ER-диаграмма (Entity-Relationship Diagram) – это графическое представление сущностей (объектов) и их взаимосвязей в базе данных.

Пример ER — диаграммы

ER-диаграмма состоит из следующих основных компонентов:

Сущности: объекты, которые могут быть представлены в базе данных (например, Автор, Книга).
Атрибуты: характеристики сущностей, описывающие их свойства (например, ФИО автора, Название книги).
Связи: отношения между сущностями.
Кардинальность: указывает, сколько экземпляров одной сущности может быть связано с экземплярами другой сущности (например, один-к-одному, один-ко-многим).

Далее у нас на повестке дня одна из самых сложных тем в области баз данных, поэтому запасаемся чайком и поехали.

Нормализация базы данных

Это способ организации данных в БД с целью снизить избыточность и повысить эффективность хранения.

Избыточность – это когда одни и те же данные хранятся в базе в нескольких местах.

Основная идея заключается в разделении таблиц на более мелкие, чтобы избавится от атрибутов:

с несколькими значениями;
повторяющихся;
не поддающихся классификации;
с избыточной информацией;
созданных из других признаков.

Именно для этого и используются так называемые нормальные формы, о которых мы сейчас и поговорим.

Нулевая нормальная форма

Ситуация, когда все данные находятся в «куче».

Посмотрите на таблицу ниже и попробуйте сказать, что в ней не так:

Надеюсь, вы ответили для себя на этот вопрос. Давайте проверим, совпадают ли наши мнения

Что не так?

необходимо удалить дублирующие строки;
в ячейках нужно хранить один номер телефона, а не список;
тип телефона вынести в отдельный столбец.

А теперь посмотрим, как должен выглядеть корректный вариант:

Первая нормальная форма (1 НФ)

Отношение находится в 1 НФ, если значения всех его атрибутов атомарны (неделимы).

Снова небольшое задание на подумать. Что не так в таблице ниже?

Сверяемся:

Нарушение нормализации 1 НФ происходит у марки BMW, т.к. в одной ячейке содержится список из 3 элементов: M1, M5, X7, т.е не является атомарным.

Корректный вариант представлен в таблице ниже:

Вторая нормальная форма (2 НФ)

Отношение находится во 2 НФ, если

Оно уже находится в 1 НФ;

В таблице есть первичный ключ, и все записи зависят от него.

Данные, которые не зависят от данного ключа, должны быть вынесены в отдельную таблицу.

Подумайте, как можно декомпозировать следующую таблицу?

Точно подумали? Тогда смотрим примерный вариант:

Третья нормальная форма (3 НФ)

Отношение находится в 3 НФ, если

Оно уже находится во 2 НФ;

Каждый неключевой атрибут зависит от первичного ключа

Проще говоря, правило требует выносить все неключевые поля, содержимое которых может относиться к нескольким записям таблицы, в отдельные таблицы.

Итак, уже известный вам вопрос. Как можно декомпозировать следующую таблицу?

Как вариант, например, так:

Такой вариант декомпозиции не совсем очевидный, поэтому дававйте разберем его чуть подробнее.

Как видно, у нас появился столбец «ID магазина». Это не естественный PK, который мы ввели сами. Для чего это надо? — спросите вы. На самом деле, такой подход позволит упростить работу с БД в будущем, если вдруг придется изменять какие-то значения (а в реальной практике точно придется, уж поверьте). Например, при изменении номера телефона магазина «Риал-авто» нам нужно будет внести новый только один раз в таблице «Магазин».

Так а для чего нужна третья нормальная форма?

По сути, для упрощения нашей жизни 🙂

Изменение названия без 3 НФ:

сложный запрос;
перебор всех строчек для изменения значения

Изменение названия с 3 НФ:

Есть так же 4, 5, и 6 НФ, но они редко встречаются на практике, и на начальном уровне их подробное изучение не требуется, достаточно просто знать об их существовании.

В общем-то это все, что я хотела обсудить в данной статье. Конечно, вместе с понятиями баз данных идут различные приложения для управления ими (по типу DBeaver и прочих), а так же подходы к построению ER-диаграмм. Но это я решила вынести в отдельную статью, дабы не перегружать текущую и ваш мозг:)

Подписывайтесь на мой тг-канал про IT и до скорых встреч!