Relational Databases: Normalization - From Unnormalized to Third Normal Form, Study notes of Accounting

The concept of database schema normalization and the importance of removing redundant data through normalization. It uses the example of a purchase order document to illustrate the process of normalizing a database from unnormalized form to third normal form, which involves removing repeating groups, partial key dependencies, and non-key dependencies. The document also discusses the benefits of normalization, such as minimizing database redundancy, easier querying, and removing update anomalies.

Typology: Study notes

Pre 2010

Uploaded on 11/08/2009

koofers-user-7w5
koofers-user-7w5 🇺🇸

2

(1)

9 documents

1 / 3

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Relational Databases: Introduction to Normalization
Database schema normalization is a database design technique. Normalization is a step-by-step procedure
for examining a database design and detecting any entity types (which are modelled as tables) that we may
have missed.
Consider the following purchase order document:
PO#: 12356
Date: 05/30/91
Vendor#: 1245
Item# Qty. Description Color# Color Price
123 12 Hammers 3 Black 4.34
236 2 Squeegees 4 Blue 1.21
238 4 Squeegees 3 Black 1.21
We can model the document directly as a single table:
PO ( PO#, Vendor#, Date, Item1#, Qty1, Desc1, Color#1, Color1, Price1,
Item2#, Qty2, Desc2, Color#2, Color2, Price2,
Item3#, Qty3, Desc3, Color#3, Color3, Price3 ,
...
ItemN#, QtyN, DescN, Color#N, ColorN, PriceN )
This database (comprised of the single table above) is considered to be in unnormalized form, because it
includes a repeating group.
This table specification has undesirable characteristics in several respects. First, we do not know how
many items to allow for. Second, it is difficult to devise queries to manipulate item information as
information on a particular item might appear in any one of N different sets of information. A query to
search for the quantity of all of a particular item which we have on order might look like:
SELECT FROM PO ITEM1#,QTY1,ITEM2#,QTY2,...,ITEMN#,QTYN
WHERE ITEM1#=234 OR ITEM2#=234...OR ITEMN#=234;
This is unwieldy, and it leads us to consider an alternative design for the table.
An alternative design removes the repeating group :
PO ( PO#, Item#, Vendor#, Date, Qty, Desc, Color#, Color, Price )
Now it is easy to devise queries which involve the selection of lines from the invoice. This table is
considered to be in First Normal Form because it contains no repeating groups.
Examine the database (which has only one table) as it looks with data:
ISM 4212 Relational Databases: Introduction to Normalization 12/02/20 1
pf3

Partial preview of the text

Download Relational Databases: Normalization - From Unnormalized to Third Normal Form and more Study notes Accounting in PDF only on Docsity!

Relational Databases: Introduction to Normalization

Database schema normalization is a database design technique. Normalization is a step-by-step procedure for examining a database design and detecting any entity types (which are modelled as tables) that we may have missed. Consider the following purchase order document:

PO#: 12356

Date: 05/30/

Vendor#: 1245

Item# Qty. Description Color# Color Price 123 12 Hammers 3 Black 4. 236 2 Squeegees 4 Blue 1. 238 4 Squeegees 3 Black 1. We can model the document directly as a single table: PO ( PO#, Vendor#, Date, Item1#, Qty1, Desc1, Color#1, Color1, Price1, Item2#, Qty2, Desc2, Color#2, Color2, Price2, Item3#, Qty3, Desc3, Color#3, Color3, Price3 , ... ItemN#, QtyN, DescN, Color#N, ColorN, PriceN ) This database (comprised of the single table above) is considered to be in unnormalized form, because it includes a repeating group. This table specification has undesirable characteristics in several respects. First, we do not know how many items to allow for. Second, it is difficult to devise queries to manipulate item information as information on a particular item might appear in any one of N different sets of information. A query to search for the quantity of all of a particular item which we have on order might look like: SELECT FROM PO ITEM1#,QTY1,ITEM2#,QTY2,...,ITEMN#,QTYN WHERE ITEM1#=234 OR ITEM2#=234...OR ITEMN#=234; This is unwieldy, and it leads us to consider an alternative design for the table. An alternative design removes the repeating group : PO ( PO#, Item#, Vendor#, Date, Qty, Desc, Color#, Color, Price ) Now it is easy to devise queries which involve the selection of lines from the invoice. This table is considered to be in First Normal Form because it contains no repeating groups. Examine the database (which has only one table) as it looks with data:

PO# Item# Vendor# Date Qty Desc Color# Color Price 12356 123 1245 05/30/91 12 Hammers 3 Black 4. 12356 236 1245 05/30/91 2 Squeegees 4 Blue 1. 12356 238 1245 05/30/91 4 Squeegees 3 Black 1. 12357 123 334 06/01/91 3 Hammers 3 Black 4. 12357 236 334 06/01/91 1 Squeegees 4 Blue 1. After first normal form is attained, second normal form is sought in the process of normalization. To go from first normal form to Second Normal Form you look for attributes that do not require the complete primary key for their identification. It is said that you look for attributes that do not depend on the complete primary key. In the above table of purchase order information, it can be seen that Vendor# and Date depend only on PO#, that is, if you know the PO# you can look up Vendor# and the PO date, as those values are uniquely defined by the PO#. Also, you can see that some of the item information (Description, Price, Color#, and Color) depends only on Item#. To achieve second normal form we isolate the attributes that depend only on PO# and those that depend only on Item# and place them in separate tables: PO ( PO#, Vendor#, Date ) Item ( Item#, Desc, Price, Color#, Color ) POLine (PO#, Item#, Qty ) So all that is left dependent on the earlier primary key (PO#+Item#) is the quantity ordered. In the process of deriving second normal form we have identified three entity types where at first we only saw a single one. We now have three tables with three primary keys. The database now contains less redundant data: PO: PO# Vendor# Date 12356 1245 05/30/ 12357 334 06/01/ Item: Item# Desc Price Color# Color 123 Hammers 4.34 3 Black 236 Squeegees 1.21 4 Blue 238 Squeegees 1.21 3 Black POLine: PO# Item# Qty 12356 123 12 12356 236 2 12356 238 4 12357 123 3 12357 236 1 Our next step in normalization is to discover a Third Normal Form. This requires that we search the database schema for instances of attributes which depend on other, non-(primary)key attributes. An examination of the above database reveals that Color always depends on Color#. Color#="3" always indicates "Black," and Color#="4" always indicates "Blue."