Проблемы при определении идентифицирующих или неидентифицирующих отношений
Я прочитал этот вопрос: в чем разница между идентифицирующими и неидентифицирующими отношениями?
Но я все еще не уверен... У меня есть три стола.
- пользователей
- Объекты
- Фотографий
Пользователь может владеть многими объектами, а также может размещать множество изображений для каждого отдельного объекта. Мои интуитивные ощущения говорят мне, что это идентифицирующая связь, потому что мне понадобится идентификатор пользователя в таблице объектов и мне понадобится идентификатор объекта в таблицах изображений...
Или я не прав? Объяснения в другой теме ограничиваются теоретическим объяснением того, как база данных интерпретирует ее после того, как она уже была закодирована, а не тем, как объекты связаны в реальной жизни. Я немного сбит с толку относительно того, как принять решение о том, чтобы идентифицировать, а не не идентифицировать, когда я думаю о том, как я собираюсь создать базу данных.
4 ответа
Оба звучат как идентифицирующие отношения со мной. Если вы слышали термины "один-к-одному" или "один-ко-многим" и "многие-ко-многим", " один-к-отношениям" идентифицируют отношения, а отношения " многие-ко-многим" не идентифицируют отношения.
Если ребенок идентифицирует своего родителя, это идентифицирующая связь. По указанной вами ссылке, если у вас есть номер телефона, вы знаете, кому он принадлежит (он принадлежит только одному).
Если ребенок не идентифицирует своего родителя, это неидентифицирующая связь. В ссылке упоминаются штаты. Думайте о состоянии как о строке в таблице, представляющей настроение. "Счастливый" не идентифицирует конкретного человека, но многих людей.
Изменить: Другие примеры из жизни:
- Физический адрес - это неидентифицирующая связь, потому что многие люди могут проживать по одному адресу. С другой стороны, адрес электронной почты (как правило, считается) идентифицирующие отношения.
- Номер социального страхования является идентифицирующим отношением, потому что он принадлежит только одному человеку
- Комментарии к видео на YouTube идентифицируют отношения, потому что они принадлежат только одному видео.
- У оригинала картины есть только один владелец (идентифицирующий), в то время как у многих людей могут быть перепечатки картины (не идентифицирующие).
Я думаю, что более простой способ визуализировать это - спросить себя, может ли запись о ребенке существовать без родителя. Например, позиция строки заказа требует наличия заголовка заказа. Таким образом, элемент строки заказа должен иметь идентификатор заголовка заказа как часть своего ключа, и, следовательно, это пример идентифицирующей взаимосвязи.
С другой стороны, телефонные номера могут существовать без права собственности на человека, хотя у человека может быть несколько телефонных номеров. В этом случае лицо, которому принадлежит номер телефона, является неключевым или неидентифицирующим отношением, так как номера телефонов могут существовать независимо от лица владельца (следовательно, лицо, владеющее номером телефона, может быть нулевым, тогда как в примере позиции строки заказа, идентификатор заголовка заказа не может быть нулевым.
NickC Сказал: отношения один-ко-это идентифицирующие отношения, а отношения многие-ко-много не идентифицирующие отношения
Объяснение кажется мне совершенно неверным. Вы можете иметь:
- Ono-to-One Неидентифицирующие Отношения
- Неидентифицирующие отношения один-ко-многим
- Идентифицирующие отношения один-к-одному
- Отношения один ко многим
- Отношения "многие ко многим"
Представьте, что у вас есть следующие таблицы: customer, products а также feedback, Все они основаны на customer_id который существует на cutomer Таблица. Таким образом, по определению NickC не должно существовать каких-либо идентификационных отношений "многие ко многим", однако в моем примере вы можете ясно видеть, что: обратная связь может существовать, только если соответствующий продукт существует и был куплен заказчиком. Клиент, продукты и обратная связь должны быть идентифицирующими.
Вы можете взглянуть на Руководство по MySQL, объясняющее, как добавить внешние ключи в MySQL Workbench.
Махди, твои инстинкты верны. Это повторяющийся вопрос, и этот ответ с неправильным голосованием не является правильным или полным. Посмотрите на два верхних ответа здесь: разница между выявлением неидентификации
Идентификация против неидентификации не имеет ничего общего с идентичностью. Просто спросите себя, может ли запись ребенка существовать без родителя? Если ответ "да", то он не является идентифицирующим.
Основная проблема заключается в том, включает ли первичный ключ дочернего элемента внешний ключ родительского элемента. В неидентифицирующих отношениях первичный ключ ребенка (PK) не может включать внешний ключ (FK).
Задайте себе этот вопрос
- Может ли дочерняя запись существовать без родительской записи?
Если ребенок может существовать без родителя, то связь не идентифицирует. (Спасибо, MontrealDevOne за более четкое изложение)
Идентифицирующие отношения один-к-одному
Номера социального страхования хорошо вписываются в эту категорию. Давайте представим, например, что номера социального страхования не могут существовать без человека (возможно, они могут в действительности, но не в нашей базе данных). Person_id будет PK для таблицы person, включая столбцы, такие как имя и адрес. (давайте будем простыми). Таблица social_security_number будет включать столбец ssn и столбец person_id в качестве внешнего ключа. Поскольку этот FK может использоваться в качестве PK для таблицы social_security_number, он является идентифицирующим отношением.
Не идентифицирующие отношения один-к-одному
В большом офисном комплексе у вас может быть офисный стол, который включает номера комнат по этажам и номер здания с ПК, а также отдельный стол для сотрудников. Таблица сотрудника (дочерняя) имеет FK, который является столбцом office_id из офисной таблицы PK. Хотя у каждого сотрудника есть только один офис, и (в данном примере) в каждом офисе есть только один сотрудник, это неидентифицирующая связь, поскольку офисы могут существовать без сотрудников, а сотрудники могут менять офисы или работать на местах.
Отношения один ко многим
Отношения "один ко многим" можно легко классифицировать, задавая один и тот же вопрос.
Отношения многие ко многим
Отношения многие ко многим всегда определяют отношения. Это может показаться нелогичным, но потерпите меня. Возьмите две таблицы libary и books, в каждой библиотеке много книг, и копия каждой книги существует во многих библиотеках.
Вот что делает это и определяет взаимосвязь: Для реализации этого вам нужна таблица связей с двумя столбцами, которые являются первичными ключами каждой таблицы. Назовите их столбец library_id и столбец ISBN. Эта новая таблица ссылок не имеет отдельного первичного ключа, но подождите! Внешние ключи становятся первичным ключом из нескольких столбцов для таблицы ссылок, поскольку дубликаты записей в таблице ссылок будут бессмысленными. Связи не могут существовать без родителей; следовательно, это идентифицирующие отношения. Я знаю, чёрт не так ли?
В большинстве случаев тип отношений не имеет значения.
Все это говорит, как правило, вам не нужно беспокоиться о том, что у вас есть. Просто назначьте надлежащие первичные и внешние ключи каждой таблице, и связь обнаружится сама собой.
РЕДАКТИРОВАТЬ: Nicole, я прочитал ответ, который вы связали, и он согласен с моим. Я согласен с его мнением о SSN и согласен, что это плохой пример. Я постараюсь придумать еще один более понятный пример. Однако, если мы начнем использовать реальные аналогии при определении отношений с базой данных, аналогии всегда рушатся. Не важно, идентифицирует ли SSN человека, важно, использовали ли вы его как внешний ключ.