1. Logical Design database design

2. Dr. Mohamed Osman Hegaz2 Conceptual Database Designing –Provides concepts that are close to the way many users perceive data. ( modeling the collected information at a high-level of abstraction) Logical Database Designing –Provides concepts that arrange the data into a logical structure which can then be mapped into the storage objects Physical Database Designing –Provide concepts that describe the details of how data is stored in the computer. Database Designing

3. (A)- Entity- Relationship to Relational Mapping Logical Design Database Design

4. Motivation

5. Contents Entity- Relationship to Relational Mapping Steps for mapping a basic ER diagram to a relational schema

6. Mapping Method Method for mapping a conceptual schema developed using the ER model to a relational database schema comprises 7 steps: 1.Entity Mapping 2.Weak Entity Mapping 3.Binary 1: 1 Relationship Mapping 4.Binary 1: N Relationship Mapping 5.Binary M: N Relationship Mapping 6.Multi- valued Attribute Mapping 7.N- ary Relationship Mapping

7. Step 1: Entity Mapping For each regular (non- weak) entity type E, create a relation R that includes all simple attributes of E – Include only simple component attributes of a composite attribute – Choose one key attribute of E as primary key for R. If key of E is composite, the set of simple attributes together should form the key – Add following attributes in subsequent steps: Foreign key, Relationship, Multi- valued

8. Step 1: Example

9. Entity Types in the Company Database: EMPLOYEE, DEPARTMENT, PROJECT

10. Step 1: Example Entity Types in the Company Database: EMPLOYEE, DEPARTMENT, PROJECT

11. Schema (in progress) EMPLOYEE [Ssn, Fname, Mit, Lname, Dob, Address, Sex, Salary] DEPARTMENT [Dnumber, DName] PROJECT [Pno, PName, Plocation]

12. Step 2: Weak Entity Mapping For each weak entity type W with owner entity type E create a relation R that includes all simple attributes of W – Include as foreign key attributes in R the primary key attributes of the relation( s) that correspond to the owner entity types. (This maps the identifying relationship type of W) – 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)

13. Step 2: Example Weak Entity Types in the Company Database: DEPENDENT

14. Schema (in progress) EMPLOYEE [Ssn, Fname, Mit, Lname, Dob,Address, Sex, Salary] DEPARTMENT [Dnumber, DName] PROJECT [Pno, PName, Plocation] DEPENDENT [ESSN, DepName, Sex, DOB, Relationship]

15. Step 3: Binary 1: 1 Relationship For each binary 1: 1 relationship type RT, identify relations S & T that correspond to the entity types participating in RT – Choose one relation (say S) and include as foreign key in S the primary key of T – It is better to choose as S, the entity type with total participation in RT – Include all the simple attributes (or simple components of composite attributes) of the 1: 1 relationship type RT as attributes of S Example paintings, artists

16. Step 3: Example Binary 1: 1 relationship type in the Company Database: MANAGES DEPARTMENT serves in the role of “S” because its participation in the MANAGES relationship type is total (every department has a manager) Include the primary key of the EMPLOYEE relation as a foreign key in the DEPARTMENT relation (renamed MGRSSN) Include the simple attribute StartDate of the MANAGES relation (renamed MGRSTART)

17. Schema (in progress) EMPLOYEE [Ssn, Fname, Mit, Lname, Dob, Address, Sex, Salary] DEPARTMENT [Dnumber, Dname, MGRSSN, MgrStart] PROJECT [Pno, PName, Plocation] DEPENDENT [ESSN, DepName, Sex, DOB, Relationship]

18. Step 4: Binary 1: N Relationship For each (non- weak) binary 1: N relationship type RT, identify relation S that represents the participating entity type at the N- side of the relationship type – Include as foreign key of S the primary key of relation T that represents the other entity type participating in RT – Include any simple attributes (or simple components of composite attributes) of the 1: N relationship type as attributes of S

19. Binary I: N relationship types in the Company Database: WORKS_ FOR, CONTROLS and SUPERVISES Where primary key of the DEPARTMENT relation is included as a foreign key in the EMPLOYEE relation (renamed Dno) Step 4: Example

20. Binary I: N relationship types in the Company Database: WORKS_ FOR, CONTROLS and SUPERVISES PROJECT [Pno, PName, Plocation, Dnum] Where primary key of the DEPARTMENT relation is included as a foreign key in the PROJECT relation (renamed Dnum)

