Lyosik | Ведущий системный аналитик (SA Lead)
Добро пожаловать в блок статей для начинающих системных/бизнес аналитиков. Здесь мы готовимся к получению заветного оффера вместе
Пожалуй, начнем с самого базового и примитивного - определения.
База данных (БД) - это набор данных, хранящихся в структурированном виде.
Вторым ключевым понятием является СУБД.
Система управления базами данных (СУБД) - это системы (или программы), позволяющие создавать базы данных и манипулировать сведениями из них.
Схема ниже представляет собой упрощенный процесс взаимодействия с БД.
Пояснение к схеме:
Когда мы, как пользователи, хотим получить данные, хранящиеся в базе данных (БД), мы формируем запрос на языке SQL. Система управления базами данных (СУБД) принимает этот запрос и обращается к БД для поиска нужной информации. После того как данные найдены, СУБД возвращает их нам, и мы можем их просмотреть.
Типы БД
Реляционные;
Нереляционные (NoSQL);
Объектно-ориентированные;
Иерархические;
Сетевые;
NewSQL.
В основном мы будем работать с реляционными базами данных, которые организуют данные в виде таблиц. Однако существуют и другие типы баз данных, о существовании которых также стоит знать.
Вторыми по приоритету идут нереляционные (NoSQL) БД.
Давайте попробуем их сравнить по основным критериям.
Особенности Реляционной БД
Жесткая структура (данные записаны в отдельных ячейках и, таким образом, структурированы);
Вертикальное масштабирование;
SQL-запросы;
Простые и удобные;
Популярные.
Особенности Нереляционной БД
Нет требований к структуре;
Вертикальное и горизонтальное масштабирование;
Различные алгоритмы запросов;
Высокая защита;
Высокий порог входа.
Вероятнее всего у вас возник вопрос касательно масштабирования. Если говорить в двух словах, не сильно углубляясь в подробности:
Вертикальное масштабирование – это по сути увеличение мощности одного конкретного сервера, где развернута БД. В случае горизонтального масштабирования мы пытаемся разделить нашу БД на несколько серверов, подключая балансировщики для равномерного распределения нагрузки.
Небольшой экскурс в сравнение двух типов БД провели. Напомню, далее (в рамках данной статьи) мы будем говорить именно про реляционные БД.
Реляционная модель данных
Реляционная модель – это модель, которая ориентирована на организацию данных в виде двумерных таблиц
Свойства реляционной таблицы
Каждый элемент таблицы – один элемент данных (т.е в каждой ячейке таблицы хранится только одно значение);
Все элементы в столбце имеют одинаковый тип;
Каждый столбец имеет уникальное имя;
У каждой записи есть свой идентификатор (ключ);
Порядок следования строк и столбцов определяют правила сортировки данных;
Отношения представлены в виде таблиц, где указывается связь и дополнительные параметры.
Здесь мы затронули такое понятие, как ключ. Его понимание важно, поэтому разберем подробнее.
Ключи
Ключ – это столбец или набор столбцов (составной ключ). Ключ идентифицирует каждую строку таблицы. С помощью него мы можем обратиться к конкретной строке данных в таблице
Виды ключей
Первичный ключ (primary key);
Внешний ключ (foreign key).
Попробуйте самостоятельно ответить, в чем ключевая разница между этими двумя видами ключей?
Подсказка
В моем тг канале уже есть разбор этого вопроса, кому интересно - welcome :)
Итак, погружаемся в определения.
Первичный ключ
Первичный ключ – это уникальный идентификатор записи в таблице базы данных.
Может быть двух видов:
Простой ключ
Состоит из одного поля, который уникально идентифицирует запись в таблице.
Например, поле "Номер сотрудника" в таблице "Сотрудники".
Составной ключ
Состоит из двух или более полей, которые вместе уникально идентифицируют запись.
Например, в таблице "Отделы" составным ключом может быть комбинация полей "Код департамента" и "Номер отдела", которая вместе определяет уникальность записи об отделе.
Внешний ключ
Внешний ключ – это атрибут или набор атрибутов, которые ссылаются на первичный ключ или уникальный ключ другой таблицы. Другими словами, это что-то вроде указателя на строку другой таблицы.
Так, с ключами в БД более-менее разобрались. Переходим к следующей части нашей темы.
Связи между таблицами
Основная информация отображена на схеме ниже, поэтому внимательно читаем и запоминаем:
Важно!
В случае построения БД связь многие - ко - многим реализуется через промежуточную таблицу, которая содержит связи между ними.
При выстраивании связи многие - ко - многим у нас по сути есть две таблицы, являющиеся источниками данных. Например таблицы "Заказ" и "Товар". Промежуточная же таблица будет содержать в себе коды заказа и товара.
Теперь предлагаю закрепить данную информацию и выполнить небольшое задание для тренировки.
Определение связей
Определите тип связи между таблицами «Продукты» и «Цены», если в таблице «Продукты» есть поля для уникального идентификатора продукта, названия продукта, веса продукта и цены продукта, а в таблице «Цены» есть поля для уникального идентификатора продукта и цены.
Определите тип связи между таблицами «Фильмы» и «Актеры», если в таблице «Фильмы» содержится информация о каждом фильме, включая его название, год выпуска и уникальный идентификатор фильма, а в таблице «Актеры» содержится информация об актерах, включая их имена, даты рождения и уникальный идентификатор актера, а также поле для уникального идентификатора фильма, в котором актер принимал участие.
Определите тип связи между таблицами «Студенты», «Курсы» и «Регистрация», если известно следующие: каждая запись в таблице «Регистрация» содержит уникальный идентификатор студента и уникальный идентификатор курса.
Укажите тип связи между таблицами «Сотрудники» и «Отделы», если в таблице «Сотрудники» есть поля для уникального идентификатора сотрудника, имени сотрудника, должности сотрудника и уникального идентификатора отдела, а в таблице «Отделы» есть поля для уникального идентификатора отдела и названия отдела.
Правильные ответы уже есть в моем тг-канале (ссылка в конце статьи)
Давайте посмотрим, как могут выглядеть 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 и до скорых встреч!
Клиент-серверная архитектура:
Общие принципы интеграций систем:
Комментарии (7)
nin-jin
06.11.2024 17:24Однако существуют и другие типы баз данных, о существовании которых также стоит знать.
И далее вы демонстрируете полное незнание этого вопроса. Лучше не пишите о том, в чем не разбираетесь.
Akina
06.11.2024 17:24Люто плюсую.
Да, на Хабре уже давно стали трендом статьи, в которых основы какой-то области знаний пытаются объяснять очевидно ничего не понимающие в этой области знаний люди. Но статья выше - просто эталон. Похоже на шпаргалку, специально приготовленную для того, чтобы подсунуть её злейшему врагу.
danielsedoff
06.11.2024 17:24Спасибо за статью, но реклама телеграм-канала в спойлере с надписью "подсказка" — это странно.
svenkov
06.11.2024 17:24В статье, претендующей на прояснение терминологии БД, я не увидел объяснения термина отношение (relation).
Dynasaur
Почему в мире с 3НФ у человека четыре ноги и некоторые с лишними коленами?