Consider the following relation to illustrate my question:
Person( name, street, city, zipcode )
name -> street , city , zipcode
street + city -> zipcode
So if we know the name, we also know where the person lives. But zipcode is also (transient) dependent on street + city. Thus, this relation breaks 3NF and should be split up into two tables to conform.
But in this case, we are not interested in zipcodes as a separate entity. It is part of the address, and just happens to be a transient dependent. We will never use it separately.
I understand why normalization is a good thing. But is it really necessary to always normalize (and thus make the database more complex)? If not, how do you know when you can skip it?
(if my terminology or notation is wrong, you are welcome to correct me)
Normalization is a tool for analysing dependencies and ensuring the correct implementation of data integrity rules (business rules) represented as dependencies. An underlying assumption of normalization is that you know or can determine which business rules you actually want to implement. If you are already certain you don’t want or need to enforce a given business rule then there is probably little value in considering it as a dependency when designing the database for it. Remember that the point of dependencies is that a rule is in force at all times for all possible data in the database; not just for current data or some particular subset of data.
It may be the case that the dependency {street,city} -> {zipcode} is not truly the desired business rule for the system and therefore should not be enforced. E.g. if data has to be entered without address verification software it may be impractical to ensure that zipcodes are consistent in that way. That doesn’t mean you are violating any normalization rule. It just means the functional dependency isn’t intended to hold and does not hold and therefore it isn’t a transitive dependency in any real sense.