PRIL7.HTML

http://www.insoft.ru/

Бойченко Е.В.

Вопросы создания интегрированного банка данных “Население” г.Москвы

Постановка задачи

Задачи создания общегосударственной автоматизированной системы учета лиц, проживающих в Российской Федерации и временно пребывающих на ее территории, и официальных документов, удостоверяющих их личность (“Автоматизированная Система “Персона”) являются весьма актуальными в России в течение последних двух десятилетий. В последнее время эта проблема закономерно привлекает внимание и кабинета министров РФ. Основной целью работ, проводимых различными государственными учреждениями и ведомствами, является реализация проекта АС “Персона”, способствующего России в кратчайшие сроки создать единую национальную, интегрированную, распределенную систему баз данных лиц, проживающих в Российской Федерации и временно пребывающих на ее территории и оптимальным способом решить многие экономические и социальные задачи

Основными задачами АС “Персона” являются:

АС “Персона” создается как единая многоуровневая Государственная система на основе законодательной базы и стандартов.

АС “Персона” относится к основным реестрам, а именно к общероссийским информационным системам, которые идентифицируют основные элементы общества.

АС “Персона” должна характеризоваться широким охватом, надежностью, многосторонностью и защитой информации.

Главным критерием АС “Персона” является эффективность ее разработки и эксплуатации для всех составляющих системы, а именно соотношение показателей цена - прибыль.

Сбор, обработка и предоставление информации субъектам-пользователям АС “Персона” юридическим и физическим лицам должны производиться в строгом соответствии с действующим законодательством Российской Федерации.

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

Проблемы создания АИБД “Население” с учетом особенностей Москвы

Постановка задачи создания банка данных “Население” Москвы не нова. Вопросы разработки и внедрения в Москве автоматизированных систем, содержащих данные о населении, имеют достаточно глубокие исторические корни. Так уже в 1980 году в Москве была предпринята попытка создания базы данных населения Краснопресненского района, в то время одного из крупных районов Москвы. С 1985 года в промышленную эксплуатацию была внедрена автоматизированная система “Соцобеспечение” (последнее название РАСОИ “Соцзащита”), содержащая данные обо всех пенсионерах Москвы. С 1991 года создается АСУ “Население” Москвы и Московского региона Главного управления внутренних дел. В 1993 году внедрена в промышленную эксплуатацию Многоуровневая интегрированная автоматизированная система “ЗАГС” г. Москвы (МАИС “ЗАГС” г. Москвы). В 1998 году внедрена в промышленную эксплуатацию Государственная автоматизированная система “Выборы” по г. Москве в части комплекса функциональных задач “Учет избирателей”. С 1997 года создаются автоматизированные системы Пенсионного фонда РФ (отделение по Москве) и московской налоговой инспекции. В то же время актуальной и целостной базы данных “Население” Москвы до сих пор не создано.

Каковы же причины того, что несмотря на значительные финансовые ресурсы, выделенные Правительством Москвы на решение задачи создания банка данных “Население” Москвы, наличие в учреждениях, работающих с населением, большого количества персональных компьютеров и серверов, общегородской электронной почты, оптоволоконных и выделенных каналов связи, внедрения большого количества автоматизированных рабочих мест для регистрации населения, актуальная и целостная база данных “Население” Москвы отсутствует. По моему мнению, должны быть рассмотрены три основных причины: функциональная, технологическая и организационно-финансовая.

Внедренные в промышленную эксплуатацию автоматизированные системы РАСОИ “Соцзащита”, МАИС “ЗАГС”, ГАС “Выборы” по г. Москве в части КФЗ “Учет избирателей” имеют огромное значение для решения задач своей предметной области.

Так РАСОИ “Соцзащита” предназначена для своевременного и правильного исчисления пенсий и пособий социально незащищенным слоям населения на основе общегородского интегрированного банка данных пенсионеров, объемом 2,5 млн. записей.

МАИС “ЗАГС” г. Москвы предназначена для автоматизированной регистрации актов гражданского состояния населения: рождения, смерти, брака, расторжения брака, установления отцовства, усыновления (удочерения), перемены имени и выдачи ответов на запросы граждан и организаций в реальном масштабе времени. Основой МАИС “ЗАГС” является общегородская база данных “ЗАГС”, объемом 12 млн. записей, об изменении гражданского состояния населения на территории Москвы за период с 1990 года по настоящее время.

