Полные атрибутивные диаграммы наиболее детально описывают все классы сущностей, их атрибуты и связи. Как правило, представляют данные в третьей нормальной форме (3NF). Однако особенности конкретных СУБД при этом все еще не учитываются и, в частности, тип данных конкретизируется лишь в той мере, в какой это необходимо для логического уровня моделирования.
На полных атрибутивных диаграммах иногда бывает удобно перейти от ссылок внешних ключей на первичные ключи к ссылкам на кандидатные ключи. Например, в базе данных организации сотрудник может идентифицироваться табельным номером как первичным ключом, и ИНН как кандидатным ключом. Но данные для налоговой службы, скорее всего, будут ссылаться по ИНН на кандидатный ключ данных о сотруднике.
5.2. Миграция ключей и виды связей
Процесс установления связей между классами сущностей, называемый миграцией ключей, связан с переносом (простого или составного) первичного ключа одного класса сущностей, называемого родительским, в другой класс, называемый дочерним.
Вдочернем классе атрибуты мигрировавшего ключа получают статус атрибутов внешнего ключа
ипри этом могут участвовать или не участвовать в формировании его первичного ключа. Таким образом, при миграции первичного ключа из родительского класса в дочерний в дочернем классе возникает внешний ключ, ссылающийся на первичный ключ родительского класса.
Введем маркеры атрибутов:
1)PK – атрибут (единственного) первичного ключа (primary key),
2)FK – атрибут (некоторого) внешнего ключа (foreign key),
3)PF – атрибут первичного/внешнего ключа.
Примечание. Для маркировки атрибутов первичного/внешнего ключа часто применяют маркер PF K
Атрибут первичного/внешнего ключа входит в состав (единственного) первичного ключа и одновременно в состав (некоторого) внешнего ключа.
Таким образом, все атрибуты класса сущностей с маркерами PK и PF образуют (в совокупности) первичный ключ. Атрибут с маркером PF или FK входит хотя бы в один внешний ключ, но может входить и в несколько внешних ключей одновременно. Конкретные вхождения определяются при установлении ссылок внешних ключей дочерних классов на первичные ключи родительских классов.
Атрибут PK первичного ключа родительского класса при миграции в дочерний классе может получить статус PF или FK, что можно символически изобразить в виде двух следующих схем миграции атрибутов первичного ключа:
1)PK 7!PF
2)PK 7!FK
Каждый атрибут первичного ключа может мигрировать по любой из этих схем. Но всевозможные комбинации таких составных миграций можно разбить на два класса со следующими схемами миграции первичного ключа:
1)8 PK (PK 7!PF)
2)9 PK (PK 7!FK)
Первая схема миграции означает, что каждый атрибут первичного ключа родительского класса переносится в состав первичного ключа дочернего класса. Такая связь называется идентифицирующей, так как все атрибуты родительского ключа участвуют в идентификации дочерней сущности.
Вторая схема миграции означает, что некоторые атрибуты первичного ключа родительского класса переносятся в состав неключевых атрибутов дочернего класса. Такая связь называется неидентифицирующей, так как не все атрибуты родительского ключа участвуют в идентификации дочерней сущности.
Идентифицирующая связь может быть двух видов в зависимости от того, полностью или неполностью (частично) атрибуты мигрировавшего ключа формируют первичный ключ дочернего класса. Полностью идентифицирующая связь называется также категориальной
Неидентифицирующая связь может быть также двух видов, но в зависимости от того, запрещены ли null-значения для всех атрибутов мигрировавшего ключа, или для некоторых разрешены. Если запрещены, то неидентифицирующая связь называется обязательной. Если разрешены, то необязательной.
Этих четырех декларативно поддерживаемых СУБД видов связей, – полностью и неполностью идентифицирующих, обязательных и необязательных неидентифицирующих, – достаточно для большинства задач, возникающих на практике. Нестандартные виды связей должны поддерживаться процедурно с помощью триггеров.
Важно отметить, что на презентационных диаграммах разработчиком устанавливаются проектируемые (требующие последующей реализации) кратности на концах связей. Например, между сущностями Отдел и Сотрудник при проектировании может быть установлена связь типа не-более- один-ко-многим (0 : : : 1 : 0 : : : 1), один-ко-многим (1 : 0 : : : 1), многие-ко-многим (0 : : : 1 : 0 : : : 1) или, скажем, два-ко-многим (2 : 0 : : : 1). Во всех случаях здесь каждому отделу разрешается иметь много сотрудников. Но в первом случае каждый сотрудник может вообще не числиться или числиться только в одном отделе. Во втором – обязан числиться в одном отделе. В третьем – может числиться во многих отделах, а в последнем случае обязан числиться в двух отделах (совместитель). Выбор того или иного типа устанавливаемых связей определяется правилами, установленными для предметной области проектируемой базы данных.
При переходе к ключевым диаграммам ситуация иная. Здесь уже представлены спроектированные (реализованные) кратности на концах связей. Эти кратности являются следствием вида установленных связей. Но возможностей, предоставляемых механизмом миграции ключей, может быть недостаточно для выражения всех требований, представленных на презентационных диаграммах. Тогда при изображении классов сущностей следует указать необходимость их поддержки, включив описания или ссылки на описания дополнительных ограничений и используемых триггеров в секцию ограничений (табл. 5.1).
Таблица 5.1.: Изображение класса сущностей с секцией ограничений
Сущности
М
а
р
к Атрибуты
е
р
ы
Ограничения Triggers
Между родительским и дочерним классами сущностей устанавливаются различные типы связей в зависимости от вида связи (рис. 5.2).
Почему возникают такие кратности? Рассмотрим примеры, соответствующие различным видам
Рис. 5.2.: Типы связей в зависимости от вида связи
связи (рис. 5.3, 5.4).
Рис. 5.3.: Схема миграции PK 7!PF: идентифицирующие связи
На родительском конце связи только в последнем случае из-за возможности появления среди значений внешнего ключа null-значений устанавливается необязательная связь (допускающая кратность 0). В остальных случаях устанавливается кратность 1, так как согласно ограничению ссылочной целостности значению внешнего ключа должно быть сопоставлено значение первичного ключа родительской сущности. Но оно может быть лишь одно, так как значения первичного ключа уникальны.
На дочернем конце связи все связи являются необязательными (допускают кратность 0), так как
Рис. 5.4.: Схема миграции PK 7!FK: неидентифицирующие связи