Database
Relational Model
The Relational Data Model
Data
Modeling
E/R diagrams
Relational
Schema
Tables:
column names: attributes
rows: tuples
Physical
storage
Complex
file organization
and index
structures.
Relational Data Model
 Core of majority of modern databases
 Virtually all business relies
on some form of relational database
 Solid theoretical/mathematical foundation
Relational Model Concepts
 The relational Model of Data is based on the
concept of a Relation.
 A Relation is a mathematical concept based
on the ideas of sets.
 Order of tuples not important
 Order of attributes not important (in theory)
RELATION
 RELATION is A table of values
 A relation may be thought of as a set of
rows.
 A relation may alternately be though of as a
set of columns.
Relation Instance
Name
Address
Telephone
Ahmed
123 Main St
555-1234
Hassan
12 State St
555-1235
Ahmed
123 Main St
555-1235
Mona
456 Main St
555-2221
Sally
456 Main St
555-2221
Sally
456 Main St
555-2223
Hassan
12 State St
555-1235
Example
State
Example Schema
Schema
Student
Course
Grade
Hermione Grainger
Potions
A-
Draco Malfoy
Potions
B
Harry Potter
Potions
A
Ron Weasley
Potions
C
 The schema of a relation is the name of the relation
followed by a parenthesized list of attributes (+ types of
attributes).
CoursesTaken(Student, Course, Grade)
 A design in a relational model consists of a set of
schemas.
 Such a set of schemas is called a relational database
schema.
Relation Schema
relation
name
set of
attributes
StockItem
Attribute
ItemID
Description
Price
Taxable
attribute
names
Domain
string(4)
string(50)
currency/dollars
boolean
attribute
domains
Relational schema
 Is a direct map from ER diagram into basic table
 For example, the schema (ID, phone, name,
birth_date, address)
Banking Example
branch (branch_name, branch_city, assets)
customer (customer_name, customer_street,
customer_city)
account (account_number, branch_name,
balance)
loan (loan_number, branch_name, amount)
depositor (customer_name, account_number)
borrower (customer_name, loan_number)
Example Database Schema
 Student (Id: INT, Name: STRING, Address:
STRING, Status: STRING)
 Professor (Id: INT, Name: STRING, DeptId:
DEPTS)
 Course (DeptId: DEPTS, CrsName: STRING,
CrsCode: COURSES)
 Transcript (CrsCode: COURSES, StudId: INT,
Grade: GRADES, Semester: SEMESTERS)
 Department (DeptId: DEPTS, Name: STRING)
13
Key Constraints
 key of R: A set of attributes SK of R such
that no two tuples will have the same value
for SK
 If a relation has several candidate keys,
one is chosen arbitrarily to be the primary
key. The primary key attributes are
underlined.
 Indicate a key by underlining the key attributes.
 Example: If name is a key for Beers:
Beers(name, manf)
Entity Set to Relation
name
category
price
Product
Product(name, category, price)
name
gizmo
category
gadgets
price
$19.99
Relationships to Relations
price
name
category
Start Year
makes
name
Company
Product
Stock price
Makes(product-name, product-category, company-name, year)
Product-name
gizmo
Product-Category Company-name
gadgets
gizmoWorks
Starting-year
1963
Relationships to Relations
price
name
category
Start Year
makes
name
Company
Product
Stock price
No need for Makes. Modify Product:
name
category price
gizmo gadgets
19.99
StartYear companyName
1963
gizmoWorks
ERD FROM DATASTORES FLIGHTS
carries
Flight
Aircraft
Flight
(flight#, arrival_airport, depart_airport, arrival_time,
depart_time)
uses
Airport (code, city)
Aircraft (aircraft, no_of_seats)
Identifier of flight seems strange. ‘Flight_no’ alone should
identify a flight.
Airport
ERD FROM DATASTORES FLIGHTS
Aircraft
Flight (flight#, arrival_airport, depart_airport, arrival_time,
depart_time)
Stopover (flight_no, code, arrival_time, depart_time)
carries
Airport (code, city)
Aircraft (aircraft, no_of_seats)
Stopover
Flight
Departs_from
Stops_at
Leaves_from
Arrives_at
Airport
Multi-way Relationships to
Relations
address
name
Product
name
price
Purchase
Store
Person
Purchase(
ssn
name
,
,
)
name
addr
Drinkers
1
name
Likes
manf
Beers
2
Buddies
husband
Favorite
wife
Married
Likes(drinker, beer)
Favorite(drinker, beer)
Married(husband, wife)
Buddies(name1, name2)
 For one-one relation Married, we can
