Normalize or not to normalize?

twitchie

Registered User.
Local time
Today, 13:44
Joined
Jan 16, 2003
Messages
41
I have a performance evaluation db in MSA 2003 I am about done with. I had asked a question and got a helpful response. However, the response mentioned normalizing so I hit up google for more info. My db is not normalized, but after reading several sites, I don't see why I need to normalize it. The sites also said there are not a lot od reason not to normalize. I can't believe I just stumbled onto one. I have fields in my table that need to be scored on a 1-5 scale. I can see making a separate table for scores. However, the list of questions never grows or shrinks. It's a standard format that asks the same 20 or so question every time. Is there a reason to split the table into multiple tables? If so, would it be the scores vs. employee info tables? TIA for your assistance!
 
normalization is something that is taught in all database courses etc, its the industry standard at getting all the fields you will be using and splitting them into dependancies on one another, the steps are quite detailed and most are fairly obvious.

Your database will prob be functioning properly anyway, but i suggest you should read more into normalization and try to understand the steps it goes through, i think there is about 4/5 steps you take. Does seem to make creating a database a confusing task but once you understand the use of it then you will see that it can be fairly easy step.
 
Normalization is the key to an efficiently run database. The rules of normalization were first devised over 30 years ago and are still in place (with little modification). The relational database model is the most popular and widely used model. In the face of such overwhelming support for this model, do you think there is still reason not to normalize?

A questionaire database would have a minimum of three tables:

tblQuestions
QuestionID (Primary Key Autonumber)
Question

tblRespondent
REspondentID (PK Autonumber)
Firstname
Lastname

tblResponses
ResponseID (PK Autonumber)
QuestionID (Foreign key)
RespondentID (FK)
 
Thanks to everyone for your input. I think some reading is in order. I've never taken any db or Access classes. Everything I know I have learned on my own. I'm learning VB right now to help out. I need to do some reading on normalization since it appears to be the smart way to organize data in a db. Thanks again!
 
I think I was the one who pointed out the issue of normalisation to you.

I'm not a trained programmer and I have only learned about normalisation through these forums. A number of applications that I have developed in the past are horribly un-normalised, yet they are still in frequent use and work perfectly adequately. However, if I develop a new one, now, I apply the rules of normalisation (more or less) and I run into much fewer problems. As Pat points out, Access does not directly support aggregation 'horizontally', only 'vertically' wheras Excel works in both directions. Normalisation makes your data 'vertical'.
 

Users who are viewing this thread

Back
Top Bottom