This is one of the cleanest explanations of normalization I have come across. I will use this with a few high school students I am working with, and I expect it will be pretty easy for them to understand.
It would have been a good explanation of normalization had the author picked some better examples for his data. The way it's written, the normalization ends up changing the semantics of the data, which is not what it's supposed to do.
- The normalized schema assumes that the location of a tournament will never change. If the 2014 Australian Open were to be held in Sydney, then looking up the location of the 2012 Australian Open would thereafter yield "Sydney".
- Population has the same problem. It's not likely that the population of a city will remain constant over time. The original database would give you the population at the time the tournament was held. The normalized version always gives you the current population of the city.
I've updated the article to use data that does not (generally) change from year to year: country and area instead of city and population. This should eliminate the semantic issue and make it clearer.
Probably okay for your tutorial...but country areas change from time to time due to territorial disputes being resolved, or due to older erroneous info being changed.
Cities can also change country. Pristina used to be in Serbia but is now in Kosovo (although this is not universally acknowledged). Bratislava used to be in Czechoslovakia but is now in Slovakia.
While just pedantic in this case, it demonstrates how hard it can be to create a strong data model.
Really, normalization is just a special case of DRY. And it has the same value for the same reasons. The attempt to enumerate the "kinds" of normal forms is, IMHO, a mistake. The only point to doing it is reducing bug surface (and just maybe storage space efficiency), so really: who cares whether or not your data is second or third normal form? Does the duplication of fields help or hurt your application?
A good example of this is US ZIP codes. In theory (I think), a ZIP uniquely identifies a city and state. But in practice no one stores it this way because the maintenance of that data (by all parties: some people don't know zips, or type them incorrectly) is more expensive than the savings from normalization.
Uh, relational databases are a well established field. The different normal forms, among other useful things, provide a guide to way to prevent specific kinds of logical errors that can otherwise appear during inserts, updates and deletes. There's a lot here.
DRY - "don't repeat yourself" - is simply a slogan that doesn't provide specific procedures for making things compact, how you do it or when its appropriate. What you're saying is a lot like "abstract algebra is just a special case of thinking logically" - sort of true but mostly deceptive if it lets you dismiss a lot of accumulated knowledge with "just think logically".
I don't think you're seeing my point: the value to "normalization" isn't its specificity or the fact that it's grounded in a formal description. It's that it's a straightforward way to reduce the maintenance burden of software using the database (your words: "prevent specific kinds of logical errors"). That's precisely the value of DRY philosophy.
I don't see it as controversial at all to paint it as a "subset" of DRY; I'm sorry if it offends your academic aesthetic.
If you are curious as to why you have been voted down: your position is "why do people care whether your data is in a specific normal form"? The answer, of course, is that if you don't normalise a relational database then you will find all sorts of problems down the track.
Enumerating the normal forms is important as you typically must do one after another. It's not just academic formalism to expound three normal forms. I suspect you don't know much about relational theory, which is why you feel that normalisation is a "mistake".
There are actually ZIP codes that intersect multiple cities, counties, and even states. This is because ZIP codes are designed to make delivering mail easy. Your main point still stands, of course.
Comments
This is one of the cleanest explanations of normalization I have come across. I will use this with a few high school students I am working with, and I expect it will be pretty easy for them to understand.
It would have been a good explanation of normalization had the author picked some better examples for his data. The way it's written, the normalization ends up changing the semantics of the data, which is not what it's supposed to do.
- The normalized schema assumes that the location of a tournament will never change. If the 2014 Australian Open were to be held in Sydney, then looking up the location of the 2012 Australian Open would thereafter yield "Sydney".
- Population has the same problem. It's not likely that the population of a city will remain constant over time. The original database would give you the population at the time the tournament was held. The normalized version always gives you the current population of the city.
I've updated the article to use data that does not (generally) change from year to year: country and area instead of city and population. This should eliminate the semantic issue and make it clearer.
Probably okay for your tutorial...but country areas change from time to time due to territorial disputes being resolved, or due to older erroneous info being changed.
Cities can also change country. Pristina used to be in Serbia but is now in Kosovo (although this is not universally acknowledged). Bratislava used to be in Czechoslovakia but is now in Slovakia.
While just pedantic in this case, it demonstrates how hard it can be to create a strong data model.
Yes, that's quite true. Creating even what I would have thought to be a 'simple' example isn't as trivial as I have expected.
Really, normalization is just a special case of DRY. And it has the same value for the same reasons. The attempt to enumerate the "kinds" of normal forms is, IMHO, a mistake. The only point to doing it is reducing bug surface (and just maybe storage space efficiency), so really: who cares whether or not your data is second or third normal form? Does the duplication of fields help or hurt your application?
A good example of this is US ZIP codes. In theory (I think), a ZIP uniquely identifies a city and state. But in practice no one stores it this way because the maintenance of that data (by all parties: some people don't know zips, or type them incorrectly) is more expensive than the savings from normalization.
normalization is just a special case of DRY
Uh, relational databases are a well established field. The different normal forms, among other useful things, provide a guide to way to prevent specific kinds of logical errors that can otherwise appear during inserts, updates and deletes. There's a lot here.
DRY - "don't repeat yourself" - is simply a slogan that doesn't provide specific procedures for making things compact, how you do it or when its appropriate. What you're saying is a lot like "abstract algebra is just a special case of thinking logically" - sort of true but mostly deceptive if it lets you dismiss a lot of accumulated knowledge with "just think logically".
I don't think you're seeing my point: the value to "normalization" isn't its specificity or the fact that it's grounded in a formal description. It's that it's a straightforward way to reduce the maintenance burden of software using the database (your words: "prevent specific kinds of logical errors"). That's precisely the value of DRY philosophy.
I don't see it as controversial at all to paint it as a "subset" of DRY; I'm sorry if it offends your academic aesthetic.
If you are curious as to why you have been voted down: your position is "why do people care whether your data is in a specific normal form"? The answer, of course, is that if you don't normalise a relational database then you will find all sorts of problems down the track.
Enumerating the normal forms is important as you typically must do one after another. It's not just academic formalism to expound three normal forms. I suspect you don't know much about relational theory, which is why you feel that normalisation is a "mistake".
There are actually ZIP codes that intersect multiple cities, counties, and even states. This is because ZIP codes are designed to make delivering mail easy. Your main point still stands, of course.