КФЗ “Учет избирателей” Государственной автоматизированной системы “Выборы” по г. Москве предназначен для регистрации и учета избирателей Москвы, нарезки избирательных участков, подготовки и печати списков избирателей. Созданная общегородская база данных “Учет потенциальных избирателей”, объемом 8 млн. записей, содержит данные об избирателях Москвы, актуальные на 1 июля, 1 января каждого года, даты проведения выборов и довыборов.

Таким образом, несмотря на то, что в целом в базовых автоматизированных системах, содержащих данные о населении Москвы, накоплены значительные объемы актуальных данных, функциональное назначение эксплуатируемых автоматизируемых систем, а, следовательно, и содержащиеся в них данных, не позволяют пока рассматривать их как основу интегрированного банка данных “Население” г. Москвы.

АСУ “Население” Москвы и Московского региона Главного управления внутренних дел разрабатывается с 1991 года. В системе к настоящему моменту накоплены данные о прибытии, убытии, рождении и смерти более 75 процентов жителей Москвы и Московского региона, что составляет 20 млн. записей. База данных о населении ГУВД создана, в основном, за счет централизованного ввода данных операторами с ежедневным объемом ввода 6 - 8 тыс. записей. Сквозная актуализация данных через автоматизированные рабочие места сотрудников паспортных служб ОВД и паспортных столов ДЕЗ районов нижнего уровня практически не отлажена. Попытки разработчиков внедрить АРМ нижних уровней в Восточном административном округе потерпели неудачу из-за ошибок в пакетах программ автоматизированных рабочих мест (АРМ) паспортиста ДЕЗ и отдела милиции. Эти пакеты программ не отвечали функциональным обязанностям паспортистов, не учитывали требований приказов и распоряжений ГУВД г. Москвы.

АСУ “Население” Москвы и Московского региона (АСУН ГУВД) по своей архитектуре является закрытой системой, трудно интегрируемой с общегородскими автоматизированными системами, содержащими данные о населении. Так, например, АСУН ГУВД не интегрированна с общегородской базой данных “ЗАГС”, являющейся источником актуализации информации по рождению и смерти граждан Москвы. Ежегодный объем актуализации по данным ЗАГС составляет около 800 тыс. записей с учетом измененных и дополненных актовых записей, что приблизительно равно трехмесячному объему актуализации данных в АСУН ГУВД. Значительная трудоемкость ежедневного ввода и актуализации данных приводят к неактуальности АСУН ГУВД. Так, например, проверка АСУН ГУВД по репрезентативной выборке данных о смерти граждан показала, что только 30 процентов данных являются актуальными, а дата смерти в актуальных записях точна только в части года.

Создание интегрированного банка данных “Население” Москвы является сложной задачей как организационно, так и технологически. Регистрация населения производится на более 800 участках Дирекций единого заказчика 125 районов Москвы. В ДЕЗ Москвы внедрено более 15 различных пакетов прикладных программ паспортного учета граждан, основными достоинствами которых является функциональная адекватность текущим процессам регистрации граждан и работоспособность. К недостаткам внедренных прикладных программ паспортного учета граждан ДЕЗ можно отнести отсутствие единой системотехнической платформы разработок, требований к составу реквизитов базы данных о населении участка ДЕЗ, справочников и классификаторов, контроля вводимых данных. Указанные недостатки приводят к значительным трудностям при интеграции данных ДЕЗ с данными паспортных столов милиции.

Пакеты прикладных программ паспортного учета в ДЕЗ внедрены, как правило, на компьютерах типа PC/486, в некоторых случаях на ранних моделях Pentium, сами прикладные программы реализованы на средствах разработки начала 90-х годов, не обеспечивают поддержки современных операционных систем и пользовательских интерфейсов, полного решения проблемы 2000. В связи с последствиями экономического кризиса, в ДЕЗ имеются финансовые трудности переоснащения существующего парка вычислительной техники. Работоспособность и функциональная адекватность внедренного программного обеспечения регистрации граждан в ДЕЗ делают бессмысленным для руководителя ДЕЗ вопрос о переходе на современные и интегрируемые аппаратно-программные средства регистрации граждан.

