йй

articles/5_1_1_1_erd2.md

@@ -2,8 +2,6 @@
 :----------------:|:----------:|:----------------:
 [Спецификация вариантов использования](./5_1_1_10_uml_uc_spec.md) | [Содержание](../readme.md#проектирование-баз-данных) | [Словарь данных](./5_1_1_1_data_dictionary.md)
 
->Основано на [этих](https://sites.google.com/site/anisimovkhv/learning/pris/lecture) лекциях.
-
 # Основы проектирования баз данных. ERD.
 
 * [Введение](#введение)
@@ -118,7 +116,271 @@ Primary key и foreign key помогают не только связывать
 
 ---
 
-Традиционно процедуру проектирования базы данных разбивают на три этапа, каждый из которых завершается созданием соответствующей информационной модели.
+Перед разработкой ПО нужно определить, с какими данными предстоит работать и как они связаны между собой. Для этого системные аналитики строят модели данных и создают ER-диаграммы.
+
+## Что такое ER‑диаграмма
+
+Системный аналитик начинает работу над новым проектом с изучения его предметной области и терминов, которые в ней используют. Например, нужно создать систему для бронирования билетов на самолёт. Аэропорт, авиакомпания, дата, рейс, пассажир, пункты прибытия и назначения, багаж — термины проекта. Их ещё называют понятиями или сущностями.
+
+В системе сущность представлена в виде экземпляров. Например, экземпляры сущности «Аэропорт» ― аэропорты «Домодедово», «Пулково», «Воронеж».
+
+У сущностей есть атрибуты — характеристики, которые их описывают. Например, атрибутами сущности «Аэропорт» будут код, адрес, номер телефона. Атрибуты есть у каждого экземпляра сущности, но у них разные значения. У аэропортов «Домодедово» и «Воронеж» есть одинаковый атрибут «Адрес», но у каждого из них разное значение этого атрибута.
+
+Собрав все сущности будущего проекта, системный аналитик выясняет, как они связаны между собой, и составляет ER-модель (сокр. от entity–relationship модель или модель «сущность-связь»). В модели есть три типа связей:
+
+* **Один-к-одному** — один экземпляр сущности связан только с одним экземпляром другой сущности. Например, пассажир рейса и его место в самолете.
+* **Один-ко-многим** — один экземпляр сущности связан со множеством экземпляров другой сущности. Например, у одного пассажира может быть несколько единиц багажа, при этом каждая единица багажа может быть связана только с одним пассажиром.
+* **Многие-ко-многим** — множество экземпляров одной сущности связаны со множеством экземпляров другой сущности. Например, аэропорт обслуживает несколько авиакомпаний. При этом каждая авиакомпания может обслуживаться в нескольких аэропортах.
+
+Системный аналитик создаёт ER-диаграмму модели данных. Это схема, которая показывает, с какими данными нужно будет работать для реализации проекта и как эти данные связаны между собой. Например, ER-диаграмма проиллюстрирует, что багаж связан с номером рейса, но не связан со временем окончания посадки пассажиров на него.
+
+Чтобы создать ER-модель, не нужны специальные инструменты. Её можно построить вручную в любом графическом редакторе: для диаграмм «сущность-связь» используют простые символы вроде квадратов, стрелок и линий. 
+
+## Типы ER‑моделей
+
+ER-модели создают разные специалисты, а сами модели отличаются друг от друга детализацией: насколько подробно в них описывают данные. Есть три уровня ER-моделей:
+
+1. **Концептуальный уровень**
+
+    Первая верхнеуровневая модель для представления новой предметной области будущего проекта: что в ней есть и с чем нужно работать. Например, в ПО для транспортной компании будут сущности «Транспорт», «Груз», «Маршрут», «Накладная».
+
+    ER-модель концептуального уровня нужна системному аналитику и заказчику, чтобы проверить, все ли термины учтены. Поэтому системный аналитик, как правило, создаёт её самостоятельно и не привлекает технических специалистов из команды разработки. 
+
+1. **Логический уровень**
+
+    На этом уровне детализируют данные из концептуальной модели: к сущностям добавляют характеристики — атрибуты. Например, на логическом уровне описывают характеристики сущности «Транспорт»: марка и модель автомобиля, количество лошадиных сил, пробег, грузоподъёмность.
+
+    Модель логического уровня тоже составляет системный аналитик, но уже не в одиночку. К работе подключают технических специалистов ― разработчика или архитектора баз данных. Готовую логическую ER-модель нужно презентовать команде разработки. Разработчики проверяют, чтобы аналитик ничего не упустил, и согласовывают модель.
+
+1. **Физический уровень**
+
+    На этом уровне описывают, как будет организована работа с данными: выбирают тип базы, её содержание и где данные будут хранить. Например, выбирают реляционный тип базы данных и СУБД для работы с ней, перечисляют таблицы в базе и определяют, что она будет храниться на внутреннем сервере компании.
+
+    Над ER-моделью физического уровня в большей степени работают архитектор баз данных и разработчики, а системный аналитик только помогает в процессе. 
+
+## Применение ER-диаграмм
+
+Модели «сущность-связь» традиционно используют для разработки программного обеспечения. При этом для метода нет конкретной области разработки: для создания любого ПО нужно работать с данными и транслировать их пользователям. Поэтому ER-модели строят и для интернет-магазина, и для корпоративного портала компании. 
+
+Обычно ER-модель создают в двух случаях:
+
+* когда перед началом проекта ещё не понятно, с какими данными предстоит работать;
+* когда нужно создать новую базу данных или добавить таблицу в уже существующую.
+
+Чем больше в системе сущностей и связей, тем важнее построить ER-модель до начала разработки ПО.
+
+На практике над простыми системами можно работать без концептуальной ER-модели. Например, программа для выдачи талонов электронной очереди — простая система, в которой всего две сущности — номер окна и номер очереди.
+
+## Символы и нотации ER‑диаграмм
+
+ER-модель — это общее представление данных, ER-диаграмма — представление модели, а нотация — графический язык для представления модели.
+
+Объясним на примере анатомии человека. Устройство человеческого организма — это модель. Её можно описать текстом, изобразить на картинке, перечислить все органы в таблице. Всё это разные представления одной и той же модели. Символы, с помощью которых описывают модель, — это нотации.
+
+Для того чтобы построить ER-диаграмму, можно использовать разные нотации. Три самые известные из них:
+
+1. **Нотация IDEF1X**. Её относят к фундаментальным, но на практике давно не используют, потому что есть более удобные варианты.
+
+1. **Нотация Чена**. Классическая нотация, которая состоит из простых символов — прямоугольников, овалов и линий. Из-за этого нотацию часто используют для концептуальных моделей, которые презентуют заказчику. Человеку, который далёк от аналитики данных, проще разобраться в понятных диаграммах со знакомыми символами.
+
+3. **Нотация Мартина**. Её ещё называют «воронья лапка» (от англ. Crow's Foot). Она компактнее нотации Чена, поэтому её используют для построения ER-моделей логического уровня, когда нужно описать в модели все атрибуты сущностей.
+
+В нотациях Чена и Мартина есть одинаковые элементы: сущности, атрибуты и связи. Но эти элементы диаграмм обозначают разными символами.
+
+В нотации Чена название сущностей, атрибутов и связей вписывают внутрь прямоугольника, овала или ромба:
+
+![](../img/chen.webp)
+
+Элементы ER-диаграммы в нотации Чена соединяют линиями. Если линия соединяет две сущности, сверху обозначают тип связи:
+
+* 1:1 — «один-к-одному»;
+* 1:N — «один-ко-многим»;
+* M:N — «многие-ко-многим».
+
+В одной компании работает много сотрудников. Тип связи между сущностями «компания» и «сотрудник» — «один-ко-многим»:
+
+![](../img/chen2.webp)
+
+В нотации Мартина сущность также вписывают в прямоугольник, а атрибуты и связи обозначают по-другому:
+
+* атрибуты перечисляют прямо под сущностью,
+* связи рисуют разными соединительными линиями.
+
+В нотации Мартина используют несколько видов соединительных линий для иллюстрации типа связи между сущностями:
+
+![](../img/martin1.webp)
+
+Для того чтобы изобразить три типа связи в нотации Мартина, можно использовать разные комбинации. Например, связь «многие-ко-многим» можно изобразить так:
+
+![](../img/martin2.webp)
+
+Официант может обслуживать от нуля до множества посетителей ресторана. При этом одного посетителя ресторана должен обслуживать хотя бы один официант, а могут и несколько
+
+А связь «один-ко-многим» может выглядеть так:
+
+![](../img/martin3.webp)
+
+За каждым столиком в ресторане закреплён только один официант. При этом за каждым официантом может быть закреплено несколько столиков
+
+## Примеры ER‑диаграмм
+
+На примере сервиса по бронированию номеров в сети гостиниц рассмотрим, как выглядит одна и та же ER-модель в разных нотациях.
+
+Сначала нужно выделить сущности ER-модели:
+
+* гость,
+* гостиница,
+* номер. 
+
+У каждой сущности есть основные атрибуты, например у сущности «гость» это ФИО и номер паспорта, у «гостиницы» — её номер в сети и адрес, у «номера» — его порядковый номер в гостинице и категория.
+
+Затем нужно установить связи между сущностями. 
+
+![](../img/chen3.webp)
+
+ER-модель концептуального уровня в нотации Чена содержит прямоугольники с сущностями, овалы с атрибутами, ромбы со связями. Сущность в подчинении у другой сущности называют дочерней и помещают в прямоугольник с двойной рамкой. Ромб со связью между ними тоже обводят двойной рамкой
+
+Между сущностями «Гость» и «Гостиница» установлена связь «многие-ко-многим» — много гостей могут бронировать много гостиниц. В нотации Чена такая связь становится самостоятельной сущностью, которую называют ассоциативной и обозначают ромбом внутри прямоугольника. Ассоциативная сущность между «Гостем» и «Гостиницей» — «Бронирование». На следующих уровнях ER-модели у неё появятся атрибуты, например дата и номер бронирования.
+
+Если строить ER-модель логического уровня в нотации Чена, она может сильно разрастись из-за большого количества атрибутов. Поэтому на следующем уровне можно построить модель в нотации Мартина.
+
+![](../img/martin4.webp)
+
+В ER-модели в нотации Мартина атрибуты сущностей перечисляют в полях под ними. За счёт этого модель занимает меньше места и её структура менее запутана
+
+## Как создать простую ER‑диаграмму
+
+Вот пошаговый алгоритм для создания простой ER-диаграммы:
+
+1. Определить сущности
+
+    Чтобы собрать все сущности будущего проекта, системные аналитики общаются с заказчиком и будущими пользователями ПО: сотрудниками или клиентами компании. Например, если нужно разработать ПО для ветеринарной клиники, системный аналитик проведёт интервью с руководителем клиники, сотрудниками, врачами и клиентами, которые будут записываться на приём.
+
+    На этом этапе обычно создают концептуальную модель и согласовывают её с заказчиком.
+
+1. Определить атрибуты
+
+    Системный аналитик детализирует информацию, собранную во время интервью, и описывает характеристики сущностей. Если данных не хватает, нужно повторно опросить заинтересованных лиц.
+
+1. Определить связи между сущностями
+
+    На этом этапе выясняют, какие сущности связаны между собой. Например, пациенты и медицинская карта, филиал клиники и врачи, которые ведут приём.
+
+1. Определить типы и характеристики связей 
+
+    Например, пациенты и медицинская карта — это связь «один-к-одному», врач и день приёма — «один-ко-многим». 
+
+    Затем ищут идентифицирующие связи между сущностями и определяют, какая из сущностей родительская. Допустим, у клиники есть филиалы — A, B и C. В каждом филиале есть кабинеты под номерами от 1 до 5. Это значит, что нельзя использовать номер кабинета без уточнения, в каком филиале он находится. Филиал — родительская сущность, а связь между филиалом и кабинетом — идентифицирующая.
+
+1. Проверить ER-модель
+
+    После завершения работы над ER-моделью системный аналитик проверяет, нет ли в ней лишних сущностей, дубликатов данных и косвенных связей между данными в одной таблице. Такую проверку называют **нормализацией** данных.
+
+    Если модель данных не соответствует нормальным формам, её нужно скорректировать.
+
+## Как привести данные в форму: что такое нормализация и зачем она нужна
+
+**Нормализация данных** — инструмент, в котором новичку бывает сложно разобраться. Объясняем, как она работает, на примере из жизни — походе в магазин за ингредиентами для салата.
+
+### Что такое нормализация данных
+
+Данные в базе могут быть в любом виде: числа, проценты, текст. Нормализация — это способ организации данных. В нормализованной базе нет повторяющихся данных, с ней проще работать и можно менять её структуру для разных задач. В процессе нормализации данные преобразуют, чтобы они занимали меньше места, а поиск по элементам был быстрым и результативным. Для этого создают дополнительные таблицы и связывают друг с другом ключами — колонками, в которых нет повторяющихся элементов.
+
+Рассмотрим на примере суть нормирования данных. Александр Сушков каждый день ходит в магазин продуктов рядом с домом. Покупает продукты, например, хлеб и творог, и оплачивает их картой. Данные о покупках, за которые рассчитывались картой, ежедневно сохраняются на сервере магазина в таблицу Excel.
+
+![](../img/norm1.webp)
+
+К концу дня данные можно проанализировать: посчитать выручку магазина, какие категории товаров продавались лучше и сколько денег принесли. Когда количество записей в таблице превысит миллион — работать с данными станет сложнее. Таблица будет медленно открываться, в ней будет труднее найти ошибки и собрать статистику по определённым товарам или категориям покупателей.
+
+Кроме Александра Сушкова, в магазине ежедневно делают покупки и другие люди, которые тоже живут поблизости — Иван Иванов и Егор Кузнецов. Фамилии и имена покупателей повторяются в каждой записи их покупок. А это в среднем 10–20 символов. Чтобы не дублировать эти данные, можно создать отдельную таблицу.
+
+![](../img/norm2.webp)
+
+В отдельной таблице каждому покупателю можно присвоить номер — ключ. Тогда в основной таблице вместо имён будут ключи, которые свяжут обе таблицы. Это сократит количество символов в основной таблице, уберёт повторяющиеся сущности и упростит поиск
+
+Имена и фамилии сотни постоянных покупателей — это в среднем 1 500 символов. Если в год каждый из них посещает магазин 300 раз, то получается 450 000 символов. Только замена имён и фамилий на цифры сократит количество символов в записях в 3–4 раза.
+
+С товарами можно поступить так же: ввести категории, например, хлебобулочные изделия или молочная продукция, и создать для них отдельную таблицу. Так работает нормализация, цель которой — оптимизировать работу с базами данных.
+
+Чтобы работать с нормальными формами БД: добавить, изменить или найти данные в базе из множества взаимосвязанных таблиц, к ней обращаются на языке программирования SQL. Это декларативный язык или язык структурированных запросов.
+
+### Зачем нормализовать данные в БД
+
+Разберём преимущества нормализации данных на примере. Работа с нормализованными данными отдалённо напоминает поход за продуктами с книгой рецептов. Чтобы купить продукты для салата оливье, нужно открыть первую таблицу — книгу рецептов, перейти в подтаблицу — раздел «Салаты», найти нужный рецепт и положить в корзину продукты из него. Примерно так работают связи между таблицами данных.
+
+Без нормализации данных книга рецептов была бы одной большой таблицей с ингредиентами блюд. Чтобы купить продукты для оливье, пришлось бы сначала собрать в корзину все ингредиенты из книги. Потом найти те, что нужны для салата, а остальные выложить из корзины.
+
+Что даёт нормализация данных и как она упрощает работу с базами:
+
+1. Уменьшает объём базы данных и экономит место.
+
+    За счёт отдельных таблиц для категорий и повторяющихся элементов можно уменьшить размер записей в базе данных, а значит, и её вес.
+
+2. Упрощает поиск и делает работу с базой удобнее.
+
+    Нормализованную базу данных, которая состоит из связанных таблиц, можно оптимизировать для задач без дополнительных действий. Например, для поиска по заданной категории не придётся искать и перебирать уникальные элементы в базе. Для этого можно обратиться к отдельной таблице с категориями и быстрее найти нужные данные.
+
+3. Уменьшает вероятность ошибок и аномалий.
+
+    Нормальные формы данных в таблицах взаимосвязаны. Например, если нужно изменить или удалить данные в одной таблице, то остальные связанные с ней данные автоматически обновятся. Не придётся перебирать все записи в поисках полей, которые нужно изменить или удалить, а значит, не будет ошибок, когда в базу внесут изменения.
+
+### Как выполнить нормализацию
+
+Процесс нормализации данных нужно прописать на этапе проектирования базы, то есть до начала сбора данных. Если этого не сделать, есть риск, что база данных будет спроектирована плохо и её придётся переделывать. Обычно аналитики нормализуют данные вручную или передают задачу специалистам, которые собирают и хранят данные, например, инженерам данных.
+
+Для нормализации данных нет специального программного обеспечения. Данные в базе преобразуют по правилам. 
+
+#### Правила нормализации баз данных
+
+По правилам нормализации есть семь нормальных форм баз данных:
+
+* первая,
+* вторая,
+* третья,
+* нормальная форма Бойса-Кодда,
+* четвёртая,
+* пятая,
+* шестая.
+
+Приводить данные к нормальным формам можно только последовательно. То есть в базе данных второй нормальной формы данные по умолчанию уже должны быть нормализованы по правилам первой нормальной формы и так далее. В итоге база данных в шестой нормальной форме — идеально нормализованная. 
+
+В некоторых случаях попытка нормализовать данные до «идеального» состояния может привести к созданию множества таблиц, ключей и связей. Это усложнит работу с базой и снизит производительность СУБД. Поэтому обычно данные нормализуют до третьей нормальной формы. Разберём на примере.
+
+#### Первая нормальная форма
+
+В базе данных не должно быть дубликатов и составных данных.
+
+![](../img/norm3.webp)
+
+Слева данные о фамилии, имени и отчестве покупателей записаны в одно поле. Справа эти данные приведены к первой нормальной форме — каждый элемент записан в отдельное поле
+
+Элементы составных данных лучше разнести по разным полям, иначе в процессе работы с данными могут появиться ошибки и аномалии.
+
+Например, отдел маркетинга решил поздравить всех Александров с именинами и сделать рассылку с промокодом. Если таблица соответствует первой нормальной форме, можно найти нужные данные без дополнительных действий. Когда имя, отчество и фамилия записаны в одно поле, при поиске и сортировке в выборку попадут, например, Александровичи, Александровны и Александровы.
+
+Другой пример — адреса. Их тоже лучше приводить к первой нормальной форме. То есть город, район, улицу, номер дом и номер квартиры записывать в отдельные поля. Если какие-то данные дублируются, как в случае с именами и фамилиями постоянных покупателей, их нужно перенести в другую таблицу.
+
+#### Вторая нормальная форма
+
+Если упростить: у каждой записи в базе данных должен быть первичный ключ. Первичный ключ — это элемент записи, который не повторяется в других записях.
+
+Допустим, 10 декабря покупатель Егор Кузнецов купил цельнозерновой хлеб за 75 рублей в сетевом магазине продуктов города Москвы. Запись о его покупке появилась в базе данных. Нельзя исключать, что другой Егор Кузнецов в этот день купит такой же товар в другом магазине сети. Запись о покупке тоже появится в базе.
+
+![](../img/norm4.webp)
+
+Чтобы записи не перепутались, можно добавить к ним идентификатор покупки, например номер чека. (Уникальный) идентификатор покупки — это первичный ключ
+
+#### Третья нормальная форма
+
+В записи (строке таблицы) не должно быть столбцов с неключевыми значениями, которые зависят от других неключевых значений.
+
+![](../img/norm5.webp)
+
+Личный номер сотрудника — это первичный ключ. Данные во втором и третьем столбце напрямую зависят от первичного ключа. Но между личным номером сотрудника и руководителем отдела только косвенная или транзитивная связь. Её в базе данных третьей нормальной формы быть не должно
+
+Данные о руководителях отделов нужно вынести в другую таблицу. Тогда в основной таблице не будет транзитивных связей, и она будет соответствовать третьей нормальной форме.
+
+---
 
 ## Этапы проектирования БД
 
@@ -128,8 +390,6 @@ Primary key и foreign key помогают не только связывать
 
 [**Этап 3-й. Физическое проектирование**](#Физическое-проектирование) – развитие логической схемы БД с учетом выбранной целевой СУБД.
 
-Концептуальное и логическое проектирование вместе называют также **инфологическим** или **семантическим** проектированием.
-
 В настоящее время для проектирования БД активно используются **ERD (Entity – Relationship Diagrams, диаграммы «сущность–связь»)**. С их помощью определяются важные для предметной области объекты (сущности), отношения друг с другом (связи) и их свойства (атрибуты). Следует отметить, что средства проектирования **ERD** в основном ориентированы на реляционные базы данных (РБД), и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы проектирования.
 
 ## Основные элементы **ERD**.