CSE 412 Database Management

Lecture 10
ER Translation
Jia Zou
Arizona State University

1
Review
• Data Definition Language
• Data Manipulation Language
• Basic Queries (SELECT-FROM-WHERE)
• ORDER BY
• Set Operations
• Null Values
• Aggregation
• Nested Queries

2
Scalar subqueries
• Which part has the highest retail price? (Return the partkey)

This is called as Scalar subqueries!

3
More Examples
• Returns me the names of customers whose account balance (c_acctbal) is
above average (larger than the average account balance of all customers.)

4
More Examples
• For each customer, returns his/her name and the difference between his
account balance and the average account balance of all customers.

5
SELECT in WITH
• For each customer, returns his/her name and the difference between
his account balance and the average account balance of all
customers.

6
Today’s Agenda
• Data Definition Language
• Data Manipulation Language
• Basic Queries (SELECT-FROM-WHERE)
• ORDER BY
• Set Operations
• Null Values
• Aggregation
• Nested Queries
• ER Translation
(We will learn data modification language (Insert, Update, Delete),
Intermediate SQL and Advanced SQL after the Midterm 1)
7
Review

8
Wrap-up

9
Wrap-up

10
Wrap-up

11
From this lecture on, we will discuss
• Phase 1: Requirement Analysis
• What users/apps expect from the database
• Phase 2: Conceptual Database Design
• Build ER (Entity-Relationship) diagram
• Phase 3: Logical Database Design
• Convert ER design into a relational database schema

12
Outline
• Strong entities
• (Binary) relationships
• 1-to-1, 1-to-many, etc
• total/partial participation
• Weak entities
• ISA-hierarchies
• Ternary relationships
• Aggregation

13
Logical DB Design: ER to Relational
• (Strong) entity sets to tables

14
Logical DB Design: ER to Relational
• (Strong) entity sets to tables

15
Relationship Sets to Tables

Country – Capital City Order – Customer

Employee – Department

Supervisor – Supervisee Course – Student

16
Author -- Paper
Relationship Sets to Tables
• Many-to-many:

17
Relationship Sets to Tables
• Many-to-many:

did dname budget

51 toy 20000
56 book 10000
18
Relationship Sets to Tables
In the table for a many-to-many relationship set, the key is the
keys from participating entity sets.
• Many-to-many: In the same time, each of these keys defines a foreign key
constraint.

did dname budget

51 toy 20000
56 book 10000
19
Relationship Sets to Tables
• Key of many-to-many
relationships:
• Keys from participating entity sets
(as foreign keys).

20
Relationship Sets to Tables

Keys from participating

entity sets (as foreign keys).

21
Relationship Sets to Tables
• 1-to-many:

ssn name lot did dname budget

did ssn since
123-22-6666 Attishoo 48 51 toy 20000
51 123-22-6666 1/1/91
131-24-3650 Smethurst 35 56 book 10000
56 123-22-6666 3/3/93

22
Relationship Sets to Tables In the table for a one-to-many or many-to-one
relationship set, the key is the key from the
“many” part.
• 1-to-many:
In the same time, each of participants’ keys define
the a foreign key constraint.

ssn name lot did dname budget

did ssn since
123-22-6666 Attishoo 48 51 toy 20000
51 123-22-6666 1/1/91
131-24-3650 Smethurst 35 56 book 10000
56 123-22-6666 3/3/93

23
Relationship Sets to Tables
• 1-to-many:

ssn name lot did dname budget

did ssn since
123-22-6666 Attishoo 48 51 toy 20000
51 123-22-6666 1/1/91
131-24-3650 Smethurst 35 56 book 10000
56 123-22-6666 3/3/93

24
Relationship Sets to Tables
Key from the “many” part.

Keys from participating

entity sets (as foreign keys).

25
 Why not:
• 1-to-many:

ssn name lot did dname budget Ssn since

123-22-6666 Attishoo 48 51 toy 20000 123-22-6666 1/1/91
131-24-3650 Smethurst 35 56 book 10000 123-22-6666 3/3/93
26
 Why not:
What if the toy department has no manager (yet)?
• 1-to-many:

ssn name lot did dname budget Ssn since

123-22-6666 Attishoo 48 51 toy 20000 123-22-6666 1/1/91
131-24-3650 Smethurst 35 56 book 10000 123-22-6666 3/3/93
27
 What if the toy department has no manager (yet)?
Why not: It cannot handle this, unless we enforce “thick
arrow” participant constraints.
• 1-to-many:

ssn name lot did dname budget Ssn since

123-22-6666 Attishoo 48 51 toy 20000 123-22-6666 1/1/91
131-24-3650 Smethurst 35 56 book 10000 123-22-6666 3/3/93
28
Relationship Sets to Tables
Key from the “many” part: If thick
arrow: 2 tables; If thin arrow: 3 tables

Keys from participating

entity sets (as foreign keys).

29
Relationship Sets to Tables
Key from the “many” part.

Keys from participating

entity sets (as foreign keys).

30
Relationship Sets to Tables
Key from the “many” part.
Key from either part.

Keys from participating

entity sets (as foreign keys).

31
Outline
• Strong entities
• (Binary) relationships
• 1-to-1, 1-to-many, etc
• total/partial participation
• Weak entities
• ISA-hierarchies
• Ternary relationships
• Aggregation

