1. Chapter 13 Enhanced Entity-Relationship Modeling
Ahmed M. Zeki
ITIS 216
ITBIS 385

2. Objectives
Limitations of basic concepts of the ER model and requirements to represent more complex applications using additional data modeling concepts.
Most useful additional data modeling concept of Enhanced ER (EER) model is called specialization/generalization.
A diagrammatic technique for displaying specialization/generalization in an EER diagram using UML.
/ 45

3. Enhanced ER Model
ER model is adequate for building data models of traditional administrative DB systems
Stock control
Product ordering
Customer invoicing
Since 1980s there has been an increase in emergence of new DB applications with more demanding requirements.
/ 45

4. Examples of such applications:
Computer Aided Design (CAD)
Computer Aided Manufacturing (CAM)
Computer Aided Software Engineering (CASE) tools
Office Information Systems (OIS)
Multimedia Systems Digital Publishing
Geographical Information Systems (GIS)
Basic concepts of ER modeling are not sufficient to represent requirements of newer, more complex applications.
 Development of additional ‘semantic’ modeling concepts.
/ 45

5. Specialization/Generalization
Associated with special types of entities knows as :
Superclass: an entity type that includes one or more distinct sub-groupings of its occurrences, which require to be represented in a data model
Subclass: a distinct subgrouping of occurrences of an entity type, which require to be represented in a data model
/ 45

6. Ex: entities that are members of the Staff entity type may be classified as
Manager
SalesPersonnel
Secretary
The relationship between a superclass and any one of its sublacsses is called a superclass/subclass relationship
Ex: Staff/Manager
/ 45

7. Each member of a subclass is also a member of the superclass.
i.e. the entity in the subclass is the same entity in the superclass
Superclass/subclass relationship is one-to- one (1:1).
Superclasses may contain overlapping or distinct subclasses.
A member of staff who is both a manager and a member of SalesPersonnel.
 we say that Manager and SalesPersonnel are overlapping subclasses of the Staff superclass.
/ 45

8. Not all members of a superclass need be a member of a subclass
Ex: members of staff without a distinct job role such as a Manager or a member of SalesPersonnel
We use superclasses and subclasses to avoid describing different types of staff with possible different attributes within a single entity.
Ex: SalesPersonnel may have special attributes such as salesArea and carAllowence
/ 45

9. If all staff attributes and those specific to particular jobs are described by a single staff entity, this may result in a lot of nulls for the job-specific attributes.
Partially filled.
Many Nulls
/ 45

10. Clearly SalesPersonnel have common attributes with other staff, such as staffNo, name, position, and salary.
It is the unshared attributes that cause problems when we try to represent all members of staff within a single entity.
There are also relationships that are only associated with particular types of staff (subclass) but not with staff.
Ex: SalesPersonnel may have distinct relationships that are not appropriate for all staff such as SalesPersonnel Uses Car.
/ 45

11. Why using Superclasses and Subclasses in the ER models?
To avoid describing similar concepts more than once  saving time for the designer and making the ER diagram more readable.
To add more semantic info to the design in a form that is familiar to many people.
Ex: the assertions that ‘Manager IS-A member of staff” “flat IS-A type of property”, communicates significant semantic content in a concise form.
/ 45

12. Attribute Inheritence
An entity in a subclass represents the same realworld object as in the superclass, and may possess subclass-specific attributes, as well as those associated with the superclass.
Ex: a member of the SalesPersonnel subclass inherits all the attributes of the Staff superclass such as staffNo, name, position, and salary together with those specifically associated with the SalesPersonnel subclass such as salesArea and carAllowance.
/ 45

13. A subclass is an entity in its own right and so it may also have one or more subclasses.
An entity and its subclasses and their subclasses and so on, is called a type hierarchy.
/ 45

14. Type hierarchies are known by a variety of names including:
Specialization hierarchy
Ex: Manager is a specialization of Staff
Generalization hierarchy
Ex: Staff is a generalization of Manager
IS-A hierarchy
Ex: Manager IS-A member of staff
/ 45

