SOEN 363 - Data Systems

for Software Engineers

Lecture 3: the Relational Model

Essam Mansour
 Today…
 Last Session:
 The entity relationship (ER) model

 Today’s Session:
 ER model (Cont’d): conceptual design choices
 The relational model
 Basic Constructs of the relational model
 Basic SQL

2
 Participation Constraints
 Consider again the “Employees” and “Departments” entity sets as well as the
“Manages” relationship set
 Should every department have a manager?
 If so, this is a participation constraint
 Such a constraint entails that every Departments entity must appear in an
instance of the Manages relationship
 The participation of Departments in Manages is said to be total (vs. partial)
since
name dname
ssn lot did budget

Employees Manages Departments

Total participation is Works_In Total participation +

denoted by a thick line key constraint are
denoted by a thick arrow
since 3
 Total vs. Partial Participations

Total, Total COUNTRY has CAPITAL

?? PERSON owns CAR

?? STUDENT takes SECTION

4
 Total vs. Partial Participations

Total, Total COUNTRY has CAPITAL

Partial, Total PERSON owns CAR

?? STUDENT takes SECTION

5
 Total vs. Partial Participations

Total, Total COUNTRY has CAPITAL

Partial, Total PERSON owns CAR

Partial, Total STUDENT takes SECTION

6
 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 (one owner, many weak entities)
 Weak entity set must have total participation in this
identifying relationship set

 The set of attributes of a weak entity set that uniquely

identifies a weak entity for a given owner entity is called
partial key

7
 Weak Entities: An Example
 “Dependents” has no unique key of its own
 “Dependents” is a weak entity with partial key “pname”
 “Policy” is an identifying relationship set
 “pname” + “ssn” are the primary key of “Dependents”

Partial keys are underlined

using broken lines
name
cost pname age
ssn lot

Employees Policy Dependents

Weak entities and identifying relationships

