web-dev-qa-db-ja.com

弱いエンティティを弱いエンティティにどのように関連付けることができますか?

以下のエンティティ関係図(ERD)を見るとわかるように、ATTENDANCEエンティティはTRANSCRIPTエンティティに関連付けられています。しかし、TRANSCRIPTに主キーがない場合、ATTENDANCEのエンティティはどのように識別できますか? ERDは間違っていますか?

ER diagram

3
MrRobot9

Coddの定義によれば、すべてのテーブルには主キーが必要です。キーは、単一の列で構成される単純なものでも、複数の列で構成される複合のものでもかまいません。これらの列が外部キーであることは完全に許容されます。 FKがPKの一部である場合、弱いエンティティと呼ばれることがあります。エンティティタイプはそれ自体では成り立たないためです。理解するには、別のタイプが必要です。

与えられた図の場合、有効な実装は次のようになります

テーブル:大学
列:名前
外部キー:なし
主キー:名前

テーブル:出席
列:CollegeName、StartDate、EndDate
ForeignKeys:CollegeNameはCollege(Name)を参照します
PrimaryKey:CollegeName、StartDate

表:筆記録
列:CollegeName、StartDate、CourseName、Semesterなど。
ForeignKeys:(CollegeName、StartDate)はAttendance(CollegeName、Startdate)を参照します
PrimaryKey:CollegeName、StartDate、CourseName

これらの主キーは、分析と正規化によって「自然に」エンティティタイプに配置される属性で構成されます。したがって、「ナチュラルキー」と呼ばれます。ご覧のとおり、自然なキーはすぐに扱いにくくなる可能性があります。そのため、多くの場合、一意の整数に置き換えられます。この整数は、自然キーを表すため、代理キーと呼ばれます。

通常、データベース設計にサロゲートキーを挿入すると、弱いエンティティが強いエンティティに変換されます。つまり、サロゲートが自然キー全体を置き換えます。これは確かにコーディングが最も簡単で、SQL IDENTITY機能でサポートされています。ただし、そうである必要はありません。 Attendanceにサロゲートを追加したとしましょう-それをAttendanceIdと呼びましょう。 Transcriptsを(AttendanceId、CourseName)としてモデル化することは依然として正当です。それでも「弱い」エンティティになります。

1
Michael Green