Database Systems Unit 7. Logical Modeling. DB / PRM1 / db07_logicalmodelling.ppt / Version Learning Goals

Transkript

1 Database Systems Unit 7 Logical Modeling DB / PRM1 / db07_logicalmodelling.ppt / Version Learning Goals In this unit you will learn how to translate an ERD into a relational DB how to represent relationship types with different cardinalities using the foreign key concept different techniques to represent generalizations / specializations in a relational database DB / PRM1 / db07_logicalmodelling.ppt / Version

2 Example: ERD of Company DB / PRM1 / db07_logicalmodelling.ppt / Version Example Company: Database Schema Diagram DB / PRM1 / db07_logicalmodelling.ppt / Version

3 Mapping Relationship Types The only construct for representing relationships in a relational database is a foreign key A foreign key represents per default a one-to-many relationship Any other cardinality may be represented using multiple foreign keys, additional relations, and/or additional constraints DB / PRM1 / db07_logicalmodelling.ppt / Version Composite Attributes The relational database model does usually not support structured attributes. Therefore, composite attributes from the conceptual model have to be mapped. For mapping, we may choose out of three possibilities: Each component of the composite attribute becomes a separate attribute in the relation (make sure that togetherness is still visible in attribute names). The composite attribute becomes one single (big) attribute in the relation. Use a separate relation with the same structure as the composite attribute. DB / PRM1 / db07_logicalmodelling.ppt / Version

4 Step1: Translating Regular Entity Types Every regular entity type in the ERD becomes a relation in the relational schema. Every attribute of the entity type becomes an attribute of the relation. Include only the simple component attributes of a composite attribute. One of the identifiers/keys is chosen to be the primary key of the relation; the other identifiers become keys and may be implemented in most DBMS using unique constraints DB / PRM1 / db07_logicalmodelling.ppt / Version Step2: Mapping of Weak Entity Types For each weak entity type W in the ER schema with the owner entity type E, create a relation R. Include all simple attributes (or simple components of composite attributes) of W as attributes of R. In addition, include as foreign key attributes of R the primary attributes of the relation that correspond to the owner entity type. The primary key of R is the combination of the primary key(s) of the owner(s) and the partial key of the weak entity type W, if any. DB / PRM1 / db07_logicalmodelling.ppt / Version

5 Example Employee (1,1) Dependent_of (0,N) Dependent SSN Name Name Employee(SSN, Name, PK(SSN)) Dependent(EmployeeSSN, Name, PK(EmployeeSSN, Name), FK(EmployeeSSN) -> Employee) DB / PRM1 / db07_logicalmodelling.ppt / Version Step 3: Mapping of Binary 1:1 Relationship Types For each binary 1:1 relationsship type R in the ER schema identify the relations S and T that correspond to the entity types participating in R. There are three possible approaches: Foreign key approach: Choose one of the relations S, say and include as a foreign key in S the primary key of T. (Choose an entity type with total participation for S.) Merged relation option: Merge the two entity types and the relationship into a single relation (appropriate when both participations are total). Cross-reference or relationship relation option: Later. DB / PRM1 / db07_logicalmodelling.ppt / Version

6 Example: 1:1-Relationship Type with mandatory Participation for both Entity Types Customer (1,1) has (1,1) Shipping Info Customer# Name ShipInfo# Ship-Address Customer (Customer#, Name, PK(Customer#)) Shipping_Info (ShipInfo#, Ship-Address, Customer# UNIQUE PK(ShipInfo#), FK(Customer#->Customer)) DB / PRM1 / db07_logicalmodelling.ppt / Version Example: 1:1-Relationship Type with optional Participation DB / PRM1 / db07_logicalmodelling.ppt / Version

7 Example: 1:1-Relationship Typemwith optional Participation for both Entity Types Male (0,1) married (0,1) Female SSN Name Date SSN Name Male(SSN, Name, FemaleSSN nv Unique, Date, PK(SSN), FK(FemaleSSN) -> Female)) Female (SSN, Name, PK(SSN)) Alternatively: Male(SSN, Name, PK(SSN)) Female(SSN, Name, MaleSSN nv Unique, Date, PK(SSN), FK(MaleSSN) -> Male)) DB / PRM1 / db07_logicalmodelling.ppt / Version Step 4: Mapping of Binary 1:N Relationship Types For each regular binary 1:N relationship type R, identify the relation S that represents the participating entity type at the N-side of R. Include as foreign key in S the primary key of the relation T the 1-side. (This can be done since each entity S is related to at most one entity instance T.) Include any attributes of the 1:N relationship type as attributes of S. We may not ensure that every primary key value occurs at least once as a foreign key value. As a result, foreign key values may be null. DB / PRM1 / db07_logicalmodelling.ppt / Version

