Lecture Normalisation
Lecture Normalisation
Number of Tables
Redundancy
• Third Normal Form (3NF)
• Boyce-Codd Normal Form (BCNF)
• Fourth Normal Form (4NF)
• Fifth Normal Form (5NF)
• Domain Key Normal Form (DKNF)
0-55-123456-9 Main Street Small House 714-000-0000 $22.95 0-55-123456-9 Jones 123-333-3333
Example 1
Example 3
AuID AuName AuPhone
1 Sleepy 321-321-1111
Table Scheme: {AuID, AuName, AuPhone}
2 Snoopy 232-234-1234 Functional Dependencies: {AuId} {AuPhone}
3 Grumpy 665-235-6532 {AuId} {AuName}
4 Jones 123-333-3333
{AuName, AuPhone} {AuID}
5 Smith 654-223-3455
6 Joyce 666-666-6666
7 Roman 444-444-4444
FD – Example
Database to track reviews of papers submitted to an academic
conference. Prospective authors submit papers for review and
possible acceptance in the published conference proceedings.
Details of the entities
• Author information includes a unique author number, a name, a
mailing address, and a unique (optional) email address.
• Paper information includes the primary author, the paper number,
the title, the abstract, and review status (pending,
accepted,rejected)
• Reviewer information includes the reviewer number, the name, the
mailing address, and a unique (optional) email address
• A completed review includes the reviewer number, the date, the
paper number, comments to the authors, comments to the
program chairperson, and ratings (overall, originality, correctness,
style, clarity)
FD – Example
Functional Dependencies
• AuthNo AuthName, AuthEmail, AuthAddress
• AuthEmail AuthNo
• PaperNo Primary-AuthNo, Title, Abstract, Status
• RevNo RevName, RevEmail, RevAddress
• RevEmail RevNo
• RevNo, PaperNo AuthComm, Prog-Comm, Date,
Rating1, Rating2, Rating3, Rating4, Rating5
Second Normal Form (2NF)
For a table to be in 2NF, there are two requirements
• The database is in first normal form
• All nonkey attributes in the table must be functionally dependent on the
entire primary key
Note: Remember that we are dealing with non-key attributes
• DB(Pno,PName,appNo,time,doctor)
• DB(Pno,PName,appNo,time,doctor)
• -seems no repeating groups. So is in 1NF
• DB(Pno,appNo,time,doctor)
• R1(Pno,PName)
• No partial Dependencies. So 2NF
• No Transitive dependencies so… 3NF
BCNF
• Every determinant is a candidate key.
• What’s going on here???
• DB(Pno,appNo,time,doctor)
• R1(Pno,PName)
• DEPENDENCIES:
• Pno -> PName
Pno,appNo -> Time,doctor
Time -> appNo
• Then we may reduce the relation to:
• DB(Pno,time,doctor)
R1(Pno,PName)
R2(time,appNo)
Decomposition – Loss of
Information
1. If decomposition does not cause any loss of information it is
called a lossless decomposition.
2. If a decomposition does not cause any dependencies to be lost
it is called a dependency-preserving decomposition.
3. Any table scheme can be decomposed in a lossless way into a
collection of smaller schemas that are in BCNF form. However
the dependency preservation is not guaranteed.
4. Any table can be decomposed in a lossless way into 3rd normal
form that also preserves the dependencies.
• 3NF may be better than BCNF in some cases