Enhanced Entity

1
Relationship Model
IS311 Enterprise Systems
Divine Word University
2 Outcomes

 Discuss EER concepts & mapping techniques

 Create subtypes and specialisations
 Create supertypes and generalisations
 Create EER data models
3 Enhanced Entity Relationship
(EER) Model
 ER modeling concepts are sufficient for representing
many database schemas for traditional database
applications
 Enhanced ER (EER) model was created to design
more accurate database schemas
 Reflect data properties and constraints more precisely
 Databases for engineering design and manufacturing
(CAD/CAM), telecommunications, complex software
systems, and geographic information systems (GIS)
 More complex requirements than traditional applications
4 Subtypes, Supertypes, and
Inheritance
 EER model includes all ER modeling concepts
 Plus concepts of:
 subclasses/subtypes & superclasses/supertypes
 specialisation and generalisation
 category or union type which is used to represent a
collection of objects (entities) that is the union of objects
of different entity types.
 attribute and relationship inheritance
5 Subtype/subclass of an
entity type
 Entity type is used to represent both:
 type of entity
 entity set or collection of entities of that type that exist in
the database.
 For example, entity type EMPLOYEE describes:
 the type (that is, the attributes and relationships) of each
employee entity, and
 refers to the current set of EMPLOYEE entities in a
COMPANY database.
6 Subtypes, Supertypes &
Inheritance
 An entity type can have subgroupings of its entities
that need to be represented explicitly
 A subgroup is a subset of entities that belong to an
entity set of an entity type
 An entity type is called supertype or superclass
 A subgroup is called subtype or subclass
7 Example

 Member entities of the EMPLOYEE entity type

(supertype/superclass) may be grouped into subtypes
 SECRETARY
 ENGINEER
 MANAGER,
 TECHNICIAN
 SALARIED_EMPLOYEE
 HOURLY_EMPLOYEE
 Every member entity of a subtype is also an entity of
the supertype
 An entity of SECRETARY is also an entity of EMPLOYEE
8 Subtypes, Supertypes &
Inheritance (cont’d.)
 Relationship between a supertype and any of its
subtypes is called a supertype/subtype relationship
 EMPLOYEE/SECRETARY is supertype/subtype relationships
 A member entity of a subtype represents the same
real-world entity as some member of the supertype
 SECRETARY entity ‘Mary Peters’ is also the EMPLOYEE
‘Mary Peters’
 Subtype member is the same as the entity in the
supertype, but in a distinct specific role.
9 Subtypes, Supertypes &
Inheritance (cont’d.)
 An entity cannot exist in the database merely by
being a member of a subtype
 It must also be a member of the supertype
 A member of a supertype can be included optionally
as a member of any number of subtypes
 For example, a salaried employee who is also an
engineer belongs to the two subtypes ENGINEER and
SALARIED_EMPLOYEE of the EMPLOYEE entity type
 Note: it is not necessary that every entity in a
supertype is a member of some subtype.
10 Type Inheritance
 Type of an entity is defined by:
 attributes it possesses
 relationship types in which it participates
 Entity in the subtype represents the same real-world entity
from the supertype, it should possess:
 values for its specific attributes
 values of its attributes as a member of the supertype
 Entity that is a member of a subtype inherits all:
 attributes of the entity as a member of the supertype
 relationships in which the supertype participates.
 Subtype, with its own specific (local) attributes and
relationships together with all the attributes and
relationships it inherits from the supertype, can be
considered an entity type in its own right.
11 EER notation to represent
subtypes

Source: Elmasri, R., & Navathe, B.S. (2007)

12 Another notation

Source: Hoffer, A.J., Prescott, M.B., & McFadden, F.R. (2007)

13 Another example

Source: Hoffer, A.J., Prescott, M.B., & McFadden, F.R. (2007)

14 Specialisation

 Process of defining a set of subtypes of an entity type

 An entity type is called the supertype of the specialisation
 Set of subtypes that forms a specialisation is defined based on
