Текст книги "Базы данных: конспект лекций"

Автор книги: авторов Коллектив

сообщить о нарушении

Текущая страница: 10 (всего у книги 12 страниц)

2. Диаграммы. Виды диаграмм

И теперь перейдем, наконец, непосредственно к рассмотрению диаграмм и их видов.

Вообще выделяют три уровня логической модели. Эти уровни различаются по глубине представления информации о структуре данных. Этим уровням соответствуют следующие диаграммы:

1) презентационная диаграмма;

2) ключевая диаграмма;

3) полная атрибутивная диаграмма.

Разберем каждый из названных видов диаграмм и подробно поясним смысл их различия по глубине представления информации о структуре данных.

1. Презентационная диаграмма.

Такие диаграммы описывают только самые основные классы сущностей и их связи. Ключи в таких диаграммах могут не описываться совсем, и соответственно, связи – никак не индивидуализироваться. Поэтому допустимыми являются связи типа «многие ко многим», хотя обычно их стараются избегать или, если они все же присутствуют, – детализировать. Также вполне допустимыми являются составные и многозначные атрибуты, хотя мы и писали раньше, что базовые отношения с такими атрибутами не являются приведенными к какой бы то ни было нормальной форме. Интересно, что из рассмотренных нами трех видов диаграмм только последний вид (полная атрибутивная диаграмма) предполагает, что данные, представленные с е помощью, находятся в некой нормальной форме. Тогда как уже рассмотренная презентационная диаграмма и следующая на очереди ключевая диаграмма ничего подобного не предполагают.

Такие диаграммы, как правило, используются для презентаций (отсюда и их название – презентационные, т. е. использующиеся для презентаций, демонстраций, где чрезмерная детализация и не нужна).

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

2. Ключевая диаграмма.

В отличие от презентационных диаграмм ключевые диаграммы описывают обязательно все классы сущностей и их связи, правда, в терминах только первичных ключей. Здесь связи «многие ко многим» уже непременно детализируются (т. е. связей такого типа в чистом виде здесь просто не может быть задано). Многозначные атрибуты все еще допускаются так же, как и в презентационной диаграмме, но если они присутствуют в диаграмме ключевой, то, как правило, они преобразуются в самостоятельные классы сущностей. Но, что любопытно, однозначные атрибуты все еще могут быть представлены не полностью или описаны как составные. Эти «вольности», еще допустимые в таких диаграммах, как презентационная и ключевая, не допустимы уже в следующем виде диаграммы, ведь они определяют, что базовое отношение не является нормализованным.

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

3. Полная атрибутивная диаграмма.

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

Однако у полных атрибутивных диаграмм все-таки есть недостаток, т. е. и их нельзя в полной мере назвать наиболее полными из диаграмм в смысле представления данных. Например, особенность конкретных систем управления базами данных при использовании полных атрибутивных диаграмм все еще не учитывается, и в частности, тип данных конкретизируется только в той мере, в какой это необходимо для необходимого логического уровня моделирования.

3. Связи и миграция ключей

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

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

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

Для удобства формулярного представления миграции ключей, введем следующие маркеры ключей:

1) PK – так мы будем обозначать любой атрибут первичного ключа (primary key);

2) FK – этим маркером мы будем обозначать атрибуты внешнего ключа (foreign key);

3) ^P_FK – таким маркером мы будем обозначать атрибут первичного/внешнего ключа, т. е. любой такой атрибут, который входит в состав единственного первичного ключа некоторого класса сущностей и одновременно в состав некоторого внешнего ключа этого же класса сущностей.

Таким образом, атрибуты класса сущностей с маркерами PK и FK образуют первичный ключ этого класса. А атрибуты с маркерами FK и ^P_FK входят в состав каких-то некоторых внешних ключей этого класса сущностей.

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

Всего различают две схемы миграции ключей.

1. Схема миграции ∀PK (PK |→^P_FK);

В этой записи символ «|→» означает понятие «мигрирует», т. е. приведенная формула прочитается следующим образом: любой (каждый) атрибут первичного ключа PK родительского класса сущностей переносится (мигрирует) в состав первичного ключа ^P_FK дочернего класса сущностей, который, естественно, является одновременно и внешним ключом для этого класса.

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

Такой вид связи называется идентифицирующей, так как ключ родительского класса сущности целиком участвует в идентификации дочерних сущностей.

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

