Атрибуты сущности в ER-модели: пять типов и примеры

Атрибут сущности в ER-модели - это именованное свойство объекта предметной области, значение которого хранится в базе данных: у сущности «Сотрудник» это, например, имя, адрес или номер телефона. От того, как именно классифицирован атрибут - простой он, составной, ключевой, многозначный или производный, - напрямую зависит, во сколько столбцов и таблиц он превратится при переходе от ER-диаграммы к реляционной схеме. Ниже разберём все пять типов по очереди, на примерах и с формулами перехода к столбцам. Чтобы сразу увидеть, как атрибуты растекаются по таблицам, покрутите калькулятор ниже: он показывает Sankey-диаграмму маршрутизации атрибутов и сравнение числа строк в главной и дочерней таблице.

Что такое атрибут в ER-модели

В терминах ER-модели (Entity-Relationship, «сущность-связь») сущность - это класс объектов предметной области («Сотрудник», «Студент», «Заказ»), а атрибут - характеристика этой сущности, значение которой берётся из некоторого домена (множества допустимых значений). У атрибута «Возраст» домен - целые неотрицательные числа, у атрибута «Пол» - конечный набор значений. На диаграмме атрибут традиционно рисуют овалом, соединённым линией с прямоугольником сущности; текст внутри овала - имя атрибута.

Не любое свойство объекта стоит выносить в атрибут: если свойство многократно используется в бизнес-логике, слабо связано с сущностью или само содержит вложенные сущности со своими атрибутами и связями, вероятно, речь о самостоятельной сущности или связи, а не об атрибуте. Но если свойство - это одно значение (или чётко определённый набор значений), принадлежащее ровно одному экземпляру сущности, перед вами атрибут, и дальше вопрос только в том, к какому из пяти типов он относится.

Пять типов атрибутов: обозначения на диаграмме

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

• Простой (атомарный) атрибут - значение неделимо на бизнес-уровне: номер группы, должность. Обычный овал.
• Составной атрибут - распадается на несколько компонентов, каждый из которых сам является атрибутом: «Адрес» = город + улица + дом. На диаграмме от составного овала отходят дочерние овалы простых частей.
• Ключевой атрибут - однозначно идентифицирует экземпляр сущности: табельный номер, номер зачётки. Имя атрибута подчёркивают.
• Многозначный атрибут - у одного экземпляра сущности может быть несколько значений одновременно: «Телефоны», «Языки владения». Изображается двойным овалом.
• Производный атрибут - не хранится, а вычисляется по другим атрибутам: «Возраст» выводится из «Даты рождения». Изображается пунктирным овалом.

Рассчитать для своей задачи

Эти пять обозначений - не формальность: тип атрибута прямо определяет, как СУБД физически хранит его значения, и об этом дальше.

Составной атрибут и его части

Составной атрибут удобен для человека - «Адрес» читается как единое целое, - но при проектировании базы данных он либо раскладывается на части ещё на этапе ER-модели, либо хранится текстом одной строкой (что почти всегда неудобно для поиска и сортировки). Каноничный пример - «Адрес», распадающийся на «Город», «Улицу» и «Дом»; при необходимости добавляют «Индекс» и «Квартиру».

Ключевое практическое правило: при переходе к реляционной таблице составной атрибут с $c$ частями превращается ровно в $c$ отдельных столбцов главной таблицы - сам «зонтичный» атрибут (например, «Адрес» целиком) отдельного столбца не получает, он существует только на уровне ER-диаграммы как группировка родственных простых атрибутов.

Рассчитать для своей задачи

Многозначный атрибут и отдельная таблица

Многозначный атрибут - самый частый источник ошибок в учебных задачах, потому что интуитивно хочется завести несколько столбцов вроде «Телефон1», «Телефон2», «Телефон3». Так делать нельзя: заранее неизвестно, сколько значений будет у конкретного экземпляра, а фиксированное число столбцов либо режет данные (если телефонов больше), либо оставляет пустые столбцы (если меньше) - оба варианта нарушают первую нормальную форму.

Правильное решение - вынести многозначный атрибут в отдельную таблицу с внешним ключом на исходную сущность: таблица «Телефоны» получает столбцы «id_сотрудника» (внешний ключ) и «телефон», а строк в ней столько, сколько всего телефонов у всех сотрудников. Если у сущности $N$ экземпляров, а в среднем $k$ значений многозначного атрибута на экземпляр, то число строк дочерней таблицы равно $N \cdot k$ - растёт не число столбцов, а число строк.

Рассчитать для своей задачи

Производный атрибут: не храним, а вычисляем

Производный атрибут связан зависимостью с одним или несколькими другими атрибутами той же (или связанной) сущности и в норме вообще не хранится физически - его значение получают вычислением в момент запроса. Классический пример - «Возраст», который выводится из «Даты рождения»:

$\text{Возраст} = \left\lfloor \frac{\text{Текущая дата} - \text{Дата рождения}}{365{,}25} \right\rfloor.$

Если хранить «Возраст» как обычный простой атрибут, значение придётся ежедневно (а формально - ежесекундно) пересчитывать и обновлять во всех строках, иначе база данных начнёт врать уже назавтра после последнего обновления. Производный атрибут решает эту проблему тем, что вообще не занимает места в таблице: на диаграмме он всё ещё присутствует (пунктирным овалом, для полноты модели предметной области), но при генерации схемы ему не сопоставляют столбец - вместо этого пишут вычисляемое выражение или представление (view).

Как атрибуты сущности превращаются в таблицы и колонки БД

Собирая всё вместе, переход от набора атрибутов сущности к реляционной схеме подчиняется простым правилам:

• Ключевой атрибут → один столбец главной таблицы, обычно первичный ключ.
• Каждый простой (не ключевой) атрибут → один столбец главной таблицы.
• Составной атрибут из $c$ частей → $c$ столбцов главной таблицы (сам составной атрибут - не столбец).
• Каждый многозначный атрибут → отдельная таблица с внешним ключом и столбцом значения; строк в ней $N \cdot k$.
• Производный атрибут → ни одного столбца; вычисляется запросом или представлением.

Если у сущности $S$ простых атрибутов (без ключа) и составной атрибут с $c$ частями, число столбцов главной таблицы:

$\text{столбцов}_{\text{главная}} = 1 + S + c.$

Пример: сущность «Сотрудник» с полным набором атрибутов

Возьмём сущность «Сотрудник» с ключевым атрибутом «Табельный номер», двумя простыми атрибутами «Имя» и «Фамилия» ($S = 2$), составным атрибутом «Адрес» из трёх частей - «Город», «Улица», «Дом» ($c = 3$), многозначным атрибутом «Телефоны» (в среднем $k = 3$ телефона на сотрудника) и производным атрибутом «Возраст» (из «Даты рождения»). При $N = 100$ сотрудниках получаем:

$\text{столбцов}_{\text{главная}} = 1 + 2 + 3 = 6,$

$\text{строк}_{\text{Телефоны}} = N \cdot k = 100 \cdot 3 = 300.$

То есть таблица «Сотрудники» получит 6 столбцов (табельный номер, имя, фамилия, город, улица, дом), а связанная таблица «Телефоны» - 2 столбца (id_сотрудника, телефон) и 300 строк. «Возраст» нигде не хранится - его выводит запрос из «Даты рождения» при каждом обращении. Именно эту схему и считает калькулятор выше: подвиньте ползунки $S$, $c$, $k$ и $N$, чтобы увидеть, как меняются число столбцов и число строк для вашей сущности.

Частые ошибки

• Хранить многозначный атрибут как несколько пронумерованных столбцов («Телефон1», «Телефон2»). Правильно - отдельная таблица с внешним ключом, число строк которой $N \cdot k$.
• Считать составной атрибут отдельным столбцом. У составного атрибута нет своего столбца - столбцами становятся только его части, число которых равно $c$.
• Хранить производный атрибут как обычный простой. Это дублирует данные и рассинхронизируется при изменении первичного атрибута («Дата рождения» изменилась - «Возраст» остался старым).
• Забывать подчеркнуть ключевой атрибут на диаграмме или указывать в качестве ключа составной либо многозначный атрибут - ключ должен однозначно идентифицировать экземпляр и не должен сам требовать разложения.
• Путать домен атрибута с его типом на диаграмме. Домен (множество допустимых значений, например, целые числа от 18 до 100) - это ограничение на значения простого атрибута, а не отдельный тип атрибута.

FAQ

Сколько типов атрибутов существует в ER-модели? Пять: простой (атомарный), составной, ключевой, многозначный и производный. Иногда ключевой атрибут выделяют не как отдельный тип, а как свойство простого или составного атрибута - но для учебных задач удобнее считать все пять типов равноправными категориями.

Может ли атрибут быть одновременно составным и многозначным? Да: например, «Образование» может включать несколько записей, каждая из которых сама составная (учебное заведение, год, специальность). Такой атрибут при переходе к реляционной схеме превращается в отдельную таблицу, где каждая часть составной структуры - свой столбец, а строк столько, сколько записей у конкретного экземпляра сущности.

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

Коротко

Атрибут сущности в ER-модели бывает пяти типов: простой, составной, ключевой, многозначный и производный, и каждый по-своему превращается в реляционную схему. Ключевой и простые атрибуты дают по одному столбцу главной таблицы, составной с $c$ частями - $c$ столбцов, многозначный с $k$ значениями на $N$ экземпляров сущности уходит в отдельную таблицу из $N \cdot k$ строк, а производный атрибут вообще не хранится и вычисляется запросом. Держа в голове эти пять правил перехода, легко и классифицировать атрибуты на ER-диаграмме, и спроектировать по ней корректную реляционную схему.