1. Database Design and the E-R Model Chapter 7 [2 of 2]
CSc a
Fall 2008
Database Design and the E-R Model Chapter 7 [2 of 2]
Entity-Relationship Design Issues Extended E-R (EER) Features Alternative Notations for Modeling Data
Reduction to Relational Schemas
CSc a
D.G.Hannay

2. Collect Homework
Chapter 6
CSc a

3. Summary of Symbols Used in E-R Notation

4. Alternative ER Notations
Chen IDE1FX (Crows feet notation)

5. IDE1FX
One of the most mature, and certainly most full featured graphical data model representations.
IDE1FX is part of a family of graphic models for all kinds of program and process information.
CSc a

6. Notation from MySQL Workbench
Crow’s Feet for “multi” end of relationship
1 or 0 indicating required vs. optional
Change in MySQL Workbench by editing the relationship
ORDER LINE known as Associative Entity
from many-to-many relationship
CSc a

7. Enhanced E-R (EER) Model Concepts
Includes all modeling concepts of basic E-R
Additional concepts: subclasses/superclasses, specialization/generalization, categories
The resulting model is called the Enhanced E-R or Extended E-R (EER) model
It is used to model applications more completely and accurately if needed
It includes some object-oriented concepts, such as inheritance

8. Supertypes and Subtypes
CSc b
Fall 2008
Supertypes and Subtypes
Subtype: A subgrouping of the entities in an entity type that has attributes distinct from those in other subgroupings
Supertype: A generic entity type that has a relationship with one or more subtypes
Attribute Inheritance:
Subtype entities inherit values of all attributes of the supertype
An instance of a subtype is also an instance of the supertype
D.G.Hannay

9. Basic notation for supertype/subtype notation
CSc b
Fall 2008
Basic notation for supertype/subtype notation
EER notation
D.G.Hannay

10. Employee supertype with three subtypes
CSc b
Fall 2008
Employee supertype with three subtypes
All employee subtypes will have emp nbr, name, address, and date hired
Each employee subtype will also have its own attributes
D.G.Hannay

11. Supertype/subtype relationships in a hospital
CSc b
Supertype/subtype relationships in a hospital
Fall 2008
Both outpatients and resident patients are cared for by a responsible physician
Only resident patients are assigned to a bed
D.G.Hannay

12. Generalization and Specialization
CSc b
Fall 2008
Generalization and Specialization
Generalization: The process of defining a more general entity type from a set of more specialized entity types. BOTTOM-UP
Specialization: The process of defining one or more subtypes of the supertype and forming supertype/subtype relationships. TOP-DOWN
D.G.Hannay

13. Extended E-R Features: Specialization
These subgroupings become lower-level entity sets that have attributes or participate in relationships that do not apply to the higher-level entity set.
ISA (E.g., instructor “is a” person).
Attribute inheritance – a lower-level entity set inherits all the attributes and relationship participation of the higher-level entity set to which it is linked.

14. Specialization Notation

15. Example of specialization
a) Entity type PART
Only applies to manufactured parts
Applies only to purchased parts
Fall 2008
CSc b

16. Example of specialization (cont.)
b) Specialization to MANUFACTURED PART and PURCHASED PART
Note: multivalued attribute was replaced by an associative entity relationship to another entity
Created 2 subtypes

17. Specialization in Hannay Reels Customer
Hannay Reels Customer Specialization (with extra attribute)
Dealers (product line handled)
OEM (equipment built)
End-User (Cr. Card #)

18. Extended E-R Features: Generalization
A bottom-up design process – combine a number of entity sets that share the same features into a higher-level entity set.
Specialization and generalization are simple inversions of each other; they are represented in an EER diagram in the same way.
The terms specialization and generalization are used interchangeably.

19. Generalization Example
CAR, TRUCK generalized into VEHICLE; both CAR, TRUCK become subclasses of the superclass VEHICLE.
We can view {CAR, TRUCK, MOTORCYCLE} as a specialization of VEHICLE
Alternatively, we can view VEHICLE as a generalization of MOTORCYCLE, CAR and TRUCK

20. Example of generalization
CSc b
Example of generalization
Fall 2008
a) Three entity types: CAR, TRUCK, and MOTORCYCLE
All these types of vehicles have common attributes
D.G.Hannay

