Lecture4: Guidelines for good relational design Mapping ERD to Relation. Ref. Chapter3

Transcription

1 College of Computer and Information Sciences - Information Systems Dept. Lecture4: Guidelines for good relational design Mapping ERD to Relation. Ref. Chapter3 Prepared by L. Nouf Almujally & Aisha AlArfaj Reviewed by Fatima Alhayan Edited by Kholoud Baselm 1 IS220 : D a t a b a s e F u n d a m e n t a l s

2 Outlines Logical Data Model Relational Model Terminology Relational Data Structure Relational Databases and Relational Database Schemas Relational Keys Some Guidelines: Semantics of the Relation Attributes Insertion, deletion and update anomalies Null Values in Tuples Primary key Avoid Data redundancy Derive relations for logical data model (Mapping ERD to Relations) 2

3 The Process of Database Design Conceptual Design Logical Design (Relational Model) Physical Design 3

4 Review 4

5 Logical Data Model In this phase, the main objective is to translate the conceptual data model created in phase 1 into a logical data model of the data requirements of the enterprise. 5

6 Relational Model Terminology The logical (relational) model represents the database as a collection of relations. Informally, each relation resembles a table of values or, to some extent, a file of records. A relation is a table with columns and rows. Attribute is a named column of a relation. Tuple is a row of a relation. Alternative Terminology for Relational Model: 6

7 Relational Model Relational Data Structure Relation is a table with columns & rows. Holds information about entities. Attribute is a named column of a relation. Tuple is a row of a relation. Degree of a relation is the number of attributes it contains. Cardinality of a relation is the number of tuples it contains. 7

8 Relational Data Structure A relation schema R A relation schema is used to describe a relation R is called the name of this relation. Denoted by R (A1, A2,...,An) is made up of a relation name R and a list of attributes, A1, A2,..., An. A relation schema R of degree n is denoted by R (A1, A2,..., An). STUDENT (Name, Ssn, Home_phone, Address, Office_phone, Age, Gpa) 8

9 Another Example 9 Write the relation schema for those two relation

10 Relational Databases and Relational Database Schemas A relational database usually contains many relations, with tuples in relations that are related in various ways. When we refer to a relational database, we implicitly include both its schema and its current state. A relational database schema S is a set of relation schemas S = {R1, R2,..., Rm} and a set of integrity constraints IC. A relational database state DB of S is a set of relation states DB = {r1, r2,..., rm} such that each ri is a state that satisfy the specified integrity constraints. 10

11 This Figure shows the schema diagram The relational database schema: COMPANY = {EMPLOYEE, DEPARTMENT, DEPT_LOCATIONS, PROJECT, WORKS_ON, DEPENDENT} The underlined attributes represent primary keys. 11

12 12 Figure shows a relational database state corresponding to the COMPANY schema.

13 13

14 Relational Model Relational Keys Candidate key (CK) is an attribute, or set of attributes, that uniquely identifies a tuple, and no proper subset is a CK within the relation. Primary Key (PK) is the CK that is selected to identify tuples uniquely within the relation. Foreign Key (FK) is an attribute, or set of attributes, within one relation that matches the CK of some relation. Used to represent relationship between tuples of two relations. 14

15 GUIDELINE 1: Semantics of the Relation Attributes and tuples Design a schema that can be explained easily relation by relation. Properties of Relations: The relation has a name that is distinct from all other relation names in the relational DB. Each Attribute has a distinct name Each cell of the relation should contains exactly single value Each tuple is distinct. There are no duplicate tuples The order of attributes and tuples have no significance. Only foreign keys should be used to refer to other entities 15

