子テーブル（A.K.A. 弱実体 ）は、主キー属性が依存するテーブルです。 別のテーブルでは、したがって子テーブルが識別されます または部分的に識別 テーブルの行によって、それは（親）に依存します。子テーブルの行は、親テーブルに対応する行がないと存在できません。
説明のために、私たち全員が精通している単純で完全に関連性のある例を見てみましょう。家族の文脈での親と子 。このようなテーブルとの関係を次のようにモデル化できます：
上記のモデルでは、 Parentsの各行 テーブルは一意に識別されます SSNによる 。 SSN は各親に固有の一意の属性であり、IDを定義するために別のテーブルに依存しないため、スタンドアロンまたは「強力な」エンティティです。
ただし、子供は必須 存在するための親（ Parent_SSN 必須 既存のSSNへの参照 Parents テーブル）。
複合主キー（ Parent_SSN、Name ） Children テーブル。これは、子供が一意に識別されることを意味します 組み合わせ Parent_SSNの および 名前 。 Nameのみに基づいて個々の子をクエリすることはできません 複数の親が同じ名前の子を持つ可能性があるため、フィールド。同様に、 Parent_SSNのみに基づいて個々の子をクエリすることはできません。 1人の親に多くの子供がいる可能性があるためです。それを考慮に入れると、子供は親によって部分的に識別されるため、識別 関係。
しかし、子供もSSNによって一意に識別できませんか？なぜそうなのか、確かに。先に進んで、それを含むようにモデルを調整しましょう：
このバージョンのモデルでは、 SSNが導入されていることに注意してください。 Childrenのフィールド 。 独自のアイデンティティ 子の数は、独自の固有の固有の SSNによって定義されるようになりました。 。彼らのアイデンティティは依存しなくなりました Parents テーブル。 Parent_SSN フィールドは引き続きSSNを参照します Parents テーブル、一意のIDには含まれていません したがって、親は非識別を持っています 子との関係、および両方のテーブルが「強力な」スタンドアロンエンティティと見なされるようになりました。
余談ですが、このバージョンのモデルには、最初のバージョンに比べていくつかの利点があります。
- 1人の親に同じ名前の子が2人以上いる可能性がありますが、エンティティの整合性 以前のモデルの制約では、これは許可されませんでした。
-
Parent_SSNを許可できますNULLを含むフィールド あなたが子供に関するデータを持っているが、彼/彼女の親が誰であるかわからないという出来事を説明するため。
上記の両方のモデルで、 Parents tableは、 Childrenの親テーブルと見なされます テーブル。ただし、非識別 2番目のモデルのParentsのような関係 外部キーParent_SSNのコンテキストでの親テーブルのみです Parent_SSN 参照/依存 SSNで Parents テーブルですが、しません 子供の実際のアイデンティティを定義することに何らかの役割を果たします。
どのテーブルが親/子テーブルであるかを決定するときにコンテキストが重要である理由を説明するために、循環依存関係を含む次の例を検討してください。
この例では、従業員と部門は独自の属性によって一意に識別され、他のテーブルからIDの一部を取得することはありません。
ここでは、2つの非識別関係があります。従業員が部門で働いています（ DeptNo Employeeで テーブル）、部門は従業員によって管理されます（ ManagerSSN Departmentで テーブル）。親テーブルはどれですか？ ...子テーブル？
それは文脈に依存します—あなたはどの外部キー関係について話しているのですか？ Departmentテーブルは、 DepartmentNoのコンテキストでは親テーブルと見なされます。 Employeeで DeptNoのためのテーブル 参照/依存 Department テーブル。
ただし、Employeeテーブルは、 ManagerSSNのコンテキストでは親テーブルと見なされます。 Departmentで ManagerSSNのためのテーブル 参照/依存 従業員 テーブル。