1) полностью идентифицирующими.

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

Полностью идентифицирующую связь еще иногда называют категориальной, потому что полностью идентифицирующая связь идентифицирует дочерние сущности по всем категориям;

2) не полностью идентифицирующими.

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

Таким образом, помимо ключа с маркером ^P_FK будет также присутствовать ключ с маркером PK. При этом внешний ключ PFK дочернего класса сущностей будет полностью определяться первичным ключом PK родительского класса сущностей, а просто первичный ключ PK этого дочернего отношения не будет определяться первичным ключом PK родительского класса сущностей, он будет сам по себе.

2. Схема миграции ∃PK (PK |→ FK);

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

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

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

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

1) обязательно неидентифицирующими.

Неидентифицирующие связи называются обязательно не идентифицирующими в том и только в том случае, когда Null-значения для всех атрибутов мигрирующего ключа дочернего класса сущностей запрещены;

2) необязательно неидентифицирующими.

Неидентифицирующие связи называются не обязательно неидентифицирующими в том и только в том случае, когда Null-значе-ния для некоторых атрибутов мигрирующего ключа дочернего класса сущностей разрешены.

Обобщим все вышесказанное в виде следующей таблицы, чтобы облегчить задачу систематизации и понимания приведенного материала. Также в эту таблицу мы включим информацию о том, какие типы связей («не более одного к одному», «многие к одному», «многие к не более одному») соответствуют каким видам связей (полностью идентифицирующими, не полностью идентифицирующими, обязательно не идентифицирующими, не обязательно не идентифицирующими).

Итак, между родительскими и дочерними классами сущностей устанавливается следующий тип связей в зависимости от вида связи.

Итак, мы видим, что во всех случаях, кроме последнего, ссылка не пустая (not null) → 1.

Заметим такую тенденцию, что на родительском конце связи во всех случаях, кроме последнего, устанавливается кратность «один». Это происходит потому, что значению внешнего ключа в случаях этих связей (а именно, полностью идентифицирующая, не полностью идентифицирующая и обязательно не идентифцирующая виды связей) обязательно должно соответствовать (и притом единственное) значение первичного ключа родительского класса сущностей. А в последнем случае из-за того, что значение внешнего ключа допускает равенство Null-значению (флажок допустимости FK: null), на родительском конце связи устанавливается кратность «не более одного».

Проводим наш анализ дальше. На дочернем конце связи во всех случаях, за исключением первого, устанавливается кратность «много». Это происходит потому, что за счет неполной идентификации, как во втором случае, (или вообще отсутствия таковой, во втором и третьем случаях), значение первичного ключа родительского класса сущностей может многократно встречаться среди значений внешнего ключа дочернего класса. А в первом случае связь – полностью идентифицирующая, поэтому атрибуты первичного ключа родительского класса сущностей можгут встречаться среди атрибутов ключей дочернего класса сущностей только однажды.

Лекция № 12. Связи классов сущностей

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

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

1. Иерархическая рекурсивная связь

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

Вообще рекурсия (или рекурсивная связь) – это связь класса сущностей с самим собой.

Иногда по аналогии с жизненными ситуациями такую связь еще называют «рыболовный крючок».

Иерархической рекурсивной связью (или просто иерархической рекурсией) называется любая рекурсивная связь типа «не более одного ко многим».

Иерархическая рекурсия чаще всего используется для того, чтобы хранить данные древовидной структуры.

При задании иерархической рекурсивной связи первичный ключ родительского класса сущностей (который в данном конкретном случае одновременно выступает и в роли дочернего класса сущностей) должен мигрировать в качестве внешнего ключа в состав обязательно неключевых атрибутов того же класса сущностей. Все это необходимо для поддержания логической целостности самого понятия «иерархическая рекурсия».

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

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

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

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

Сначала составим презентационную диаграмму:

Теперь построим более подробную – ключевую диаграмму:

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

А теперь построим диаграмму, представляющую этот класс сущностей. Для этого выделим из таблицы все необходимые для этого сведения: предка у узла с кодом «единица» не существует или не определен, из этого делаем вывод, что узел «единица» является вершиной. Этот же самый узел «единица» является предком для узлов с кодом «два» и «три». В свою очередь, у узла с кодом «два» имеются два потомка: узел с кодом «четыре» и узел с кодом «пять». А у узла с кодом «три» – только один потомок – узел с кодом «шесть».

