CIS 9002: Oracle SQL

Normalization
At the end of this assignment, you will:

Apply 1NF, 2NF, 3NF criteria to a table of data

THERE WILL BE ONE (1) PRINTOUTS/FILES TO SUBMIT FOR CREDIT:

1. Assignment #1 your_name_normalform.doc - MS Word document that
includes tables of data in 1NF, 2NF, 3NF
Online students: email assignments to cis_assignments@comcast.net Be sure to
put CIS 60online in the subject of the email, put your name in the content of the email.
Attach the assignment files to the email. Send a copy to your own email address

Normalization
Normalization is the process of organizing and refining relations within a relational
database. It usually has the effect of reducing the duplication of data items within the
database at times reducing the amount of storage space needed for the base tables of
the database while addressing insertion, deletion and update anomalies.
Normalization often results in the creation of additional tables to achieve these goals.
Normal forms are the theoretical rules against which a relation is tested. Each normal
form presents an increasing stringent set of rules, In theory, the higher the normal
form, the stronger the design of the database. In theory, there are seven (7) forms of
normalization (1NF thru 7NF), in practically any database administrator would be
happy to have their data tables in 3NF.

1NF
First Normal Form: No Repeating Elements or Groups of Elements

Suppose novice database designer wishes to record the names and telephone
numbers of customers. He defines a customer table which looks like this:

Customer
Customer ID First Name Surname
123
Robert
Ingram
456
Jane
Wright
789
Maria
Fernandez

Telephone Number
555-861-2025
555-403-1659
555-808-9633

The designer then becomes aware of a requirement to record multiple telephone

numbers for some customers. He reasons that the simplest way of doing this is to
allow the "Telephone Number" field in any given record to contain more than one
value:

HW3a: Normal Forms: 8/11

Page: 1

CIS 9002: Oracle SQL

Customer
Customer ID First Name Surname Telephone Number
123
Robert
Ingram
555-861-2025
555-403-1659
456
Jane
Wright
555-776-4100
789
Maria
Fernandez 555-808-9633
Assuming, however, that the Telephone Number column is defined on some Telephone
Number-like domain (e.g. the domain of strings 12 characters in length), the
representation above is not in 1NF. 1NF (and, for that matter, the RDBMS) prevents a
single field from containing more than one value from its column's.
Repeating groups across columns

The designer might attempt to get around this restriction by defining multiple
Telephone Number columns:

Customer
Customer ID First Name Surname Tel. No. 1
Tel. No. 2
Tel. No. 3
123
Robert
Ingram
555-861-2025
456
Jane
Wright
555-403-1659 555-776-4100 555-403-1659
789
Maria
Fernandez 555-808-9633
This representation, however, makes use of nullable/blank columns, and therefore
does not conform to definition of 1NF. Even if the view is taken that nullable/blank
columns are allowed, the design is not in keeping with the spirit of 1NF. Tel. No. 1, Tel.
No. 2., and Tel. No. 3. share exactly the same customer ID and exactly the same
meaning; the splitting of Telephone Number into three headings is artificial and causes
logical problems. These problems include:

Difficulty in querying the table. Answering such questions as "Which customers

have telephone number X?" and "Which pairs of customers share a telephone
number?" is awkward
Inability to enforce uniqueness of Customer-to-Telephone Number links through the
RDBMS. Customer 789 might mistakenly be given a Tel. No. 2 value that is exactly
the same as her Tel. No. 1 value
Restriction of the number of telephone numbers per customer to three. If a
customer with four telephone numbers comes along, we are constrained to record
only three and leave the fourth unrecorded. This means that the database design is
imposing constraints on the business process, rather than (as should ideally be the
case) vice-versa.
Repeating groups within columns
The designer might, alternatively, retain the single Telephone Number column but
alter its domain, making it a string of sufficient length to accommodate multiple
telephone numbers:

HW3a: Normal Forms: 8/11

Page: 2

CIS 9002: Oracle SQL

