DATABASE DESIGN

DATABASE DESIGN history

Relational database was proposed by Edgar Codd (of IBM
Research) around 1969. It has since become the dominant
database model for commercial applications (in comparison
with other database models such as hierarchical, network
and object models).
Today, there are many commercial Relational Database
Management System (RDBMS), such as Oracle, IBM DB2 and
Microsoft SQL Server. There are also many free and open-
source RDBMS, such as MySQL, mSQL (mini-SQL) and the
embedded JavaDB (Apache Derby).
 DATABASE DESIGN introduction

TABLE NAME
A relational database organizes data
FIELD 1
in tables.
FIELD 2
FIELD 3 A table is made up of rows and
TABLE NAME 2
FIELD 1
columns.
FIELD 2
FIELD 3
 DATABASE DESIGN objectives

1. Eliminate Data Redundancy

duplication of data is a waste of storage in
computers memory and can lead to inconsistencies
2. Ensure Data Integrity and Accuracy
 DATABASE DESIGN how to
Step 1: Define the Purpose of the Database
(Requirement Analysis)
Step 2: Gather Data, Organize in tables and Specify the
Primary Keys
Step 3: Create Relationships among Tables
Step 4: Refine & Normalize the Design
 Gather the requirements and define
the objective of your database.
Draftingout the sample input forms
and creating logical diagrams to help
understand the system.

DEFINE THE PURPOSE OF THE DATABASE

 IT 29 Covered Activities
System Analysis
Data Flow Diagram
Entity-Relationship Diagram

DEFINE THE PURPOSE OF THE DATABASE

system analysis
conversion of ERD to relational db

Logical ERD Physical ERD

system analysis
conversion of ERD to relational db
The ER Model is intended as a description of real-
world entities. Although it is constructed in such a
way as to allow easy translation to the relational
schema model, this is not an entirely trivial process.

The ER diagram represents the conceptual level

of database design meanwhile the relational
schema is the logical level for the database
design.
system analysis
conversion of ERD to relational db
simple entity-attribute
An entity type within ER diagram is turned
into a table.
Each attribute turns into a column (attribute)
in the table. The key attribute of the entity is
the primary key of the table which is usually
underlined.
system analysis
conversion of ERD to relational db
simple entity-attribute

PERSON
Name
Lastname
Phone
Email
system analysis
conversion of ERD to relational db
simple entity-attribute
Identify the primary/other keys.
Primary Keys = PK or *
Foreign Key = FK

PERSON PERSON
Name Person Number *
Lastname Name
Phone Lastname
Email Phone
Email
system analysis
conversion of ERD to relational db
multi-valued attributes
Ifyou have a multi-valued attribute, take the
attribute and turn it into a new entity or
table of its own.
Then make a 1:N relationship between the
new entity and the existing one.
system analysis
conversion of ERD to relational db
multi-valued attributes
1. Create a table for the attribute. Country Code

Area Code

PERSON PHONE
Name Country Code
Area Code
system analysis
conversion of ERD to relational db
multi-valued attributes
1. Create a table for the attribute.
PERSON PHONE
Person Number* Phone ID*
Name Country Code
Area Code

system analysis
conversion of ERD to relational db
multi-valued attributes
2. Add the primary (id) column of the parent
entity as a foreign key within the new table
PERSON PHONE
Person Number* Phone ID*
Name Person Number FK
Country Code
Area Code

system analysis
conversion of ERD to relational db
1:1 relationship
Make tables for each entities and set the
foreign key to the table where the other table
is depending/connecting to.
system analysis
conversion of ERD to relational db
1:1 relationship

PERSON WIFE
Name Name
Lastname
Phone
Email

system analysis
conversion of ERD to relational db
1:1 relationship
PERSON WIFE
Person Number * Wife Number *
Name Name
Lastname
Phone
Email
Wife Number FK

Note: this can be done in the other way around depending

on the relationship
system analysis
conversion of ERD to relational db
1:N relationships
Make tables for each entities and set the
foreign key to the table where the other table
is depending/connecting to.

Unlike the 1:1, the relationship should be

considered before setting the foreign to the
other table and not the other way around.
system analysis
conversion of ERD to relational db
1:N relationships

PERSON HOUSE
Name House Number
Lastname Address
Phone
Email
system analysis
conversion of ERD to relational db
1:N relationshipsPERSON HOUSE
Person Number* House Number*
Name Address
Lastname Person NumberFK
Phone
Email

the Person can have a House from zero to many , but

