1

ER データ モデルで、x が「多数」ではなく固定数である 1:x 関係をモデル化する方法を知りたいです。簡略化された理論上の例:

エンティティ ハウス ルーム

HOUSE と ROOM の間には 1:n の関係があります。

別の不自然で、より複雑で、わずかに異なる例:

エンティティ 家 部屋 親 子供

関係 HOUSE 1:n ROOM PARENT 1:n CHILD HOUSE 1:1 PARENT - 親は正確に 1 つの家を所有する必要があり、家は正確に 1 つの親によって所有される必要があります。

これに次をどのように追加しますか: 家の部屋の数は、家の所有者が持つ子供の数と同じでなければなりませんか?

ありがとう。

4

2 に答える 2

1

データベースでは、制約などのルールを実装できます。

SQL では、ルールの CHECK 制約は次のようになります。

CHECK NOT EXISTS
(
  SELECT MAX(house.owner) parent, COUNT(*) cnt
  FROM house, room
  WHERE house.house_id = room.house_id
  GROUP BY house_id
  EXCEPT
  SELECT parent, COUNT(*) cnt
  FROM child
  GROUP BY parent
)

これは ISO 標準 SQL ですが、すべての SQL DBMS がサブクエリを制約に入れる機能をサポートしているわけではありません。このような制約は、通常、テーブルの 1 つだけに適用する必要があります。SQL DBMS では通常、一度に 1 つのテーブルへの挿入しか許可されないため、家のテーブルと子のテーブルの両方に同様の制約を適用すると、最初の挿入によって制約が破られるため、新しい家や子供を追加することができなくなります。可能な回避策は、制約を一時的に無効にすることです。一部の DBMS は、この目的のために「遅延」(一時的に無効化) 制約の概念をサポートしています。

ER モデリングでは、一般に制約の標準表記法はありません。図で表すことができるのは、特定の非常に単純なルールだけです。より複雑なルールは、テキスト注釈として追加されるか、ER 図から完全に除外されることがあります。

そのようなルールを正式にモデル化できることが重要な場合は、ER 図に頼らないでください。オブジェクト ロール モデリング、SBVR、RuleML などのツールを使用して、ルール セットを記録します。

于 2013-10-29T18:15:22.810 に答える
0

お気づきかもしれませんが、簡単に説明すると、リレーショナル データベースの用語では、通常、関係は 1:1、1:M、または M:M と表現されます。それらがどのように機能するかには、根本的な違いがあります。1:1 の関係では、外部キーを 1 つのテーブルに別のテーブルにポストする必要があります。それはどちらのテーブルにもある可能性があります。1:M では、その 1 つを指す「多」テーブルに外部キーをポストする必要があります。AM:M では、新しいテーブルを作成する必要があります。リレーションシップ テーブルの各レコードには、各「メイン」テーブルへのポインターが 1 つずつあります。

たとえば、私たちの集合住宅にはスイートごとにちょうど 4 部屋があるとしたら、それは一般的な 1:M の関係ではなく、より具体的な 1:4 の関係であると言えます。ただし、データを RDB に格納する方法に関しては、1:M として格納します。各「ルーム レコード」には、「スイート レコード」へのポインタがあります。DB 構造に関する限り、1:M のままです。DB トリガーまたはコードに制約を追加して、数値が常に正確に 4 でなければならないことを強制できますが、これは DB 構造には影響しません。

このような制約が重要な ERD では、一部の DB 設計者は、DB エンティティに付けられた「多」記号の隣に数字を書きます。ちょうど 4 でなければならない場合は、「4」と書きます。

正確な数または最小値を強制するのは難しい場合があることに注意してください。実生活では、誰もがちょうど2人の親を持っていると言うのは1つのことです. これをデータベース設計の要件にするのは別の話です。つまり、両方の両親を同時に追加しない限り、「人物」レコードを追加することはできません。したがって、データ入力画面には、本人とその両親に関するすべてのデータのフィールドが必要です。または、親データの入力に取りかかるまで、何らかのダミー レコードを追加する必要があります。そして、この例では、両親が人物と同じレコード タイプである場合 (たとえば家系図データベースを作成している場合)、両親の両親を追加せずに両親を追加することはできず、両親の両親の両親を追加することはできません。 、そして...どこで止まりますか？私たちのことを言うための何らかの規定が必要です。

場合によっては、関連するレコードが特定の数だけでなく、それらが何らかの形で異なる場合、それぞれに個別のポインターを作成することがあります。たとえば、各人には 2 人の親がいる、つまり M=2 の 1:M の関係であると言う代わりに、各人には母親と父親がいる、つまり 2 つの 1:1 の関係であると言うことができます。個人的には、通常はクエリとインデックス作成がより困難になるため、これを行うことはめったにありません。parent_id を調べて両方の親を取得する代わりに、mother_id と Father_id の両方を調べる必要があります。一方にインデックスを付けたい場合は、おそらくもう一方にインデックスを付けたいと思うでしょう。数が 2 または 3 よりも多く、クエリで多くのポインター フィールドを調べる必要がある場合、たとえば、ポインター 1、2、3、5、および 6 をチェックするのに 4 を含めるのを忘れるなど、プログラマーがあなたを見逃すのは簡単です。 .

ところで、「部屋の数は所有者の子供の数と同じでなければならない」などの制約は注意が必要です。頭のてっぺんから作った例だと思いますが、特定の数値を設定するときに陥りやすい種類の罠です。あなたの家族では、それぞれの子供が自分の寝室を持っているかもしれませんが、多くの家族では、子供たちは部屋を共有しなければなりません. または逆に、多くの家族がゲスト用に予備の寝室を持っています。何年も前に医療保険のシステムに取り組んだことを思い出します。そこでは、家族ごとに子供を 8 人までという制限を設けていました。しかし、もちろん、8 人以上の子供を持つ家族もいます。

于 2016-05-02T14:58:45.897 に答える