7. ER Model to Relational Model copy.pdf
- 1. Entity Relationship Model to Relational Model Email: l.ung@aupp.edu.kh Telegram: @lyheangu Lecturer: Lyheang UNG
- 2. Recap ❑ Database Design process can be divided into six steps: ❑ Requirement Collection and Analysis ❑ Conceptual Database Design ❑ Logical Database Design ❑ Schema Refinement ❑ Physical Database Design ❑ Application and Security Design ❑ Logical Database Design is the focus of this chapter, it is also known as Data Model Mapping
- 3. Introduction ❑ Similar to the conceptual data model, the logical data model provides a beneficial blueprint for designing the system and referencing the database structure later. ❑ Logical data model is crucial for the implementation of a corporate database. ❑ Logical data model can be used to facilitate the discussion between a non- technical user and a designer, feedback and input from the discussion can make sure the requirements are being met. ❑ A flaw in logical design can cause costly changes on ❑ Data collection ❑ Storage ❑ Securtiy ❑ The chapter provides a procedure for creating relational schema from entity- relationship schema.
- 5. Mapping Regular Entities to Relations ❑ Mapping of Regular(Strong) Entity set ❑ An entity set is mapped to a relation in a straightforward manner; each attribute of an entity set becomes an attribute of a relation. ❑ Simple attributes: ER attributes are mapped directly into a relation. ❑ Composite attributes: map only simple attributes within the composite attributes into a relation. ❑ Choose one of the key attributes of an entity set as the primary key of a relation. ❑ If the key attribute is composite, the set of simple attributes that form the mentioned key together will form as the primary key of the relation.
- 6. Mapping Regular Entities to Relations ❑ Mapping of Regular(Strong) Entity set ❑ Ex:
- 7. Mapping Weak Entity Set ❑ Mapping weak entity set ❑ It becomes a separate relation with a foreign key taken from the superior entity. ❑ Its primary key composes of the following: ❑ Partial identifier of the weak entity set. ❑ Primary key of identifying relation (strong entity set). ❑ For weak entity set W2 whose owner entity set W1 which is also a weak entity set ❑ W1 should be mapped before W2 to determine the primary key first. ❑ Rename attributes, if necessary to avoid name conflicts. NOTE: the domain constraint for the foreign key should NOT allow NULL value if DEPENDENT is a weak entity.
- 8. Mapping Binary Relationship Set ❑ There are three approaches for One to One: ❑ Foreign Key approach: ❑ Include the primary key of relation R1 as a foreign key in relation R2. ❑ In case of having partial and total participation for two entity sets, the entity set that has total participation constraint should play the role of R2. ❑ It is not recommended for the side that has total participation to play the role of R1; because it results in storing multiple NULL values. ❑ Having foreign keys in both R1 and R2 is not recommended; as this results in data redundancy.
- 9. Mapping Binary Relationship Set ❑ There are three approaches for One to One: ❑ Foreign Key approach: ❑ Ex:
- 10. Mapping Binary Relationship Set ❑ There are three approaches for One to One: ❑ Merged relation approach: ❑ Merging two entity sets and a relationship into a single relation, this can be done when both participation is total. ❑ As the relation of the two entity sets has the exact same amount of tuples. ❑ Cross-reference or relationship relation approach: ❑ Setting up a third relation for storing foreign keys (cross-referencing) which are the primary keys of the two relations R1 and R2. ❑ Declare one of the key attributes of R1 or R2 as a primary key ❑ The third relation is called Relationship relation or lookup table. ❑ It is not recommended for one to one relationship as this results in having an extra relation and required an extra join operation for combining related tuples.
- 11. Mapping Binary Relationship Set ❑ There are two approaches for One to Many: ❑ Foreign key approach: ❑ Primary key on the one side becomes a foreign key on the many side. ❑ Ex:
- 12. Mapping Binary Relationship Set ❑ There are two approaches for One to Many: ❑ Cross-reference or relationship relation approach: ❑ Declare the foreign key attribute for the relation schema corresponding to the participating entity set on the N-side as the primary key ❑ The same condition applies as One to One. ❑ This approach is only considered when a few relationship instances exist to avoid NULL values in foreign keys.
- 13. Mapping Binary Relationship Set ❑ There is only one approach for Many to Many: ❑ Cross-reference or relationship relation approach: ❑ Create a new relation with the primary keys of the two entities as its primary key.
- 14. Mapping Multivalued Attributes ❑ Create a new relation R to store ❑ Attributes of the multivalued attribute M ❑ If M is composite, its simple attributes are stored in the relation ❑ Primary key K of the original relation as a foreign key in R
- 15. Mapping Unary Relationship Set ❑ One to many relationship: ❑ Recursive foreign key in the same relation.
- 16. Mapping Unary Relationship Set ❑ Many to many relationship: ❑ Create a relation to store attributes of an entity set. ❑ Create another relation that consists of two primary key attributes and descriptive attributes. item_no description unit_cost item_no component_no quantity Item Component
- 17. Mapping N-ary Relationship Set ❑ Cross-reference approach is used for n-ary relationship, where n>2 ❑ A new relationship relation S is created to store ❑ Primary keys of each participating entity set as the foreign keys in the relation S. ❑ Descriptive attributes ❑ The primary key of S is usually the combination of all the foreign keys that reference the relations representing the participating entity sets.
- 18. Correspondence between ER and Relational Models
- 19. Exercise
- 20. Exercise
- 21. Exercise
- 22. Exercise
- 23. Mapping Specialization/Generalization ❑ For any specialization (total or partial, disjoint or overlapping) ❑ Separate relation per superclass and subclasses ❑ Single relation with at least one attribute per subclass or
- 24. Mapping Categories/Union Types ❑ Create a relation schema to represent union type ❑ Specify a new key attribute (surrogate key) ❑ Ex: Owner and Registered vehicle