Итак, с учетом всего вышесказанного построим древовидную структуру, отражающую информацию о данных, заложенную в предыдущей таблице:

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

2. Сетевая рекурсивная связь

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

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

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

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

В нашем частном случае (в базах данных, подлежащих рассмотрению в нашем курсе) ассоциативная сущность не имеет собственных дополнительных атрибутов и называется именующей, так как именует связи «Предок – Потомок» путем ссылок на них. Таким образом, первичный ключ класса сущностей, представляющего узлы сети, должен дважды мигрировать в классы ассоциативных сущностей. В этом классе мигрировавшие ключи в совокупности должны образовывать составной первичный ключ.

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

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

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

Сначала представим презентационную диаграмму:

А теперь построим более подробную ключевую диаграмму:

Что мы здесь видим? А видим мы, что обе связи, имеющиеся в данной ключевой диаграмме, являются связями вида «многие к одному». Причем кратность «0… ∞ » или кратность «много» стоит на конце связи, обращенной к именующему классу сущностей. Действительно, ведь ссылок много, а ссылаются они все на какой-то один код узла, являющийся первичным ключом класса сущностей «Узлы».

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

Узлы:

Ссылки:

Действительно, вышеприведенное представление исчерпывающе: оно дает всю необходимую информацию для того, чтобы без труда воспроизвести зашифрованную здесь графовую структуру. Например, мы без всяких препятствий можем увидеть, что у узла с кодом «один» имеются три потомка соответственно с кодами «два», «три» и «четыре». Также мы видим, что у узлов с кодами «два» и «три» потомков не имеется вообще, а у узла с кодом «четыре» имеются (также как и у узла «один») три потомка с кодами «один», «два» и «три».

Изобразим граф, заданный классами сущностей, приведенными выше:

Итак, только что построенный нами граф и является теми данными, для связывания классов сущностей которых и использовалась связь вида сетевой рекурсии.

3. Ассоциация

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

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

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

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

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

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

Чаще всего ассоциация используется для детализации (разрешения) связей вида «многие ко многим».

Проиллюстрируем это утверждение.

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

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

А теперь построим более подробную ключевую диаграмму, в которой мы уже детализируем все имеющиеся связи «многие ко многим». Для этого мы соответственно введем новый класс сущностей, назовем его «Прием», который будет выступать в роли класса ассоциативных сущностей (позже мы посмотрим, почему именно это будет классом ассоциативных сущностей, а не просто классом именующих сущностей, о которых мы говорили ранее).

Итак, наша ключевая диаграмма будет выглядеть следующим образом:

Итак, теперь наглядно видно, почему новый класс «Прием» не является классом именующих сущностей. Ведь этот класс имеет свой дополнительный атрибут «Дата – Время», поэтому согласно определению нововведенный класс «Прием» и является классом ассоциативных сущностей. Этот класс «ассоциирует» классы сущностей «Врачи» и «Пациенты» друг с другом посредством времени, в которое и проводится тот или иной прием, что делает работу с такой базой данных гораздо удобнее. Таким образом, мы, введя атрибут «Дата – Время», буквально организовали так необходимое расписание работы различных врачей.

Также мы видим, что внешний первичный ключ «Код Врача» класса сущностей «Прием» ссылается на одноименный первичный ключ класса сущностей «Врачи». И аналогично внешний первичный ключ «Код Пациента» класса сущностей «Прием» ссылается на одноименный первичный ключ класса сущностей «Пациенты». В данном случае, что само собой разумеется, классы сущностей «Врачи» и «Пациенты» являются родительскими, а класс ассоциативных сущностей «Прием», в свою очередь, является единственным дочерним.

Мы видим, что теперь имеющаяся в прежней презентационной диаграмме связь типа «многие ко многим» полностью детализирована. Вместо одной связи «многие ко многим», какую мы видим в презентационной диаграмме, приведенной ранее, у нас имеется две связи типа «многие к одному». На дочернем конце первой связи стоит кратность «много», это буквально означает, что в классе сущностей «Прием» записано много врачей (все, которые есть в больнице). А на родительском конце этой связи стоит кратность «один», что это значит? А значит это, что в классе сущностей «Прием» каждый из имеющихся кодов каждого конкретного врача может встречаться неограниченно много раз. Действительно, ведь в расписании в больнице код одного и того же врача встречается много раз, в разные дни и время. А вот этот же код, но уже в классе сущностей «Врачи» может встретиться один и только один раз. Действительно, ведь в списке всех врачей больницы (а класс сущностей «Врачи» представляет собой не что иное, как такой список) код каждого конкретного врача может присутствовать только один раз.

