4.5.2. Определение владельцев атрибутов

На следующем этапе каждый неключевой атрибут должен быть приписан к одной сущности-владельцу. Для многих атрибутов сущности-владельцы очевидны. Например, разработчик без заминки свяжет атрибут ИМЯ-ПРОДАВЦА с сущностью ПРОДАВЕЦ. Однако некоторые атрибуты могут вызвать у разработчика трудности при определении их сущностей-владельцев.

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

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

Для всех выявленных на стадии 4 атрибутов должны быть разработаны определения. Здесь также применимы основные принципы построения определений, уже используемых в модели данных (в особенности из стадии 3). Разработанные определения должны быть точными, специфическими, полными и универсально понимаемыми. Эти определения атрибутов записываются в том же формате, что и определения атрибутов из стадии 3.

Определение атрибута включает:

• имя атрибута;

• определение атрибута;

• синонимы/псевдонимы атрибута.

Каждому атрибуту должно быть присвоено уникальное имя, поскольку в IDEFlX-модели и к сущностям, и к атрибутам применяется правило "одно и то же имя - один и тот же смысл". Поэтому разработчик может воспользоваться стандартным подходом к именам атрибутов. Однако для облегчения чтения при проверке правильности лучше использовать привычные для пользователя естественные названия. Если встречаются имена атрибутов, которые должны удовлетворять строгим правилам языка программирования (например, ограниченность имен переменных в фортране семью символами), то они должны всегда идентифицироваться как псевдонимы или не включаться вовсе.

В определении атрибута разработчик может пожелать установить формат атрибута, например, буквенно-цифровой код, текст, денежные единицы, дату и т.д. В определении может быть также установлена область допустимых значений в формате списка (например, понедельник, вторник, среда, четверг, пятница) или диапазона (например, больше нуля, но меньше десяти). В определении могут быть также указаны утверждения, включающие несколько атрибутов. Например, атрибут ОКЛАД_СЛУЖАЩЕГО должен быть больше 20000 долларов или СЛУЖЕБНЫЙ_КОД_СЛУЖАЩЕГО равен двенадцати.

4.5.4. Детализация модели

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

Единственное отличие в применении на стадии 4 правил необращения в ноль и неповторяемости заключается в том, что эти правила относятся преимущественно к неключевым атрибутам. На рис. 4-23 проиллюстрировано применение к неключевому атрибуту правила необращения в ноль. На рис. 4-24 приведен пример применения к неключевому атрибуту правила неповторяемости.

Рис. 4-23. Стадия 4 - применение правила необращения в ноль

Вместо того чтобы немедленно создавать новые сущности для атрибутов, нарушающих правила детализации, можно отмечать такие нарушения по мере их выявления с тем, чтобы позднее создать новые сущности. Рядом с именами атрибутов-нарушителей в диаграммах атрибутов могут быть сделаны пометки в скобках (буква N для нарушителей правила необращения в ноль и буква R для нарушителей правила неповторяемости).

Рис. 4-24. Стадия 4 - применение правила неповторяемости

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

Должна быть также определена принадлежность каждого атрибута в соответствии с правилом полной функциональной зависимости. Это правило утверждает, что ни одно значение неключевого атрибута, принадлежащего экземпляру сущности, не может быть идентифицировано лишь частью значения ключа данного экземпляра сущности. Это правило применимо только к сущностям с составными ключами и эквивалентно второй нормальной форме в реляционной теории. Рассмотрим диаграмму, приведенную на рис. 4-19. Если ИМЯ_ПРОЕКТА - неключевой атрибут, считающийся принадлежащим сущности ЗАДАНИЕ, то оно удовлетворяет правилам необращения в ноль и неповторяемости. Однако, поскольку ИМЯ_ПРОЕКТА может идентифицироваться только атрибутом НОМЕР_ПРОЕКТА, т.е. частью ключа ЗАДАНИЯ, то этот атрибут не удовлетворяет правилу полной функциональной зависимости. ИМЯ_ПРОЕКТА будет, очевидно, атрибутом сущности ПРОЕКТ.

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

Рассмотрим сущность СЛУЖАЩИЙ на рис. 4-19. Если ИМЯ_ОТДЕЛА является для сущности СЛУЖАЩИЙ неключевым атрибутом, то оно будет удовлетворять правилам необращения в ноль и неповторяемости. Однако поскольку ИМЯ_ОТДЕЛА может быть определено из НОМЕРА_ОТДЕЛА, который является наследуемым неключевым атрибутом, то ИМЯ_ОТДЕЛА не удовлеторяет правилу отсутствия транзитивной зависимости и поэтому не является атрибутом, принадлежащим сущности СЛУЖАЩИЙ. ИМЯ_ОТДЕЛА будет, очевидно, неключевым атрибутом сущности ОТДЕЛ.

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