Enhanced%20Entity-Relationship%20(EER)%20Modeling

1
Chapter 4

• Enhanced Entity-Relationship (EER) Modeling

2
Enhanced Entity-Relationship Model

• Basic concepts of ER modeling are not sufficient
  to represent more complex systems.
• Semantic concepts incorporated into the original
  ER model are called the Enhanced
  Entity-Relationship (EER) model.
• Examples of additional EER concepts are
• subclass / superclass
• specialization / generalization
• Categories (UNION types)
• aggregation

3
Subclasses and Superclasses

• Superclass
• An entity type that includes one or more distinct
  subgroupings of its occurrences.
• Example Employee entity may be further grouped
  into Secretary, Mechanic, Manager, etc.
• Subclass
• A distinct subgrouping of occurrences of an
  entity type.
• Example Secretary is a subclass of Employee

4
Subclasses and Superclasses (2)

• Superclass/subclass relationship is one-to-one
  (11).
• These are called IS-A relationships
• Superclass may contain overlapping or distinct
  subclasses.
• An engineering manager may become member of two
  subclasses Manager and Engineer.
• Not all members of a superclass need be a member
  of a subclass.
• Some employees may be unclassified.

5
Specialization / Generalization

• Attribute Inheritance
• An entity in a subclass may possess
  subclass-specific attributes, as well as those
  associated with the superclass.
• Specialization Top down process of defining a
  set of subclasses of a superclass.
• Identify unique characteristics of each subclass.
• Generalization Bottom up process that is the
  reverse of the specialization process.
• Identify common characteristics of the subclasses.

6
AllStaff relation holding details of all staff
7
Specialization/generalization of Staff entity
into subclasses representing job roles
8
Specialization/generalization of Staff entity
into job roles and contracts of employment
9
EER diagram with shared subclass and subclass
with its own subclass
10
Constraints on Specialization / Generalization

• Two constraints that may apply to a
  specialization/generalization
• participation and disjoint constraints
• Participation constraint
• Determines whether every member in a superclass
  must participate as a member of a subclass.
• May be mandatory or optional.
• Also called total (for mandatory) or partial (for
  optional)
• Disjoint constraint
• Describes whether member of a superclass can be a
  member of one, or more than one, subclass.
• May be disjoint (Or) or nondisjoint (And).

11
Constraints on Specialization / Generalization

• There are four categories of constraints of
  specialization and generalization
• mandatory and disjoint
• optional and disjoint
• mandatory and nondisjoint
• optional and nondisjoint.
• Reasons for using Specialization/Generalization
• To add descriptive attributes specific to a
  subclass
• To identify entities that participate in a
  relationship

12
EER diagram for a Real Estate organization with
specialization/generalization
13
Categories (UNION type)

• A shared subclass is a subclass participating in
  relationships with more than one superclass.
• Shared class may have its own attributes
• This leads to multiple inheritance.
• A member of a shared subclass must be a member of
  the associated superclasses.
• A UNION type is a special shared subclass
• A UNION subclass must exist in at least one of
  its superclasses (not in all).
• Participation is usually optional

14
Aggregation

• It is an abtraction concept.
• Similar to the is-part-of relationship in UML
• Use a box to include its components.
• Used when we have to model a relationship
  involving a relationship type
• Aggregation allows us to treat a relationship
  type as a high level entity for purpose of
  participation in other relationships.

15
Example of Aggregation
Contact_Name Contact_Phone Date
Job_Applicant SSN Name Address Phone
Company Cname Caddress
1
11
Interview
11
Starting_Date Starting_Salary
Results_in
01
Job_Offer Position
16
Example of incorrect design
Job_Applicant SSN Name Address Phone
Company Cname Caddress
11
11
Contact_Name Contact_Phone Date Starting_Date Star
ting_Salary
If an interview does not result in an offer, then
Starting_Date and Starting_Salary are
NULL. Multiplicities are different than those on
previous diagram. May show a wrong interview
instance that is not allowed by the aggregation.
01
Job_Offer Position