Тема 2.1. Введение в информационные системы. ER – диаграмма. 2 страница

Рассмотрим дерево множеств сущностей, соединенных связями isa. Некоторая сущность состоит из компонентов (components), относящихся к одному или несколь­ким указанным множествам сущностей, если эти компоненты принадлежат поддереву (subtree) исходного дерева, включающему корневую вершину. Другими словами, если некоторая сущность е обладает компонентом с из множества сущностей Е и родитель­ским по отношению к Е в дереве является множество F, то е обладает также некото­рым компонентом d из F. Кроме того, с и d должны быть представлены в виде пары во множестве данных для связи isa, направленной от Е к F. Сущность е имеет те же атрибуты, которыми обладает любой из ее компонентов, и участвует в тех же связях, к которым имеет отношение любой из этих компонентов.

Пример 10. Обратимся к рис. 10. Сушность-"кинофильм", которая не относится ни к жанру мультипликации {Cartoons),, ни к числу "боевиков" (Murder-Mysteries), бу­дет обладать только таким компонентом, который принадлежит корневому множеству сущностей Movies ("кинофильмы"). Всем сущностям Movies поставлены в соответствие четыре атрибута (length ("продолжительность"), title ("название"), year ("год производ­ства") и filmType ("тип пленки")) и две связи (Stars-in ("актеры-участники") и Owns ("владеет") — последние на рис. 2.10 не показаны).

Различия параллельных связей

На рис. 10 иллюстрируется одна тонкая особенность ER-связей, требующая до­полнительного разъяснения. Диаграмма содержит две различные связи, Studio-of-Star ("студия-владелец актера") и Producing-Studio ("студия-продюсер кинофиль­ма"), и каждая из них соединяет одни и те же множества сущностей — Contracts ("контракты") и Studios ("киностудии"). Мы, однако, не вправе ожидать, что из факта "параллельности" связей следует идентичность множеств данных, соответ­ствующих этим связям. Действительно, в рассматриваемом здесь случае совершен­но неправомочно полагать, что обе связи представляют один и тот же "контракт", относящийся к некоторой сущности-"киностудии", поскольку иначе студия долж­на заключать контракт сама с собой.

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

Сущность-"мультфильм", не являющаяся "боевиком", обладает двумя компонен­тами, один из которых относится к множеству Movies, а другой — к Cartoons. Поэтому она получит не только четыре упомянутых выше атрибута множества Movies, но и связь Voices ("голоса"). Аналогичным образом, сущность-"боевик", не являющаяся "мультфильмом", также обладает двумя компонентами, один из которых относится к множеству Movies, а другой — к Murder-Mysteries, и поэтому характеризуется пятью атрибутами, включая weapon ("оружие").

Наконец, сущности-"кинофильмы" (подобные "Roger Rabbit"), которые относятся к жанрам мультипликации и "боевика" одновременно, обладают компонентами всех трех множеств — Movies, Cartoons и Murder-Mysteries. Компоненты соединяются в це­лостную сущность благодаря связям isa. Рассматриваемые совместно, эти компоненты поставят в соответствие тому же "Roger Rabbit" все четыре атрибута множества сущ­ностей Movies плюс атрибут weapon множества Murder-Mysteries плюс связь Voices мно­жества Cartoons.

Принципы проектирования

1. Достоверность

Прежде всего, проект обязан достоверно представлять спецификацию базы дан­ных. Другими словами, множества сущностей и их атрибуты должны соответствовать реальным требованиям. Вы не вправе, например, ассоциировать с множеством сущно­стей Stars ("актеры") атрибут number-of-cylinders ("количество цилиндров"), хотя по­следний вполне применим по отношению к множеству Automobiles ("автомобили"). Прежде чем вводить в модель новое множество сущностей, атрибут или связь, надле­жит задаться вопросом, а все ли доподлинно известно о той части реального мира, ко­торая должна быть смоделирована.

