Все еще запутано в определении или неидентифицирующих отношениях

Ответ 1

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

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

Re comment from @Niels:

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

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

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

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

Ответ 2

", поскольку я не хочу учиться чему-то не так".

Welll, если вы действительно это понимаете, тогда вы можете перестать беспокоиться о ER lingo и терминологии. Это неточно, смущает, запутывает, совсем не согласуется, и по большей части не имеет значения.

ER - это куча прямоугольников и прямых линий, нарисованных на листе бумаги. ER намеренно предназначен для использования в неформальном моделировании. Таким образом, это ценный первый шаг в разработке базы данных, но это также просто: первый шаг.

Никогда не будет диаграмма ER нигде ближе к точности, точности и полноте дизайна базы данных, формально записанной в D.

Ответ 3

Идентификация/неидентификация отношений - это концепции в моделировании ER - отношение является идентифицирующим, если оно представлено внешним ключом, который является частью первичного ключа таблицы ссылок. Это обычно имеет очень малое значение в терминах реляционного моделирования, поскольку первичные ключи в реляционной модели и в базах данных SQL не имеют никакого особого значения или функции, как в ER-модели.

Например, предположим, что ваша таблица использует два ключа-кандидата, A и B. Предположим, что A также является внешним ключом в этой таблице. Представленная таким образом связь считается "идентифицирующей", если A обозначен как "первичный" ключ, но не идентифицирует, является ли B первичным ключом. Однако форма, функция и смысл таблицы одинаковы в каждом случае! Вот почему, на мой взгляд, я не думаю, что концепция идентификации/неидентификации действительно очень важна.

Ответ 4

Я считаю, что только разница между идентифицирующей и неидентифицирующей связью связана с Nullability внешнего ключа. Если FK не может быть NULL, отношение, которое оно представляет, идентифицирует (ребенок не может существовать без родителя), иначе он не идентифицируется.

Ответ 5

часть проблемы здесь - путаница терминологии. идентифицирующие отношения полезны для избежания длинных путей объединения.

Лучшее определение, которое я видел, это "идентифицирующая связь включает в себя PK как родителя в дочернем PK. Другими словами, PK ребенка включает FK в родительскую, а также" фактическую "PK ребенок.

Ответ 6

Да, пойдите первым, но я не думаю, что второй противоречит первому. Он просто сформулировал немного путаницу..

UPDATE:

Только что проверено - второй вопрос ответ неверен в некоторых предположениях,.. book-author не обязательно 1: n отношение, так как это может быть m: n. В реляционных базах данных, которые создают таблицу пересечений для этого отношения m: n, и вы получаете идентификацию отношений между таблицей пересечений и двумя другими таблицами.

Ответ 7

идентифицирующая взаимосвязь выдает от одного до многих необязательных отношений, когда мы должны определить родительское отношение к дочерним отношениям. Кроме того, он дает только одно отношение от дочернего к родительскому потоку. Поскольку первичный ключ родительского объекта будет частью первичного ключа дочерний объект, экземпляр дочернего объекта идентифицирует экземпляр родительского объекта. Он представлен сплошной линией в диаграмме er.

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