1-3 Normalization is actually not that didactic/pedagogic. Essentially, the goal of normalization is to ensure data integrity/sanity across tables as your database goes through life.
Foreign keys:
Let's say we have the classic example of classes at the U. Classes have students and professors. Both students and professors may change between the time the class is announced and the time school starts.
Notice that prof_id and class_id don't change, yet they are in each row. Suppose the professor changes from Dumbledore to Hagrid - then we have to do some kind of select * from class where class_id = 360...and it gets gnarly - I didn't include a row_id so I'm not sure at the moment how to write out the rest! We're in 1NF however - we don't have a group of student ids in one row.
That's *two* tables now instead of simply one. However, we have the significant advantage of being able to update the professor whenever we so please without making a major query out of it. The unique_ids let us do manipulation much easier; instead of making the entire row a primary key, we can simply use the unique ID.
no subject
Essentially, the goal of normalization is to ensure data integrity/sanity across tables as your database goes through life.
Foreign keys:
Let's say we have the classic example of classes at the U. Classes have students and professors. Both students and professors may change between the time the class is announced and the time school starts.
So a git-er-done method looks like this...
create table class(student_id int, prof_id blob, class_id int).
Over time it will wind up looking something like...
Notice that prof_id and class_id don't change, yet they are in each row. Suppose the professor changes from Dumbledore to Hagrid - then we have to do some kind of select * from class where class_id = 360...and it gets gnarly - I didn't include a row_id so I'm not sure at the moment how to write out the rest!
We're in 1NF however - we don't have a group of student ids in one row.
A 3NF way of writing this would be this
create table class_prof(unique_id int, class_id int, prof_id int)
create table class_list(unique_id int, student_id, class_id int)
That's *two* tables now instead of simply one. However, we have the significant advantage of being able to update the professor whenever we so please without making a major query out of it. The unique_ids let us do manipulation much easier; instead of making the entire row a primary key, we can simply use the unique ID.