На основании выше изложенного краткого анализа можно сделать следующие выводы.

    1. Общегородские автоматизированные системы МАИС “ЗАГС”, РАСОИ “Соцзащита” и ГАС “Выборы” по г. Москве содержат актуальные данные о значительной части населения Москвы, но функционально не предназначены для регистрации и учета всех категорий граждан.
    2. АСУН ГУВД Москвы и Московского региона по своему функциональному назначению должна содержать актуальные данные о населении, но в связи с технологическими недоработками является неактуальной и уже более 10 лет внедряется в эксплуатацию.
    3. Внедрение автоматизированного интегрированного банка данных “Население” Москвы требует решение большого количества технологических и организационно-финансовых проблем на беспрецедентном количестве объектов автоматизации.

Предлагаемый путь разработки и внедрения АИБД “Населения” Москвы

Наиболее важным принципом, сформулированным Московским комитетом по науке и технологиям, влияющим на создание АИБД “Население” Москвы, является разработка и внедрение системы снизу вверх, т.е. опережающие разработка и внедрение модулей нижнего уровня и обеспечение основ для сквозной актуализации данных в модулях верхнего уровня уже на этапе опытной эксплуатации. Такая методология была использована при разработке и внедрении крупнейших автоматизированных систем Москвы, содержащих данные о населении: Многоуровневой автоматизированной системы “ЗАГС” Москвы и Государственной автоматизированной системы “Выборы” в части учета избирателей Москвы. Эти системы были внедрены в промышленную эксплуатацию через три года после начала разработки, в опытную эксплуатацию в промышленном режиме через шесть месяцев.

К сожалению, АСУН ГУВД Москвы разрабатывается с использованием противоположной методологии: сверху вниз. Это привело к тому, что многомиллионная база данных “Население” ГУВД не является актуальной после 10 лет разработки. Система до сих пор не внедрена в эксплуатацию, тратятся значительные средства налогоплательщиков – граждан Москвы на постоянный централизованный ввод карточек регистрации граждан. Не внедрены автоматизированные системы по учету населения административного округа и паспортного стола отдела милиции.

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

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

Анализ автоматизированных систем объектов нижнего уровня – паспортных столов участков ДЕЗ показал, что, с одной стороны, в них внедрены работоспособные и полнофункциональные автоматизированные системы, а с другой стороны, внедренные автоматизированные системы не могут быть интегрированы в глобальную систему по причинам, приведенным в разделе 2 статьи.

Каков же выход из сложившейся ситуации – ведь переоснащение участков ДЕЗ и внедрение на них единого интегрируемого программного обеспечения приведет к значительным затратам временных и финансовых ресурсов и отодвинет задачу создание интегрированного банка данных “Население” Москвы еще как минимум на пять лет? Для решения таких проблем в мировой практике используются многоуровневые интерфейсы информационного взаимодействия. Стоимость таких интерфейсов составляет 5 - 10 процентов от стоимости разработки интегрируемой системы.

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

Таким образом, внедрение автоматизированной технологии информационного взаимодействия паспортных столов милиции и паспортных столов ДЕЗ, создаст основу для автоматической актуализации базы данных “Население” паспортного стола района Москвы.

Для поддержания БД “Население” паспортного стола района милиции в актуальном состоянии отдельно необходимо рассмотреть процессы интеграции с общегородской базой данных “ЗАГС” (ОБД “ЗАГС”). Последняя регистрирует изменения гражданского состояния населения Москвы, в частности рождение и смерть граждан. Интеграция с ОБД “ЗАГС” позволит сотрудникам паспортного стола отдела милиции решить такие задачи, как:

Интеграция с ОБД “ЗАГС” значительно повышает уровень актуальности БД “Население” паспортного стола милиции. Несоответствие структур управления паспортными столами милиции и отделами ЗАГС Москвы, а также законодательные основы регистрации акта гражданского состояния о рождении и смерти определили технологию интеграции систем. Так как рождение и смерть регистрируются в 70 процентах случаев по месту жительства, а в 30 процентах случаев по месту рождения или смерти, полные данные об этих событиях содержатся только в общегородской базе данных “ЗАГС”.

Интеграция с районной базой данных “Учет потенциальных избирателей” обеспечит автоматическое поддержание последней в актуальном состоянии. Внедрение такой технологии позволит автоматически получать актуальные списки избирателей на любую дату. АИБД “Население паспортного стола района должна являться источником актуализации АИБД “Население” административного округа.

АИБД “Население” административного округа должна являться источником актуализации АИБД “Население” Москвы. Структурно-функциональная схема АИБД “Население” административного округа на примере Восточного административного округа Москвы приведена на рис. 1.

Требования к интерфейсу информационного взаимодействия автоматизированных систем “Паспортный стол милиции” – “Паспортный стол ДЕЗ”

