Крайне содержательное сообщение, daunito, спасибо.

> Валидность данных во времени, да ещё и валидность-историчность структуры данных - усложняют
> задачу в разы.

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

> программа должна просто уметь доставать нужные данные и из справочников (на определенную дату)

Вы забыли присовокупить блок-схему телепатического устройства для такой базы данных.

Г-н _мод уже сказал все, что можно сказать по теме. Любые другие варианты реализации, включая оракловые приблуды, - поделки обкуренных китайских первоклассников-второгодников. Обсуждать имеет смысл достаточно узкие вещи: критерии выбора метамодели, набор атрибутов, совместное использование версий и истории и пр.

> Г-н _мод уже сказал все, что можно сказать по теме

Причем, все сказанное обсуждалось не раз и не два, легко найдете поиском.

> суров...

При чем здесь "суров"? Тема возникает регулярно. И регулярно одни и те же люди дают одни и те же ответы. Причем, и неправильные ответы дают тоже регулярно и тоже одни и те же люди. Вас бы не задолбало читать ахинею?

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