Сущности, атрибуты и ключи

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

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

Как и в случае с сущностями, важно различать атрибуты и экземпляры атрибутов. Атрибутом автомобиля является Registration Number ( Регистрационный номер ), а экземпляром этого атрибута - 180 EOD. Сомнительно, чтобы этот атрибут можно было использовать в качестве первичного ключа: регистрационные номера автомобилей часто меняются, и, кроме того, номер может быть уникален только в стране регистрации. Chassis Serial Number ( Заводской номер щасси ) - более удачный вариант, но если несколько мащин разобрать, смешать их части и собрать автомобили заново, то что будет определять данный автомобиль? Данный пример иллюстрирует тот факт, что задача поиска возможных ключей не всегда так проста, как кажется на первый взгляд.

Отношения

Мы увидели, что в информационной модели сущности могут описываться через Первичный ключ и другие неключевые атрибуты. Но у нас нет еще полной картины, потому что сущности рассматриваются отдельно друг от друга. Однако между ними существуют реальные отношения. Например, вы связаны со своим автомобилем как его владелец. Вы и, возможно, ваши супруга и дети, связаны с этим автомобилем как его водители. Если вы взяли ссуду для покупки автомобиля, то ваш банк может быть связан с ним как его финансист. И так далее...

Опять-таки следует различать отношение и конкретные его проявления. Если мы определим отношение между сущностями Cars ( Автомобили ) и People ( Люди ) и назовем его Is Owner Of ( Является владельцем... ), то одно из проявлений этого отношения будет связывать Batman с Batmobile (если Batmobile можно классифицировать как автомобиль, а Batman - как лицо).

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

Однако таким образом можно реализовать только отношения типа один к одному (1:1) и один ко многим (1:п). (Что это такое, мы объясним ниже.) Если же нужно реализовать отношение многие ко многим , необходимо добавить так называемую промежуточную сущность (о ней мы тоже расскажем позже). Главное здесь заключается в том, что если сторона один отношения имеет несколько возможных уникальных идентификаторов (первичных ключей-кандидатов), то для поддержки данного отношения можно использовать любой из них. Выбор ключа - это первый пример проектного решения, которое должно быть принято при переходе от информационной модели к модели данных, причем это решение может оказать существенное влияние на производительность.

Отношения могут связывать сущность саму с собой. Такие отношения называют рефлексивными. Типичный пример - отношение для сущности Employees, используемое для определения структуры подчиненности в организации. Рефлексивные отношения часто отражают иерархические отношения внутри структуры данных. Из-за способа изображения в моделях сущность-отношение рефлексивные отношения часто называют свиными ушами.

Подтипы и супертипы

Иногда атрибут имеет особое значение для сущности: он разделяет ее на типы, и сущность делится по этим категориям. Полученные в результате сущности называют подтипами, а исходная сущность становится супертипом. Сущность Саг ( Автомобиль ) можно разбить на категории Two Wlieel Drive ( С приводом на два колеса ) и Four Wheel Drive ( С приводом на четыре колеса ). Сама сущность Саг может быть подтипом более широкой группы, называемой Motor Vehicles ( Автотранспорт ). Важно, чтобы все экземпляры сущности-супертипа относились только к одному из подтипов. Некоторые автомобили можно переключать с двухколесного привода на четырехколесный, поэтому, вероятно, нужно ввести новый подтип - Selectable Drive ( Переключаемый привод ). Чтобы проверить, нужен ли супертип, следует установить, как много одинаковых свойств имеют различные подтипы. Чем меньше они похожи друг на друга (продолжая при этом пользоваться одним первшгным ключом), тем явственнее необходимость наличия супеутипа.

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

Диаграммы сущность-отношение

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

Идея ЕК-диаграммы - это попытка концептуализации требований. Задача проектировщика - превратить концепцию в реальность. Во многих случаях информационная модель слишком сложна и содержит очень много объектов, поэтому создается несколько диаграмм, разбитых на категории по предмету. Например, могут существовать отдельные ER-диаграммы Производство , Составление счетов , Заказы и т.д. Если вы пользуетесь CASE-продуктом, который в состоянии построить всеохватывающую картину, сделайте это и повесьте полученный рисунок на стенку. Конечно, такая диаграмма, вероятно, будет напоминать карту автодорог Европы или топологию большой интегральной схемы, но она:

1. Служит ценным источником информации для определения последствий от принятия решения, влияющего на всю систему в целом.

2. Является полезным напоминанием о том, что каждый разрабатываемый участок - это не изолированная система, а подсистема сложного комплекса.

Изображение сущностей и атрибутов

Существует несколько способов представления ER-диаграммы, и в каждом из них объекты показываются по-разному. Мы будем пользоваться условными обозначениями, принятыми в Методике разработки информационных систем (IBM). Они несколько отличаются от используемых в CASE-средствах Oracle. По нашему методу, сущность изображается в виде прямоугольника с именем в верхней части (рис. 3.2).

АВТОМОБИЛ bfc

с 3.2. Сущность