"Проектирование реляционных баз данных." - читать интересную книгу автора (Джен Л. Харрингтон)

КГ ¦ DATETIME Комбинация из даты и времени.
¦ BOOLEAN Логическое значение (истина (true) или ложь (false)).
Во многих современных СУБД поддерживается также тип данных, называемый BLOB (binary large object — двоичный большой объект), с помощью которого можно хранить любые двоичные значения, например графику.
Выбор правильного домена может играть большую роль, в значительной степени Влияя на точность базы данных. Так, почтовый индекс в США состоит из пяти или Девяти цифр. Можно ли атрибуту почтового индекса назначить домен INT? Нельзя по двум причинам. Во-первых, было бы неплохо иметь возможность включать в девятизначные почтовые индексы дефис. Во-вторых, и это более важно, почтовые индексы на северо-востоке начинаются с нуля. Если их хранить как числа, то начальный нуль пропадает. Поэтому для почтовых индексов всегда выбирается домен CHAR. Поскольку над почтовыми индексами никогда не выполняются арифметические операции, Ри использовании символов вместо чисел ничего не теряется. ; Кроме того, для хронологических данных важно выбирать домены DATE 1МЕ. В качестве примера посмотрим, что произойдет, если даты 01/12/2000 Uo/12/1999 хранить как символы. Обратимся к СУБД и попросим определить, экая из дат наступит раньше. СУБД сравнит строки символов в алфавитном порядке ответит, что первой будет дата 01/12/2000, поскольку число 01 в алфавитном Рядке предшествует числу 08. Единственным способом правильно упорядочить Ч|Мвольные даты является использование формата YYY/MM/DD, который редко
16
Часть первая • Теория
применяется где-либо в мире. Если же датам назначить домен DATE, то СУБД упорядочит их правильно. Кроме того, СУБД сможет выполнять над датами арифметические операции, определяя интервал между двумя датами или добавляя к датам постоянные значения (например, 30 дней).
Базовые взаимоотношения данных
После определения основных сущностей в среде базы данных следующая задача — идентифицировать взаимоотношения, установленные между этими сущностями. В процессе работы вы можете встретиться со взаимоотношениями трех типов: "один-к-одному", "один-ко-многим" и "многие-ко-многим".
Прежде всего необходимо учесть один важный аспект: взаимоотношения, содержащиеся в базе данных, устанавливаются между экземплярами сущностей. Так, клиент Lasers Only связан с товарами, которые он заказывает. Каждый экземпляр сущности клиентов связан с экземплярами конкретных заказываемых товаров (см. рис. 2.4).
Анализируя рис. 2.4, не забывайте о том, что это чисто концептуальное представление базы данных, не имеющее никакого отношения к физическому хранению информации:
При документировании взаимоотношений данных, например при построении ER-диаграммы, изображаются типы взаимоотношений сущностей. Указываются возможные взаимоотношения, разрешенные в базе данных. Если взаимоотношение необязательно, то не требуется, чтобы в каждом документируемом взаимоотношении фигурировал каждый экземпляр каждой сущности. Например, в Lasers Only могут храниться данные о клиенте, не имеющем никаких текущих заказов.
Customer #0905 Ja Doe ,^>
5555 1111 2222 3333
Customer «0985 .-¦• 10/10/00 $02.65


Customer #0985
У У 12/15/00'' У"'
$75.90
Customer #0985
05/12/00 ' ' У 8110.00.'
Рис. 2.4. Взаимоотношения между экземплярами сущностей в базе данных

