Учет населения

Интересно. Что есть "ГЭРН" (государственный единый реестр населения) ?
Расскажу зачем мне это нада - я строю софт который будет считать коммуналку на город. Учет населения ведеться тупо - цифра сколько прописано в квартире (например, 5 чел).
Хочеться переделать, чтобы хранилось поименно нечто -
наниматель - ........
жена/муж - .....
сын/дочь - ......
Заодно облегчить жизнь ЖЭКовским папортистам (типа АРМа для них). Все это будет крутиться у меня (как центр расчетов), коммунальщиков (т.к. они заинтересованы) ну и возможно в отделе коммунального хоз-ва города в горисполкоме для аналитики. Никакой автоматизации паспортной службы/загса (прочих ведомств) в городе не будет (у них есть свои вышестоящие конторы, пусть занимаются)

Нет, ГЭРН - Городской Эталонный Регистр Населения.

Да, знакомо... Мы этим занимались в 94-95 гг в рамках малого предприятия в нескольких районах Питера. АРМы паспортистов до сих пор работают (Clipper87, если это слово о чем то говорит). Расчет квартплаты делался и печатался другой подсистемой другого малого предприятия. Потом это все было централизовано в ГУП ВЦКП ЖХ.

Прежде всего надо разделить подсистемы. Для расчета по большому счету нужны квартиры и съемщики. Значит для этих сущностей нужно обеспечить генерацию уникальных ключей (GUID вполне подойдет), чтобы без проблем экспортировать/импортировать и сливать в единую базу при нужде. Желательно, конечно, для всех сущностей так поступить, но это уже на совести проектировщика. Для адресов у нас существовал общегородской справочник-кодификатор районов и улиц. Дома и квартиры берутся из прописки, там, если не ошибаюсь, используется почтовый адрес. Есть еще и строительный адрес, который в общем случае, не совпадает с почтовым. Но вас, в любом случае, должен интересовать именно почтовый, поскольку извещения рассылаются почтой.

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

Вот структура ПИН-кода гражданина, использовавшаяся для ГЭРН:

Дата рождения (шесть цифр: две -год, две- месяц, две -день) + номер рождения (три цифры нечетные для мужчин, четные для женщин) + контрольная цифра. Между датой рождения и номером рождения ставиться дополнительное тире, которое меняется на знак плюс при достижении гражданином возраста 100 лет.

Документ "Коцепция создания АИС "Государственный Регистр Населения". Взят из открытых источников.

File attachments: 

Прикрепленный файлРазмер
Package icon konc_grn.zip73.56 KB

Forums: 

Изображение пользователя st.

Прочитал документ,

Прочитал документ, который Вы прислали - надо признать, он достаточно основателен и как описание концепции и как ТЗ для разработки конкретных решений.
Было бы интересно также ознакомиться с документами которые Вы упоминали (или хотя бы с частью этих документов).
Интересует еще один нюанс в проектировании - который я бы хотел уточнить.
Итак гражданин как учетная единица имеет документы, что моделируется сущностью ГРАЖДАНЕ и сущностью ДОКУМЕНТЫ с отношением один ко многим.
Однако удостов. документы и документы - основания для прописки являясь подмножеством документов есть обязательные документы, тогда как другие - нет.
В приведенной выше модели связь сущности ГРАЖДАНЕ с сущностью ДОКУМЕНТЫ достаточно слаба для обязательных документов и вполне подходит для других типов документов.
Тут есть идея либо создать отдельную сущность ОБЯЗАТЕЛЬНЫЕ_ДОКУМЕНТЫ и делать в сущности ГРАЖДАНЕ ссылку на них - тем самым обеспечив сильную связь, либо создать с сущностью ДОКУМЕНТЫ "двухстороннюю" связь (для обязательных документов) (просьба не плеваться :) ) либо включить все обязательные реквизиты прямо в сущность ГРАЖДАНЕ.
Каков был Ваш подход ?

Каков был подход сейчас уже не стОль важно, ввиду того, что система 10 лет назад функционировала на DBF, т.е. целостность поддерживалась на уровне приложения.
Сейчас на уровне БД можно (и нужно :) ) попытаться поддержать эту целостность средствами СУБД.
Итак, имеем сущность ДОКУМЕНТЫ_ГРАЖДАН для моделирования отношения М:М между гражданами и их документами.
Одной декларативной ссылочной целостности здесь, видимо не хватит: в этом случае нужно проектировать ДОКУМЕНТЫ_ГРАЖДАН в отношении 1:1 к ГРАЖДАНЕ и вводить поля-ссылки на документы по горизонтали, помечая обязательные документы как NOT NULL. В этом случае расширение номенклатуры документов также должно происходить по горизонтали, т.е. меняет структуру таблицы и кода приложения, что не всегда может быть приемлемо с точки зрения сопровождения.
Более гибкий способ не требующий изменения структуры, но требующий программирования - ввести сущность ОБЯЗАТЕЛЬНЫЕ_ДОКУМЕНТЫ_ГРАЖДАНИНА.
Тогда ДОКУМЕНТЫ_ГРАЖДАН расширяются по вертикали (строка: ID_Гражданина, ID_Документа), а наличие обязательных документов в отношении в соответствии со списком должно проверяться триггером. Также придется программировать триггером и логику добавления новых обязательных документов.
Если я вас правильно понял, то примерно так.