21. Step 4: Example Binary I: N relationship types in the Company Database: WORKS_ FOR, CONTROLS and SUPERVISES EMPLOYEE [Ssn, Fname, Mit, Lname,Dob, Address, Sex, Salary, Dno,SuperSsn] Where primary key of the EMPLOYEE relation is included as a foreign key within the EMPLOYEE relation (called SuperSsn) Note the recursive relationship!

22. Schema (in progress) EMPLOYEE [Ssn, Fname, Mit, Lname,Dob, Address, Sex, Salary, Dno, SuperSSN] DEPARTMENT [Dnumber, Dname,MGRSSN, MgrStart] PROJECT [Pno, PName, Plocation,DNum] DEPENDENT [ESSN, DepName, Sex, DOB,Relationship]

23. Step 5: Binary M: N Relationship For each binary M: N relationship type RT, create a new relation S to represent RT – Include as foreign key of S the primary keys of the relations that represent the participating entity types in RT – The combination of foreign keys will form the primary key of S (Note: cannot represent the M: N using a single foreign key in one relation because of the M: N cardinality ratio) – Include any simple attributes (or simple components of composite attributes) of the M: N relationship type as attributes of S.

24. Step 5: Example Binary M: N relationship type in the Company Database: WORKS_ ON WORKS_ ON [ESSN, PNo, Hours] Where WORKS_ ON includes the primary keys of the PROJECT and EMPLOYEE relations as foreign keys The primary key of WORKS_ ON is the combination of the foreign key attributes (renamed to PNO and ESSN respectively) HOURS in WORKS_ ON represents the attribute of the relationship type

25. Schema (in progress) EMPLOYEE [Ssn, Fname, Mit, Lname, Dob, Address, Sex, Salary, Dno, SuperSSN] DEPARTMENT [Dnumber, Dname, MGRSSN, MgrStart] PROJECT [Pno, PName, Plocation, DNum] DEPENDENT [ESSN, DepName, Sex, DOB, Relationship] WORKS_ ON [ESSN, PNo, Hours]

26. Step 6: Multivalued Attributes For each multi- valued attribute A, create a new relation R that includes an attribute corresponding to A plus the primary key K (as a foreign key of 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 attributes A & K – If the multi- valued attribute is composite, include its simple components

27. Step 6: Example Multi- valued attributes in the Company Database: Locations DEPT_ LOCS [DNumber, DLocation] Where primary key of DEPT_ LOCS is the combination of {DNumber, DLocation} Attribute DLocation will represent the attributes Locations of DEPARTMENT multi-valued Attribute DNumber (as foreign key) represents the primary key of the DEPARTMENT relation

28. Final Schema EMPLOYEE [Ssn, Fname, Mit, Lname, Dob, Address, Sex, Salary, Dno, SuperSSN] DEPARTMENT [Dnumber, Dname, MGRSSN, MgrStart] PROJECT [Pno, PName, Plocation, DNum] DEPENDENT [ESSN, DepName, Sex, DOB, Relationship] WORKS_ ON [ESSN, PNo, Hours] DEPT_ LOCS[ DNumber, DLocation]

29. Step 7: N- ary Relationship Type For each “n- ary” relationship type RT, create a new relation S to represent RT. – Include as foreign key attributes of S the primary keys of the relations that represent the participating entity types in RT – Include any simple attributes of the n- ary relationship type – The combination of foreign keys referencing the relations representing the participating entity types is used to form primary key of S

30. Ternary relationship example SUPPLIER [sname,…,] PROJECT [ProjName,... ] PART [PartNo,... ] SUPPLY [SName, ProjName, PartNo, Quantity]

31. Step 8: Super & Sub- classes Option 8A – We create a relational table for the superclass and create a relational table for each subclass. – The primary key of each of the subclass is the primary key of the superclass.

32. Step 8 (cont) Option 8B – We create a relational table for each subclass. The attributes of the superclass are merged into each of the subclasses. – The primary key of the subclass table is the primary key of the superclass.

33. Step 8 (cont) Option 8C – We create a single relational table for all subclasses and the superclass. – The attributes of the table is the union of all attributes plus the attribute T to indicate the subclass to which each tuple belongs. T is NULL in tuples that do not belong to anysubclass (for partial constraints)

34. Step 8 (cont) Option 8D – We create a single relational table for all subclasses and the superclass. – The attributes of the table is the union of all attributes plus m extra boolean attributes for each subclass to indicate whether or not the tuple belongs to this subclass.