Phases of Database Design

Data
Requirements  Conceptual design begins with the
Specification of requirements
and results
collection of requirements and results
Conceptual
needed from the database (ER Diag.)
Design
 Logical schema is a description of the
Conceptual Schema structure of the database (Relational,
Logical Network, etc.)
Design
 Physical schema is a description of
Logical Schema
the implementation (programs, tables,
Physical dictionaries, catalogs
Design

Physical Schema
1
 Overview of Database Design
• Requirements Analysis: Understand what data will be stored in
the database, and the operations it will be subject to.
• Conceptual Design: (ER Model is used at this stage.)
• What are the entities and relationships in the enterprise?
• What information about these entities and relationships should
we store in the database?
• What are the integrity constraints or business rules that hold?
• A database `schema’ in the ER Model can be represented
pictorially (ER diagrams).
• Can map an ER diagram into a relational schema.
• Logical Design: Convert the conceptual database design into the
data model underlying the DBMS chosen for the application.
 Overview of Database Design (cont.)

• Schema Refinement: (Normalization) Check relational

schema for redundancies and anomalies.
• Physical Database Design and Tuning: Consider typical
workloads and further refinement of the database design (v.g. build
indices).
• Application and Security Design: Consider aspects of the
application beyond data. Methodologies like UML often used for
addressing the complete software development cycle.
 name
ssn lot
ER Model Basics
Employees

• Entity: Real-world object distinguishable from

other objects. An entity is described using a set of
attributes.
• Entity Set: A collection of entities of the same
kind. E.g., all employees.
• All entities in an entity set have the same set of
attributes.
• Each entity set has a key(a set of attributes uniquely
identifying an entity).
• Each attribute has a domain.
 name

ER Model Basics (Contd.) ssn lot

since Employees
name dname
super-
ssn lot did budget visor subor-
dinate
Reports_To
Employees Works_In Departments
• Relationship: Association among two or more entities. E.g., Peter works in
Pharmacy department.
• Relationship Set: Collection of similar relationships.
• An n-ary relationship set R relates n entity sets E1 ... En; each relationship in
R involves entities e1  E1, ..., en  En
• Same entity set could participate in different relationship sets, or in different
“roles” in same set.
• Relationship sets can also have descriptive attributes (e.g., the since attribute of
Works_In). A relationship is uniquely identified by participating entities
without reference to descriptive attributes.
 Self Relationship
 Sometimes entities in a entity set may relate to other
entities in the same set. Thus self relationship
 Here employees mange some other employees
 The labels “manger” and “worker” are called roles
the self relationship
 Key Constraints
(a.k.a. Cardinality) since
name dname
• Consider Works_In (in
ssn lot did budget
previous slide): An
employee can work in
many departments; a Employees Manages Departments
dept can have many
employees.
• In contrast, each dept
has at most one
manager, according to
the key constraint on
Manages.
1-to-1 1-to Many Many-to-1 Many-to-Many
Constraints are IMPORTANT because they must be ENFORCED
when IMPLEMENTING the database
 Key Constraints name

(ternary relationships)
Location
name dname
ssn lot did budget
Each employee can work at
most in one department at
a single location
Employees works_In Departments

12-233 D10

12-354 • D12

12-243
•
• Rome
D13
12-299 •
London

Paris
 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 Department MUST have at least an employee
• Every employee MUST work at least in one department
• There may exist employees managing no department

since
name dname
ssn lot did budget

Employees Manages Departments

Works_In

since
 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 sets must have total participation in this identifying relationship
set.
• transac# is a discriminator within a group of transactions in an ATM.

address
atmID since transac# amount

type
ATM Transactions
 name
ssn lot
ISA (`is a’) Hierarchies
Employees
As in C++, or other PLs, attributes
are inherited. hourly_wages hours_worked
ISA
Ifwe declare A ISA B, every A entity is contractid
also considered to be a B entity.
Hourly_Emps Contract_Emps

• Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps

entity? if so, specify => Hourly_Emps OVERLAPS Contract_Emps.
• Covering constraints: Does every Employees’ entity also have to be an
Hourly_Emps or a Contract_Emps entity?. If so, write Hourly_Emps AND
Contract_Emps COVER Employees.

» Reasons for using ISA:

To add descriptive attributes specific to a subclass.
To identify entities that participate in a relationship.
 name