choose either husband or wife as key.
Weak Entity Sets, Relationships 
Relations
 Relation for a weak E.S. must include its full key
(i.e., attributes of related entity sets) as well as its
own attributes.
 A supporting (double-diamond) relationship yields
a relation that is actually redundant and should be
deleted from the database schema.
Representing Entity Sets With Simple Attributes
 A strong entity set reduces to a schema with
the same attributes
student(ID, name, tot_cred)
 A weak entity set becomes a table that includes
a column for the primary key of the identifying
strong entity set
section ( course_id, sec_id, sem, year )
Example
name
Logins
name
@
Hosts
Hosts(hostName)
Logins(loginName, hostName)
At(loginName, hostName, hostName2)
 In At, hostName and hostName2 must be the
same host, so delete one of them.
 Then, Logins and At become the same
relation; delete one of them.
 In this case, Hosts’ schema is a subset of
Logins’ schema. Delete Hosts?
Converting Non-identifying Attributes
 Single-valued (standard attribute)
 Create a table column for each
 Derived
 Omit: these values are not stored in our tables

Later, we can produce these values using a query
 Multi-valued
 Relational model does not directly support!
 However, as we have discussed, a multi-valued
attribute can be conceptualized as a new (weak)
entity, thus implying a separate table.
Composite and Multivalued Attributes
 Composite attributes are flattened out by
creating a separate attribute for each component
attribute
 Example: given entity set instructor with
composite attribute name with component
attributes first_name and last_name the
schema corresponding to the entity set has
two attributes name_first_name and
name_last_name

Prefix omitted if there is no ambiguity
 Ignoring multivalued attributes, extended
