4. Eer-модель

Рассмотренных выше понятия ER-моделирования вполне достаточно для пред­ставления большинства схем баз данных в традиционных административно-управленческих приложениях. Однако, начиная с 80-х годов, стали быстро распро­страняться многие новые типы приложений баз данных — например, инструменты автоматизированного проектирования (Computer Aided Design — CAD), инструменты автоматизированной подготовки производства (Computer Aided Manufacturing — САМ), инструменты автоматизированного проектирования и создания программ (Computer Aided Software Engineering — CASE), мультимедийные приложения. Эти типы приложений предъявляют к базам данным более строгие требования, чем тра­диционные административно-управленческие приложения. Поэтому основных понятия ER-моделирования оказалось недостаточно для удовлетворения новых требова­ний, выдвигаемых все более усложнявшимися приложениями. Подобная ситуация стимулировала разработку дополнительных концепций семантического моделирова­ния. Предлагались разные семантические модели данных, причем некоторые из них были успешно включены в исходную ER-модель. Такая ER-модель, дополненная но­выми семантическими концепциями, получила название расширенной ER-модели (или EER-модели (Enhanced ER)).

EER-модель включает все концепции ER-модели плюс дополнительные концепции специализации/генерализацииикатегоризации. В этом разделе описываются эти но­вые понятия, а также иллюстрируется способы их представления в EER-моделях.

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

4.1. Суперклассы и подклассы типов сущностей

Как уже обсуждалось в предыдущем разделе, тип сущности — это множество сущностей-одного типа, например Staff, Branch или Property for Rent.

Суперкласс:тип сущности, включающий разные подклассы, которые необходи­мо представить в модели данных.

Подкласс:подкласс является типом сущности, который исполняет отдельную роль, а также является членом суперкласса.

В некоторых случаях тип сущности может иметь несколько разных подклассов. Например, для типа сущности Staff отдельные экземпляры этой сущности можно классифицировать как подтипы Manager, Secretary и Sales Personnel. Иначе говоря, сущность Staff можно рассматривать как суперкласс для подклассов Manager, Secre­tary и Sales Personnel. Связь между суперклассом и любым его подклассом называет­ся связью "суперкласс/подкласс". Например, связь Staff/Manager является связью типа "суперкласс/подкласс".

Каждый член подкласса является членом суперкласса. Другими словами, член под­класса является сущностью суперкласса и в то же время играет собственную отдельную роль. Связь между суперклассом и подклассом относится к типу "один к одному" (1:1). Некоторые суперклассы могут содержать перекрывающиеся подклассы. Например, со­трудник может быть одновременно менеджером (Manager) и торговым агентом (Sales Personnel). В этом примере подклассы Manager и Sales Personnel являются пере­крывающимися подклассами суперкласса Staff. Однако не каждый член суперкласса обязательно должен быть членом какого-либо подкласса — например, это могут быть рядовые сотрудники, не играющие какой-либо особой роли в организации.

Суперклассы и подклассы могут использоваться с целью исключения описания раз­личных типов персонала с (возможно) разными атрибутами внутри одной сущности. Например, торговые агенты (Sales_Personnel) могут иметь особые атрибуты Car Allowance (Компенсация транспортных расходов). Sales Area (Район сбыта) и т.д. Если все атрибуты сотрудников и особые атрибуты для выполнения отдельных работ будут описаны в одной сущности Staff, то это может привести к появлению большого количества неопределенных значений (NULL) атрибутов, описывающих отдельные виды работ. Очевидно, что подкласс Sales Personnel имеет указанные общие атрибуты со све­дениями о других сотрудниках — например, таких как Staff No, Name, Address и DOB. Однако именно не используемые совместно атрибуты могут вызывать проблемы при представлении сведений обо всех сотрудниках с помощью одной сущности. Можно также показать связи, которые имеются только для отдельных групп работников (подклассов), но не для всех сотрудников в целом. Так, подкласс Sales_Personnel может иметь отдельные связи, которые не подходят для всех сотрудников, например связь Requires(Требует) между сущностями Sales_Personnel и Car (Автомобиль).

Существует две причины введения понятий суперклассов и подклассов в ER-модель. Во-первых, это позволяет избежать повторного описания сходных понятий, что сэкономит время проектировщика и повысит читабельность ER-диаграмм. Во-вторых, при проектировании в базы данных включается больше семантической ин­формации в форме, более привычной для многих людей. Например, в утверждениях "менеджер ЯВЛЯЕТСЯ сотрудником" и "квартира ЯВЛЯЕТСЯ типом собственности" в очень краткой форме содержится значительная семантическая информация.