ssn lot

Aggregation Employees

• Used when we have to

model a relationship Monitors until
involving (entity sets
and) a relationship set.
• Aggregation allows us started_on since
to treat a relationship dname
pid pbudget did budget
set as an entity set for
purposes of
participation in (other) Projects Sponsors Departments
relationships.
• Employees are assigned  Aggregation vs. ternary relationship:
to monitor
SPONSORSHIPS.
 Monitors and Sponsors are distinct relationships,
with descriptive attributes of their own.
 Also, can say that each sponsorship
is monitored by at most one employee (which we
cannot do with a ternary relationship).
 Conceptual Design Using the ER
Model
• Design choices:
• Should a concept be modeled as an entity or an attribute?
• Should a concept be modeled as an entity or a relationship?
• Identifying relationships: Binary or ternary? 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.
Key in a table
 A key in a table is a field or group of fields that creates identity, makes relationship with another
table and/or make a table more efficient.
Super Key – An attribute or a combination of attribute that is used to identify the records uniquely is
known as Super Key. A table can have many Super Keys.
E.g. of Super Key
1 ID
2 ID, Name
3 ID, Address
4 ID, Department_ID
5 ID, Salary
6 Name, Address
7 Name, Address, Department_ID ………… So on as any combination which can identify the records
uniquely will be a Super Key. table or be NULL.
(II) Candidate Key – It can be defined as minimal Super Key or irreducible
Super Key. In other words an attribute or a combination of attribute that
identifies the record uniquely but none of its proper subsets can identify the
records uniquely.
E.g. of Candidate Key
1 Code
2 Name, Address
For above table we have only two Candidate Keys (i.e. Irreducible Super
Key) used to identify the records from the table uniquely. Code Key can
identify the record uniquely and similarly combination of Name and Address
can identify the record uniquely, but neither Name nor Address can be used
to identify the records uniquely as it might be possible that we have two
employees with similar name or two employees from the same house.
Primary Key & Foreign
 A Primary key is a key that uniquely identifies a row in each table. It is
normally denoted with its first two letters, namely, PK.
 A Foreign key is a key borrowed from another related table (that’s why its

foreign) in order to make the relationship between two tables. It is normally

denoted with its first two letters, namely, FK.
Examples from Premier Database – Primary Key

Repnum uniquely identifies the Rep table

and is the primary key of this table.
Examples from Premier Database – Primary Key

Customernum uniquely identifies the Customer table

and is the primary key of this table.
Examples from Premier Database – Primary Key

Ordernum and Partnum makes up the primary key

Of the OrderLine table. This is what is known as a Composite
Primary key, that is, primary key that is made up of more than
one field.
Examples from Premier Database –
Foreign Key

Repnum is a Foreign key borrowed from Rep table

Notation example

Customer Rep
1
Customernum (PK) Repnum (PK)
Customername Lastname
Street Firstname
City Street
State City
Zip State
Balance Zip
CreditLimit Commission
Repnum (FK) M Rate

 One Rep could have one or more customer (one to many) using
Primary and foreign key to create the relationship.
Notation example

Customer Rep
1
Customernum (PK) Repnum (PK)
Customername Lastname
Street Firstname
City Street
State City
Zip State
Balance Zip
CreditLimit Commission
Repnum (FK) M Rate

 Always remember the many side has the Foreign key. In this case the many side is on the Customer
table and therefore has the foreign key Repnum which is the primary key of Rep table.
Referential Integrity
 Referential Integrity means that the Foreign key must match in terms of
actual values and data types with the related Primary Key.
Referential Integrity
 Example:

 The foreign key RepNum in Customer must match

with the primary key RepNum in Rep table.
Referential Integrity
 In terms of Data Type

 Customer RepNum (Foreign Key) has Text Data type

and Rep RepNum (Primary Key) has also Text Data
type.
Notations used in ER diagram

Yan Huang - ER 01/11/2021 26

Notations used in ER diagram

Yan Huang - ER 01/11/2021 27

Translating ER Model to Relational
Model
Review - Concepts
Relational Model is made up of tables

 A row of table = a relational instance/tuple

 A column of table = an attribute
 A table = a schema/relation
 Cardinality = number of rows
 Degree = number of columns
Review - Example

Attribute

Cardinality = 2
tuple/relational instance
SID Name Major GPA
1234 John CS 2.8
5678 Mary EE 3.6

