Chapter No 4

Introduction To Database
By: Hadeesullah Sahak
Department of Computer Science
What is Normalization
 Normalization is a database design technique which organizes tables in a

manner that reduces redundancy and dependency of data.

 It divides larger tables to smaller tables and link them using relationships.

 The inventor of the relational model Edgar Codd proposed the theory of

normalization with the introduction of First Normal Form and he

continued to extend theory with Second and Third Normal Form.

 Later he joined with Raymond F. Boyce  to develop the theory of Boyce-

Codd Normal Form. 

What is Normalization – Continue

 Theory of Data Normalization in Sql is still being developed further.

For example there are discussions even on 6th Normal Form. But in

most practical applications normalization achieves its best in

3rd Normal Form. The evolution of Normalization theories is

illustrated below.
Problem With An Normalized Database

 Insert Anomaly: There are facts we cannot record until we know

information for the entire row.  In our example we cannot record a

new sales office until we also know the sales person.  Why?  Because
in order to create the record, we need provide a primary key.  In our
case this is the EmployeeID. 
Problem With An Normalized Database

 Update Anomaly: The same information is recorded in multiple rows. 

For instance if the office number changes, then there are multiple
updates that need to be made.  If these updates are not successfully
completed across all rows, then an inconsistency occurs. 
Problem With An Normalized Database

 Deletion Anomaly: Deletion of a row can cause more than one set of

facts to be removed.  For instance, if John Hunt retires, then deleting

that row cause use to lose information about the New York office. 
Database Normalization Example

 Assume a video library maintains a database of movies rented out.

Without any normalization all information is stored in one table as

shown below.

 Here you see Movies  Rented column has multiple values.

1NF (First Normal Form) Rules
 Each table cell should contain single value.
 Each record needs to be unique.
 The above table in 1NF-

 Before we proceed lets understand a few things --

What is a KEY ?
 A KEY  is a value used to uniquely identify a record in a table. A KEY could
be a single column or combination of multiple columns
 Note: Columns in a table that are NOT used to uniquely identify a record
are called non-key columns.
 What Is a Primary Key?
 A primary is a single column values used to uniquely identify a database
record.
 It has following attributes
 A primary key cannot be NULL
 A primary key value must be unique
 The primary key values can not be changed
 The primary key must be given a value when a new record is inserted.
What is Composite Key?
 A composite key is a primary key composed of multiple columns used
to identify a record uniquely
 In our database , we have two people with the same name Robert Phil
but they live at different places.

 Hence we require both Full Name and Address to uniquely identify a

record. This is a composite key.
2NF (Second Normal Form) Rules
 Rule 1- Be in 1NF
 Rule 2- Single Column Primary Key

 It is clear that we can't move forward to make our simple database in

2ndNormalization form unless we partition the table above.

2NF (Second Normal Form) – continue

 We have divided our 1NF table into two tables . Table 1 and Table2.

Table 1 contains member information. Table 2 contains information on

movies rented.

 We have introduced a new column called Membership_id which is the

primary key for table 1. Records can be uniquely identified in Table 1

using membership id
Normalization Summary
Designing A Database From the Scratch

 Steps:

 Requirements specification

 Analysis

 Conceptual design

 Implementation Design

 Physical Schema Design and Optimization

Requirements Specification

 In consultation with all potential users of the database, a database

designer’s first step is to draw up a data requirements document. The

requirements document contains a concise and non-technical

summary of what data items will be stored in the database, and how

the various data items relate to one another.

Analysis

 Taking the ‘data requirements document’, further analysis is done to

give meaning to the data items, e.g. define the more detailed

attributes of the data and define constraints if needed. The result of

this analysis is a ‘preliminary specifications’ document. 

Conceptual Design

 Taking the specifications document, the database designer models

how the information is viewed by the database system and is how it is

processed and conveyed to the end user.

Implementation Design

 In the implementation design phase, the conceptual design is

translated into a more low-level, DBMS specific design.

Data Models & Schemas as a Means of Capturing Data

 The database development design phases brings up the concept of

‘data models’. Data models are diagrams or schemas, which are used

to present the data requirements at different levels of abstraction.

The first step in the Database Development Life Cycle is to draw up a

requirements document.
Database Design 1st Step: Requirement Document

 The business is a sweet factory called ‘Candy Land’. The business buys raw

ingredients from several suppliers and keep a monthly record of the purchases.

 ‘Candy Land’ has several employees who prepare the ingredients or make sweets

in three of the company’s departments. The products are sold to a number of

