現実のビジネスでは、システムに完全に正規化を行った場合、かえって無駄になるということがあります。例えば、顧客が企業の場合、住所という項目に入るデータがほとんどの企業は一つ、ただしいくつかの企業は複数の住所を持つといった場合（東京、大阪の２本社制など）、繰り返しグループからといって住所テーブルを作ることはありません。
通常は、ほとんどの企業が収まるように住所１、住所２のようにあえて非正規化のままでテーブルにします。常識的に考えて、多くの人が納得できるレベルでの理由があれば、非正規形も許されるのです。ここでは簡単な例をあげましたが、実際には重要な決定になりえるような、非正規化の判断が必要な局面があるのです。
そういったレベルのトレードオフは、システムを購入するユーザ側に決定権があり、毎回異なるわけで、そのための顧客とのコミュニケーションを取れるエンジニアが重宝されるのでしょうね（いわゆる要件定義能力）。そのためには、やはり、技術をおさえるべきで、正規化などは、システム全体に影響するような重要な部分ですので、この解説でより多くの人が、理解してもらえたのならうれしく思います。
あと、情報処理試験に出る正規化は比較的単純ですが、実際のビジネスはもっと複雑です。項目数も本当にありえないと思うほどあることがほとんどです。（しかも一つ一つの項目が難しい。）そのため、データベースの正規化は、顧客業務に通じたエンジニアの仕事であり、この理論を生かすためには長年の経験、継続的な業務の学習が大切だと思います。