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

Коллектив авторов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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