Levels of Data Normalization

I've been thinking my whole career through what the Levels of Data Normalization means. I know I've been doing it, but I didn't know on which level I am at during this process. I had a discussion with an office colleague and he told me to follow the standards, i.e., up to the 3rd level of normalization. But I didn't know what that it meant! I know this is discussed way back in College but for some reason, I couldn't remember if it was indeed taught to us by our teacher.

So I researched the internet and came up with this link here.

 An excerpt from the link:

1NF Eliminate Repeating Groups - Make a separate table for each set of related attributes, and give each table a primary key.
2NF Eliminate Redundant Data - If an attribute depends on only part of a multi-valued key, remove it to a separate table.
3NF Eliminate Columns Not Dependent On Key - If attributes do not contribute to a description of the key, remove them to a separate table.
BCNF Boyce-Codd Normal Form - If there are non-trivial dependencies between candidate key attributes, separate them out into distinct tables.
4NF Isolate Independent Multiple Relationships - No table may contain two or more 1:n or n:m relationships that are not directly related.
5NF Isolate Semantically Related Multiple Relationships - There may be practical constrains on information that justify separating logically related many-to-many relationships.
ONF Optimal Normal Form - a model limited to only simple (elemental) facts, as expressed in Object Role Model notation.
DKNF Domain-Key Normal Form - a model free from all modification anomalies.

Published 10-11-2007 5:52 AM by lamia
Filed under:

Comments

Sunday, October 14, 2007 6:28 PM by Comgen

# re: Levels of Data Normalization

I've been an instructor at AMA for 2 years, worked for a courier company for a year and now I've been working here for more than 2 years now and have been digging the structure of our banking system which was  developed by a foreign banking system company.

And Wow. Since I've been a instructor I've been asking what's on the mind of the developers, why this schema, why not normalized?

IMHO its not always "Follow" the standards. We should also sometimes de-normalized to go with query Speed, simplicity of query. etc.

Though it is very important for a developer to learn this things. =).

Hope you'll also post some things related to the "old terms" (am not sure) used like tuples,attributes etc. well its not important but its fun knowing this terms.

Sunday, October 14, 2007 11:38 PM by lamia

# re: Levels of Data Normalization

And I will sure research on that! Thanks for pointing that out! :)

Monday, October 15, 2007 1:37 AM by jakelite

# re: Levels of Data Normalization

These "Old Terms" are they the ones from relational algebra (en.wikipedia.org/.../Relational_algebra). Database subjects used to be thought using this notation. Those were the days. =D

Tuesday, October 16, 2007 7:38 AM by Comgen

# re: Levels of Data Normalization

Boss Jakelite, Mukhang lumalabas matanda na tayo heheheh..... =)

Tuesday, October 16, 2007 9:48 PM by jakelite

# re: Levels of Data Normalization

hahaha yes bossing. actually sa masters namin sa mapua. ganyan parin ang notation

Wednesday, October 24, 2007 8:08 AM by TuldokLambat

# re: Levels of Data Normalization

In the world of datawarehouses, e.f.codd will get laugh at. Try researching about datawarehouses and how it's structured and you'll realize that codd's law only applies to OLTPs (not that it does not apply to datawarehouses but it fits OLTPs more) and how your database application should be design more around current information and that history should be handled yet by another application either by a service application or a scheduled feed that transfers it from your OLTP to a datawarehouse. Making your application light. With regards to history searches, your database design should conform to that of datawarehouses i.e. denormalized for faster queries.

I'm drunk don't mind me.