Normalization? What does this mean?

Rick Stanich

King and Supreme Ruler
Local time
Today, 16:34
Joined
May 13, 2009
Messages
93
I read this line a lot in posts and I dont fully understand it.
The first problem I see is that maybe you have a normalization issue.

I'm as normal as they come, unless you ask my mom, she says I'm an alien. :cool:

What does this mean to databases?
 
It means you should split up your tables into dozens of tables, preferably no more than 2 fields per table (not including a primary key):D
 
It means you should split up your tables into dozens of tables, preferably no more than 2 fields per table (not including a primary key):D

What kind of answer is that? :confused: bad advice. :eek:
 
What kind of answer is that? :confused: bad advice. :eek:

I think it was an attempt at humor. (see the smiley added on?)

I like humor too but in this case I don't think it worked. But anyway, a very simple explanation of normalization means:

Creating a structure which will enable you to maintain the integrity of the data, add new things using records instead of having to add fields, and keeping redundant data to a minimum. There are, of course, several levels of normalization and those are discussed in the link that was provided (I believe). You want to normalize to a point which helps your application do what it needs to do without having to make major changes every time something changes.

Hope that helps lift the fog a little.
 
I think it was an attempt at humor. (see the smiley added on?)

I like humor too but in this case I don't think it worked. But anyway, a very simple explanation of normalization means:

Creating a structure which will enable you to maintain the integrity of the data, add new things using records instead of having to add fields, and keeping redundant data to a minimum. There are, of course, several levels of normalization and those are discussed in the link that was provided (I believe). You want to normalize to a point which helps your application do what it needs to do without having to make major changes every time something changes.

Hope that helps lift the fog a little.

I understood the humor, but didn't want to confuse the OP.... :) :p
 
I hope that was in jest... it's impossible to quantify how much fields a given table. It's possible for a perfectly normalized table to have 100 fields but such valid structure are almost guaranteed to be very few and quite far in between.

The core point of normalization is to eliminate redundancy so you only store one piece of data, whatever it may be, in a single location, and have all references to that data pointed by other records. It's a worthwhile exercise to study the process of decomposing your tables into normalized structure.


(Crikey, now I feel like a snail!)
 
Geeeeez! I won't be making anymore jokes ever!

Anyway, all of the information given is highly accurate but after clicking the link I felt that someone with no knowledge of normalization would still be left confused and thus the joke. Although Bob and Banana's (and msft) answers are correct I think the OP needs to purchase an access book (Missing Manual series is very helpful) and go over normalization and other design techniques. Otherwise they will end up doing just as the joke implied!
 
Geeeeez! I won't be making anymore jokes ever!

Anyway, all of the information given is highly accurate but after clicking the link I felt that someone with no knowledge of normalization would still be left confused and thus the joke. Although Bob and Banana's (and msft) answers are correct I think the OP needs to purchase an access book (Missing Manual series is very helpful) and go over normalization and other design techniques. Otherwise they will end up doing just as the joke implied!

No worries, we got the humor :)
 
Otherwise they will end up doing just as the joke implied!
Not necessarily, but there is a chance. That's why a thread in the theory and design forum area posted after designing the structure is a good thing to do. That way they can have several people look at it and help them fix any problems with the design BEFORE going further.
 
The purpose of normalization is to remove data anomalies.

Examples are helpful in understanding normalization. A good site for data modelers is the data administrator's network (www.tdan.com). There are articles and examples.

Proper data modeling is a profession to itself. It's best to just understand the basics. Then just ask on a forum like this if your model needs more work. You'll get tons of responses (some of them will be right).

In the end, you'll use the model that meets the needs outlined by your users. Please observe that this is different from the model the users say to use, which normally looks like a spreadsheet (not normalized with plenty of data anomalies).
 
Last edited:
Consider as an example a data base for your personal contacts.

In this data base you keep records of your friends and such details as their name, age etc. and also the details of their children such as gender, age, school and so on.

You make a table and add the various fields. But a problem will arise with the details of the kids. If all your friends had only one child then you could have fields in the table such as

ChildFirstName ChildAge ChildSchool ChildGender

But since some will have more than one kid you will also need fields

ChildFirstName2 ChildAge2 ChildSchool2 ChildGender2
ChildFirstName3 ChildAge3 ChildSchool3 ChildGender3 and so on.

How many sets of fields do you have?

After you set up that up imagine how difficult it will be to find the average age of your friend's kids, the oldest and youngest etc. A lot of your friends will have no kids so you will have lots of records with lots of empty fields.

So instead of having fields for children details you make another table for those details. Now someone who has 6 kids will have 6 records in that table and each record will have a field for an ID number and that number will be the same as the main record in the main table.

The data base with all the details in one table would be very unnormalised and the second would be normalised.

Then next stage is the degree of normalisation and your friends address and phone details would be example. In my case I never fully normalise so I will have home, business and mailing address details in the main table. I will also have home phone, business, mobile and fax in the main table. However, that can cause a problem if they have two mobile phones and three business numbers etc. I get around that by having another table that acts as "an extra details" and is in the form of notes such as "phone Bob on 123456789 if his other number is engaged or whatever. However, that is not the accepted way of doing things.
 

Users who are viewing this thread

Back
Top Bottom