Подтип PROGRAMMER отображается в другую базовую переменную-отношение, например PGMR, с таким же первичным ключом, что и у переменной-отношения ее супертипа, но с другим набором атрибутов, соответствующим свойствам, которые применяются для описания только работников-программистов (например, LANG в нашем примере).

VAR PGMR BASE RELATION { EMPi ... , LANG, ... } PRIMARY KEY { EMPi } ... ;

Более того, первичный ключ переменной-отношения PGMR также является внешним ключом, который ссылается на переменную-отношение ЕМР. Следовательно, приведенное выше определение необходимо соответствующим образом расширить (в частности, обратите внимание на определение правил удаления и обновления).

VAR PGMR BASE RELATION { ЕМР# ... , LANG, ... } PRIMARY KEY ( EMPi ) ; FOREIGN KEY ( EMPi ) REFERENCES EMP

ON DELETE CASCADE

ON UPDATE CASCADE ;

Нам также потребуется представление, например с именем EMP PGMR, являющееся соединением переменных-отношений супертипа и подтипа.

VAR EMP PGMR VIEW ЕМР JOIN PGMR ;

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

Такая структура позволяет выполнять следующие действия.

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

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

С помощью представления EMP PGMR можно получить доступ ко всему набору свойств программистов.

В базовую переменную-отношение ЕМР можно вставлять сведения о работниках, которые не являются программистами.

Сведения о работниках-программистах можно вставлять в базу данных с помощью представления EMPPGMR.

Сведения о любых работниках (программистах и не программистах) можно удалить из базы данных, удалив их из базовой переменной-отношения ЕМР, а сведения о работниках-программистах можно удалить из базы данных, удалив их из представления EMP PGMR.

Свойства, общие для всех работников, можно обновлять в базовой переменной-отношении ЕМР, а свойства только работников-программистов можно обновлять и с помощью представления EMP PGMR.

Свойства, характерные только для программистов, можно обновлять в базовой переменной-отношении PGMR.

Статус сотрудника-не программиста можно изменить на статус программиста за счет вставки сведений об этом сотруднике в базовую переменную-отношение PGMR или же в представление EMP PGMR.

Статус программиста можно изменить на статус сотрудника-не программиста за счет удаления сведений об этом программисте из базовой переменной-отношения PGMR.

Читателю предлагается самостоятельно разобраться в других типах сущностей, показанных на рис. 13.2 (APPLICATION PROGRAMMER и SYSTEM PROGRAMMER).

13.6. Краткий анализ ER-модели

в этом разделе кратко рассматриваются некоторые определенные аспекты ER-модели. Большая часть излагаемого здесь материала взята из другой работы автора [13.8], в которой эта тема обсуждается подробнее. Дополнительные сведения и комментарии можно найти в аннотациях, помещенных в список рекомендуемой литературы к данной главе.

ER-модель как основа реляционной модели

Рассмотрим подход с использованием ER-модели с несколько иной точки зрения. Надо полагать, вполне очевидно, что идеи, послужившие основанием для разработки этого подхода, во многом очень близки тем идеям, которые послужили Кодду неформальной основой при создании им исходной формальной реляционной модели. Как уже объяснялось в разделе 13.2, общий подход к разработке расширенных моделей включает четыре больших этапа; назначение каждого из них можно кратко сформулировать следующим образом.

1. Идентифицировать полезные семантические концепции.

2. Определить формальные объекты.

3. Определить формальные правила поддержки целостности данных ( метаограничения ).

4. Определить формальные операторы.

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

схожему с ними. Действительно, работы Кодда подтверждают это, поскольку в его первой статье (самой ранней версии работы [5.1]), посвященной реляционной модели, имеются следующие строки.

Множество сущностей заданного типа сущности можно рассматривать как отношение, и такое отношение мы будем называть отнощением типа сущности... Оставшиеся отношения... .между типами сущностей... называются межсущностными отнощениями... Важнейшим свойство.м каждого межсущностного отношения является то, что [оно содержит по крайней мере два внешних кчюча, которые] обращаются к различным типам сущностей либо к общему типу сущности, выполняющему различные роли.

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

В противоположность этому ER-модель не является (или, по крайней мере, не в первую очередь является) формальной моделью. Фактически она состоит из набора преимущественно неформальных концепций, соответствующих тоЛько первому из четырех приведенных выще этапов. (Более того, ее формальные аспекты на самом деле не очень значительно отличаются от соответствующих аспектов основной реляционной модели; обсуждение этого вопроса будет продолжено ниже.) Для проектирования базы данных, конечно, полезно иметь в своем распоряжении, помимо всего прочего, набор концепций, определенных на этапе 1. Однако несомненным остается тот факт, что проектирование базы данных не может быть заверщено без применения формальных объектов и правил, представленных на этапах 2 и 3, а множество других задач и вовсе не может быть реще-но без использования формальных операторов, определяемых на этапе 4. Следует отметить, что перечисленные выще замечания не предполагают доказательства бесполезности ER-модели; скорее всего, наоборот. Однако одной этой модели недостаточно. Более того, несколько странным кажется тот факт, что первые описания неформальной ER-модели были опубликованы спустя несколько лет после опубликования описания фор.мапьной реляционной модели, изначально основанной (как мы видели) на некоторых идеях ER-модели.

Является ли ER-модель моделью данных

Из выщеизложенного не совсем ясно, является ли ER-модель на самом деле моделью данных, по крайней мере в предложенном в этой книге смысле (т.е. формальной системой, включающей структурные аспекты, аспекты поддержания целостности и манипулирования данными). Конечно, термин ER-моделирование обычно используется для обозначения процесса выбора только структуры базы данных, хотя выще, в разделах 13.3-13.5, рассматривались и некоторые аспекты целостности (они, в основ-

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