非正規化を使用するとデータの整合性が実現できないのはなぜですか？
このチュートリアル は次のように述べています。
非正規化の支持者にとっての考え方は次のとおりです。正規化は、より高い正規形に進むにつれてより多くのテーブルを作成しますが、より多くのテーブルは、データが取得されるときに行われる結合がより多くなることを意味し、クエリの速度が低下します。そのため、特定のクエリのパフォーマンスを向上させるために、データ整合性の利点を上書きして、データ構造をより低い通常の形式に戻すことができます。
非正規化を使用するとデータの整合性が実現できないのはなぜですか？つまり、DBMSは、データの一部が更新されたときに、そのデータのすべての冗長コピーが自動的に更新されることを確認しないのですか？
たとえばOracleでは、非正規化はマテリアライズドビューを使用して実装され、元のテーブルが変更されると、マテリアライズドビューのデータが自動的に変更されます（データが自動的に変更されないように選択することもできます）。また、マテリアライズドビューを使用せず（DBMSでサポートされていない場合など）、非正規化を手動で実装した場合でも、トリガーを自分で作成してデータの整合性を保つことができます（非正規化を使用しても、必ずしもデータの整合性が保たれるとは限りません不可能である）。
データの整合性は、正規化されたデータベースと非正規化されたデータベースの両方で可能です。 2つのケースの違いは、アプリケーションプログラムが不良データをデータベースに書き込む方法の数です。
悪いデータの単純なケースを見てみましょう。データベースでは、ID 123の従業員の姓が「Brown」であると記載されています。しかし、現実の世界では、従業員123の姓は「Browne」です。これは、どのように見ても悪いデータです。しかし、もう少し深く行きましょう。
1つのデータベース、つまり正規化されたデータベースでは、姓が正確に1か所のEmployeesテーブルに格納されます。それは正しいか間違っています。そして、それが間違っている場合、データベース内のデータを修正する正しい答えを知っている人次第です。これはデータ管理の一部ですが、自動化で作業する私たちにとってはそれほどエキサイティングな部分ではありません。
別のデータベース（非正規化データベース）では、従業員123の姓が、従業員テーブルと連絡先テーブルの2つのテーブルに格納されています。連絡先の表は、電話番号と住所に関するものです。正規化されたデータベースには、連絡先テーブルはありません。代わりにビューです。今、より多くの可能性があります。姓は両方の場所で正しい場合もあれば、両方の場所で間違っている場合もあります。しかし、別の故障モードがあります。ある場所では正しいかもしれないが、別の場所では間違っているかもしれない。現在、データベースは間違っているだけでなく、自己矛盾しています。姓は一度しか保存されないため、これは正規化されたデータベースではまったく不可能です。
これは、いわゆる有害な冗長性の例です。第2正規形から第5正規形は、1つのファクトを1か所に格納するルールを課すことにより、有害な冗長性のケースを排除することを目的としています。これはデータの整合性を保証するものではありませんが、少なくともデータの不整合を未然に防ぎます。データを正しく管理するにはデータを管理する必要がありますが、DBMSはデータを正しく管理するのに役立ちます。
パフォーマンスはまったく別の話です。特定の種類のトラフィックでは、データベースの1つが他のデータベースよりも優れている場合があります。データベースの1つは更新のパフォーマンスが高いが、もう1つはクエリのパフォーマンスが高い可能性もあります。ただし、優れたパフォーマンスと間違った答えは、破滅的な場合もあれば、許容できる場合もあります。
私が示した例では、たとえ面倒でも、間違ったデータの検出はかなり簡単です。現実の世界では、DBMSからできる限りの支援を得なければ、誤ったデータ検出がほとんど不可能である例があります。この点で正規化が役立ちます。
さて、すべてのアプリケーションコードが常に正しいことを実行するようにしてください。そもそも、ミッションの範囲が拡大するにつれて、アプリケーションコードの量は劇的に増加します。 2番目に、おそらくDBAによる対話型SQLの使用により、データエラーが侵入する可能性があります。防御的なアプリケーションコードを書くことは良いことですが、何らかの理由で、うまくいかない場合があります。
申し訳ありませんが、これは長すぎるのですが、ここで何が起こっているのかを説明する必要がありました。データ管理は終わりのない戦いです。間違ったデータを見つけてクリーンアップすることは、その戦いのほんの一部です。それは汚い仕事ですが、誰かがやらなければなりません。正規化と組み合わせた優れたDBMSが役立ちます。
リレーショナルシステムでは、宣言的なデータ整合性にはいくつかの側面があります。
1つの側面はNULL可能性です。 nullでない列を持つ正規化されたテーブルがあるとします。そのテーブルは、一致しない行がある外部結合の右側です。現在、非正規化された結果は、一部の行のnullでない列に対してnullを示す必要があります。
宣言された一意性が影響を受ける可能性があります。正規化されたテーブルには、一意の制約がある場合があります。そのテーブルが1対多または多対多の結合の「多」側にある場合、一意性は保証されなくなります。
これは外部キーに影響を及ぼします。 documentation が言うように
参照される列は、PRIMARY KEYまたはUNIQUEインデックスである必要があります。
非正規化が参照された列が一意でないことを意味する場合、外部キーは定義できません。
あなたがコメントするように、このすべてのチェックをトリガーまたはアプリケーションの他の層に置くことを止めるものは何もありません。ただし、メンテナンスのオーバーヘッドになります。宣言的な参照整合性の喜びは、単一の単純なステートメントで、そのソースや履歴に関係なく、すべてのデータが信頼できることを保証できることです。