参照整合性制約は、データの冗長性の問題に対処するのに役立ちますか？
1472 次
3 に答える
3
参照整合性制約は、「一般的なデータベース制約」のサブセットにすぎません。
正規化とデータベースの制約は、明確ですが絡み合った概念です。
テーブルCUSTOMERORDER（custID、custName、orderID）があり、「＃custID＃で識別され、＃custName＃という名前の顧客が＃orderID＃で識別される注文を出した」とします。
おそらく適用されるFDcustID->custNameのため、このテーブルが3NFにある可能性は低いです。ただし、それでもこの1つのテーブルの設計を維持するとします。次に、データの一貫性を確保するために何をする必要がありますか？上記のFDを実施する必要があります。同じ顧客が2回目の注文を行った場合、2つの行のcustNameは同じになることを確認する必要があります。（1、Smith、2）や（1、Jones、7）などの行が両方のテーブルに表示されることを禁止する必要があります。これは、設計をすべての記載されたビジネスルールに一致させるために適用される一種のデータベース制約です。
ただし、ここでは「参照」制約がないことに注意してください。明らかに、参照する2番目のテーブルがないためです。
また、この1つのテーブルの設計では、すぐには明らかにならない可能性のある他の制約が「自動的に」適用されることにも注意してください。たとえば、1つのテーブルの設計では、対応するcustIDとcustNameが存在しないとorderIDが存在することはできません。（nullについて考えている場合は、やめてください。関係理論では、「null」などは存在しません。）orderIDが登録されている場合は、対応するcustIDPLUScustNameも存在する必要があるという「ルール」は、1つのテーブルであるという設計によって「暗黙的に」強制されます。
しかし今では、従来の正規化理論で規定されているように、設計を2つのテーブルに分解します。
CUSTOMER（custID、custName）KEY custID; ORDER（custID、orderID）KEY custID、orderID;
実施する必要のあるビジネスルールは同じです。つまり、（a）同じcustIDを持つが異なる名前（FD）を持つ2人の顧客は存在できず、（b）対応するcustIDがないと注文はできません。その注文のプラスcustName 。
2つのテーブルの設計がこれらのビジネスルールをどのように処理するかを見てみましょう。（a）custIDをCUSTOMERのキーとして宣言することにより、明らかに強制されます。（b）に関しては、custIDも記録せずにorderIDをORDERに記録することは不可能であることは明らかです。しかし、すべてのORDER行に対応するcustNameも存在することを保証するにはそれで十分ですか？明らかにありません。そのため、ORDERとCUSTOMERの間に明らかな参照整合性ルールを導入する必要があります。
したがって、RI制約は、テーブルを分解し、設計全体にRI制約を導入することで、データの整合性の特定の保証を維持しながら、特定の種類の冗長性を排除できるという意味で、実際に「データの冗長性の問題に対処するのに役立ちます」 。設計にRI制約を導入する可能性がなければ、データの一貫性を犠牲にして冗長性を排除するだけです。
于 2011-04-13T11:47:58.497 に答える
0
参照整合性は、参照整合性のみを保証します。
冗長性を防ぐのは、データベースのレイアウト方法です（Odedが指摘した正規化を参照）。
于 2011-04-13T10:26:36.090 に答える