あなたが言うように、
アクションとルールの両方に groupId FK を設定することもできます…</p>
これは、グループとルール、およびグループとアクションが「1 対多」に関連付けられていることを意味します。つまり、1 つのグループには複数のルール/アクションを含めることができ、1 つのルール/アクションは 1 つのグループにのみ属することができます。その場合は、groupId
それらの関係に列を使用してください。
関連するルールとアクションが同じグループに属している必要があるという制限付きで、ルールとアクションの間に多対多の関係を確立するには、いくつかの冗長性を導入する必要があります。具体的には、グループに関する情報を複製します。 2つのエンティティが属しています。
それを考慮して、3 番目のテーブル をRulesActions
次のように定義できます。
RuleID
ActionID
GroupID
FOREIGN KEY (RuleID, GroupID)
FOREIGN KEY (ActionID, GroupID)
GroupID
列は冗長ビットです。明らかに、のグループRuleID
またはActionID
のグループのいずれかは、対応するテーブルを検索することによって決定できます。ただし、ご覧のとおり、単一のGroupID
列が両方のグループ参照として使用されているため、2 つのアイテムが同じグループを持つようになっています。そして、グループ ID が実際にルールとアクションの両方が属するものであることを確認するために (任意のものだけでなく)、列は両方の外部キーに含まれます。つまり、RulesActions
テーブルは のみではなく によって参照Rules
され、同じのために。(RuleID, GroupID)
RuleID
Actions
もちろん、このような FK 定義が与えられた場合、ターゲット テーブル内の対応する主キーまたは一意制約を同じ方法で定義する必要があります。私が使用している製品であるSQL Serverでは、外部キーは、主キーとして定義されているか、一意の制約が適用されている列を参照できるため、主キーまたは一意の制約と言います。したがって、SQL Server では、テーブルRules
とActions
テーブルを次のように定義できます。
Rules
:
RuleID PRIMARY KEY
GroupID FOREIGN KEY
UNIQUE (RuleID, GroupID)
Actions
:
ActionID PRIMARY KEY
GroupID FOREIGN KEY
UNIQUE (RuleID, GroupID)
RulesActions
これにより、以前に指定したスキーマを持つことができます。他の多くの製品がそれを許可するかどうかはわかりません。そうでない場合は、代わりに次のアプローチを試すことができます。
Rules
:
RuleID UNIQUE
GroupID FOREIGN KEY
PRIMARY KEY (RuleID, GroupID)
Actions
:
ActionID UNIQUE
GroupID FOREIGN KEY
PRIMARY KEY (RuleID, GroupID)
このように、UNIQUE 制約は (エンティティ) ID 列のみに適用され、ID の一意性が確保され、外部キーのターゲット列セットがRulesActions
主キーとして定義されるため、共通の FK <-> PK が得られます。関係。
多対多のグループ/ルールおよび/またはグループ/アクションの関係が必要であることが判明した場合、アイデア自体はほとんど変わらないことに注意してください。多対多の関係の場合、 がEntityID, GroupID
主キーになるマッピング テーブルを導入する必要があり、対応する外部キーは、メイン エンティティのテーブルではなくそのテーブルを参照する必要があります。