Главная » Microsoft SQL Server, Базы данных » Реляционные шаблоны – ЧАСТЬ 2

0

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

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

Если партнер является клиентом, то его дополнительная информация заносится в сущность Customer; если он поставщик— в сущность Supplier. При этом все три сущности (Contact, Customer и Supplier) имеют один и тот же первичный ключ. Один элемент в сущности Contact не обязательно может быть связан с одним элементом в сущности Customer и(или) с одним элементом в сущности Supplier (рис. 2.4).

Рис. 2.4. Отношение “один к одному ” связывает первичный ключ с другим первичным ключом

Большинство моделей “супертип-подтип” допускает наличие только одного элемента подтипа для каждого элемента супертипа. В то же время в приведенном примере информации

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

Дополнительная Модель “супертип-подтип” очень сходна с концепцией наследования классов в информация объектно-ориентированном анализе. Таким образом, если база данных содержит несколько моделей “супертип-подтип”, то база данных может считаться кандидатом на объектно-реляционный стиль вместо реляционного. Объектно-реляционные СУБД для SQL Server можно загрузить с сайта www. SQLServerBible. com.

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

Отношение “многие ко многим”

В отношениях типа “многие ко многим” обе стороны могут быть связаны с множеством элементов противоположной стороны. Отношение “многие ко многим” часто встречается в реальной жизни. Приведу несколько примеров.

?               Заказ может содержать несколько товаров, а каждый товар может находиться во множестве заказов.

?               В базе данных турфирмы Cape Hatteras Adventures экскурсовод может быть квалифицирован для ведения нескольких туров, а каждый тур может иметь несколько квалифицированных экскурсоводов.

?               В базе данных турфирмы клиент может принимать участие в нескольких турах, а каждый тур может иметь множество участников.

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

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

Для разрешения отношения “многие ко многим” используется ассоциированная таблица (рис. 2.6), иногда называемая стыковочной. Эта таблица искусственно создает два отношения “один ко многим” между двумя сущностями.

Puc. 2.5. Логическая модель uмногие ко многим ” содержит множество элементов с каждой из сторон отношения

Рис. 2.6. Физическая модель отношения “многие ко многим” включает стыковочную таблицу, имеющую отношения “один ко многим ” к обеим сущностям

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

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

Сущности категорий

Еще одним типом поддерживающей сущности является сущность категорий, иногда называемая таблицей классификаторов. Эти сущности обеспечивают целостность домена в смысле способа организации элементов. Отличным примером может служить таблица штатов США. Вместо того чтобы в таблице клиентов атрибут региона мог принимать некорректные значения (например, F1 или FLA для штата Флорида), эта таблица связана с таблицей штатов, в которой все эти названия заведомо корректны. Такая целостность данных ускоряет и облегчает поиск и сортировку данных.

Видимые сущности обычно связаны с сущностями категорий отношением “один ко многим”; такое отношение может быть как обязательным, так и нет.

Возвратные отношения

В некоторых случаях отношение устанавливается между двумя элементами одного и того же типа. Приведем несколько примеров.

?               Организационная диаграмма представляет сотрудника, отчитывающегося перед другим сотрудником.

?               Список материалов детализирует, как один материал получается из других материалов.

?               В базе данных семей некоторое лицо имеет отношение к своей матери и отцу.

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

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

Так как первичным ключом является PersonID (идентификатор человека), a MotherlD — внешним, устанавливается отношение “один ко многим” (рис. 2.7). Одна мать может иметь несколько детей, однако каждый ребенок имеет одну и только одну мать.

Puc. 2.9. Физическая схема базы данных возвратного отношения “многие ко многим” должна содержать связывающую сущность, как и в обычных отношениях

Нормализация

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

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

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

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии