Модель сущность-связь

2.2.7 Сильные и слабые сущности

Уточним понятия сильной и слабой сущности.

Может оказаться, что в первичный ключ сущности необходимо включить внешний ключ. Такая сущность называется слабой или зависимой.

Допустим, у нас есть никак не связанные команды и игроки. Пусть распределение игроков по командам несущественно. Это один подход. При втором подходе считается, что игрок — это всего лишь член некоторой команды. Если это так, то кроме его личного идентификатора, необходимо указать, к какой команде он относится. Сущность "Игрок" зависима от сущности "Команда". потому, что без указания команды игрока не выделишь однозначно.

Создадим две независимые сущности "Команда" и "Игрок" (рисунок 2.17):

Рис. 2.17. Независимые сущности

Установление идентифицирующей связи определяет сущность "Игрок" как слабую, то есть зависимую (рисунок 2.18).

Рис. 2.18. Идентифицирующая связь

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

Теперь рассмотрим случай, когда команды и игроки независимы. Выбираем неидентифицирующую связь (рисунок 2.19). Обратите внимание, что форма сущности "Игрок" осталась прежней (без скругления), а идентификатор из "Команды" мигрировал уже в неключевую область "Игрока".

Рис. 2.19. Неидентифицирующая связь

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

В базах данных есть много вещей, с которыми разобраться невозможно, если не использовать сведения из бизнеса. Дело в том, что база данных что-то из модели бизнеса отображает, а что-то — нет. Если вы не умеете или не хотите разбираться с бизнесом, то база данных у вас получится не вполне адекватной модели бизнеса.

Альтернативные ключи

Потенциальные ключи, не использующиеся как первичные, могут быть определены как альтернативные ключи и записаны в секции данных модели с символом (AKn.m), где n.m — номер альтернативного ключа в формате "номер_сущности". "номер_ключа", AK означает — альтернативный ключ (alternate key).

Допустим, нас устраивает "Номер потребителя" в качестве первичного ключа. Если все потребители имеют ИНН, то он тоже может быть ключом. Мы не используем его как ключ, но помечаем как альтернативный (рисунок 2.20).

Рис. 2.20. Альтернативный ключ

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

Отметим, что в реализациях на первичный, альтернативный и уникальный ключи обычно создается индекс. Индексы иногда (далеко не всегда) ускоряют поиск, но из-за необходимости перестраивания индекса всегда замедляются вставка, обновление и удаление записей. Если обозначим ИНН как альтернативный ключ, то при создании базы данных на него система сама построит индекс. Если вы никогда не будете производить поиск по этому столбцу, то значит вы перетяжелили базу, дали ей лишнюю нагрузку.

Если вы хотите отрисовывать пиктограммы ключей, то:

• На логическом уровне выберите в меню Format > Entity Display. Затем установите галочки в позициях Primary Key Designator, Foreign Key Designator, Alternative Key Designator.
• На физическом уровне выберите в меню Format > Table Display. Затем установите галочки в позициях Primary Key Designator, Foreign Key Designator, Alternative Key Designator.

2.2.8 Зачем нужна и когда используется модель сущность-связь?

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

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

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

Инструментальная поддержка модели "сущность-связь" дает хорошую графическую документацию для логической и физической схем базы. Более того, для самых распространенных баз, основанных на реляционной модели данных ( "Реляционная модель данных" ), по схеме можно сгенерировать скрипт на языке SQL, создающий схему базы. Эта операция называется прямым инжинирингом. Она выполняется только для диаграмм физического уровня. Обратный инжиниринг — это создание графического изображения модели по скрипту, создающему схему.

На рисунке 2.21 показан скрипт создания базы, сгенерированный по схеме рисунка 2.19 представленной на физическом уровне. В ERwin для выполнения прямого инжиниринга необходимо в головном меню выбрать позицию Tools, затем Forward Engeneer / Scheme Generation. Если в появившейся панели выбрать Preview, появится текст скрипта.

Рис. 2.21. Прямой инжиниринг

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