From ER to Relational Model Book Chapter 3 (part 2 ) The slides for this text are organized into chapters. This lecture covers Chapter 3, and introduces the relational model of data. It covers the data model and integrity constraints in detail, together with the related SQL commands for creating tables and expressing these constraints. We discuss how to take an ER design and convert it to the schema for a relational database. Querying and modifying tables, and the concept of views, are covered briefly. 1

Logical DB Design: ER to Relational Translate Entity sets to tables: CREATE TABLE Employees (ssn CHAR(11), name CHAR(20), lot INTEGER, PRIMARY KEY (ssn)) Employees ssn name lot The slides for this text are organized into several modules. Each lecture contains about enough material for a 1.25 hour class period. (The time estimate is very approximate--it will vary with the instructor, and lectures also differ in length; so use this as a rough guideline.) This covers Lectures 1 and 2 (of 6) in Module (5). Module (1): Introduction (DBMS, Relational Model) Module (2): Storage and File Organizations (Disks, Buffering, Indexes) Module (3): Database Concepts (Relational Queries, DDL/ICs, Views and Security) Module (4): Relational Implementation (Query Evaluation, Optimization) Module (5): Database Design (ER Model, Normalization, Physical Design, Tuning) Module (6): Transaction Processing (Concurrency Control, Recovery) Module (7): Advanced Topics 3

Translate Relationship Sets to Tables since name dname ssn lot did budget Employees Works_In Departments 5

Translate Relationship Sets to Tables Attributes of relation include: Keys for each participating entity set All descriptive attributes. CREATE TABLE Works_In( ssn CHAR(11), did INTEGER, since DATE) since name dname ssn lot did budget Employees Works_In Departments 5

Translate Relationship Sets to Tables Foreign Keys: Keys for each participating entity set (?) Keys: This set of attributes forms superkey for relation (?) CREATE TABLE Works_In( ssn CHAR(11), did INTEGER, since DATE, PRIMARY KEY (ssn, did), FOREIGN KEY (ssn) REFERENCES Employees, FOREIGN KEY (did) REFERENCES Departments) since name dname ssn lot did budget Employees Works_In Departments 5

Translation to relational model? Key Constraints 1-to-1 1-to Many Many-to-1 Many-to-Many Translation to relational model? 6

Review: Key Constraint Each dept has at most one manager, according to key constraint Each department appears only once in relationship since lot name ssn dname did budget Manages Employees Departments Translation to relational model? 1-to Many 6

Translate Key Constraint : Approach I. Separate tables for Employees and Departments Note that did is key now! TABLE Dept(…) TABLE Employee (…) CREATE TABLE Manages( ssn CHAR(11), did INTEGER, since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, FOREIGN KEY (did) REFERENCES Departments) 7

Translate Key Constraint: Approach II. Combine Manages and Departments into one relation. Each department has a unique manager TABLE Employee (…) CREATE TABLE Dept_Mgr( did INTEGER, dname CHAR(20), budget REAL, ssn CHAR(11), since DATE, ) since lot name ssn dname did budget Manages Employees Departments 7

Translate Key Constraint: Approach II. TABLE Employee (…) CREATE TABLE Dept_Mgr( did INTEGER, dname CHAR(20), budget REAL, ssn CHAR(11), since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees) since lot name ssn dname did budget Manages Employees Departments 7

Participation + Key Constraint. Every department must have a manager ! Every did value in Departments table must appear in a row of the Manages table (with a non-null ssn value!) since since name name dname dname ssn lot did did budget budget Employees Manages Departments 8