16 GUIDELINE 2: Insertion, deletion and update anomalies Design a schema that does not suffer from the insertion, deletion and update anomalies. Attributes of different entities (EMPLOYEEs, DEPARTMENTs, PROJECTs) should not be mixed in the same relation Example Consider the relation: EMP_PROJ ( Emp#, Proj#, Ename, Pname, No_hours) 1. Update Anomaly: Changing the name of project number P1 from Billing to Customer-Accounting may cause this update to be made for all 100 employees working on project P1. 16

17 Example of an anomaly 2. Insert Anomaly: Cannot insert a project unless an employee is assigned to. Inversely - Cannot insert an employee unless an he/she is assigned to a project. 3. Delete Anomaly: When a project is deleted, it will result in deleting all the employees who work on that project. Alternately, if an employee is the sole employee on a project, deleting that employee would result in deleting the corresponding project. 17

18 EXAMPLE OF AN UPDATE ANOMALY Tbl_Staff_Branch Tbl_Staff Tbl_Branch 18

19 GUIDELINE 3: Null Values in Tuples Relations should be designed such that their tuples will have as few NULL values as possible Attributes that are NULL frequently could be placed in separate relations (with the primary key) NULL values: Unknown value: a particular person has a date of birth but it is unknown, so it is represented by NULL in the database. Unavailable value: a person has a home phone but does not want it to be listed, so it is represented as NULL in the database. Not applicable attribute: an attribute College Degree would be NULL for a person who has no college degrees. 19

20 GUIDELINE 4: Candidate key 1. The candidate key must be unique within its domain. 2. The candidate key cannot hold NULL values (NULL is not zero. Zero is a number. NULL is 'nonexistent value'). 3. The candidate key can never change. It must hold the same value for a given occurrence of an entity for the lifetime of that entity. 20

21 GUIDELINE 5: Avoid Data redundancy Data redundancy is a term used about databases and means simply that some data fields appear more than once in the database. Disadvantages : 1. Weak maintaining of the database 2. Waste memory 21

22 22

23 Derive relations for logical data model In this step, we derive relations for the logical data model to represent the entities, relationships, and attributes. 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; 23

24 Derive relations for logical data model To implement the database in relational DBMS, ERD must be translated to tables 1. Specify the name of the relation. 2. A list of the relation s simple attributes enclosed in brackets. 3. Identify the primary key and foreign key(s) of the relation. 4. Specify the identification of a foreign key, the relation containing the referenced For example: Staff (staffno, fname, lname, position, sex, DOB) Client (clientno, fname, lname, telno, preftype, maxrent, staffno) Foreign Key staffno references Staff(staffNo) 24

25 1- Mapping strong entity types A (strong) entity set reduces to a table with the same attributes and PK. If composite attributes exist, only their component simple attributes are needed. Derived attributes are usually omitted. FName MName LName Name EmpNo Employee Employee ( EmpNo, FName, MName, LName ) 25

26 2- Mapping Multi_valued Attributes Here two new relations are created 1. First relation contains all of the attributes of the entity type except the multivalued attribute 2. Second relation contains two attributes that form the primary key of the second relation: primary key for the first relation, which becomes a foreign key in the second relation The second is the multivalued attribute 26

27 2- Mapping Multi_valued Attributes 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 ) EPK FK : EPK references E (EPK) E M 27

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

29 Example of Multi-valued Attributes telno Branch BranchNo Street City PostCode telno B1 Brookline rd London B2 River drive Dubai B3 West river rd London

30 Example of Multi-valued Attributes Branch BranchNo Street City Zip telno B1 Brookline Rd London B2 West End Glasgow B3 West River Rd London one of guidelines is violated here 30

31 Example of Multi-valued Attributes Branch The solution: BranchNo Street City PostCode Branch_Tel BranchNo telno B1 Brookline Rd London 3310 B2 West End Glasgow 1320 B3 West River Rd London 1100 B B B B

32 3- Mapping Weak Entities A weak entity set becomes a table that 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) 32

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

34 4- Mapping Binary Relationships 34

35 1. Many-to-many binary relationship set Create a new relation R with columns for the PKs of the two participating entity sets, and attributes of the relationship. The PK of the new relation consists of the PKs of the two entities. The PKs of the two entities also serve as foreign keys referencing the entities. 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) 35

36 Example 1 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) 36

37 Student SNo SName Asma Nouf Noura Subject S_ID S_name CS 110 Programming Language (1) IS 333 Project Management IS 220 Database Fundamentals Enrollment SNO S_ID Date IS IS IS CS

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

