Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Коннолли Т. -> "Базы данных. Проектирование, реализация и сопровождение. Теория и практика" -> 198

Базы данных. Проектирование, реализация и сопровождение. Теория и практика - Коннолли Т.

Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика — М.: Вильямc, 2003. — 1440 c.
ISBN 5-8459-0527-3
Скачать (прямая ссылка): bazidannihpproekt2003.djv
Предыдущая << 1 .. 192 193 194 195 196 197 < 198 > 199 200 201 202 203 204 .. 683 >> Следующая


12.1.2 Связи суперкласс/подкласс

Каждый элемент подкласса является также элементом суперкласса. Иными словами, сущность, которая относится к подклассу, является той же сущностью, которая относится и к суперклассу, но выполняет в суперклассе и подклассе разные роли. Связь между суперклассом и подклассом является связью "один к одному" (1:1) и называется связью суперкласс/под клас<-(сж. раздел 11.6.1). Некоторые суперклассы могут содержать перекрывающиеся подклассы; это можно показать на примере сотрудника компании, который одновременно является и менеджером, и одним из торговых работников, В данном примере Manager и SalesPersonnel представляют собой перекрывающиеся подклассы суперкласса Staff С другой стороны, не каждый элемент суперкласса должен быть элементом одного из подклассов; например, в компании могут быть сотрудники, не имеющие такой конкретной должности, как менеджер или торговый работник.

Суперклассы и подклассы могут применяться для того, чтобы в процессе разработки не приходилось описывать разные типы сотрудников компании, которые могут характеризоваться различными атрибутами в пределах одной сущности. Например, торговый работник может характеризоваться такими специальными атрибутами, как salesArea (торговый отдел) и сагЛ Iowance (транспортные расходы). Если бы в одной сущности Staff были представлены атрибуты, не только присущие всем сотрудникам, но и характерные для конкретной должности, то это могло привести к появлению большого количества незаполненных атрибутов, относящихся только к определенной должности. Безусловно, что торговые работники имеют общие атрибуты с другими сотрудниками компании, такие как staffNo (табельный номер), HclvIt (фамилия и имя), рс ait on (должность) и salary (l ірплаї ¦)• Тем не менее они имеют также индивидуальные атрибуты, поэтому попытка представить эти атрибуты в одной сущности наряду с другими индивидуальными атрибутами прочих сотрудников компании может вызвать проблемы. К тому же, используя индивидуальные атрибуты, можно показать связи, которые относятся только к конкретным категориям персонала (подклассам), а не ко всему персоналу в целом. Например, если торговым работникам при выполнении их обязанностей разрешено пользоваться автомобилем за счет компании, а другим сотрудникам компании — нет, то для них может быть предусмотрена отдельная связь, такая как SalesPersonnel Uses Саг (Торговый работник использует автомобиль).

В качестве иллюстрации этих соображений рассмотрим отношение AllStaff (Весь персонал), показанное на рис. 12.1. Это отношение содержит сведения обо всех сотрудниках компании, независимо от занимаемой должности. Результатом того, что сведения обо всем персонале хранятся в одном отношении (в одной таблице базы данных), становится следствие, что атрибуты, всегда характерные для всего персонала (а именно: staffNo, name, position и salary), всегда заполнены, а те атрибуты, которые относятся только к определенным производственным функциям, заполнены только частично. Например, в таблице хранятся значения атрибутов, связанных с должностью Manager (гг.згг. artDate (дата вступления в должность) и bonus (премия)), SalesPersonnel (salesArea и carAllowance) и Secretary (typingSpeed (скорость печати)), только в тех строках, которые относятся к элементам соответствующих подклассов. Иными словами, атрибуты, ха-

Гпава 12. Расширенная модель "сущность-связь"

431 рактерные для подклассов Manager, SaiesPersonnel и Secretaiy, не заполнены у тех сотрудников компании, которые не принадлежат к этим подклассам.

Итак, концепции суперклассов и подклассов могут быть введены в F.R-модель по двум основным причинам. Во-первых, они позволяют не описывать несколько раз аналогичные сущности, благодаря чему экономится время проектировщика, а ER-диаграммы становятся болие удобными для восприятия. Во-вторых, они позволяют ввести в проект больший объем семантической информации в форме, знакомой для широкого круга пользователей. Например, утверждения, что "Менеджер IS-A (является) сотрудником компании" и "Квартира IS-A (являетеJfi одним из типов объектов недвижимости", позволяют сообщить важную семантическую информацию в краткой форме.

12.1.3. Наследование атрибутов

Как указано выше, сущность, которая относится к подклассу, представляет гот же объект "реального мира", если рассматривается в составе суперкласса, и может обладать не только атрибутами, характерными для подкласса, но и атрибутами, присущими суперклассу. Например, представитель подкласса SalesPersonnel наследует все атрибуты суперкласса staff (такие как staffNo, name, position и salary), а также обладает атрибутами, характерными только для подкласса SalesPersonnel (такими как salesArea и carAllowance).

Подкласс, как таковой, также является сущностью и поэтому может, в свою очередь, ьключачь один или несколько подклассов. Сущность вместе с ее подклассами, подклассами своих подклассов и т.д. составляет так называемую иерархию типов. Иерархии типов иэгестны под разными именами; в 1 астности, для их обозначения используются термины иерархия уточнения (например, понятие Manager является уточніши» м понятия Staff), иерархия обобщения (например, понятие Staff является обобщением понятия Manager) и иерархии ISA (например, Manager IS-A (является представителем) Staff). Процесс уточнения и обобщения рассматривается в следующих разделах.
Предыдущая << 1 .. 192 193 194 195 196 197 < 198 > 199 200 201 202 203 204 .. 683 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100