Customer
Customer ID First Name Surname
Telephone Numbers
123
Robert
Ingram
555-861-2025
456
Jane
Wright
555-403-1659, 555-776-4100
789
Maria
Fernandez 555-808-9633
This design is consistent with 1NF, but still presents several design issues. The
Telephone Number heading becomes semantically non-specific, as it can now
represent either a telephone number, a list of telephone numbers, or indeed anything
at all. A query such as "Which pairs of customers share a telephone number?" is more
difficult to formulate, given the necessity to cater for lists of telephone numbers as
well as individual telephone numbers. Meaningful constraints on telephone numbers
are also very difficult to define in the RDBMS with this design.
A design that complies with 1NF

A design that is unambiguously in 1NF makes use of two tables: a Customer Name
table and a Customer Telephone Number table.

Customer Name
Customer ID First Name Surname
123
Robert
Ingram
456
Jane
Wright
789
Maria
Fernandez

Customer Telephone Number

Customer ID Telephone Number
123
555-861-2025
456
555-403-1659
456
555-776-4100
789
555-808-9633

Repeating groups of telephone numbers do not occur in this design. Instead, each
Customer-to-Telephone Number link appears on its own record. With Customer ID as
key fields, a "parent-child" or one-to-many (1:M) relationship exists between the two
tables, since a customer record (in the "parent" table) can have many telephone
number records (in the "child" table), but each telephone number usually has one, and
only one customer. This table is now in 1NF. It is worth noting that this design
meets the additional requirements for second and third normal form (3NF).

HW3a: Normal Forms: 8/11

Page: 3

CIS 9002: Oracle SQL

2NF
Any table that is in second normal form (2NF) or higher is, by definition, also in 1NF
(each normal form has more stringent criteria than its predecessor). On the other
hand, a table that is in 1NF may or may not be in 2NF; if it is in 2NF, it may or may not
be in 3NF, and so on.
Normal forms higher than 1NF are intended to deal with situations in which a table
suffers from design problems that may compromise the integrity of the data within it.
For example, the following table is in 1NF, but is not in 2NF and therefore is vulnerable
to logical inconsistencies:

Subscriber Email Addresses

Subscriber ID
Email Address
Subscriber First Name Subscriber Surname
108
steve@aardvarkmail.net
Steve
Wallace
252
carol@mongoosemail.org
Carol
Robertson
252
crobertson@aardvarkmail.net Carol
Robertson
360
hclark@antelopemail.com
Harriet
Clark
The table's key is {Subscriber ID, Email Address}.
If Carol Robertson changes her surname by marriage, the change must be applied to
two rows. If the change is only applied to one row, a contradiction results: the question
"What is Customer 252's name?" has two conflicting answers. 2NF addresses this
problem. Note that Carol Robertson's record is appearing in the table twice because it
has more than one email address related to it.
A practical way to think of 1NF in the above table is to ask a series of questions about
the relationships that records (rows) can have between entities (tables) or attributes
(columns), based on given business rules or constraints. For example, could a
Subscriber record relate to many Email Address records? Could an Email Address
record relate to many Subscriber records? In the above table we can see that Carol
Robertson has more than one email address. We could answer the questions by saying
there's a one-to-many relationship (1:M) between Subscriber and Email Address in the
above table, since a subscriber can have many email addresses, and an email address
usually has one, and only one subscriber. We would then create a separate table
called Subscribers and move the Subscriber First Name and Subscriber
Surname columns from the Subscriber Email Addresses table into the new
Subscribers table, adding a third column Subscriber ID as the primary key.
Thus, a one-to-many relationship exists between the Subscribers table (with
Subscriber ID as the primary key) and the Subscriber Email Addresses table (with
Subscriber ID as the foreign key). The tables would conform to 1NF.

HW3a: Normal Forms: 8/11

Page: 4

CIS 9002: Oracle SQL

Assignment #1a: Normal Form (1NF, 2NF, 3NF)

STEP 1: Create a MS Word document called: yourname_normalform.doc Copy
and paste the following.

