Skema Relasi. Entity-Relationship to Relational Mapping

Transcription

1 Skema Relasi Entity-Relationship to Relational Mapping

2 DATABASE Modules Fundamentals Data Modeling Data Design Data Access Architecture Module 1: Database Systems Module 2: Relational Model Module 3: Entity Relationship Model Module 4: ER to Relational Mapping Module 5: FDs and Normalization Module 6: Relational Algebra Module 7: SQL Module 8: Database Systems Architecture 2

3 Database Desain Conceptual perspective User s perspective Database Requirements The Entity Relationalship (ER) Model is one of the most widely used mthod for conceptual design Conceptual Design Logical Design (Mapping) Conceptual Schema (ER) The Relational Model is the basic for several commercial DBMSs Logical Schema (Relational) Internal Schema

4 Contents Entity-Relationship to Relational Mapping Steps for mapping a basic ER diagram to a relational schema Uses the Company database example to illustrate the concepts Design choices in the ER Model and their impact on the resulting relational schema 4

5 Mapping Method Method for mapping a conceptual schema developed using the ER model to a relational database schema comprises 7 steps [ CASE tools also exist for this task ] 5

6 Steps for Mapping 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 6

7 7 PROJECT EMPLOYEE Fname Minit Name Lname Bdate Ssn Sex Salary Address DEPENDENT Name Number DEPARTMENT MANAGES WORKS_FOR WORK_ON CONTROLS SUPERVISION N Relationship Name BirthDate Sex Name PNumber Location Number Of Employee StartDate supervisor supervise 1 N N N M N Hours Example ER Model: Company Database DEPENDENTS_OF Locations

8 8 PROJECT EMPLOYEE Fname Minit Name Lname Bdate Ssn Sex Salary Address Name Number DEPARTMENT MANAGES WORKS_FOR WORK_ON CONTROLS SUPERVISION Relationship Name BirthDate Sex Name PNumber Location Number Of Employee StartDate Hours Company Database in alternative notation (1,N) (1,1) (1,1) (0,1) (0,N) (1,1) (1,N) (1,N) (0,N) (0,1) (0,N) (1,1) Locations Locations DEPENDENTS_OF supervisor supervise employee departement manager Departementmanaged worker project Controllingdepartement employee dependent Controlledproject DEPENDENT

9 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 9

10 Step 1: Example Entity Types in the Company Database: EMPLOYEE, DEPARTMENT, PROJECT Fname Minit Name Lname Sex Salary Address Ssn Bdate EMPLOYEE EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate, Address, Sex, Salary ] 10

11 Step 1: Example Entity Types in the Company Database: EMPLOYEE, DEPARTMENT, PROJECT Name Number Number of employee Locations DEPARTMENT DEPARTMENT [ Dnumber, Dname, DnumEmp ] 11

12 Step 1: Example Entity Types in the Company Database: EMPLOYEE, DEPARTMENT, PROJECT Name PROJECT PNumber Location PROJECT [ Pno, Pname, Plocation ] 12

13 Schema (in progress) EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate, Address, Sex, Salary ] DEPARTMENT [ Dnumber, Dname, DnumEmp ] PROJECT [ Pno, Pname, Plocation ] 13

14 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 primary key of the weak entity type W (if any) 14

15 Step 2: Example Weak Entity Types in the Company Database: DEPENDENT EMPLOYEE DEPENDENTS_OF Ssn DEPENDENT [ ESsn, DepName, Sex, Birthdate, Relationship ] where Primary Key {ESSN, DepName} includes Name Sex DEPENDENT Relationship BirthDate SSN, the primary key of the EMPLOYEE relation, which is the owner entity type, as a foreign key attribute of DEPENDENT (renamed ESSN) DepName, the partial key of DEPENDENT 15

16 Schema (in progress) EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate, Address, Sex, Salary ] DEPARTMENT [ Dnumber, Dname, DnumEmp ] PROJECT [ Pno, Pname, Plocation ] DEPENDENT [ ESsn, DepName, Sex, BirthDate, Relationship ] 16