Пример 10. Если вновь присмотреться к связи Stars-in ("актеры-участники"), соеди­няющей множества сущностей Stars ("актеры") и Movies ("кинофильмы"), станет оче­видным, что она должна относиться к типу "многие ко многим". Причины бесспор­ны: здравый смысл, основанный на элементарном понимании моделируемых сущно­стей, подсказывает, что актеры вправе участвовать в съемках нескольких фильмов, а в каждом фильме могут быть заняты одновременно несколько актеров. Совершенно неправомерно считать, что связь Stars-in в любом направлении может представлять отношение "многие к одному" или, более того, "один к одному".

Пример 11. Подчас, однако, далеко не очевидно, как именно те или иные объекты реального мира должны соотноситься в рамках ER-модели. Рассмотрим для примера множества сущностей Courses ("учебные курсы") и Instructors ("преподаватели"), со­единенные связью Teaches ("обучает"). Действительно ли Teaches представляет связь типа "многие к одному" в направлении от Courses к Instructors! Ответ зависит от кор­поративной политики и традиций конкретного учебного заведения. Вполне возможно, что за каждым курсом закреплен в точности один преподаватель. Даже в том случае, если несколько преподавателей ведут курс совместно, не исключено, что в соответст­вии с внутренними требованиями организации в базе данных должен быть указан только один из преподавателей, "ответственный" за курс. В любом из подобных слу­чаев мы имеем право утверждать, что связь Teaches, соединяющая множества сущно­стей Courses и Instructors^ должна относиться к типу "многие к одному" (если рассмат­ривать ее в указанном направлении).

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

Отсутствие избыточности

Мы обязаны тщательно следить за тем, чтобы объекты структуры не повторяли друг друга. Пусть, например, сущности Movies ("кинофильмы") и Studios ("киностудии") соединены связью Owns ("владеет"). Мы можем также снабдить мно­жество сущностей Movies атрибутом studioName ("название студии"). Хотя такое реше­ние на первый взгляд вполне приемлемо, оно таит в себе ряд опасностей.

1. Повторение описания студии-владельца кинофильма приводит к дополнитель­ному расходу памяти при хранении атрибута в базе данных.

2. При продаже кинофильма мы можем изменить название студии, которая им владела, на новое, определяемое связью Owns, но забыть исправить содержимое атрибута studioName — или умудриться сделать наоборот. Конечно, можно ут­верждать, что подобные ошибки вряд ли вероятны, но на практике они, к не­счастью, случаются, и, пытаясь описать некий объект несколькими различными способами, мы заранее ставим себя, мягко говоря, в невыгодное положение.

Простота

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

Пример 12. Предположим, что вместо непосредственной связи между множествами сущностей Movies ("кинофильмы") и Studios ("киностудии") мы считаем целесообраз­ным использовать новое "промежуточное" множество сущностей Holdings ("права вла­дения"), описывающее факт принадлежности конкретного фильма определенной сту­дии. Между каждым фильмом и сущностью "права владения" может быть установлена связь Represents ("представляет") типа "один к одному". Общую картину, иллюстри­руемую рис. 11, завершает связь типа "многие к одному", соединяющая множества сущностей Holdings и Studios.

Рис. 11. Неудачный пример: в диаграмму включено избыточное множество сущностей

Если говорить формально, структура, приведенная на рис. 11, совершенно верно отображает реальные зависимости, поскольку она позволяет "проследовать" от кон­кретного кинофильма к студии, которая им владеет, при посредничестве множества сущностей Holdings. Последнее, однако, не выполняет никаких уникальных функций, и его вполне можно исключить. Не сделав этого, при создании базы данных и соот­ветствующих программных приложений мы затратим усилия и время на реализацию более сложных зависимостей и поиск дополнительных вероятных ошибок, а также из­расходуем лишнее дисковое пространство. □

Выбор подходящих связей

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

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

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

Пример 2.15. Вернемся к диаграмме рис. 7, на которой множества сущно­стей Movies ("кинофильмы"), Stars ("актеры") и Studios ("киностудии") соединены с помощью тернарной связи Contracts ("контракты"). Здесь опущены две бинарные связи, Stars-in ("актеры-участники") и Owns ("владеет"), введенные в диаграмму ра­нее, на рис. 2. Возникает закономерный вопрос, действительно ли связи Stars-in (между Movies и Stars) и Owns (между Movies и Studios) все еще необходимы при наличии связи Contracts? Ответ таков: "не известно; решение зависит от того, ка­кой смысл мы вкладываем в каждую из трех рассматриваемых связей".

