RELATIONAL-APPROACH

INTENSION : The Column Heading are known as

INTENTION of the table.
EXTENSION : The Records (actual values) are known as
EXTENSIONS.
PRIMARY KEY : The Attribute which is unique, fixed
and must exist, is termed as PRIMARY KEY e.g. Customer
No, Account No are keys for their Database.
CANDIDATE KEY : The Attribute which purely depends
on Primary Key is called CANDIDATE KEY. E.g.
Customer Name, Account Name.
FOREGIN KEY : The Attribute value in a Table which is
required to be present in its corresponding Base Table is
called FOREGIN KEY. E.g. Customer No in Transaction
Table.
 BASIC RELATIONAL RULES

Any truly Relational Database must be manageable

entirely through its own relational capabilities. This
rule is also called as RULE 0.
CODD’S RULES FOR “FULLY” RELATIONAL
FUNCTIONAL SYSTEM

• INTEGRITY INDEPENDENCE RULE

a. ENTITY INTEGRITY RULE
Primary key value cannot be NULL.
b. REFRENTIAL INTEGRITY RULE
The foreign key value must be present in
corresponding base table.
2. INFORMATION RULE
All information is explicitly and logically represented
in one way – by data values in tables.
 CODD’S RULES FOR “FULLY” RELATIONAL
FUNCTIONAL SYSTEM

3. GURANTEED ACCESS RULE

Every Item of Data must be Logically addressable by
using Table Name, Primary Key value and Column
Name.
3. SYSTEMATIC TREATMENT OF NULL VALUES
All fields, whatever type (Character or Numeric or
Date …), must support the entry of NULL values.
5. DATABASE DESCRIPTION RULE
There must be defined Data Dictionary (Table
Structure ) within the RDBMS using which records
can be viewed and SQL can be operated.
7. COMPREHENSIVE SUB-LANGUAGE RULE
There must be inbuilt languages like DDL, DCL, DML
to define and manipulate tables.
 CODD’S RULES FOR “FULLY” RELATIONAL
FUNCTIONAL SYSTEM

7. VIEW UPDATING RULE

All views that can be updated in theory should also be
possible to update by the system.
8. INSERT AND UPDATE RULE
Major DML commands like SELECT, DELETE,
UPDATE and INSSERT must be available and
operational on sets of rows in a table.
9. PHYSICAL INDEPENDENCE RULE
Changes in the Physical devices e.g. Monitors, Disks
should not create dependency problem on access of
data. i.e. one should be able to view the same data even
on change of visual or storage terminals.
 CODD’S RULES FOR “FULLY” RELATIONAL
FUNCTIONAL SYSTEM

1. LOGICAL INDEPENDENCE RULE

Table structures should be independent of Procedures,
Programs and Vice-versa i.e. insertion of a new column
in a table should not force a change in concerned
procedure or program.
3. DISTRIBUTION RULE
A RDBMS must have distribution independence i.e.
decomposing tables into sub-tables, recombining them
with us SQL JOIN, UNION, MINUS and INTERSECT
concepts and operators.
12. NO SUBVERSION RULE
If a RDBMS supports lower level language, e.g. 3GL
COBOL or C etc., which permits row-at-a-time
processing, then this language must not be able to
bypass any integrity rules or constraints defined in the
higher level, set-at-a-time, relational language.
 NORMALIZATION

CASE STUDY

In a Company there are 100 Employees. Each Employee

is assigned a job-code and job-title. Many Employees are
working on company projects. Each Project is assigned a
Project Number, Completion Date, Number of Hours
worked. Design a Database to Computerize this
information.
 NORMALIZATION

To Solve the above case, there may be different

