From ER to RM to SQL

Requirement Conceptual Logical Physical

Analysis Model Model Model
How can you transform the following ER model into
a relational schema?

⚫ Using a visual representation, provide:

 Tables and its attributes
 Primary Key of each table
 Foreign keys when applicable
 Entity Sets
⚫ Entity sets are translated to tables.
Relational
ER Diagram Employee
RUT name age

SQL
CREATE TABLE Employee
(RUT CHAR(11),
name CHAR(20),
age INTEGER,
PRIMARY KEY (RUT));
 Relationship Sets
⚫ Relationship sets are also translated to tables.
Keys for each participating entity set (as foreign keys).
 All descriptive attributes of the relationship set.

ER Diagram Relational

Employee Department
RUT name age did dname budget

works_in
RUT did since
 Relationship Sets
ER Diagram

SQL

Relational CREATE TABLE Works_In(

ssn CHAR(11),
Employee Department did INTEGER,
RUT name age did dname budget since DATE,
PRIMARY KEY (ssn, did),
FOREIGN KEY (ssn) REFERENCES Employee,
works_in FOREIGN KEY (did) REFERENCES Department);
RUT did since
 Key Constraints
ER Diagram
Relational v1

Employee Department
RUT name age did dname budget

works_in manages
RUT did since did RUT since

Relational v2
Employee
⚫ 2 choices RUT name age
 Map relationship set to a table
⚫ Separate tables for Employees and Departments. Department
⚫ Note that did is the key now! did dname budget Manager MangerSince

 Since each department has a unique manager, works_in

we could instead combine Manages and RUT did since
Departments.
 Key Constraints
Relational v1 SQL

Employee Department CREATE TABLE Manages(

RUT name age did dname budget RUT CHAR(11),
did INTEGER,
since DATE,
PRIMARY KEY (did),
works_in manages FOREIGN KEY (ssn) REFERENCES Employees,
RUT did since did RUT since FOREIGN KEY (did) REFERENCES Departments)

⚫ Choice 1
 Map relationship set to a table
⚫ Separate tables for Employees and
Departments.
⚫ Note that did is the key now!
 Key Constraints
Relational v2
Employee SQL
RUT name age
CREATE TABLE Department(
did INTEGER,
Department
dname CHAR(20),
did dname budget manager mangerSince budget REAL,
manager CHAR(11),
works_in mangerSince DATE,
RUT did since PRIMARY KEY (did),
FOREIGN KEY (manager) REFERENCES Employee)

⚫ Choice 2
 Since each department has a unique
manager
 Combine Manages and Departments!!
 Participation Constraints
⚫ We can capture participation constraints (at least one relationships) involving one
entity set in a binary relationship, using NOT NULL.
⚫ In other cases, we need CHECK constraints.

CREATE TABLE Department(

did INTEGER,
dname CHAR(20),
budget REAL,
manager CHAR(11) NOT NULL,
mangerSince DATE,
PRIMARY KEY (did),
FOREIGN KEY (manager) REFERENCES Employee)
 Weak Entity Sets
⚫ A weak entity set can be identified uniquely only by considering the primary key
of another (owner) entity set.
 Owner entity set and weak entity set must participate in a one-to-many relationship set
(one owner, many weak entities).
⚫ Weak entity has partial key. It’s primary key is made of
• Its own partial key
• Primary key of Strong Entity
 Weak entity set must have total participation in this identifying relationship set.

Partial Key
 Weak Entity Sets
⚫ Weak entity set and identifying relationship set
are translated into a single table.
 When the owner entity is deleted, all owned
weak entities must also be deleted.

CREATE TABLE Employee (

RUT CHAR(20) PRIMARY KEY,
name CHAR(20),
email CHAR(20));

CREATE TABLE Dependant ( Dependant

employee CHAR(20), employee name age

name CHAR(20),
age REAL,
Employee
PRIMARY KEY (employee, name),
RUT name email
FOREIGN KEY (employee) REFERENCES Employee
ON DELETE CASCADE);
 Example

CREATE TABLE Match (

homeTeam CHAR(20),
visitorTeam CHAR(20),
date DATE,
Team Location score_home INTEGER,
name locName address score_visitor INTEGER,
locName CHAR(20)
PRIMARY KEY (homeTeam, visitorTeam,date),
FOREIGN KEY (homeTeam) REFERENCES Team
Match
ON DELETE CASCADE
homeTeam visitorTeam date score_home score_visitor locName
ON UPDATE CASCADE,
FOREIGN KEY (visitorTeam) REFERENCES Team,
ON DELETE CASCADE
ON UPDATE CASCADE,
FOREIGN KEY (locName) REFERENCES Location);
 Subclasses
⚫ declare A ISA B
 every A entity is also considered to be a B
entity
 A is a specialization of B
