以下のエンティティ関係図(ERD)を見るとわかるように、ATTENDANCE
エンティティはTRANSCRIPT
エンティティに関連付けられています。しかし、TRANSCRIPT
に主キーがない場合、ATTENDANCE
のエンティティはどのように識別できますか? ERDは間違っていますか?
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)としてモデル化することは依然として正当です。それでも「弱い」エンティティになります。