А.2.3.3. Спецификация проекта в рамках модели данных

В процессе спецификации проекта языки интерфейсов для баз данных генерируются на основе семантической модели данных. Хотя эти интерфейсы соответствуют определенным моделям данных, мы должны отличать их от понятия «семантическая модель данных». Широко известны такие модели данных, как иерархические, сетевые, реляционные, объектно-ориентированные. Иерархические модели данных представляют интерес лишь с исторической точки зрения, а сетевые постепенно утрачивают свое значение, поэтому мы сосредоточим внимание на реляционных моделях данных и лишь вскользь затронем объектно-ориентированные.

На первом этапе информационные объекты уровня определения требований трансформируются в отношения. Здесь необходимо соблюдать определенные правила.

На втором этапе отношения оптимизируются посредством нормализации. При этом удаляются любые аномалии, возникающие при использовании функций «вставка», «изменение» и «удаление». Теперь предварительные отношения, перенесенные с уровня определения требований, разбиваются на более мелкие элементы. Если чрезмерная детализация приведет к снижению производительности, можно применить прямо противоположный метод, который называется денормализацией.

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

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

Реляционная схема переносится на используемый базой данных язык описания данных (ЯОД) и адаптируется к техническим требованиям ЯОД. Саму реализацию это никак не затрагивает. В то же время ЯОД представляет собой язык описания, наиболее «близкий» к реализации, где с моделью данных взаимодействуют другие модели ARIS. Приложения должны взаимодействовать только через схему базы данных, описанную посредством ЯОД.

А.2.3.3.1. Создание отношений

Отношения (R_i) описываются путем перечисления имен атрибутов Aij (см. (1) на рис. 68). Удобно представлять отношения в виде таблиц. С математической точки зрения, отношение есть подмножество декартова произведения доменов, связанных с атрибутами.

(1) R_i (A_i1, A_i2, … ,A_iz) a_ij = Attribute j in relation

Деталь (Номер детали, Имя, Запас)

Деталь	Номер детали	Имя	Запас
	4717	Отверстие	526
	4728	Болт	768

(2) R_i (D_i1 x D_i2 x … x D_iz)

whereby D is the domain of A

Рис. 68. Описание отношений

Соблюдая сравнительно простые правила, отношения можно вывести на основе модели ERM, описывающей требования на уровне данных. При этом каждый тип сущности и каждый тип отношения n:n преобразуется в отношение. Тип отношения n:n означает, что максимальное значение мощностей связей по крайней мере двух смежных типов сущностей равно n.

С другой стороны, связи типа 1:n не имеют собственного отношения. В этом случае отношения адаптируются путем введения ключевого атрибута в тип сущности, в результате чего максимальное значение мощности оказывается равно 1 (см. примеры на рис. 69). Такой перенесенный ключевой атрибут называется внешним ключом.

Рис. 69. Выведение отношений на основе ЕПМ

Метамодель, представленная на рис. 70, вводит класс ОТНОШЕНИЕ. Его отношение с классом ИНФОРМАЦИОННЫЙ ОБЪЕКТ, созданным на стадии определения требований, устанавливается при помощи связи СОЗДАНИЕ ОТНОШЕНИЯ. В соответствии с формированием отношений информационный объект может иметь либо 0, либо (максимум) 1 отношение, тогда как одно отношение может быть связано с одним или множеством информационных объектов. Атрибутом класса ОТНОШЕНИЕ является его собственное имя, которое также может совпадать с именем исходного информационного объекта ERM. Имена атрибутов, принадлежащих тому или иному отношению, также можно взять из определения требований, хотя их можно и изменить. Если изменения не вносятся, атрибуты создаются путем связывания классов ОТНОШЕНИЕ и ИНФОРМАЦИОННЫЙ ОБЪЕКТ. Однако для того чтобы подчеркнуть автономность спецификации проекта на уровне разработки, присваиваемые отношению атрибуты связываются с общим описанием атрибутов на уровне определения требований при помощи АССОЦИАЦИИ ОТНОШЕНИЕ-АТРИБУТ. Если при переносе с уровня определения требований имена не меняются, отношения можно формировать в соответствии с описанными требованиями. Многие коммерческие инструменты типа CASE обеспечивают такой автоматический переход от модели ERM.

Рис. 70. Метамодель выведения отношений

Доступ доменов к имеющимся описаниям доменов, полученным на этапе определения требований, осуществляется через присвоение атрибутов. Для иллюстрации мы рассмотрим класс ДОМЕН, когда будем обсуждать реляционную модель и условия целостности, относящиеся к доменам.

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