Eer L1
Eer L1
RELATIONSHIP MODEL
It’s a high level data model that incorporates extensions to the original
ER model.
It incorporates several concepts that are closely related to the object
oriented design and programming.
EER model consists of all the modelling concepts of ER model + the
concepts of subclass ,super class and concepts of specialization and
generalization.
When these concepts are described in the diagram,it’s called Enhanced
ER diagrams or EER diagrams.
It describes more accurate database schemas.
It reflects the data properties and constraints more precisely.
SUBCLASS ,SUPERCLASS AND INHERITANCE
Subclass of an entity type:Subgroupings of an entity type that are meaningful
and need to be represented explicitly because of their significance to the
database application.
Employee
Engineer Secretary Technician
Shape
Square Circle Triangle
Employee is the superclass and engineer ,secretary,technician are sub classeses.
A member entity of the subclass represents the same real-world entity as the
member of superclass.
The subclass member is the same as the entity in the superclass, but in a
distinct specific role.
An entity cannot exist in the database merely by being a member of a subclass;
it must also be a member of the superclass.
It’s not necessary that every entity in a superclass is a member of some subclass.
The relationship between a superclass and anyone of its subclasses is called a
superclass/subclass or simply class/subclass relationship.
EMPLOYEE/ENGINEER and EMPLOYEE/SECRETARY
EMPLOYEE/TECHNICIAN are class/subclass relationships.
Inheritance :An entity that is a member of a subclass inherits all the attributes
of the entity as a member of the superclass.
The entity also inherits all the relationships in which the superclass
participates.
SPECIALIZATION AND GENERALIZATION
Specialization
Specialization is the process of defining a set of subclasses of an entity type; this
entity type is called the superclass of the specialization.
The set of subclasses that form a specialization is defined on the basis of some
distinguishing characteristic of the entities in the superclass.
Eg:The set of subclasses {ENGINEER,SECRETARY, TECHNICIAN} is a
specialization of the superclass EMPLOYEE that distinguishes among employee
entities based on the job type of each employee entity.
We can have several specializations of the same entity type based on different
distinguishing characteristics.
Eg:Another specialization of the EMPLOYEE entity type gives the set of subclasses
{SALARIED_EMPLOYEE,HOURLY_EMPLOYEE};
This specialization distinguishes among employees based on the method of pay.
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
It’s a reverse process of specialization in which we suppress the differences among
several entity types, identify their common features, and generalize them into a
single super-class of which the original entity types are special subclasses.
Eg:Consider the entity types CAR and TRUCK .
Because they have several common attributes, they can be generalized into the
entity type VEHICLE.
Both CAR and TRUCK are now subclasses of the generalized superclass VEHICLE.
The term generalization to refer to the process of defining a generalized entity type
from the given entity types.
A diagrammatic notation to distinguish between generalization and
specialization is used in some design methodologies.
An arrow pointing to the generalized superclass represents a generalization,
whereas arrows pointing to the specialized subclasses represent a
specialization.
Constraints on Specialization and Generalization
If the specialization consist of a single subclass only, such as the {MANAGER}
specialization ,we do not use the circle notation.
Predicate-defined (or condition-defined) subclasses:
In some specializations we can 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 example, if the EMPLOYEE entity type has an attribute ]obType, as shown
in Figure, we can specify the condition of membership in the SECRETARY
subclass by the condition (JobType = '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 value for ]obType is 'Secretary'
belong to the subclass.
We display a predicate-defined subclass by writing the predicate condition next
to the line that connects the subclass to the specialization circle.
Attribute-defined specialization: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, and the attribute is called the defining
attribute of the specialization.
We display an attribute-defined specialization by placing the defining attribute name
next to the arc from the circle to the superclass, as shown in following Figure .
User Defined Subclass:When there is no condition for determining
membership in a subclass, the subclass is called user-defined.
Membership in such a subclass is determined by the database users when they
apply the operation to add an entity to the subclass; hence, membership is
specified individually for each entity by the user, not by any condition that may
be evaluated automatically.
2 other constraints on specialization are disjointness constraint and completeness
constraint.
Disjointness constraint : This constraint specifies that the subclasses of the
specialization must be disjoint.
This means that an entity can be a member of at most one of the subclasses of the
specialization.
In the EER diagram the d in the circle stands for disjoint.
If the subclasses are not constrained to be disjoint, their sets of entities may overlap;
that is, the same (real-world) entity may be a member of more than one subclass of
the specialization.
This case is displayed by placing an o in the circle.
Completeness constraint can be total or partial.
A total specialization constraint specifies that every entity in the superclass
must be a member of at least one subclass in the specialization.
Eg: Every EMPLOYEE must be either an HOURLY_EMPLOYEE or a
SALARIED_EMPLOYEE, then the specialization {HOURLY_EMPLOYEE,
SALARIED_EMPLOYEE} is a total specialization of EMPLOYEE.
It is shown in EER diagrams by using a double line to connect the superclass to
the circle.
Partial specialization, which allows an entity not to belong to any of the
subclasses.
Eg:If some EMPLOYEE entities do not belong to any of the subclasses
{SECRETARY, ENGINEER, TECHNICIAN} then that specialization is partial.
A single line is used to display a partial specialization.
Specialization and Generalization
Hierarchies and Lattices
A subclass itself may have further subclasses specified on it, forming a
hierarchy or a lattice of specializations.
Eg:In the following Figure ENGINEER is a subclass of EMPLOYEE and is
also a superclass of ENGINEERING_MANAGER; this represents the real-
world constraint that every engineering manager is required to be an engineer.
A specialization hierarchy has the constraint that every subclass participates as
a subclass in only one class/subclass relationship; that is, each subclass has
only one parent, which results in a tree structure.
In contrast, for a specialization lattice, a subclass can be a subclass in more
than one class/subclass relationship. Hence, the following figure is a lattice.
Shared subclass:A subclass with more than one superclass is called a shared
subclass, such as ENGINEERING_MANAGER in the previous figure.
Multiple Inheritance :The shared subclass ENGINEERING_MANAGER
directly inherits attributes and relationships from multiple classes.
The existence of at least one shared subclass leads to a lattice (and hence to
multiple inheritance).
If no shared subclasses existed, we would have a hierarchy rather than a lattice.
An important rule related to multiple inheritance is that if an attribute (or
relationship) originating in the same super class is inherited more than once via
different paths in the lattice, then it should be included only once in the shared
subclass .
Eg:Consider the shared subclass STUDENT_ASSISTANT in the following
figure, which inherits attributes from both EMPLOYEE and STUDENT.
Both EMPLOYEE and STUDENT inherit the same attributes from PERSON.
There fore an attribute (or relationship) originating in the same super class
(PERSON) is inherited more than once via different paths (EMPLOYEE and
STUDENT) in the lattice, then it should be included only once in the shared
subclass (STUDENT_ ASSISTANT).
Hence, the attributes of PERSON are inherited only once in the
STUDENT_ASSISTANT subclass .