This document contains notes from a database management systems course taught by Sumit Mittu. It discusses E.F. Codd's 12 rules for relational database management systems and the concepts of database normalization. The notes cover the different normal forms including 1NF, 2NF, 3NF, BCNF, 4NF and 5NF. It also briefly discusses denormalization and provides examples to illustrate database normalization concepts.

1. INT306
Database Management Systems
RELATIONAL DATABASE DESIGN
Text book
Database System Concepts
A. Silberschatz, H. F. Korth, S. Sudarshan
Course Instructor
Mr. Sumit Mittu
Assistant Professor and Placement Coordinator, CSE/IT
Lovely Professional University, Punjab (India)
sumit.12735@lpu.co.in sumit.mittu@gmail.com
http://tinyurl.com/askSumit
01-03-2014 11:40:41

2. IN THIS CHAPTER
• e. f. codd rules for rdbms
• normalization of database
01-03-2014 11:40:42
Sumit Mittu, Assistant Professor, CSE/IT
2

3. E. F. CODD RULES
• Codd's Rules for RDBMS
• E.F Codd was a Computer Scientist who invented Relational
model for Database management.
• Based on relational model, Relation database was created.
• Codd proposed 13 rules popularly known as Codd's 12 rules to
test DBMS's concept against his relational model.
• Codd's rule actually define what quality a DBMS requires in
order to become a Relational Database Management
System(RDBMS).
• Till now, there is hardly any commercial product that follows all
the 13 Codd's rules.
• Even Oracle follows only eight and half out(8.5) of 13.
01-03-2014 11:40:42
Sumit Mittu, Assistant Professor, CSE/IT
3

4. E. F. CODD RULES
Rule zero
Rule 1 :
Information rule
Rule 2 :
Guaranteed Access
01-03-2014 11:40:42
• This rule states that for a system to qualify as an
RDBMS, it must be able to manage database
entirely through the relational capabilities.
• All information(including metadeta) is to be
represented as stored data in cells of tables. The
rows and columns have to be strictly unordered.
• Each unique piece of data(atomic value) should
be accesible by : Table Name + primary
key(Row) + Attribute(column).
Sumit Mittu, Assistant Professor, CSE/IT
4

5. E. F. CODD RULES
Rule 3 : Systemetic
treatment of NULL
•Null has several meanings, it can mean missing data, not
applicable or no value. It should be handled consistently.
Primary key must not be null. Expression on NULL must give
null.
Rule 4 : Active
Online Catalog
•Database dictionary(catalog) must have description of
Database. Catalog to be governed by same rule as rest
of the database. The same query language to be used
on catalog as on application database.
Rule 5 : Powerful
language
•One well defined language must be there to provide all
manners of access to data. Example: SQL. If a file
supporting table can be accessed by any manner
except SQL interface, then its a violation to this rule.
01-03-2014 11:40:42
Sumit Mittu, Assistant Professor, CSE/IT
5

6. E. F. CODD RULES
Rule 6 : View
Updation rule
Rule 7 : Relational
Level Operation
Rule 8 : Physical
Data
Independence
01-03-2014 11:40:43
•All view that are theoretically updatable should be
updatable by the system.
•There must be Insert, Delete, Update operations at each
level of relations. Set operation like Union, Intersection
and minus should also be supported.
•The physical storage of data should not matter to the
system. If say, some file supporting table were renamed or
moved from one disk to another, it should not effect the
application.
Sumit Mittu, Assistant Professor, CSE/IT
6

7. E. F. CODD RULES
Rule 9 :
Logical Data
Independence
•If there is change in the logical structure(table structures) of
the database the user view of data should not change. Say, if
a table is split into two tables, a new view should give result as
the join of the two tables. This rule is most difficult to satisfy.
Rule 10 : Integrity
Independence
•The database should be able to enforce its own integrity
rather than using other programs. Key and Check constraints,
trigger etc. should be stored in Data Dictionary. This also make
RDBMS independent of front-end.
Rule 11 : Distribution
Independence
•A database should work properly regardless of its distribution
across a network. This lays foundation of distributed database.
01-03-2014 11:40:43
Sumit Mittu, Assistant Professor, CSE/IT
7

8. E. F. CODD RULES
Rule 12 :
Nonsubversion
rule
01-03-2014 11:40:43
• If low level access is allowed
to a system it should not be
able to subvert or bypass
integrity rule to change data.
This can be achieved by some
sort of looking or encryption.
Sumit Mittu, Assistant Professor, CSE/IT
8

9. SCRATCH YOUR MIND!!!
•
01-03-2014 11:40:43
Sumit Mittu, Assistant Professor, CSE/IT
9