21. Example of generalization (cont.)
CSc b
Fall 2008
Example of generalization (cont.)
b) Generalization to VEHICLE supertype
So we put the shared attributes in a supertype
Note: no subtype for motorcycle, since it has no unique attributes
D.G.Hannay

22. Design Constraints on a Specialization/Generalization
Constraint on which entities can be members of a given lower-level entity set.
condition-defined
Example: all customers over 65 years are members of senior-citizen entity set; senior-citizen ISA person.
user-defined
Constraint on whether or not entities may belong to more than one lower-level entity set within a single generalization.
Disjoint
an entity can belong to only one lower-level entity set
Noted in E-R diagram by having multiple lower-level entity sets link to the same triangle
Overlapping
an entity can belong to more than one lower-level entity set

23. Design Constraints on a Specialization/Generalization (Cont.)
Completeness constraint -- specifies whether or not an entity in the higher-level entity set must belong to at least one of the lower-level entity sets within a generalization.
total: an entity must belong to one of the lower-level entity sets
partial: an entity need not belong to one of the lower-level entity sets

24. Subtype discriminator (disjoint rule)
A simple attribute with different possible values indicating the subtype

25. Subtype discriminator (overlap rule)
A composite attribute with sub-attributes indicating “yes” or “no” to determine whether it is of each subtype

26. Examples of disjointness constraints
a) Disjoint rule
A patient can either be outpatient or resident, but not both

27. Examples of disjointness constraints (cont.) b) Overlap rule
A part may be both purchased and manufactured

28. Example of supertype/subtype hierarchy
CSc b
Fall 2008
Example of supertype/subtype hierarchy
D.G.Hannay

29. TextBook Superclass/Subclass Notation (Not used in CSc-340—not as intuitive)
Text EER Diagram Notation:

30. Entity Clusters (Aggregation)
CSc a
Fall 2008
Entity Clusters (Aggregation)
EER diagrams are difficult to read when there are too many entities and relationships
Solution: Group entities and relationships into entity clusters
Entity cluster: Set of one or more entity types and associated relationships grouped into a single abstract entity type
D.G.Hannay

31. Aggregation
Consider the ternary relationship proj_guide, which we saw earlier
Suppose we want to record evaluations of a student by a guide on a project

32. Aggregation (Cont.)
Relationship sets eval_for and proj_guide represent overlapping information
Every eval_for relationship corresponds to a proj_guide relationship
However, some proj_guide relationships may not correspond to any eval_for relationships
So we can’t discard the proj_guide relationship
Eliminate this redundancy via aggregation
Treat relationship as an abstract entity
Allows relationships between relationships
Abstraction of relationship into new entity

33. Aggregation (Cont.)
Without introducing redundancy, the following diagram represents:
A student is guided by a particular instructor on a particular project
A student, instructor, project combination may have an associated evaluation 33

34. Could aggregate related groups of entities into clusters
CSc a
Fall 2008
Possible entity clusters for Pine Valley Furniture in Microsoft Visio
Could aggregate related groups of entities into clusters 34
D.G.Hannay

35. EER diagram of PVF entity clusters
CSc a
Fall 2008
EER diagram of PVF entity clusters
More readable, isn’t it?
D.G.Hannay

36. Manufacturing entity cluster
CSc a
Fall 2008
Manufacturing entity cluster
Detail for a single cluster
D.G.Hannay

37. CSc a
Fall 2008
Business Rules
Statements that define or constrain some aspect of the business
Classification of business rules:
Derivation–rule derived from other knowledge, often in the form of a formula using attribute values
Structural assertion–rule expressing static structure. Includes attributes, relationships, and definitions
Action assertion–rule expressing constraints/control of organizational actions
D.G.Hannay