some distinguishing characteristic of entities in supertype.
 E.g. set of subtypes {SECRETARY, ENGINEER, TECHNICIAN} is a
specialisation of the supertype EMPLOYEE that distinguishes
among employee entities based on the ‘job type’ of each
employee entity.
 There can be several specialisations of the same entity type
based on different distinguishing characteristics.
 E.g. another specialisation of EMPLOYEE entity type may have set
of subtypes {SALARIED_EMPLOYEE,HOURLY_EMPLOYEE}; based on
the ‘method of pay’.
15 Specialisation

 Figure 8.1 shows how we represent specialisation in an

EER diagram.
 Subtypes that define a specialisation are attached by
lines to a circle that represents the specialisation,
which is connected in turn to the supertypes.
 Subset symbol on each line connecting subtype to
circle indicates the direction of the supertype/subtype
relationship.
16 Another example

Source: Hoffer, A.J., Prescott, M.B., & McFadden, F.R. (2007)

17 Specific
attributes/relationship types
 Attributes that apply only to entities of a particular
subtype – such as TypingSpeed of SECRETARY – are
attached to the rectangle representing that subtype.
 Called specific attributes (or local attributes) of the
subtype.
 Subtype can participate in specific relationship types
 E.g. HOURLY_EMPLOYEE subtype participating in the
BELONGS_TO relationship
18 Instances of Specialisation

Source: Elmasri, R., & Navathe, B.S. (2007)

19 Instances of Specialisation

 Figure 8.2 shows few entity instances that belong to

subtypes of {SECRETARY, ENGINEER, TECHNICIAN}
 Entity that belongs to subtype represents the same real-
world entity as entity connected to it in the EMPLOYEE
supertype
 E.g. e1 is shown in both EMPLOYEE and SECRETARY
 Supertype/subtype relationship such as the EMPLOYEE
/SECRETARY resembles 1:1 relationship at instance level
 In 1:1 relationship two distinct entities are related
 In supertype/subtype relationship, entity in subtype is same
real-world entity as entity in the supertype but is playing a
specialised role
 E.g. EMPLOYEE specialised in the role of SECRETARY or an
EMPLOYEE specialised in the role of TECHNICIAN.
20 Reasons for supertype/subtype
relationships
 Certain attributes may apply to some but not all entities of
supertype
 Subtype is defined in order to group the entities to which these
attributes apply.
 Members of the subtype may still share the majority of their
attributes with the other members of the supertype.
 E.g. SECRETARY subtype has specific attribute Typing_speed,
whereas ENGINEER subtype has specific attribute Eng_type, but
SECRETARY and ENGINEER share their other inherited attributes
from the EMPLOYEE entity type.
 Some relationship types may be participated in only by entities
that are members of the subtype
 E.g. if only HOURLY_EMPLOYEES can belong to a trade union, we
represent that fact by creating the subtype HOURLY_EMPLOYEE
of EMPLOYEE and relating the subtype to an entity type
TRADE_UNION via the BELONGS_TO relationship type.
21 Generalisation

 Process of defining a generalised entity type from given

entity types based on common features
 Original entity types are called subtypes
 E.g. CAR and TRUCK in Figure 8.3(a) have several
common attributes and can be generalised into the
entity type VEHICLE, as shown in Figure 8.3(b).
 CAR and TRUCK are subtypes and VEHICLE is a supertype
 {CAR, TRUCK} is a specialisation of VEHICLE
 VEHICLE is a generalisation of CAR and TRUCK
 Similarly, EMPLOYEE is a generalisation of SECRETARY,
TECHNICIAN, and ENGINEER.
22 Generalisation

Source: Elmasri, R., & Navathe, B.S. (2007)

23 Another example

 Source: Hoffer, A.J., Prescott, M.B., & McFadden, F.R. (2007)

24 Constraints of Specialisation and
Generalisation

 Several specialisations may be defined on the same

entity type (or supertype)
 In such cases, entities may belong to subtypes in each of
