Идентификация неключевых атрибутов

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

Процесс построения пула атрибутов похож по сути на построение пула сущностей (рис.4-22). На стадии 1 мы выбирали из списка исходных данных стадии 0 имена, появлявшиеся в качестве существительных-объектов. Теперь мы вернемся к списку исходных данных и выберем имена, появляющиеся в качестве описательных существительных. Описательные существительные (существительные для описания объектов) обычно представляют атрибуты.

Номер	Имя атрибута	Номер исх. данных
	Номер заказа на покупку
	Код покупателя
	Имя продавца
	Код заказа
	Номер замены
	Куда отгружен
	Имя продавца
	Адрес продавца
	Код упаковщика
	Имя упаковщика
	Имя заказчика	11,42
	Код отдела
	Отгружено через
	Имя покупателя
	Номер заказа на покупку
	Дата подписи документа об отгрузке
	Код контроля качества
	.........

Рис. 4-22. Пример пула атрибутов

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

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

 

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

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

⇐ Предыдущая21222324252627282930Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: