ЧАСТЬ 1 Теория реляииомных баз данных

ко два отношения, в результате будут получены совершенно неверные данные.

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

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

Итоги

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

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

Связи

ГЛАВА

В главе 2 мы подробно рассмотрели процесс модели

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

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

Основные понятия и определения

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

Участие каждой сущности в связи бывает полным или частичным, в зависимости может и эта сущность существовать, если дан-

ная связь не определена. Например, для связи двух сущностей -CMitomer (Покупатель) и Order {Счет), участие сущности Customer дет частичным, поскольку информацию о можно

до того как покупателю будет выписан первый счет. Участие cyrjiF-foc-ти Order в связи Customer - Order будет полным, поскольку любой счет можно выписать только какому-либо покупателю.

ЧАСТЬ 1 баз данных

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

независимо от наличия связей между ними и другими сущностями. Подобная классификация положена в основу метода составления ди-.аграмм сущности - связи , предложенного ом (Chen).

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

классификация всех связей не является строго обязательной при создании модели данных. И все же если при моделировании больших сложных систем указано влияние отношения остъ, задача разработчика заметно облегчается. Чтобы указать на диаграмме сущности мзи*, является ли сущность слабой или обгчной, вы можете использовать обозначения, показанные на рис. 3-1.

Рис. 3-1. Различия между слабыми и обычными сущностями

В некотор1х случаях полезно разделить все связи на два типа - IsA ( является А или входит в А ) адаетА ). Принцип такого! разделения весьма прост, мы проиллюстрируем его на примере сущностей В и С: В либо IsA С, либ С. Например, для сущностей Employee (Сотрудник) и allTeam (Баскетбольная команда) может быть определена связь BasketballTeam (сотрудник является членом баскетбольной команды); для сущностей Employee и Address (Адрес) может быть определена связь Employee А(п)Address. Конечно, английские термин:> и Has не всегда правильно описывают природу связи между сущностями. Например, если связь между Employee и SalesOrder (Счет-фактура) определена как Employee HasA SalesOrder, это отнюдь не означает, что сотрудник обладает счетом - на самом деле он выписывает счет. Но все же при семантическом анализе очевидно, что связь между Employee и SalesOrder не может быть IsA SalesOrder - это допущение слишком далеко от реальности.

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