Теоретические основы проектирования. Часть 2

Базовые понятия

Ранее были введены три ключевых понятия: сущность, атрибут и отношение. Далее рассматриваются правила, определяющие, каким требованиям должен соответствовать объект, чтобы считаться сущностью.

Правила определения сущности

Имя сущности
Сущность должна обладать уникальным именем, представленным существительным в единственном числе (например, «Студент»). Уникальность имени — принципиальное требование: в рамках одной схемы не может быть двух сущностей с одинаковым названием, подобно тому, как в базе данных не может быть двух таблиц с одинаковым именем. Физически система управления базами данных (СУБД) не накладывает ограничений на символы, однако с точки зрения культуры проектирования принято придерживаться именно такого формата.
На уровне итоговой реализации все имена таблиц и полей обычно задаются на английском языке или с использованием транслитерации. Это связано с чувствительностью программного обеспечения к кодировкам и нестандартным символам. На стадии же рисования диаграммы допустимы названия на любом языке.

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

• Собственные атрибуты принадлежат самой сущности (например, у представителя сущности «Студент» это имя, фамилия, отчество).
• Наследуемые атрибуты поступают от родительской сущности через связь по внешнему ключу (foreign key, FK). Пример — поле «Семейное положение», значение которого берется из отдельного справочника и передается через внешний ключ.

Ключи сущности
Каждая сущность должна иметь один или несколько атрибутов, однозначно идентифицирующих каждый её экземпляр. Такой атрибут или группа атрибутов называется ключом. Если достаточно одного поля (например, номер паспорта), ключ является простым. Если требуется комбинация полей — ключ называется составным. В первую очередь речь идёт о первичном ключе (primary key, PK), который может быть как простым, так и составным.

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

Внешний ключ и типы связей

Внешний ключ, приходящий в дочернюю сущность, может либо входить в состав её первичного ключа, либо не входить. Это определяет тип связи и статус сущности.

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

Пример неидентифицирующей связи: у сущности «Счёт» первичный ключ — номер счёта, а внешний ключ — идентификатор клиента (например, номер паспорта). Поскольку FK не входит в первичный ключ, связь между «Клиентом» и «Счётом» неидентифицирующая.

Уровни представления и этапы проектирования

Проектирование базы данных разделяется на три этапа.

1. Инфологический этап
На этом этапе создается диаграмма «сущность-связь» (ER-диаграмма). Задача — осмыслить предметную область в общих чертах: выявить основные сущности и связи между ними, не вдаваясь в детали атрибутов. Сущность здесь изображается просто как прямоугольник с именем, а связь подписывается глагольным оборотом (например, «Клиент имеет Счёт»).
2. Даталогический этап
На этом этапе строится полная атрибутивная модель (также именуемая моделью данных, основанной на ключах). Здесь каждая сущность детализируется: в прямоугольнике указывается имя, ниже под горизонтальной чертой — первичный ключ, затем — все неключевые атрибуты. Внешние ключи помечаются как FK. Количество сущностей на этом этапе обычно увеличивается за счёт введения дополнительных таблиц для реализации связей.
3. Физический этап
Заключительный этап — реализация спроектированной схемы в конкретной СУБД. Таблицы, поля и связи физически создаются в базе данных и становятся готовыми к заполнению реальными данными.

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

Требования к атрибутам

• Каждый атрибут в рамках одной сущности должен иметь уникальное имя. Повторение имени допускается только в разных сущностях (например, атрибут «Название» может быть и у сущности «Книга», и у сущности «Цвет»).
• Количество атрибутов у сущности не ограничено.
• Атрибуты делятся на собственные и наследуемые (передаваемые через внешний ключ).

Краткие итоги

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

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

Методология проектирования предлагает не мгновенный переход к таблицам, а последовательное восхождение по уровням абстракции. Инфологический этап с его лаконичной диаграммой «сущность-связь» решает коммуникативную задачу — позволяет согласовать с заказчиком общее видение системы без погружения в технические детали. Даталогический этап, результатом которого становится полная атрибутивная модель, переводит это видение на язык, понятный разработчику, с точным определением всех полей и ключей. Такая двухступенчатая детализация служит страховкой от дорогостоящих ошибок: сначала фиксируется структура бизнес-понятий, и лишь затем она наполняется атрибутами. Итоговый физический этап низводит абстрактную модель до конкретной реализации в выбранной СУБД с поправкой на технические ограничения, включая лингвистические аспекты вроде перевода имен на английский язык во избежание проблем с кодировками. Выстроенная иерархия от концептуального рисунка к физической схеме формирует сквозную прослеживаемость проектных решений.