38. EER diagram to describe business rules
CSc a
Fall 2008
EER diagram to describe business rules
D.G.Hannay

39. From EER Diagrams to Relations
Entity types become relations with the same set of attributes.
Relationships become relations whose attributes are only:
The keys of the connected entity types.
Attributes of the relationship itself.

40. Mapping EER to Relational Model
Each strong entity type becomes a table
Non-composite, single-valued attributes become attributes of table
Composite attributes: either make the composite a single attribute or use individual attributes for components, ignoring the composite
Multi-valued attributes: remove them to a new table along with the primary key of the original table; also keep key in original table
Weak entity types become tables by adding primary key of owner entity
Binary Relationships:
1:M-place primary key of 1 side in table of M side as foreign key
1:1- make sure they are not the same entity. If not, use either key as foreign key in the other table
M:M-create a relationship table with primary keys of related entities, along with any relationship attributes
Ternary or higher degree relationships: construct relationship table of keys, along with any relationship attributes

41. Mapping a regular entity
CSc a
Fall 2008
Mapping a regular entity
(a) CUSTOMER entity type with simple attributes
(b) CUSTOMER relation
D.G.Hannay

42. Entity Type -> Relation
name
manf
BEER
Relation: BEER(name, manf)

43. Mapping a composite attribute
CSc a
Mapping a composite attribute
Fall 2008
(a) CUSTOMER entity type with composite attribute
(b) CUSTOMER relation with address detail
D.G.Hannay

44. Mapping an entity with a multivalued attribute
Multivalued attribute becomes a separate relation with foreign key
(b)
One–to–many relationship between original entity and new relation

45. CSc a
Fall 2008
Mapping Weak Entities
Becomes a separate relation with a foreign key taken from the superior entity
Primary key composed of:
Partial identifier of weak entity
Primary key of identifying relation (strong entity)
D.G.Hannay

46. Example of mapping a weak entity [1 of 2] a) Weak entity DEPENDENT
CSc a
Fall 2008
Example of mapping a weak entity [1 of 2]
a) Weak entity DEPENDENT
D.G.Hannay

47. Example of mapping a weak entity [2 of 2]
b) Relations resulting from weak entity
NOTE: the domain constraint for the foreign key should NOT allow null value if DEPENDENT is a weak entity
Foreign key
Composite primary key

48. Mapping Binary Relationships
CSc a
Fall 2008
Mapping Binary Relationships
One-to-Many–Primary key on the one side becomes a foreign key on the many side
Many-to-Many–Create a new relation with the primary keys of the two entities as its primary key (recall associative entity)
One-to-One–Primary key on the mandatory side becomes a foreign key on the optional side
D.G.Hannay

49. Example of mapping a 1:M relationship
CSc a
Fall 2008
Example of mapping a 1:M relationship
a) Relationship between customers and orders
Note the mandatory one
b) Mapping the relationship
Again, no null value in the foreign key…this is because of the mandatory minimum cardinality
Foreign key
D.G.Hannay

50. Example of mapping an M:N relationship [1 of 2]
a) "Completes" relationship (M:N)
The Completes relationship will need to become a separate relation

51. Example of mapping an M:N relationship [2 of 2]
b) Three resulting relations
Composite primary key
Foreign key
New intersection relation

52. Risk with Many-Many Relationships
Combining Drinkers with Likes (as opposed to Favorites) would be a mistake. It leads to redundancy:
name addr beer
Sally 123 Maple Bud
Sally 123 Maple Miller
Redundancy

53. Example of mapping a binary 1:1 relationship [1 of 2]
a) "In_charge" relationship (1:1)
Often in 1:1 relationships, one direction is optional

54. Example of mapping a binary 1:1 relationship [2 of 2]
b) Resulting relations
Foreign key goes in the relation on the optional side,
matching the primary key on the mandatory side