39 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) QUOTE (Material_ID, Vendor_ID, Unit_price) FKs: Material_ID references RAW_MATERIALS (Material_ID) Vendor_ID references VENDOR (Vendor_ID) 39

40 2. One-to-many binary relationship sets Instead of using a separate table for the relationship, just modify the tables for the two entities: add the PK of the one side to the many side. It also serves as a FK of the many side. Add the attributes of the relationship to the many-side. 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) 40

41 Example 1 Department 1 N Has staff DeptName DeptNo year sname scode Department (DeptNo, DeptName) Staff (scode, sname, DeptNo, year) FK: DeptNO references Department(DeptNo) 41

42 Example 1 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. 42

43 Example 1 Department Staff DeptNo DeptName SID SName DeptNo Year 140 Information System 160 Computer Science 171 Networks 1211 Nora Fatima Dena S Samar N Sara L Reem N

44 Example 2 1 M 44

45 Foreign key CUSTOMER (Customer_ID, Customer_Name, Customer_Address) Order (Order_ID, Order_Date, Customer_ID) FK: Customer_ID references CUSTOMER (Customer_ID) 45

46 3- One-to-one relationship sets A. Mandatory participation on both sides Add the PK attributes of one side, and attributes of the relationship, to the other side. B. Optional on both sides Choose one side and add its PK, and attributes of the relationship, to the other side. 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) 46

47 3- One-to-one relationship sets C. Mandatory on one side Add the PK attributes of the optional side, and attributes of the relationship, to the mandatory side. 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) 47

48 1:1 relationship -Mandatory on both sides 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) 48

49 1:1 relationship - Mandatory on one sides 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) 49

50 1:1 relationship - Optional on both sides 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) 50

51 5 Mapping Unary Relationships Unary relationships are relationships between the instances of a single entity type They are also called recursive relationships The approach to mapping is different for the two types one-to-many and many-to-many 51

52 Unary one-to-many (1:N) relationships 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 foreign key attribute is added within the same relation that references the primary key values (this foreign key must have the same data type as the primary key) A recursive foreign key is a foreign key in a relation that references the primary key values of that same relation. 52

53 Unary one-to-many (1:M) E1 1 M R A E1-PK R1 E1 ( E1-PK, A, E1_PK_Copy, R1 ) FK1 : E1_PK_Copy references E1 (E1-PK) 53

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

55 Unary many-to-many (M:N) relationships Two relations are created; 1. one to represent the entity type in the relationship 2. associative relation representing the M:N relationship itself Associative relation: create a new relation with columns for the PK of the entity, copy of the primary key (renamed), and attributes of the relationship. The PKs of the new relation: consists of two attributes, the PK of the entity and the renamed key. Both are taking their values from the primary key of the other relation The PKs also serve as foreign keys referencing the Pk in the original entity. 55

56 Unary many-to-many (M:N) M E1 N R R1 A E1-PK E1 ( E1-PK, A) New_E ( E1-PK, E1_PK_copy, R1 ) FK1 : E1-PK references E1 (E1-PK) FK2 : E1_PK_copy references E1 (E1-PK) 56

57 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) 57

58 Unary one-to-one (1:1) Mandatory participation on both sides Follow the rules of mapping 1:M unary relationship Optional on both sides Follow the rules of mapping M:N unary relationship Mandatory on one side Follow either of the two methods above. 58

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

60 6 Mapping n-ary Relationships Create a relation R to represent the relationship Include the PK of the participating entities E1,E2.. En as FKs in R. The combination of all FKs form the PK of R. Add the relationship attributes to R 60

61 6 Mapping n-ary Relationships 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) 61

62 6 Mapping n-ary Relationships Supplier (SName) Project (ProjName) Part (PartNo) Supply (SName, PartNo, ProjName, Quantity) FKs : SName references Supplier(SName) PartNo references Part(PartNo) ProjName references Project(ProjName) 62

63 63

64 Convert the following ERD to relational tables, specify the primary key and foreign keys 64

65 References Database Systems: A Practical Approach to Design, Implementation and Management. Thomas Connolly, Carolyn Begg. 5 th Edition, Addison-Wesley,