Классика баз данных - статьи

       

Теперь мы можем продолжить разрабатывать


Все эти компоненты – примитивны. Полученная модель представлена на рис.10.



Рис. 10. Декомпозиция объекта "employee" в плоскости агрегации

Теперь мы можем продолжить разрабатывать модель, декомпозируя любой объект (который еще не был декомпозирован) в любой плоскости. Поскольку для нас не представляют интерес какие-либо подтипы "employee type", этот объект не декомпозируется в плоскости обобщения. По подобным же причинам мы не декомпозируем объекты "trucker", "secretary" и "engineer" в плоскости обобщения. Однако каждый из этих трех объектов должен быть декомпозирован на (примитивные) объекты в плоскости агрегации. Эти декомпозиции включены на рис.11. Чтобы избежать загромождения рисунка, мы не провели до конца линии, связывающие каждый объект "employee ID#", "name" и "age" с каждым из объектов "trucker", "secretary" и "engineer". В заключение мы можем выбрать для каждого объекта селекторы и ключи. И тогда получается реляционная модель, представленная на рис. 11.



Рис. 11. Реляционная модель для объекта "employee"

Определения отношений "employee" и "employee type" даются на рис.12. Заметим, что в отношении "employee type" содержатся детальные сведения о "trucker", "secretary" и "engineer", когда они полагаются родовыми объектами. Отношение "employee" отсылает к этим детальным сведениям через домен образов (т.е. домен с селектором "TN"). Это позволяет для каждого отдельного служащего ссылаться на все родовые свойства подкласса служащих, к которому он относится.

var employee: generic

TN = (trucker, txoretary, engineer) of

aggregate [E#] E#: employee ID#; N: name; А: age; TN: key employee-type end

var employee-type: generic of

aggregate [TN] TN: typename; N: size; А: vacancies; TN: agency end

Рис. 12. Определение для объектов "employee" и "employee-type" с


Содержание  Назад  Вперед