4 Degree

A Schema / Relation
From ER Model to Relational Model
So… how do we convert an ER diagram into a table?? Simple!!
Basic Ideas:
 Build a table for each entity set

 Build a table for each relationship set if necessary

 Make a column in the table for each attribute in the entity set

 Primary Key

 Contraints
 Example – Strong Entity Set
SID Name SSN Name

Student Advisor Professor

Major Dept
GPA

SID Name Major GPA SSN Name Dept

1234 John CS 2.8 9999 Smith Math
5678 Mary EE 3.6 8888 Lee CS
Representation of Weak Entity Set
 Weak Entity Set Cannot exists alone
 To build a table/schema for weak entity set

◦ Construct a table with one column for each attribute in the weak entity set
◦ Remember to include discriminator
◦ Augment one extra column on the right side of the table, put in there the primary
key of the Strong Entity Set (the entity set that the weak entity set is depending on)
◦ Primary Key of the weak entity set = Discriminator + foreign key
 Example – Weak Entity Set
Age
SID Name Name

Student owns Children

Major GPA

Age Name Parent_SID

10 Bart 1234
8 Lisa 5678

* Primary key of Children is Parent_SID + Name

Representation of Relationship Set
 Unary/Binary Relationship set
 Depends on the cardinality and participation of the relationship
 Two possible approaches
 N-ary (multiple) Relationship set
 Primary Key Issue
 Identifying Relationship
 No relational model representation necessary
Representing Relationship Set
Unary/Binary Relationship
 For one-to-one relationship w/out total participation
◦ Build a table with two columns, one column for each participating entity set’s primary
key. Add successive columns, one for each descriptive attributes of the relationship
set (if any).
 For one-to-one relationship with one entity set having total participation
◦ Augment one extra column on the right side of the table of the entity set with total
participation, put in there the primary key of the entity set without complete
participation as per to the relationship.
 Example – One-to-One Relationship Set
Degree
SID Name ID Code

Student study Major

Major GPA

SID Maj_ID Co S_Degree

9999 07 1234
8888 05 5678

* Primary key can be either SID or Maj_ID_Co

 Example – One-to-One Relationship Set
Condition
SID Name 1:1 Relationship S/N #

Student Have Laptop

Major GPA Brand

SID Name Major GPA LP_S/N Hav_Cond

9999 Bart Economy -4.0 123-456 Own
8888 Lisa Physics 4.0 567-890 Loan

* Primary key can be either SID or LP_S/N

Representing Relationship Set
Unary/Binary Relationship
 For one-to-many relationship w/out total participation
◦ Same thing as one-to-one
 For one-to-many/many-to-one relationship with one entity set having total
participation on “many” side
◦ Augment one extra column on the right side of the table of the entity set on the “many”
side, put in there the primary key of the entity set on the “one” side as per to the
relationship.
 Example – Many-to-One Relationship Set
Semester
SID Name N:1 Relationship SSN

Student Advisor Professor

Major GPA Dept Name

SID Name Major GPA Pro_SSN Ad_Sem

9999 Bart Economy -4.0 123-456 Fall 2006
8888 Lisa Physics 4.0 567-890 Fall 2005

* Primary key of this table is SID

Representing Relationship Set
Unary/Binary Relationship
 For many-to-many relationship
◦ Same thing as one-to-one relationship without total participation.
◦ Primary key of this new schema is the union of the foreign keys of both entity sets.
◦ No augmentation approach possible…
Representing Relationship Set
N-ary Relationship
 Intuitively Simple
◦ Build a new table with as many columns as there are attributes for the union of the
primary keys of all participating entity sets.
◦ Augment additional columns for descriptive attributes of the relationship set (if
necessary)
◦ The primary key of this table is the union of all primary keys of entity sets that are on
“many” side
◦ That is it, we are done.
 Example – N-ary Relationship Set
P-Key1
D-Attribute A-Key
E-Set 1

P-Key2 A relationship Another Set

E-Set 2

P-Key3

E-Set 3

P-Key1 P-Key2 P-Key3 A-Key D-Attribute

9999 8888 7777 6666 Yes
1234 5678 9012 3456 No

* Primary key of this table is P-Key1 + P-Key2 + P-Key3

Representing Relationship Set
Identifying Relationship
 This is what you have to know