8 Example: 1:N-Relationship Type with mandatory Participation DB / PRM1 / db07_logicalmodelling.ppt / Version Step 5: Mapping of Binary M:N Relationship Types For each binary M:N relationship type R, create a new relation S to represent R. Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types; their combination will form the primary key of S. Include also any attributes of the M:N relationship type as attributes of S. Notice that we can always map 1:1 or 1:N relationships in a manner similar to M:N relationships by cross-reference (relationship relation) approach. DB / PRM1 / db07_logicalmodelling.ppt / Version

9 Example: Binary M:N Relationship Type DB / PRM1 / db07_logicalmodelling.ppt / Version Example (cont.) DB / PRM1 / db07_logicalmodelling.ppt / Version

10 Mapping Recursive Relationship Types The same rules as for binary relationships must also be applied here: For one-to-many and one-to-one cardinalities, only one foreign key is needed and may be combined with further constraints For many-to-many cardinalities, an additional relationship table is also needed here The same methods as discussed before for binary relationship types can be used with recursive ones. The only exception is that all foreign keys reference one and the same relationship DB / PRM1 / db07_logicalmodelling.ppt / Version Example SSN Name is subordinate of Employee (0,1) (0,N) is manager of Employee (SSN, Name, Mngr_SSN nv, PK(SSN), FK(Mngr_SSN) -> Employee) manages DB / PRM1 / db07_logicalmodelling.ppt / Version

11 Step 6: Mapping of Multivalued Attributes For each multivalued attribute A, create a new relation R. This relation R will include an attribute corresponding to A, plus the primary key attribute K as a foreign key in R of the relation that represents the entity type or relationship type that has A as an attribute. The primary key of R is the combination of A and K. If the multivalued attribute is composite, we include its simple components. DB / PRM1 / db07_logicalmodelling.ppt / Version Example DB / PRM1 / db07_logicalmodelling.ppt / Version

12 Step 7: Mapping of N-ary Relationship Types For each n-ary relationship type R, where n > 2, create a new relation S to represent R. Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types. Also include any attributes of the n-ary relationship type as attributes of S. The primary key of S is usually a combination of all the foreign keys that reference the relations representing the participating entity types. DB / PRM1 / db07_logicalmodelling.ppt / Version Example: Ternary Relationship Type DB / PRM1 / db07_logicalmodelling.ppt / Version

13 Mapping of Specialization or Generalization There are several options for mapping a number of subclasses that together form a specialization (or alternatively, that are generalized into a superclass). Multiple relations Superclass and subclasses Multiple relations Subclass relations only. Single relation with one type attribute. Single relation with multiple type attributes. DB / PRM1 / db07_logicalmodelling.ppt / Version Modeling Superclass/Subclasses by Multiple Relations Subclass relations only. Objective: Represent only the subclasses as relations in the database. The superclass will implicitly be represented by the union of all the relations representing subclasses Mapping: Each subclass type inherits explicitly all the attributes from the superclass. Each subclass inherits explicitly all the relationship types from the superclass. Mandatory relationships (1, x) become optional (0, x). DB / PRM1 / db07_logicalmodelling.ppt / Version

14 Modeling Superclass/Subclasses by a Single Relation Objective: Represent the superclass and all of the subclasses in only one relation in the database Mapping: Attributes of the subclasses become optional attributes of the superclass. Relationship types of the subclass types become relationship types of the superclass. Mandatory relationship types (1, x) become optional (0, x). Make sure that attribute values allow to decide whether an entity instance belongs to a given subclass type or not. If necessary, add a discriminating attribute. DB / PRM1 / db07_logicalmodelling.ppt / Version EER Representation of a Super-/Sub-Entity Hierarchy DB / PRM1 / db07_logicalmodelling.ppt / Version

15 Examples: Mapping of Superclass-Subclasses DB / PRM1 / db07_logicalmodelling.ppt / Version Mapping Process: Overview Analyze redundancies in the ERD Remove generalization hierarchies Map regular entity types, attributes, and keys Map relationship types and attributes Map weak entity types and its relationship to the parent entity type Optimize the relational schema using relation merging and/or splitting DB / PRM1 / db07_logicalmodelling.ppt / Version

16 Entity Merging For performance or complexity reasons it might sometimes be useful to merge two related entity types into one Depending on the cardinalities of the involved relationship type, we always have to keep in mind the secondary effects of this merging Redundancy Anomalies DB / PRM1 / db07_logicalmodelling.ppt / Version Redundancy Analysis Types of redundancies: Attributes that may be derived (calculated) from other attributes Attributes that may be derived from relationships and attributes in other entities (usually aggregated values) Implicit relationship types Two solutions: Do not translate redundant structures into the relational schema Ensure that redundancy is controlled by the DBMS DB / PRM1 / db07_logicalmodelling.ppt / Version

17 Correspondence between ER and Relational Models ER Model Relational Model Entity type Entity relation 1:1 or 1:N relationship type Foreign key (or relationship relation) M:N relationship type Relationship relation and two foreign keys n-ary relationship type Relationship relation and n foreign keys Simple attribute Attribute Composite attribute Set of simple component attributes Multivalued attribute Relation and foreign key Value set Domain Key attribute Primary key DB / PRM1 / db07_logicalmodelling.ppt / Version