The best thing is to get a good book on the subject. There is 1st normal
form, 2nd normal form....etc. (quite a few).
I would think that 1st normal form should do (i.e. no repeating groups as in
address1, address2...addressN) Look at how the data relates to each other.
The nature of relationships - one to one, one to many, many to one.
Example - database of students, classes, and class schedules - at minimum you
would have a table of student data, a table of all course offerenings as
classes, and a table that
associated a student with a particular class for a particular date/time.
Take that further, you might want to break out the class descriptions, etc.
into a separate table, associate
by the course-id, and perhaps a section number uniquely identifies a class,
ex. - Computer Science 302 at 10:00 am MWF...
The key is to create your tables so that there is maximum flexiblity, but
keep it simple enough that you don't have to join 30 tables together to
display one studen't class schedule...
Duke Normandin wrote:
I asked this a year or so ago, but never did receive a "practical" reply
> that I could understand. So I'll give it another shot...
> What are the "nuts-and-bolts" of normalization? In a "practical" sense,
> how do you guys go about doing it? Do you create a spreadsheet or
> something, and start creating 'test' tables and see how they pan out?
> I understand what the 'goal' of normalization is suppose to be, I just
> never stumbled on a method of achieving it. Know what I mean?
> Calgary, Alberta, Canada
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]