Post on 19-Dec-2015
CSc-340 6a 1
Database Designand the E-R Model
Chapter 7 [2 of 2]
Entity-Relationship Design IssuesExtended E-R (EER) Features
Alternative Notations for Modeling Data
Reduction to Relational Schemas
CSc-340 6a 2
Collect Homework
Chapter 6
Summary of Symbols Used in E-R Summary of Symbols Used in E-R NotationNotation
Alternative ER Notations
Chen IDE1FX (Crows feet notation)
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-340 6a 5
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-340 6a 6
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
Supertypes and SubtypesSupertypes and Subtypes
Subtype:Subtype: A subgrouping of the entities in an A subgrouping of the entities in an entity type that has attributes distinct from entity type that has attributes distinct from those in other subgroupingsthose in other subgroupings
Supertype:Supertype: A generic entity type that has a A generic entity type that has a relationship with one or more subtypesrelationship with one or more subtypes
Attribute Inheritance:Attribute Inheritance: Subtype entities inherit values of all Subtype entities inherit values of all
attributes of the supertypeattributes of the supertype An instance of a subtype is also an instance An instance of a subtype is also an instance
of the supertypeof the supertype
Basic notation for supertype/subtype notation
EER notation
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
Supertype/subtype relationships in a hospital
Both outpatients and resident patients are cared for by a responsible physician
Only resident patients are assigned to a bed
Generalization and Generalization and SpecializationSpecialization
Generalization:Generalization: The process of The process of defining a more general entity type defining a more general entity type from a set of more specialized entity from a set of more specialized entity types. types. BOTTOM-UPBOTTOM-UP
Specialization:Specialization: The process of The process of defining one or more subtypes of the defining one or more subtypes of the supertype and forming supertype and forming supertype/subtype relationships. supertype/subtype relationships. TOP-TOP-DOWNDOWN
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.
Specialization Notation
Fall 2008 CSc-340 3b15
Example of specialization
a) Entity type PART
Only applies to manufactured parts
Applies only to purchased parts
b) Specialization to MANUFACTURED PART and PURCHASED PART
Note: multivalued attribute was replaced by an associative entity relationship to another entity
Created 2 subtypes
Example of specialization (cont.)
Specialization in Hannay Reels Customer
Hannay Reels Customer Specialization (with extra attribute) Dealers (product line handled) OEM (equipment built) End-User (Cr. Card #)
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.
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
Example of generalization
a) Three entity types: CAR, TRUCK, and MOTORCYCLE
All these types of vehicles have common attributes
Example of generalization (cont.)
So we put the shared attributes in a supertype
Note: no subtype for motorcycle, since it has no unique attributes
b) Generalization to VEHICLE supertype
Design Constraints on a Design Constraints on a Specialization/GeneralizationSpecialization/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
Design Constraints on a Design Constraints on a Specialization/Generalization (Cont.)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
Subtype discriminator (disjoint rule)
A simple attribute with different possible values indicating the subtype
Subtype discriminator (overlap rule)
A composite attribute with sub-attributes indicating “yes” or “no” to determine whether it is of each subtype
a) Disjoint rule
Examples of disjointness constraints
A patient can either be outpatient or resident, but not both
b) Overlap rule
A part may be both purchased and manufactured
Examples of disjointness constraints (cont.)
Example of supertype/subtype hierarchy
TextBook Superclass/Subclass Notation
(Not used in CSc-340—not as intuitive)
Text EER Diagram Notation:
Entity ClustersEntity Clusters(Aggregation)(Aggregation)
EEREER diagrams are difficult to read when diagrams are difficult to read when there are too many entities and there are too many entities and relationshipsrelationships
Solution: Group entities and Solution: Group entities and relationships into relationships into entity clustersentity clusters
Entity clusterEntity cluster: Set of one or more : Set of one or more entity types and associated entity types and associated relationships grouped into a single relationships grouped into a single abstract entity typeabstract entity type
AggregationAggregation 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
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
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
3434
Possible entity clusters for Pine Valley Furniture in Microsoft Visio
Could aggregate related groups of entities into clusters
EER diagram of PVF entity clusters
More readable, isn’t it?
Manufacturing entity cluster
Detail for a single cluster
Business RulesBusiness Rules
Statements that Statements that definedefine or or constrainconstrain some some aspect of the businessaspect of the business
Classification of business rules:Classification of business rules: Derivation–rule derived from other knowledge, often Derivation–rule derived from other knowledge, often
in the form of a formula using attribute valuesin the form of a formula using attribute values Structural assertion–rule expressing static structure. Structural assertion–rule expressing static structure.
Includes attributes, relationships, and definitionsIncludes attributes, relationships, and definitions Action assertion–rule expressing constraints/control Action assertion–rule expressing constraints/control
of organizational actionsof organizational actions
EER diagram to describe business rules
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.
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
(a) CUSTOMER entity type with simple attributes
Mapping a regular entity
(b) CUSTOMER relation
Entity Type -> Relation
Relation: BEER(name, manf)
BEER
name manf
(a) CUSTOMER entity type with composite attribute
Mapping a composite attribute
(b) CUSTOMER relation with address detail
Mapping an entity with a multivalued attribute
One–to–many relationship between original entity and new relation
(a)
Multivalued attribute becomes a separate relation with foreign key
(b)
Mapping Weak EntitiesMapping Weak Entities
Becomes a separate relation with Becomes a separate relation with a foreign key taken from the a foreign key taken from the superior entitysuperior entity
Primary key composed of:Primary key composed of: Partial identifier of weak entityPartial identifier of weak entity Primary key of identifying relation Primary key of identifying relation
(strong entity)(strong entity)
Example of mapping a weak entity [1 of 2]
a) Weak entity DEPENDENT
NOTE: the domain constraint for the foreign key should NOT allow null value if DEPENDENT is a weak entity
Foreign key
Composite primary key
Example of mapping a weak entity [2 of 2]
b) Relations resulting from weak entity
Mapping Binary Mapping Binary RelationshipsRelationships
One-to-Many–Primary key on the one One-to-Many–Primary key on the one side becomes a foreign key on the many side becomes a foreign key on the many sideside
Many-to-Many–Create a Many-to-Many–Create a new relationnew relation with the primary keys of the two entities with the primary keys of the two entities as its primary key (recall associative as its primary key (recall associative entity)entity)
One-to-One–Primary key on the One-to-One–Primary key on the mandatory side becomes a foreign key mandatory side becomes a foreign key on the optional sideon the optional side
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
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
New intersection
relation
Foreign key
Foreign key
Composite primary key
Example of mapping an M:N relationship [2 of 2]
b) Three resulting relations
Risk with Many-Many Relationships
Combining Drinkers with Likes (as opposed to Favorites) would be a mistake. It leads to redundancy:
name addr beerSally 123 Maple BudSally 123 Maple Miller
Redundancy
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
b) Resulting relations
Example of mapping a binary 1:1 relationship [2 of 2]
Foreign key goes in the relation on the optional side,matching the primary key on the mandatory side
Mapping Unary Mapping Unary RelationshipsRelationships
One-to-ManyOne-to-Many Recursive foreign key in the same Recursive foreign key in the same
relationrelation Many-to-ManyMany-to-Many
Two relations:Two relations: One for the entity typeOne for the entity type One for an associative relation in which the One for an associative relation in which the
primary key has two attributes, both taken primary key has two attributes, both taken from the primary key of the entityfrom the primary key of the entity
Mapping a unary 1:N relationship
(a) EMPLOYEE entity with unary relationship
(b) EMPLOYEE relation with recursive foreign key
Mapping a unary M:N relationship
(a) Bill-of-materials relationships (M:N)
(b) ITEM and COMPONENT relations
Mapping Ternary (and n-ary) Mapping Ternary (and n-ary) RelationshipsRelationships
One relation for each entity One relation for each entity and one for the associative and one for the associative entityentity
Associative entity has foreign Associative entity has foreign keys to each entity in the keys to each entity in the relationshiprelationship
Mapping a ternary relationship [1 of 2]
a) PATIENT TREATMENT Ternary relationship with associative entity
b) Mapping the ternary relationship PATIENT TREATMENT
Remember that the
primary key MUST be
unique
Mapping a ternary relationship [2 of 2]
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#
Mapping Mapping Supertype/Subtype Supertype/Subtype
RelationshipsRelationships One relation for supertype and for each subtypeOne relation for supertype and for each subtype Supertype attributes (including identifier and Supertype attributes (including identifier and
subtype discriminator) go into supertype subtype discriminator) go into supertype relationrelation
Subtype attributes go into each subtype; Subtype attributes go into each subtype; primary key of supertype relation also becomes primary key of supertype relation also becomes primary key of subtype relationprimary key of subtype relation
1:1 relationship established between supertype 1:1 relationship established between supertype and each subtype, with supertype as primary and each subtype, with supertype as primary tabletable
Supertype/subtype relationships
Mapping Supertype/subtype relationships to relations
These are implemented as one-to-one relationships
S
Design Issues
Use of entity sets vs. attributes
Use of phone as an entity allows extra information about phone numbers (plus multiple phone numbers)
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.
CSc-340 6a 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-340 6a 67
In-Class ExerciseCreate 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)