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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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