Идентификация против неидентифицирующих отношений (снова!!!)

Итак, я прочитал здесь много ответов на stackoverflow, но я все еще смущен всей концепцией этого. В частности, я перешел к этой статье (включая все, на что она ссылается), но, похоже, не может найти надежного понимания концепции (или, возможно, это моя путаница между мощностью (n: m и т.д.) И тождествами ):

Все еще запутано в определении неиндексирующих отношений

Моя проблема такова: я знаю, что идентификация отношений подразумевает, что первичный ключ дочернего объекта должен включать в себя его внешний ключ, и что противоположное верно для неидентифицирующих отношений (это правильно?). Теперь это кажется слишком "передовым мышлением" для меня? То же самое было сказано в одном из комментариев в одной из ссылок. Как я могу "сделать шаг назад" и фактически увидеть , какие отношения имеют личность?

Например, у меня есть две дилеммы:

  • job_title (parent, 1) - employee (child, 1.. *). Правильно ли я считаю, что job_title - это таблица поиска, это должно быть не идентифицирующее отношение? Или было бы более точным сказать, что "сотрудник не может существовать без job_title, поэтому он должен идентифицировать"? Или это будет отношение, определяющее этот сценарий?
  • employee до employee_equipment (соединяющий объект между мощностью m: n) до equipment. Теперь я читал, что это должно быть идентифицирующее отношение по обе стороны от employee_equipment. Но что, если сотрудник не нуждается в оборудовании? Можно ли иметь необязательную идентификационную связь?

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

Любая помощь будет очень признательна!

ОТВЕТЫ

Ответ 1

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

Об опциональности важно помнить, что опциональность направлена. Чтобы использовать ваш пример employee_equipment: Конечно, сотрудникам не требуется оборудование. Отношение "один ко многим" от employee до employee_equipment является необязательным. В то же время, глядя на это с противоположной точки зрения, отношения являются обязательными. Вы не можете записать запись в employee_equipment, если нет employee, чтобы связать ее с.

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

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

Хорошими примерами являются чистые таблицы пересечений (например, employee_equipment). Первичным ключом чистого пересечения является комбинация внешних ключей с обеими родительскими таблицами. Обратите внимание, что некоторые люди могут также добавить суррогатный ключ к этим таблицам. Это не имеет большого значения с точки зрения идентификации, если есть несколько ключей-кандидатов. Что важно при определении личности, является ли внешний ключ частью ключа-кандидата, является ли этот ключ-кандидат первичным ключом.

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

Ответ 2

Joel предоставил хороший ответ (+1 к нему), позвольте мне просто предложить небольшой умственный ярлык, который вы можете использовать, думая об идентификации отношений... просто спросите себя:

Можно ли достичь уникальности только с атрибутами дочернего объекта?

Если нет, и вам нужно включить атрибуты, перенесенные из родителя в дочерний ключ, чтобы сделать его уникальным, тогда у вас есть идентифицирующее отношение 1. Это об идентификации-зависимости, а не о существовании-зависимости 2!

Вам может быть интересно этот пост для некоторых размышлений по этой теме.

1 И дочерний объект является "слабым" или "зависимым".

2 Хотя идентификационная зависимость обычно подразумевает зависимость существования.