КурдльЭто решение продиктовано моделью.
...
Во всяком случае для OLTP-систем.
Сомневаюсь.
Кроме большого количества проблем разного рода, включая проблемы с оптимизатором (в том числе проблем со стоимостью, join elemination и др.), я уже не говорю про вагон и маленькую тележку очевидных проблем не связанных с апексом, не встречал ни одного полезного свойства (при том, что работать с ними приходилось много).
Это всё скорее ошибки проектирования, имхо.

Курдль,

По теме: В апексе тяжело будет работать с составными ключами.

Начиная с какой-то версии (скорее всего 4.1 или раньше) есть выбор при создании Tabular Form: на основе ROWID или PK.
Для остальных случаев (например, выпадающих списков), можно создать обновляемое представление, и представить в виде PK что угодно. При этом заполнять PK можно в instead of триггере, а не на клиенте, на основе, например, скрытых полей, для которых проставлен default или hidden items. Впрочем instead of - это достаточно тяжелый метод, сильно усложняет разработку, проще переделать на простые ключи, если еще не поздно.

Курдль,

т.е. таблица CITIZENSHIP с полями ID_персоны и ID_государства - первичный ключ ?

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

Касательно уникальности, не очевидно. Гражданство может меняться, например, от гражданства можно отказаться или лишиться.
Другой пример - могут быть люди без гражданства (и это не то же самое, что данные не введены), но, например, с видом на жительство, поэтому отношения между странами и людьми могут быть не такими простыми.

Люди тоже постоянно меняют фамилию. Не редко бывают запросы от людей: когда первый раз у них одна фамилия, во втором запросе другая (и другой паспорт), соответственно их часто заводят как разных людей (и даже если паспорт одинаковый, такое часто бывает), а потом нужно объединить => меняется идентификатор человека.

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

Касательно апекса, если делать по вашему, можно сделать вью: PK - составное поле через разделитель, и отдельно поля, сделать вью обновляемой. Соответственно в Tabular Form первичный ключ - составное поле из view, для новых строк будет null, указать, что генерируется на основании триггера. view пересчитывает значение уже после внесения записи, соответственно, MRU смотрит, если поле первичного ключа null - запись новая, если не null - существующая.

Petro123ID ФИО Гражданство(FK)2 Петров РФ3 Сидров5 Иванов "то что в паспорте"
Даже в таком варианте, если заменить в FK естественный ключ на суррогатный, для программиста будет +.
Сожмёт таблицу, улучшит производительность. Рано или поздно понадобится изменить значение => облегчит модификацию в справочнике гражданств.

Если нужно что-то кроме РФ, то логично появление нескольких записей для одного человека.
Насколько детально нужно проектировать может знать только ТС.
В более серьезных ситуациях вносится не само гражданство, а документы, удостоверяющие наличие гражданства (паспорт и др.), а само гражданство уже можно взять оттуда.