Теория и практика построения баз данных (1088289), страница 51
Текст из файла (страница 51)
Существование этого чего-то не должно зависеть от присутствия или отсутствия определенных значений панн ых. Поскольку суррогатные ключи нс могут быть изменены пользователем н поскольку они являются гарантированно уникальными, они представляют идентичность строки (плп сущности). Чтобы прояснить этот момент, рассмотрим две таблицы на рис. 6.30, а, которые используют в качестве ключей данные, а не суррогатные ключи. Между отношениями РУКОВОДИТЕЛЬ и СТУДЕНТ существует связь вида 1:Ы. Эта связь обеспечивается внешним ключом Имяруководителя в отношении СТУДЕНТ.
Теперь предположим, что профессор Сэшнс хочет поменять фамилию на Джонсон. Допустим, что такое изменение разрешено, и допустим также, что наше приложение достаточно умно для того, чтобы распространить это изменение через внешний ключ таким образом, что в столбце ИмяРуководителя таблицы СТУДЕНТ все значения с фамилией Сзшнс заменяются на Джонсон. Данные будут выглядеть, как показано на рис. 6.30, 6. И вот мы наблюдаем путаницу. Мы перегрузили фамилию Джонсон, так что теперь невозможно определить, какими студентами руководит профессор Джонсон с кафедры бухгалтерского учета, а какими — профессор Джонсон с кафедры права.
Хуже того, эта неразбериха является артефактом нашего проекта, а не следствием каких-либо проблем в среде пользователей. (Лирическое отступление: вам может прийти в голову, что проблема заключается в том, что атрибут Имяруководителя не был определен как уникальньш. Такое определение, разумеется, предотвратило бы возникновение хаоса, однако сразу напрашивается вопрос: а кто мы такие, разработчики базы данных, чтобы определять, что руководители не могут иметь одинаковых имен? Если семантика Отношение РУКОВОДИТЕЛЬ Номерруководителя Имя Отдел Отношение РУКОВОДИТЕЛЬ Имя Отдел НомерСтуденте Отношение СТУДЕНТ Специальность ИмяРуководителя Имя Отношение РУКОВОДИТЕЛЬ Номерруководителя Имя Отдел Отношение РУКОВОДИТЕЛЬ Имя Отдел НомерСтудентв Отношение СТУДЕНТ Специвльность Имяруководителя Имя 236 Глава 6.
Проектирование баз данных в рамках модели «сущность — связь» рассматриваемой задачи допускает, что разные руководители могут иметь одно и то же имя, то мы не имеем права конструировать базу данных, которая не допускает дублирования имен. Ограничивать поведение пользователей в угоду базе данных — зто плохой замысел.) Рассмотрим ту же ситуацию с суррогатными ключами. На рис. 6.31, и изображены данные перед изменением имени, а на рис. 6.31, б — после изменения. Ключи не перепутываются, поскольку для представления связи используются суррогатные ключи. б Рис. 6.30.
Пример ситуации с перепутыванием ключей: з — отношения СТУДЕНТ и РУКОВОДИТЕЛЬ без суррогатных ключей, до изменения; б — те же отношения после изменения Есть множество других способов выразить понятие о том, что суррогатные ключи защищают идентификацию. Мир объектно-ориентированного программирования приводит (другими способами) тот же самый аргумент для объектов Деревья, сети и списки материалов 237 ООП.
Все аргументы сводятся к тому, что если идентификатор строки неизме- нен на протяжении всего времени существования строки, идентификация втой строки сможет производиться всегда. Отношение СТУДЕНТ Имя Специальность Номеррукоаодителя Отношение СТУДЕНТ Имя Специальность Номерруководителя Рис. В.зт. Пример ситуации, когда благодаря использованию суррогатных ключей перепутывание ключей невозможно: в — отношения СТУДЕНТ и РУКОВОДИТЕЛЬ до изменения; б — тежо отношения после изменения Это преимущество, однако, имеет свою цену.
В структуре на рис. 6.30, и вы можете посмотреть на строку отношения СТУДЕНТ и сразу сказать, кто является руководителем данного студента. Имея в роли ключей данные, вам не нужно выполнять поиск в таблице РУКОВОДИТЕЛЬ, чтобы найти имя руководителя за данным номером, как зто приходится делать со структурой на рпс. 6.31, б. Кроме того, если база данных обменивается информацией с другими базами, которые используют данные в качестве ключей, применение суррогатных ключей может привести к проблемам.
РезюмЕ 239 Резюме 238 Глава б. Проектирование баз данных в рамках модели «сущность — связь» Так использовать суррогатные ключи или нет? Каков же итог дискуссии? Мнения экспертов расходятся. Никто не оспаривает прагматических причин для их использования, но некоторые считают, что применение суррогатных ключей должно быть ограничено теми случаями, где онн необходимы, подобно примеру с моллюсками.
Другие возражают, что суррогатные ключи должны использоваться везде и что данные вообще не следует использовать в качестве ключей. Сам я использую суррогатные ключи почти всегда. Я не решаюсь вводить суррогатные ключи в таблицах, имеющих в качестве естественного ключа легко индексируемые данные, — например в таблице ПРОДУКТ, содержащей столбец НомерПродукта с уникальными целыми значениями. Иногда я также не ввожу суррогатные ключи в таблицах, которые регулярно используются для обмена данными с другими базами данных.
Эта политика означает, что в некоторых базах данных, разработанных мною, присутствует смесь информационных и суррогатных ключей. Мне зто не нравится, и это может приводить к недоразумениям. До некоторой степени количество недоразумений можно уменьшить, используя четкую схему именования столбцов с суррогатными ключами. Я обычно использую для этих столбцов имена вроде ИмяТаблицы10 или ИмяТаблицы 5К. Обсудите эту тему с вашим преподавателем — у него определенно будут другие идеи и мнения. Данное решение относится к сфере искусства и должно, по моему мнению, приниматься индивидуально для каждой таблицы.
Пустые значения Атрибут имеет пустое значение (ппй ча!пе), если его значение не задано. Проблема с пустыми значениями состоит в том, что они допускают множество толкований. Пустое значение может означать, что: а) значение атрибута неизвестно; б) атрибут неприменим; в) значение атрибута равно нулю. Рассмотрим, например, атрибут Датабиерти в отношении КЛИЕНТ. Что означает пустое значение этого атрибута? Возможно, пользователи не знают, жив клиент или нет; возможно, клиент является корпоративным и данный атрибут к нему неприменим; наконец, возможно, что клиент является физическим лицом и он жив.
Есть несколько способов устранения этой неоднозначности. Первый способ заключается в том, чтобы не допускать ее. Определите атрибут как обязательный. Это работает отлично, если в представлении пользователей атрибут действительно является обязательным. Однако пользователей может раздражать необходимость указывать, например, значение атрибута ЛюбимыйЦветПокупателя, если этот атрибут не представляет важности для их работы. В главе 3 мы узнали способ избежать появления пустых значений там, где атрибут является неприменимым, — введение подтппов.
Введение сущностей ПАЦИЕНТ-МУЖЧИНА н ПАЦИЕНТ-ЖЕНЩИНА в качестве подтипов сущности ПАЦИЕНТ избавит пациента мужского пола от необходимости указывать количество беременностей, а пациентов женского пола — от вопросов о состоянии предстатель- ной железы, например, Однако это решение является дорогим — в том смысле, что оно требует введения двух новых таблиц, и чтобы получить данные обо всех пациентах, понадобится соединять эти таблицы. Еще одно решение заключается в том, чтобы определить каждый атрибут с начальным значением, распознаваемым как пустое. Текстовому атрибуту, например, может быть присвоено начальное значение (не определено), Далее пользователи могут присвоить ему значение (пе подходит) в случае неприменимости данного значения.
Данный подход будет более эффективен, если такие варианты выбора будут появляться в раскрывающихся списках (см, главу 10). Хотя данное решение работает для текстовых атрибутов, проблема с числовыми, логическими и другими нетекстовыми атрибутами остается. Разумеется, выйти из положения можно, моделируя эти атрибуты в виде текста, чтобы можно было ввести значения типа (не определепо) и (пе подходит).
Но в этом случае вам придется писать собственную процедуру редактирования, которая гарантирует, что в таблицу будут вводиться правильные числа или даты. Вам также придется программным путем преобразовывать эти данные к соответствующему типу, прежде чем производить над ними арифметические операции. Иногда лучшее решение — не делать ничего с пустыми значениями. Если пользователи могут смириться с неоднозначностью или если решение требует больше затрат, чем приносит выгоды, просто документируйте факт существования проблемы.
Обратитесь также к главе 9, где вы найдете информацию о последствиях, вызываемых наличием пустых значений при выполнении операций соединения. Для преобразования модели «сущность — связь» каждую сущность в модели нужно представить отношением. Атрибуты сущности при этом станут атрибутами отношения. Созданное отношение следует проанализировать на предмет необходимости нормализации и, если потребуется, разбить на два или более ноных отношения. В модели «сущность — связь» существует три в|«да бинарных связей типа «ИМЕЕТ»: 1:1, 1:1«и Х:М. Чтобы представить связь 1:1, мы помещаем ключ одного отношения в другое отношение, Иногда отношения «один к одному» указывают на то, что два отношения принадлежат одной сущности н их следует объединить в одно отношение.
Чтобы представить связь 1:)Ч, мы помещаем ключ родительского отношения и дочернее отношение. Наконец, чтобы представить связь М 1Ч, мы создаем отношение пересечения, содержащее ключи двух других отношений. Рекурсивные связи — это связи, в которых участвуют сущности одного и того же класса. Есть три типа рекурсивных связен: 1:1, 1:Х н Х:М. Эти типы представляются так же, как и в случае нерекурсивных связей. Для связей 1:1 и 1;Х мы помешаем внешний ключ в отис~пенис, которое представляет сущность.
Для представления рекурсивных связей Н:М мы создаем отношение пересечения. 240 Глава 6. Проектирование баз данных в рамках модели «сущность — связь» Вопросы ! группы, 241 Вопросы ! группы Тернарные связи и связи высших порядков могут быть представлены в ниле комбинаций бинарных связей.
Однако в этом случае все бинарные ограничения, налагаемые на тернарную связь, также должны быть представлены в проекте. Поскольку такие ограничения невозможно реализовать в реляционной структуре, их необходимо документировать как положения делового регламента. Имеется три типа таких ограничений: «ДОЛЖНО БЫТЬ», «НЕ ДОЛЖНО БЫТЬ» и ДОЛЖНО ВКЛЮЧАТЬ». Сущности надтипов и подтипов (связи типа «ЕСТЬ») также представляются в виде отношений.
Вводится одно отношение для сущности надтипа и по одному отношению — для каждой сущности подтипа. Обычно ключи отношений совпадают и связи между строками определяются с помощью этих ключей. Если же ключи не совпадают, можно поместить ключ отношения надтнпа в отношение подтипа, илн наоборот. Чаще всего ключ отношения надтипа помещается в отношение подтипа. Комбинации бинарных связей могут формировать три типа более сложных структур. Дерево — это совокупность типов записей, в которой каждая запись имеет ровно одного родителя, за исключением корня, у которого нет родителя. В простой сети записи могут иметь нескольких родителей, но все родители должны быть различных типов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
