Chapter 4

The Enhanced ER model (EER)

 Introduction
 The databases as CAD/CAM, telecommunications, complex
software systems, GIS (global information system), etc.. have
more complex requirements.
 This lead to the development of additional semantic data modeling
concepts that were incorporated into conceptual data models such
as the ER model.
 The ER model can be enhanced to include the features that have
been proposed for semantic data models, leading to the enhanced
ER (EER) model.
 Cont’d

 The EER model includes all the modeling concepts of the ER

model.
 In addition, it includes the concepts of subclass & super class and
the related concepts of specialization & generalization and also
includes some object-oriented concepts, such as inheritance.
 The diagrammatic technique for displaying these concepts in
EER schema is called Enhanced ER ,EER Diagrams or Extended
ER Diagrams.
Subclasses, Super classes & Inheritance
 Cont’d
 In ER modeling, an entity type is used to represent both a type of
entity and the entity set (collection of entities of that type) that exists
in the database.
 In many cases, An entity type may have additional meaningful
subgroupings of its entities.
 And it needs to be represented explicitly because of their significance
for database application.
 Cont’d
Example: EMPLOYEE may be further grouped into:
 SECRETARY, ENGINEER, TECHNICIAN (Based on the EMPLOYEE’s Job)

 MANAGER ( based on the role they play)

 SALARIED_ EMPLOYEE and HOURLY_EMPLOYEE (based on method of pay)

 Every entity that is a member of these sub groupings is also an

employee.
 These sub groupings are called as a subclass of the EMPLOYEE entity
type and the EMPLOYEE entity type is called the superclass for each
of these subclasses.
 superclass also called parent or base class, it is a class from which
many subclass can be created.
 The figure below shows how these concepts are diagrammatically
represented in EER diagrams.
 Cont’d
 The relationship between a superclass and any one of its subclasses is
called as a class/subclass relationships or IS-A relationships.
 It is said that SECRETARY is an EMPLOYEE, a TECHNICIAN is an
EMPLOYEE, etc…….
 A member entity of the subclass represents the same real world entity as
some member of the superclass.
 For eg: a SECRETARY entity, say ‘Mary Smith’ is also the
EMPLOYEE ‘Mary Smith’.
 Hence the subclass member is the same as the entity in the super class,
but in a distinct specific role.
 Cont’d
 An entity cannot exist in the database merely by being a member of a subclass;

it must also be a member of the superclass.

 Such an entity can be included optionally as a member any number of

subclasses.
 For eg: a salaried employee who is an engineer belongs to the two subclasses

ENGINEER and SALARIED_EMPLOYEE of the EMPLOYEE entity type.

 A salaried employee who is also an engineering manager belongs to the three

subclasses: MANAGER, ENGINEER, and SALARIED_EMPLOYEE

 However, it is not necessary that every entity in a superclass should be a

member of some subclasses.

 Attribute Inheritance in Superclass / Subclass Relationships

 An important concept associated with subclasses is that of type inheritance.

 Since, an entity in the subclass represents the same real-world entity from the
superclass, it should possess values for its specific attributes.
 An entity that is a member of a subclass inherits all the attributes of the
entity as the member of the superclass.
 Also, it inherits all the relationships in which the superclass participates.

 Example: In the previous slide, SECRETARY (as well as TECHNICIAN and

ENGINEER) inherit the attributes Name, SSN, …, from EMPLOYEE
Specialization & Generalization
 Specialization
 Specialization is the process of defining a set of subclasses of an entity

type or superclass.
 The set of subclasses that forms a specialization is defined on the basis

of some distinguishing characteristics.

 It uses Top to Bottom approach.
 Example 1: the set of subclasses { SECRETARY, ENGINEER, TECHNICIAN} is a

specialization of the superclass EMPLOYEE that distinguishes among employee

entities based on the job_type of each employee entity.
 There can have several specializations of the same entity type, based on different

distinguishing characteristics.

 Example2: MANAGER is a specialization of EMPLOYEE based on the role the

 Cont’d
 Example3: the subclasses {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE} is a

specialization of the superclass EMPLOYEE entity type based on the method of pay.

 Superclass/subclass relationships and specialization can be

diagrammatically represented in EER diagrams.
 Attributes of a subclass are called specific or local attributes.
For example, the attribute Typing Speed of SECRETARY
 The subclass can also participate in specific relationship types.
– For example, a relationship BELONGS_TO of HOURLY_EMPLOYEE
 The subclasses that define a specialization are attached by lines to a circle that
represents the specialization , which is connected to the super class.
 Example 1: the set of subclasses { SECRETARY, ENGINEER, TECHNICIAN} is a
specialization of the superclass EMPLOYEE that distinguishes among employee
entities based on the job_type of each employee entity.
 Cont’d
 The attributes that apply only to entities of a particular
subclass are called specific attributes or local attributes.
 Similarly, a subclass can participate in specific relationship
types also .
 In summary, the specialization process allows us to do the
following
 Define a set of subclasses of an entity type

 Establish additional specific attributes with each subclass

 Establish additional specific relationship types between
each subclass and other entity types or other subclasses.
 Generalization

 Generalization is the reverse of the specialization process. (Bottom to Top ).

 Several classes with common features are generalized into a superclass. Or

