

Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
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
1 / 3
This page cannot be seen from the preview
Don't miss anything!


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:
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."