1 / 26

Chapter 9 Relational Database Design by ER- and EER-to-Relational Mapping

Chapter 9 Relational Database Design by ER- and EER-to-Relational Mapping. Relational Database Design by ER- and EER-to-Relational Mapping. Design a relational database schema Based on a conceptual schema design Seven-step algorithm to convert the basic ER model constructs into relations

jamal
Télécharger la présentation

Chapter 9 Relational Database Design by ER- and EER-to-Relational Mapping

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Chapter 9 Relational Database Design by ER- and EER-to-Relational Mapping

  2. Relational DatabaseDesign by ER- and EER-to-Relational Mapping • Design a relational database schema • Based on a conceptual schema design • Seven-step algorithm to convert the basic ER model constructs into relations • Additional steps for EER model

  3. ER-to-Relational Mapping Algorithm • COMPANY database example: Assume that the mapping will create tables with simple single-valued attributes

  4. ER-to-Relational Mapping Algorithm • Step 1: Mapping of Regular Entity Types: entity relations • For each regular entity type E in the ER schema, create a relation R that includes all the simple attributes of E. • Include only the simple component attributes of a composite attribute. Choose one of the key attributes of E as the primary key for R. If the chosen key of E is a composite, then the set of simple attributes that form it will together form the primary key of R. • If multiple keys were identified for E during the conceptual design, the information describing the attributes that form each additional key is kept in order to specify secondary (unique) keys of relation R. Knowledge about keys is also kept for indexing purposes and other types of analyses. • Each tuple represents an entity instance

  5. ER-to-Relational Mapping Algorithm

  6. ER-to-Relational Mapping Algorithm (cont’d.) • Step 2: Mapping of Weak Entity Types • For each weak entity type W in the ER schema with owner entity type , create a relation R and include all simple attributes of the entity type as attributes of R • Include primary key attribute of owner as foreign key • 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 attributes of R

  7. ER-to-Relational Mapping Algorithm (cont’d.)

  8. ER-to-Relational Mapping Algorithm (cont’d.) • Step 3: Mapping of Binary 1:1 Relationship Types • For each binary 1:1 relationship type R in the ER schema, identify the relations S and T that correspond to the entity types participating in R • 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. It is better to choose an entity type with total participation in R in the role of S. Include all the simple attributes (or simple components of composite attributes) of the 1:1 relationship type R as attributes of S.

  9. ER-to-Relational Mapping Algorithm (cont’d.) • Step 3: Mapping of Binary 1:1 Relationship Types • Possible approaches: • Foreign key approach • Merged relationship approach • An alternative mapping of a 1:1 relationship type is to merge the two entity types and the relationship into a single relation. This is possible when both participations are total. • Cross-reference or relationship relation approach • set up a third relation R for the purpose of cross-referencing the primary keys of the two relations S and T representing the entity types. • The relation R is called a relationship relation (or sometimes a lookup table). • The drawback is having an extra relation, and requiring an extra join operation when combining related tuples from the tables.

  10. ER-to-Relational Mapping Algorithm (cont’d.) • Step 4: Mapping of Binary 1:N Relationship Types • For each regular binary 1:N relationship type R • Identify relation that represents participating entity type at N-side of relationship type • Include primary key of other entity type as foreign key in S • Include simple attributes of 1:N relationship type as attributes of S • Alternative approach • Use the relationship relation (cross-reference) option as in the third option for binary 1:1 relationships

  11. ER-to-Relational Mapping Algorithm (cont’d.) • Step 5: Mapping of Binary M:N Relationship Types • For each binary M:N relationship type R • Create a new relation S • Include primary key of participating entity types as foreign key attributes in S; their combination will form the primary key of S. • Include any simple attributes of M:N relationship type

  12. ER-to-Relational Mapping Algorithm (cont’d.) • Step 6: Mapping of Multivalued Attributes • For each multivalued attribute A • Create a new relation R • Primary key of R is the combination of A and primary key attribute K of the relation that represents the entity type or relationship type that has A as a multivalued attribute • If the multivalued attribute is composite, include its simple components

  13. ER-to-Relational Mapping Algorithm (cont’d.) • Step 7: Mapping of N-ary Relationship Types • For each n-ary relationship type R • Create a new relation S to represent R • Include primary keys of participating entity types as foreign keys • Include any simple attributes as attributes

  14. ER-to-Relational Mapping Algorithm (cont’d.)

  15. Discussion and Summary of Mapping for ER Model Constructs

  16. Discussion and Summary of Mapping for ER Model Constructs (cont’d.) • In a relational schema, relationship types are not represented explicitly • Represented by having two attributes A and B:one a primary key and the other a foreign key

  17. Mapping of Specialization or Generalization • Step 8: Options for Mapping Specialization or Generalization • Option 8A: Multiple relations—superclass and subclasses • Create a relation L for C with attributes Attrs(L) = {k, a1, ..., an} and PK(L) = k. • Create a relation Li for each subclass Si, 1 ≤ i ≤ m, with the attributes Attrs(Li) = {k} ∪ {attributes of Si} and PK(Li) = k. • This option works for any specialization (total or partial, disjoint or overlapping)

  18. Mapping of Specialization or Generalization • Option 8B: Multiple relations—subclass relations only • Subclasses are total (every entity in the superclass must belong to (at least) one of the subclasses). • Specialization has disjointedness constraint • Create a relation Li for each subclass Si, 1 ≤ i ≤ m, with the attributes Attrs(Li) = {attributes of Si} ∪ {k, a1, ..., an} and PK(Li) = k. • If the specialization is overlapping, the same entity may be duplicated in several relations.

  19. Mapping of Specialization or Generalization (cont’d.) • Option 8C: Single relation with one type attribute • Type or discriminating attribute indicates subclass of tuple. • Create a single relation L with attributes Attrs(L) = {k, a1, ..., an} ∪ {attributes ofS1} ∪ ... ∪ {attributes of Sm} ∪ {t} and PK(L) = k. The attribute t is called a type (or discriminating) attribute whose value indicates the subclass to which each tuple belongs, if any. • This option works only for a specialization whose subclasses are disjoint, and has the potential for generating many NULL values if many specific attributes exist in the subclasses.

  20. Mapping of Specialization or Generalization (cont’d.) • Option 8D: Single relation with multiple type attributes • Create a single relation schema L with attributes Attrs(L) = {k, a1, ..., an} ∪ {attributes ofS1} ∪ ... ∪ {attributes ofSm} ∪ {t1, t2, ..., tm} and PK(L) = k. Each ti, 1 ≤ i ≤ m, is a Boolean type attribute indicating whether a tuple belongs to subclass Si. • This option is used for a specialization whose subclasses are overlapping. • Will also work for a disjoint specialization

  21. Mapping of Shared Subclasses (Multiple Inheritance) • Apply any of the options discussed in step 8 to a shared subclass

  22. Mapping of Categories (Union Types) • Step 9: Mapping of Union Types (Categories) • A category (or union type) is a subclass of the union of two or more superclasses that can have different keys because they can be of different entity types • Creating a relation to correspond to the category. The keys of the defining classes are different • Specify a new key attribute • Surrogate key

More Related