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

Правила построения модели IDEF1X

От функциональных блоков к сущностям

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

Формирование списка потенциальных сущностей

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

Масштаб модели и инструменты

Если общее количество сущностей и связей превышает 25–30, модель IDEF1X считается необозримой для ручного рисования. Возникает потребность в специализированном программном обеспечении, позволяющем зумировать, масштабировать и перемещаться по цифровой модели, а не просто видеть рисунок на бумаге.

Визуализация и документирование

Информационная модель функции должна давать возможность видеть структуру документа и воспроизводить информацию, содержащуюся в порождаемых документах. Большую модель разбивают на логические блоки (HR, бухгалтерия, CRM и т.п.), сохраняя только входные связи между блоками. Каждый элемент модели обязан сопровождаться текстовыми пояснениями в глоссарии или гипертексте, иначе восприятие «с листа» крайне затруднено.

Определение атрибутов

После составления списка сущностей, их группировки и пояснения связей, переходят к раскрытию содержимого каждой сущности — перечню её атрибутов (attributes). Порядок: сначала сущности и связи, затем внутренняя структура.

Пример: модель строительства садового домика

Первоначальный перечень потенциальных сущностей

Рассмотрим упрощённую задачу. Составляется список: Дом, Крыша, Материалы, Проект дома, Стены, Строители, Фундамент, Каменщики, Плотники, Кровельщики, Мастер по отделке. Реальный процесс включает закупки, поставщиков и многое другое, но для иллюстрации ограничимся этим.

Отсев компонентов

Не все элементы являются самостоятельными сущностями. Крыша, фундамент и стены — это компоненты, части дома. В модели они не выделяются как отдельные сущности, а остаются лишь элементами сущности Дом. Самостоятельными признаны: Проект дома, Материал, Строитель (с подтипами) и, собственно, Дом.

Атрибуты сущностей

• Проект дома:
o Номер проекта — суррогатный ключ (surrogate key), искусственный простой первичный ключ (primary key, PK).
o ФИО архитектора, дата создания, стоимость. При необходимости добавляются стиль, этажность и прочее.
• Материал:
o Код материала — простой первичный ключ.
o Название, вид, характеристики.
• Строитель:
o Табельный номер — первичный ключ.
o ФИО, профессия, стаж работы, адрес.

Категоризация строителей

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

Сущность «Дом»: составной ключ и связи

Для сущности Дом первичный ключ образуют два атрибута: Адрес + ФИО хозяина. Это составной первичный ключ (composite primary key). Одного ФИО недостаточно, потому что один человек может владеть несколькими домами. Одного адреса тоже мало — адреса могут повторяться в разных регионах. Вероятность, что владелец приобрёл дома по абсолютно одинаковому адресу в двух регионах, ничтожно мала, поэтому пара «адрес + ФИО хозяина» обеспечивает уникальность.

Внешние ключи (foreign key, FK), ссылающиеся на родительские сущности:
• Номер проекта (ссылка на «Проект дома»);
• Код материала (ссылка на «Материал»);
• Табельный номер (ссылка на «Строитель»).

Все три внешних ключа не входят в первичный ключ «Дом», а остаются в списке вторичных атрибутов. Следовательно, эти связи являются неидентифицирующими (non-identifying relationships). Если бы внешний ключ попадал в состав первичного ключа дочерней сущности, связь была бы идентифицирующей (identifying relationship).

Кардинальность и обязательность

От сущностей Проект дома и Материал к Дом отходит связь с мощностью P (один или много, one or many). Это означает: в дочерней сущности обязательно должна существовать хотя бы одна запись, ссылающаяся на родительскую.

• Дом нельзя построить без проекта — каждый проект обязан быть реализован хотя бы в одном доме.
• Материал заводится в справочник только тогда, когда используется в строительстве, поэтому каждый материал хотя бы раз появляется в таблице «Дом».

Если бы связь имела мощность N (ноль, один или много, zero, one or many), допускалось бы существование неиспользованных проектов или материалов, что противоречит условию задачи.

Обзор ключевых понятий IDEF1X

Изученная нотация IDEF1X оперирует следующими элементами:
• Сущности — независимые (нет внешних ключей в первичном ключе) и зависимые (внешний ключ включён в первичный ключ). Среди них выделяются ассоциативные, характеристические, а также общие сущности, выступающие родителями в иерархии категорий.
• Атрибуты — первичные ключи (простые или составные), альтернативные ключи, внешние ключи и неключевые (вторичные) атрибуты.
• Отношения — идентифицирующие, неидентифицирующие, неспецифические («многие ко многим», many-to-many) и отношения категоризации с дискриминатором.

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

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

Когда перечень сущностей определён, на первый план выходит детализация: каждая сущность наделяется атрибутами, из которых выбирается или создаётся первичный ключ. Выбор ключа — это всегда компромисс между естественной уникальностью и удобством. Суррогатные ключи просты и стабильны, но не несут смысловой нагрузки; составные естественные ключи, напротив, отражают бизнес-логику, однако усложняют связи. В примере с домом использован составной ключ «адрес + ФИО хозяина» именно потому, что он опирается на реальные свойства объекта, а не на искусственный идентификатор, и гарантирует корректную идентификацию даже при масштабировании на множество регионов.

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

Особое место занимает механизм категоризации с дискриминатором. Он позволяет выразить иерархию «общее–частное» без дублирования общих атрибутов и с сохранением специфических свойств подтипов. Этот приём незаменим там, где сущности одной природы имеют разные наборы характеристик: достаточно вспомнить пример со студентами-бюджетниками и платниками. Тонкость заключается в том, что дискриминатор чётко определяет, какая запись в какое подмножество попадёт, исключая неоднозначность. В результате модель остаётся компактной, а прикладная логика легко считывается.

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