NAME: ___________________________________________________________
CIS 9002 Online
DJFields
Todays date: ________________________________________________________________________

Assume you have designed this relation database table; asterisk (*) indicates the
primary key
*order_
no
001

*cust_
no
250

002

350

003

250

Na
me
Jone
s
Lee
Jone
s

Addre
ss
212
Main
111
Elm
212
Main

Ite
m1
Nut

Qt
y
20

Pric
e
2.00

Ite
m2
Bolt

Qt
y
20

Pric
e
2.00

Saw

Tabl
e

25.0
0

Drill

35.0
0
55.0
0

Item
3
wash
er

Qt
y
20

pri
ce
2.0
0

1. Put the above table in 1NF, put asterisk (*) to indicate primary key (NOTE: I have
given you some answers)

Order
Table
*Order_
no
001

Customer Table
*Order_
no

*Line_
no

003

Price

003
Jone 212 Main
s
Hint: Be sure each table has appropriate column title names

Order
Table
*Order_
no
001
002
003

250

drill

55.00

Customer Table
*Order_
no

*Line_
no

*Cust_
no

Nam
e

Addre
ss

Item

Qt
y

001

250

Jones

nut

20

2.00

001

250

Jones

212
Main
212
Main

bolt

20

2.00

HW3a: Normal Forms: 8/11

Pric
e

Page: 5

CIS 9002: Oracle SQL

001

002

002

003

Hint: Be sure each table has

HW3a: Normal Forms: 8/11

250

Jones

212
Main
350
Lee
111
Elm
350
Lee
111
Elm
250
Jones 212
Main
appropriate column title names

wash
er
saw

20

2.00

35.00

table

25.00

drill

55.00

Page: 6

CIS 9002: Oracle SQL

2. Put your solution to 1NF above into in 2NF, put asterisk (*) to indicate primary key

___ORDER_________
Table

___ORDER_________
Table
*Order_
no
001

*Cust_
no
250

Name

002

350

Lee

003

250

Jones

Addres
s
212
Main
111
Elm
212
Main

Jones

Hint: One order can consist of several line items. For example, your order to
Amazon can consist of several items. You Amazon order has ONE order #, that
order # can consist of one or more line items. Hint: Be sure each table has
appropriate column title names

_________________ Table
*Order_
no

*line_n
o

Ite
m

Qty

Pric
e

__Customer______ Table
*Order_
no
001
001

*line_
no
1
2

HW3a: Normal Forms: 8/11

Item

Qty

nut
bolt

20
20

Pric
e
2.00
2.00
Page: 7

CIS 9002: Oracle SQL

001

20

2.00

wash
er
saw

002

002

table

003

drill

35.0
0
25.0
0
55.0
0

HW3a: Normal Forms: 8/11

Page: 8

CIS 9002: Oracle SQL

3. Put your solution to 2NF above into in 3NF, put asterisk (*) to indicate primary key

_Order_
Table
*order_
no

_Customer__ Table
*cust_no

name

address

*cust_no

Hint: each order has only one customer, each order can have one or more line
items.

____Order/LineNo__________
Table
*line_n
o
1
2
3
1
2
1

_Order_
Table
*order_
no
001
002
003

_Customer__ Table
*cust_no
250
350

*cust_
no
250
350
250

name
Jones
Lee

address
212 Main
111 Elm

Hint: each order has only one customer, each order can have one or more line
items.

____Order/LineNo__________
Table
*order_
no
001

*line_n
o
1

HW3a: Normal Forms: 8/11

Item

Qty

price

nut

20

2.00

Page: 9

CIS 9002: Oracle SQL

001
001
002
002
003

2
3
1
2
1

bolt
washer
saw
table
drill

20
20
1
1
1

2.00
2.00
35.00
25.00
55.00

When done, email to me (cis_assignments@comcast.net) the MS Word file

your_name_normalform.doc

Car

HW3a: Normal Forms: 8/11

Page: 10