Организация адресного реестра

Организация адресного реестра

Статус: Сертифицировано DIRECTUM

Версия: 1.0

Платформа: DIRECTUM 4.5.1 — 5.0

Назначение

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

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

Наиболее типичные проблемы при работе с адресами следующие:

• Качество данных вводимой информации. Без структуризации операторами могут допускаться ошибки формирования наименования. Например, полное наименование улицы – «Улица Мажита Гафури». Однако оно может некорректно записываться и как «М. Гафури». Такая информация в текстовом поле усложняет поиск данных и проверки дубликатов. При этом практически отсутствуют инструкции по унифицированному вводу адресных данных.
• Разграничение прав ведения адресных данных. Текстовые поля не позволяют разграничивать права доступа. Зарекомендовавшая себя схема – выделение улиц, городов и т.д. в отдельные справочники – позволяет вести сами наименования ответственным оператором или администратором, а адреса – обычным пользователям. Это устраняет проблему корректности наименований.
• Адресная информация не является прямой информацией объекта. Как правило, наименования улиц выносятся в справочник, а адресная информация о расположении находится у объекта. Это проблематично, если у персоны более одного адреса или у организации не совпадают почтовый и юридический адрес.
• Неконтролируемое распространение адресной информации. Например, несколько персон проживает по одному адресу. Если не выделять адресный реестр, у каждого человека будет «свой» адрес, хотя в действительности адрес один и тот же (если оператор вводит все строго по шаблону). Такая ситуация не позволяет, к примеру, автоматически работать в рамках одного адресного пространства. Другой пример: при переезде компании и соответствующей смене адреса в рамках адресного реестра легко автоматизировать арендные данные по адресу. Поскольку договор прикреплен к адресу и сама организации имеет адрес из адресного реестра, связка будет идти по одному справочнику, что устраняет дублирование и неконтролируемые адресный данные.
• Проблема переименования адресных элементов (например, улиц). Если улица выделена в отдельный справочник, то проблема решается легко. Если же улица пишется в текстовом поле, решить проблему актуальности наименования будет сложнее.
• Проблема учета территориальных и административных делений. Рассмотрим адреса «РФ Республика Башкортостан город Уфа улица Ленина дом 5» и «РФ Республика Башкортостан город Уфа Кировский район улица Ленина дом 5». Первый адрес является почтовым, а второй специфичный для некой системы. Кировский район – это административное деление, которое к самому адресу не имеет отношение. Частных решений таких ситуаций несколько, ниже будет рассмотрен подход в рамках иерархического адресного реестра.
• Иерархичность данных. Распространенный подход для обеспечения иерархичности данных заключается в создании отдельных, связанных между собой, справочников, «Страна», «Регион», «Город», «Поселок», «Улица». Однако такое деление не дает гибкости. Например, рассмотрим два адреса: в одном город является региональным («РФ Респ. Башкортостан г. Уфа ул. Малая Кольцевая д. 180-3»), в другом — город не региональный («РФ Респ. Башкортостан р-н Ишимбайский г. Ишимбай ул. Космонавтов д. 6-118»). У города Ишимбай есть «родительский» район. То есть эти адреса уже различаются количеством адресных элементов, но жесткая структура неиерархического адреса с трудом позволяет отображать это различие.
• Переоформление адресных территориальных единиц. Например, прилегающее поселение, деревня и т.д. входят в состав расширяющего города, или наоборот — город обрастает подчиненными областями. В системе необходимо корректно переоформить адреса. Если данные не иерархичные, то придется постараться с конвертерами. При иерархичных данных никаких дополнительных операций делать не нужно.
• Уникальность наименование улиц. Очень часто наименование улицы повторяется в различных населенных пунктах (например, улица Ленина). Иерархичность позволяет однозначно по одному адресному элементу идентифицировать всю адресную ветку.
• Проблема наименования видов адресных элементов. Часто возникают проблемы, когда улица в действительности является проспектом, бульваром или площадью, и это отражается в названии. При иерархическом адресном реестре трудностей с такими объектами не возникает.
• Интеграция данных. Четкое определение адреса позволяет значительно упрощать процесс взаимодействия.

Для решения обозначенных проблем был разработан иерархический адресный реестра. Иерархический адресный реестр призван:

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

Описание компоненты

Иерархический адресный реестр состоит из двух основных понятий: Адресный элемент и Адресный реестр

 

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

 

Поясним на примере. «Улица Ленина», где «Улица» – это вид адресного элемента, а «Ленина» – непосредственно сам адресный элемент. У адресного элемента есть понятие Признак адресного элемента. Он характеризует, является ли адресный элемент образующим адресный реестр или нет. Например, «Респ. Башкортостан» – является не образующим элементов. То есть адрес не может быть вида «Респ. Башкортостан д. 180-3». «Улица» – является образующим адресным элементом. Образующим адресным элементом может быть и деревня, село, поселок в силу малонаселенности при отсутствии улиц.

 

Адресный реестр – это совокупность адресных элементов с адресной информацией о расположении. Например, «РФ Респ. Башкортостан г.Уфа ул. Малая Кольцевая д. 180-3».

 

Компонента «Адресный реестр» состоит из справочников:

• Адрес;
• Вид адреса;
• Адресный элемент;
• Вид адресного элемента;
• Фильтр поиска адреса.

Используются следующие стандартные справочники:

• Персоны;
• Организации.

Пример использования компоненты

 

В качестве примера реализации в DIRECTUM рассмотрим следующие модификации.

 

Для справочника Персоны разработана модификация для работы с адресным реестром. Строковое наименование формируется строго по шаблону, поэтому все наименования четко формализованы и оператор не имеет возможности «вмешиваться» в формирование адресной строки.

 

Данные по адресным элементам ведутся администратором, а сами адреса непосредственно операторами.

 

Форма поиска/фильтра доработана таким образом, что при вводе новых данных (которых еще нет в адресном реестре) система автоматически на основе введенных данных предлагает создать запись в адресном реестре. Заключение

 

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