私の質問を説明するために、次の関係を検討してください。
Person( name, street, city, zipcode )
name -> street , city , zipcode
street + city -> zipcode
そのため、名前がわかれば、その人がどこに住んでいるかもわかります。ただし、郵便番号は（一時的な）通りと都市にも依存します。したがって、この関係は壊れ3NFており、準拠するために2つのテーブルに分割する必要があります。
ただし、この場合、個別のエンティティとしての郵便番号には関心がありません。これはアドレスの一部であり、たまたま一時的に依存しています。個別に使用することはありません。
正規化が良いことである理由を理解しています。しかし、常に正規化する（したがってデータベースをより複雑にする）必要があるのでしょうか。そうでない場合は、いつスキップできるかをどのようにして知ることができますか？
（私の用語や表記が間違っている場合は、私を訂正してください）
パフォーマンスに加えて、完全に正規化されないもう1つの理由は、データに特定の「あいまいさ」がある場合です。
私が理解している限り1、ZIPは街区または地域に固有である可能性があります。つまり、特に長い通りには複数のZIPが含まれる可能性があります。また、ZIPが米国のcity + streetに対応していても、他の国の郵便番号には当てはまらない可能性があります。
ただし、 ZIPが実際に都市と道路に固有であると仮定しても、人間は住所情報を自分で入力する可能性があります。つまり、誤ったZIPなどの間違いを犯す可能性があります。したがって、都市と通りの同じ組み合わせに対して2つのZIPを使用することになります。
完全に正規化されたデータベースには、それを表す方法がありません。何らかの方法でZIPの1つを選択する必要があります。すべてのZIPの完全で最新のデータベースにアクセスできない限り、この競合を解決する良い方法はありません。間違ったZIPを選択してしまうと、同じ都市と通りにいるすべての人が間違ったZIPを使用することになります。
一方、非正規化されたデータベースでは、各人が自分のZIPを保持し、後で他の人から隔離された結果に苦しむことになります。オートコンプリートの提案を実装して、「よろしいですか？」ユーザーがすでにZIPを持っている既存の都市+通りに別のZIPを入力した場合に警告しますが、確信がある場合は、ユーザーに続行させます。
1そして、私は米国に住んでいないので、私はオフになっている可能性があります。
正規化は、依存関係を分析し、依存関係として表されるデータ整合性ルール（ビジネスルール）の正しい実装を保証するためのツールです。正規化の基本的な前提は、実際に実装するビジネスルールを知っているか決定できるということです。特定のビジネスルールを適用したくない、または適用する必要がないとすでに確信している場合は、データベースを設計するときに、それを依存関係と見なすことにはほとんど価値がありません。依存関係のポイントは、データベース内のすべての可能なデータに対して常にルールが適用されていることです。現在のデータやデータの特定のサブセットだけではありません。
依存関係{street、city}-> {zipcode}がシステムにとって本当に望ましいビジネスルールではないため、強制されるべきではない場合があります。たとえば、住所確認ソフトウェアを使用せずにデータを入力する必要がある場合、郵便番号がそのように一貫していることを確認するのは実用的でない場合があります。これは、正規化ルールに違反しているという意味ではありません。これは、機能依存性が保持されることを意図しておらず、保持されないことを意味します。したがって、実際の意味では推移的な依存性ではありません。
正規化を完全に推進する価値とコストは異なります。これは主に、データをどのように処理するかによって異なります。
データを使用する方法は（少なくとも）2つあります。1つはオンライントランザクション処理（OLTP）です。もう1つは、オンライン分析処理（OLAP）です。
OLTPでは、正規化しない場合のコストが非常に高くなる可能性があります。トランザクションはより複雑で遅くなり、ボトルネックによってパフォーマンスが低下します。OLAPでは、正規化の利点は限られており、同じ作業でより多くの利点を生み出すことができる他の設計分野があります。それらの選択肢の1つは、検索できるスタースキーマ設計です。
ただし、正規化されていない、または非正規化されているという問題ではなく、正規化されたデータベースが作成されない場合でも、別の設計規律に従うことが重要です。
概説した特定のケースに戻ると、顧客のアクティビティに大きなトランザクション負荷がかかるシステムはたくさんありますが、顧客テーブルはそれらのトランザクションで読み取り専用の目的で使用されます。
3NFに準拠しないと、新しい顧客を入力する必要がある場合にのみ問題が発生します。同じ都市、通り、および郵便番号を持つ他の顧客がすでに存在する場合は、郵便番号をもう一度入力する必要があります。また、郵便局が特定の通りの郵便番号の割り当てを変更した場合、正規化されたテーブルの1行だけでなく、多くの住所を更新する必要があります。
これはそれほど高いコストではなく、起こりそうなイベントでもありません。
一方、郵便局が1つの通りを通り、住所が通りのどのブロックにあるかに応じて、その通りを2つの郵便番号に分割する可能性はどのくらいありますか。この後者のイベントが発生した場合、実際には3NFに違反する構造を使用したほうがよいでしょう。郵便局が分割について提供した情報を使用して、住所ごとに異なる郵便番号を自由に入力できます。
では、この2番目のシナリオはどのくらいありそうですか？最初のものよりも可能性が高いと思います。しかし、あなたは私の推測ではなく、あなたの推測に沿って進む必要があります。
私はアメリカ人ではないので、これを言うのは躊躇しますが、あなたが郵便番号を理解しているとは思いません。一部の個々の建物には、独自の郵便番号があります。郵便番号は州の境界を越えることができます。郵便番号は、地理的に重要な私書箱を表すことができます。
したがって、正規化の利点に関係なく、あなたの例は選ぶのに悪い例です。（通り、都市）と郵便番号の間に明確な相関関係はありません。
私がこれを間違っている可能性はありますが、英国の道路（非常に短い道路でも）には複数の郵便番号が含まれている可能性があります。
{street、city}-> {zipcode}の場合、dbmsがそれを強制できるように、その制約をdbmsに知らせる必要があります。そうしないと、すぐに次のようなデータになってしまいます。
name street city zipcode
--
Barack Obama Pennsylvania Ave Washington, DC 90210
90210は郵便番号ですが、カリフォルニア州ビバリーヒルズ用です。
これは、そのような悪いデータを本当に許容できるまれなアプリケーションです。