instructor schema is
 instructor(ID,
first_name, middle_initial, last_name,
street_number, street_name,
apt_number, city, state, zip_code,
Composite and Multivalued Attributes
 A multivalued attribute M of an entity E is represented by a
separate schema EM
 Schema EM has attributes corresponding to the
primary key of E and an attribute corresponding to
multivalued attribute M
 Example: Multivalued attribute phone_number of
instructor is represented by a schema:
inst_phone= ( ID, phone_number)
 Each value of the multivalued attribute maps to a
separate tuple of the relation on schema EM

For example, an instructor entity with primary key 22222 and
phone numbers 456-7890 and 123-4567 maps to two tuples:
(22222, 456-7890) and (22222, 123-4567)
Converting Binary Relationships
 One-to-one relationships


Consider the 2 associated entity tables.
The foreign key column(s) can be with either entity

As before, copy the primary key column(s) of the related
table
 Note: in a 1:1 relationship, the two entities often use the
same identifier, in which case the existing primary key
columns serve the “dual role” of both primary and foreign
keys

A separate foreign key column is then unnecessary!
Converting Binary Relationships
 One-to-many relationships
 Consider the 2 associated entity tables.
 Within the “many side” entity’s table, we need to have
foreign key column(s) referring to the related “one
side” entity instances
 We use the identifier of the related entity to define the
foreign key column(s)

In other words, we include a column (a “copy”) of primary key
values from the related table
 The copied primary key values we call “foreign keys.”
Schema Diagram
REVIEW
Reverse engineer
this relational
schema to find an
equivalent ER
schema.
Converting Binary Relationships
 Many-to-many relationships
 Relational model does not directly support!
 However, each many-to-many relationship can be
conceptualized as a new (associative) entity, thus
implying a separate table.
 The identifier for the associative entity is the
combination of the identifiers for the two related
entities.

Thus, for the separate table we create for an M:M
relationship, its primary key columns include the primary key
columns for both of the related tables.
Finding the Keys
If the relation comes from a many-many relationship, the
key of the relation is the set of all attribute keys in the
relations corresponding to the entity sets
name
Product
Person
buys
price
name
date
buys(name, ssn, date)
ssn
PREVIEW: ER to Relational
EER Bank Schema
Step 1: Regular Entities
 Regular entity types become relations
 include all simple attributes
 include only components of compound
attributes
 keys become primary keys
 if multiple keys (candidates) select a primary
key
CUSTOMER(Ssn, Name, Addr, Phone)
Step 1: Regular Entities
BANK(Code, Name, Addr)
ACCOUNT(Acct_no, Type, Balance)
LOAN(Loan_no, Type, Amount)
Step 2: Weak Entities
 Weak entity types become relations
 include all simple attributes
 include only components of compound attributes
 create a primary key from partial key
and key of owning entity type (through identifying
relationship)
 attributes acquired through identifying relationship
become a foreign key*
* typically, deletions and insertions will be propagated
through this foreign key
Step 2: Weak Entities
 Weak entity types become relations
BANK_BRANCH(Bank_code, Branch_No, Addr)
FK
BANK(Code, Name, Addr)
Step 3: Binary 1:1 Relationships
 Approach 1: Foreign Key
EMPLOYEE(Ssn, Name, …)
FK
DEPARTMENT(Name, Number, Mgr, Mgr_start_date)
Step 3: Binary 1:1 Relationships
 Approach 2: Merged Relation
AJB(x, y, p, q, r)
or
AJB(x, y, p, q, r)
Step 4: Binary 1:N Relationships
 1:N Relationships become foreign key at N side
 any relationship attributes also go to N side
LOAN(Loan_no, Type, Amount,
Bank, Branch)
BANK_BRANCH(Bank_code, Branch_No,
Addr)
Step 4: Binary 1:N Relationships
 1:N Relationships become foreign key at N side
 any relationship attributes also go to N side
ACCOUNT(Acct_no, Type, Balance,
Bank, Branch)
BANK_BRANCH(Bank_code, Branch_No,
Addr)
Step 5: Binary M:N Relationships
 M:N Relationships must become a new relation
 contains FKs to both related entities
 combined FKs become PK for new relations
 relationship attributes go in new relation
CUSTOMER(Ssn, Name, Addr,
Phone)
A_C(Acct, Cust)
ACCOUNT(Acct_no, Type,
Balance, Bank, Branch)
Step 6: Multivalued Attributes
 Multivalued attributes must become new
relations


FK to associated entity type
PK is whole relation
DEPARTMENT(Name, Number, Mgr, Mgr_start_date)
DEPT_LOCATIONS(DName, Dno, Location)
Step 7: N-ary Relationships
 Non-Binary Relationships become new relations
 FKs to all participating entity types
 Combine FKs to make a PK
(exclude entities with max participation of 1)
 Include any relationship attributes
SUPPLIER(SName)
PROJECT(Proj_name)
PART(Part_no)
SUPPLY(SName, PName, Part, Quantity)
Completed Bank Schema
CUSTOMER(Ssn, Name, Addr, Phone)
BANK(Code, Name, Addr)
ACCOUNT(Acct_no, Type, Balance, Bank, Branch)
LOAN(Loan_no, Type, Amount, Bank, Branch)
BANK_BRANCH(Bank_code, Branch_No, Addr)
A_C(Acct, Cust)
L_C(Loan, Cust)
BANK_BRANCH(Bank_code) refers to BANK
LOAN(Bank,Branch) refers to BANK_BRANCH
ACCOUNT(Bank,Branch) refers to BANK_BRANCH
A_C(Acct) refers to ACCOUNT
A_C(Cust) refers to CUSTOMER
L_C(Loan) refers to LOAN
L_C(Cust) refers to CUSTOMER
Bank Schema: MS Access
Exercise
A university database contains information about
professors (identified by social security number) and
courses (identified by courseid). Professors teach
courses; each of the following situations concerns the
Teaches relationship set. For each situation, draw an
ER diagram that describes it.
 Professors can teach the same course in several
semesters, and each offering must be recorded.
49
Exercise
Professors can teach the same course in several
semesters, and only the most recent such offering
needs to be recorded.
50
Exercise
 Every professor teaches exactly one course (no more,
no less)
 Every professor teaches exactly one course (no more,
no less), and every course must be taught by some
professor
51
Practice
 Professors have an SSN, a name, an age, a rank, and a
research specialty.
 Projects have a project number, a sponsor name (e.g.,
NSF), a starting date, an ending date, and a budget.
 Graduate students have an SSN, a name, an age, and a
degree program
 Each project is managed by exactly one professor
(known as PI)
 Each project is worked in by one or more professors
(known as Co-PIs)
 Each project is worked on by one or more graduate
students (known as RAs)
52
 When graduate students work on a project, a professor must supervise their
work on the project. Graduate students can work on multiple projects, in
which case they will have a potentially different supervisor for each project.
 Departments have a department number, a department name, and a main
office.
 Department has a professor (known as Chairman) who runs the department.
53
 Professors work in one or more departments, and for each department that
they work in, a time percentage is associated with their job
 Graduate students have one major department in which they are working on
their degree.
 Each graduate student must have another, more senior graduate student as
an advisor.
54
55
 A company database needs to store information about employees
(identified by ssn, with salary and phone as attributes), departments
(identified by dno, with dname and budget as attributes), and
children of employees (with name and age as attributes).
Exercise
 A
company database needs to store information about
employees (identified by ssn, with salary and phone as
attributes),
departments
(identified
by
dno,
with dname and budget as attributes), and children of
employees
(with
name
and
age
as
attributes).
Employees
work
in
departments;
each
department
is managed by an employee; a child must be identified uniquely
by name when the parent (who is an employee; assume that
only one parent works for the company) is known.
 Draw an ER diagram that captures this information.
 Employees work in departments;
 each department is managed by an employee;
 a child must be identified uniquely by name when the parent (who is
an employee; assume that only one parent works for the company)
is known.
Exercise
 You set up a database company, ArtBase, that builds a product for art
galleries. The core of this product is a database with a schema that
captures all the information that galleries need to maintain.
 Galleries keep information about artists, their names (which are
unique), birthplaces, age, and style of art. For each piece of artwork, the
artist, the year it was made, its unique title, its type of art (e.g., painting,
lithograph, sculpture, photograph), and its price must be stored. Pieces
of artwork are also classified into groups of various kinds, for example,
portraits, still lifes, works by Picasso, or works of the 19th century; a
given piece may belong to more than one group. Each group is
identified by a name (like those just given) that describes the group.
Finally, galleries keep information about customers. For each customer,
galleries keep that person’s unique name, address, total amount of
dollars spent in the gallery (very important!), and the artists and groups
of art that the customer tends to like. Draw the ER diagram for the
database
Galleries keep information about artists, their names (which are unique), •
birthplaces, age, and style of art.
For each piece of artwork, the artist, the year it was made, its unique title, its •
type of art (e.g., painting, lithograph, sculpture, photograph), and its price must
be stored.
• Pieces of artwork are also classified into groups of various kinds, for
example, portraits, still lifes, works by Picasso, or works of the 19th century;
a given piece may belong to more than one group.
• Each group is identified by a name (like those just given) that describes
the group.
• Finally, galleries keep information about customers. For each customer,
galleries keep that person’s unique name, address, total amount of dollars
spent in the gallery (very important!),
• and the artists and groups of art that the customer tends to like
Subclasses  Relations
1. Object-oriented: each entity is in one class. Create a
relation for each class, with all the attributes for that class.
2. E/R style: an entity is in a network of classes related by
isa. Create one relation for each E.S.
 An entity is represented in the relation for each
subclass to which it belongs.
 Relation has only the attributes attached to that E.S. +
key.
3. Use nulls. Create one relation for the root class or root
E.S., with all attributes found anywhere in its network of
subclasses.
 Put NULL in attributes not relevant to a given entity.
Example
name
Beers
isa
color
Ales
manf
OO-Style
nam e
manf
nam e
manf
color
Bud
A.B.
Summ erBrew
Pete's
dark
Beers
Ales
E/R Style
nam e
man f
name
Color
Bud
Summ erBrew
A.B.
Pete 's
Sum merBrew
dark
Beers
Ales
Using NULLS
nam e
man f
co lor
Bud
Summ erBrew
A.B.
Pete 's
NUL L
dark
Beers
Design Issues
 Use of entity sets vs. attributes
 Use of phone as an entity allows extra
information about phone numbers (plus
multiple phone numbers)
Design Issues
 Use of entity sets vs. relationship sets
Possible guideline is to designate a relationship
set to describe an action that occurs between
entities
Preview:
Queries
Read the following database case and then draw the
•
EERD for that case. After that, transform that EERD into a
relational model. Assume from 3-5 attributes for each entity
type.
ABC is a company whose business is to deliver
shipments. The company has many branches in
Egypt each of which has many stores. Each store
has many employees working for it. A store receives
many customer shipments to deliver to destinations.
A customer is able to send many shipments and for
each he/she is expecting a confirmation on delivery.
A fare is payable for each delivery. However, when
the shipment is lost an apology is to replace the
confirmation. ABC is using many vehicles including
aircrafts, trucks and ships for sending the customer
shipments.