Приходит заказчик и говорит: «Мы новую систему строим, проконсультируйте нас, пожалуйста. Вы же адресами занимаетесь. Нам нужно сделать универсальную адресную модель. Вот у вас «Единый адрес» есть, какая там модель адреса? Мы примем ее за эталонную и будем в своих системах использовать».
Ребята, я вас сейчас разочарую. В «Едином адресе» не одна адресная модель, а несколько. И ни одну из них копировать просто так не нужно.
Эта статья для архитекторов, аналитиков и разработчиков. В ней я расскажу, в чем подводные камни в работе с адресами и что нужно учитывать при проектировании адресных моделей.
Вводная информация по адресам. Что такое адресная модель
Основной справочник адресов России — Государственный адресный реестр (ГАР), его ведет Федеральная информационная адресная система (ФИАС). Заведует всем этим ФНС. Как устроен ГАР, мы разбирали в этой статье.
Адресный объект — конкретный узел дерева адресов, запись в справочниках ГАР (ФИАС).
К адресным объектам относятся дома, квартиры, населенные пункты. У каждого из них есть свой набор характеристик — тип, значение, коды по классификаторам, например КЛАДР-код, ФИАС-GUID, идентификаторы ГАР, ОКАТО, ОКТМО, история переименований и т.д.
Адрес — это способ текстом указать цепочку адресных объектов, которые идентифицируют конкретный объект-узел. Адрес рассказывает, как по дереву добраться до конкретного объекта.
Например:
адресный объект — «офис 401»,
адрес — «Турчанинов пер, д 6 к2, офис 401».
Иерархичность. Большая часть узлов дерева адресов имеют «родителей» и «детей». Например, «родитель» всех московских улиц — Москва, а «дети» Ленинского проспекта — все стоящие на нем дома.
Иерархия адресных объектов не едина. Существуют административное и муниципальное деления, и один и тот же адрес в них выглядит по-разному.
Адресная модель — это структура данных, используемая для хранения, обработки и анализа адресной информации. Она определяет, как элементы адреса (например, страна, регион, город, улица, дом, квартира) организуются и взаимодействуют друг с другом.
На основе ГАР можно строить различные адресные модели, так как он содержит и сами адресные объекты, и дерево адресных объектов в административном и муниципальном делениях, и характеристики адресных объектов.
На первый взгляд, идея создания универсальной модели адреса, которая могла бы использоваться и в СRM, и в аналитических системах, кажется привлекательной. Однако на практике такой подход несет больше проблем, чем пользы. Адресная модель сильно зависит от бизнес-процессов. Вот примеры.
Если речь идет о доставке, принципиальна геопозиция (координаты) клиента. Эти данные позволяют ответить на вопросы, работает ли компания с конкретной территорией, доедут ли туда автомобили и курьеры.
Для IT-систем в этом случае важна не столько гранулярность хранения региона, города, сколько отдельные геокоординаты. Понадобятся и другие сведения — подъезд, этаж, код от домофона или хитрые комментарии (как пробраться мимо шлагбаума, охранников или цепных собак). При доставке курьер ориентируется именно на геокоординаты, а адрес выполняет лишь вспомогательную функцию, если нужно уточнить дорогу. При этом в логистических документах адрес доставки должен быть прописан. А еще он нужен аналитикам — например, чтобы посчитать, какие направления самые популярные.
Если говорить о работе с объектами недвижимости и расчете страховки для них, адрес — обязательная штука. Человек хочет застраховать дом, который стоит в зоне ежегодного подтопления? Адрес будет влиять на страховой коэффициент. При детальном описании объекта недвижимости рядом с адресом появляются и другие характеристики — материал стен, год постройки, природные факторы риска и так далее.
Есть ситуации, когда ИТ-система должна хранить не просто адрес, а адрес регистрации строго по паспорту (да, даже если улицу успели переименовать). Например, если человек оформляет кредит или услугу по предоставлению связи или Интернета.
Кому-то важны ОКАТО и ОКТМО. Так бывает, когда требуется фильтрация различных адресных выборок по наличию кодов. Сам адрес тоже может храниться, но на процессы будет влиять именно классификатор.
Вывод: требования к хранению адресов зависят от сценариев, в которых они используются. Где-то важна верхняя часть адреса (страна, регион, населенный пункт), а где-то «последняя миля».
Почему идентификатор ГАР не панацея
Погруженный в тему читатель возразит: зачем вообще все эти разговоры про адресные модели, если можно взять идентификаторы ГАР (ФИАС) и жить не тужить? Но — увы! — они работают далеко не всегда.
Проблемы, которые возникают при использовании GUID — уникального идентификатора ГАР (ФИАС):
1. Реестр не включает 100% адресных объектов России. В проектах мы встречали дельту в размере примерно 10% домов, которые в ФНС отсутствуют, а наши клиенты ногами своих сотрудников их собрали. Речь, как правило, о новых домах, которые еще не успели внести в реестр.
2. Идентификаторы не всегда стабильны. Например, Железнодорожный переехал в Балашиху, и все GUID полностью изменились. История изменений адресного объекта оказалась утрачена (да, такое бывает редко, но сбрасывать со счетов нельзя).
3. Формат идентификаторов ФНС может меняться со временем, как и формат справочника. Сначала был КЛАДР с кладр-кодами, потом появился ФИАС с GUID, теперь есть ГАР, в котором есть и GUID, и новые идентификаторы ГАР.
Кроме того, не у всех объектов реального мира есть адреса и идентификаторы в принципе: иногда бизнес работает с объектами, которые привязаны к ближайшему адресу, но идентифицируются геоточками.
Допустим, все тот же погруженный в тему читатель знает подводные камни ГАР и готов с ними мириться. Но особенность иерархической модели ГАР в том, что в ней существуют два деления — административное и муниципальное, и бизнесу в зависимости от процесса надо выбирать, как сформировать строку адреса. Плюс в ГАР нет характеристик, критичных для многих компаний, — например, геокоординат.
А что, если развернуть иерархический ГАР в плоскую структуру? Сделаем это один раз и заживем? Что ж, счастливы вы будете ровно до первого переименования улицы, города или их переподчинения (вспомним, как объекты Московской области резко стали Новой Москвой). После этого придется актуализировать информацию во всех системах.
Что учесть при проектировании адресной модели?
Часто на переговорах слышим: давайте тогда спроектируем модель, учитывающую все возможные сценарии использования данных. Пусть она будет одинаково полной и пусть ее используют все системы. Да, сделать такое можно. Но такая модель будет очень громоздкой. И часть систем, которые хранят адреса, будут сталкиваться с оверхедами, которые она накладывает.
Чтобы построить полезную и удобную для бизнеса адресную модель, вам предстоит ответить на такие вопросы:
1. Какие задачи решает система, которая будет работать с адресными данными?
2. Какой набор атрибутов адреса нужен для решения этих задач? Например, для скоринга достаточен уровень региона, для доставки нужны геокоординаты и точность до квартиры, для аналитики — сегментация по городам или районам. Иногда и вовсе достаточно минимального общепринятого набора полей, а подробности не нужны.
3. Какие дополнительные атрибуты могут понадобиться — сейчас или в перспективе?
Среди таких атрибутов — этаж, подъезд, код домофона, шлагбаум и др. Пример: установщикам оборудования и инженерам телеком-компаний важно знать материал стен — так они возьмут нужный инструмент. Для логистических служб важна высота домовой арки, чтобы отправить к клиенту подходящую по размеру машину.
4. Все ли атрибуты надо хранить в модели или можно получать их в моменте из другой системы или справочника?
При ответе на этот вопрос учтите: есть внутренняя модель хранения адреса, а есть публичные интерфейсы для систем-потребителей. Если система не хранит атрибут, но он нужен бизнес-потребителям, решите, как вы его будете получать. И нужно ли расширять вашу модель под хранение этого атрибута?..
5. Если работаете с адресами, то в каком виде их нужно получать или хранить?
Допустим, в форме доставки в поле «город» человек пишет «СНТ Ромашково». Никто не пострадает, Ромашково будет найдено. А вот для учетных, доходных и расходных систем, где важен тип объекта, не подойдет простая плоская табличка «город, улица, дом, квартира». Здесь уже требуется модель, в которой есть объект и его тип (подвал, домовладение, здание и др). А когда адресные данные нужны для отчетности, требуется формат ФНС с административным и муниципальным делением. Выберите, какое из них нужно вам (бывает, что и то, и другое).
Нужны ли адреса одной строкой?
Рекомендуем сохранять исходный адрес одной строкой, как его ввел человек. Не стоит обязывать клиента гранулировать адрес. Если вы можете ему в этом помочь (например, предоставив подсказки в форме ввода) — прекрасно. Если нет, дайте возможность ввести адрес строкой. В дальнейшем вы можете разложить адрес на компоненты: глубина обработки определяется теми сценариями, в рамках которых планируете работать с адресом.
6. Как будет выглядеть процесс актуализации — например, если переименована улица или населенный пункт? Как часто это будет происходить?
Почему важно хранить идентификатор адресного объекта из ГАР?
Мы рекомендуем хранить идентификатор адресного объекта из ГАР, потому что именно по нему вы сможете найти и актуализировать объект в случае его переименования.
Варианты хранения идентификаторов:
Идентификатор конечного адресного объекта. Например, в адресе «Москва, Ленинский проспект, д. 41/2, кв. 289» можно хранить только идентификатор квартиры — 61af3e15-be8c-42bb-b79a-f060c3b1d796. Нюанс в том, что, как я уже рассказала, не у всех реально существующих объектов может быть идентификатор из справочника.
Отдельно хранить идентификатор адресного объекта до домовой части (населенный пункт или улица). В нашем примере это идентификатор Ленинского проспекта — 5f2a1243-a57b-418e-baee-ff76f4993b45. Также отдельно сохранять идентификаторы дома и квартиры — при наличии этих объектов в справочнике;
Хранить идентификаторы каждого узла отдельно — регион, населенный пункт, улица. Здесь нюанс в том, что могут появляться новые уровни. Вспомним, что когда-то в ФИАС появился 65-й уровень «планировочная структура», которого не было в КЛАДР.
И еще одна деталь: поскольку у объекта не всегда есть идентификатор, стоит добавить признак «адрес однозначно сопоставлен со справочником».
Напомню, что помимо идентификатора нужно сохранять исходный адрес. И не трогать его! Актуализированный или стандартизированный адрес, если такой появится, храните в отдельных полях. Дело в том, что иногда бизнесу нужно именно то написание адреса, которое было актуально на момент заключения договора или оказания услуг — вспомним Ленинград и Санкт-Петербург, Ростов и Ростов Великий.
7. Как хранить тип объекта и его значение?
Тут возможны варианты. Кто-то делает отдельные общепринятые поля — город, улица, дом и так далее. А кто-то хранит в виде «ключ-значение», где в качестве ключа выступает тип объекта (село, СНТ, деревня и т.д.). Подробно о типах объектов рассказывали в этой статье.
Как хранить домовую часть, и почему это нетривиальная история
Домовая часть хранится в шести полях — три под тип и три под значение. И все это может быть знатно перемешано. Мой совет: если задачи сегментировать нет, кладите данные в одно поле. А если есть, то продумайте, как будете хранить домовую часть. В отдельных полях, которые уже названы (дом, корпус, строение, владение)? Или все помещать в поле «тип-значение», так как есть еще домовладение, участок, подвал, гараж…
Хранить домовую часть можно так:
-
Отдельно поля под типы, отдельно под значения (как в ГАР). Если у вас есть отдельный справочник типов, то вместо полного и краткого типа сохраняйте референс из справочника. В такой модели хранения учтены все возможные типы, но при обмене данными между системами не все будут готовы, что может приехать тип «гараж» или «шахта», если, конечно, такие данные у вас есть. Поля: typeShort — сокращение типа; typeFull — полный тип; value — значение; type2Short — сокращение типа-2; type2Full — полный тип-2; value2 —значение-2; type3Short — сокращение типа-3; type3Full — полный тип-3; value3 —значение-3.
Например, дом с идентификатором fa3e1bf0-4834-40e2-a31e-3a980dcb67bb — г. Санкт-Петербург, Гражданский пр-кт, д. 31 к. 4 литера А
Именованные поля. Просто для интеграций, но сложнее при появлении нового типа (например «гараж»). Придется добавлять новое поле в модель и предупреждать интеграции. Примеры: house, vladenie, zdanie и др.
Все складываем в поле «дом». Просто для интеграций, но сложно унифицировать потоки данных из разных систем. Например, одна система передает полные типы, и вы сохраняете «дом 41/2, корпус 2». Вторая система передает краткие типы «д.41/2, к.2», а в третьей человек вводил руками без подсказок и получилось «дом №41/2 корп.2». В таком случае для сопоставления и аналитики данных без стандартизации или идентификаторов не обойтись.
В наших моделях в «Едином адресе» используется первый и второй варианты. Плюс мы храним идентификаторы объектов. Если вам не нужно гранулировать поля, но есть возможность хранить домовую часть отдельно, то облегчите себе жизнь: сложите все в одно поле и сохраните идентификатор из справочника при его наличии.
8. Если решено хранить адрес, то достаточно ли только типа и значения или нужен еще и уровень объекта? Например, Москва имеет уровень «регион», так как это город федерального значения.
Ограничения и другие нюансы
Обратите внимание, какие ограничения для хранения адресной информации есть в системе, для которой вы проектируете модель. Мы встречали коробочные решения, в которых модель адреса была фиксирована и расширение было невозможно или минимально. Например, номер дома предполагал хранение только цифр. Чтобы сохранить дробное значение углового дома ( д. 41/2), требовалось отдельное поле с названием «дробь».
Проанализируйте, как именно хранятся адреса в системах, которые будут для вашей источником или потребителем данных. Какие атрибуты и для каких процессов необходимы им? Как хранятся адреса в источниках данных? Допустим, вы решите хранить адрес в формате ГАР, а в качестве источника будет CRM, где адрес хранится одной строкой. В таком случае стоимость интеграции по преобразованию данных может быть сопоставима с разработкой модели.
Итак, проектирование адресных моделей в системах зависит от:
бизнес-процессов и задач, для которых эта система необходима,
возможностей системы;
интеграций.
И главный итог: если можно чего-то не делать, не делайте. Чем проще, тем лучше. Но строка исходного адреса или описание объекта плюс идентификатор конечного узла адресного объекта из справочника — это минимум для комфортной жизни.
А вы какие подходы используете при проектировании адресных моделей? Делитесь в комментариях!