Теория и практика построения баз данных (1088289), страница 46
Текст из файла (страница 46)
210 Глава 6. Проектирование баз данных в рамках модели «сущность — связь» Преобразование моделей «сущность — связь», 211 Тем не менее, отношения в ДКНФ ие всегда являются самыми предпочтительными. Если отношения запутаны и с ними сложно работать, более удачным может оказаться решение, не основанное на ДКНФ. Производительность также может иметь значение. Обращение к двуга или трем отношениям для получения необходимых данных о клиенте может отнимать чересчур много времени. Независимо от того, каким будет наше решение относительно нормализаццп, мы должны исследовать каждое из отношений сущности применительно к критериям нормализации. То естть если мы собираемся «согрешить», следует принять на этот счет взвешенное и обдуманное решение.
Попутно мы определим типы аномалий модификации, которым подвержены исследуемые отношения. Представление слабых сущностей Слабые сущности требуют особого подхода при создании реляционной структуры. Вспомните, что существование слабой сущности зависит от некоторой другой сущности. Если слабая сущность является экзистенциально-зависимой, но не идентификационно-зависимой, ее можно преобразовать в реляционную конструкцию с помощью приемов, описанных в предыдущем разделе. Экзистенциальная зависимость должна быть встроена в реляционную конструкцию таким образом, чтобы приложение не могло создать слабую сущность без ее родителя (сущности, от которой данная сущность зависит). Более того, деловой регламент необходимо дополнить положением, согласно которому при удалении родителя слабая сущность также удаляется.
Эти правила должны быть описаны в реляционной структуре. Данная ситуация вы~ладит несколько по-иному, если слабая сущность является также идентификационно-зависимой. На рис. 6.4, а СТРОКА РАСХОДОВ является идентификационно-зависимой сущностью. Эта сущность слабая, поскольку ее логическое существование зависит от сущности СЧЕТ, и идентификационно-зависимая, поскольку ее идентификатор содержит идентификатор сущности СЧЕТ.
При создании отношения для иде~ттнфикационно-зависимой сугцностн мы обязаны поместить в него ключ как самой сущности, так и ее родителя. Посмотрим, например, что получилось бы, если бы мы просто ввели отношение для сущности СТРОКА РАСХОДОВ и не включили в него ключ сущности СЧЕТ. Такое отношение показано на рис. 6.4, б. Что является ключом этого отношения? Поскольку сущность СТРОКА РАСХОДОВ является идентификационно-зависимой, у пее нет полноценного ключа, и фактически, это отношение вполне может иметь повторяющиеся строки. (Такое может случиться, если в двух заказах указано одно и то же количество определенного тонара в одной и той же строке.) Таким образом, если имеется идентификационно-зависимая сущность, в отношение для этой сущности необходимо добавить ключ родительского отношения, и этот дополнительный атрибут становится частью ключа слабой сущности.
На рис. 6А, в мы добавили в отношение СТРОКА РАСХОДОВ атрибут НомерСчета— ключ отношения СЧЕТ. Ключом отношения СТРОКА РАСХОДОВ является комбинация (НомерСчета, НомерСтроки). СТРОКА РАСХОДОВ (Номврстдокии, Количество, Нем«РТовврв, Описание, Цена, Стоимость) б ~к«г (а«к, к Описание, цена, Стоимость) Рис. В.4. Реляционное представление слабой сущности: в — пример слабой сущности; б — отношение, представляющее сущность СТРОКА РАСХОДОВ, с неправильным ключом; в — отношение, представляющее сущность СТРОКА РАСХОДОВ, с правильным ключом Представление связей типа «ИМЕЕТ» В модели «сущность — связь> есть две разновидности связей; связь типа «ИМЕЕТ», характерная для сущностей, принадлежащих к разным логическим типам, и связь типа «ЕСТЬ», возникающая между сущностями, которые являются подтипами одного и того же логического типа.
В этом разделе мы рассмотрим связи типа ИМЕЕТ»; к связям типа «ЕСТЬ» мы обратимся позже. Существует три вида связей типа «ЕСТЬ»: «один к одному», «один ко многим» и «многие ко многим». Представление связи «один к одному» Простейшая форма бинарной связи — зто связь «один к однотиу» (1;1), при которой сущность одного типа связана не более чем с одной сущностью другого типа. В примере с сущностями СОТРУДНИК и АВТОМОБИЛЬ такая связь отражает ситуацию, когда за сотрудником может быть закреплено не более одного автомобиля, а автомобиль может быть выделен не более чем одному сотруднику. ЕК-диаграхгма для этого случая изображена на рнс.
6.5. Представление связи 1:1 с помощью реляционной модели осуществляется просто. Сначала каждая сугцность представляется в виде отношения, а затем ключ одного из отнонтений помегпается в другое. На рис. Б.6, а ключ отношения СОТРУДНИК помещается в отношение АВТОМОБИЛЬ, а на рис. 6.6, б ключ отношения АВТОМОБИЛЬ помещается в отношение СОТРУДНИК. Когда ключ одного отношения помещается в другое отношение, он называетгя внешттим ключом (Тоге)цп )сеу).
На рис. 6.6, а НомерСотрудника является внешним ключом отношения АВТОМОБИЛЬ, а на рпс, 6.6, б НомерЛицензии — внешний ключ оттто~пения СОТРУДНИК, На этом рисунке внешние ключи выделены куренном, но иногда их подчеркивают пунктирной линией. Бывает и так, что внешние ключи вообще никак специально не выделяются, В тех местах данного текста, где потенциально может возникнуть путаница, мы будем выделять внешние ключи курсивом, но в болыпинстве случаев они не будут обозначаться явно. При связи 1:1 можно взять ключ любой из таблиц и поместить его в качестве ннешнего ключа в другую таблицу.
На рис. 6.6, а в таблицу СОТРУДНИК помещен нпешний ключ НомерЛицензии. При такой структуре мы можем двигаться от 212 Глава б. Проектирование баз данных в рамках модели «сущность — связь» Преобразование моделей «сущность — связь» 213 таблицы СОТРУДНИК к таблице АВТОМОБИЛЬ или в обратном направлении. В первом случае нам известен сотрудник, и мы хотим узнать, какой автомобиль закреплен за этим сотрудником. Чтобы получить данные о сотруднике, мы находим в таблице СОТРУДНИК строку с этой информацией по значению атрибута Номер- Сотрудника. Из найденной строки мы берем НоиерЛицензии автомобиля, закрепленного за данным сотрудником. По номеру лицензии мы находим информацию об автомобиле в таблице АВТОМОБИЛЬ. Рис.
6.6. Пример связи 1:1 сОтРУДник (Но»дар ~отоудникаа, имлсотрулника, телефон, ... ноыерл«пензии) "(Ы > «Е~ "" ' ек ""' '" '-( Ограничения осы»очной целостности; Значение атрибута НоыерЛицензии е отношении СОТРУДНИК должно существовать среди значений атрибута НомерЛ«цензе« е отношении АВТОМОБИЛЬ а СОТРУДНИК 1НомедСатйудндий, ИылСотрудеика, Телефон, ...) ю~~~ю~ (~, е~ .к Номер Со(»рудника) Ограничения ссыпочной целостности: Значение атрибута НоыерСотрудника е отношении АВТОМОБИЛЬ должно существовать среди значений атрибута НоыерСогрудника е отношении СОТРУДНИК Рис. 6.6. Возможные варианты представления связи 1;1: а — помещение ключа отношения АВТОМОБИЛЬ е отношение СОТРУДНИК; б — помещение ключа отношения СОТРУДНИК е отношение АВТОМОБИЛЬ Теперь рассмотрим движение в противоположном направлении.
Допустим, у нас имеется автомобиль, и мы хотим выяснить, за кем он закреплен. Используя структуру, изображенную на рис, 6.6, а, мы обращаемся к таблице СОТРУДНИК и ищем в ней с~року, которая содержит заданный номер лицензии. Данные о сотруднике, эа которым закреплен этот автомобиль, находятся в этой строке. Аналогичные действия предпринимаются для движения в двух направлениях при альтернативной структуре, в которой внешний ключ НомерСотрудника помещается в таблицу АВТОМОБИЛЬ. Двигаясь от сотрудника к автомобилю, мы обращаемся напрямую к отношению АВТОМОБИЛЬ и ищем в нем строку с заданным значением атрибута НомерСогрудника. Двигаясь от автомобиля к сотруднику, мы ищем в отношении АВТОМОБИЛЬ строку с заданным значением атрибута НомерЛицензии.
Из этой строки мы извлекаем НоиерСотрудника и по нему находим данные о сотруднике в таблице СОТРУДНИК. Под термином поиск здесь подразумевается нахождение строки по значению одного из столбцов. Позднее, когда мы будем обсуждать модели конкретных СУБД, мы покажем, как это делается. Хотя две структуры, изображенные на рис. 6.6, эквивалентны по сути, они могут различаться по производительности. Например, если запросы в одном направлении осуществляются чаще, чем в другом, мы можем отдать предпочтение какой-либо одной из этих структур. Кроме того, если СУБД осуществляет поиск (н> первичным ключам гораздо быстрее, чем по внешнцм ключам, одна из этих структур также может оказаться более предпочтительной.
«Подозрительные» связи 1:1 Па рис. 6.7 показана еще одна связь 1:1, в которой каждый сотрудник имеет определенный разряд тарифной сетки и каждый разряд тарифной сетки соответствует какому-либо сотруднику. Перпендикулярныс черточки указывают на то, что связь между сущностями СОТРУДНИК и РАЗРЯД носит в обоих направлениях обязательный характер. Когда связь имеет вид 1:1 и является обязательной в обоих на>>равлениях, то с высокой вероятностью указанные записи отражают различные ;юпекты одной и той же сущности, особенно если обе сущности имеют одинаковый ключ, как показано на рпс. 6.7. В таком случае, вообще говоря, записи следует объединить в одно отношение.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
