Re: Normalization HOW-TO??

Duke, It's really quite simple. You get to third normal form by eliminating redundant information from your tables, and having sufficient keys to be able to fetch the information in the way you want it. Take a simple grouping and work with it, breaking it apart and then asking a bunc hof questions on how to recombine the information. Quick example ... Family Table Surname Address (etc.) Phone family_table_key (must be unique) FamilyMembers table Name Date_of_Birth Relationship (son, daughter, mother, father, etc.) Hair_color (etc.) family_member_key (unique) family_table_key (foreign key into family) So the relationship from family to familymembers is one to many, based on the family_table_key which is unique for family but not for familymembers. So, if you wanted all the members of the Normandin family you could ... select * from Family, FamilyMembers where family.surname="Normandin" which could give you all of your brothers, sisters, aunts, grandparents, moved-away-from-home children , etc. To narrow it down, you might issue ... select * from Family, FamilyMembers where family.surname="Normandin" and address = "where_you_live" Now, you can already see where I have a flaw in the design. "Relationship" is pretty vague, we may want to keep it, or add two fields "mother" and "father". These are properties unique to each child, so it would then be possible to derive a family tree, the present design doesn't allow that. But we have a high failure rate among marriages today, how do we handle scenarios where there are step-parents, etc. What about a "former-family" table, created as families break up, consisting of family_table_key and familymember keys? This raises more questions, as to the relationship field, and possibly a field should be created for the key_value of mother and father. This also is where you get into the realm of normalization vs. what do I want to store as history. I didn't use the classical "invoice" and "invoice lines" example, because the family scenario is messier, and decisions are tougher. Anyway, I hope this has helped. Regards - Miles PS If you wish, email your suggested data structures to me directly and I'll offer suggestions. But above all, don't let it snow you - it's simply eliminating repetitive information and providing sufficient keys so that you can recombine your data. /mt Duke Normandin wrote: > Hi All........ > > I've asked this before and didn't get much of a response. Would anyone be in > a position to explain *how* to implement normalization 1,2, and 3, let's > say. I've been to a lot of tutorial sites on the issue, and understand ( I > think) conceptually what they're driving at, but am having a bitch of a time > implementing the concept. It would be nice to be in the same office with > someone who was in the process or doing normalization, to see how he > goes about doing it. Maybe I'm over-complicating this, and as a result > can't see the forest for the trees. Tia.......... > -duke > > -- > PHP Database Mailing List (http://www.php.net/) > To unsubscribe, e-mail: php-db-unsubscribe@lists.php.net > For additional commands, e-mail: php-db-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net