Интересно. Что есть "ГЭРН" (государственный единый реестр населения) ?
Расскажу зачем мне это нада - я строю софт который будет считать коммуналку на город. Учет населения ведеться тупо - цифра сколько прописано в квартире (например, 5 чел).
Хочеться переделать, чтобы хранилось поименно нечто -
наниматель - ........
жена/муж - .....
сын/дочь - ......
Заодно облегчить жизнь ЖЭКовским папортистам (типа АРМа для них). Все это будет крутиться у меня (как центр расчетов), коммунальщиков (т.к. они заинтересованы) ну и возможно в отделе коммунального хоз-ва города в горисполкоме для аналитики. Никакой автоматизации паспортной службы/загса (прочих ведомств) в городе не будет (у них есть свои вышестоящие конторы, пусть занимаются)
Нет, ГЭРН - Городской Эталонный Регистр Населения.
Да, знакомо... Мы этим занимались в 94-95 гг в рамках малого предприятия в нескольких районах Питера. АРМы паспортистов до сих пор работают (Clipper87, если это слово о чем то говорит). Расчет квартплаты делался и печатался другой подсистемой другого малого предприятия. Потом это все было централизовано в ГУП ВЦКП ЖХ.
Прежде всего надо разделить подсистемы. Для расчета по большому счету нужны квартиры и съемщики. Значит для этих сущностей нужно обеспечить генерацию уникальных ключей (GUID вполне подойдет), чтобы без проблем экспортировать/импортировать и сливать в единую базу при нужде. Желательно, конечно, для всех сущностей так поступить, но это уже на совести проектировщика. Для адресов у нас существовал общегородской справочник-кодификатор районов и улиц. Дома и квартиры берутся из прописки, там, если не ошибаюсь, используется почтовый адрес. Есть еще и строительный адрес, который в общем случае, не совпадает с почтовым. Но вас, в любом случае, должен интересовать именно почтовый, поскольку извещения рассылаются почтой.
Для родственных отношений, насколько я помню, использовался внутренний справочник, всем съемщикам выставлялось значение родства относительно ответственного квартиросъемщика.
Льготы, нормативы и коэффициенты - это уже прерогатива БД расчета. Нужно только обеспечить синхронизацию на уровне подсистем "паспортная" - "расчет квартплаты". Вкратце пока все.
Вот структура ПИН-кода гражданина, использовавшаяся для ГЭРН:
Дата рождения (шесть цифр: две -год, две- месяц, две -день) + номер рождения (три цифры нечетные для мужчин, четные для женщин) + контрольная цифра. Между датой рождения и номером рождения ставиться дополнительное тире, которое меняется на знак плюс при достижении гражданином возраста 100 лет.
Документ "Коцепция создания АИС "Государственный Регистр Населения". Взят из открытых источников.
File attachments:
Прикрепленный файл | Размер |
---|---|
![]() | 73.56 KB |
Прочитал документ,
Пишет st,
Каков был подход сейчас уже не стОль важно, ввиду того, что система 10 лет назад функционировала на DBF, т.е. целостность поддерживалась на уровне приложения.
Сейчас на уровне БД можно (и нужно :) ) попытаться поддержать эту целостность средствами СУБД.
Итак, имеем сущность ДОКУМЕНТЫ_ГРАЖДАН для моделирования отношения М:М между гражданами и их документами.
Одной декларативной ссылочной целостности здесь, видимо не хватит: в этом случае нужно проектировать ДОКУМЕНТЫ_ГРАЖДАН в отношении 1:1 к ГРАЖДАНЕ и вводить поля-ссылки на документы по горизонтали, помечая обязательные документы как NOT NULL. В этом случае расширение номенклатуры документов также должно происходить по горизонтали, т.е. меняет структуру таблицы и кода приложения, что не всегда может быть приемлемо с точки зрения сопровождения.
Более гибкий способ не требующий изменения структуры, но требующий программирования - ввести сущность ОБЯЗАТЕЛЬНЫЕ_ДОКУМЕНТЫ_ГРАЖДАНИНА.
Тогда ДОКУМЕНТЫ_ГРАЖДАН расширяются по вертикали (строка: ID_Гражданина, ID_Документа), а наличие обязательных документов в отношении в соответствии со списком должно проверяться триггером. Также придется программировать триггером и логику добавления новых обязательных документов.
Если я вас правильно понял, то примерно так.