Все еще перепутанный идентификацией по сравнению с неидентификацией отношений

) Техническое определение идентифицирующей связи состоит в том, что внешний ключ дочернего элемента является частью его первичного key.

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 . Точно так же он имеет идентифицирующую связь с авторами .

Комментарий к видео YouTube имеет идентифицирующую связь с соответствующим видео. video_id должен быть частью основного ключ таблицы Комментарии .

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 на самом деле является просто атрибутом, а не частью первичного ключа человека.

Re comment from @Niels:

Итак, если мы используем суррогатный ключ вместо составного первичного ключа, не будет заметной разницы между использованием идентифицирующих или неидентифицирующих отношений?

Полагаю, да. Я не решаюсь сказать да, потому что мы не изменили логические отношения между таблицами с помощью суррогатного ключа. То есть вы по-прежнему не можете оставить комментарий, не ссылаясь на существующее видео. Но это просто означает, что video_id не должен быть NULL. И логический аспект для меня действительно важен в выявлении отношений.

Но есть и физический аспект установления отношений. И это тот факт, что столбец внешнего ключа является частью первичного ключа (первичный ключ не обязательно является составным ключом, это может быть один столбец, который является как первичным ключом комментариев, так и внешним ключом для таблицы видео. , но это будет означать, что вы можете хранить только один комментарий для каждого видео).

Выявление взаимосвязей кажется важным только для построения диаграмм сущностей-взаимосвязей, и это проявляется в инструментах моделирования данных графического интерфейса пользователя.