From week 3 Tutorial
CAddr
CPhone
CUSTOMER
CId
Makes
CName
PaidStatus
OId
PId
ORDER
ODate
PName
PART
PDesc
IsRequestedIn
Mapping Infinite Multi-valued Attributes
CAddr
CUSTPHONE
Makes
CUSTOMER
CId
Makes
CName
PaidStatus
CPhone
OId
PId
ORDER
ODate
PName
PART
IsRequestedIn
PDesc
CUSTOMER
CId
CName
CAddr
CUSTPHONE
CPhone
CId
Mapping relationships
CAddr
CUSTPHONE
CUSTOMER
Makes
CId
Makes
CName
PaidStatus
CPhone
OId
PId
IsRequestedIn
PART
PName
PDesc
PDesc
ORDER
OId
PaidStatus
ODate
PName
PART
PId
ORDER
ODate
PId
Mapping relationships
CAddr
CUSTOMER
Makes
CUSTPHONE
CId
Makes
CName
PaidStatus
CPhone
OId
PId
IsRequestedIn
PART
PName
PDesc
ODate
PName
PART
PId
ORDER
PDesc
ORDER
OId
PaidStatus
ODate
PId
CUSTOMER
CId
CName
CAddr
CId
Final Schema
PART
PId
PName
PDesc
ORDER
OId
PaidStatus
PId
ODate
CId
CUSTOMER
CId
CName
CAddr
CUSTPHONE
CPhone
CId
SQL Data Definition
PART
PId
PName
PDesc
CREATE TABLE Part (PId INTEGER,
PName CHAR(20),
PDesc CHAR(30),
PRIMARY KEY (PId))
CUSTOMER
CId
CName
CAddr
CREATE TABLE Customer (Cid INTEGER,
CName CHAR(20),
CAddr CHAR(40),
PRIMARY KEY (Cid))
SQL Data Definition
PART
PId
PName
PDesc
ORDER
OId
PaidStatus
ODate
PId
CId
CUSTOMER
CId
CName
CAddr
CREATE TABLE Order (OId INTEGER,
ODate DATE,
PaidStatus CHAR(1),
PId INTEGER,
CId INTEGER,
PRIMARY KEY (OId),
FOREIGN KEY (PId) REFERENCES Part,
FOREIGN KEY (Cid) REFERENCES Customer)
Joined Relations
Var1 Var2
a
c
b
d
2
1
Var3
b
e
3
4
Var1
Var2
Var3
Var4
1
a
c
b
c
2
a
c
e
f
3
b
d
b
c
4
b
d
e
f
Var4
c
f
JOIN
Table 1
Table 2
TID
Var1
SID
Var2
1
a
1
d
2
b
3
e
3
c
5
f
The
Relations
forProduct
(TID=SID)
The
Cartesian
is is:
TID
Var1
SID
Var2
1
a
1
d
1
a
3
e
1
2
a
b
5
1
f
d
2
b
3
e
2
b
5
f
3
c
1
d
3
c
3
e
3
c
5
f
JOIN
Table 1
Table 2
TID
Var1
SID
Var2
1
a
1
d
2
b
3
e
3
c
5
f
The Cartesian
Product
for (TID-SID)
is:
The Cartesian
Product
is
TID
Var1
SID
Var2
1
a
1
d
3
c
3
e
Functional Dependencies and Keys
• Functional Dependency: The value of one
attribute (the determinant) determines the
value of another attribute
• Candidate Key:
– A unique identifier. One of the candidate keys
will become the primary key
• E.g. perhaps there is both credit card number and
SS# in a table…in this case both are candidate
keys
– Each non-key field is functionally dependent
on every candidate key
Steps in
normalization
First Normal Form
• No multi-valued attributes
• Every attribute value is atomic
• multi-valued attributes  it is not a
relation
Second Normal Form
• 1NF PLUS every non-key attribute is
fully functionally dependent on the
ENTIRE primary key
– Every non-key attribute must be defined by
the entire key, not by only part of the key
– No partial functional dependencies
Functional Dependencies
Full Dependency
Transitive Dependencies
Partial Dependencies
Partial Dependencies
Order_ID  Order_Date, Customer_ID, Customer_Name, Customer_Address
Customer_ID  Customer_Name, Customer_Address
Product_ID  Product_Description, Product_Finish, Unit_Price
Order_ID, Product_ID  Order_Quantity
Therefore, NOT in 2nd Normal Form
Getting it into Second Normal Form:
Removing Partial Dependencies
Partial Dependencies are removed, but there
are still transitive dependencies
Third Normal Form
• 2NF PLUS no transitive dependencies
(functional dependencies on non-primary-key
attributes)
• Note: this is called transitive, because the
primary key is a determinant for another attribute,
which in turn is a determinant for a third
• Solution: non-key determinant with transitive
dependencies go into a new table; non-key
determinant becomes primary key in the new
table and stays as foreign key in the old table
Getting it into Third Normal Form
Transitive dependencies are removed
Boyce-Codd Normal Form (BCNF)
Customer-street
Customer-id
Branch-name
Customer-city
Branch-ID
Customer-name
Customer
GetLoan
Loan-Number
Amount
Branch
Branch-city
Boyce-Codd Normal Form (BCNF)
• Customer-schema = (customer-id, customer-name, customer-street,
customer-city)
customer-id -> customer-name customer-street customer-city
• Branch-schema = (branch-id, branch-name, branch-city)
branch-id -> branch-name branch-city
• Loan-info-schema (branch-id, customer-id, loan-number, amount)
loan-number -> amount branch-id
e.g.
(Melbourne101, c1234, L-44, $1000)
(Melbourne101, c1235, L-44, $1000)
NOT in BCNF
Loan-schema (loan-number, branch-id, amount)
Borrower-schema (customer-id, loan-number)