15. A subclass with more than one superclass is called shared subclass.
i.e. a member of ahsared subclass must be a member of the associated superclasses.
The attributes of the superclasses are inherited by the shared subclass, which may also have its own additional attributes. This process is referred to as multiple inheritance.
/ 45

16. Specialization
Specialization
Process of maximizing differences between members of an entity by identifying their distinguishing characteristics.
It is a top-down approach to defining a set of superclasses and their related subclasses.
The set of subclasses is defined on the basis of some distinguishing characteristics of the entities in the superclasse.
/ 45

17. Specialization
When we identify a set of subclasses of an entity type, we then:
associate attributes specific to each subclass (where necessary), and also
identify any relationships between each subclass and other entity types or subclasses (where necessary).
/ 45

18. Specialization
Ex: in a model, all members of staff are represented as an entity called Staff.
To apply the process of specialization on the Staff entity, we attempt to identify differences between members of this entity such as members with distinctive attributes and/or relationships, such as Manager, SalesPersonnel and Secretary which have distinctive attributes  we identify them as subclasses of a specialized Staff superclass.
/ 45

19. Generalization Generalization
Process of minimizing differences between entities by identifying their common characteristics.
Is a bottom-up approach, which results in the identification of a generalized superclass from the original entity types.
Reverse of specialization.
/ 45

20. Generalization
Ex: in a model has Manager, SalesPersonnel, and Secretary represented as distinct entity types.
By applying the generalization on these entities we attempt to identify similarities between them such as common attributes and relationships.
These entities share attributes common to all staff  we identify Manager, SalesPersonnel and Secretary as (job roles) subclasses of a generalized Staff superclass.
/ 45

21. Specialization / Generalization
Common attributes
Relationship applicable to only one subclass
Describes the constraints on the relationship between the superclass and its subclasses
Attributes specific to a given subclass are listed in the box.
/ 45

22. Specialization / Generalization
Can be a member of more than one
Every member of Staff must have a contract of employment
Either Full or part time, not both
We may have several specialization of the same entity
/ 45

23. Specialization / Generalization
Example of type hierarchy:
A member of Staff need not have an additional job role such as Manager SalesPersonnel or Secretary
A member of this is a member of the Secretary and Staff  attributes of Staff and Secretary are inheritied by AssistantSecretary which also has its onw attributes.
A member of this must be a member of the above 2 parent superclasses as well as the Staff superclasses  Attributes of Staff, Manager, & SalesPersonnel are inherited by SalesManager
No need to put Or, And for single subclass
/ 45