10. NORMALIZATION
•
•
•
•
Normalization
Need for Normalization
Anomalies in database
Decomposition
• Desirable Properties
• Attribute Dependency
• FD, FFD, PFD, TD, MVD, etc.
01-03-2014 11:40:43
Sumit Mittu, Assistant Professor, CSE/IT
10

11. NORMALIZATION
• Normal Forms
• Phases/Levels of Normalization
•
•
•
•
•
•
•
•
1 NF – First Normal Form
2 NF – Second Normal Form
3 NF – Third Normal Form
BCNF – Boyce Codd Normal Form
4 NF – Fourth Normal Form
5 NF – Fifth Normal Form
DKNF – Domain Key Normal Form
Etc.
01-03-2014 11:40:43
Sumit Mittu, Assistant Professor, CSE/IT
11

12. NORMALIZATION
• Normal Forms •
•
•
•
1 NF
2 NF
3 NF
BCNF
• 4 NF
– Eliminate groups
+ Preserve Functional Dependencies
– Eliminate Transitive Dependencies
+ Preserve FDs that determinants are irreducible
candidate key
– Eliminate Multi-valued Dependencies
• at most 1 multi-valued dependency can be allowed
• 5 NF
01-03-2014 11:40:43
+ Preserve Join Dependency
Sumit Mittu, Assistant Professor, CSE/IT
12

13. NORMALIZATION
• First Normal Form
•
•
•
•
•
The data must be represented as tables
Fields must be atomic domains
There should be no multivalued attributes
Data must be represented as non-repeating groups
Do not have null values against record fields
• Example…
01-03-2014 11:40:43
Sumit Mittu, Assistant Professor, CSE/IT
13

14. NORMALIZATION
• Second Normal Form
• Tables must be in 1NF
• There must be a candidate key in each table
• Preserve Fully-Functional Dependencies
• Partial FDs should not exist
• Determinant may be composite key
• All non-key attributes must be dependent on key attribute
• Example…
01-03-2014 11:40:43
Sumit Mittu, Assistant Professor, CSE/IT
14

15. NORMALIZATION
• Third Normal Form
• Tables must be in 2NF
• There must be a candidate key in each table
• Eliminate all Transitive Dependencies
• Example…
01-03-2014 11:40:43
Sumit Mittu, Assistant Professor, CSE/IT
15

16. NORMALIZATION
• Boyce-Codd Normal Form
•
•
•
•
Tables must be in 2NF
There must be a candidate key in each table
Every determinant must be non-composite (irreducible)
Every irreducible determinant must be a candidate key
• Example…
01-03-2014 11:40:42
Sumit Mittu, Assistant Professor, CSE/IT
16

17. NORMALIZATION
• Fourth Normal Form
• Tables must be in 3NF / BCNF
• Eliminate all multi-valued dependencies
• If not possible, decompose the relations such that each relation
after decomposition must not have more than one multi-valued
dependency
• Example…
01-03-2014 11:40:43
Sumit Mittu, Assistant Professor, CSE/IT
17

18. NORMALIZATION
• Fifth Normal Form
• Tables must be in 4NF
• Preserve Join Dependency
• There are certain conditions under which after decomposing a
relation, it cannot be reassembled losslessly back into its original
form.
• It is 5NF when this stage is reached
• This normal form is also known as Project-Join normal Form
(PJNF)
• Example…
01-03-2014 11:40:43
Sumit Mittu, Assistant Professor, CSE/IT
18

19. DE-NORMALIZATION
• De-normalization
• In order to improve performance, the designers sometimes
choose a schema that has redundant information
• De-normalization presents a trade-off between
performance and modification anomalies / data
redundancy.
• Example…
01-03-2014 11:40:43
Sumit Mittu, Assistant Professor, CSE/IT
19

20. DE-NORMALIZATION
• The relation CUSTOMER (CustomerID, Name, Address,
City, State, Zip) can be normalized as:
• CUSTOMER (CustomerID, Name, Address, Zip)
• ZIPCODES (Zip, City, State)
• This suffers with a performance penalty like:
• Each customer address lookup requires we look in two relations
(tables).
• More technically, obtaining a complete customer and address
record requires us to join CUSTOMER and ZIPCODES together.
• Hence, de-normalization is performed
• re-assemble the original CUSTOMER relation we started with
that will contain all of the attributes.
01-03-2014 11:40:43
Sumit Mittu, Assistant Professor, CSE/IT
20

21. SCRATCH YOUR MIND!!!
•
•
01-03-2014 11:40:43
Sumit Mittu, Assistant Professor, CSE/IT
21