Вполне возможно получить связь, аналогичную Stars-in, на основании связи Contracts. Если актер появляется в фильме только при наличии соответствующего кон­тракта, в котором упоминаются сам актер, студия и производимый ею фильм, тогда дей­ствительно необходимость в использовании связи Stars-in отпадает: для определения всех пар вида "актер—кинофильм" для заданных сущностей "актер" и "кинофильм" достаточно просмотреть кортежи "актер—кинофильм—киностудия" множества данных, отвечающего связи Contracts, и выбрать нужные, ограничившись компонентами "актер" и "кинофильм". Если, однако, актер может сниматься в фильме, не подписав кон­тракт — или, что более вероятно с практической точки зрения, не имея контракта, кото­рый был бы зафиксирован в нашей базе данных, — тогда во множестве данных связи Stars-in могут существовать такие пары вида "актер—кинофильм", которые не являются ча­стью кортежей "актер—кинофильм—киностудия" множества данных связи Contracts. В этой ситуации связь Stars-in обладает самостоятельным значением и должна быть сохранена.

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

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

Пример 2.16. Давайте вновь обратимся к диаграмме рис. 2. На ней нет ка­ких-либо прямых связей между множествами сущностей Stars ("актеры") и Studios ("киностудии"). Но мы можем получить необходимую соединяющую цепочку, ис­пользуя свойства связей Stars-in ("актеры-участники") и Owns ("владеет"), поскольку некоторый "актер" связан посредством Stars-in с определенными "кинофильмами", а те, в свою очередь, благодаря связи Owns соединены с соответствующими сущностями-"киностудиями". Таким образом, можно говорить, что актер связан со студией, владеющей фильмом, в котором этот актер снимался.

Имеет ли смысл включать в диаграмму дополнительную связь — что-то вроде Works-for ("работает" на киностудию) — между множествами сущностей Stars и Studios, как показано на рис. 12? И вновь, как и прежде, мы не можем ответить на этот вопрос однозначно, не обладая нужными сведениями. Самое главное, каково истинное назначение этой связи? Если ее смысл таков, что "актер снялся, по меньшей мере, в одном фильме, выпушенном студией", тогда, вероят­но, веских причин для использования подоб­ной связи нет, так как аналогичная информа­ция может быть получена на основе сущест­вующих связей, Stars-in и Owns.

Однако вполне вероятна ситуация, что име­ется некая иная информация (возможно, со­вершенно уникальная) об особенностях работы актеров со студиями, которая не отражена в цепочке связей Stars-in и Owns. В этом случае связь, соединяющая множества сущно­стей Stars и Studios напрямую, может оказаться полезной и не восприниматься как избыточ­ная. Например, такая связь должна представить тот факт, что актер связан со студией неким общим контрактом, который не имеет отношения к конкретному кинофильму. Кроме того, как мы упоминали в примере 7, отнюдь не невероятно, что актер, заключивший контракт с одной студией, принимает участие в фильме, выпускаемом другой студией. В подобных ситуациях новая связь Works-for никак не зависит от связей Stars-in и Owns и определенно не бу­дет считаться излишней.

Рис. 12 Включение в диаграмму дополнительной связи.

Использование элементов адекватных типов

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

Пример 2.17. Обратимся к рис.2 и рассмотрим одну частную проблему. На­сколько здравым было наше решение о представлении объектов "киностудия" отдель­ным множеством сущностей Studios? Может быть, следовало передать атрибуты "название студии" и "адрес студии" множеству сущностей Movies ("кинофильмы") и исключить Studios вовсе? Если поступить так, как мы сказали, придется повторять ад­рес студии в наборе данных о каждом кинофильме. Это еще один пример избыточности, подобный тем, которые упоминались в двух предыдущих разделах. Помимо издержек, связанных с избыточностью данных, мы столкнемся со следующей опасностью: если в базе данных будут отсутствовать сведения о каких бы то ни было фильмах, снятых определенной студией, информация об этой студии как таковой окажется утраченной.

