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

       

в проектах. Предполагается, что данный


Рассмотрим связь между служащими (employee) и проектами (project), которая идентифицирует работы (job), выполняемые служащими в проектах. Предполагается, что данный служащий может выполнять одновременно работы в нескольких проектах, но не несколько работ в одном и том же проекте. Эта связь лучше всего моделируется путем агрегации объектов "employee" и "project" в абстрактный объект, скажем, "job". Могут быть введены другие атрибуты "job", такие как "название" (title) и "ставка" (payrate). Объект "job" показан на .

Определение объекта "job" с соответствующим выбором селекторов и ключа приводится ниже:

var job: generic of

aggregate [E#, P#] E#: key employee; P#: key project; T: title; PR: payrate end

Здесь выбран ключ "E#, P#", поскольку, в соответствии с указанным выше ограничением, работы находятся во взаимно-однозначном соответствии с парами служащий-проект. В этом определении предполагается, что никакая декомпозиция "Работы" в плоскости обобщения не представляет интереса. Теперь предположим, что некоторых пользователей модели интересуют отдельные типы работ. Допустим, что среди проектов имеется проект, связанный с разработкой модемов, и другой, предусматривающий модернизацию принтеров. Некоторые пользователи могут пожелать рассматривать "работу в модемном проекте" (modern project job) и "работу в принтерном проекте" (printer project job) как родовые объекты. На рис.18 показано, как выглядит модель после включения в нее этих объектов как потомков "job" в плоскости обобщения.



Рис. 18. Результат декомпозиции объекта "job"в плоскости обобщения.

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

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