approaches by different analysts. The standard
common approach which can be recommended
to all is NORMALIZATION method.
In NORMALIZATION method we-
3. Present the Data in Tabular Format.
4. Minimize Data Redundancy
5. (By creating separate Table for fully Functional
dependencies.
 FIRST NORMALIZED FORM

1. Decide Attributes
2. Collect Some Data
3. Design Tabular Format.
The above case in First Normalized Form :
Emoployee Job Job Project Completion Hrs.
Name
No. Code Title No. Date Worked
101 Ajay 1 Programmer 1 17-JUL-2001 37

101 Ajay 1 Programmer 8 12-JAN-2001 12

102 Lata 1 Programmer 1 17-JUL-2001 45

102 Lata 1 Programmer 8 12-JAN-2001 21

103 Henry 2 Analyst 8 12-JAN-2001 10

104 John 3 Operator 1 17-JUL-2001 15

104 John 3 Operator 12 21-MAR-2001 30

----- ----- ----- ----- ----- ----- -----

----- ----- ----- ----- ----- ----- -----

 FIRST NORMALIZED FORM

Explanation :

Here Employee No., Job-Code and Project No., are

candidate keys (main attributes which are
Independent and unique in themselves). Each
Employee will have unique Employee No., each
Project will have unique Project Number and each
Job will have unique Job-Code. Employee No. is
not dependent on any other key so Employee No
can be considered as main Primary Key for this
Table.
 FIRST NORMALIZED FORM

Problems :
• Redundancy : Attributes Data Employee Name, Job
Code, Job Title is repeated again and again for same
Employee in different Tuples (Which can be
avoided) This increases work load for data Entry,
updation, maintenance.
• Insertion And Deletion :
a. A Project cannot be entered in the Table until
there are Employees working in it (there may be
Projects which are planned but not implemented and
so on Employee assigned to them)
b. If a Project is dropped (deleted) Employee
information of that Record is also deleted and vice-
versa.
 SECOND NORMALIZED FORM

The Second Normal Form is aimed to minimize the problems

of the first normal form. To get the table in the second
normal form-
• Find functional dependency and full functional
dependencies
• Create a separate Table for full functional dependency
sets
FUNCTIONAL DEPENDENCY:
If given a value of X, value of Y is determined then Y is said
to be functionally dependent on X.
FULL FUNCTIONAL DEPENDENCY:
In some cases a column may not be functionally dependent
on a single column but may be dependent on composite
(aggregate or group) column. Such a column is called
Full Functionally dependent on the Composite Column.
 SECOND NORMALIZED FORM

FUNCTIONAL DEPENDENCY:
Example : Employee Name is functionally dependent on
Employee No. In other words Employee No. determines
Employee Name.

FULL FUNCTIONAL DEPENDENCY:

Hours worked depends on Employee number as well as
Project No.
To change the Table to Second Normal Form a separate
Table should be created for Project and for Hours
worked.
 SECOND NORMALIZED FORM

Employee
Employee Name Job Job Project Completion
No. Code Title No. Date
101 Ajay 1 Programmer 1 17-JUL-2001

101 Ajay 1 Programmer 8 12-JAN-2001

102 Lata 1 Programmer 1 17-JUL-2001

102 Lata 1 Programmer 8 12-JAN-2001

103 Henry 2 Analyst 8 12-JAN-2001

104 John 3 Operator 1 17-JUL-2001

104 John 3 Operator 12 21-MAR-2001

----- ----- ----- ----- ----- -----

----- ----- ----- ----- ----- -----
SECOND NORMALIZED FORM

Hours Worked

Employee Project Hrs.

No. No. Worked

101 1 37
101 8 12
102 1 45
102 8 21
103 8 10
104 1 15
104 12 30
----- ----- -----
----- ----- -----
 SECOND NORMALIZED FORM

Problems :
A Particular Job Title cannot be entered for a Job Code
unless a Employee is doing the Job (It may be a new
job, say Executive Administrator, is created in a
organization but no one has been appointed for the
Post, yet Organization may like to store this new Job’s
data in the Database.)

Similarly deleting a Employee’s Record will delete the Job

information also.

Similarly updating Job Title for a particular Job may

require repeated updations.
 THIRD NORMALIZED FORM

THIRD NORMAL FORM :

The Third Normal Form is to over come the Problem of
Second Normal form.
To design the Third Normal Form :
4. Find the Transitive Dependency
5. Create separate Table for Transitive Dependency.

TRANSITIVE DEPENDENCY :
If Column C is functionally dependent on column B and
column B is functionally dependent on column A then
column C is said to be Transitively Dependent on
column A.
 THIRD NORMALIZED FORM

Transitive Dependency

A B C

For the above case, the Transitive Dependencies will be-

Employee No Job Code Job Title

Employee No Project Code Completion Date

 THIRD NORMALIZED FORM

Employee Name Job Job Job

No. Code Code Title
101 Ajay 1 1 Programmer
102 Lata 1 2 Analyst
103 Henry 2 3 Operator
104 John 3 4 Manager

Project Completion Employee Project Hrs.

No. Date No. No. Worked
1 17-JUL-2001 101 1 37
101 8 12
8 12-JAN-2001
102 1 45
10 25-SEP-2001
102 8 21
12 21-MAR-2001
103 8 10
----- ----- 104 1 15
104 12 30