Прежде всего - тема НЕ про преимущества/недостаки - это обсуждено многократно. Вопрос чисто терминологичекий.

Обычно первичный ключ таблицы называют "суррогатным ключом таблицы" если это поле,
1) не имеет смысла за пределами той БД, в которой определена таблица.
Точнее сказать единственный смысл его вне БД - разным значениям соответсвтуют разные записи. Глядя офф-лайн на список
Человек.ИД123456можно точно сказать, что людей двое. Однако надеятся, что при следующем обращении под ИД =123 по-прежнему лежит все тот же человек, что и в момент распечатки, вообще говоря запрещено.
Кроме того из (1) обычно следует
2) значение поля генерируется автоматически в БД .

"Естественным ключом таблицы" называют поле (группу полей) которое
1) используется в БД и внешнем мире в одинаковом смысле ибо
2) получает значение из стороннего по отношению к БД источника
и каким-то образом эквивалентность (1) сохраняется в дальнейшем.

А как назвать поле которое
1) используется в БД и внешнем мире в одинаковом смысле,
но
2) значение поля генерируется автоматически в БД
и каким-то образом эквивалентность (1) сохраняется в дальнейшем.
Может, "искусственный ключ" ?

Тогда каждый естественный ключ где-то является искусственным. Этим где-то не обязательно является компьютерная система. Можно тогда обсуждать типа
'ИМХО использование в системе Х в качестве ЕК таблицы Т искусственного ключа из системы Z вызывает сомнения ибо ...'

Ненавижу 1С
Как раз наоборот, человек сменит фамилию, имя, но это будет тот же человек!Пока, как в вашем последнем примере кто-то не решил свободные ключи использовать для новых данных. Или выгрузил/загрузил данные с переприсвоением ключей. И это полное право администратора - он по определению не обязан сохранять смысл суррогатного ключа, также как СУБД не обязана гарантировать, что запись с данных ключом вечно будет иметь данный Rowid. Если такая обязанность существует, то этой другой случай - другой термин.
Ненавижу 1СВот тут действительно не правы, даже номер и серия паспорта не идентифицирует человека (они могут смениться)!Верно. Для человека подобрать естественный ключ не могут даже ЦРУ с ФСБ, но речь опять не о существовании или целесообразности, а о терминах. В предшествующей фразе использован термин "естественный ключ" , он нуждается в определении.
Ненавижу 1С
Так в 1С:Зарплата и кадры поле "Табельный номер сотрудника" считалось уникальным (допустимо, всех новых принимать и давать новые номера). Но на некоторых предприятиях ведется практика давать вновь принятым работникам табельные номера уже уволившихся. Соответственно не о какой уникальности речи быть не может. Не совсем понял, что значит считалось уникальным, если допускается более одной записи?

vadiminfo
Неизменность значений, и вообще все что Вы включили в пп2 не имеет прямого отношения к ключам (у них главное уникальность).Все, что не уникально, просто не имеет отношения к теме. Дальнейшая классификация имеет прямое отношение только к ключам. И строится она по признакам, харктеризующим взаимосвязь данной БД и внешнего мира (возможно других БД). Таких признаков предложено два:
- сохранение согласованности значений: да или нет. Если да, то такие ключи можно назвать бизнес-ключами - они имеют смысл во внешнем мире. Каким образом поддерживается согласованность пока не важно. Может быть просто неизменность, а может быть и специальные процедуры (перекодирование и пр.) для синхронизации изменений.
- источник значений:
если БД тогда это искусственный бизнес-ключ этой БД или просто искусственный ключ,
если внешний мир то это естественный бизнес-ключ или просто естественный ключ
vadiminfo Может иметь косвенное в плане физической реализации и прямое к идентификаторам. Но не везде первичный ключ считают идентификатором. Он может иметь значение физическое в плане производительности, и с учетом того, что некоторые операции в диалектах языков БД (или каких-то фичах) различных производителей возможны для первичных ключей, и не допустимы для альтекрнативных.
). С терминами альтернативный и первичный проблем нет, согласен.
vadiminfo
В любом случае это поле, про которое Вы говорите, обыкновенно претендует на термин "естественный". Поскольку единственным признаком деления на Естественные или Суррогатные является принадлежность атрибута реальному объекту или нет.
Вот это обыкновение мне не совсем нравится, ибо если мы генерируем ключ в БД, например, присваиваем инвентарный номер экземпляру книги в библиотеке, то изначально этот номер реальному объекту не принадлежит и в нем ничего естественного нет. Когда он будет нанесен на экземпляр, то уже конечно безразлично, откуда он взялся, главное что он одинаков в БД и во внешнем мире.

