Атрибут

Атрибут – это поименованная характеристика сущности (свойство типа сущности), значимая с точки зрения пользователя.

Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: АВТОМОБИЛЬ, ТЕКСТ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д.

У атрибута также существует различие между типом и экземпляром, при этом каждому экземпляру сущности присваивается только одно значение атрибута.

Например:

Тип атрибута ЦВЕТ имеет много экземпляров или значений:

Красный, Синий и т.д.

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

Примеры: НомерСтудбилета, ФамилияПреподавателя, НазваниеУчебника, Заказчик и т.п.

Атрибут может быть простым, как первые три. Их значения принадлежат простым типам данных.

Он может быть составным, например {ИмяЗаказчика, АдресЗаказчика, ТелефонЗаказчика}

Заметим, что решение о том, является ли атрибут простым или составным, зависит от степени детализации сведений, приемлемой для пользователя. Например, НомерАудитории можно считать простым атрибутом, если пользователя вполне устраивают строковые значения вида ‘ 227рк’, ‘418фэт’, ‘411гл’.

Атрибут может быть производным. Например, в состав атрибутов сущности ГРУППА может входить атрибут ЧисленностьГруппы. Его значение для каждого экземпляра ГРУППы может быть вычислено подсчётом числа экземпляров сущности СТУДЕНТ, связанных с этим экземпляром.

Замечание. Значения производных атрибутов сохраняются в БД в исключительных случаях. Однако на этапе проектирования все такие атрибуты, представляющие интерес для пользователя, должны быть выявлены и описаны.

Ключ

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

Для сущности Расписание поездов ключом является атрибут Номер_поезда или набор: {Пункт_отправления, Время_отправления и Пункт_назначения}.

Выделяют уникальные ключи (потенциальные ключи) и неуникальные. Значение уникального ключа не может встретиться у двух экземпляров сущности. Оно указывает на один и только один экземпляр (НомерСтудбилета, НомерАудитории). Значение неуникального ключа указывает на множество экземпляров (ФамилияПреподавателя = Иванов указывает на всех Ивановых, преподающих в ВУЗе).

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

Сущность может иметь несколько уникальных и неуникальных ключей.

Атрибут нельзя назначить уникальным ключом сущности. Он либо является таковым, либо не является.

Связь

Связь – это характеристика отношений между двумя или более сущностями.

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

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

Как и для сущностей и атрибутов, в ER-модели различаются типы (классы) и экземпляры связей.

Описание сущностей и их связей – это и есть (с точки зрения проектировщика БД) основная часть модели требований пользователя к данным.

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