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

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

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

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

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

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

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

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

Типы БД

1. Реляционные;

2. Нереляционные (NoSQL);

3. Объектно-ориентированные;

4. Иерархические;

5. Сетевые;

6. NewSQL.

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

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

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

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

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

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

• SQL-запросы;

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

• Популярные.

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

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

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

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

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

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

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

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

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

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

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

Пример реляционной модели

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

• Каждый элемент таблицы — один элемент данных (т.е в каждой ячейке таблицы хранится только одно значение);

• Все элементы в столбце имеют одинаковый тип;

• Каждый столбец имеет уникальное имя;

• У каждой записи есть свой идентификатор (ключ);

• Порядок следования строк и столбцов определяют правила сортировки данных;

• Отношения представлены в виде таблиц, где указывается связь и дополнительные параметры.

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

Ключи

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

Виды ключей

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

Подсказка

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

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

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

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

• Простой ключ

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

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

Пример простого ключа

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

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

Пример составного ключа

Внешний ключ

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

Пример внешнего ключа

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

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

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

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

Важно!

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

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

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

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

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

1. Определите тип связи между таблицами «Продукты» и «Цены», если в таблице «Продукты» есть поля для уникального идентификатора продукта, названия продукта, веса продукта и цены продукта, а в таблице «Цены» есть поля для уникального идентификатора продукта и цены.

2. Определите тип связи между таблицами «Фильмы» и «Актеры», если в таблице «Фильмы» содержится информация о каждом фильме, включая его название, год выпуска и уникальный идентификатор фильма, а в таблице «Актеры» содержится информация об актерах, включая их имена, даты рождения и уникальный идентификатор актера, а также поле для уникального идентификатора фильма, в котором актер принимал участие.

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

4. Укажите тип связи между таблицами «Сотрудники» и «Отделы», если в таблице «Сотрудники» есть поля для уникального идентификатора сотрудника, имени сотрудника, должности сотрудника и уникального идентификатора отдела, а в таблице «Отделы» есть поля для уникального идентификатора отдела и названия отдела.

Правильные ответы уже есть в моем тг-канале, а так же там регулярно публикуются интересные посты про it: будни айтишника, разборы реальных вакансий, практические интерактивы и многое другое — переходите по ссылочке ниже и подписывайтесь :)

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

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

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

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

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

1. Сущности: объекты, которые могут быть представлены в базе данных (например, Автор, Книга).

2. Атрибуты: характеристики сущностей, описывающие их свойства (например, ФИО автора, Название книги).

3. Связи: отношения между сущностями.

4. Кардинальность: указывает, сколько экземпляров одной сущности может быть связано с экземплярами другой сущности (например, один-к-одному, один-ко-многим).

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

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

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

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

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

• с несколькими значениями;

• повторяющихся;

• не поддающихся классификации;

• с избыточной информацией;

• созданных из других признаков.

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

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

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

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

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

Что не так?

• необходимо удалить дублирующие строки;

• в ячейках нужно хранить один номер телефона, а не список;

• тип телефона вынести в отдельный столбец.

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

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

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

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

Сверяемся:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Клиент-серверная архитектура:

Общие принципы интеграций систем:

© Habrahabr.ru