Межсистемный интерфейс информационного взаимодействия должен описывать все события, возникающие при регистрации граждан по месту жительства и по месту пребывания. В составе интерфейса информационного взаимодействия, разработанного инженерно-внедренческим центром “Инсофт”, описаны следующие события:

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

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

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

По окончании сеанса информационного взаимодействия автоматически формируется протокол информационного взаимодействия с описанием причин отказа регистрации отдельных событий. Каждый протокол содержит информацию о паспортистке ДЕЗ, подготовившей данные, о паспортистке отдела милиции, осуществлявшей ввод данных, дате формирования протокола, номере участка ДЕЗ, отдела милиции. В соответствии с принятым регламентом протокол информационного взаимодействия хранится в системе 6 месяцев.

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

При регистрации жителей ведомственного жилья и общежитий в программном обеспечении предусмотрены специальные процедуры для ввода и контроля данных с клавиатуры.

Описание реляционной модели автоматизированного интегрированного банка данных “Население”

Структурная схема реляционной модели АИБД "Население" изображена на рис.2.

Модель включает три логических элемента: таблицы классификаторов, данных и журналы информационного взаимодействия.

На современном этапе разработки системы к таблицам классификаторов и справочников отнесены следующие:

На современном этапе разработки системы к таблицам данных о жителей и жилом фонде отнесены следующие:

На современном этапе разработки системы к журналам информационного взаимодействия отнесены следующие:

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

Реляционная модель является открытой и не должна претерпевать изменений при подключении дополнительных субъектов – источников и пользователей информации. Изменению должны подлежать только журналы информационного взаимодействия и классификаторы в части их альтернативного описания в интегрируемых системах.

Эти свойства предложенной реляционной модели данных значительно снижают стоимость разработки и эксплуатации АИБД “Население”.

Описание методологии альтернативных понятий классификаторов

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

Сложность в однозначном описании и идентификации этих объектов состоит в том, что в паспортах граждан подчас одной и той же квартиры присутствует различное описание улицы или адреса. Особенно это характерно для жителей центральных и окраинных районов Москвы. Так, например, в моем паспорте и паспорте моего сына, выданном на 10 лет позже, улица и дом описаны по-разному в связи с их переименованиями.

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

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

В настоящее время выявлены и внесены в классификатор более 500 альтернативных описаний для Москвы. При формирования альтернативного описания для него ведется базовое описание, источник формирования альтернативного описания, дата и номер документа, на основании которых сформировано альтернативное описание.

Технология альтернативного описания объектов классификации может быть использована и при описании российских объектов административно-территориального деления, стран мира и т.д.

Объединение баз данных в АИБД “Население” и проблема поддержания единого идентификационного кода гражданина

При актуализации окружной АИБД “Население”, загрузке данных автоматизируемых районов возникает проблема однократного описания гражданина, уже описанного в базе данных. Это происходит в следующих случаях.

Например, объектом первой автоматизации является район “Гольяново” Москвы. Гражданин был зарегистрирован в районе “Гольяново” и затем выехал в район последующей автоматизации. В этом случае гражданин может попасть в базу данных с другим идентификационным кодом и будет учтен дважды. Для однократного учета граждан разработаны специальные технологии обратной связи с АИБД “Населения” для уровня паспортного стола милиции. При актуализации или дозагрузке АИБД “Население” уровней округа (впоследствии города) задействуется специальная процедура поиска возможных двойников и синхронизации идентификационных номеров граждан. Идентификация граждан на первом этапе осуществляется по полному соответствию фамилии, имени, отчества, даты рождения, адреса места жительства, периода регистрации, на втором этапе по предыдущим значениям фамилии, имени и отчества.

Предложенный механизм не является универсальным и может давать сбои в следующих случаях. При изменении адреса места жительства (например, на другой субъект Российской Федерации) и фамилии, имени или отчества, а затем повторной регистрации в АИБД “Население” гражданин принципиально может быть учтен дважды. Полное совпадение фамилии, имени и отчества, даты рождения и места рождения также не является абсолютно уникальным.

Так, например, при загрузке АИБД “Население” Восточного административного округа и ее интеграции с ОБД “ЗАГС” был выявлены дети – двойники, имеющие одну и ту же фамилию, имя, отчество, дату рождения и место рождения (в данном случае Москва). Следует отметить, что дети были зарегистрированы в разных отделах ЗАГС, в разные даты и разными актовыми записями.