⚫ Attributes of B are inherited to A.
⚫ Overlap constraints
 Can Joe be an Hourly_Emps as well as a
Contract_Emps entity?
⚫ depends
⚫ Covering constraints
 Does every Employees
entity either have to be an
Hourly_Emps or a
Contract_Emps entity?
⚫ depends
 Subclasses
⚫ One table for each of the entity
sets (superclass and
subclasses).
⚫ ISA relationship does not
require additional table.
⚫ All tables have the same key,
i.e. the key of the superclass.
⚫ E.g.: One table each for
Employees, Hourly_Emps and
Contract_Emps.
 General employee attributes are
Employee
recorded in Employees
RUT name email
 For hourly emps and contract
emps, extra info recorded in the
respective relations hourlyEmp contractEmp
RUT Hourly_wages Hours_worked RUT contractID
 Subclasses
CREATE TABLE Employees(
Employee RUT CHAR(11) PRIMARY KEY,
RUT name email name CHAR(20),
email CHAR(20));

hourlyEmp contractEmp
RUT hourly_wages hours_worked RUT contractID

CREATE TABLE HourlyEmp( CREATE TABLE contractEmp(

RUT CHAR(11) PRIMARY KEY, RUT CHAR(11) PRIMARY KEY,
hourly_wages INTEGER, contractID CHAR(20),
hours_worked INTEGER, FOREIGN KEY (RUT) REFERENCES Employees,
FOREIGN KEY (RUT) REFERENCES Employees, ON DELETE CASCADE)
ON DELETE CASCADE)

⚫ Queries involving all employees easy, those involving just Hourly_Emps

require a join to get their special attributes.
 Subclasses
⚫ Alternative translation
 Create tables for the subclasses
only. These tables have all
attributes of the superclass(es) and
the subclass.
 This approach is applicable only if
the subclasses cover the
superclass.
⚫ Queries involving all employees
difficult, those on Hourly_Emps and
Contract_Emps alone are easy.
hourlyEmp
⚫ Only applicable, if RUT name email hourly_wages hours_worked
Hourly_Emps AND Contract_Emps
COVER Employees
contractEmp
RUT name email contractID
 Summary
⚫ There are guidelines to translate ER diagrams to a relational database
schema.
⚫ However, there are often alternatives that need to be carefully considered.
⚫ Entity sets and relationship sets are represented by tables.
⚫ Some constructs of the ER model cannot be easily translated, e.g. multiple
participation constraints.
Example: from business rules to Relational Model

Requirement Conceptual Logical Physical

Analysis Model Model Model
 Walkthrough: Business Rules
⚫ Business Rules
 A Student can take many Courses
 A Course can be taken by many Students
 A Student can complete many Assessments
 An Assessment must be completed by at least one Student
 Every student that takes the assesment does it on given date and gets a grade
 A Course must have at least one Assessment
 An Assessment is for only one Course
 A Student has a StudentId, LastName, FirstName, Sex, Email, Htel and WTel
 A Course has a Code, ShortName, FullName and Description
 An Assessment has an AssessmentNo, Description and Weighting
 Walkthrough: ER model Design
⚫ Entities
 A Student has a StudentId, LastName, FirstName, Sex, Email, Htel and WTel
 A Course has a Code, ShortName, FullName and Description
 An Assessment has an AssessmentNo, Description and Weighting
 Walkthrough: ER model Design

⚫ Business Rules
 A Student can take many Courses
 A Course can be taken by many
Students
 A Student can complete many
Assessments
 An Assessment must be completed
by at least one Student. He takes the
assesment on a given date and gets
a grade
 A Course must have at least one
Assessment
 An Assessment is for only one
Course
 Walkthrough: From ER to RM
ER Diagram

Relational
Student
studentID firstName lastName Htel Wtel sex email

Assesment Course
AssNumber Description Weighting Code Fullname ShortName Description
 Walkthrough: From ER to RM
⚫ Group together tables (formerly entities) and their relationships that have a
cardinality of “at most one” (thick lines)

Assesment
AssNumber Description Weighting Course

Course
0 Code Fullname ShortName Description

Student
studentID firstName lastName Htel Wtel sex email
 Walkthrough: From ER to RM
⚫ Relationships whose cardinalities can be of more than one on both sides become new tables in
the new relational model.
 primary keys from the two tables
involved in the relationship
become a composite primary key
in the new table
 New table usually has a name
that is a combined form of the two
original table names

StudentCourse
studentID Code
 Walkthrough: From ER to RM
⚫ Relationships whose cardinalities can be of more than one on both sides become new tables in
the new relational model.

StudentAssesment
studentID AssNumber DateGiven Grade

0
 ER Diagram

Walkthrough
⚫ Final tables
⚫ Are they create in a specific
order?

Relational