a House can have only one Person. To represent such
relationship the person number as the Parent node must
be placed within the Child table as a foreign key but not the
other way around
system analysis
conversion of ERD to relational db
N:N relationships
Many to many relationship will require
additional field to connect both of the tables.
system analysis
conversion of ERD to relational db
N:N relationships Address

PERSON COUNTRY
Name Country Num
Lastname Address
Phone
Email
system analysis
conversion of ERD to relational db
N:N relationships
PERSON COUNTRY
Person Number* Country Number*
Name Address
Lastname

Person-Country
Person-CountryID*
Person NumberFK
Country NumberFK
 1. Gather the data that are needed to be
stored in the database.
2. Divide the data into subject-based tables.
3. Choose one column (or a few columns) as
the so-called primary key, which
uniquely identify the each of the rows.

GATHER DATA, ORGANIZE IN TABLES AND SPECIFY THE PRIMARY KEYS

 TeacherID NAME OFFICE PHONE Email
0001 Felicity Smoak Verdant +218711 frl@mail.com

0002 John Snow Wall +2987123 Js@mail.com

0003 Rick hunter East London +165932 rock@mail.com

0004 Oliver Quin Verdant +164685 oli@mail.com

GATHER DATA, ORGANIZE IN TABLES AND SPECIFY THE PRIMARY KEYS

 Primary Key is identified by an asterisk (*) or PK and
at the top of the field list. Foreign Key specified by FK.

* PK

FK

GATHER DATA, ORGANIZE IN TABLES AND SPECIFY THE PRIMARY KEYS

 PRIMARY KEY
In the relational model, a table cannot
contain duplicate data (eliminate data
redundancy). To ensure uniqueness, each
table should have a column (or a set of
columns), called primary key, that uniquely
identifies every records of the table.

GATHER DATA, ORGANIZE IN TABLES AND SPECIFY THE PRIMARY KEYS

 PRIMARY KEY PROPERTIES
The values of primary key shall be unique.
The primary key shall always have a value.
In other words, it shall not contain NULL.

GATHER DATA, ORGANIZE IN TABLES AND SPECIFY THE PRIMARY KEYS

 CHOOSING A PRIMARY KEY
1. The primary key shall be simple and familiar
2. The value of the primary key should not change
3. Primary key often uses integer (or number) type. But it could
also be other types, such as texts. However, it is best to use
numeric column as primary key for efficiency.
4. Primary key could take an arbitrary number. Most RDBMSs
support so-called auto-increment (or AutoNumber type) for
integer primary key, where (current maximum value + 1) is
assigned to the new record
5. Primary key is usually a single column

GATHER DATA, ORGANIZE IN TABLES AND SPECIFY THE PRIMARY KEYS

 EXAMPLE
A table customers contains columns lastName,
firstName, phoneNumber, address, city, state, zipCode.
The candidates for primary key are name=(lastName,
firstName), phoneNumber, Address1=(address, city,
state), Address1=(address, zipCode).
Name may not be unique. Phone number and address
may change. Hence, it is better to create a fact-less
auto-increment number, say customerID, as the primary
key.

GATHER DATA, ORGANIZE IN TABLES AND SPECIFY THE PRIMARY KEYS

 RELATIONSHIPS
The power of relational database lies in the
relationship that can be defined between tables.
The most crucial aspect in designing a relational
database is to identify the relationships among
tables.
one-to-many, many-to-many and one-to-one

CREATE RELATIONSHIPS AMONG TABLES

 ONE to MANY
In a class list database, a teacher may teach zero or more
classes, while a class is taught by one (and only one)
teacher.
In a "company" database, a manager manages zero or
more employees, while an employee is managed by one
(and only one) manager.
In a "product sales" database, a customer may place
many orders; while an order is placed by one particular
customer.

CREATE RELATIONSHIPS AMONG TABLES

 ONE to MANY

The column teacherID in the child table Classes is known as the foreign
key. A foreign key of a child table is a primary key of a parent table, used
to reference the parent table.

CREATE RELATIONSHIPS AMONG TABLES

 MANY to MANY
In a "product sales" database, a customer's
order may contain one or more products;
and a product can appear in many orders.
In a "bookstore" database, a book is written
by one or more authors; while an author
may write zero or more books.

CREATE RELATIONSHIPS AMONG TABLES

 MANY to MANY

CREATE RELATIONSHIPS AMONG TABLES

 MANY to MANY
1. An order has many items in OrderDetails. An
OrderDetails item belongs to one particular order.
2. A product may appears in many OrderDetails. Each
OrderDetails item specified one product.