Participation Constraints in SQL Approach I. every did value in Department appears in a tuple of Managers corresponding tuple must have a non-null ssn values Does this capture with “not-null” work ? TABLE Dept(…) TABLE Employee (…) CREATE TABLE Manages( ssn CHAR(11) NOT NULL, did INTEGER, since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, FOREIGN KEY (did) REFERENCES Departments, 9

Participation Constraints in SQL Approach I. every did value in Department appears in a tuple of Works_In the corresponding tuple must have a non-null ssn values TABLE Dept_mgr(…) TABLE Employee (…) CREATE TABLE Manages( ssn CHAR(11) NOT NULL, did INTEGER, since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, FOREIGN KEY (did) REFERENCES Departments, CHECK ( (SELECT Count(*) FROM Manages) = (SELECT Count(*) FROM Dept) ) Must utilize check constraints ! 9

Participation Constraints in SQL Approach II. - capture participation constraints involving one entity set in a binary relationship using combined table. TABLE Employee (…) CREATE TABLE Dept_Mgr( did INTEGER, dname CHAR(20), budget REAL, ssn CHAR(11) NOT NULL, since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, SEMANTICS ??? ) Does this “non-null” approach now work ? 9

Participation Constraints in SQL Approach II. - capture participation constraints involving one entity set in a binary relationship using combined table. TABLE Employee (…) CREATE TABLE Dept_Mgr( did INTEGER, dname CHAR(20), budget REAL, ssn CHAR(11) NOT NULL, since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, SEMANTICS ??? ) What should happen if manager-employee is deleted? 9

Participation Constraints in SQL Approach II. - use the “on action” propagation constraint ! CREATE TABLE Dept_Mgr( did INTEGER, dname CHAR(20), budget REAL, ssn CHAR(11) NOT NULL, since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, ON DELETE NO ACTION) 9

More on Participation Constraints What about other cases of “must have” constraint ? since since name name dname dname ssn lot did did budget budget Employees Manages Departments Works_In since What if we want to capture participation for many-to-many relationships? Anwer: We need to use CHECK constraints. 8

Review: Weak Entities A weak entity can be identified uniquely only by considering primary key of another (owner) entity. Owner entity set and weak entity set must participate in a one-to-many relationship set (1 owner, many weak entities). Weak entity set must have total participation in this identifying relationship set. name cost ssn pname lot age Employees Policy Dependents 10

Translating Weak Entity Sets Weak entity set and identifying relationship set are translated into a single table. CREATE TABLE Dep_Policy ( pname CHAR(20), age INTEGER, cost REAL, ssn CHAR(11) NOT NULL, --- (?), PRIMARY KEY (pname, ssn), --- (?) FOREIGN KEY (ssn) REFERENCES Employees, WHAT SEMANTICS HERE ??? ) 11

Translating Weak Entity Sets When the owner entity is deleted, all owned weak entities must also be deleted CREATE TABLE Dep_Policy ( pname CHAR(20), age INTEGER, cost REAL, ssn CHAR(11), PRIMARY KEY (pname, ssn), FOREIGN KEY (ssn) REFERENCES Employees, ON DELETE CASCADE) 11

Review: ISA Hierarchies Attributes are inherited name ssn lot Employees hourly_wages hours_worked contractid ISA ISA Hourly_Emps Contract_Emps 12

Translating ISA Hierarchies What are possible alternatives of mapping IS-A to the relational model ? 13

Translating ISA Hierarchies Alternative : Three Relations Employees ( ssn, name, lot) Hourly_Emps (ssn, hourly_wages, hours_worked); Contract_Emps (ssn, contractid); Alternative: Two Relations Hourly_Emps (ssn, name, lot, hourly_wages, hours_worked) Contract_Emps (ssn, name, lot, contractid) Alternative: One Relation Emps (ssn, name, lot, hourly_wages, hours_worked,contractid) 13

Pros/Cons : Translating ISA Hierarchies Pros/cons for three relations: + Queries involving all employees easy Queries involving just Hourly_Emps may require accessing multiple tables Pros/Cons for two relations: If all employees must be of the subentity type (“total”), then no need to create a table for the super-entity type This design has each employee in one of these two subclasses. Avoid joins for subtable queries Disadvantage that keys are stored redundantly. Pros/Cons for one relation: Looses isa semantics May have many many nulls 13

ISA Hierarchy Translation? name ssn lot Employees hourly_wages hours_worked ISA contractid Hourly_Emps Contract_Emps Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps entity? (Allowed/disallowed) Covering constraints: Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity? (Yes/no) 12

Relations Corresponding to Aggregation To represent aggregation, create a table with: primary key of the aggregated relationship primary key of the associated entity set any descriptive attributes

Mapping Aggregation Manages between aggregation relationship works-on and entity manager:

Mapping Aggregation create table manages(employee-id, branch-name, title, manager-name)

Summary ER Modeling : graphical design view Relational Model: A tabular representation of data. Rules to translate ER to relational model exist Later : More design optimizations can be applied, after initial relational design has been derived. 15