С другой стороны, если потребность в хранении адреса студии не возникает, ника­кого вреда не принесет то, что наименование студии в качестве атрибута будет по­ставлено в соответствие каждому фильму. Теперь об избыточности из-за многократ­ного повторения адреса студии речь не идет, а то, что наименование студии, такое как, скажем, "Disney", указывается для каждого фильма, снятого этой студией, не может рассматриваться как излишняя информация, поскольку авторские права студии должны быть отражены так или иначе. □

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

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

2. Атрибуты множества Е в совокупности обязаны однозначно определять любую сущность множества. Чаще всего имеется только один такой атрибут, и в этом случае условие определенно удовлетворяется. Если же множество обладает не­сколькими атрибутами, ни один из них не должен зависеть от остальных (таким образом, как, например, атрибут address ("адрес") множества сущностей Studios ("киностудии") зависит от атрибута пате ("название") того же множества).

3. Ни в одной из связей множество Е не должно участвовать многократно.

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

a) если существует связь R типа "многие к одному", направленная от некото­рого множества сущностей F к множеству Е, следует удалить R и передать атрибуты Е множеству F, выполнив при необходимости их переименование, если F уже содержит атрибуты с теми же именами; в результате каждая сущ­ность множества F получит в качестве атрибута наименование уникальной связанной с ней сущности множества Е ⁴ (как, например, в случае, когда сущностям "кинофильм" передается атрибут "название студии", а атрибут "адрес студии" исключается).

b) если существует многосторонняя связь R, содержащая стрелку, направлен­ную к £, целесообразно передать атрибуты Е связи R и удалить стрелку, со­единяющую R с Е\ примером может служить возврат от диаграммы рис. 8, где было введено новое множество сущностей Salaries, к исход­ной версии диаграммы с аналогичным атрибутом salary, относящимся к элементу связи Contracts (см. рис. 7).

Пример 2.18. Проанализируем ситуацию, предполагающую выбор компромиссного решения — использовать многостороннюю связь или предпочесть соединяющее мно­жество сущностей и набор из нескольких бинарных связей. В разделе 2.1.8 на мы рассматривали четырехстороннюю связь Contracts ("контракты"), соединяющую сущ­ности "актер" (из множества Stars), "кинофильм" (Movies) и две сущности "киностудия" (Studios) (см. рис.6). На диаграмме рис. 9 в пре­дыдущем разделе эта структура была "механически" преобразована в одноименное со­единяющее множество сущностей Contracts с несколькими дополнительными бинар­ными связями. Возникает вопрос, насколько принципиален подобный выбор.

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

⁴ В ситуации, где F-сущность не связана ни с какой Е -сущностью, новым атрибутам множе­ства F будут присвоены специальные значения null, свидетельствующие об отсутствии подходя­щей Е-сущности. Подобное замечание применимо и к случаю передачи атрибутов множества Е связи R, который рассматривается в п. (b).

Чтобы модель адекватно описывала условия поставленной задачи, множество дан­ных связи Contracts должно состоять из кортежей вида

(star, movie, set-of-studios),

и связь Contracts как таковая будет охватывать не только привычные множества сущ­ностей Stars и Movies, но и новое множество сущностей, элементами которого являют­ся множества студий ("set-of-studios"). Хотя в рассматриваемой ситуации такого ре­зультата, как кажется, избежать нельзя, похоже, не совсем естественно воспринимать множества студий в виде элементарных сущностей, и поэтому мы не рекомендуем применять указанный подход.

Более предпочтительным представляется решение, в котором контракты описываются множеством сущностей. На диаграмме рис. 9 сущность "контракт" соединяет­ся с сущностями "актер", "кинофильм" и двумя сущностями "киностудия", но сейчас ог­раничение на количество киностудий, подписывающих контракт, должно быть снято. Связь между множествами Contracts и Studios приобретает свойство "многие ко многим", а не относится к типу "многие к одному", как в том случае, когда Contracts является "подлинным" соединяющим множеством сущностей. Новая версия диаграммы приве­дена на рис. 13. Еще раз подчеркнем, что теперь контракт соединяет по одной сущно­сти вида "актер" и "кинофильм" с произвольным числом сущностей "киностудия". □

Рис. 13. Контракт соединяет актера и кинофильм с произвольным множеством киностудий

