1

1970 年に Edgar Codd によって最初に定義されたリレーショナル モデルのルールを理解しようとしています。

具体的には、参照整合性が彼のリレーショナル モデルの一部であるかどうかに興味があります。次の例でデモンストレーションを試みます（この質問をきれいにするためだけに）：

お客様

+------+------------
| Name | Address
|------+------------
| John | ....
| Mike | ....
| Kate | ....
+------+------------

請求書

+------+------------
|  ID  | Customer
|------+------------
|   1  | John
|   2  | John
|   3  | Mary
+------+------------

さて、ご覧のとおり、顧客 (外部キー) がMaryである請求書が 1 つあります。これは彼のリレーショナル モデルに違反しますか? エドガー・コッドはこれを見て、「なんてこった」と言うでしょうか? それとも、彼は言うでしょうか、それはまったく問題ありません...

これは理論的な問題です。

4

6 に答える 6

4

Customers テーブルに Mary という名前の顧客が存在しない場合、テーブル間に参照整合性はありません。具体的には、外部キーは存在しない主キーを参照します。

これはリレーショナル モデルを壊しますか? いいえ。これはリレーショナル モデルで定義されており (つまり、参照整合性の欠如)、基になるデータに問題があることを示しています。

Edgar Codd 著「A Relational Model of Data for Large Shared Data Banks」より (Communications of the ACM、Volume 13、Number 6、1970 年 6 月):

ユーザーが他の要素を P に挿入することを意図していた可能性があります。その要素を挿入すると、一貫した状態が一貫した状態に変換されます。ポイントは、システムは通常、その環境 (おそらく不整合を作成したユーザー) に問い合わせることなしに、この問題を解決する方法がないということです。

そのため、参照整合性の問題が発生し、ユーザーまたはシステムがプログラムによる方法で解決する必要があると想定されます。

于 2009-03-16T16:23:29.210 に答える
3

言語が関係的に完全であると見なされる (Codd によって造られたフレーズ) には、関係代数として知られる関係演算子のセットをサポートする必要があります。真のリレーショナル代数は 1 つも存在しないことに注意してください: コッドは最初のものを提案しましたが、他の代数はその後洗練され、コッド (たとえば、第三宣言) に基づいて構築されました。

参照整合性は関係演算子ではないため、言語の関係完全性の要件ではありません。参照整合性制約がDBMSの有用な機能または必要な機能であるかどうかは、別の問題です。

于 2011-03-23T11:36:09.640 に答える
2

リレーショナルモデルでは、すべてのリレーショナルデータベースに適用するために参照整合性機能は必要ありません。このような制約が適切でない、または望ましくない場合、これはばかげています。名前、住所、会員番号で構成されるクラブ会員リストを考えてみてください。ここでは必ずしもRI制約が使用されるとは限りませんが、データがリレーションの形式で格納されている場合は、リレーショナルデータベースのままです。

Coddの13のルールでさえ、RDBMSがRI制約を作成する機能をサポートする必要はありません。ほとんどのRDBMSが外部キーを持っていると予想されるほど、外部キーが非常に便利であるというだけです。

于 2011-03-16T15:05:09.703 に答える
2

以下は、参照整合性がリレーショナル モデルに含まれていることを明確に述べているものとして読みました。

すべてのリレーショナル データベースには、次の 2 つの整合性規則が適用されます。

1 エンティティの完全性:
基本関係の主キーのコンポーネントである属性では、どちらのタイプのマークも許可されません

2 参照整合性:
D を、1 つ以上の単一属性の主キーが値を引き出すドメインとします。K をドメイン D から値を引き出す外部キーとします。K で発生するすべてのマークされていない値は、何らかの基本関係の主キーの値としてデータベースにも存在する必要があります。

「リレーショナル データベースでの欠落情報 (適用可能および適用不可)」、EF Codd、ACM SIGMOD Record、vol. 15、いいえ。4, pp. 53-78, 1986.

