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

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

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

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

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

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

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

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

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

Типы БД

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

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

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

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

  5. Сетевые;

  6. NewSQL.

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

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

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

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

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

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

  • SQL-запросы;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ключи

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

Виды ключей

  • Первичный ключ (primary key);

  • Внешний ключ (foreign key).

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

Подсказка

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

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

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

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

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

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

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

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

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

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

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

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

Внешний ключ

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

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

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

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

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

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

Важно!

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример 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 и до скорых встреч!


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

Клиент-серверная архитектура. SA для самых маленьких
Lyosik | Ведущий системный аналитик (SA Lead) Добро пожаловать в блок статей для начинающих системны...
habr.com

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

Общие принципы интеграций систем. SA для самых маленьких
Lyosik | Ведущий системный аналитик (SA Lead) Добро пожаловать в блок статей для начинающих системны...
habr.com

Комментарии (7)


  1. Dynasaur
    06.11.2024 17:24

    Почему в мире с 3НФ у человека четыре ноги и некоторые с лишними коленами?


  1. nin-jin
    06.11.2024 17:24

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

    И далее вы демонстрируете полное незнание этого вопроса. Лучше не пишите о том, в чем не разбираетесь.


    1. Akina
      06.11.2024 17:24

      Люто плюсую.

      Да, на Хабре уже давно стали трендом статьи, в которых основы какой-то области знаний пытаются объяснять очевидно ничего не понимающие в этой области знаний люди. Но статья выше - просто эталон. Похоже на шпаргалку, специально приготовленную для того, чтобы подсунуть её злейшему врагу.


  1. ValeryGL
    06.11.2024 17:24

    Простите, но это каша. Нарезанные и перемешанные фрагменты знаний


  1. danielsedoff
    06.11.2024 17:24

    Спасибо за статью, но реклама телеграм-канала в спойлере с надписью "подсказка" — это странно.


  1. sap058
    06.11.2024 17:24

    Статью не сохраняй в закладках


  1. svenkov
    06.11.2024 17:24

    В статье, претендующей на прояснение терминологии БД, я не увидел объяснения термина отношение (relation).