17 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 17

18 Step 3: Example Binary 1:1 relationship type in the Company Database: MANAGES Ssn StartDate Number EMPLOYEE MANAGES DEPARTMENT DEPARTMENT [ Dnumber, Dname, DnumEmp, #MGRSsn, MgrStartDate ] 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 MGRStartDate) 18

19 Schema (in progress) EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate, Address, Sex, Salary ] DEPARTMENT [ Dnumber, Dname, DnumEmp, #MGRSsn, MgrStartDate ] PROJECT [ Pno, Pname, Plocation ] DEPENDENT [ ESsn, DepName, Sex, BirthDate, Relationship ] 19

20 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 20

21 Step 4: Example Binary 1:N relationship types in the Company Database: WORKS_FOR, CONTROLS and SUPERVISION EMPLOYEE Ssn Number N 1 WORK_FOR DEPARTMENT EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate, Address, Sex, Salary, #Dnumber ] Where primary key of the DEPARTMENT relation is included as a foreign key in the EMPLOYEE relation (rename Dnumber) 21

22 Step 4: Example Binary 1:N relationship types in the Company Database: WORKS_FOR, CONTROLS and SUPERVISION DEPARTMENT Number 1 CONTROLS N PNumber PROJECT [ Pno, Pname, Plocation, #Dnumber ] Where primary key of the DEPARTMENT relation is included as a foreign key in the PROJECT relation (renamed Dnumber) PROJECT 22

23 Step 4: Example Binary I:N relationship types in the Company Database: WORKS_FOR, CONTROLS and SUPERVISION EMPLOYEE supervisor supervise 1 N SUPERVISION EMPLOYEE [Ssn, Fname, Minit, Lname, Bdate, Address, Sex, Salary, #Dnumber, #SuperSsn ] Where primary key of the EMPLOYEE relation is included as a foreign key within the EMPLOYEE relation (called SuperSsn) Note the recursive relationship! Ssn SSsn 23

24 Schema (in progress) EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate, Address, Sex, Salary, #Dnumber, #SuperSsn ] DEPARTMENT [ Dnumber, Dname, DnumEmp, #MGRSsn, MgrStartDate ] PROJECT [ Pno, Pname, Plocation, #Dnumber ] DEPENDENT [ ESsn, DepName, Sex, BirthDate, Relationship ] 24

25 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. 25

26 Step 5: Example Binary M:N relationship type in the Company Database: WORKS_ON EMPLOYEE WORKS_ON [ ESsn, Pno, Hours ] Ssn Number N WORK_FOR N DEPARTMENT 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 26

27 Schema (in progress) EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate, Address, Sex, Salary, #Dnumber, #SuperSsn ] DEPARTMENT [ Dnumber, Dname, DnumEmp, #MGRSsn, MgrStartDate ] PROJECT [ Pno, Pname, Plocation, #Dnumber ] DEPENDENT [ ESsn, DepName, Sex, BirthDate, Relationship ] WORKS_ON [ ESsn, Pno, Hours ] 27

28 More on M:N Mapping Note that 1:1 and 1:N relationships can be mapped in the same way as M:N Advantageous when few relationship instances exist (Sparse 1:1 Relationship) as it reduces the number of nulls that appear as foreign key values 28

29 Sparse 1:1 Relationship PK2 NK2 PK1 as FK Null Null PK1 X NK1 PK2 NK2 PK1 X NK1 A B C X Y Y A X A Null B C Y Null Y Y B C Y No Nulls as Foreign Keys Standard Implementation M:N Implementation 29

30 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 30

31 Step 6: Example Multi-valued attributes in the Company Database: Locations DEPT_LOCS [ DNumber, Dlocation ] Name Number DEPARTMENT Locations Where primary key of DEPT_LOCS is the combination of {DNumber, DLocation} Attribute DLocation will represent the multivalued attributes Locations of DEPARTMENT Attribute DNumber (as foreign key) represents the primary key of the DEPARTMENT relation 31

32 Final Schema EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate, Address, Sex, Salary, #Dnumber, #SuperSsn ] DEPARTMENT [ Dnumber, Dname, DnumEmp, #MGRSsn, MgrStartDate ] PROJECT [ Pno, Pname, Plocation, #Dnumber ] DEPENDENT [ ESsn, DepName, Sex, BirthDate, Relationship ] WORKS_ON [ ESsn, Pno, Hours ] DEPT_LOCS [ DNumber, Dlocation ] 32

33 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 33

34 Special case:n-ary Relationship If the participation constraint (min,max) of one of the entity types E participating in RT has max = 1, then the primary key of S need not include the foreign key attribute that references the relation E 34

35 N-ary Mapping Examples Ternary relationship Ternary relationship with participation constraint of one entity type having max=1 Weak entity with three owners Semantically different representation of relationship between 3 entities 35

36 Ternary relationship Sname Quantity ProjName SUPPLIER (1,N) SUPPLY (1,N) PROJECT PartNo (1,N) PART SUPPLIER [ Sname,... ] PROJECT [ ProjName,... ] PART [ PartNo,... ] SUPPLY [ SName, ProjName, PartNo, Quantity ] 36

37 Ternary relationship (max=1) Participation constraint with max = 1 (Only one Supplier for each Project/Part) Sname SUPPLIER (1,1) PartNo Quantity SUPPLY (1,N) (1,N) ProjName PROJECT PART SUPPLIER [ Sname,... ] PROJECT [ ProjName,... ] PART [ PartNo,... ] SUPPLY [ ProjName, PartNo, #Sname, Quantity ] 37

38 Weak entity with three owners Sname Quantity ProjName SUPPLIER 1 SS N N 1 SUPPLY SPJ PROJECT N PartNo SP PART 1 SUPPLIER [ Sname,... ] PROJECT [ ProjName,... ] PART [ PartNo,... ] SUPPLY [ SName, ProjName, PartNo, Quantity ] Same as ternary relationship 38

39 Relationships between 3 Entities Sname ProjName SUPPLIER M CAN_SUPPLY M PartNo SUPPLIES N PROJECT M USES Semantically different from ternary relationship N PART N SUPPLIER [Sname,... ] PROJECT [ProjName,... ] PART [PartNo,... ] SUPPLIES [SName, ProjName] CANSUPPLY [SName, PartNo] USES [PartNo, ProjName] 39

40 Contents Entity-Relationship to Relational Mapping Steps for mapping a basic ER diagram to a relational schema Uses the Company database example to illustrate the concepts Design choices in the ER Model and their impact on the resulting relational schema 40

41 Expressibility of ER Constraints play an important role in determining the best database design for an enterprise. Several kinds of integrity constraints can be expressed in the ER model, e.g., key constraints, participation constraints. Some foreign key constraints are also implicit in the definition of a relationship set. Some constraints (notably, functional dependencies) cannot be expressed in the ER model. Some additional constructs have not been discussed: ISA hierarchies, and aggregation. There are many variations on ER model 41

42 Subjectivity of ER Design ER model is a means of capturing user s data requirements. However, different designers may interpret the semantics of the user s requirements differently This may result in the same UoD being represented by different ER diagrams because of different Design Choices These design choices in the ER Model impact on the resulting relational schema 42

43 What are Design Choices? Should a concept be modeled as an entity or an attribute? Should a concept be modeled as an entity or a relationship? Should a concept be modeled as a weak entity or a complex (composite, multivalued) attribute Is a relationship binary or ternary?? 43

44 Entity vs. Attribute enr-dept gives the enrolling department for a Student ofr-dept gives the offering department for a Course A designer may choose to create an entity type Department with a single attribute dname. Other attributes for Department (Hod, dbudget) may be discovered later name sno Enr-dept Student Studies name sno Enr-dept Student Studies enrol Department dname Hod ctitle ccd ofr-dept Course ctitle ccd ofr-dept Course offer dbudget 44

45 Entity vs. Relationship Works_In2 does not allow an employee to work in a project more than once. Works_In3 allows an employee to work in the same project more than once. Can an employee work in the same project, for the same period under two different positions? name from ssn add Employees name ssn add Employees from to pos Works_In2 EPH pid pid pos pname budget Projects pname budget Projects to Works-In3 45

46 Weak Entity vs. Complex Attrib If a weak entity participates in other relationship types, besides the identifying relationship, then it has to be modeled as a weak entity If the weak entity has only one attribute, then it may be modeled as a multivalued attribute of the owner entity name ssn add Employees name ssn Employees add Works_In2 dname dname Dependents 46

47 Binary vs. Ternary Relationships ssn name add dname dbudget If a project is controlled by, and an employee works in only one department, the ternary relationship is inappropriate EPD [ssn, dname, projid] (90, CSEE, WF99) (90, CSEE, Hydro88) (87, CSEE, Hydro88) (87, CSEE, Spark4) (32, Biology,Gen2000) 1 Employees EPD Department M N projid Project cost name ssn Employees M Assigned-to add 1 Works-In M projid cost dname dbudget Department 1 Controlled N Project N 47

48 From UoD to Database Correctness (How can we be sure?) semantic non-ambiguity (unique name and elementary value) minimum representation (no redundancy and no derivables) Completeness (Is it good for all applications?) Everything in UoD is represented Everything expressed by the model is true in UoD 48

49 Example Exercise Extract the conceptual model (ER DIAGRAM) from a given user specification Map the conceptual model to a RELATIONAL SCHEMA Refine the relational schema using functional dependencies and normalization (Next Module) 49

50 Specifications Sebuah bank, yang dikenali dari code, name dan head office address, dapat memiliki beberapa branches. Setiap branch untuk bank tertentu memiliki branch number and address. Satu cabang dapat memiliki beberapa account, masingmasing diidentifikasi dengan AC number. Setiap account memiliki type, current balance, dan satu atau lebih account holder. Satu cabang dapat memilik pinjaman, masing-masing pinjaman dikenali dari unique loan number, type, amount dan satu atau lebih loan holders Nama, alamat, telepon dan id dari semua pelanggan (account dan pinjaman) dari setiap bank dicatat dan dipelihara. 50

51 ER Diagram Code Name HO-Addr Addr Branch-No BANK 1 BRANCHES N BANK-BRANCH 51

52 ER Diagram Code Name HO-Addr Addr Branch-No BANK 1 BRANCHES N BANK-BRANCH ACNo Type ACCOUNT N ACCTS 1 Balance 52

53 ER Diagram Code Name HO-Addr Addr Branch-No BANK 1 BRANCHES N BANK-BRANCH ACNo Type ACCOUNT N ACCTS 1 1 Balance LoanNo LOANS Type LOAN N Amount 53

54 ER Diagram Code Name HO-Addr Addr Branch-No BANK 1 BRANCHES N BANK-BRANCH ACNo Type ACCOUNT N ACCTS 1 1 LOANS Balance N AHOLDER LoanNo Type Amount M N LOAN N CUSTOMER LHOLDER M SSN Name Addr Phones 54

55 Relational Schema BANK [Code, Name, HOAddr] BRANCH [BankCode, BranchNo, Addr] ACCOUNT [ACNo, Type, Balance, BankCode, BranchNo] LOAN [LoanNo, Type, Amount, BankCode, BranchNo] CUSTOMER [SSN, Name, Address] CUSTPHONE [SSN, Phone] ACCOUNT-HOLDER [ACNo, SSN] LOAN-HOLDER [LoanNo, SSN] 55

56 Review Seven mapping steps address basic constructs that appear on ER diagrams The result is a relational database schema that exhibits good design characteristics There are other ER constructs that we have not addressed ER design is subjective. There are often several ways to model a given scenario! Analyzing alternatives can be tricky, especially for a large enterprise. ER to Relational Mapping is a starting point. Resulting relational schema has to be analyzed and refined further to achieve optimal design, using functional dependency information and techniques such as normalization (Next Module) 56