◦ You DON’T have to build a table/schema for the identifying relationship set once you
have built a table/schema for the corresponding weak entity set
◦ Reason:
 A special case of one-to-many with total participation
 Reduce Redundancy
Representing Composite Attribute
 Relational Model Indivisibility Rule Applies
 One column for each component attribute
 NO column for the composite attribute itself

SSN Name

SSN Name Street City

Professor 9999 Dr. Smith 50 1st St. Fake City
8888 Dr. Lee 1 B St. San Jose
Address

Street City
Representing Multivalue Attribute
 For each multivalue attribute in an entity set/relationship set
◦ Build a new relation schema with two columns
◦ One column for the primary keys of the entity set/relationship set that has the
multivalue attribute
◦ Another column for the multivalue attributes. Each cell of this column holds only
one value. So each value is represented as an unique tuple
◦ Primary key for this schema is the union of all attributes
Example – Multivalue attribute
SID Name The primary key for this table is
Student_SID + Children, the union of
all attributes
Children
Student

Major GPA

Stud_SID Children
1234 Johnson
1234 Mary
SID Name Major GPA
5678 Bart
1234 John CS 2.8
5678 Lisa
5678 Homer EE 3.6
5678 Maggie
Representing Class Hierarchy
 Two general approaches depending on disjointness and completeness
◦ For non-disjoint and/or non-complete class hierarchy:
 create a table for each super class entity set according to normal entity set translation method.
 Create a table for each subclass entity set with a column for each of the attributes of that entity
set plus one for each attributes of the primary key of the super class entity set
 This primary key from super class entity set is also used as the primary key for this new table
Example SSN Name

Person

SID Status
Gender
ISA
Student

Major GPA
SSN Name Gender
1234 Homer Male
5678 Marge Female

SSN SID Status Major GPA

1234 9999 Full CS 2.8
5678 8888 Part EE 3.6
Representing Class Hierarchy
 Two general approaches depending on disjointness and completeness
◦ For disjoint AND complete mapping class hierarchy:
◦ DO NOT create a table for the super class entity set
◦ Create a table for each subclass entity set include all attributes of that subclass entity
set and attributes of the superclass entity set

◦ Simple and Intuitive enough, need example?

Example SSN Name
No table created for superclass entity set

SJSU people

ISA
SID
Student Faculty
Disjoint and Complete
mapping
Major GPA Dept

SSN Name SID Major GPA SSN Name Dept

1234 John 9999 CS 2.8 1234 Homer C.S.
5678 Mary 8888 EE 3.6 5678 Marge Math
Representing Aggregation
Name SSN Name

Student Advisor Professor

Dept
SID

Name
member
Primary Key of Advisor
Dept

SID Code
Code
1234 04
Primary key of Dept
5678 08
Query Processing
Basic Steps in Query Processing
1. Parsing and translation
2. Optimization
3. Evaluation
Basic Steps in Query Processing (Cont.)
 Parsing and translation
◦ translate the query into its internal form. This is then translated into relational algebra.
◦ Parser checks syntax, verifies relations
 Evaluation
◦ The query-execution engine takes a query-evaluation plan, executes that plan, and returns the
answers to the query.
 Basic Steps in Query Processing : Optimization
 A relational algebra expression may have many equivalent expressions
◦ E.g., salary75000(salary(instructor)) is equivalent to
salary(salary75000(instructor))
 Each relational algebra operation can be evaluated using one of several different algorithms
◦ Correspondingly, a relational-algebra expression can be evaluated in many ways.
 Annotated expression specifying detailed evaluation strategy is called an evaluation-plan.
◦ E.g., can use an index on salary to find instructors with salary < 75000,
◦ or can perform complete relation scan and discard instructors with salary  75000
Relational Algebra
Fundamentals
What is Relational Algebra?

• It is a language in which we can ask questions (query) of a database.

• Basic premise is that tables are sets (mathematical) and so our query language should
manipulate sets with ease.
• Select
• Project
• Cartesian product
• Union
• Set Difference
• Rename
Supplier-Part Example
supplies
Supplier Part

PK Sno PK Pno
(0,n) (1,n)
Sname Pdesc
Location O_date Colour

Supplier Part
Sno Sname Location Pno Pdesc Colour

s1 Acme NY p1 screw red

