Chapter 4

The Enhanced Entity-Relationship Model

 Enhanced Entity Relationship (EER) model
• Created to design more accurate database schemas.
• Reflect the data properties and constraints more precisely.
• More complex requirements than traditional applications.
• EER model includes all modeling concepts
of the ER model
• In addition, EER includes:
 Subclasses and super classes
 Specialization and generalization
 Category or union type
Attribute and relationship inheritance
Weak Entity: it is an entity that can be uniquely identified with the help
of other entity. That is, for the entity to be uniquely distinguished some
of its attributes in conjunction with the primary key of another entity
has to be used.
The entity which contributes its primary key is called the identifying or
owner entity set.
• For an entity set to be called a weak entity set the following restrictions
has to hold:
The owner entity set and the weak entity set must participate in a one-
to-many relationship set (one owner entity is associated with one or
more weak entities, but each weak entity has a single owner). This
relationship set is called the identifying relationship or supporting
relationship of the weak entity set.

The weak entity set must have total participation in the identifying
relationship.
• To distinguish weak entities that depend on one particular identifying
entity (strong entity) an attribute or set attributes in the weak entity
set is used. Such an attribute or set of attributes is referred to as
discriminator.

• The key (primary key) of a weak entity set consists of:

1. Zero or more of its own attribute; the discriminator, and
2. Key attributes of the owner (identifying) entity set.
Notation for Weak Entity Set
- Weak Entity sets are represented by Double boarder Rectangles.

- The identifying many-to-one relationship is represented by Double

border Diamonds.

- If the entity set has a discriminator then it is represented by

Underlining the attribute(s).
Example:
- Consider “TEAMS” entity set Teams with the same name can be
formed to work on different projects. Thus neither “Name” nor
“Description” can uniquely identify a “TEAMS” entity. Rather an entity
will be distinguished when it is related to a “PROJECT” entity. Note
that the relationship in between is a many-to-one relationship when it
is seen from the “TEAMS” side.
• The two most common sources of weak entity sets are:
- Inheritance or specialization and generalization, and
- Multi-way relationships that are transformed into binary
relationships through entity sets.

Specialization and Generalization

• Sometimes grouping of entity set in hierarchical structure can be

helpful to show the association between the entities in the real world.
• Specialization is a top-down process in grouping of entities that are
similar in some way and distinct in some other ways in which
distinctions are made explicitly.
• Generalization is a design process of bottom-up approach in which
multiple entity sets are synthesized into a higher level entity set based
on their common features.
• Specialization and generalization in E/R model are represented by a
triangle labeled “ISA” between
the entities. The vertex of the triangle is towards the generalized
(super class) entity set.
Example:

- “FULL-TIME EMPLOYEES” and “PART-TIME EMPLOYEES” can be

generalized to for an entity set “EMPLOYEES”
- “PROJECTS” entity set may be further specialized into “WEB-BASED
PROJECTS” and “WIN32 PROJECTS”
Constraints on Specialization and Generalization

• Condition-defined vs. User-defined Lower-level Entity Sets: -

Members of condition-defined specialized (lower-level) entity sets are
those satisfying an explicit condition or predicate from the higher-
level entity set; whereas, User-defined members are determined upon
the entry of the entities from the user irrespective of any constraint.
Example:

- Consider the “EMPLOYEES” entity set specialization. If there is field

named “Emp Type”, in the higher-level entity set that determines for a
given entity to belong to either of the two lower-level entity sets “FULL-
TIME EMPLOYEES” and “PART-TIME EMPLOYEES”. Then the lower-level
entities are said to be condition-defined.
• Disjoint vs. Overlapping Specialization: - Specialization of a higher-
level entity set to lower entities may be either Disjoint or Overlapping
based on whether the entities may belong to one or more lower-level
entity sets. If the specialization allows for a higher-level entity to
belong to more than one entity then the lower-level entities are said
to be Overlapping otherwise Disjoint.
Example:

- Consider the “PROJECTS” entity set specialization. If a given project is

allowed to have the two flavors “web-based” and “win32” applications
then the lower-level entity sets are said to be Overlapping. However,
the “EMPLOYEES” specialization entities are disjoint, since an employee
can be either full-time or part-time but not both.
• Total vs. Partial Specialization or Generalization: - If each higher-level
entity set in specialization or generalization must belong to one of the
lower-level entity sets then the specialization or generalization is said
to be total, however if it is not a must for the entity to belong
any of the lower-level entity sets it is said to be partial.
Aggregation
One deficiency in E/R modeling is the fact that a relationship is allowed
only between entity sets. But in some cases it may be advantageous to
have a relationship between a relationship and an entity set or a
collection of entity sets.
Example:

Consider the “WorksOn” relationship between “TEAMS” and

“PROJECTS”. From the case study it is to be noted that every project is
to be lead by a senior manager. Hence the manager is responsible for
managing the teams, projects and the outcome of the project, the
software. Therefore the resulting E/R model would be as follows.
• As can be seen from the diagram above redundancy loop is
introduced as the E/R model doesn’t allow a direct association of a
relationship to a relationship.
• An alternative way to avoid the redundancy is with the use of the
aggregation. Aggregation is an abstraction through which collection
of related entity sets and relationships are treated as highlevel
entities. It allows indicating for a relationship set (identified through a
box) to participate in another relationship set.
Example:

