データベース プロジェクトにSale
は、主キーと 2 つの排他的外部キーを持つテーブルがあります: Vehicle_ID
とPiece_ID
. たとえば、車両を販売する場合Vehicle_ID
、外部キーとして必要ですが、必要ありませんPiece_ID
。に NULL を入れることはPiece_ID
できますか? 外部キーを null にすることはできますか? または、この仕事を行う方法はありますか?
ありがとう。
データベース プロジェクトにSale
は、主キーと 2 つの排他的外部キーを持つテーブルがあります: Vehicle_ID
とPiece_ID
. たとえば、車両を販売する場合Vehicle_ID
、外部キーとして必要ですが、必要ありませんPiece_ID
。に NULL を入れることはPiece_ID
できますか? 外部キーを null にすることはできますか? または、この仕事を行う方法はありますか?
ありがとう。
主キーの列 (または列) は NOT NULL である必要があります。レコードは、NULL によって一意に識別できません。したがって、外部キーの参照先の ID 列は NOT NULL として定義する必要があります。
ただし、外部キー関係をオプションにすることは正当な設計上の決定であり、それを表す方法は、キーの参照側をオプションにすること、つまり NULL を許可することです。
データモデリングの用語では、あなたが説明したのは(排他的な)アークです。論理モデリングではアークは完全に受け入れられますが、別のテーブルとして実装することを支持する強い意見があります。あなたのシナリオでは、汎用Sale
テーブルと 2 つのサブタイプ テーブル、VehicleSale
およびPieceSale
.
個別テーブルの実装の利点は次のとおりです。
ただし、利点はすべて一方通行ではありません。a が aまたは a のSale
いずれかに適用され、両方には適用されないことを確認するのは非常に簡単ですが、 a に子レコードが必要であるというルールを適用することは、実際には非常に危険です。VehicleSale
PieceSale
Sale
したがって、優勢なアドバイスは、排他的なアークは間違っているというものであり、一般的には良いアドバイスです。しかし、一部の人が理解するほど明確ではありません。
はい、できます。FK 自体を NULL 可能にしますが、CHECK を追加して、それらの 1 つだけに非 NULL 値が含まれていることを確認します。
FK は、1..0:N の関係をモデル化する NULL 可能にすることができます。つまり、「子」行は「親」行を持つことができます(必須ではありません)。
NOT NULL 外部キーは、1:N の関係をモデル化します。つまり、すべての子には親が必要です。
FK が複合1で、そのフィールドの少なくとも 1 つが NULL 可能である場合、NULL 値と非 NULL 値の混合は特別な方法で処理されます。
ほとんどの DBMS はデフォルトで MATCH SIMPLE ( MS Accessの注目すべき例外を除く) に設定されており、ほとんどの場合、デフォルト以外はサポートされていません。
1ここにはありません - 完全を期すために言及しているだけです。
「排他的外部キー」が何を意味するかによっては、乗り物とピースをより大きなスーパークラスの 2 つのサブクラスと考えているかもしれません。これを販売可能なアイテムと呼びます。
「クラス テーブルの継承」と呼ばれる設計パターンを使用すると、スーパークラス用に 1 つ、各サブクラス テーブル用に 1 つずつ、計 3 つのテーブルが作成されます。さらに、「共有主キー」と呼ばれる設計を使用すると、3 つのテーブルすべてに同じ主キーを使用できます。
これにより、Sale テーブルは、Saleable_Item テーブルを参照する単一の外部キー、Saleable_Item_Id を持つことができ、場合によっては Vehicle または Piece テーブルも参照できます。これは、既存の設計よりもうまくいく可能性があります。
詳細については、Google の「クラス テーブルの継承」と「共有主キー」を参照してください。
null の外部キーがある場合、Oracle は文句を言うべきではありません。
いくつかのエラーに遭遇しましたか?