mirЕсли кого-то интересует мое мнение, то главное, что отличает суррогатный ( искусственный) ПК от натурального (естественного, интеллектуального) ПК, это вовсе не известность / неизвестность его наличия для внешнего пользователя информационной системы, а все же сам факт существования такого набора атрибутов вне информационной системы. То есть если некоторые характеристики создаются внутри информационной системы, то они не могут называться естественными. Поэтому любой ПК, значения которого генерируются программно (самой СУБД или клиентским ПО, неважно), во избежание путаницы следует называть суррогатным (искусственным).

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

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

г. Cелко известен своим трудом о деревьях и как автор книг по SQL, однако по поводу определений я бы не стал на него надеятся. Например его статья вызвала у меня больше вопросов, чем дала ответов:).

2 4321
Отличный вопрос! Сам над этим думаю, в следующем направлении...
В определении суррогатный/бизнес-ключ важно относительно чего мы определяемся, где проведена граница системы. Поскольку мы рассматриваем базу данных в целом, то для данной родительской таблицы, имеющей суррогатный ключ таблицы (СКТ), все внешние ключи на него из других таблиц этой БД также являются суррогатами нашей системы. Все они определенны на одном суррогатном домене - суррогатном ключе базы данных (СКБД) для той сущности, которую представляет таблица.

Если бы мы по каким-то причинам провели границу системы между родителем и дочерними таблицами, то получили бы ситуацию искусственный - естественные ключи.

Выбор идентифицирующей / неидентифицирующей миграции первичного ключа в подчиненную таблицу - отдельная песня. Как суррогатные так и бизнес-ключи родительских таблиц могут мигрировать и тем и другим способом. В ваших примерах
я бы сказал что все поля - это СКБД, а id_rab также СКТ таблицы T2 .
Достойна ли ситуация T1 какого-то специального термина кроме "идентифицирующая миграция СК" ? Не думаю, что в этом есть необходимость.
Итого имеем 2 таблицы, 5 полей все СКБД, З домена все суррогатные, 2 иденифицирующие и 2 неидентифицирующие миграции, 1 СКТ.

З.Ы. В T2 я бы еще добавил альтернативный ключ (id_comp,id_per) в соответствии с нашими текущими представлениями о предметной области.

4321 Подойдем с такой стороны:
в предметной области (вернее ее логической модели ) есть сущности
"компании", "персоны", "работники", причем "работники" - это отношение (в некотором приближении, ес-но) меж сущностями "компании" и "персоны" (именно "в предметной области", что означает, как говорилось, в ее логической модели - т.к. _соб-сно_ в п.о. нет даже и сущностей) - и по самой сущности "отношения" есть ничто иное, как набор указателей на компании и персоны, т.е. есть набор пар ключей этих сущностей. А уж то, что ключи сущностей взяты суррогатными - не влияет на природу отношения.
Да. (id_comp,id_per) и как первичный ключ в T1, и как альтернативный ключ в T2 несомненно моделируют некое "естественное" бизнес-правило про найм работников. 4321 Т.ч. заключаем что (id_comp,id_per) - естественный
Не согласен. Главное - значение ключа (id_comp,id_per) также не имеет смысла за пределами БД и является суррогатным поскольку всего его компоненты-суррогаты. Заметьте, суррогатный ключ собственно таблицы людей также выражает "естественное" бизнес-правило уникальности людей. (см. начало топика). Благодаря этому можно например посчитать количество людей используя только суррогатное поле. Однако сам ключ если был суррогатным, то им и остается.
Конечно, наличие ключа (id_comp,id_per) существенно расширяет наши возможности. Используя лишь суррогатные ключи теперь можно посчитать среднее , максимальное, минимальное число людей - работников в организациях.
Усложним ситуацию. Пусть id_comp - это естественный ключ кампании. Что тогда сказать про (id_comp,id_per) ? Суррогатный на 50%?
По-моему не нужно применять эту терминологию к композитным ключам, включающим мигрировавшие ключи.
Резюме. Я бы назвал (id_comp,id_per) ключом, реализующим бизнес-правило, соответсвующим бизнес-правилу, но не естественным.

Андрей ЛеонидовичЗдесь я пользовался терминологией объектных моделей данных и ОСУБД, где просто нет ключей (но есть уникальные характеристики, при необходимости), и нет нужды анализировать прилагательные к существительному "ключ"... А уникальные характеристики не могут иметь прилагательных? Типа код страны по ISO - естественная уникальная характеристика.