Проблемы при определении идентифицирующих или неидентифицирующих отношений

Question

Я прочитал этот вопрос: В чем разница между идентифицирующими и неидентифицирующими отношениями?

Но я все еще не уверен ... У меня есть три таблицы.

1. Пользователи
2. Предметы
3. Фотографии

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

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

Answer 1

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

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

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

Редактировать : Другие примеры из реальной жизни:

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

Answer 2

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

Answer 3

NickC Сказано: отношения «один к одному» идентифицируют отношения, а отношения «многие ко многим» - это не идентифицирующие отношения

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

• Неидентифицируемые отношения Ono-to-One
• Неидентифицирующие отношения один-ко-многим
• Идентифицирующие отношения один-к-одному
• Отношения один-ко-многим
• Отношения ко многим для идентификации

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

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

Answer 4

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

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

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

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

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

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

Идентифицирующее отношение один-к-одному

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

Неидентифицирующая связь один-к-одному

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

Отношения один-ко-многим

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

отношения многие ко многим

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

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

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

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

РЕДАКТИРОВАТЬ: NicoleC , я прочитал ответ , который вы связали, и он согласен с моим. Я понимаю его мнение о SSN и согласен, что это плохой пример. Я постараюсь придумать еще один более понятный пример. Однако, если мы начнем использовать реальные аналогии при определении отношений с базой данных, аналогии всегда рушатся. Не важно, идентифицирует ли SSN человека, важно, использовали ли вы его в качестве внешнего ключа.