From ER to Relational Model. Book Chapter 3 (part 2 )

From ER to Relational Model Book Chapter 3 (part 2 )

Logical DB Design: ER to Relational Translate Entity sets to tables: ssn name Employees lot CREATE TABLE Employees (ssn CHAR(11), name CHAR(20), lot INTEGER, PRIMARY KEY (ssn))

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

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) name since dname ssn lot did budget Employees Works_In Departments

Translate Relationship Sets to Tables Foreign Keys: Keys: Keys for each participating entity set (?) 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) name since dname ssn lot did budget Employees Works_In Departments

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

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

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)

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, ) name since dname ssn lot did budget Employees Manages Departments

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) name since dname ssn lot did budget Employees Manages Departments

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!) name since dname ssn lot did budget Employees Manages Departments

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 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, Does this capture with not-null work?

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!

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?

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?

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)

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

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-tomany relationship set (1 owner, many weak entities). Weak entity set must have total participation in this identifying relationship set. name ssn lot cost pname age Employees Policy Dependents

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

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)

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

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

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)

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

ISA Hierarchy Translation? ssn name 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)

Relations Corresponding to Aggregation To represe t aggregatio, create a tab e ith: primary key of the aggregated re atio ship primary key of the associated e tity set a y descriptive attributes

Mapping Aggregation Manages bet ee aggregatio re atio ship works-on a d e tity manager:

Mapping Aggregation create tab e 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.