mysql - 識別関係または非識別関係の子テーブルはどれですか?

Question

テーブル間の識別関係と非識別関係のコンテキストでは、MySQL のドキュメントでは、テーブルを親テーブルと子テーブルと呼んでいます。

どのテーブルが親テーブルで、どのテーブルが子テーブルであるかをどのように判断しますか?

Answer 1

子テーブル (AKA弱いエンティティ) は、主キー属性が別のテーブルに依存するテーブルです。したがって、子テーブルは、依存するテーブル (親) の行によって識別または部分的に識別されます。子テーブルの行は、親テーブルに対応する行がなければ存在できません。

説明するために、私たち全員がよく知っている単純で完全に関連性のある例を見てみましょう:家族のコンテキストでの親と子。この関係を次のようにテーブルでモデル化できます。

Parents上記のモデルでは、テーブルの各行はによって一意に識別されますSSN。はSSN、各親に固有の一意の属性です。その ID を定義するために別のテーブルに依存しないため、スタンドアロンまたは「強力な」エンティティです。

ただし、子が存在するためには親が必要です(テーブル内の既存のものを参照するParent_SSN 必要があります)。SSNParents

表の複合主キー ( Parent_SSN, Name) に注目してChildrenください。これは、子がとの組み合わせによって一意に識別されることを意味します。複数の親が同じ名前の子を持つ可能性があるため、フィールドのみに基づいて個々の子を照会することはできません。同様に、 1 つの親が多くの子を持つ場合があるため、フィールドのみに基づいて個々の子を照会することはできません。それを考慮すると、子供は親によって部分的に識別され、したがって関係を識別します。Parent_SSN NameNameParent_SSN

しかし、子供も SSN で一意に識別できないのでしょうか? はい、もちろんです。モデルを調整して、以下を含めましょう。

モデルのこのバージョンでは、 のSSNフィールドが導入されていることに注意してChildrenください。子の一意のアイデンティティは、独自の固有および一意の によって定義されるようになりましたSSN。それらの IDはテーブルに依存しなくなりました。フィールドは引き続きテーブルのを参照Parentsしますが、子の一意の IDには関与しないため、親は子に対して非識別関係を持ち、両方のテーブルを「強力な」スタンドアロン エンティティと見なすことができます。Parent_SSNSSNParents

余談ですが、このバージョンのモデルには、最初のバージョンよりもいくつかの利点があります。

• 1 つの親が同じ名前の 2 つ以上の子を持つことができるようになりましたが、以前のモデルのエンティティ整合性制約ではこれが許可されませんでした。
• 子供に関するデータはあるが、親が誰であるかがわからないというイベントを説明するために、Parent_SSNフィールドに含めることができます。NULL

上記の両方のモデルで、Parentsテーブルはテーブルの親テーブルと見なされChildrenます。ただし、2 番目のモデルのような非識別関係では、テーブル内で参照/依存するため、Parents外部キーのコンテキストでは親テーブルにすぎませんが、子の実際の ID の定義には関与しません。Parent_SSNParent_SSN SSNParents

どのテーブルが親/子テーブルであるかを決定する際にコンテキストが重要である理由を説明するために、循環依存関係を含む次の例を検討してください。

この例では、従業員と部門は独自の属性によって一意に識別され、他のテーブルから ID のどの部分も派生しません。

ここでは、2 つの非識別関係があります。従業員は部門で働いており (DeptNo表Employee内)、部門は従業員によって管理されManagerSSNています (Department表内)。親テーブルはどれですか？...子供テーブル？

それはコンテキストに依存します — どの外部キー関係について話しているのでしょうか? Department テーブルは、テーブルを参照/依存しているためDeptNo、テーブル内のコンテキストでは親テーブルと見なされます。EmployeeDeptNoDepartment

ただし、従業員テーブルは、テーブルを参照/依存しているためManagerSSN、テーブル内のコンテキストでは親テーブルと見なされます。DepartmentManagerSSNEmployee

Answer 2

リレーションシップにおけるテーブルの役割を決定する厳密な規則はありません。実際、それがリレーショナル モデルの美点であり革新的な点です。つまり、階層がありません。

通常、特定のテーブルから別のテーブルへの強い依存関係がある場合、子ロールまたは親ロールはテーブルのセマンティクスによって決定されます。例: order、order_detailsリレーションシップでは、それorderが親でorder_detailsあり子であることは明らかです。

他の場合では、関係が関係で果たす役割が明確ではありません。例:ordersとcustomers関係。orders特定のものに属するすべてを取得するクエリを実行するとcustomer、親は子である可能性がcustomersありordersます。しかし、クエリを実行して、特定の のすべての出荷情報 (customersリレーションに格納されている)を取得することもできます。この場合、このクエリではが親であり、 が子でorderあると主張するかもしれません。ordercustomers

前に述べたように、リレーショナル モデルが 70 年代後半に発明されたとき、支配的なパラダイム (階層データ モデル) の 1 つに対する主な利点の 1 つは、依存関係に関係なく関連データを検索できることでした。

Answer 3

ここで素晴らしい定義が提案されています：

識別関係とは、子テーブル内の行の存在が親テーブル内の行に依存する場合です。(...) 正式には、これを行う「正しい」方法は、外部キー[つまり、親の主キー]を子の主キーの一部にすることです。