Enhanced Entity Relationship Model

• Allows modeling of inheritance

• Can be mapped to relational model much like ER modeling

• There are multiple alternatives for representing inheritance

• Object-relational features may be used instead

Elements of the EER Model

• Includes all elements of the ER Model

• Additionally includes class hierarchy using class / subclass relationships

• Class hierarchies may be the result of a specialization or a generaliza-

tion

• Categories are class hierarchies without common primary key

Class / subclass relationship

• Represents an ”IS-A” relationship

• Members of subclasses represent the same real world entity

• An entity cannot be a member of a subclass without being a member

of its superclass

• A subclass entity possesses all attributes as well as relationships of the

superclass

• Can be modeled similar to 1-to-1 relationships

Specialization and Generalization

• A specialization is set of subclasses that is defined on the basis of a
distinguishing characteristics

• A generalization is defined by generalizing related entities to have one

superclass

1
 • In practice specializations and generalizations can often not be distin-
guished

Representation in an EER diagram

• A specialization (with more than one subclass) is shown as a triangle
• Allows subclasses to have different attributes, e.g.,
– GradStudent may have the attribute graduateStanding (not ap-
plicable to undergraduate)
– UnderGraduateStudent would probably have an attribute for the
level, such as Freshman, Sophomore, Junior, Senior (not distin-
guished for graduate students)
• Also allows subclasses to have different relationships, e.g.,
– A GradStudent may have an adviser (not applicable to undergrad-
uate)

2
Differences with regard to object-oriented programming
• Multiple overlapping specializations can apply to the same entity, e.g.,
A student may be a GradStudent or UnderGradStudent, and in either
case he/she may or may not be an Assistant

Constraints on specializations
Defining predicate
• Sometimes an attribute is used to specify the subclass

• Alternatively, subclass membership may be user-defined

Disjointness constraint
• A specialization is disjoint if each real world entity can belong to one
subclass at most, e.g.,

– A student is either a graduate student or an undergraduate stu-

dent but not both at the same time
– A faculty member at NDSU can be either part-time or full-time
but not both

• If there is a defining predicate, it can be a simple (i.e. single-valued)

attribute

• A specialization is overlapping if each real world entity can belong to

more than one subclass, e.g.,

– A student assistant could be research assistant or teaching assis-

tant or both

• A defining predicate would have to be multivalued

Completeness constraint
• A specialization is mandatory if each real world entity hast to belong
to at least one subclass, e.g.,

3
 – Every student has to be either an undergraduate or a graduate
student (assuming there are no non-degree students)

• A specialization is optional if each real world entity may not belong to

any subclass, e.g.,

– A student does not have to be a student assistant

Mandatory Overlapping Mandatory Disjoint

Optional Overlapping Optional Disjoint

A library has books and wants to save special information for text-
books and for novels. Mandatory or optional specialization?
Optional if we assume that the library has other books, too.

Does a generalization result in a mapping equivalent to a manda-

tory or optional specialization?
For a generalization you take existing classes and generalize them by defining
a superclass, so it is equivalent to modeling it as mandatory: All members
of the superclass exist already as subclass members.

4
Examples
Mandatory Optional
Disjoint Faculty has to be part-time Library books can be
or full-time and nothing else textbooks or novels (assuming
no novel is a textbook)
Overlapping Persons in the NDSU database A conference gives a special
can be students, employees, status to members of some
or alumni (assuming all professional associations
have some relationship to NDSU)

Modeling Alternatives
Assume that there are N subclasses

• N + 1 tables: One table for each subclass plus one table for the super-
class

• N tables: One table for each subclass, which also holds the superclass
attributes

• 1 table: One table that holds all attributes

Solution with subclass and superclass tables (N + 1 ta-

bles)
• The superclass table has the shared attributes and relationships

• Each subclass table have the specific attributes of that subclass

• The primary key of the superclass is not only used as foreign key in the
subclasses, but also as their primary key (as for 1-to-1 relationships)

• Does not require a defining predicate

• Combining the information in superclass and subclasses requires a join,

i.e. slowest of the alternatives

• Space efficiency trade-off: Foreign keys use some space, but the solution
avoids null values

5
 • Preferable when there are many subclass attributes

• Works for all constraint combinations

Student
PK student_id
name
address

Undergrad Grad
PK, FK student_id PK, FK student_id
level grad_standing

Solution with only subclass tables (N tables)

• The subclass tables have both the shared and the specific attributes

• Enforcing a uniqueness of the primary key across all relations requires

use of a constraint specification language (or an extra table that holds
all primary keys)

• Does not require a defining predicate

• Combining all records requires an outer union, which is normally faster

than a join (An outer union keeps all attributes from both relations
and includes null values where necessary)

• Only works for disjoint relations! Otherwise redundancy is introduced

• If the specialization is optional, an additional ”none of the above” table

has to be added

• Very space efficient (when relations are disjoint)

6
 UndergradStudent GradStudent
PK student_id PK student_id
name name
address address
level grad_standing

Solution with a single table

• One table with all attributes

• No need for joins or unions, hence typically fastest

• Problem: Potentially many null values

• Space-tradeoff: No need for foreign keys, but null values use space

• Preferable when there are few subclass attributes

• One defining attribute sufficient for disjoint subclasses

• N binary defining attributes needed for overlapping subclasses

Student
PK student_id
name
address
is_grad
level
grad_standing

7
Category
• So far we only had a shared subclass of classes that originated from a
single superclass

• Now we look at shared subclasses of superclasses that correspond to

distinct entity types

• Example: If not every Company and Person is an AccountHolder there

is no shared key

• ⇒ We have to introduce a surrogate key