Comp

Comp 3311
3311 Database
Database Management
Management Systems
Systems

11. Midterm Review

1
 Main Topics at Logical Data Level

• ER model (ER Diagram)

– Notation
– Conversion between ERD and RDM
• Relational data model
– Structures
– RA
• SQL
– DML
– DDL
• Database design
– FDs
– Normal Forms (3NF and BCNF)
2
Summary of ER Symbols I

3
Summary of ER Symbols II

4
 Symbols of ER Diagram (Cont.)

(a) one-to-one 1 1
All employees Department Managed- Employee
by
have a dept;
a dept has only one employee
(b) one-to-many 1 N
All employees Department Works-in Employee
have a dept;
a dept has many employees
(c) many-to-many N M
Employee Member- Project
N:M of

(e)relationship N M
Employee Member- Project
attribute of

time
 Symbols of ER Diagram (Cont.)
(f) recursive 1 boss
(with role names) Employee Manager-
of
N worker

(g) ternary N M
relationship Employee Uses Project

Language

(h) generalization/specialization Employee

ISA

Manager Engineer Technician

E-R Diagram of a Bank

7
 RELATIONAL MODEL
The relational model represents the data for an applicat
ion as a collection of tables.
Relational Representation Notation
Model
Relation  table R(A1, A2, …, An)
Attribute  column Ai
Domain  type and range of attribute dom(Ai)
values
Tuple / Record  row
Attribute value  value in table cell
 A set of relation schemas define a relational database.

 Tables show the instances of relation schemas.

 Relational Model
Automatic conversion between relational tables and ER
D branch_name city assets

– Entities Branch

– Relationships 1

street city state Gives

account_number balance access_date customer_id name address phone#

N
N M N M loan#
Account Deposits_to Customer Takes_out Loan
amount
1 N 1
interest_rate overdraft Guarantor_of
Disjoint

Saving Checking Has

Payment

9
number date amount
 BANK RELATIONAL SCHEMA

Account(account_number, balance) Payment(loan#, number, date, amount)

loan# references Loan
Saving(account_number, interest_rate) on delete cascade
account_number references Account
on delete cascade Deposits_to(account_number, customer_id,
access_date)
Checking(account_number, overdraft) account_number references Account
account_number references Account on delete cascade
on delete cascade customer_id references Customer
Customer(customer_id, name, address)* on delete cascade

Branch(branch_name, city assets) Takes_out(customer_id, loan#)

customer_id references Customer
Loan(loan#, amount, branch_name, customer_id) on delete cascade
branch_name references Branch loan# references Loan
on delete cascade on delete cascade
customer_id references Customer
on delete set null Customer_phone(customer_id, phone#)
customer_id references Customer
* Using option 1 for address composite attribute. on delete cascade
 Relational Algebra

• Basic operations:
– Selection (  )
– Projection (  )
– Cross-product ( x )
– Set-difference ( - )
– Union (  )
– renaming (  )
• Additional operations:
– Intersection (), join ( ), division (/)

11
 SQL: BASIC STRUCTURE
• SQL is based on set and relational algebra operations
with certain modifications and enhancements.

• A SQL query has the form (where […] means optiona

l):
select select-clause
from from-clause
[where where-clause]
[order by order-by-expression]
[group by group-by-attributes]
[having condition-for-each-group];

 The result of an SQL query is a relation (but it may contain

duplicates).

 SQL statements can be nested.

 SQL FEATURES

• Duplicate removal: distinct.

• An aggregation function (e.g., max, sum, …)
– without group by returns a single value.
– with group by returns a single value for each group.
– Null is ignored except count(*)
– Count always return a non-negative integer
• All non-aggregation attributes in the select clause wi
th a group by must also appear in the group by cla
use.
• If an attribute appears in a group by clause, it may
not necessarily appear in the select clause.

13
 Functional Dependencies (FDs)
• A FD X  Y holds on R, if and only if, for any legal relations r(R), whenever any
two tuples t1 and t2 of r agree on the attributes X, they also agree on the attribut
es Y

• The set of all functional dependencies logically implied by F is the FD closure of

F. (i.e. F+)

• For computing the closure we use Armstrong’s axioms

A1 if Y  X, then X  Y (reflexivity)
A2 if X  Y, then ZX  ZY (augmentation)
A3 if X  Y, and Y  Z, then X  Z (transitivity)

• Given a set of attributes X, the attribute closure of X under F (denoted by X+) is t

he set of attributes that are functionally determined by X under F

• If X determines all attributes, then it is a superkey. If it is also minimal, then it is

a candidate key. One candidate key is chosen to be the primary key to id a tuple

• A canonical cover of F is a minimal set of functional dependencies equivalent to

F, without any redundant dependencies or redundant attributes
14
 Database Design

• Goal
– remove redundancy & preserve constraints
• Major normal forms
– BCNF: for every non-trivial FD without useless attributes X
 Y, X is a candidate key.
– 3NF: a table in BCNF also satisfies 3NF. In addition, 3NF allo
ws FDs where every attribute in Y is prime.
– 2NF: a table in 3NF also satisfies 2NF. In addition, 2NF allow
s FDs where X is not a proper subset of a candidate key.
– 1NF: every relational table is 1NF because all attribute value
s are atomic.

15
 3NF Decomposition Algorithm

Let Fc be a canonical cover for F

for each X  Y in canonical cover Fc
create (X,Y)
if none of the created tables contains a candidate key
create a table with any candidate key for R;

The final tables are in 3NF. The decomposition is both

lossless-join and dependency-preserving, but the
tables may have redundancy.

16
 BCNF Decomposition Algorithm

Compute F+;
Result = {R};
While (any XY in F+ on a schema Ri in Result violates
BCNF) {
Create a new table (X,Y);
Result = (Result-{Ri}) U {(Ri - Y)} U {(X,Y)};
}

The final tables are in BCNF. The decomposition is

lossless-join, does not have redundancy, but may not
preserve FDs.
17
That’s all, folks!

18