CSC 261/461 Database Systems Lecture 10

Transcription

1 CSC 261/461 Database Systems Lecture 10 Spring 2018 Please put away all electronic devices

2 Announcements From now on, no electronic devices allowed during lecture Includes Phone and Laptop Why? For your own good And for others What should I do instead? Get your notebook out and start keeping notes!

3 Design Theory (ER model to Relations)

4 ER Models to Relations Please go through Chapter 9

5 Entity Sets to Tables (Step 1) Alex Bob John 12 CREATE TABLE ( char(11), varchar(30), Integer, PRIMARY KEY ())

6 Multivalued Attribute Multivalued Attribute CREATE TABLE Hobby( varchar(30), Hobby varchar(30), PRIMARY KEY ( , Hobby), FOREIGN KEY ( ) REFERENCES User( ) ON DELETE CASCADE )

7 Translating Weak Entity Sets cost p age Policy Dependents CREATE TABLE Dept_Policy( p varchar(30), age integer, cost float, char(11), PRIMARY KEY (p, ), FOREIGN KEY () REFERENCES ON DELETE CASCADE )

8 Relationship Sets (without Constraints) to Tables since d did budget Works_In Departments address Locations capacity

9 Relationship Sets (without Constraints) to Tables CREATE TABLE Works_in( char(11), did integer (30), address varchar(30), since date, PRIMARY KEY (, did, address), FOREIGN KEY () REFERENCES, FOREIGN KEY (address) REFERENCES Locations, FOREIGN KEY (did) REFERENCES Departments, )

10 Relationship Sets (without Constraints) to Tables supervisor Reports_To subordinate CREATE TABLE Reports_To( supervisor_ char(11), subordinate_ char(11), PRIMARY KEY (supervisor_, subordinate_), FOREIGN KEY (supervisor_ ) REFERENCES (), FOREIGN KEY (subordinate_ ) REFERENCES () )

11 ONE-TO-ONE RELATIONSHIP

12 Relationship Sets to Tables (Option 1) since d did budget 1 1 Manages Departments CREATE TABLE Manages( char(11), did integer, since date, PRIMARY KEY (did), FOREIGN KEY () REFERENCES ON DELETE CASCADE, FOREIGN KEY (did) REFERENCES Departments ON DELETE CASCADE, )

13 Relationship Sets to Tables (Option 2) since d did budget 1 1 Manages Departments CREATE TABLE Manages( char(11), did integer, since date, PRIMARY KEY (), FOREIGN KEY () REFERENCES ON DELETE CASCADE, FOREIGN KEY (did) REFERENCES Departments ON DELETE CASCADE, )

14 Better way of doing it (Option 3) since d did budget 1 1 Manages Departments CREATE TABLE Dept_Mgr( did integer d varchar(30), budget float(30), char(11), since date, PRIMARY KEY (did), FOREIGN KEY () REFERENCES ON DELETE SET NULL, )

15 Possible but not recommended (Option 4) since d did budget 1 1 Manages Departments CREATE TABLE Employee_Mgr( char(11), varchar(30), integer, since date, did integer, PRIMARY KEY (), FOREIGN KEY (did) REFERENCES Departments (did) ON DELETE SET NULL, ) Why Bad? Many NULL Entries

16 ONE-TO-MANY RELATIONSHIP

17 Relationship Sets to Tables (Option 1) since d did budget 1 N Manages Departments CREATE TABLE Manages( char(11), did integer, since date, PRIMARY KEY (did), FOREIGN KEY () REFERENCES ON DELETE CASCADE, FOREIGN KEY (did) REFERENCES Departments ON DELETE CASCADE, )

18 Relationship Sets to Tables (Option 2) since d did budget 1 N Manages Departments CREATE TABLE Manages( char(11), did integer, since date, PRIMARY KEY (), FOREIGN KEY () REFERENCES ON DELETE CASCADE, FOREIGN KEY (did) REFERENCES Departments ON DELETE CASCADE, ) Wrong

19 Relationship Sets to Tables (Option 2 (2 nd try)) since d did budget 1 N Manages Departments CREATE TABLE Manages( char(11), did integer, since date, PRIMARY KEY (, did), FOREIGN KEY () REFERENCES ON DELETE CASCADE, FOREIGN KEY (did) REFERENCES Departments ON DELETE CASCADE, )

20 Better way of doing it (Option 3) since d did budget 1 N Manages Departments CREATE TABLE Dept_Mgr( did integer d varchar(30), budget float(30), char(11), since date, PRIMARY KEY (did), FOREIGN KEY () REFERENCES ON DELETE SET NULL, )

21 Not Possible (Option 4) since d did budget 1 N Manages Departments CREATE TABLE Employee_Mgr( char(11), varchar(30), integer, since date, did integer, PRIMARY KEY (), FOREIGN KEY (did) REFERENCES Departments (did) ON DELETE NO ACTION, ) Wrong Why Not? All relations are flat.

22 What about this? since d did budget 1 N Manages Departments CREATE TABLE Employee_Mgr( char(11), varchar(30), integer, since date, did integer, PRIMARY KEY (, did), FOREIGN KEY (did) REFERENCES Departments (did) ON DELETE RESTRICT, ) Possible. But Our Next topic It s a bad Functional Dependency

23 Should Department entity have Total participation? since d did budget 1 N Manages Departments CREATE TABLE Dept_Mgr( did integer d varchar(30), budget float(30), char(11), since date, PRIMARY KEY (did), FOREIGN KEY () REFERENCES ON DELETE CASCADE, ) No. We do not want to delete a department if the manager quits

24 MANY-TO-MANY RELATIONSHIP

25 Relationship Sets to Tables (Only Option) since d did budget N Manages M Departments CREATE TABLE Manages( char(11), did integer, since date, PRIMARY KEY (did, ), FOREIGN KEY () REFERENCES ON DELETE CASCADE, FOREIGN KEY (did) REFERENCES Departments ON DELETE CASCADE, )

26 MAPPING RELATIONSHIP INTO ENTITY SET

27 Version 1 since d did budget N Manages M Departments

28 Version 2 since d did budget EmpManages Manager Dept Manages Departments If you ever face this, check if you could simplify

29 TRANSLATING CLASS HIERARCHIES

30 Translating Class Hierarchies Hours_worked Contract_id Hourly_wages isa Hourly_Emps Contract Emps

31 Two options 1. We can map each of the entity sets, Hourly_Emps, and Contract_Emps to a distinct relation. 2. We can create just two relations, corresponding to Hourly_Emps and Contract_Emps Both have their pros and cons Redundancy Performance

32 Notes on Project 1 Milestone 2 We did not cover Chapter 4 and you do not need to study it for exam or quizzes. If you understand this isa concept and how to convert such an ER diagram into tables, that s fine. And this is exactly what steps 8 and 9 are in Chapter 9

33 Hints for Project 2 Part 1

34 E/R Summary E/R diagrams are a visual syntax that allows technical and non-technical people to talk For conceptual design Basic constructs: entity, relationship, and attributes A good design is faithful to the constraints of the application, but not overzealous The ER model to relation mapping is very important part of the database design.

35 Acknowledgement Some of the slides in this presentation are taken from the slides provided by the authors. Many of these slides are taken from cs145 course offered by Stanford University.