24. Constraints on Speci/Gener
Participation Constraints
Determines whether every member in the superclass must participate as a member of a subclass
It can be:
Mandatory participation
Every member in the superclass must also be a member of a subclass (use {Mandatory} below the triangle)
Optional participation
A member of a superclass need not belong to any of its subclasses (use {Optional} below the triangle
/ 45

25. Constraints on Speci/Gener
Disjoint Constraints
Describes the relationship between members of the subclasses and indicates whether it is possible for a member of a superclass to be a member of one, or more than one, subclass
/ 45

26. Constraints on Speci/Gener
Only applies when a superclass has more than one subclass.
If the subclass are disjoint then an entity occurrence can be a member of only one of the subclasses. Use ‘Or’ next to the participation constraint.
If the sublcass are nondisjoint then an entity occurrence may be a member of more than one subclass, use ‘And’ next to the participation constraint.
/ 45

27. Constraints on Speci/Gener
Categories of constraints of specialization and generalization:
Mandatory and disjoint
Optional and disjoint
Mandatory and nondisjoint
Optional and nondisjoint
/ 45

28. Worked Example
The inclusion of the Spec./Gene. is optional in building EER model.
The choice to use it or not is dependent on the complexity of the enterprise and whether using the additional concepts of the EER model will help the process of DB design.
There are several instances where there is a potential to use Spec./Gener:
/ 45

29. Fig 11.1
/ 45

30. Worked Example Three options in representing the Staff entity:
Represent all members of staff as a generalized Staff entity
Create three distinct entities Staff, Manager, and Supervisor
Represent the Manager and Supervisor as subclasses of a Staff superclass.
The option we select is based on the commonality of attributes and relationships associated with each entity.
/ 45

31. Worked Example
For example all attributes of the Staff entity are represented in the Manager and Supervisor entities, including the same primary key (staffNo).
The supervisor entity does not have any additional attributes representing this job role.
Both Manager and Supervisor entities are associated with distinct relationships (Manager Manages Branch) and (Supervisor Supervises Staff).
/ 45

32. Worked Example
Based on this information, we select the 3rd option and create Manager and Supervisor subclasses of the Staff superclass.
Not all members of staff are Managers or Supervisors. A single member of staff can’t be both a Manager and a Supervisor.
/ 45

33. Worked Example Relationship between owners.
There are 2 types of owners:
PrivateOwner
BusiensssOwner
Three options in modeling the owners:
Leave PrivateOwner and BusienssOwner as two distinct entities.
Represent both types of owners as a generalized Owner entity.
Represent the PrivateOwner and BusinessOwner as subclasses of Owner superclass.
/ 45

34. Worked Example
To decide, examine the attributes and relationships associated with these entities:
PrivateOwner and BusinessOwner share the common attributes: address and telNo.
They both also have similar relationship with property for rent (i.e. PrivateOwner Pwons PropertyForRent and BusinessOwner Powns PropertyForRent)
/ 45

35. Worked Example
Both types of owner also have different attributes: PrivateOwner has distinct attributes bName, bType, and contactName.
We create a superclass called Owner, with PrivateOwner and BusinessOwner as subclasses:
An owner must be either a private owner or a business owner, but can’t be both.
/ 45

36. Worked Example
There are several persons with common characteristics described in the data requirements specification for the Branch user views.
For example, member of staff, private property owners, and clients all have number and name attributes.
/ 45

37. Worked Example  we create a Person superclass with Staff (including
Manager and
Supervisor
subclasses),
PrivateOwner,
and Client as
subclasses.
/ 45

38. Worked Example
To what extent we wish to use Spec./Gener to represent the Branch user views?
To simplify EER we chose only (a) and (b), but not (c) because the use of spec/gener in this case places too much emphasis on the relationship between entities that are persons rather than emphasizing the relationship between these entities and some of the core entities such as Branch and PropertyForRent.
The option to use Spec./Gener is a subjective decision.  Optional step.
/ 45

39. Fig 12.8
/ 45

40. Aggregation
Represent a “Has-a” or “is-part-of” relationship entity types, where one represents the “whole” and the other the “part”.
It does not change the meaning of navigation across the relationship between the whole and its parts, nor does it link the lifetimes of the whole and its parts.
Ex: Branch Has Staff.
/ 45

41. Aggregation
Use open diamond at one end of the relationship line, next to the entity that represents the ‘whole’.
Staff
staffNo
Branch
branchNo
< Has
1..*
1..1
0..1
1..1
Oversees v
0..100
PropertyForRent
propertyNo
< Offers
1..*
/ 45

42. Composition
A specific form of aggregation that represents an association between entities, where there is a strong ownership and coincidental lifetime between the ‘whole’ and the ‘part’.
Aggregation is entirely conceptual and does nothing more than distinguish a ‘whole’ from a ‘part’.
/ 45

43. Composition
In a composite, the ‘whole’ is responsible for the disposition of the ‘parts’, which means that the composition must manage the creation and destruction of its ‘parts’.
i.e. an object may only be part of one composite at a time.
/ 45

44. Composition
Example: Displays relationship relates the Newspaper entity to the Advert
entity.  an Advert entity (part)
belongs to exactly one Newspaper
entity (whole).
This is in contrast to aggregation,
in which a part may be shared by
many wholes. Ex: a staff entity may
be ‘a part of’ one or more Branches entities.
Advert
1..*
Display ^
1..1
Newspaper
newspaperName
/ 45

45. Composition
The option to use aggregation and composition, and to what extent, are subjective decisions.
They should only be used when there is a requirement to emphasize special relationships between entity types such as ‘has-a’ or ‘is-part- of’, which has implications on the creation, update, and deletion of these closely related entities.
We should only use them when the enterprise data is too complex to easily represent using only the basic concepts of ER model.
/ 45