В чем принципиальная разница между идентифицирующей и неидентифицирующей связью?

Question

[Иван Мельников]

В идентифицирующей связи первичный ключ родительской таблицы становится частью первичного ключа в дочерней таблице. Это делается того, чтобы запись в дочерней таблице не могла существовать сама по себе, без ссылки на существующую запись в родительской таблице. Но что мешает нам не делать внешний ключ в дочерней таблице частью первичного ключа, а просто сделать его NOT NULL? Тогда запись в дочерней таблице тоже не сможет существовать без ссылки на существующую запись в родительской таблице.
На ER-диаграмме ниже таблицы Phone_1 и Phone_2 должны быть на мой взгляд полностью равносильны. Или я чего-то не понимаю?

Comments

[Saboteur]

Тогда запись в дочерней таблице тоже не сможет существовать без ссылки на существующую запись в родительской таблице.

Почему? Кто мне мешает сделать рандомную запись во второй таблице, если никакой привязки нет и я могу сгенерировать любую запись?

[Иван Мельников]

Saboteur, почему нет никакой привязки? Есть же внешний ключ Employee_id NOT NULL (пунктирная линия). И этот внешний ключ помешает вам сгенерить любую запись.

[Saboteur]

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

[Иван Мельников]

Saboteur, я чего-то не понимаю. Каким образом я могу сделать запись в таблицу Phone_1 без ссылки на существующую запись в таблице Employee? Поле employee_id же является внешним ключом и при этом NOT NULL.

[Saboteur]

Значит у вас в обоих случаях идентифицирующая связь. Ибо неиндифицирующая связь позволяет создать в таблице сущность, которая не связана с записей в таблице 1.

Answer 1

[Vindicar]

Ну, положим, они не полностью равносильны.
В Phone_1 id должен быть уникален для каждой записи. Поэтому если ты захочишь переключить запись в Phone_1 с одного Employee на другого, ты точно всегда сможешь это сделать. Это можно интерпретировать как "записи в Phone_1 существуют сами по себе, несмотря на обязательную связь с Employee".
В Phone_2 id должен быть уникален среди записей с одинаковым Employee_id. Т.е. уникальной должна быть их комбинация. При попытке переключения записи в Phone_2 с одного Employee на другого Employee есть риск коллизии по id. Это можно интерпретировать как "записи в Phone_1 существуют строго в контексте Employee, и их собственные id имеют смысл только в контексте, заданном Employee_id". Т.е. Employee_id становится своего рода "пространством имён".

Comments

[Иван Мельников]

А если id - это автоинкрементное поле, то есть оно уникально по факту в рамках всей таблицы, а не только для каждого employee_id.

[Vindicar]

Иван Мельников, ну если специально делать всё, чтобы имитировать свойства одного типа связей средствами другого, то внезапно эти типы будут неразличимы. Это должно удивлять? =)

Если вопрос был "существует ли четкая граница между двумя типами связей", то ответ "нет, не существует". Но это не значит, что нельзя различать ситуации, в которых применяется один или другой тип.

Answer 2

[ComodoHacker]

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

Так что ничто не мешает.

Comments

[Иван Мельников]

А почему составные первичные ключи сейчас почти не применяются?

[ComodoHacker]

Иван Мельников, Ну, это я погорячился. Применяются, просто я последние лет 10 не встречал. :)