s2 Ajax Bos p2 bolt yellow
s3 Apex Chi p3 nut green
s4 Ace LA p4 washer red
s5 A-1 Phil

Supplies
Sno Pno O_date

s1 p1 nov 3
s2 p2 nov 4
s3 p1 nov 5
s3 p3 nov 6
s4 p1 nov 7
s4 p2 nov 8
s4 p4 nov 9
SELECTION:

• Selection returns a subset of the rows of a single table.

• Syntax:
select <table_name> where <condition>
/* the <condition> must involve only
columns from the indicated table */

alternatively

σ <condition> (table_name)

Find all suppliers from Boston.

Supplier
Answer
Sno Sname Location
Sno Sname Location
Select Supplier
s1 Acme NY
s2 Ajax Bos
where Location = ‘Bos’
s2 Ajax Bos
s3 Apex Chi
s4 Ace LA σ Location = ‘Bos’ (Supplier)
s5 A-1 Phil
SELECTION Exercise:

• Find the Cardholders from Modena.

select Cardholder where b_addr = ‘Modena’

alternatively

σ b_addr = ‘Modena’ (Cardholder)

• Observations:
– There is only one input table.
– Both Cardholder and the answer table have the same schema (list of columns)
– Every row in the answer has the value ‘Modena’ in the b_addr column.
SELECTION:
same schema

Answer

All rows in the answer have

the value ‘Modena’ in the
b_addr column
 PROJECTION:

• Projection returns a subset of the columns of a single table.

• Syntax:
project <table_name> over <list of columns>
/* the columns in <list of columns> must
come from the indicated table */

alternatively

π <list of columns> (table_name)

Find all supplier names

Supplier Answer
Sname
Sno Sname Location
Project Supplier over Sname
Acme
s1 Acme NY
Ajax
s2 Ajax Bos π Sname (Supplier) Apex
s3 Apex Chi
Ace
s4 Ace LA
A-1
s5 A-1 Phil
PROJECTION Exercise:

• Find the addresses of all Cardholders.

project Cardholder over b_addr

alternatively

π b_addr (Cardholder)

• Observations:
– There is only one input table.
– The schema of the answer table is the list of columns
– If there are many Cardholders living at the same address these are not duplicated
in the answer table.
PROJECTION:
schema of answer table
is the same as the list of
columns in the query

Answer

Duplicate ‘New Paltz’ values

in the Cardholder table are
dropped from the Answer table
CARTESIAN PRODUCT:

• The Cartesian product of two sets is a set of pairs of elements (tuples), one from each
set.
• If the original sets are already sets of tuples then the tuples in the Cartesian product
are all that bigger.
• Syntax:
<table_name> x <table_name>

• As we have seen, Cartesian products are usually unrelated to a real-world thing. They
normally contain some noise tuples.
• However they may be useful as a first step.
 CARTESIAN PRODUCT:

5 rows 4 rows
Supplier Part
Sno Sname Location Pno Pdesc Colour

s1 Acme NY p1 screw red

s2 Ajax Bos p2 bolt yellow
s3 Apex Chi p3 nut green
s4 Ace LA p4 washer red
s5 A-1 Phil

Supplier x Part 20 rows

Sno Sname Location Pno Pdesc Color

s1 Acme NY p1 screw red

s2 Ajax Bos p1 screw red
noise:
s3 Apex Chi p1 screw red
13 rows
info: s4 Ace LA p1 screw red
in total
7 rows s5 A-1 Phil p1 screw red
in total s1 Acme NY p2 bolt yellow
...
s5 A-1 Phil p4 washer red
CARTESIAN PRODUCT Exercise:

Names = Project Cardholder over b_name

Addresses = Project Cardholder over b_addr

Names x Addresses

Names x Addresses

. noise
.
Names x Addresses
.

Info =
project cardholder
over b_name, b_addr
How many rows? 36
UNION:

• Treat two tables as sets and perform a set union

• Syntax: table_1
table_1 table_2
table_2

Table1 UNION Table2

alternatively

∩
Table1 Table2

• Observations:
– This operation is impossible unless both tables involved have the same schemas.
Why?
– Because rows from both tables must fit into a single answer table; hence they must
“look alike”.
– Because some rows might already belong to both tables
UNION Example:

Part1Suppliers = project (select Supplies where Pno = ‘p1’) over Sno

Part2Suppliers = project (select Supplies where Pno = ‘p2’) over Sno