CREATE RELATIONSHIPS AMONG TABLES

 ONE to ONE
In a "product sales" database, a product may have
optional supplementary information such as image,
more Description and comment. Keeping them inside
the Products table results in many empty spaces (in
those records without these optional data). Furthermore,
these large data may degrade the performance of the
database.

CREATE RELATIONSHIPS AMONG TABLES

 ONE to ONE

CREATE RELATIONSHIPS AMONG TABLES

 adding more columns
createa new table for optional data using one-
to-one relationship
split a large table into two smaller tables

REFINE AND NORMALIZE DESIGN

NORMALIZATION
Normalization is a process that improves a
database design by generating relations that are
of higher normal forms:
1NF is considered the weakest,
2NF is stronger than 1NF,
3NF is stronger than 2NF

REFINE AND NORMALIZE DESIGN

FUNCTIONAL DEPENDENCIES
An attribute, B, has a functional dependency on
another attribute, A, if for any two records,
which have the same value for A, then the
values for B in these two records must be the
same. { A -> B }

REFINE AND NORMALIZE DESIGN

FUNCTIONAL DEPENDENCIES
Suppose we keep track of employee email addresses, and we
only track one email address for each employee. Suppose
each employee is identified by their unique employee number.
We say there is a functional dependency of email address on
employee number:
employee number -> email address
Employee Number Employee Name Email Address
0001 Barry Allen bAllen@mail.com
0002 Quentin Coldwater quentin@mail.com

REFINE AND NORMALIZE DESIGN

1ST NORMAL FORM
As per First Normal Form, no two Rows of data
must contain repeating group of information i.e
each set of column must have a unique value,
such that multiple columns cannot be used to
fetch the same row. Each table should be
organized into rows, and each row should have a
primary key that distinguishes it as unique.

REFINE AND NORMALIZE DESIGN

1ST NORMAL FORM

REFINE AND NORMALIZE DESIGN

1ST NORMAL FORM
STUDENT TABLE 1NF

REFINE AND NORMALIZE DESIGN

2ND NORMAL FORM
As per the Second Normal Form there must not
be any partial dependency of any column on
primary key. It means that for a table that has
concatenated primary key, each column in the
table that is not part of the primary key must
depend upon the entire concatenated key for its
existence. If any column depends only on one
part of the concatenated key, then the table fails
Second Normal Form.

REFINE AND NORMALIZE DESIGN

2ND NORMAL FORM

REFINE AND NORMALIZE DESIGN

2ND NORMAL FORM
In example of First Normal Form there are two rows for
Adam, to include multiple subjects that he has opted for.
While this is searchable, and follows First normal form, it is
an inefficient use of space. Also in the Table in First Normal
Form, while the candidate key is {Student, Subject}, Age of
Student only depends on Student column, which is incorrect
as per Second Normal Form. To achieve second normal
form, it would be helpful to split out the subjects into an
independent table, and match them up using the student
names as foreign keys.

REFINE AND NORMALIZE DESIGN

2ND NORMAL FORM
STUDENT
Name
Age
Subject

STUDENT SUBJECT
Name Name
Age Subject

REFINE AND NORMALIZE DESIGN

2ND NORMAL FORM
STUDENT TABLE SUBJECT TABLE

REFINE AND NORMALIZE DESIGN

3rd NORMAL FORM
Third Normal form applies that every non-prime
attribute of table must be dependent on primary
key, or we can say that, there should not be the
case that a non-prime attribute is determined by
another non-prime attribute. So this transitive
functional dependency should be removed from
the table and also the table must be in Second
Normal form.

REFINE AND NORMALIZE DESIGN

3rd NORMAL FORM
In this table STUDENT ID is
Primary key, but State and STUDENT
city depends upon Zip. Student ID
The dependency between zip Student Name
and other fields is called Date of Birth
transitive dependency. Hence State
to apply 3NF, we need to City
move the street, city and Zip
state to new table, with Zip as
primary key.

REFINE AND NORMALIZE DESIGN

3rd NORMAL FORM
STUDENT Address
Student ID PK Zip PK
Student Name City
Date of Birth State
Zip FK

REFINE AND NORMALIZE DESIGN

3rd NORMAL FORM
Third Normal form applies that every non-prime
attribute of table must be dependent on primary
key, or we can say that, there should not be the
case that a non-prime attribute is determined by
another non-prime attribute. So this transitive
functional dependency should be removed from
the table and also the table must be in Second
Normal form.

REFINE AND NORMALIZE DESIGN