• 450098 г.Уфа
  • ул. Российская 157/2

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

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

Версия: 1.0

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

Назначение

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

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

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

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

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

 

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

 

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

 

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

 

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

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

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

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

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

 

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

 

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

 

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

 

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

 

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