Добавлен: 25.10.2018
Просмотров: 5093
Скачиваний: 13
Однако, рассмотрев использование НОМЕРА_ПУНКТА_ЗАКАЗА, мы увидим, что один и тот же экземпляр сущности ЗАКАЗ может быть ассоциирован со многими НОМЕРАМИ_ПУНКТА_ЗАКАЗА, по одному на каждый заказываемый пункт.
Для правильного отражения этого факта в модели данных должна быть создана новая сущность, называющаяся ПУНКТ_ЗАКАЗА с добавлением дуги и метки отношения, синтаксиса и определения.
Таким образом, начинают выясняться истинные характеристики связи между заказами на покупку и пунктами заказов на покупку.
На рис. 2.7 приведена диаграмма вариантов детализации, относящаяся к применению правила необращения в ноль.
Рис. 2.7. Детализация правила необращения в ноль.
Заметим, что ключ НОМЕР_ДЕТАЛИ промигрировал к ПУНКТУ_ЗАКАЗА.
Эта ассоциация установилась в связи с тем, что ПУНКТ_ЗАКАЗА связан некоторым образом с деталями. Однако показано, что диаграмма утверждает ассоциированность каждого пункта заказа на покупку в точности с одним номером детали.
Исследование (или, возможно, комментарий рецензента) показывает, что не все пункты заказа на покупку ассоциируются с деталями. Некоторые из них могут быть связаны с услугами или другими товарами, не имеющими номеров деталей. Это запрещает миграцию НОМЕРА_ДЕТАЛИ непосредственно в сущность ПУНКТА_ЗАКАЗА и требует в нашем примере установления новой сущности ЗАКАЗАННАЯ_ДЕТАЛЬ.
Как только новая сущность установлена, в соответствии с правилом миграции обязательно должна произойти миграция ключа, и разработчик будет снова проверять правильность соответствия структуры сущность-отношение правилам необращения в ноль и неповторяемости.
Каждый составной ключ должен проверяться на соответствие правилу наименьшего ключа.
Это правило требует, чтобы любая сущность с составным ключом не могла разделяться на несколько сущностей с более простыми ключами (на меньшие компоненты) без потери некоторой информации.
В связи со стадией определения отношений упоминалась тенденция выявления избыточных отношений. Однако на той стадии анализ, в основном, проводится разработчиком по его усмотрению. Установив ключи, разработчик может быть более точным в анализе.
Двойной путь отношений существует тогда, когда существует сущность-потомок с двумя отношениями, ведущими, в конечном итоге, обратно (через одно или несколько отношений) к общей «корневой» сущности-родителю.
В случае существования двойных путей требуется утверждение пути, чтобы определить, являются ли пути равными, неравными или неопределенными.
Определение. Пути равны, если для каждого экземпляра сущности-потомка оба пути отношений всегда ведут к одному и тому же экземпляру корневой родительской сущности.
Определение. Пути являются неравными, если для каждого экземпляра сущности-потомка оба пути отношений всегда ведут к различным экземплярам корневой родительской сущности.
Определение. Пути являются неопределенными, если они равны для некоторых экземпляров сущности-потомка и не равны для остальных экземпляров.
Если один из путей состоит только из одного отношения и пути равны, то путь из одного отношения является излишним и должен быть удален.
Простейшим случаем отношения, имеющего двойственные пути, является отношение, в котором оба пути состоят из единственного отношения.
Например, каждый экземпляр сущности СХЕМА_СБОРКИ может быть связан с двумя различными экземплярами сущности ДЕТАЛЬ, избыточности нет.
В этом случае утверждение пути будет требовать, чтобы пути были неравны, поскольку ДЕТАЛЬ не может быть вмонтирована в себя.
Определение. Если один из путей содержит несколько отношений, а другой путь содержит одно отношение, то такая структура называется триадой.
На рис. 2.8 приведен пример триады.
Рис. 2.8. Пример триады
В этом случае СЛУЖАЩИЙ связан с ОТДЕЛЕНИЯМИ как прямо, так и косвенно, через ОТДЕЛ.
Если утверждение пути состоит в том, что ОТДЕЛЕНИЕ, которому принадлежит СЛУЖАЩИЙ, содержит ОТДЕЛ, которому принадлежит СЛУЖАЩИЙ, то отношение между сущностями ОТДЕЛЕНИЯ и СЛУЖАЩИЙ является избыточным и должно быть удалено.
Заметим, что если некоторые, но не все, СЛУЖАЩИЕ могут в действительности принадлежать двум различным отделениям, то должна быть добавлена еще одна сущность, такая, как ВРЕМЕННЫЙ_СЛУЖАЩИЙ, чтобы НОМЕР_ОТДЕЛЕНИЯ удовлетворял правилу необращения в ноль в качестве внешнего ключа сущности СЛУЖАЩИЙ.
Утверждения могут также применяться к отношениям двойственных путей, когда оба пути раскрывают более одного отношения.
В приведенном на рис. 2.9 примере между сущностями ОТДЕЛ и ИСПОЛНИТЕЛЬ_ЗАДАНИЯ существуют два пути отношений.
Если СЛУЖАЩИЙ может быть приписан только к тому ПРОЕКТУ, которым руководит его ОТДЕЛ, то пути равны.
Рис. 2.9. Пример утверждения пути
Если СЛУЖАЩИЙ может быть приписан только к тому ПРОЕКТУ, которым руководит не его отдел, то пути не равны.
Если СЛУЖАЩИЙ может быть приписан к ПРОЕКТУ независимо от того, руководит его ОТДЕЛ ПРОЕКТОМ или нет, то пути являются неопределенными.
Обычно, пути предполагаются неопределенными, если только утверждения точно не определены.
Утверждения должны быть добавлены в качестве примечаний к диаграммам стадии определения ключей и включены в определение сущности-потомка.
После идентификации элементов первичного ключа производятся записи в пул атрибутов.
Для идентификации распределения и использования атрибутов в модели может применяться матрица сущность/атрибут.
Эта матрица обладает следующими свойствами:
1. Все имена сущностей изображаются с краю.
2. Все имена атрибутов изображаются наверху.
3. Использование атрибутов сущностями изображается в соответствующей строке с помощью следующей кодировки:
־ «О» = владелец,
־ «К» = первичный ключ,
־ «I» = наследуемый.
Пример матрицы сущность/атрибут приведен в таблицах 2.4 и 2.5.
Эта матрица является основным средством поддержки целостности модели.
Таблица 2.3.
Пример матрицы «Сущность/атрибут»
Таблица 2.5.
Имена атрибутов
2.5.3. Определение ключевых атрибутов
После установления ключей наступает момент для определения атрибутов, которые были использованы в качестве ключей.
Для этих определений будут точными, специфическими, полными и универсально понимаемыми.
Определения атрибутов всегда ассоциированы с сущностями, владеющими этими атрибутам, т.е. они всегда являются элементами набора документов сущностей-владельцев. Поэтому достаточно просто определить атрибуты, которые принадлежат каждой сущности и используются в этом первичном или альтернативном ключе сущности.
В примере из таблицы 2.4 эти атрибуты кодируются ОК в матрице сущность/атрибут.
Определение атрибута включает:
־ имя атрибута;
־ определение атрибута;
־ синонимы атрибута.
2.5.5. Изображение результатов стадии определения ключей
В результате идентификации и миграции ключей диаграммы функционального представления могут теперь быть обновлены для отражения и детализации отношений.
Диаграммы функционального представления должны изображать:
־ атрибуты первичных, альтернативных и внешних ключей;
־ независимые от идентификатора (с прямыми углами) и зависимые от идентификатора (с закругленными углами) сущности;
־ идентифицирующие (сплошная линия) и неидентифицирующие (штриховая линия) отношения.
Большую часть информации, полученной в результате анализа на этой стадии, содержат сами сущности.
Каждый набор документов сущности содержит:
־ определение сущности;
־ список атрибутов первичных, альтернативных и внешних ключей;
־ определения принадлежащих сущности ключевых атрибутов;
־ список отношений, в которых сущность является общей;
־ список отношений, в которых сущность является сущностью-категорией;
־ список идентифицирующих отношений, в которых сущность является сущностью-родителем;
־ список идентифицирующих отношений, в которых сущность является сущностью-потомком;
־ утверждения двойных путей (в случае необходимости).
Если нужно, разработчик может построить для сущности отдельную диаграмму, следуя тому же подходу, что и при построении необязательной диаграммы сущности на стадии определения отношений.
Помимо табличных списков определений отношений, полезны перекрестные обратные ссылки на ассоциированные сущности.
В документах, разработанных на стадии определения ключей, необходимо перекрестно ссылаться на те атрибуты, которыми сущности обладают, и на те, которые они разделяют.
2.6. Стадия определения неключевых атрибутов
Данная стадия является завершающей стадией разработки модели.
Она включает:
- разработку пула атрибутов;
- установление принадлежности атрибутов;
- определение неключевых атрибутов;
Результаты стадии определения атрибутов изображаются на одной или нескольких диаграммах (диаграммах уровня атрибутов). В конце стадии модель данных полностью детализируется (в соответствии с пятой нормальной формой в реляционной теории).
Модель снабжается полным множеством определений и перекрестных ссылок для всех сущностей, (ключевых и неключевых) атрибутов и отношений.
2.6.1. Разработка пула атрибутов
На стадии определения сущностей в пул сущностей в качестве потенциальных сущностей было введено много имен из списка исходных данных начальной стадии. Некоторые из этих имен, однако, могли не быть признаны на стадии определения ключей в качестве сущностей. По всей вероятности они являются атрибутами.
Кроме того, многие из имен, не выбранные из списка исходных данных сначала, являются, возможно, атрибутами. Этот список, в сочетании со сведениями, полученными на стадиях определения сущностей и отношений, является основой для установления пула атрибутов.
Определение. Пул атрибутов является списком потенциально жизнеспособных атрибутов, замеченных в контексте модели.
Этот список будет, по всей вероятности, заметно больше пула сущностей.
Пример пула атрибутов приведен в таблице 2.6.
Таблица 2.6
Пул атрибутов является источником имен, используемых в модели.
Атрибуты, появившиеся на более поздних стадиях моделирования, добавляются в пул атрибутов и им приписываются уникальные идентифицирующие номера. Затем они развиваются для дальнейшего использования в модели.
2.6.2. Определение владельцев атрибутов
На этом этапе каждый неключевой атрибут должен быть приписан к одной сущности-владельцу.
Для многих атрибутов сущности-владельцы очевидны.
Например, разработчик без заминки свяжет атрибут ИМЯ-ПРОДАВЦА с сущностью ПРОДАВЕЦ.
Однако некоторые атрибуты могут вызвать у разработчика трудности при определении их сущностей-владельцев.
Если разработчик не уверен в сущности-владельце для атрибута, он может обратиться к исходному материалу, откуда был выбран атрибут. Это поможет в определении владельца.
На начальной стадии был сформирован список исходных данных, ставший основой пула атрибутов. Этот список указывает разработчику места, где значения представленных атрибутов использовались в исходном материале.
Анализ примеров использования атрибута в исходном материале упрощает поиск сущности-владельца в модели. Он должен иметь в виду, что главенствующим фактором в определении владельцев атрибутов является вхождение экземпляров атрибутов, представленных отражаемыми в исходном материале значениями атрибутов.
После того, как каждому атрибуту будет назначена сущность-владелец, это назначение должно быть зафиксировано.
2.6.3. Определение атрибутов
Для всех выявленных на данной стадии атрибутов должны быть разработаны определения атрибутов.
Здесь также применимы основные принципы построения определений, уже используемых в модели данных (в особенности из стадии определения ключей).
Разработанные определения должны быть точными, специфическими, полными и универсально понимаемыми.
Эти определения атрибутов записываются в том же формате, что и определения атрибутов из стадии 3.
Определение атрибута включает:
- имя атрибута;
- определение атрибута;
- синонимы/псевдонимы атрибута.
Каждому атрибуту должно быть присвоено уникальное имя, поскольку в IDEF1X-модели и к сущностям, и к атрибутам применяется правило «одно и то же имя – один и тот же смысл».
Поэтому разработчик может воспользоваться стандартным подходом к именам атрибутов.
Однако для облегчения чтения при проверке правильности лучше использовать привычные для пользователя естественные названия.
Если встречаются имена атрибутов, которые должны удовлетворять строгим правилам языка программирования, то они должны всегда идентифицироваться как псевдонимы или не включаться вовсе.
В определении атрибута разработчик может пожелать установить формат атрибута, например, буквенно-цифровой код, текст, денежные единицы, дату и т.д.
В определении атрибута может быть также установлена область допустимых значений в формате списка (например, понедельник, вторник, среда, четверг, пятница) или диапазона (например, больше нуля, но меньше десяти).
В определении атрибута могут быть также указаны утверждения, включающие несколько атрибутов.
Например, атрибут ОКЛАД_СЛУЖАЩЕГО должен быть больше 20000 рублей или СЛУЖЕБНЫЙ_КОД_СЛУЖАЩЕГО равен двенадцати.
2.6.3. Детализация модели
Теперь необходимо начать детализацию отношений на стадии определения атрибутов.
Здесь используются те же основные правила, что и на стадии определения ключей.
Правила необращения в ноль и неповторяемости теперь применяются и к ключевым, и к неключевым атрибутам.
В результате могут возникнуть некоторые новые сущности. После идентификации этих сущностей должно применяться правило миграции ключей точно так же, как на стадии определения ключей.
Единственное отличие в применении на данной стадии правил необращения в ноль и неповторяемости заключается в том, что эти правила относятся преимущественно к неключевым атрибутам.
На рис. 2.10 проиллюстрировано применение к неключевому атрибуту правила необращения в ноль.
На рис. 2.11 приведен пример применения к неключевому атрибуту правила неповторяемости.
Вместо того, чтобы немедленно создавать новые сущности для атрибутов, нарушающих правила детализации, можно отмечать такие нарушения по мере их выявления с тем, чтобы позднее создать новые сущности.