LECTURE 6: GUIDELINES FOR GOOD RELATIONAL DESIGN MAPPING ERD TO RELATIONS

Transcription

1 LECTURE 6: GUIDELINES FOR GOOD RELATIONAL DESIGN MAPPING ERD TO RELATIONS Ref. Chapter 16 Logical Database Design Methodology for the Relational Model 1

2 Objectives 2 How to derive a set of relations from a conceptual data model (Mapping ERD to Relations)

3 Derive relations for logical data model 3 In this step: We specify the name of the relation followed by a list of the relation s simple attributes enclosed in brackets. We then identify the primary key and foreign key(s) of the relation. Following the identification of a foreign key, the relation containing the referenced primary key is given Any derived attributes are also listed together with how each one is calculated For example: Staff (staffno, fname, lname, position, sex, DOB) Client (clientno, fname, lname, telno, preftype, maxrent, staffno) Foreign Key staffno references Staff(staffNo)

4 Derive relations for logical data model 4 The relationship that an entity has with another entity is represented by the primary key/foreign key mechanism. In deciding where to place the foreign key attribute(s), we must first identify the parent and child entities involved in the relationship. The parent entity refers to the entity that posts a copy of its primary key into the relation that represents the child entity, to act as the foreign key.

5 Derive relations for logical data model 5 We describe how relations are derived for the following structures that may occur in a conceptual data model: (1) strong entity types; (2) weak entity types; (3) composed / multi-valued / derived attributes; (4) binary relationship types; (5) recursive relationship types; (6) complex relationship types; (7) superclass/subclass relationship types;

6 Mapping Strong Entity types 6 For each strong entity in the data model, create a relation that includes all the simple attributes of that entity. If composite attributes exist, only their component simple attributes are needed. FName MName LName Name Employee EmpNo Employee ( EmpNo, FName, MName, LName ) Derived attributes are usually omitted.

7 Mapping Multi_valued Attributes 7 Create a new relation to represent multi-valued attribute and include primary key of the entity in the new relation, to act as a foreign key. The primary key of the new relation is the combination of the multi-valued attribute and the primary key of the entity. A multivalued attribute M of an entity E is represented by a separate table EM 1. Includes the multivalued attribute M in EM 2. Includes the PK of E as FK in EM 3. The PK of EM is the combination of the PK of E and the multivalued attribute M. EM ( M, EPK ) FK : EPK references E (EPK) E EPK M

8 Example of Multi-valued Attributes 8 BranchNo street city Branch telno postcode Branch( branchno, street, city, postcode) BranchTel (telno, branchno) FK: branchno references Branch(branchNo)

9 Example of Multi-valued Attributes 9 Branch BranchNo Street City PostCode telno B1 Brookline London B2 River drive Dubai B3 West river London Not allowed After Mapping: Branch BranchNo Street City PostCode B1 Brookline London 3310 B2 West End Glasgow 1320 B3 West River London 1100 Branch_Tel BranchNo telno B B B B

10 Mapping Weak Entities 10 Create a relation for each weak entity that includes all the simple attributes of that entity. A weak entity s key includes its key and the primary key of the owner entity as FK. The PK of the weak entity: is the combination of the two keys E1 M R N E2 B A Y X E1 ( A, B ) E2 (X, A, Y) FK : A references E1 (A)

11 Mapping Weak Entities - Example 11 1 M Employee has Dependents EmpNo Lname DepAge DepName Employee ( EmpNo, Lname) Dependents(EmpNo, DepName, DepAge) FK : EmpNo references Employee (EmpNo)

12 12 Mapping Binary Relationships One to many One to one Many to many

13 Mapping Binary Relationships 13 Identify one entity as parent and other entity as child As a general rule: PK of parent is added to child as FK Any attributes of the relationship are added to child relation

14 1. One-to-many (1:N) binary relationship 14 For each 1:* binary relationship, the entity on the one side of the relationship is designated as the parent entity and the entity on the many side is designated as the child entity To represent this relationship: Add a copy of the primary key attribute(s) of parent entity one side into the relation representing the child entity many side, to act as a foreign key. Add the attributes of the relationship into the relation. E1 1 N R E2 A E1-PK R1 B E2-PK E1 ( E1-PK, A) E2 ( E2-PK, B, E1_PK, R1 ) FK1 : E1-PK references E1 (E1-PK)