StudentAssesment Assesment
studentID AssNumber DateGiven Grade AssNumber Description Weighting Course

StudentCourse Course
studentID Code Code Fullname ShortName Description

Student
studentID firstName lastName Htel Wtel sex email
 Walkthrough: From RM to SQL
⚫ Create tables with no dependencies first
Relational

Student Course
studentID firstName lastName Htel Wtel sex email Code Fullname ShortName Description

SQL

CREATE TABLE Student ( CREATE TABLE Course(

StudentID BIGINT PRIMARY KEY, Code VARCHAR(20),
firstName VARCHAR(100), FullName VARCHAR(100),
lastName VARCHAR(100), ShortName VARCHAR(100),
HTel VARCHAR(20), Description VARCHAR(8000),
WTel VARCHAR(20), PRIMARY KEY (Code) );
Sex CHAR(1),
EMail VARCHAR(100));
 Walkthrough
⚫ Create tables dependent on entities. Relational
⚫ Can we create StudentsAssessments?
 Not yet StudentCourse
studentID Code
⚫ Can we create StudentCourses?
 Yes!

SQL

Data types must be

CREATE TABLE StudentsCourses(
identical in all tables
Code VARCHAR(20),
referencing the same field!
StudentID BIGINT,
PRIMARY KEY (Code, StudentID), Note that by default we have:
FOREIGN KEY (Code) REFERENCES Course, ON DELETE NO ACTION
FOREIGN KEY (StudentID) REFERENCES Student); ON UPDATE NO ACTION
 Walkthrough
⚫ We can also create Assesment Relational

Assesment
AssNumber Description Weighting Course

SQL

CREATE TABLE Assessment(

AssNumber INTEGER,
Description VARCHAR(100),
Weighting DECIMAL(4,2),
Course VARCHAR(20),
PRIMARY KEY (AssNumber),
FOREIGN KEY (Course) REFERENCES Course
ON UPDATE SET NULL
ON DELETE CASCADE);
 Walkthrough
⚫ Now we can also create Relational
StudentAssesments
StudentAssesment
studentID AssNumber DateGiven Grade

SQL

CREATE TABLE StudentsAssessments(

studentID BIGINT,
AssNumber INTEGER,
DateGive DATE NOT NULL,
Grade DECIMAL(4,2),
PRIMARY KEY (AssNumber , studentID),
FOREIGN KEY (AssNumber) REFERENCES Assessment,
FOREIGN KEY (studentID) REFERENCES Student);
 CREATE TABLE Student( CREATE TABLE StdsAss (
CREATE TABLE Course(
StdID BIGINT PRIMARY KEY, AssNo INTEGER,
Code VARCHAR(20) PRIMARY KEY,
LName VARCHAR(100), StdID BIGINT,
…
… …
);
); PRIMARY KEY (AssNo , StdID),
CREATE TABLE Assessment( FOREIGN KEY (AssNo) REFERENCES Assessment,
AssNo INTEGER, FOREIGN KEY (StdID) REFERENCES Student);
Code VARCHAR(20),
CREATE TABLE StdsCourses(
…
Code VARCHAR(20),
PRIMARY KEY (AssNo),
StdID BIGINT,
FOREIGN KEY (Code) REFERENCES Course
PRIMARY KEY (Code, StdID),
ON UPDATE SET NULL
FOREIGN KEY (Code) REFERENCES Course,
ON DELETE CASCADE);
FOREIGN KEY (StdID) REFERENCES Student);

⚫ Can I have a Student that takes an Assesment of a Course in which he is not registered?

Student Course Assesment StdsCourse StdsAss

StdID … Code … AssNo Code … Code StdID … AssNo StdID …
11111 SDC11 1025 SDC11 DS12 7777 5684 77777
77777 DS12 5684 DS12 7 1025 11111
⚫ This instance satsifies all the PKs and FKs! But student 11111 took Assesment 1025 of course SCD11
without being registered in the course
 Solutions: modify schema or use other types of constraints that we will see later
 Student Course Assesment StdsCourse StdsAss
StdID … Code … AssNo Code … Code StdID … AssNo StdID …
11111 SDC11 1025 SDC11 DS12 7777 5684 7777
77777 DS12 5684 DS12 7 7
1025 11111
⚫ Can I remove course with code=‘SDC11’?
1. The reference from StdsCourse is not affected since no tuple in it references SDC11
2. The reference from Assesment is afected since it contains tuple (1025,SDC11).
3. Assessment has the instrucion “ON DELETE CASCADE” so we need to delete tuple (1025,SDC11)
4. Trying to delete (1025,SDC11) affects StdsAss which is set be default to NO ACTION. Thus,
the removal of (1025,SDC11) is rejected
5. Since the deletion of (1025,SDC11) was rejected, the removal of tuple (SDC11) from
Course is also rejected by the DBMS.