32
Review: Participation Constraints
• Does every department have a manager?
• If so, this is a participation constraint: the participation of Departments in
Manages is said to be total (vs. partial).
• Every did value in Departments table must appear in a row of the Manages table (with a
non-null ssn value!)

33
 Participation Constraints in SQL
• We can capture participation constraints involving one entity set in a
binary relationship.

ssn name lot

123-22-6666 Attishoo 48
131-24-3650 Smethurst 35

did dname budget Ssn since

51 toy 20000 123-22-6666 1/1/91
56 book 10000 123-22-6666 3/3/93

34
 Participation Constraints in SQL
• Total participation (‘no action’ -> do NOT do the delete)
• i.e., a department MUST have a manager

ssn name lot

123-22-6666 Attishoo 48
131-24-3650 Smethurst 35

did dname budget Ssn since

51 toy 20000 123-22-6666 1/1/91
56 book 10000 123-22-6666 3/3/93

35
 Participation Constraints in SQL
• Partial participation, i.e. a department may be headless

ssn name lot

123-22-6666 Attishoo 48
131-24-3650 Smethurst 35

did dname budget Ssn since

51 toy 20000 123-22-6666 1/1/91
56 book 10000 123-22-6666 3/3/93

36
Participation Constraints in SQL
• Partial partipation, ie, a department may be headless
• OR (better): use the three-table solution (without the foreign key
definition)
ssn name lot
123-22-6666 Attishoo 48
131-24-3650 Smethurst 35

did ssn since

51 123-22-6666 1/1/91
56 123-22-6666 3/3/93

did dname budget

51 toy 20000
56 book 10000 37
Outline
• Strong entities
• (Binary) relationships
• 1-to-1, 1-to-many, etc
• total/partial participation
• Weak entities
• ISA-hierarchies
• Ternary relationships
• Aggregation

38
Review: Weak Entities
• A weak entity can be identified uniquely only by considering the
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.

39
Review: Weak Entities
• How to turn ‘Dependents’ into a table?

40
Translating Weak Entity Sets
• Weak entity set and identifying relationship set are translated into a
single table (== ‘total participation’)

41
 Participation Constraints in SQL
• We can capture participation constraints involving one entity set in a
binary relationship.

ssn name lot

123-22-6666 Attishoo 48
131-24-3650 Smethurst 35

did dname budget Ssn since

51 toy 20000 123-22-6666 1/1/91
56 book 10000 123-22-6666 3/3/93

42
Translating Weak Entity Sets
• Weak entity set and identifying relationship set are translated into a
single table (== ‘total participation’)
• When the owner entity is deleted, all owned weak entities must also be
deleted (-> ‘CASCADE’)

43
Outline
• Strong entities
• (Binary) relationships
• 1-to-1, 1-to-many, etc
• total/partial participation
• Weak entities
• ISA-hierarchies
• Ternary relationships
• Aggregation

44
Review: ISA Hierarchies

• 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)
45
Drill:
• What would you do?

46
Translating ISA Hierarchies to Relations
• General approach: 3 relations: Employees, Hourly_Emps and
Contract_Emps.
• how many times do we record an employee?
• what to do on deletion?
• how to retrieve all info about an employee?

47
Why not:
• Alternative: Just Hourly_Emps and Contract_Emps.
• Hourly_Emps: ssn, name, lot, hourly_wages, hours_worked.
• Each employee must be in one of these two subclasses.

48
Why not:
• Alternative: Just Hourly_Emps and Contract_Emps.
• Hourly_Emps: ssn, name, lot, hourly_wages, hours_worked.
• Each employee must be in one of these two subclasses.

Notice: ‘black’ is gone! So it is fine if Covering constraint

is “yes”, but not fine if there is no covering constraint. 49
Why not:
• Alternative: 1 table + nulls

Employee information Hourly information Contractors information

50
Why not:
• Alternative: 1 table + nulls

Employee information Hourly information Contractors information

It can work, but the table is sparse, may contain a lot of

null values, which is not storage-efficient 51
Outline
• Strong entities
• (Binary) relationships
• 1-to-1, 1-to-many, etc
• total/partial participation
• Weak entities
• ISA-hierarchies
• Ternary relationships
• Aggregation

52
Ternary relationships; aggregation
• rare
• keep keys of all participating entity sets

53
Ternary relationships; aggregation
• rare
• keep keys of all participating entity sets

(or: avoid such situations: break into 2-

way relationships)

54
Review: Database Design and ER-to-relational
Translation
• strong entities:
• key -> primary key
• (binary) relationships:
• get keys from all participating entities - pr. key:
• 1:1 -> either key
• 1:N -> the key of the ‘N’ part
• M:N -> both keys
• total/partial participation:
• Total participation: 2 tables
• Partial participation: 3 tables
• NOT NULL; ON DELETE NO ACTION

55
Review: Database Design and ER-to-relational
Translation
• weak entities:
• Total participation: 2 tables
• strong key + partial key -> primary key
• ..... ON DELETE CASCADE
• ISA:
• 2 tables (‘total coverage’)
• 3 tables (most general)
• ternary relationships:
• get keys from all; decide which one(s) -> prim. key
• aggregation: like ternary relationships

56
Now we have a relational database designed
• A Database: A set of relations
• A relation:
• rows: tuples
• columns: attributes
• Keys:
• superkey
• key
• primary key
• candidate key
• foreign key
• Constraints:
• domain constraints
• primary key constraints: unique, non null
• foreign key constraints: on delete no action, on delete set null, on delete cascade

57