0

参照整合性を使用していて、2 つのエンティティ (A と B) の間に関係があり、両側の最小カーディナリティが 1 であるとします。つまり、テーブル A がいっぱいになる前に、テーブル B にはテーブル A ができるレコードが必要です。にリンクされます。ただし、最小カーディナリティは両側で 1 であるため、逆の場合も同じことが言えます。つまり、レコードをテーブルに挿入する前に、テーブル B のレコードをリンクできるテーブル A のレコードが必要です。 B.

私が正しく理解していれば、参照整合性により、両方のシナリオで、レコードを他のテーブルの別のレコードにリンクする必要があるため、どちらのテーブルにもレコードを入力できないため、問題があるようです...

誰かがこのシナリオで何が起こるか説明できますか?

これと同じ質問を先生に尋ねたところ、最小カーディナリティ 1..1 の関係 (この表記は正しいですか?) は確かに可能であるとのことですが、どのテーブルを最初に入力する必要があるかを説明することはできませんでした。

申し訳ありませんが、具体的な例がありません。これについてランダムに考えていました...回答で実際の例を使用して詳しく説明できれば、それは素晴らしいことです。

4

2 に答える 2

1

あなたのケースは正しくないようです。

1 対 1 の関係では、1 つのテーブルが親で、もう 1 つは子である必要があります。

1 つのユーザー テーブルと 1 つのユーザー プロファイル テーブルがあるとします。この場合、user_profile は user に属します。ユーザーが作成されるまで、user_profile を作成することはできません。つまり、User テーブルが親で、user_profile が子です。所属先には、親テーブルの ID が含まれます。

user と user_profile のシナリオでは、user_profile テーブルに user_id が保持されます。最初にユーザー オブジェクトを作成してから、この ID を user_profile に渡し、user_profile を作成する必要があります。

したがって、シナリオでは、どちらを親にし、どちらを子にするかを見つける必要があります。そうでない場合は、常に鶏の卵を使用します。

于 2014-09-15T15:18:09.943 に答える
0

この質問では、ユーザーの観点から、DBMS が一度に操作できるテーブルは 1 つだけであると想定していますが、実際にはそうではありません。

概念レベルでは、カーディナリティが 1 対 1 の 2 つのエンティティを持つことは確かに可能です。

リレーショナル データ モデルの論理レベルでは、これは、あるリレーションの候補キーの値のセットが、別のリレーションの候補キーの値のセットと正確に等しくなければならないことを意味します。

ほとんどの DBMS の物理レベルでは、この整合性制約は外部キー制約として実装されます。

実際、ほとんどの DBMS では、一度に操作できるテーブルは 1 つだけです。

この場合、すべてのステートメントの後に制約がチェックされる場合、1 つのテーブルを「親」として、もう 1 つを「子」として選択する必要があります。ステートメントの後で外部キー制約に違反しないように、テーブルの操作は正しい順序で行う必要があります。トリガーなどで追加の検証が必要になる場合があります。これにより、親ごとに子が 1 つだけ存在するようになります。

ただし、変更がコミットされるまでチェックされないように制約のチェックを延期できる場合は、2 つの外部キー制約を指定できます。最初のテーブルと 2 番目のテーブルの間で 1 つ、2 番目のテーブルと最初のテーブルの間でその逆。テーブルの操作は、変更がコミットされるまでにどちらの制約にも違反していない限り、任意の順序で実行できます。ただし、ユーザーの観点から見ると、複数ステートメントのトランザクションの途中で、制約に違反しています。

複数の割り当ての概念もあります。これは、複数のテーブルの操作が単一のアトミック操作と見なされる場合です。この場合、ステートメントの最後で制約に違反しないように、1 つのステートメントで両方のテーブルを操作する必要があります。この場合、ユーザーの観点からは、制約に違反することはなく、決して違反することはありません。これらの複数の割り当てをサポートする非商用の DBMS があります。

複数の割り当ての概念を導入した Chris Date と Hugh Darwen の Third Manifesto を読みたいと思うかもしれません。

于 2014-09-26T22:32:09.530 に答える