Data Modals

Database Management

A database is a collection of logically related information and store information in a proper way.

Database Management is the process of maintaining data in the database so that information is available easily when required. The System used to for Database Management is called Database Management System. Database Management System involves:

1 –Design Database structure to store and maintain a huge amount of data.

2-Provide facilities to retrieving, inserting, updating and deleting records from database.

3- Taking and restoring data.

4- Secure data from unauthorized users.

Organizing the data in the database is described in a Data Model. Mainly there are two types of data models

1-      Object-based logical model, which focuses on describing the data, the relation among the data.

2-      Record-based logical model, which focuses on describing the data structure and the access techniques in a database management system.

An Entity is any object, place, person, or activity about which data is recorded. For example Teacher and Student etc.

Relationship is an association among entities. For example there is the relation between Teacher and Student as Teacher Teaches Student.

There are three type of relationships

1-One to One Relationship

Example: For a particular department (like Chemistry, Physics) there is only one Department Head.

3-      One to Many Relationship

Example: One department can contain many teachers to teach same subject.

Example: One student can select many Courses and One Course can be selected by many students.

Normalization of database

Normalization is a method through which we break down complex table structures into simple table structure. Using this method we can reduce redundancy in a table and eliminate the inconsistency and reduce  the disk space without loss of information.

Normalization has several advantages like it makes sorting faster enables index creation, more cluster indexes, few indexes per tables, few NULLs and make the database compact.

Normalization helps to simplify the table structure of tables. The performance of an application is directly linked to the database design. If database design is not proper then it slow down the process of application.

Some rules that should be followed to achieve a good database design are:

1 -Each table should have an identifier.

2-Each table should store data for a single type of entity.

3-Columns that accept NULLs should be avoid.

4-The repetition of values of columns should be avoided.

Normalization results in the formation of tables that satisfy certain specified rules and represent certain normal forms. The normal forms are used to ensure the various types of anomalies and inconsistencies are not introduced in the database. A table structure is always in a certain normal form. Several normal forms have been identified. The most important and widely used normal forms are:

1-First Normal Form (1NF)

2-Second Normal Form (2NF)

3 –Third Normal Form (3NF)

4-                4-Boyce-Codd Normal Form (BCNF)

The first, second and third normal forms were originally defined by Dr. E.F. Codd. Later, Boyce and Codd introduced another normal form called the Boyce-Codd Normal Form.

Functional Dependency

The normalization theory is based on the fundamental notion of functional dependency. First, let’s examine the concept of functional dependency.

In a given relation R, attribute A is functionally dependent on attribute B if each value of A in R is associated with precisely on value of B.

In other words, attribute A is functionally dependent on B if and only if, for each value of B, there is exactly one value of A.

Attribute B is called the determinant. Consider the following table Employee:

Code	Name	City
E1	John	Texas
E2	Sally	California
E3	Mick	Florida

Here, for Code E1 there is exactly one value of Name, John. Hence Name is functionally dependent on Code. Similarly, there is one value of City for each value of Code. Hence, the attribute City is functionally dependent on the attribute Code.  The attribute Code is the determinant. It means that Code determines City and Name.

First Normal Form (1 NF)

A table is  said to be in the 1 NF when each cell of the table contains precisely one value.

Consider the following table Project.

Ecode	Dept	DeptHead	ProjCode	Hours
E101	Systems	E901	P27 P51 P20	90 101 60
E305	Sales	E906	P27 P22	109 98
E508	Admin	E908	P51 P27	Null 72

The data in the table is not normalized because the cells in ProjCode and Hours have more than one value.

By applying the 1NF definition to the Project table, you arrive at the following table:

Ecode	Dept	DeptHead	ProjCode	Hours
E101	Systems	E901	P27	90
E101	Systems	E901	P51	101
E101	Systems	E901	P20	60
E305	Sales	E906	P27	109
E305	Sales	E906	P22	98
E308	Admin	E908	P51	NULL

Second Normal Form (2 NF)

A table is said to be in 2 NF when it is in 1 NF and every attribute in the row in functionally dependent upon the whole key, and not just part of the key. Consider the table Project

Ecode	ProjCode	Dept	DeptHead	Hours
E101	P27	Systems	E901	90
E305	P27	Finance	E909	10
E508	P51	Admin	E908	NULL
E101	P51	Systems	E901	101
E101	P20	Systems	E901	60
E508	P27	Admin	E908	72

This situation could lead to the following problems:

A-     Insertion

The department of a particular employee cannot be recorded until the employee is assigned a project.

B-     Updation

For a given employee, the employee code, department name, and department head are repeated several times. Hence, if an employee is transferred to another department, this change will have to be recorded in every row of the table pertaining to that employee. Any omission will lead to inconsistencies.

C-Deletion

When an employee completes work on a project, the employee’s record is deleted. The information regarding the department to which the employee belongs will also be lost.

The primary key here is composite (Ecode + ProjCode).

Convert a table to 2NF

Find and remove attributes that are functionally dependent on only a part of the key and not on the whole key. Place them in a different table.

Combine the remaining attributes.

To convert the table Project  into 2NF, you must remove the attributes that are not functionally dependent on the whole key and place them in a different table along with the attribute that it is functionally dependent on. In above example, since Dept is not functionally dependent on the whole key ECode+ProjCode, you place Dept along with ECode in a separate table called EmployeeDept. We also move the DeptHead to the EmployeeDept table

Following are the tables

EmployeeDept

ECode	Dept	DeptHead
E101	Systems	E901
E305	Finance	E909
E508	Admin	E908

Project

ECode	ProjCode	Hours
E101	P27	90
E101	P51	101
E101	P20	60
E305	P27	10
E508	P51	NULL
E508	P27	72

Third Normal Form (3 NF)

A table is said to be in 3NF when it is in 2 NF and every non-key attribute is functionally dependent only on the primary key.

Consider the table EmployeeDept

ECode	Dept	DeptHead
E101	Systems	E901
E305	Finance	E909
E402	Sales	E906
E508	Admin	E908
E607	Finance	E909
E608	Finance	E909

Problems in data manipulation above tables are:

A-     Insertion

The department head of a new department that does not have any employees at present cannot be entered in the DeptHead column. This is because the primary key is unknown.

B-     Updation

For a given department, the code for a particular department head (DeptHead) is repeated several times. Hence, if a department head moves to another department, the change will have to be made consistently across the table.

C-Deletion

If the record of an employee is deleted, the information regarding the head of the department will also be deleted. Hence,  there will be a loss of information.

Convert a table to 3NF

Find and remove non-key attributes that are functionally dependent on attributes that are not the primary key. Place them in a different table.

Group the remaining attributes.

To convert the table EmployeeDept into 3NF, you must remove the column DeptHead since it is not functionally dependent on only the primary key ECode, and place it in another table called Department along with the attribute Dept that it is functionally dependent on.

EmployeeDept                                               Department

Ecode	Dept
E101	Systems
E305	Finance
E402	Sales
E508	Admin
E607	Finance
E608	Finance

Dept	DeptHead
Systems	E901
Sales	E906
Admin	E908
Finance	E909