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)