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

Наличие нескольких телефонных номеров превращает атрибут телефонного номера в многозначный. Поскольку в реляционной базе данных сущность не может иметь многозначные атрибуты, необходимо упорядочить их, создав сущность для их хранения.
В данной ситуации можно создать сущность телефонных номеров. В каждый экземпляр этой сущности нужно включить номер клиента, которому принадлежит телефонный номер, и сам телефонный номер. Если у клиента три телефонных номера, то для него будут существовать три экземпляра сущности телефонных номеров. Идентификатор такой сущности нужно составлять из номера клиента и из телефонного номера. "~-\
Избежать использования телефонного, номера в качестве элемента идентификатора сущности телефонных номеров невозможно. Далее вы увидите, что в данном конкретном случае никакого вреда от подобного использования телефонного номера нет.
Как правило, при встрече с многозначным атрибутом рекомендуется создать еще один атрибут. Единственным способом работы с несколькими значениями одного атрибута является создание сущности, несколько экземпляров которой можно хранить в базе данных, по одному для каждого значения атрибута.
О совокупности сущностей
Ь> начале работы с сущностями может показаться, что природа сущности довольно
гуманна. Рассмотрим, к примеру, запас товаров компании Lasers Only. Является ли
апас товаров сущностью? Нет. Этот запас состоит из отдельных товаров, с которы-
ч работает магазин. Настоящей сущностью является отдельный товар. Товарный
^ас определяется просмотром всех экземпляров сущности отдельных товаров как
еДиного целого.
12
Часть первая • Теория
Чтобы прояснить ситуацию, рассмотрим атрибуты, которые необходимы в случае создания сущности запаса товаров: число товаров, название товара, количество на складе, розничная цена и т. д. Так как весь запас товаров мы пытаемся описать с помощью одной сущности, для каждого из этих атрибутов требуется по несколько значений. Однако, как было показано выше, атрибуты не могут быть многозначными, т. е. запас товаров сущностью быть не может. Его необходимо представлять в виде совокупности экземпляров сущности отдельных товаров.
В качестве другого примера рассмотрим медицинскую историю болезни человека, заполняемую врачом. Подобно запасу товаров, история болезни представляет собой совокупность нескольких сущностей. Она состоит из обращений к врачу и из событий, происходящих во время этих обращений. Следовательно, реально история является совокупностью экземпляров сущностей обращений и сущностей курсов лечения. "История" — это выходная информация, которую приложение базы данных может получить, выбрав данные, хранящиеся в экземплярах базовых сущностей.
Документирование сущностей и атрибутов
Диаграммы взаимоотношений сущностей позволяют документировать сущности в базе данных, а также атрибуты, описывающие эти сущности. Есть несколько типов ER-диаграмм. Наиболее часто используются диаграммы Чена (Chen) (по имени изобретателя ER-моделирования) и диаграммы информационного проектирования (Information Engineering). Разрешается применять диаграммы любого типа, главное, чтобы тот, кто использует диаграмму, понимал ее символику.
В обеих моделях для представления сущностей применяются пря-
CUStomer моугольники. Имя каждой сущности заключается в прямоугольник ----------------' и ставится в единственном числе, как показано на рисунке слева.
В исходной модели Чена __________ ___________
не предусмотрена возможность I *id_numb
отображения атрибутов непосредственно на ER-диаграмме. Однако многие расширяют эту модель, внося атрибуты и заключая их в овалы (рис. справа).
last name
customer
first name
telephone!
customer
*id_numb first_name last_name telephone
Идентификатор сущности — это атрибут, предваряемый звездочкой (*id__numb).
В модели информационного проектирования атрибуты указываются в прямоугольнике вместе с сущностью (см. рис. слева).
Модель информационного проектирования позволяет строить более компактные диаграммы. Для большинства диаграмм нашей книги используется именно эта модель, хотя в данной главе рассматриваются элементы обеих моделей.
;Глава 2 • Сущности и взаимоотношения данных
13
Cus tomer
*cus tomer_numb
cus tomer_f i rs t_name
cus tomer_I as t_name
cus tomer_s tree t
customer_ci ty
customer-state
customer_zip
cus tomer_phone
cred i t_j:ard_numb
card_exp_jda te
Order
*order_numb customer_numb
orderjdate order_fiI led
0 i s tr i bu tor wd i s tr i bu tor_numb d i s tr i bu tor_name d i s tr i bu tor_s tree t distributor_jei ty distributor_state
distributor.zip
d i s tr i bu tor-phone