I’m a jr. developer (5 months on the job), and I have a question about data normalization. Now, as I understand it, the general principle behind data normalization is to create a RDBMS where data redundancy is kept to a minimum. In my project, one of the DB people created a DB. We have 50+ tables, and the tables in the DB are usually very fragmented, ie. a table has two or three columns and that’s it. Now, when it comes to writing sql queries, it has become something of a minor hassle since each query involves combing through several different tables and joining them together. I was wondering if this is a a side effect of data normalization? Or does this point to something else?
I know that the easiest thing to do, for me, would be to write tables based off the queries I have to write. This will create a DB with a lot of redundant data, but I was curious if there is a happy medium?
Just as a postscript, I don’t want to come across like I’m whining about my work, but I’m genuinely curious to learn more about this. My work environment is not the most friendly so I don’t feel comfortable posing this question with my colleagues. However, I would appreciate any thoughts, books, tutorials or opinions from more experienced people.
Thanks.
Only partly true.
Normalization is not about “redundancy”.
It’s about “update anomalies”.
1NF is the “don’t use arrays” rules. Breaking 1NF means a row isn’t atomic, but a collection and independent updates in the collection wouldn’t work out well. There’d be locking and slowness.
2NF is the “one key” rule. Each row has exactly one key and everything in the row depends on the key. There are no dependencies on part of the key. Some folks like to talk about candidate keys and natural keys and foreign keys; they may exist or they may not. 2NF is satisfied when all attributes depend on one key. If the key is a single-column surrogate key, this normal form is trivially satisfied.
If 2NF is violated, you’ve got columns which depend on part of a key, but not the whole key. If you had a table with (Part Number, Revision Number) as a key, and attributes of color and weight, where weight depends on the whole key, but color only depends on the part number. You have a 2NF problem where you could update some part colors but not others, creating data anomalies.
3NF is the “only the key” rule. If you put derived data in a row, and change the derived result, it doesn’t match the source columns. If you change a source column without updating the derived value, you have a problem, too. Yes, triggers are a bad hackaround to allow 3NF design violations. That’s not the point. The point is merely to define 3NF and show that it prevents an update problem.
It is.