Комплексное определение для информационного моделирования (IDEF1X), страница 30

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

Пример такого использования показан на рисунке A3.15.

Рисунок A3.15. Функциональные имена атрибутов

A3.4.5 Проверка правильности выделения ключей и отношений

Основные правила, влияющие на идентификацию и миграцию первичных ключей:

a) Использование синтаксиса неопределенных отношений запрещено.

b) Миграция первичного ключа от родителя (или универсального объекта) дочернему объекту  (или объекту категории) обязательна.

c) Использование атрибута, у которого может быть более одного значения в одно время, запрещено. (правило запрещения повторов)

d) Использование атрибута первичного ключа, который может иметь нулевое значение (то есть может не иметь значения), запрещено.

e) Объекты с составными первичными ключами не могут быть разбиты на несколько объектов с более простыми первичными ключами (Правило наименьшего ключа).

f) Для двойных связей отношениями между двумя объектами требуются утверждения (ПОЯСНЕНИЯ).

Мы уже обсудили первые два правила в предыдущих разделах, таким образом следует обратить внимание на последнюю группу правил в этом пункте.

На рисунке A3.16 изображена диаграмма, которая иллюстрирует “Правило запрещения повторов.” Обратите внимание, что предмет диаграммы имеет в качестве частей первичного ключа ЗАКАЗА НА ПОСТАВКУ и НОМЕР ЗАКАЗА НА ПОСТАВКУ и НОМЕР ЭЛЕМЕНТА ЗАКАЗА НА ПОСТАВКУ. Однако, в данном примере, в котором используется НОМЕР ЭЛЕМЕНТА ЗАКАЗА НА ПОСТАВКУ, видно, что один ЗАКАЗ НА ПОСТАВКУ (экземпляр класса объекта) может иметь много НОМЕРОВ ЭЛЕМЕНТА ЗАКАЗА НА ПОСТАВКУ, по одному на каждый заказываемый элемент. Чтобы должным образом изобразить это в модели данных, должен быть создан новый объект под названием ЭЛЕМЕНТ ЗАКАЗА НА ПОСТАВКУ, в котором также указываются отношения, и определения. Только тогда появляется ясная связь между заказом на поставку и элементами заказа на поставку.

Рисунок A3.16. Правило невозможности повторов при усовершенствовании

На рисунке A3.17 изображена диаграмма альтернативы усовершенствования, которая нужна для анализа нулевых атрибутов. Отметим, что НОМЕР КОМПОНЕНТА мигрирует к ЭЛЕМЕНТУ ЗАКАЗА НА ПОСТАВКУ. Эта связь устанавливается, потому что элементы заказа на поставку связаны в некотором роде с компонентами. Однако, как видно из рисунка, диаграмма показывает, что каждый элемент заказа на поставку связан только с одним номером компонента. Проверка (или возможно комментарий рецензента) выявляет, что не все элементы заказа на поставку связаны с компонентами. Некоторые могут быть связаны с услугами или другими товарами потребления, у которых нет номеров компонентов. Это запрещает миграцию НОМЕРА КОМПОНЕНТА непосредственно к объекту ЭЛЕМЕНТ ЗАКАЗА НА ПОСТАВКУ и требует создания нового объекта, названного в нашем примере "заказанный элемент компонента".

Рисунок A3.17. Правила усовершенствования

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

Каждый составной первичный ключ должен быть проверен, с целью удостовериться, что он удовлетворяет минимальному правилу ключей. Это правило требует, чтобы ни один объект с составным первичным ключом не мог быть разбит на два или более объектов с более простыми первичными ключами (которые содержат компонентов), без потери какой-либо информации.

На Этапе 2, была упомянута тенденция определять избыточные отношения. Однако, анализ со стороны разработчика модели на Этапе 2 был поверхностным. С установленными ключами разработчик модели может провести более тщательный анализ. Двойные отношения существуют тогда, когда есть дочерний объект с двумя отношениями, которые в конечном счете возвращаются (через одно или более отношений) к общему "корневому" родительскому объекту. Когда существуют такие отношения, необходимо определять, равны ли пути, или неравны, или они могут быть неопределенны. Пути равны, если для каждого экземпляра класса дочернего объекта оба пути отношений всегда приводят к тому же самому корневому родительскому экземпляру класса объекта. Пути неравны, если для каждого экземпляра класса дочернего объекта оба пути отношений всегда приводят к различным экземплярам класса корневого объекта (родителя). Пути неопределенны, если они равны для некоторых дочерних экземпляров класса объекта и неравны для других. Если один из путей состоит из только из одиночного отношения, и пути равны между собой, то этот одиночный путь отношений избыточен и должен быть удален.

Самый простой случай двойных отношений пути - тот, в котором оба пути состоят из одиночных отношений. Пример этой структуры показан на рисунке A3.15. Так как каждый экземпляр класса ИСПОЛЬЗОВАНИЯ КОМПОНЕНТА может быть связан с двумя различными экземплярами класса КОМПОНЕНТЫ, никакой избыточности не существует. Утверждение пути в этом случае потребовало бы, чтобы пути были неравны, так как КОМПОНЕНТ не может входить сам в себя.