Техническое определение идентифицирующих отношений состоит в том, что внешний ключ ребенка является частью его первичного ключа.
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 - это внешний ключ, но он также является одним из столбцов в первичном ключе. Таким образом, эта таблица имеет идентифицирующую связь с ссылочной таблицей 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:
Так что, если мы используем суррогатный ключ вместо составного первичного ключа, нет заметной разницы между использованием идентифицирующих или неидентифицирующих отношений?
Полагаю, так. Я не решаюсь сказать «да», потому что мы не изменили логическое отношение 1033 * между таблицами, используя суррогатный ключ. То есть вы по-прежнему не можете оставлять комментарии, не ссылаясь на существующее видео. Но это просто означает, что video_id должен быть NOT NULL. И логический аспект, для меня, действительно заключается в определении отношений.
Но есть и физический аспект идентификации отношений. И это тот факт, что столбец внешнего ключа является частью первичного ключа (первичный ключ не обязательно является составным ключом, это может быть один столбец, который является как первичным ключом комментариев, так и внешним ключом таблицы Videos. , но это будет означать, что вы можете хранить только один комментарий к видео).
Идентификация отношений, кажется, важна только для построения диаграмм отношений сущностей, и это появляется в инструментах моделирования данных GUI.