Database Design and the E-R Model Chapter 7 [2 of 2] CSc-340 6a 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-340 6a D.G.Hannay

Collect Homework Chapter 6 CSc-340 6a

Summary of Symbols Used in E-R Notation

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

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

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 Subtypes CSc-340 3b 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

Basic notation for supertype/subtype notation CSc-340 3b Fall 2008 Basic notation for supertype/subtype notation EER notation D.G.Hannay

Employee supertype with three subtypes CSc-340 3b 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

Supertype/subtype relationships in a hospital CSc-340 3b 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

Generalization and Specialization CSc-340 3b 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

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

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

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

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 CSc-340 3b Example of generalization Fall 2008 a) Three entity types: CAR, TRUCK, and MOTORCYCLE All these types of vehicles have common attributes D.G.Hannay

Example of generalization (cont.) CSc-340 3b 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

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

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

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

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

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

Example of supertype/subtype hierarchy CSc-340 3b Fall 2008 Example of supertype/subtype hierarchy D.G.Hannay

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

Entity Clusters (Aggregation) CSc-340 4a 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

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

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 33

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

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

Manufacturing entity cluster CSc-340 4a Fall 2008 Manufacturing entity cluster Detail for a single cluster D.G.Hannay

CSc-340 4a 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

EER diagram to describe business rules CSc-340 4a Fall 2008 EER diagram to describe business rules D.G.Hannay

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

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

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

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

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

CSc-340 5a 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

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

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

Mapping Binary Relationships CSc-340 5a 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

Example of mapping a 1:M relationship CSc-340 5a 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

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

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

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

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

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

Mapping Unary Relationships CSc-340 5a 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

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

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

Mapping Ternary (and n-ary) Relationships CSc-340 5a 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

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

Mapping a ternary relationship [2 of 2] CSc-340 5a 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

Mapping Supertype/Subtype Relationships CSc-340 5a 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

Supertype/subtype relationships CSc-340 5a Fall 2008 Supertype/subtype relationships D.G.Hannay

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

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

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.

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

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-340 6a