「いずれかのタイプのマーク」によって、彼は未知の値を参照しており、今日では NULL を使用しています。この論文では、2 つの異なるタイプの未知の値が提案されています。

「マークなし」とは、NULL ではないことを意味します。

@dportas からの再コメント: 実際、引数を作成するために参照された関係を空にする必要さえありません。いくつかの行を含めることができますが、K の A マークは、その参照関係に存在する値と等しいとは言えないため、仮想欠損値が制約を満たすとは言えません。したがって、Aマークを許可することは、値が提供されると制約を満たすという信仰の行為にならなければなりません。そうしないと、行が挿入された瞬間から無効になり、無意味な遡及的制約違反。

于 2009-03-16T17:33:29.337 に答える
1

最初に尋ねるのは、RM の RI 部分です。

参照整合性が彼のリレーショナル モデルの一部であるかどうか

はい。Codd の古典「Is your DBMS really relational?」より コンピューターワールド、1985 年 10 月 14 日:

ただし、リレーショナル モデルには 3 つの主要な部分 (構造部分、操作部分、整合性部分) が含まれていることを覚えておくことは非常に重要です。この事実は、都合よく忘れられがちです。

ルール 10: 特定のリレーショナル データベースに固有の整合性制約は、アプリケーション プログラムではなく、リレーショナル データ サブ言語で定義でき、カタログに格納できる必要があります。

しかし、別のあいまいな質問で言い換えると、次のようになります。

顧客 (外部キー) が Mary である 1 つの請求書があります。これは彼のリレーショナル モデルに違反しますか?

つまり、RM は、宣言された FK に違反することを許可しますか、つまり、DBMS によって停止されませんか?

いいえ。それは、FK 制約を宣言できるが、それを強制しない DBMS です。このような DBMS は、その点で非リレーショナルです。

つまり: RM では、Invoices Customer が Customers Name にも表示される必要があるというビジネス ルール (つまり、すべての有効なデータベースの状態がそのようなものであること、つまり、Invoices Customer から Customers Name への FK 制約があること) が許可されていませんか? DBMS に対して宣言されていますか (たとえば、FK 宣言を介して)?

はい。しかし、いくつかの無効な状態が許容されるため、これは悪い設計です。

于 2015-07-02T23:32:45.927 に答える
0

これで良いかどうかはデザイン次第だと思います。

請求書には、請求書が作成または送信された時点のデータが含まれている必要があります。そのため、特に自然キーを使用している場合は、顧客データに関連するデータが必要であるが、直接外部キーではない必要があるように見えます。

たとえば、Mary Jones が何かを注文し、2010 年 5 月 31 日に請求されたとします。2010 年 9 月 12 日、彼女は名前を Mary Jones-Smith に変更し、夫の住所に引っ越しました。請求書は当時の写真であり、Mary Jones という名前と、送付先の元の住所を保持する必要があります。現在の顧客と彼女の情報へのリンクも保持できることが最善です (これが、名前が変更されたときに顧客テーブルに顧客 ID があり、incvoice テーブルに Customerid の FK がある理由です)。しかし、Mary Jones が顧客テーブルに存在しなくなったときに Mary Jones を格納することは問題ないだけでなく、実際に何が起こったかを追跡する必要があります。

製品と価格と請求書についても同じことが言えます。請求書に現在の価格を反映させるのではなく、現在の価格とは直接関係なくても、請求時のプロセスを反映させたいと考えています。この場合、Product テーブルは、真の親子関係というよりもルックアップ テーブルのようなものになる可能性があります。製品のすべての詳細を請求書詳細テーブルに保存する場合、製品への外部キーは必要ありません。注文時にアクティブな製品を検索するためだけに必要です。実際、ベンダーがモデル番号を変更したり、製品を完全に削除したりした場合、過去の請求書のモデル番号が製品テーブルに含まれていない可能性があります。しかし、過去に購入した製品に関するデータを失いたくはありません。

一方、リレーションシップでデータが現在の値と一貫性を保つ必要がある場合は、正式な外部キーが最適な方法です。

于 2011-09-13T20:34:22.137 に答える