Аналогичное происходит и со связью между родительским классом «Пациенты» и дочерним классом «Пациенты». В списке всех пациентов больницы (в классе сущностей «Пациенты») код каждого конкретного пациента может встретиться только один раз. Но зато в расписании приемов (в классе сущностей «Прием») каждый код конкретного пациента может встретиться сколь угодно много раз. Именно поэтому кратности на концах связи расставлены как раз таким образом.

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

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

Итак, построим ключевую диаграмму, отражающую суть отношений между заказчиком, исполнителем и консультантом.

Итак, начнем подробный разбор приведенной ключевой диаграммы.

Во-первых, класс «График» является классом ассоциативных сущностей, но, так же как и в прошлом примере, не является классом именующихся сущностей, ведь у него есть атрибут, не мигрирующий в него вместе с ключами, а являющийся его собственным атрибутом. Это атрибут «Дата – Время».

Во-вторых, мы видим, что атрибуты дочернего класса сущностей «График» «Код заказчика», «Код исполнителя» и «Дата – Время» образуют составной первичный ключ этого класса сущностей. Атрибут «Код консультанта» является просто внешним ключом класса сущностей «График». Обратим внимание, что этот атрибут допускает среди своих значений Null-значения, ведь по условию присутствие на встрече консультанта не обязательно.

Далее, в-третьих, заметим, что первые две связи (из трех имеющихся связей) являются не полностью идентифицирующими. Именно не полностью идентифицирующими, потому что мигрирующий ключ в обоих случаях (первичные ключи «Код заказчика» и «Код исполнителя») не полностью формирует первичный ключ класса сущностей «График». Действительно, ведь остается атрибут «Дата – Время», который также является частью составного первичного ключа.

На концах обеих этих не полностью идентифицирующих связей проставлены кратности «один» и «много». Это сделано для того, чтобы показать (как и в примере о врачах и пациентах) разницу, между упоминанием кода заказчика или исполнителя в разных классах сущностей. Действительно, в классе сущностей «График» любой код заказчика или исполнителя может встречаться сколь угодно много раз. Поэтому на этом, дочернем, конце связи стоит кратность «много». А в классе сущностей «Заказчики» или «Исполнители» каждый из кодов соответственно заказчика или исполнителя может встречаться один и только один раз, ведь эти классы сущностей являются каждый не чем иным, как полным списком всех заказчиков и исполнителей. Поэтому на этом, родительском конце связи, и стоит кратность «один».

И, наконец, заметим, что третья связь, а именно связь класса сущностей «График» с классом сущностей «Консультанты», является не обязательно не идентифицирующей.

Действительно, ведь в этом случае речь идет о переносе ключевого атрибута «Код консультанта» класса сущностей «Консультанты» в одноименный неключевой атрибут класса сущностей «График», т. е. первичный ключ класса сущностей «Консультанты» в классе сущностей «График» не идентифицирует первичного ключа уже этого класса. И, кроме того, как уже было упомянуто ранее, атрибут «Код консультанта» допускает Null-значения, поэтому здесь и используется именно не полностью не идентифицирующая связь. Таким образом, атрибут «Код консультанта» приобретает статус внешнего ключа и ничего более того.

Также обратим внимание на кратности связей, поставленных на родительском и дочернем концах этой не полностью не идентифицирующей связи. На ее родительском конце стоит кратность «не более одного». Действительно, если вспомнить определение не полностью не идентифицирующей связи, то мы поймем, что атрибуту «Код консультанта» из класса сущностей «График» не может соответствовать более одного кода консультанта из списка всех консультантов (которым является класс сущностей «Консультанты»). Да и вообще может так получиться, что ему не будет соответствовать ни одного кода консультанта (вспомним о флажке допустимости Null-значений Код консультанта: Null), ведь по условию присутствие консультанта на встрече заказчика и исполнителя, вообще говоря, не обязательно.