1. у человека, из атрибутов, не могут меняться наверно только дата рождения, и место рождения
следовательно table1(men_id, men_birth_date)
2. далее... идут разные события в жизнии, например получение свидетельства о рождении, где появятся его ФИО и родители, будет указан пол - это всё атрибуты, которые будут всегда, но могут меняться)
table2(id, men_id, men_name1...3, parents, sex....)
далее указываем вид события и связанный с ним документ
table2( ... event_id,event_date, doc_type,doc_id)
и как говорили выше справочник событий (events) и связаных с ними документов обязательно дополняемый.
ещё будут таблицы с видами документов, сами документами (по doc_type - что за документ, по doc_id - данные документа из соотв. таблицы)

получается, что для каждого человека будет одна запись в таблице table1
и несколько в table2
для просмотра текущей информации, делается view, где отображается последнее "событие", можно ещё для "определённого" документа

минус такой схемы - дублирование информации в table2... например мадам выходит замуж, меняется только фамилия, а надо будет в table2 новую строку добавить которая будет отличаться от предыдущей только одним полем, и новый "паспорт" надо будет добавить, который такой же как и предыдущий, но где есть запись о супруге.

плюс - хранится вся история о людях и их документах

возможно имеет смысл сделать отдельный справочники для имён, фамилий, и отчеств..
parents - ссылаться на table.men_id...

по адресам, если могут меняться и названия, то думаю надо делать дерево, с возможностью хранения истории (примерно как показано выше) ... и в table2 указывать ID места рождения
сразу же сделать в клиенте возможность обновлять это дерево данными кладр

в итоге получится наверно ОЧЕНЬ большая таблица, и ОЧЕНЬ геморойно будет делать клиента... и надо отдельно что-то писать для переконвертирования старой БД

Novise Кифирчик
возможно имеет смысл сделать отдельный справочники для имён, фамилий, и отчеств..

О, только не это!!!
это почему? я заинтригован
по идее размеры в разы будут меньше, и вся таблица кроме поля ev_date получится в числах...
а комп быстрее с циферками работает нежеле с varchar.... в чём проблема?

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

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

ИМХО будет больше проблем в синхронизации с КЛАДР и само создание адресного реестра....
надо как-то извратиться, чтобы он отвечал нужным требованиям (например можно было хранить историю названий, или был в виде дерева) и одновременно сохранялись все ID при синхронизации с КЛАДР....
также проблема будет в конвертировании старой базы в новую... надо быть на 100% увереным в том что ошибок не будет... и сам переход на использование новой базы и клиента будет мучительным

ERROR MESSAGEА как ваша структура будет отражать факт смены пола гражданина?
если это ко мне вопрос, то:
Кифирчик
... идут разные события в жизнии, например получение свидетельства о рождении, где появятся его ФИО и родители, будет указан пол - это всё атрибуты, которые будут всегда, но могут меняться )
table2(id, men_id, men_name1...3, parents, sex ....)
далее указываем вид события и связанный с ним документ.....

в таблице table2 появится ещё одна строка, связанная с человеком, в которой будет другое поле sex, более поздняя дата, и возможно ссылка на новый паспорт или другой документ