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

В главе 9 рассматривается роль инструментальных программных средств, обеспечивающих выполнение различных операций в процессе проектирования базы данных. В главах с 10 по 12 содержатся аналитические примеры проектирования баз данных, представляющие разнообразные вопросы и трудности, с которыми вы можете встретиться.
Сущности
и взаимоотношения
данных
В этой главе анализируется фундаментальная концепция, лежащая в основе всех баз данных: в деловой среде существуют предметы, информацию о которых необходимо хранить, и эти предметы связаны друг с другом самыми разными способами. Вообще говоря, для того чтобы область хранения информации рассматривалась в качестве базы данных, в ней должны содержаться не только данные, но и сведения о взаимоотношениях между этими данными.
Смысл понятия базы данных таков, что пользователь — либо человек, взаимодействующий с ней, либо прикладная программа — не должен заботиться о том, каким именно образом данные физически хранятся на диске. Пользователь выражает запросы манипулирования данными на языке взаимоотношения данных. Программные средства, называемые системой управления базами данных (СУБД — DBMS, database management system), организуют связь между запросом пользователя и физической областью хранения информации.
Формальным способом отображения взаимоотношений данных на СУБД является модель данных. Реляционная модель данных, о которой пойдет речь в этой книге,— как раз такая формальная структура. Однако взаимоотношения, лежащие в основе среды базы данных, независимы от модели данных и поэтому независимы от применяемой СУБД. Перед началом проектирования базы данных для любой модели необходимо определить взаимоотношения, существующие между данными.
В большинстве СУБД поддерживается только одна модель данных. Поэтому, выбирая СУБД, вы выбираете еще и модель данных.
В этой главе рассматриваются взаимоотношения данных и характеристики этих взаимоотношений. Кроме того, описывается независимый от СУБД метод документирования взаимоотношений, называемый диаграммой взаимоотношения сущностей, или ER-диаграммой (entity-relationship diagram).
Глава 2 • Сущности и взаимоотношения данных
9
Customer »0985
Ш Hat* ¦".•^•° ¦'""Doe ^
Customer «0081
? дГ "'«('ее,
11111,
Sam Si
|f'S55B 111122223333
J).
"**» * Thi6 Town
,jf 1111 ^^
(555)555-3333 06/02
ST
**й
Рис 2.1.
Экземпляры сущности клиентов в базе данных
Сущности и их атрибуты
Сущность (entity) — это нечто, о чем хранится информация. Клиент — это сущность, как и товар, хранящийся на складе Lasers Only. Вовсе не обязательно, 'чтобы сущности были материальны. Так, некоторое событие, например концерт, является сущностью; обращение к врачу — тоже сущность.
Сущности описываются данными, называемыми атрибутами (attributes). Например, клиент как сущность обычно описывается номером, именем, фамилией, улицей, городом, штатом (страной), почтовым индексом и номером телефона. Сущность концертов можно описать названием, датой, местом проведения и именем исполнителя. N,
При представлении сущностей в базе данных фактически сохраняются только атрибуты. Каждая группа атрибутов, описывающих одно реальное проявление сущности, представляет собой экземпляр (instance) сущности. Например, на рис. 2.1 Можно видеть четыре хранящихся в базе данных экземпляра сущности клиентов. Если в базе 1000 клиентов, то будут присутствовать 1000 наборов атрибутов клиентов.
Здесь не говорится о физическом хранении экземпляров. То, что изображено на рис. 2.1,— чисто концептуальное представление.
Идентификаторы сущностей
Единственной целью размещения в базе данных информации, описывающей Сущность, является последующее считывание этой информации. Следовательно, необходимо иметь определенный метод, позволяющий отличать одну сущность от другой
I
\
10
Часть первая • Теория
и тем самым обеспечивающий считывание нужной сущности. Для этого каждой сущности присваиваются определенные значения атрибутов, отличающие ее от любой другой сущности базы данных; совокупность значений называется идентификаторол! сущности (entity identifier).
Предположим, что в Lasers Only имеются два клиента с именем Джон Смит. Если служащий ищет пункты заказа Джона Смита, сведения о каком из Джонов Смитов выберет СУБД? В данном случае — об обоих. Поскольку не существует способа различения двух клиентов, результаты запроса будут неточны.
В Lasers Only рассматриваемая проблема решена созданием уникальных номеров клиентов. Это весьма распространенный способ идентификации экземпляров сущностей, когда в собственно данных не предусмотрен какой-либо простой уникальный идентификатор.
Другим решением может стать объединение имени и фамилии клиента с его телефонным номером. Подобная комбинация столбцов (составной идентификатор) также однозначно определяет каждого клиента. Однако здесь имеются два недостатка. Во-первых, такой идентификатор длинен и громоздок, и при вводе любого из его компонентов велика вероятность ошибки. Во-вторых, при изменении номера телефона клиента идентификатор тоже должен измениться. Как отмечено в главе 1, изменение идентификатора сущности может привести к возникновению серьезных проблем в базе данных.
У некоторых сущностей, например у счетов-фактур, имеются естественные идентификаторы (номера счетов-фактур). Другим сущностям — главным образом людям, населенным пунктам и предметам — присваиваются уникальные номера без определенного смысла. Для третьих необходимы составные идентификаторы.
О том, что такое хороший уникальный идентификатор, более детально рассказывается в главе 3 при рассмотрении первичных ключей.
При сохранении экземпляра сущности в базе данных нужно, чтобы СУБД обеспечивала наличие у нового экземпляра уникального идентификатора. Это является примером ограничения (constraint) в базе данных — правила, которому должны соответствовать данные. Реализация различных ограничений помогает поддерживать согласованность и точность информации.
Однозначные и многозначные атрибуты
В данном случае конечным итогом процесса проектирования является создание реляционной базы данных, поэтому атрибуты нашей модели данных должны быть однозначными. Другими словами, у каждого атрибута конкретного экземпляр3 сущности может быть только одно значение. Например, сущность клиентов допускает наличие только одного телефонного номера для каждого клиента. Если у клиента
i
Глава 2 • Сущности и взаимоотношения данных . ' 11
несколько телефонных номеров, которые нужно включить в базу данных, то сущность клиентов не сможет вместить их все.
^/m^/mhrfiS. Хотя верно то, что модель взаимоотношения сущностей базы данных не зависит от формальной модели данных, используемой для отображения структуры данных в СУБД, часто решения о моделировании данных принимаются исходя из требований той формальной модели, которая будет применяться впоследствии. Одно из подобных решений — удаление многозначных атрибутов. Аналогичный пример будет приведен при рассмотрении взаимоотношений "многие-ко-многим" между сущностями.