• The previous example can be alternatively represented as follows

Object Definition Language (ODL) Data Model

• Object Definition Language (ODL) is an object-oriented approach in a

database design that is standardized by the ODGM (Object Data
Management Group). It is an extension of IDL (Interface Data
Language) a component in the distributed object-oriented computing
standard CORBA (Common Object Request Broker Architecture).
 Overview of Object Oriented Concept

• Some of the basic ideas in object oriented programming are:

Complex Types – Object oriented programming supports rich collection
of complex data types. Typical types that can be constructed in OOP
are: Structures (Records), Reference Types (Pointers) and Collection
Types:

Classes and Objects – Classes are types (molds or templates) for similar
set of objects. And objects are instances of classes. Every object has
(current) state and behavior.
• Example: For a Vehicle class: - Color, Make, Model, Gas are states and
Driving, Parking are behaviors

- Variables represent the state of the object or the class.

- Methods/functions represent the behavior of the object or the class.
- Objects interact with each other through messages that initiate tasks.
Objects Identity – Every object has a unique identity that helps to identify
the object independent of its values.

 Inheritance – Objects can inherit properties, both state and behavior,

from other objects. A class hierarchy (super-class and sub-classes) can be
formed with the help of inheritance.
 ODL Design and Syntax

• Object Definition Language (ODL) is an object oriented approach that

models the real world as a composition of objects. Objects in ODL
model are some how similar to the entities in E/R model. Real world
concepts that are represented by objects of similar description and
behavior are grouped into classes.
• ODL is used to define persistent classes, those whose objects may be
stored permanently in the database. The ODL classes are described by
three properties (elements):
• Attributes – which are values associated with the objects whose types are
from the built in primitive types or a structure of the primitive types.
• Relationships – are connections between the object and another object of
some class.
• Methods – are functions that may be applied to objects of the class.
NOTE: ODL classes look like Entity sets with binary relationships, plus
methods.An ODL class declaration includes:

1. A name for the class.

2. Optional key declaration(s).
3. Extent declaration: - name for the set of currently existing objects of the class.
4. Element declarations: - An element is either an attribute, a relationship, or a
method.
• The simplest form of the class declaration is:
 Attributes in ODL

• Attributes are (usually) elements with a type that does not involve
classes. They can be of simple, enumerated or structured type. The
syntaxes for the three types are as follows, respectively:
• Example:
- Consider the “EMPLOEES” class partial declaration.
 Relationships in ODL

• Syntax for a relationship in ODL is as follows

• Relationship Types in ODL

The word <type> in the relationship declaration of ODL design refers
to the type of relationship and the related class in the statement.
• Example:
- Consider the “EMPLOYEES” class and its relationship to “TEAMS”
class.
• The basic collection types of attributes and relationships in ODL
model are:
1. Set:- Set<T> denotes a relationship to class T with finite number of
association between the objects in the class. It is an unordered set of
association which doesn’t allow repetition.
2. Bag (Multiset):- It is similar to the Set operator which allows
repetition of association to one object.
3. List:- It is an association in which order is material.
4. Array:- Array<T, i> denotes a fixed number of association to objects
in the class T which are indexed.
 Inverse Relationships

• Unlike E/R design the relationships in ODL model are only binary.
Hence for every relationship in class C there is an inverse relationship
in the related class D. Suppose class C has a relationship R to class D,
then class D must have some relationship S to class C. R and S must
then be true inverses. That is; if object d is related to object c by R,
then c must be related to d by S.
• Example:
- Consider the “EMPLOYEES” class and its relationship to “TEAMS”
class.
• Inverse relationship in ODL design is represented by using the
keyword inverse.
 Multiplicity of Relationships

• Multiplicity of relationships in ODL design is indicated by the type

operators in the relationship and the inverse relationship.
Many-to-many relationships: - are indicated by Set<…> for the type of
the relationship and its inverse.
One-to-many relationships: - have Set<…> in the relationship of the
“one” and just the class for the relationship of the “many.”
One-to-one relationships: - have classes as the type in both directions.
• Example:
- In the previous relationship declaration between “EMPLOYEES” class
and the “TEAMS” class there is a many-to-many relationship.
• - Consider the one-to-many relationship between “PROJECTS” and
“CUSTOMERS”
• - Consider the one-to-one relationship between “PROJECTS” and
“SOFTWARE”
 Inheritance in ODL

• Inheritance in ODL is similar to the usual object-oriented inheritance

principle. It indicates a relationship between superclass and
subclasses. Subclass lists only the properties unique to it and it
inherits its superclass’ properties.
Inheritance in ODL design is indicated by the colon operator as
follows.
• Example:
- Consider the “PART-TIME EMPLOYEES” class that is inherited from
“EMPLOYEES” class.
Declaring Keys in ODL

• every object has an object Identifier and keys are attributes that can
identify an object uniquely for the set of objects.
In ODL any number of keys for a class can be declared by adding the
following code after the class name.
• A key consisting of more than one attribute needs additional
parentheses around those attributes.
Example:
• For each class in ODL there is an extent, the set of existing objects of
that class. Extent is the relation with that class as its schema
(definition). It is indicated after the class name, along with keys, as:

• Conventionally, singular nouns are used for class names and plural for
the corresponding extent.
Example: