expla,

Вы меня не поняли. Да и я был немногословен. :) Поясняю.

В таблице сущность "Персона" не изменяется, а дополняется. Поле idPrevious содержит ссылку на Person.idPerson, где содержатся данные до смены фамилии/имени/(да можно и отчества:)). Зря вы idPrevous выкинули в "суррогатный" обвес.
Что то наподобии древа, но на idPerson накладывается уникальный индекс и, в результате, получаем связанный список. Все "ипостаси" личности (не знаю я как назвать совокупность атрибутов имя/фамилия назвать) хранятся в таблице, вместе со ссылками на предыдущую.

explaSenya_L,

я не вижу смысла выстраивать цепочки из ФИО, ведь чел может одновременно называть себя или проходить по документам и Ивановым и Петровым.Одновременно человек не может называть себя двумя фамилиями. Равно как и иметь разные паспорта. Зато он может в различные промежутки времени обладать, например, правом подписи и как Иванов, и как Петров.

Конечно, не считая случая загранпаспорта, где может быть те же фамилия/имя, но латиницей. С таким случаем дела не имел и, имхо, его надо рассматривать как особый.

explaМожет быть ты пытаешься притянуть сюда жизненный цикл паспорта. Не то что притянуть, а именно в соответствии с паспортом и должен фигурировать человек в документах, либо на основании документа его заменяющего. Случай мошеничества не рассматривается.

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

NafДанный шаблон может применяться, например, для курсов валют или цен товаров.Кстати, хотелось бы покритиковать этот шаблон. В нем трудно организовать CONSTRAINT на непересекаемость интервалов.

explaДа он вообще то не рабочий.

В контексте триггера OnAfterInsert функция DimensionSlice(new.Point, new.<Измерения>) на оракле будет поднимать исключение, типа таблица мутирует. Да что вы чУдите бесплатно! Автор привел образец врменного "среза" в SELECT'е, а не пример использования в Оракле.

NafSenya_L,
Да избыточность имеет место. Ограничения с помощью триггеров. Запросы на изменения не должны на прямую содержать значения EndPeriod.
Можно привести реализацию этого же шаблона без избыточности. Конец периода - начало следующего. Но Select там гораздо сложнее.Не совсем избыточность. Я тут подумал, все же EndPeriod нужен, если периоды не стыкуются и есть "разрывы".
NafНо Select там гораздо сложнее.В случае, например, изменения цен на товар ни капли не сложней. В заказе будет содержаться ссылка на ID правильной записи, и дальше - просто, чисто конкретный, JOIN :)