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

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

_мод О ссылках в СБД"Какие факторы мешают использовать естественный ключ в качестве ссылки в сетевой модели?"
1. Может меняться
2. М.б. составным
3. Их м.б. несколько
4. Они м.б. не уникальны или содержать null
ну и.т.д.
Все это можно легко запретить (кроме "ну и.т.д.") без большого ущерба для здоровья. Собственно пп. 1, 3 и 4 обычно никто не использует (будучи в здравом уме).

Остается п.2. Почему составной ключ это плохо для ссылки? Например, все документы в фирме могут кодироваться двумя полями: отдел и номер. Тогда при создании документа надо их инициализировать, а далее как обычно забыть про их существование:


В чем проблема?

Интересно, а чем ссылки в ООБД отличаются от ссылок в СБД? И вообще, чем эти две модели отличаются?