NafChAМожете обосновать необходимость суррогатного атомарного основного ключа в таблицах, реализующих, например, связи сущностей M:N ?
Пример: 2 сущности - Организации, ФизЛица
множественная ассоциация между ними: Работник(Организация,Физлицо) - многие-ко-многим
Организация может содержать множество работников, Физлицо может быть работником нескольких организаций: в разный период действия, а также быть внешним или внутренним совместителем.
Сущности начислений и удержаний работников имеют ссылки именно на ассоциативную сущность Работник: именно от параметров ассоциации (оклад, срок выслуги) зависят расчеты по ним.Честно говоря, не ожидал столь широкой трактовки таблицы связи, под которую можно подвести любую таблицу, из которой есть ссылки на пару любых сущностей. Ваш пример описывает скорее процесс, чем состояние. Не то, чтобы это принципиально что-то меняет, но суть вопроса затемняет. Поэтому поправлюсь, подразумевались таблицы, в которых для идентификации любой из её строк достаточно упомянутых ссылок. Навскидку:
"Фильм"-"Жанр"

"Книга"-"Автор"

"Рецепт"-"Ингредиент"

"Диагноз"-"Симптом"

"Сплав"-"Элемент"
и т.п.
При этом, таблица связи может иметь какие-то дополнительные поля, это неважно. Но ключ уже есть - идентификаторы обоих сущностей(пусть каждый из них суррогатен и атомарен). Что даст добавления в такую таблицу ещё одного поля - суррогатного атомарного идентификатора ? И выбор его в качестве основного ключа ? А вот если отказаться от идентифицирующей пары, хотя бы, в качестве альтернативного ключа, то возникает реальная опасность, получить сколько угодно повторяющихся пар с одинаковыми значениями. И зачем ?
_модЭлементарно: аудитВ принципе, та же проблема. Для идентификации строки недостаточно ссылок, нужны дополнительные поля, например, время события. Но тогда столкнемся с другой проблемой, дискретность, с которой можно получить время от компьютера, да и хранить тоже. Не говоря уж о том, что, в многозадачной среде события могут происходить "одновременно". Поэтому лучшим вариантом здесь действительно является суррогатный ключ, благодаря тому, что генератор суррогатных значений сериализует обращения.
_модВсе сущности независимы по определению. Просто между ними м.б. ссылки.
Например: есть Организации и Подразделения, Подразделения ссылаются на Организации. Но можно получить список всех подразделений независимо от Организации по какому-либо признаку.Хотелось бы увидеть это определение. На мой взгляд, выглядит спорно. Иначе зачем говорить о том, что они независимы, если других(по определению) не бывает.
Возможность независимого доступа, IMHO, вовсе не означает независимости описываемых в БД сущностей, это свойство РБД, так как все данные хранятся в раздельных равнодоступных плоских таблицах. В иерархических же системах хранения данных такой доступ был бы "нелегален".
В данном примере, удаление организации автоматически подразумевает удаление всех его подразделений. Они попросту не могут существовать вне организации. Что это, если не зависимость ?
Да и ценность получения списка подразделений независимо от организации сомнительна.

P.S. Удобство и применимость суррогатных ключей не оспаривалось. Они нужны для решения разного рода практических задач, начиная с упрощения запросов, физического размера БД, скорости слияний, для той же сериализации, наконец. Оспаривалась необходимость автоматического их включения в любую таблицу и полный отказ от составных ключей. Хуже того, суррогатный ключ может провоцировать на отказ от альтернативных ключей. К сожалению, это реальность, приходилось сталкиваться с таким подходом.

_модChAОни попросту не могут существовать вне организации. Что это, если не зависимость ?Сущности ссылаются друг на друга - вот и появляется иллюзия зависимости. Так подразделение просто нельзя добавить, если нет организации - это просто обязательное поле. И удалить ничего нельзя, если есть ссылки.Сущности равнодоступны, вот и появляется иллюзия независимости. IMHO, вполне симметричный аргумент.
У меня создалось впечатление, что со стандартом IDEF1X Вы совсем не знакомы, равно как и с понятиями идентифицирующей и неидентифицирующей связи.
Судя по всему, определения не будет._модChAДа и ценность получения списка подразделений независимо от организации сомнительна.Ну например все ИТ подразделения всех организацийКак-то уже обсуждалось нечто подобное. В большинстве случаев, полезность такой информации имеет разве что статистический характер. "Есть ложь, есть наглая ложь, а есть статистика"©. Не то, чтобы она вовсе бесполезна, но в данном примере её ценность стремится к нулю. Например, в данном случае, станет известно, что из 10 организаций 5 имеют IT-отделы, хотя лично я бы не взялся определить их только по названию подразделения. И что ?_модПроще говоря - сурр. ключ никому не мешает, но может оказаться полезен в любой момент развития системы.Т.е., места он не просит, индекс тоже обходится бесплатно ?

_модChAУ меня создалось впечатление, что со стандартом IDEF1X Вы совсем не знакомы, равно как и с понятиями идентифицирующей и неидентифицирующей связи.Бесполезные понятия.Следовательно, бесполезна и декларативная ссылочная целостность. Удручающая тенденция.

P.S. Наткнулся на забавный пример из практики одного из "светочей", близкого соратника Дейта, автора Practical Issues in Database Management: A Reference for the Thinking Practitioner . Вместо 4 сущностей сделал 5, но так и не обеспечил декларативной ссылочной целостности. Но все таблицы с обязательным атомарным суррогатным ключом и никаких идентифицирующих связей. Печальное зрелище, IMHO.