База данных

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

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

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

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

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

 

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

4. Обобщения

 

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

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

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

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

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

В качестве примера реализации обобщения в реляционной модели данных построим следующую модель. Эта модель будет основана на обобщенном понятии «Учащиеся» и будет описывать  следующие категориальные понятия (т. е. будет обобщать следующие дочерние классы сущностей): «Школьники», «Студенты» и «Аспиранты».

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

 

Итак, что же мы видим?

Во-первых, каждому из базовых отношений (или из классов сущностей, что одно и то же) «Школьники», «Студенты» и «Аспиранты» соответствуют свои собственные атрибуты, как то «Класс», «Курс» и «Год обучения». Каждый из этих атрибутов характеризует участников своего собственного класса сущностей. Еще мы видим, что первичный ключ родительского класса сущностей «Учащиеся» мигрирует в каждый дочерний класс сущностей и формирует там первичный внешний ключ. При помощи этих связей мы можем по коду любого учащегося определить его имя, фамилию и отчество, информацию о которых мы не найдем в самих соответствующих дочерних классах сущностей.

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

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

 

Create table Школьники

…

primary key (Код  ученика)

foreign key (Код  ученика) references Учащиеся (Код ученика)

on update cascade

on delete cascade

 

Create table Студенты

…

primary key (Код студента)

foreign key (Код студента) references Учащиеся (Код студента)

on update cascade

on delete cascade;

 

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