15 Example 1 15 The Department has Staff relationship is a 1:* relationship, A single department can has many staff members. Department is on the one side and represents the parent entity, and Staff is on the many side and represents the child entity. The relationship between these entities is established by placing a copy of the primary key of the Department (parent) entity, DeptNo, into the Staff (child) relation Department 1 N Has Staff DeptName DeptNo year sname scode Department (DeptNo, DeptName) Staff (scode, sname, DeptNo, year) FK: DeptNO references Department(DeptNo)

16 Example 1 Department DeptNo DeptName 140 Information System 160 Computer Science 171 Networks After Mapping: Department DeptNo DeptName 140 Information System 160 Computer Science 171 Networks Staff SID SName 1211 Nora 6550 Fatima 2250 Dena S Samar N Sara L Reem N. Staff SID SName DeptNo Year 1211 Nora Fatima Dena S Samar N Sara L Reem N

17 Example 2 1 M CUSTOMER (Customer_ID, Customer_Name, Customer_Address) Order (Order_ID, Order_Date, Customer_ID) FK: Customer_ID references CUSTOMER (Customer_ID) Foreign key 17

18 2- One-to-one (1:1) binary relationship 18 Creating relations to represent a 1:1 relationship is slightly more complex as the cardinality cannot be used to help identify the parent and child entities in a relationship. The participation are used to help decide how to map the relationship. We consider how to create relations to represent the following participation constraints: (a) mandatory participation on both sides of 1:1 relationship (b) optional participation on both sides of 1:1 relationship (c) mandatory participation on one side of 1:1 relationship

19 2- One-to-one (1:1) binary relationship 19 A. Mandatory participation on both sides B. Optional on both sides Choose one entity and add its PK, and attributes of the relationship, to the other entity. E1 1 1 R E2 A E1-PK R1 B E2-PK E1 ( E1-PK, A) E2 ( E2-PK, B, E1-PK, R1 ) FK1 : E1-PK references E1 (E1-PK) E1 ( E1-PK, A, E2-PK, R1 ) FK1 : E2-PK references E2 (E2-PK) E2 ( E2-PK, B)

20 2- One-to-one (1:1) binary relationship 20 C. Mandatory participation on one side In this case we are able to identify the parent and child entities for the 1:1 relationship using the participation constraints. The entity that has optional participation in the relationship is designated as the parent entity, and the entity that has mandatory participation in the relationship is designated as the child entity To map this relation, Add the PK attributes of the optional side Parent, and attributes of the relationship, to the mandatory side Child. E1 1 1 R E2 A E1-PK R1 B E2-PK E1 ( E1-PK, A) E2 ( E2-PK, B, E1-PK, R1 ) FK1 : E1-PK references E1 (E1-PK)

21 1:1 relationship -Mandatory on both sides 24 Employee 1 1 has Office Emp_name Emp_id year officeno Office_Loc Employee( Emp_name, Emp_id ) Office (officeno, office_loc, Emp_id, year) FKs: Emp_id references Employee (Emp_id)

22 1:1 relationship - Mandatory on one sides 25 Employee 1 1 has Spouse Emp_name Emp_id year Spouse_id Spoude_name Employee( Emp_name, Emp_id ) Spouse(Spouse_id, Spouse_name, Emp_id, year) FKs: emp_id references employee (Emp_id)

23 1:1 relationship - Optional on both sides 26 Employee 1 1 use Car Emp_name Emp_id year Car_No Car_name Employee( Emp_name, Emp_id ) Car (Car_No, Car_name, Emp_id, year) FKs: Emp_id references Employee (Emp_id)

24 3. Many-to-many (M:N) binary relationship 27 Create a relation to represent the relationship and include any attributes that are part of the relationship. Add the primary key attribute(s) of the entities that participate in the relationship into the new relation, to act as foreign keys. These foreign keys will also form the primary key of the new relation, possibly in combination with some of the attributes of the relationship. E1 M R N E2 A E1-PK R1 B E2-PK E1 ( E1-PK, A) E2 ( E2-PK, B) R (E1-PK, E2-PK, R1 ) FK1 : E1-PK references E1 (E1-PK) FK2 : E2-PK references E2 (E2-PK)

25 Example 1 28 STUDENT M Enroll N SUBJECT stname stno date sname scode Student (stno, stname) Subject (scode, sname) Enroll (stno, scode, date) FKs: stno references Student(stNo) scode references Subject(sCode)

26 29 Student StNo StName Asma Nouf Noura Subject scode sname CS 110 Programming Language (1) IS 333 Project Management IS 220 Database Fundamentals Enroll SNO S_ID Date IS IS IS CS

27 Example 2 30 M M The Supplies relationship will need to become a separate relation