Глава 2 • Сущности и взаимоотношения данных
17
Взаимоотношения "один-к-одному"
Рассмотрим пример. В небольшом городе есть аэропорт. Город и аэропорт описа-ды в базе данных аэропортов небольших городов. Каждый из таких элементов можно представить в качестве экземпляра сущностей разных типов. После этого взаимоотношения между двумя экземплярами можно отобразить в виде "аэропорт находится в одном и только одном городе, а в городе имеется один и только один аэропорт".
Это и есть взаимоотношение типа "один-к-одному" (one-to-one relationship), так как в любом случае один аэропорт не может быть связан с более чем одним городом и любой город не может быть связан с более чем одним аэропортом (города рассматриваемой базы данных слишком малы и не могут иметь несколько аэропортов).
Другим взаимоотношением типа "один-к-одному" является обычный брак. Мужчина может быть неженатым или женатым на одной женщине; женщина может быть незамужней или замужем за одним мужчиной.
Если имеются два экземпляра двух сущностей (А и В), называемые А; и В;, то взаимоотношение "один-к-одному" устанавливается в том случае, когда А; не связан ни с какими экземплярами сущности В или связан с одним экземпляром сущности В, а В; не связан ни с какими экземплярами сущности А или связан с одним экземпляром сущности А. \
В деловой среде взаимоотношения "один-к-одному" довольно редки. В качестве примера предположим, что в Lasers Only принято решение начать работу с новым оптовым поставщиком (или дистрибьютером — distributor) лазерных дисков. Вначале компания заказывает у него диски только одного наименования. В таком случае экземпляр сущности оптовых поставщиков связан лишь с одним экземпляром товаров. Это, казалось бы, и есть взаимоотношение типа "один-к-одному", однако впоследствии Lasers Only может заказать у нового поставщика большее число наименований, что приведет к нарушению правила, по которому поставщик должен быть связан не более чем с одним товаром. Следовательно, это взаимоотношение не является настоящим взаимоотношением типа "один-к-одному" (это пример взаимоотношения один-ко-многим", о котором пойдет речь ниже).
А если Lasers Only создаст специальную сущность кредитных карт для хранения Данных о кредитных картах, используемых теми, кто берет диски напрокат, для защиты своей платы за услугу? Для каждого клиента в магазине .регистрируется только Дна кредитная карта. Поэтому может показаться, что между экземпляром сущности клиентов и экземпляром сущности кредитных карт установлено взаимоотношение типа Дин-к-одному". Однако в данном случае реально рассматривается одна сущность. МеР кредитной карты, ее тип и дата истечения срока действия могут стать атрибута-сУЩности клиентов. При условии, что для каждого клиента хранится только одна Дитная карта, атрибуты не являются многозначными, и никакой отдельной сущно-^и не требуется.
Ьсли вы думаете, что имеете дело со взаимоотношением типа "один-к-одному", «еситесь к нему со всем вниманием. Убедитесь в том, что в действительности оно является взаимоотношением типа "один-ко-многим" или что это не две сущности, ^°Рьхе на самом деле должны быть одной.
18 Часть первая • Теория
Взаимоотношения "один-ко-многим"
Самый распространенный тип взаимоотношений — "один-ко-многим' (one-to-many relationship). На практике большинство реляционных баз данных состоит только из взаимоотношений типа "один-ко-многим". Так, в Lasers Only у каждого оптовика заказывается, как правило, несколько дисков, а конкретный диск поставляется только одним оптовиком. Аналогично, клиент делает множество заказов, но конкретный заказ делается только одним клиентом.
Если имеются два экземпляра двух сущностей (А и В), то взаимоотношение "один-ко-многим" устанавливается между двумя экземплярами (А; и В;) в том случае, когда А; связан с нулем, одним или большим числом экземпляров сущности В, а В; связан с нулем или одним экземпляром сущности А.
Другим примером взаимоотношений "один-ко-многим" являются взаимоотношения между ребенком и его родной матерью. У женщины может быть нуль, одна или более родных дочерей, но у дочери только одна родная мать. В качестве еще одного примера рассмотрим компьютер и его процессор (ЦП). ЦП может быть не установлен ни в каком компьютере или может быть установлен максимум в одном. В компьютере же может не быть ЦП вовсе, может быть один ЦП или более одного ЦП.
Пример с Lasers Only и оптовым поставщиком, у которого компания заказывает диски только одного наименования,— это, в действительности, пример взаимоотношения типа "один-ко-многим", где "многие" в тот момент являются "одним". Помните, что при определении взаимоотношений данных указываются возможные взаимоотношения; при этом совсем не обязательно, чтобы в каждом документируемом взаимоотношении фигурировали все экземпляры всех сущностей. Вовсе не требуется, чтобы оптовик был связан с каким-либо товаром, с одним или несколькими (наличие в базе данных поставщика, у которого компания не заказала ни одного диска, возможно, и неоправданно, однако способов предотвратить хранение данных о таком поставщике нет).
Взаимоотношения "многие-ко-многим"
Взаимоотношения "многие-ко-многим" (many-to-many relationship) также Д» вольно распространены. Это, например, взаимоотношение между заказом, сделанным клиентом Lasers Only, и товарами, поставляемыми магазином. Заказ может состоять из нескольких пунктов; каждый пункт (товар) может фигурировать в более чем одно» заказе. То же самое справедливо и по отношению к заказам на поставку товаров-заказ может состоять из нескольких пунктов, и каждый пункт может фигурировав1 в нескольких заказах.
Взаимоотношение "многие-ко-многим" устанавливается между сущностями А и в том случае, когда для двух экземпляров этих сущностей (А; и В;) А; можно связат с нулем, одним или большим числом экземпляров сущности В, а В; можно связа с нулем, одним или большим числом экземпляров сущности А.


Глава 2 • Сущности и взаимоотношения данных 19
Наличие взаимоотношений "многие-ко-многим" приводит к возникновению двух серьезных проблем при проектировании базы данных. Эти вопросы и способы их оешения описываются ниже (см. раздел "Использование взаимоотношений многие-ко-многим ).
Слабые сущности и обязательные взаимоотношения
При обсуждении различных типов взаимоотношений данных описание взаимоотношений начиналось с "нуля". Это означает, что наличие во взаимоотношении какого-либо экземпляра сущности необязательно. Так, в базе данных Lasers Only можно сохранить сведения о клиенте до того, как он сделает заказ. Таким образом, не требуется, чтобы экземпляр сущности клиентов был связан с определенным Экземпляром сущности заказов.
Однако обратное в этой базе данных несправедливо: заказ должен быть связан С клиентом. Без клиента заказ существовать не может. Таким образом, заказ является примером слабой (weak) сущности — сущности, которая не может присутствовать в базе данных, если нет связанного с ней экземпляра другой сущности. Экземпляр сущности клиентов можно связать с нулем, одним или несколькими заказами. Однако экземпляр сущности заказов должен быть связан с одним и только одним клиентом. По отношению к слабой сущности вариант "нуль" неприменим. Следовательно, взаимоотношение между экземпляром сущности заказов и клиентом — это обязательное взаимоотношение.