Однако в отсутствии законодательства и практики применения единого гражданского кода в России, предлагаемая технология идентификации является единственной и дает идентификацию 98 – 99 процентов.

Для выявления возможных двойников в АИБД “Население” разработана технология поиска похожих записей.

Первичная загрузка данных

Первичная загрузка данных из автоматизированных систем участков ДЕЗ является важным этапом создания АИБД “Население”. Основной проблемой первичной загрузки является правильное распознавание и целостное описание данных ДЕЗ по всем событиям, зарегистрированным в ДЕЗ.

При информационном взаимодействии с базами данных ДЕЗ, созданными различными разработчиками, приходится сталкиваться с отсутствием какого-либо системотехнического подхода к формированию данных. В большинстве баз данных отсутствуют данные о рождении детей, смешиваются события прибытия, первичного получения паспорта, смены документа. Отсутствие каких-либо собственных классификаторов причин прибытия – убытия, родственных отношений приводит к тому, что при миграции данных приходится разбираться с целыми “сочинениями” в символьных полях.

Типичной ошибкой разработчиков автоматизированных систем ДЕЗ является невнимание к логическому контролю данных. Так, например, в базах существует до 20 вариантов написания данных о смерти при выбытии по смерти, в поля места рождения заносятся причины прибытия – убытия и т.д.

Для обеспечения целостности первично загруженных данных используются следующие методы выравнивания данных.

    1. Построение альтернативных описаний адресов места жительства.
    2. Получение статистик по повторяемости причин прибытия – убытия, смены паспорта, родственных отношений, их соотнесение с базовым описанием справочников.
    3. Итерационные процедуры переноса и преобразования данных, переданных в соответствии с неправильными реквизитами.
    4. Интеграция с ОБД “ЗАГС”, содержащей 12 млн. выверенных записей, для дополнения данных АИБД “Население”.
    5. Формирование поля “Место рождения – Москва” по информации ЗАГС.

Процедура первичной загрузки не является стандартизованной. Как правило, первичная загрузка данных одного района Москвы занимает от 1 до 2 недель.

Информационное взаимодействия с общегородскими автоматизированными системами “ЗАГС” и “Выборы”.

Информацинное взаимодействие с общегородской системой “Выборы” осуществляется на уровне района Москвы. Данные для внесения изменений в БД “Учет потенциальных избирателей района” формируются в автоматическом режиме с заданной системным администратором ГАС “Выборы” переодичностью. В случае, если системный администратор сомневается в актуальности базы данных “Учет потенциальных избирателей” за заданный промежуток времени, он может сформировать файл информационного взаимодействия за этот промежуток.

Данные поступают в КФЗ “Учет избирателей” в соответствии с режимом “Взаимодействие с АСУ “Население” (АСУН)”. Автоматическая обработка месячных изменений занимает не более 10 минут. Далее в соответствии с технологиями ГАС “Выборы” производятся профилактические процедуры данных и строится дефектная ведомость информационного взаимодействия.

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

Информационное взаимодействие с МАИС “ЗАГС” осуществляется аналогичным образом. Результатом взаимодействия является внесение изменений по рождению и смерти в АИБД “Население” по информации ЗАГС. При этом делается различие между датами рождения и смерти и регистрации этих событий в паспортных столах милиции. Анализ информационного взаимодействия показал, что между регистрацией этих событий органами ЗАГС и паспортными столами милиции может пройти до 5 лет.

Информационное взаимодействие с автоматизированными системами, содержащими данные о населении.

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

Интеграция с паспортным столом милиции и отделом ЗАГС покрывает 95 процентов субъектов – источников данных. Незначительными по объемам субъектами – источниками данных являются автоматизированные системы Городского военкомата, содержащие данные о призыве и возвращении с военной службы, и автоматизированные системы судов, содержащие данные о признании граждан недееспособными.

Информационное взаимодействие с военкоматами и судами предполагается реализовать на этапе разработки

Информационное взаимодействие с субъектом – пользователем данных технологически должно осуществляться через журналы информационного взаимодействия по согласованным сторонами протоколам и регламентом. Юридические аспекты возможности передачи данных в настоящей статье не рассматриваются.

Заключение

Описанные в статье технологии создания АИБД “Населения” по заказу МКНТ Москвы апробированы на районах Восточного и Южного административного округов.

С демонстрационными версиями АИБД “Население” Москвы можно ознакомится на www.insoft.ru.

Буду признательна за любые Ваши отзывы на мою статью. Мой адрес ev@insoft.ru