28 Foreign key Composite primary key New relation Foreign key RAW_MATERIALS (Material_ID, Standard_cost, unit-of_measure) VENDOR (Vendor_ID, Vendor_Name, Vendor_Address) 31 QUOTE (Material_ID, Vendor_ID, Unit_price) FKs: Material_ID references RAW_MATERIALS (Material_ID) Vendor_ID references VENDOR (Vendor_ID)

29 32 Mapping Unary Relationships One to many One to one Many to many

30 Unary one-to-many (1:N) relationships 33 For a 1:N recursive relationship represent it as a single relation with two copies of the primary key ( one needs to be renamed and treated as the FK), plus attributes of the relationship.. A recursive foreign key is a foreign key in a relation that references the primary key values of that same relation. E1 1 M R A E1-PK R1 E1 ( E1-PK, A, E1_PK_Copy, R1 ) FK1 : E1_PK_Copy references E1 (E1-PK)

31 1 M Employee ( Employee_ID,Name,Birthdate,Manager_ID) FK : Manager_ID references Employee (Employee_ID) 34

32 Unary many-to-many (M:N) relationships 35 For a M:N recursive relationship, Two relations are created; One to represent the entity type in the relationship A new relation to represent the relationship. The new relation would includes two copies of the primary key, and attributes of the relationship. The copies of the primary keys act as foreign keys and have to be renamed to indicate the purpose of each in the relation. E1 ( E1-PK, A) M New_E ( E1-PK, E1_PK_copy, R1 ) FK1 : E1-PK references E1 (E1-PK) FK2 : E1_PK_copy references E1 (E1-PK) A E1 N E1-PK R R1

33 M M ITEM (Item_No, Name, Unit_Cost) COMPONENT (Item_No, Component_No, Quantity) FK1: Item_No references ITEM (Item_No) FK2: Component_No references ITEM (Item_No) 36

34 Unary one-to-one (1:1) 37 Mandatory participation on both sides Follow the rules of mapping 1:M unary relationship represent the recursive relationship as a single relation with two copies of the primary key. Optional on both sides Follow the rules of mapping M:N unary relationship create a new relation to represent the relationship. Mandatory on one side Follow either of the two methods above.

35 Unary one-to-one (1:1) 38 Person (SSN, Name) Marriage (Husband_SSN, Wife_SSN, Date) FK1: Husband_SSN reference Person(SSN) FK2: Wife_SSN reference Person(SSN)

36 39 Mapping Complex Relationships (n-ary)

37 Mapping Complex Relationships (n-ary) 40 For each complex n ary relationship R where n>2, create a new relation to represent the relationship and include any attributes that are part of the relationship. Add a copy of the primary key attribute(s) of the entities E1,E2.. En that participate in the complex relationship into the new relation, to act as foreign keys. However, this will change if the cardinality constraints on any of the participating entities in R is 1! Any foreign keys that represent a many relationship generally will form the primary key of this new relation, possibly in combination with some of the attributes of the relationship

38 Mapping Complex Relationships (n-ary) 41 A E3-PK E3 E1 R E2 A E1-PK R1 B E2-PK E1 ( E1-PK, A) E2 ( E2-PK, B) E3 ( E3-PK, A) R (E1-PK, E2-PK, E3-PK, R1 ) FK1 : E1-PK references E1 (E1-PK) FK2 : E2-PK references E2 (E2-PK) FK3: E3-PK references E3 (E3-PK)

39 Mapping Complex Relationships (n-ary) 42 Supplier (SName) Project (ProjName) Part (PartNo) Supply FKs : (SName, PartNo, ProjName, Quantity) SName references Supplier(SName) PartNo references Part(PartNo) ProjName references Project(ProjName)

40 43 Mapping Superclass/subclass relationship types

41 Mapping Superclass/subclass relationship types 44 Identify superclass entity as parent entity and subclass entity as the child entity. There are various options on how to represent such a relationship as one or more relations. The selection of the most appropriate option is dependent on a number of factors: Disjointness and participation constraints on the superclass/subclass relationship.

42 45 Mapping Superclass/subclass relationship types

43 Mapping Superclass/subclass relationship types 46 onwerno address telno Owner d fname bname lname name PrivateOwner BusinessOwner btype contactname How to map these entities?

44 47

45 48

46 Exercise 49 Convert the following ERD to relational tables, specify the primary key and foreign keys Fname Lname SSN Name Bdate sex Person Adress City Apt_no Street Rank Office d class Salary Faculty Student N Belong M M Major 1 Department