Проблемы, связанные с определением или отсутствием идентификации

Ответ 1

Оба звучат как определение отношений со мной. Если вы слышали термины "один-к-одному" или "один ко многим" и "многие ко многим", один-к-отношениям относятся идентифицирующие отношения и < сильные отношения > многие-ко-многим не идентифицирующие отношения.

• Если дочерний элемент идентифицирует родителя, это идентифицирующее отношение. В приведенной ссылке, если у вас есть номер телефона, вы знаете, к кому он принадлежит (он принадлежит только одному).

• Если дочерний элемент не идентифицирует своего родителя, это не идентифицирующая связь. В ссылке упоминаются состояния. Подумайте о состоянии как строке в таблице, представляющей настроение. "Счастливый" не идентифицирует конкретного человека, но многие люди.

Изменить. Другие примеры реальной жизни:

• Физический адрес - это не идентифицирующая связь, потому что многие люди могут проживать по одному адресу. С другой стороны, адрес электронной почты (обычно считается) идентифицирующим отношением.
• Номер социального обеспечения - это идентифицирующее отношение, поскольку оно принадлежит только одному человеку.
• Комментарии к видео Youtube определяют отношения, потому что они принадлежат только одному видео.
• В оригинале картины есть только один владелец (идентифицирующий), в то время как многие люди могут перепечатывать картину (не идентифицировать).

Ответ 2

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

Ответ 3

NickC Said: отношения "один-к-отношениям" идентифицируют отношения, а отношения "многие ко многим" - это не идентифицирующие отношения

Объяснение кажется совершенно неправильным для меня. Вы можете:

• Относительные отношения Ono-to-One
• Относительные отношения "один-ко-многим"
• Индивидуальные идентификационные отношения
• Индивидуальные отношения "один ко многим"
• Многозначительные идентификационные отношения

Представьте, что у вас есть следующие таблицы: customer, products и feedback. Все они основаны на customer_id, который существует в таблице cutomer. Таким образом, по определению NickC не должно существовать каких-либо определений отношений "многие-ко-многим", однако в моем примере вы можете ясно видеть, что: Обратная связь может существовать только в том случае, если соответствующий Продукт существует и был куплен Клиентом, поэтому Клиент, Продукты и Обратная связь должны быть идентифицированы.

Вы можете посмотреть Руководство по MySQL, объяснив, как добавить внешние ключи в MySQL Workbench.

Ответ 4

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

Идентификация против неидентификации не имеет ничего общего с идентификацией. Просто спросите себя, может ли запись ребенка существовать без родителя? Если ответ "да", он не идентифицируется.

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

Задайте себе этот вопрос

• Может ли запись ребенка существовать без родительской записи?

Если ребенок может существовать без родителя, тогда связь не идентифицируется. (Спасибо, MontrealDevOne за более четкое изложение)

Индивидуальная идентификационная связь

Номера социальной защиты хорошо подходят для этой категории. Представьте, например, что номера социального страхования не могут существовать вне человека (возможно, они могут на самом деле, но не в нашей базе данных). person_id будет PK для таблицы человек, включая столбцы, такие как имя и адрес. (пусть будет проще). Таблица social_security_number включала бы столбец ssn и столбец person_id в качестве внешнего ключа. Поскольку этот FK может использоваться как PK для таблицы social_security_number, это идентифицирующее отношение.

Индивидуальное неидентификационное отношение

В большом офисном комплексе у вас может быть таблица офис, которая включает номера комнат по полу и номеру здания с ПК и отдельную таблицу сотрудник. Таблица employee (child) имеет FK, который является столбцом office_id из таблицы PK office. Хотя каждый сотрудник имеет только один офис и (для этого примера), в каждом офисе есть только один сотрудник, это не идентифицирующие отношения, поскольку офисы могут существовать без сотрудников, а сотрудники могут менять офисы или работать в этой области.

Отношение "один ко многим"

Отношения "один ко многим" можно легко классифицировать, задавая тот же вопрос.

Связи Many-to-many

Отношения "многие ко многим" всегда определяют отношения. Это может показаться встречным интуитивным, но нести меня. Возьмите две таблицы libary и книги. В каждой библиотеке много книг, а в каждой из них существует копия каждой книги.

Вот что он делает и идентифицирует отношения: Чтобы реализовать это, вам нужна таблица ссылок с двумя столбцами, которые являются первичными ключами для каждой таблицы. Назовите их столбцом library_id и столбцом ISBN. Эта новая таблица ссылок не имеет отдельного первичного ключа, но подождите! Внешние ключи становятся многоколоночным первичным ключом для таблицы ссылок, поскольку дублирующие записи в таблице ссылок не имеют смысла. Ссылки не могут существовать без родителей; поэтому это идентифицирующая связь. Я знаю, да, правильно?

В большинстве случаев тип отношения не имеет значения.

Все, что сказал, обычно вам не нужно беспокоиться о том, что у вас есть. Просто назначьте правильные первичные и внешние ключи для каждой таблицы, и связь обнаружит себя.

EDIT: NicoleC, я прочитал ответ , который вы связали, и согласен с моим. Я беру его точку в SSN и соглашусь с тем, что это плохой пример. Я постараюсь придумать еще один более яркий пример. Однако, если мы начнем использовать реальные аналогии в определении отношения базы данных, аналогии всегда ломаются. Не имеет значения, независимо от того, идентифицирует ли SSN человека, важно ли вы использовать его как внешний ключ.