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

Question

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

Но я все еще не совсем уверен...Все, что у меня есть, - это три таблицы.

1. Пользователи
2. Объекты
3. Фотографии

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

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

• Неидентифицирующие отношения "Одно к одному"
• Неидентифицирующие отношения "Один ко многим"
• Взаимно однозначное определение взаимосвязей
• Идентифицирующие отношения "Один ко многим"
• Идентифицирующие отношения "Многие ко многим"

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

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

Answer 4

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

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

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

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

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

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

Взаимно однозначное идентифицирующее отношение

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

Взаимно-однозначное неидентифицирующее отношение

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

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

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

Отношения "Многие ко многим"

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

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

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

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

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