are drawn using thick lines 8
 ISA (`is a’) Hierarchies
 Entities in an entity set can sometimes be classified into subclasses
(this is “kind of similar” to OOP languages)

 If we declare B ISA A, every B entity is also considered to be an A entity

name
ssn lot

“Employees” Employees “Hourly_Emps”

is specialized and
into subclasses hourly_wages hours_worked “Contract_Emps”
ISA are generalized
contractid by “Employees”

Hourly_Emps Contract_Emps

9
 Overlap and Covering Constraints
 Overlap constraints A
 Can an entity belong to
both ‘B’ and ‘C’?

 Covering constraints
B C
 Can an ‘A’ entity belong
to neither ‘B’ nor ‘C’?

10
 Overlap Constraints: Examples
 Overlap constraints A
 Can John be in Hourly_Emps and
Contract_Emps? Intuitively, no

 Can John be in Contract_Emps

and in Senior_Emps? B C
Intuitively, yes 
“Contract_Emps OVERLAPS Senior_Emps”

11
 Covering Constraints: Examples
 Covering constraints A
 Does every one in Employees
belong to a one of its subclasses?
Intuitively, no

 Does every Motor_Vehicles B C

entity have to be either a
Motorboats entity or
a Cars entity? Intuitively, yes 
“Motorboats AND Cars COVER Motor_Vehicles”
12
 More Details on ISA Hierarchies
 Attributes are inherited (i.e., if B ISA A, the attributes
defined for a B entity are the attributes for A plus B)

 We can have many levels of an ISA hierarchy

 Reasons for using ISA:

 To add descriptive attributes specific to a subclass
 To identify entities that participate in a relationship

13
 Outline

ER Model: Conceptual Design Choices

and Summary 
The Relational Model: Introduction

The Relational Model: Basic SQL

14
 Conceptual Design Choices
 Should a concept be modeled as an entity or an attribute?

 Should a concept be modeled as an entity or a relationship?

 How should we identify relationships?

 Binary or ternary?
 Ternary or aggregation?

 Constraints in the ER Model:

 A lot of data semantics can (and should) be captured
 But some constraints cannot be captured in ER diagrams
15
 Entity vs. Attribute
 Should address be an attribute of Employees or an
entity (connected to Employees by a relationship)?

 This depends upon the use we want to make of

address information, and the semantics of the data
 If we have several addresses per an employee, address
must be an entity (since attributes cannot be set-valued)
 If the structure (city, street, etc.) is important (e.g., we want
to retrieve employees in a given city), address must be
modeled as an entity

16
 Entity vs. Attribute (Cont’d)
 Consider the following ER diagram:
from to
name dname
ssn lot did budget

Employee Works_In4 Department

 A problem: Works_In4 does not allow an employee to work in a

department for two or more periods

 Solution: introduce “Duration” as a new entity set

name dname
ssn lot did budget

Employee Works_In4 Department

from Duration to 17
 Entity vs. Relationship
 Consider the following ER diagram, whereby a manager gets a separate
discretionary budget for each department
since dbudget
name dname
ssn lot did budget

Employee Manages2 Department

 What if a manager gets name

ssn lot
a discretionary budget
that covers all since dname
managed departments? Employee did budget
 Redundant data
Manages2 Department
 Misleading ISA

This fixes the

Managers dbudget problem!
18
 Binary vs. Ternary Relationships
name
ssn lot pname age

Employee Covers Dependent

If each policy is
owned by just 1
employee: Policies

policyid cost

19
 Binary vs. Ternary Relationships
name
ssn lot pname age

Employee Covers Dependent

If each policy is
owned by just 1
employee: Policies

policyid cost

Bad design!

Key constraint on Policies would mean policy can only cover 1 dependent!

20
 Binary vs. Ternary Relationships
name pname age
ssn lot
Dependents
Employees
If each policy is
owned by just 1 Purchaser
Beneficiary

employee:
Policies

policyid cost

Better design!

21
 Binary vs. Ternary Relationships
 But sometimes ternary relationships cannot
be replaced by a set of binary relationships

22
 Binary vs. Ternary Relationships
 But sometimes ternary relationships cannot
be replaced by a set of binary relationships
qty

Parts Contract Departments VS.

Parts Departments
Suppliers

can-supply
Suppliers deals-with

23
 Binary vs. Ternary Relationships
 But sometimes ternary relationships cannot
be replaced by a set of binary relationships
qty

Parts Contract Departments VS.

Parts Departments
Suppliers

can-supply
Suppliers deals-with

24
 Binary vs. Ternary Relationships
 But sometimes ternary relationships cannot
be replaced by a set of binary relationships
qty

Part Contract Department VS.

Part Department
Supplier

can-supply
Supplier deals-with

Why is it bad?
25
 Binary vs. Ternary Relationships
 But sometimes ternary relationships cannot
be replaced by a set of binary relationships
 S “can-supply” P,
D “needs” P, and D
“deals-with” S do not VS.
imply that D
has agreed to buy P Parts Departments
from S
can-supply
 How do we record Suppliers deals-with
qty?
Why is it bad?
26
 ER Model: Summary
 Conceptual design follows requirements analysis
 Yields a high-level description of data to be stored

 The ER model is popular for conceptual design

 Its constructs are expressive, close to the way
people think about their applications

 The basic constructs of the ER model are:

 Entities, relationships, and attributes (of entities
and relationships)
27
 ER Model: Summary
 Some additional constructs of the ER model are:
 Weak entities, ISA hierarchies, and aggregation

 Several kinds of integrity constraints can be

expressed in the ER model
 Key constraints, participation constraints, and
overlap/covering constraints for ISA hierarchies

 Note: there are many variations on the ER model

28
 ER Model: Summary
 ER design is subjective
 There are often many ways to model a given scenario!

 Analyzing alternatives can be tricky, especially for a

large enterprise

 Common choices include:

 Entity vs. attribute
 Entity vs. relationship
 Binary or n-ary relationship (e.g., ternary)
 Whether or not to use ISA hierarchies
 Whether or not to use aggregation 29
 Outline

ER Model: Conceptual Design Choices

and Summary

The Relational Model: Introduction


The Relational Model: Basic SQL

30
 Why Studying the Relational Model?
 Most widely used model
 Vendors: IBM/Informix, Microsoft, Oracle, Sybase, etc.

 “Legacy systems” in older models

 E.g., IBM’s IMS

 Object-Oriented concepts have merged into

 An object-relational model
 Informix->IBM DB2, Oracle 8i
31
 What is the Relational Model?
 The relational model adopts a “tabular” representation
 A database is a collection of one or more relations
 Each relation is a table with rows and columns

 What is unique about the relational model as opposed

to older data models?
 Its simple data representation
 Ease with which complex queries can be expressed

32
 Basic Constructs
 The main construct in the relational model is the relation

 A relation consists of:

1. A schema which includes:
 The relation’s name
 The name of each column
 The domain of each column

2. An instance which is a set of tuples

 Each tuple has the same number of columns as the
relation schema
33
 The Domain Constraints
 A relation schema specifies the domain of each column which
entails domain constraints

 A domain constraint specifies a condition by which each

instance of a relation should satisfy
 The values that appear in a column must be drawn from the
domain associated with that column

 Who defines a domain constraint?

 DBA
 Who enforces a domain constraint?
 DBMS 34
 More Details on the Relational Model
Degree (or arity) = # of fields

sid name login age gpa

53666 Jones jones@cs 18 3.4
Cardinality = 53688 Smith smith@eecs 18 3.2
# of tuples
53650 Smith smith@math 19 3.8
An instance of the “Students” relation

 What is the relational database schema (not the relation schema)?

 A collection of schemas for the relations in the database

 What is the instance of a relational database (not the instance

of a relation)?
 A collection of relation instances 35
 A To-Do List

 Textbook:
 Raghu Ramakrishnan and Johannes Gehrke,
"Database Management Systems", Third Edition,
McGraw-Hill, download it here
 Read Chapter 1 and 2

36
 Next Class

The Relational Model (Cont’d)

and SQL

37