the specialisations.
 Specialisation may also consist of a single subtype
only, such as the {MANAGER} specialisation
 In such a case, we do not use the circle notation.
25 Constraints of Specialisation
and Generalisation
 We can determine entities that will become members of each
subtype by placing a condition on the value of some attribute of
the supertype
 Such subtypes are called predicate-defined (or condition-
defined) subtypes
 E.g. if EMPLOYEE entity type has an attribute Job_type, we can
specify the condition of membership in the SECRETARY subtype
by the condition (Job_type = ‘Secretary’), which we call the
defining predicate of the subtype
 This condition is a constraint specifying that exactly those entities
of the EMPLOYEE entity type whose attribute value for Job_type is
‘Secretary’ belong to the subtype
 We display a predicate-defined subtype by writing the predicate
condition next to the line that connects the subtype to the
specialisation circle.
26 Constraints of Specialisation
and Generalisation
 If all subtypes in a specialisation have their
membership condition on the same attribute of the
supertype:
 specialisation is called an attribute-defined specialisation
 attribute is called defining attribute of the specialisation
 All the entities with the same value for the attribute
belong to the same subtype
 We display an attribute-defined specialisation by
placing the defining attribute name next to the arc
from the circle to the supertype
28 EER for attributed-defined
specialisation

Source: Elmasri, R., & Navathe, B.S. (2007)

29 Disjointness constraint of
Specialisation and
Generalisation
 Disjointness (or disjointedness) constraint specifies that
subtypes of the specialisation must be disjoint
 Entity can be a member of at most one of the subtypes of
the specialisation
 Specialisation that is attribute-defined implies the
disjointness constraint
 if attribute used to define the membership predicate is single-
valued
 Figure 8.4 illustrates this case, where the d in the circle
stands for disjoint.
 The d notation also applies to user-defined subtypes of a
specialisation that must be disjoint
 Illustrated by specialisation {HOURLY_EMPLOYEE,
SALARIED_EMPLOYEE} in Figure 8.1.
30 Overlapping

 If subclasses are not constrained to be disjoint, their

sets of entities may be overlapping
 Same (real-world) entity may be a member of more than
one subtype of the specialisation
 This is displayed by placing an o in the circle, as shown
in Figure 8.5.
31 Overlapping

Source: Elmasri, R., & Navathe, B.S. (2007)

32 Completeness constraints of
Specialisation and
Generalisation
 Completeness (or totalness) constraint may be total or
partial.
 Total specialisation constraint specifies that every
entity in the supertype must be a member of at least
one subtype in the specialisation
 E.g. if every EMPLOYEE must be either an
HOURLY_EMPLOYEE or a SALARIED_EMPLOYEE, then
the specialization {HOURLY_EMPLOYEE,
SALARIED_EMPLOYEE} is total specialisation of
EMPLOYEE.
 Shown by using a double or thick line to connect the
supertype to the circle
33 Completeness constraints of
Specialisation and
Generalisation
 Partial specialisation constraint specifies that not every
entity in the supertype must be a member of a
subtype in the specialisation
 Single line is used to display partial specialisation
 which allows an entity not to belong to any of the
subtypes.
 E.g. if some EMPLOYEE entities do not belong to any of
the subclasses {SECRETARY, ENGINEER, TECHNICIAN}
then that specialisation is partial.
34 Possible constraints on
specialisation
 Disjointness and completeness constraints are
independent.
 Four possible constraints on specialisation:
 Disjoint, total
 Disjoint, partial
 Overlapping, total
 Overlapping, partial
35 Summary

 Subtypes and supertypes

 Supertype/subtype relationship
 Specialisation and generalisation
 Specific attribute and a specific relationship
 User-defined and predicate-defined subtypes
 User-defined and attribute-defined specialisations
 Constraints on specialisations and generalisations.
36 To Do

 Read sections 8.1 – 8.3

 Tutorial 1
37 Next

 EER to Relational Mapping

 How to map an EER diagram to a relational database
schema