1.

The Information Rule

All Information is explicitly and logically represented in tables as data values.

2.The Rule Of Guaranteed Access Every item of data must be logically addressable with the help of a name, primary key value and column name.

3.The Systematic treatment of null values The RDBMS must be able to support null values (these values are different are different from zeros and spaces) to present missing or inapplicable information.

4.The Database Description Rule A description of database is manipulated using logical structures with which data was defined the RDBMS. These are accessible to users with appropriate authority and are stored in the dictionary

5.Comprehensive Data Sub Language According to this rule, the system must the following Data definition View definition Data manipulation Integrity constraints Authorization Transaction management operations

6. The View Updating Rule All views that are theoretically updateable must also be updateable by system.

7. The Insert and Update Rule A single operand must hold good for all retrieval, update delete and insert activities. This rule implies that all the data manipulation commands must be operational on sets of rows having a relation rather than on a single row.

8. The Physical Independence Rule

Application programs must remain unimpaired when any changes are made in storage representation or access methods.

9. The Logical Data Independence Rule The changes that are should affect the users ability to work with the data. The change can be splitting the table into many more tables.

10. The Integrity Independence Rule The Integrity constraints should be stored in the system catalog or in the database as a table.

11. The Distribution Rule

The System must be able to access or manipulate the data that is distributed in other systems.

12. The Non-Subversion Rule

The non-subversion rule states that different levels of the language cannot subvert or bypass the integrity rules and constraints. To put it in simple words, if an RDBMS supports a lower level language then it should not bypass any integrity constraints defined in the higher level.

Normalization theory is built the concept of normal forms.

Normalizations reduces redundancy. Redundancy is unnecessary repetition of data. It can cause problems with storage and retrieval of data.
During the process of normalization, dependencies can be identified, which can cause problems during deletion and updation. Normalization theory is based on the fundamental notation of functional dependency. Normalization helps in simplifying the structure of tables.

First Normal Form

consider an example, One employee has different project codes. Hence the Projcode is said to be functionally dependent on the attribute Ecode. Now consider an unnormalized data that is represented in the following Table.

Ecode 101

Dept Accounts

Projcode 20 40 41 56 78 20 45

Hours 90 101 60 50 92 48 67

343
987

Admin
Sales

A relational model does not permit or support such unnormalized tables. The data table must be present atleast in the first normal form. Ecode 101 101 101 343 343 987 987 Dept Accounts Accounts Accounts Admin Admin Sales Sales Projcode 20 40 41 56 78 20 45 Hours 90 101 60 50 92 48 67

Second Normal Form

In the previous form it was noted that there was redundancy of data, and hence the table was decomposed without any loss of information. The problems encountered here were:

Insertion: Employee details cannot be recorded until the employee is assigned a project.

Updation: The employee code and department is repeated. Hence if an employee is transferred to another department, these changes must be reflected everywhere. Any omission will lead inconsistencies. Deletion: If an employee completes his project, his record will be deleted and details pertaining to that employee lost.

Ecode 101 343 987 Ecode 101 101 101 343 343 987 987

Dept Accounts Admin Sales Projcode 20 40 41 56 78 20 45 Hours 90 101 60 50 92 48 67

Third Normal Form A table is said to be in the third normal form if it in second normal form and every non-key attribute is functionally dependent on just the primary key. The primary key here is Ecode. The attribute dept-code is dependent on dept. There is an indirect dependence on the primary key, which has to be noticed. It is illustrated in the following table.

Ecode 101 303 400 500 600 777

Dept Finance Sales Sales Admin Systems Finance

Dept-code 909 906 906 908 901 909

Even here it was noted that there were problems during insertion, updation and deletion. The relation is thus reduced as shown in the following table.
Ecode 101 303 400 500 600 777 Dept Finance Sales Sales Admin Systems Finance

Dept Finance Sales Sales Admin Systems Finance

Deptcode 909 906 906 908 901 909

Each non-key attribute is wholly dependent only on the primary key. Even the third normal form did not satisfy the needs. Hence, a new form called the Boyee-Codd Normal from was introduced.

Boyee-Codd Normal Form The third normal form was not satisfactory for relations that had multiple candidate keys, are unique for each row. Consider that another table that has few other details, as shown in the following table.

Cusno 100 121 280

Cusname Preethi Jai kumar Shalini

Here the candidate keys are cuscode, and cusname. The attribute cuscode and cusname are unique for each row. Consider that table that has few other details, as shown in the following table.

Cuscode 100 100 121 280

Cusname Preethi Preethi Jai Kumar Shalini

Itemcode 19 16 29 33

Qty 4 2 6 1

The attributes cuscode and cusname of the above two tables can be used to link these tables. These act as a foreign key in the second table. These tables can be reduced on order to minimize redundancy. The tables are shown below.

Cuscode
100 101 121 280

Itemcode
19 16 29 23

Qty
4 2 6 1

Cuscode 100 121 280

Cusname Preethi Jai Kumar Shalini