Part1Suppliers UNION Part2Suppliers

alternatively
Part1Suppliers = πSno(σPno = ‘p1’ (Supplies) )
Part2Suppliers = πSno(σPno = ‘p2’ (Supplies) )

∩
Answer = Part1Suppliers Part2Suppliers

Part1Suppliers
union
Part1Suppliers Part2Suppliers Part2Suppliers
Sno Sno Sno

s1 s2 s1
s3 s4 s2
s4 s3
s4
UNION Exercise:

• Find the borrower numbers of all borrowers who have either borrowed or reserved a
book (any book).
Reservers = project Reserves over borrowerid
Borrowers = project Borrows over borrowerid
Answer = Borrowers union Reservers
alternatively
Reservers = πborrowerid (Reserves)
Borrowers = πborrowerid(Borrows)

∩
Answer = Borrowers Reservers
Borrowers
union
Reservers
Borrowers Reservers
borrowerid
borrowerid borrowerid
1234
1234 1345 1325
1325 1325 2653
2653 9823 7635
not duplicated
7635 2653 9823
9823 7635 5342
5342 1345
INTERSECTION:

• Treat two tables as sets and perform a set intersection

• Syntax: Table1 Table2

Table1 INTERSECTION Table2

alternatively

Table1 ∩
Table2

• Observations:
– This operation is impossible unless both tables involved have the same schemas.
Why?
– Because rows from both tables must fit into a single answer table; hence they must
“look alike”.
INTERSECTION Example:
Part1Suppliers = project (select Supplies where Pno = ‘p1’) over Sno
Part2Suppliers = project (select Supplies where Pno = ‘p2’) over Sno

Part1Suppliers INTERSECT Part2Suppliers

alternatively
Part1Suppliers = πSno(σPno = ‘p1’ (Supplies) )
Part2Suppliers = πSno(σPno = ‘p2’ (Supplies) )

Answer = Part1Suppliers
∩
Part2Suppliers

Part1Suppliers
intersect
Part1Suppliers Part2Suppliers
Part2Suppliers
Sno Sno
Sno
s1 s2
s3 s4 s4
s4
INTERSECTION Exercise:

• Find the borrower numbers of all borrowers who have borrowed and reserved a book.

Reservers = project Reserves over borrowerid

Borrowers = project Borrows over borrowerid

Answer = Borrowers intersect Reservers

alternatively
Reservers = πborrowerid (Reserves)
Borrowers = πborrowerid(Borrows)

Answer = Borrowers ∩
Reservers Borrowers
intesect
Borrowers Reservers Reservers
borrowerid borrowerid borrowerid
1234 1345 1325
1325 1325 2653
2653 9823 7635
7635 2653 9823
9823 7635
5342
SET DIFFERENCE:

• Treat two tables as sets and perform a set intersection

• Syntax: Table1
Table1 Table2
Table2

Table1 MINUS Table2

alternatively

Table1 \ Table2

• Observations:
– This operation is impossible unless both tables involved have the same schemas.
Why?
– Because it only makes sense to calculate the set difference if the two sets have
elements in common.
SET DIFFERENCE Example:
Part1Suppliers = project (select Supplies where Pno = ‘p1’) over Sno
Part2Suppliers = project (select Supplies where Pno = ‘p2’) over Sno

Part1Suppliers MINUS Part2Suppliers

alternatively
Part1Suppliers = πSno(σPno = ‘p1’ (Supplies) )
Part2Suppliers = πSno(σPno = ‘p2’ (Supplies) )

Answer = Part1Suppliers \ Part2Suppliers

Part1Suppliers
minus
Part1Suppliers Part2Suppliers Part2Suppliers
Sno Sno Sno
s1 s2
s4
s1
s3
s4 s3
SET DIFFERENCE Exercise:

• Find the borrower numbers of all borrowers who have borrowed something and
reserved nothing.
Reservers = project Reserves over borrowerid
Borrowers = project Borrows over borrowerid

Answer = Borrowers minus Reservers

alternatively
Reservers = πborrowerid (Reserves)
Borrowers = πborrowerid(Borrows)

Borrowers
Answer = Borrowers \ Reservers minus
Borrowers Reservers Reservers
borrowerid borrowerid borrowerid
1234 1345
1234
1325 1325
5342
2653 9823
7635 2653
9823 7635
5342