55. Mapping Unary Relationships
CSc a
Fall 2008
Mapping Unary Relationships
One-to-Many
Recursive foreign key in the same relation
Many-to-Many
Two relations:
One for the entity type
One for an associative relation in which the primary key has two attributes, both taken from the primary key of the entity
D.G.Hannay

56. Mapping a unary 1:N relationship
CSc a
Fall 2008
Mapping a unary 1:N relationship
(a) EMPLOYEE entity with unary relationship
(b) EMPLOYEE relation with recursive foreign key
D.G.Hannay

57. Mapping a unary M:N relationship
CSc a
Fall 2008
Mapping a unary M:N relationship
(a) Bill-of-materials relationships (M:N)
(b) ITEM and COMPONENT relations
D.G.Hannay

58. Mapping Ternary (and n-ary) Relationships
CSc a
Fall 2008
Mapping Ternary (and n-ary) Relationships
One relation for each entity and one for the associative entity
Associative entity has foreign keys to each entity in the relationship
D.G.Hannay

59. Mapping a ternary relationship [1 of 2]
CSc a
Mapping a ternary relationship [1 of 2]
Fall 2008
a) PATIENT TREATMENT Ternary relationship with associative entity
D.G.Hannay

60. Mapping a ternary relationship [2 of 2]
CSc a
Mapping a ternary relationship [2 of 2]
Fall 2008
b) Mapping the ternary relationship PATIENT TREATMENT
Remember that the primary key MUST be unique
This is why treatment date and time are included in the composite primary key
But this makes a very cumbersome key…
It would be better to create a surrogate key like Treatment#
D.G.Hannay

61. Mapping Supertype/Subtype Relationships
CSc a
Fall 2008
Mapping Supertype/Subtype Relationships
One relation for supertype and for each subtype
Supertype attributes (including identifier and subtype discriminator) go into supertype relation
Subtype attributes go into each subtype; primary key of supertype relation also becomes primary key of subtype relation
1:1 relationship established between supertype and each subtype, with supertype as primary table
D.G.Hannay

62. Supertype/subtype relationships
CSc a
Fall 2008
Supertype/subtype relationships
D.G.Hannay

63. These are implemented as one-to-one relationships
CSc a
Fall 2008
Mapping Supertype/subtype relationships to relations S
These are implemented as one-to-one relationships
D.G.Hannay

64. Design Issues Use of entity sets vs. attributes
Use of phone as an entity allows extra information about phone numbers (plus multiple phone numbers) 64

65. Summary: EER Design Decisions
The use of an attribute or entity set to represent an object.
Whether a real-world concept is best expressed by an entity set or a relationship set.
The use of a ternary relationship versus a pair of binary relationships.
The use of a strong or weak entity set.
The use of specialization/generalization – contributes to modularity in the design.
The use of aggregation – can treat the aggregate entity set as a single unit without concern for the details of its internal structure.

66. Homework/Project No Homework due Next Class Homework due in One Week:
7.1, 7.3, 7.5, 7.6, 7.8, 7.9, 7.10, 7.11, 7.12
Project
Convert your E-R diagram to EER by adding generalization/specialization (supertype/subtypes)
CSc a

67. In-Class Exercise Create an EER Diagram
You are working for a large country club. This country club wants to keep a database on its members and their guests. For each member, the club keeps mail and telephone contact information, name, and membership number. When you join this club, you can join as a social member (which allows you two rounds of golf a year as well as privileges to the swimming pool and weight room), a tennis member (which allows you all the privileges of a social member as well as use of the tennis courts and four rounds of golf), or a golfing member (all privileges of a tennis member and unlimited use of the golf course).
Track how often a member uses the golf course, and how many guests each member brings to the club. Guests are tracked, to send them mailings inviting them to join the club.
Convert the EER diagram to relations (underline PKs, arrows from FKs)
CSc a