Упражнения к разделу 2.2

Упражнение 2.2.1. На рис. 2.14 представлена диаграмма, описывающая структуру базы данных банка, в которой предусматривается хранение информации о клиен­тах {Customers) и их счетах {Accounts). Поскольку в общем случае клиент вправе от­крыть в банке несколько счетов, а счетом могут совместно распоряжаться несколь­ко клиентов, клиентам ставятся в соответствие "наборы счетов" (AcctSets), и каж­дый счет может быть членом (Member-of) одного или нескольких "наборов счетов". Мы полагаем, что смысл всех остальных связей и атрибутов, приведенных на диа­грамме, внятно определяется их названиями (owner-address — "адрес владельца", Has — "обладает", пате — "имя", number — "номер счета", balance — "размер ос­татка на счете", Lives-at — "проживает", Addresses — "адреса", address — "адрес"). Изучите схему и попытайтесь выдвинуть собственные критические замечания. Ка­кие правила проектирования, по вашему мнению, нарушены? Почему? Какие из­менения вы предложили бы внести?

Упражнение 2.2.2. При каких условиях два множества сущностей — Studios ("киностудии") и Presidents ("президенты") — и связь Runs ("возглавляет"), обра­зующие диаграмму рис. 3 (с учетом атрибутов, которые для краткости опущены), могут быть заменены единственным множеством сущностей с соответ­ствующими атрибутами?

Упражнение 2.2.3. Предположим, что атрибут address ("адрес") множества сущно­стей Studios ("киностудии") на диаграмме рис. 7 удален. Покажите, ка­ким образом множество Studios теперь может быть заменено некоторым атрибутом. Как именно следовало бы расположить этот атрибут?

Рис. 2.14. Неудачный пример: диаграмма банковской базы данных

Упражнение 2.2.4. Выберите атрибуты для перечисленных ниже множеств сущно­стей диаграммы рис. 2.13, что позволит заменить каждое из этих множеств некото­рым атрибутом:

a) Stars ("актеры");

b) Movies ("кинофильмы");

c)! Studios ("киностудии").

Упражнение 2.2.5. В этом и следующих примерах мы рассмотрим два альтернативных проектных решения, касающихся возможности описания события рождения челове­ка. С фактом рождения связана одна сущность "младенец" (событие рождения близ­нецов может быть отображено набором отдельных кортежей данных), сущность "мать" и произвольные наборы сущностей "медсестра" и "врач". Предположим да­лее, что имеются множества сущностей Babies ("младенцы"), Mothers ("матери"), Nurses ("медсестры") и Doctors ("врачи"), а также связь Births ("роды"), соединяющая названные множества сущностей так, как показано на диаграмме рис. 2.15. При­мите к сведению, что кортеж множества данных связи Births имеет следующий вид:

(baby, mother, nurse, doctor).

Если родовспоможением занимается более одной медсестры и/или врача, будут су­ществовать несколько кортежей для одних и тех же компонентов данных "младенец"

("baby") и "мать" ("mother") — по одному на каждую комбинацию компонентов "медсестра" ("nurse") и "врач" ("doctor").

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

Рис. 15. Представление события "ро­ды " с помощью многосторонней связи

а) Каждой сущности "младенец" соответ­ствует уникальная сущность "мать".

b) Каждому сочетанию сущностей "младенец", "медсестра" и "доктор" соот­ветствует уникальная сущность "мать".

Рис. 16. Представление события "роды" посредством множества сущностей

с) Каждой комбинации сущностей "младенец" и "мать" соответствует уни­кальная сущность "доктор".

Упражнение 2.2.6. Другой подход к решению проблемы, описанной в упражнении 2.2.5, состоит в соединении множеств сущностей Babies ("младенцы"), Mothers ("матери"), Nurses ("медсестры") и Doctors ("врачи") с множеством сущностей Births ("роды") посредством четырех отдельных связей, как показано на рис. 2.16. Используя стрелки (с целью констатации, что соответствующая связь относится к типу "многие к одному"), обеспечьте реализацию следующих условий:

d) каждая сущность "младенец" связана с уникальной сущностью "роды" и каждая сущность "роды" связана с уникальной сущностью "младенец";