retail stores, and the sales are recorded in an inventory on a monthly basis.
Database Design 1st Step: Requirement Document

 The company would like to keep track of purchases of raw ingredients and their

suppliers, as well as employees and their wages. There are 20 employees in the

company. And 3 departments.

 The employees are specialized in different areas of the sweet manufacturing process

and have different job descriptions.

 The company sells their product to a number of different remailers in various cities.

They would like to keep track of this information.

Database Design 1st Step: Requirement Document

 As far as keeping track of sales and purchases is concerned, the

company would like to keep track of the value and date of sales and
purchases as well who bought or sold what to them.

 The company is loosing a lot of money and they would like to be able

to see where costs could be cut. One example would be to examine

how much they could save by reducing the highest paid employees
wages, with the idea that they could let those employees go, and
replace them with lower skilled employees.
Database Design 1st Step: Requirement Document

 They would also like to keep track of where employees live with the

aim of letting go of employees who live too far away.

 Another request is to be able to locate retailers form various cities so

they can reduce costs by having one single deliver system to each

city, rather than have multiple deliveries there.

Database Design 2nd Step: Analyzing

 The requirements document can then be analyzed and turned into a

basic data set which can be converted into a conceptual model.

 The end result of the conceptual design phase is a conceptual data

model, which provides little information of how the database system

will eventually be implemented. The conceptual data model is simply a

high-level overview of the database system.

Database Design 2nd Step: Analyzing
COMPANY(company_name, City);

PURCHASES(company_name,suppliers_name,purchase_date, purchase_cost, ingredient_name, ingredient_quantity)

SUPPLIER(supplier_name, supplier_city)

EMPLOYEE(employee_id, employee_name, street, city, sex, ssn, bdate)

WORKS(employee_id, department_id, product_id, job_title, salary)

DEPARTMENT(department_id, company_name)

PRODUCT (product_id, product_name)

SALES (product_id, retailer_name, sales_date, sales_quantity, sales_cost)

RETAILER (retailer_name, retailer_city)

Database Design 2nd Step: Analyzing

 The previous Data Set is the Result of analyzing the Information from

the Requirements Phase. The Primary Keys are Underlined.

Database Design 3rd Step: Conceptual Design
Database Design 3rd Step: Conceptual Design
Database Design 3rd Step: Conceptual Design

A Normalized Entity-Relationship model (ERD) in Crow’s Foot

Notation is an Example of a Conceptual Data Model and provides no

information of how the database system will eventually be

implemented
Database Design 4rd Step: Implementation Design

 In the implementation design phase, the conceptual data model is translated into a

‘logical’ representation of the database system.

 The logical data model conveys the “logical functioning and structure” of the database

and describes ‘how the data is stored’ (e.g. what tables are used, what constraints are

applied) but is not specific to any DBMS.

 Logical database model is a lower-level conceptual model, which must be translated to

a physical design.
Database Design 4rd Step: Implementation Design
Database Design 4rd Step: Implementation Design

 In the implementation design phase, the conceptual data model (ERD)

is translated into a ‘logical’ representation (logical schema) of the

database system: a data dictionary.

Implementing the Database

 The final step is to physically implement the logical design which was

illustrated Before.

 To physically implement the database, a SQL can be used. These are

the main steps in implementing the database:

Create Database
 Limitations and Restrictions
 A maximum of 32,767 databases can be specified on an instance of
SQL Server.

 CREATE DATABASE Candy_Land

Create Database Tables
 The tables come directly from the information contained in the Data

Dictionary.

 The following blocks of code each represent a row in the data dictionary

and are executed one after another.

 The blocks of “create table” code contain the details of all the data

items (COMPANY, SUPPLIER, PURCHASES, EMPLOYEE etc), their attributes

(names, ages, costs, numbers and other details), the Relationships
between the data items, the Keys and Data Integrity Rules.
Create Database Tables – Continue

 All of this information is already detailed in the Data Dictionary, but

now we are actually converting it and implementing it in a physical

database system.
Create Database Tables – Continue
COMPANY TABLE
Create Database Tables – Continue
EMPLOYEE TABLE
Create Database Tables – Continue

SUPPLIER TABLE
Create Database Tables – Continue
PURCHASE TABLE
Create Database Tables – Continue
RETAILER TABLE
Create Database Tables – Continue
PORODUCT TABLE
Create Database Tables – Continue
DEPARTMENT TABLE
Create Database Tables – Continue
WORKS TABLE
Create Database Tables – Continue
SALES TABLE