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

0

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

?               Строгость — количество объектов, которые могут существовать на каждом конце отношения.

?               Обязательность — является ли отношение обязательным.

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

Вторичные сущности и внешние ключи

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

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

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

Строгость отношения

Строгость отношения описывает количество элементов с каждой его стороны. Каждая из сторон отношения может допускать как один объект, так и их множество. Тип ключа определяет возможность множества объектов. Первичные ключи допускают наличие только одного объекта, в то время как внешние — их множества.

Существуют различные возможные варианты строгости; все они перечислены в табл. 2.2. В этом разделе мы подробно рассмотрим каждый из этих вариантов.

Таблица 2.2. Строгость отношений

Тип отношения

Ключ первой сущности

Ключ второй сущности

Один к одному

Первичный ключ главной сущности — один

Первичный ключ главной сущности —

объект

один объект

Один ко многим

Первичный ключ главной сущности — один

Внешний ключ вторичной сущности —

объект

множество объектов

Многие ко многим

1 Внешний ключ главной сущности — мно

Внешний ключ вторичной сущности —

жество объектов

множество объектов

Обязательность отношений

Вторым свойством отношений является их обязательность. Различие между обязательным и необязательным отношением критична для поддержания целостности базы данных.

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

?               Строка заказа без самого заказа бессмысленна.

?               Заказ без заказчика не имеет смысла.

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

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

?               Заказчик, не имеющий дисконтной карточки, все равно остается клиентом.

?               Заказ может иметь и не иметь код приоритета — в любом случае он остается заказом.

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

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

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

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

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

?               Если же используется атрибут заказного товара, то атрибут идентификатора товара остается пустым.

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

Диаграмма модели данных

Те, кто занимается моделированием данных для графического отображения создаваемых моделей, используют несколько методов. Популярным является ER-метод Чена, а система Visio Professional содержит еще пять других методов. Метод, который предпочитаю лично я, — самый простой. Он предполагает зарисовку схемы на доске, как показано на рис. 2.2. Строгость отношения отображается одной или тремя линиями (куриная лапа). Если отношение необязательное, то около внешнего ключа помещается окружность.

Рис. 2.2. Простой метод отображения на диаграммах логических схем

Еще одним преимуществом этого простого метода построения диаграмм является то, что он не требует установки расширенной версии программы Visio.

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

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

? Каждый клиент может разместить множество заказов. Каждый заказ имеет свой уникальный первичный ключ OrderlD (идентификатор заказа); сущность Order (заказы) также имеет вторичный ключ Customer ID (идентификатор клиента), указывающий

?               В базе данных турагентства Cape Hatteras Adventures каждый базовый лагерь может иметь несколько туров, которые берут в нем начало. Каждый тур может начинаться только из одного базового лагеря; таким образом, один лагерь связан отношением “один ко многим” с несколькими турами. Отношение устанавливается между первичным ключом сущности Base Camp (базовые лагеря) и внешним ключом сущности Tour (туры) (рис. 2.3). Каждый атрибут внешнего ключа таблицы Tour содержит копию первичного ключа таблицы Base Camp.

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

на клиента, разместившего заказ. Сущность Order может содержать несколько элементов, имеющих один и тот же идентификатор клиента, что указывает на наличие отношения “один ко многим”.

?               Благотворительная организация может получать ежегодные взносы своих спонсоров. Как только спонсор вносит ежегодный платеж, он заносится во вторую сущность, которая может хранить данные о взносах за многие годы. Структура этой сущности может быть следующей: DonorName, 2 001pledge, 2 002pledge, но возможны и другие варианты.

?               Заказ может иметь несколько строк. Первичный ключ сущности Order дублируется во вторичном ключе сущности OrderDetail. Каждый заказ имеет один элемент в сущности Order, но может иметь множество ассоциированных элементов в сущности OrderDetail.

Отношение “один к одному”

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

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

Отношения между подтипом и супертипом

Элемент проектирования, использующий отношение “один к одному”, на самом деле формирует отношение между супертипом и подтипом. Это отношение связывает одну сущность супертипа с несколькими сущностями подтипов, чтобы расширить состав атрибутов элемента. Сущность супертипа имеет необязательное отношение “один к одному” с каждой из сущностей подтипов.

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

По теме:

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