extract common properties from set of entities and create a generalized entity
from it.
Example: CAR, TRUCK generalized into VEHICLE;
– both CAR, TRUCK become subclasses of the superclass VEHICLE.
– We can view {CAR, TRUCK} as a specialization of VEHICLE
– Alternatively, we can view VEHICLE as a generalization of CAR and
TRUCK
  Since both the entity types are having several common attributes, they
can be generalized into the entity type VEHICLE, as shown in below
diagram.

Both CAR and TRUCK entities are now subclasses of the generalized superclass
VEHICLE.
 Notice that generalization process can be viewed as being
functionally the inverse of the specialization process.
 Hence, in the above figure, it can be viewed {CAR, TRUCK} as a
specialization of VEHICLE, rather than viewing VEHICLE as a
generalization of CAR and TRUCK.
 Similarly, from the previous example, EMPLOYEE can be viewed
as a generalization of SECRETARY, TECHNICIAN and
ENGINEER.
 A diagrammatic notation (normally an arrow)to distinguish
between generalization and specialization is used in some design
methodologies, but the decision as to which process more
 Constraints on Specialization & Generalization

 Basic constraints can apply to a specialization/ generalization:

– Membership constraints:(user defined and attribute defined)

– Disjointness Constraint: (disjoint and overlap)
– Completeness Constraint: (total and partial)
 Membership constraints
 In general, there may have several specialization defined on the
same entity type (or super class) as shown in the diagram below.
 Predicate-defined ( or condition-defined) : based on some predicate.
E.g., based on value of an attribute, payment, Job-type, or Age.
 Attribute-defined: shows the name of the attribute next to the line
drawn from the superclass toward the subclasses (see Fig. 4.1)
 User-defined: membership is defined by the user on an entity by
entity basis
Cont’d
 Cont’d
 However, a specialization may also consist of a single subclass only,
such as the {MANAGER} specialization in the figure above.
 In such situations, the circle notation will not be used (refer the
diagram above).
 In some specialization, it is possible to determine exactly the entities
that will become members of each subclass by placing a condition
on the value of some attribute of the superclass.
 Such subclasses are called predicate-defined (or condition-
defined) subclasses. For eg: consider the following diagram.
Cont’d
 The EMPLOYEE entity type has an attribute Job_type.
 We can specify the membership in the SECRETARY subclass, by the
condition (Job_type= ‘Secretary’), which we call the defining
predicate of the subclass.
 This condition is a constraint specifying that, exactly those entities
of the EMPLOYEE entity type, whose attribute values for Job_type
is ‘Secretary’, belong to the subclass SECRETARY.
 A predicate_defined subclass is displayed by writing the predicate
condition next to the line that connects the subclass to the
specialization circle.
 If all subclasses in a specialization have their membership
condition on the same attribute of the superclass, the specialization
itself is called an attribute_defined specialization.
 Example: JobType is the defining attribute of the specialization
{SECRETARY, TECHNICIAN, ENGINEER} of EMPLOYEE.
 When there is no condition for determining membership in a
subclass, the subclass is called user_defined subclass.
 Disjointness constraint
 Disjoint constraint, which specifies that the subclass of the
specialization must be disjoint.
 This means that an entity can be a member of atmost one of the
subclasses of the specialization.
 A specialization that is attribute_defined implies the disjointness
constraint if the attribute used to define the membership predicate is
single-valued.
 This case is represented as d enclosed in a circle (refer the above
diagram).
 The same notation is also used to specify the constraint that
user_defined subclasses of a specialization, which must be disjoint.
 Cont’d

 If the subclasses are not constrained to be disjoint, their sets of

entities may overlap; i.e, the same entity may be a member of
more than one subclass of the specialization.
 If not disjoint, specialization is overlapping:
 This case is displayed by placing a o in the circle as shown in the
below diagram.
Cont’d
 Completeness constraint

 The other constraint on specialization is called the completeness constraint, which

may be total or partial.

 A total specialization constraint specifies that every entity in the super class must be

a member of at least one subclass in the specialization.

 For eg: if every EMPLOYEE must be either an HOURLY_EMPLOYEE or a

SALARIED_EMPLOYEE, then the specialization {HOURLY_EMPLOYEE,

SALARIED_EMPLOYEE} of the below given figure is a total specialization of EMPLOYEE.

 This is shown in EER diagrams by double line to connect the super class to the circle.

 A single line is used to display a partial specialization, which shows an entity may

not belong to any of the subclasses.

 For eg: if some EMPLOYEE entities do not belong to any of the subclasses {SECRETARY,

ENGINEER, TECHNICIAN} of the following figure, then that specialization is partial.

Cont’d
 Notice that disjointness and completeness constraints are
independent.
 Hence, we have the following four possible constraints on
specialization.
 Disjoint, total

 Disjoint, partial
 Overlapping, total
 Overlapping, partial
Example of disjoint partial Specialization
Example of overlapping total Specialization
 Certain insertion and deletion rules apply to specialization (and
generalization) as a consequence of the constraints specified earlier.
 Some of the rules are as follows;

 Deleting an entity from a super class implies that it is

automatically deleted from all the subclasses to which it belongs.
 Inserting an entity in a super class implies that the entity is
mandatorily inserted in all predicate_defined (or attribute_defined)
subclasses for which the entity satisfies the defining predicate.
 Inserting an entity in a super class of a total specialization implies
that the entity is mandatorily inserted in atleast one of the
subclasses of the specialization.
Thank You!!!!