識別関係の技術的な定義は、子供の外部キーがその主キーの一部であるということです。
CREATE TABLE AuthoredBook (
author_id INT NOT NULL,
book_id INT NOT NULL,
PRIMARY KEY (author_id, book_id),
FOREIGN KEY (author_id) REFERENCES Authors(author_id),
FOREIGN KEY (book_id) REFERENCES Books(book_id)
);
見る？ book_idは外部キーですが、主キーの列の1つでもあります。したがって、このテーブルには、参照されるテーブルとの識別関係がありますBooks。同様に、との識別関係がありAuthorsます。
YouTube動画へのコメントは、それぞれの動画と識別関係があります。は、テーブルの主キーの一部である必要がありvideo_id ますComments。
CREATE TABLE Comments (
video_id INT NOT NULL,
user_id INT NOT NULL,
comment_dt DATETIME NOT NULL,
PRIMARY KEY (video_id, user_id, comment_dt),
FOREIGN KEY (video_id) REFERENCES Videos(video_id),
FOREIGN KEY (user_id) REFERENCES Users(user_id)
);
最近では、複合主キーの代わりにシリアル代理キーのみを使用することが一般的になっているため、これを理解するのは難しいかもしれません。
CREATE TABLE Comments (
comment_id SERIAL PRIMARY KEY,
video_id INT NOT NULL,
user_id INT NOT NULL,
comment_dt DATETIME NOT NULL,
FOREIGN KEY (video_id) REFERENCES Videos(video_id),
FOREIGN KEY (user_id) REFERENCES Users(user_id)
);
これにより、テーブルに識別関係がある場合がわかりにくくなる可能性があります。
私はSSNが識別関係を表すとは考えていません。一部の人々は存在しますが、SSNを持っていません。他の人は新しいSSNを取得するためにファイルするかもしれません。したがって、SSNは実際には単なる属性であり、個人の主キーの一部ではありません。
@Nielsからのコメント：
したがって、複合主キーの代わりに代理キーを使用する場合、識別関係と非識別関係の使用に顕著な違いはありませんか？
そうだと思います。代理キーを使用してテーブル間の論理関係を変更していないため、「はい」と言うことを躊躇します。つまり、既存の動画を参照せずにコメントを作成することはできません。しかし、それは単にvideo_idがNULLでなければならないことを意味します。そして、論理的な側面は、私にとって、実際には関係を特定することについてのポイントです。
しかし、関係を特定するという物理的な側面もあります。そして、それは外部キー列が主キーの一部であるという事実です（主キーは必ずしも複合キーではなく、コメントの主キーとビデオテーブルの外部キーの両方である単一の列である可能性があります、ただし、動画ごとに1つのコメントしか保存できないことを意味します）。
関係を特定することは、実体関連図を作成するためにのみ重要であるように思われます。これは、GUIデータモデリングツールで発生します。