Основные проблемы адресации

Содержание
Введение .........................................................................................................................................2
Основные проблемы адресации ...................................................................................................3
Не качественное исполнение своих обязанностей работниками кадастровой палаты.......3
Межевание и слияние земельных участков ............................................................................3
Садовые участки, в составе садоводческих товариществ .....................................................4
Строящиеся объекты .................................................................................................................4
Пристройки и встроено-пристроенные секции ......................................................................4
Дубликаты адресов и здания с несколькими адресами .........................................................5
Ввода адресных данных о контрагентах, находящихся за пределами локальной
(подконтрольной) территории ..................................................................................................5
Изменения границ городской черты ........................................................................................6
Общесистемные проблемы ...........................................................................................................7
Синхронизация данных .............................................................................................................7
Применение каскадированных счётчиков...............................................................................8
Устаревшие реляционные подходы к проектированию информационных систем,
хранилищ и баз данных.............................................................................................................9
Отсутствие входного контроля данных.................................................................................10
Проблема трактовки понятий .................................................................................................10
Искажения понятий в российском законодательстве ..........................................................12
Преимущества централизованно-распределённых систем .....................................................14
Заключение...................................................................................................................................16
Автор: архитектор ЦКРД,
Альберт Гаилевич
системный аналитик, ведущий программист Шараев
Введение
В ходе дискуссий и споров относительно АСИ АР РФ возник вопрос о его необходимости
и целесообразности его введения. Также некоторыми участниками дискуссии
выдвигаются такие доводы как первичность координатных данных и вторичность
адресных данных.
Фактически все юридические документы содержат не координатное, а адресное указание
на объект. Да и в общем понимании все без исключения общаются общепринятыми
названиями (не считая сленговых или «народных» названий объектов). Такая форма
адресации является понятной и общедоступной. Координатная система не является ни
понятной, ни общепринятой. Фактически координатная система позволяет с помощью
соответствующих приборов и систем найти пространственный объект в пространстве. Но
такая система «идентификации» не может быть общедоступным ресурсом, так
предполагает наличие определённых приборов и знания систем и методов определения
координат в пространстве.
Есть мнение об идентификации элементов адресного реестра непосредственно
идентификаторами пространственных объектов.
Такое не возможно по нескольким причинам, одной из которых является фактически
отсутствие такого идентификатора. О каком отсутствии идёт речь? Многие линейные
градостроительные элементы (улицы) состоят из нескольких пространственных объектов.
Соответственно один адресный элемент может содержать в себе 2 и более
идентификатора пространственных объектов. Что совершенно не приемлемо для
современных реестровых информационных систем.
Необходимость в качественном и актуальном реестре адресов, конечно же, существует, и
заменить такой реестр пространственными данными о различных объектах невозможно.
Основные проблемы адресации
При попытке синхронизации данных из различных источников (КУМС, ГлавАрхитектура,
БТИ, УЖХ и др.) МУП МИТЦ столкнулось со следующей проблемой:
Как однозначно идентифицировать объекты недвижимости в различных ИС?
Тут же у всех участников возник ответ «по адресу!».
Далее МУП МИТЦ столкнулось с рядом проблем, касаемых адресации различных
объектов недвижимости в России в целом (и в г. Уфе в частности).
Основными проблемами стали:
 Наличие нескольких адресов у одного здания;
 Наличие одного адреса у нескольких зданий (или различных секций здания);
 Отсутствие адресов у строящихся зданий
 Отсутствие адресов у всех сооружений, в т.ч. и строений;
 Отсутствие адресов (почтовых) у земельных участков (зачастую земельным
участкам присваивают адрес, выданный зданию на этом ЗУ);
Перед МУП МИТЦ не ставились проблемы идентификации и хранения коммуникаций,
анализ таких данных не проводился, поэтому об этих проблемах в данном документе
упоминается вскользь.
Не качественное исполнение своих обязанностей работниками
кадастровой палаты
В частности нескольким различным земельным участкам (ЗУ), были выданы номера ЗУ с
нулями в младшей части мантиссы кадастрового номера. Такой номер ЗУ соответствует (и
идентифицирует) кадастровый квартал, а не конкретный ЗУ.
Проблема с невозможностью первичной идентификации ЗУ по кадастровому номеру.
Уточнение границ ЗУ производит МУ «Земельное агентство», а присвоение кадастрового
номера – кадастровая палата. Таким образом, на этапе создания первичного
информационного объекта в ИС ключевой информации, под которой можно было бы
идентифицировать объект, нет. Она выдаётся позднее на этапе регистрации ЗУ в КП.
Фактически кадастровый номер не является идентификатором земельного участка, а лишь
является некоторым «инвентарным номером», всегда зависящим от способа проведения
инвентаризации.
Технология, на которой основано ЦКРД позволяет иметь несколько идентификаторов
одного и того же объекта в различных ИС, но сопоставление информации в ЦКРД
производится по уникальным ключевым группам (например, ФИО и дата рождения для
физ. лиц), коих у земельных участков нет.
Межевание и слияние земельных участков
Межевание
Кадастровый номер сохраняется за одним из участков (при этом этот участок имеет новые
характеристики – фактически становится новым объектом недвижимости). Наличие
нового ЗУ со старым кадастровым номером не даёт понять о создании 2х объектов
правовых отношений, фактически такой номер обязан иметь время жизни, равное объекту
которому он принадлежит.
Слияние
Кадастровый номер берётся от одного из участков. Фактически новый объект
недвижимости сохраняет чужие идентификационные данные.
Хотя в некоторых случаях операцию слияния можно трактовать как «присоединение»
однородного объекта (ЗУ), что на первый взгляд не является чем-то особенным. Такие
операции не возможны на примере зданий и пристроек к ним, что будет
продемонстрировано далее.
Слияние и межевание ЗУ являются по своей сути стандартной проблемой миграции
объектов. Но бывают и миграции объектов «не стандартные», например, преобразование
строящегося здания в здание, здания в памятник архитектуры, или, к примеру, проекта
постановления в постановление.
Садовые участки, в составе садоводческих товариществ
Садовые участки зачастую номеруются порядковыми номерами, также очень часто в
нумерации используют «дроби». В ситуации, когда председатели садоводческих
товариществ меняются, чуть ли не каждый год, и каждый новый председатель выдаёт
новые садоводческие книжки и составляет новые карты садовых участков, номера
садовых участков не сохраняются. Садовые участки могут менять свои границы и номера,
владельцев, и об уникальном адресе садового участка можно забыть.
Для возможности хранения адреса садового участка было предложено следующее. В
частности в отделе регулирования земельных отношений КУМС г. Уфы было предложено
расширить состав обычного почтового адреса добавлением атрибутики «Номер квартала»
и «Номер участка», для получения возможности адресации садовых участков.
Данный подход полностью тождественен адресации ЗУ кадастровой палатой, за
исключением старшей разрядной сетки кадастрового номера, которую в данном случае
заменяет обычная почтовая адресация (а именно вместо 02:55:03 подставляется РБ, г. Уфа,
Кировский район)
Такой способ адресации аналогичен адресации зданий в некоторых городах России, где
младшим адресным элементом адресации является «Микрорайон», а фактическим
адресом объекта является внутриквартальный порядковый номер корпуса.
Строящиеся объекты
Зачастую адресуется адресом ЗУ на котором ведётся строительство (строительной
площадки). Понятно что после окончания строительства здание получает отмостку, и ЗУ
под ним обретает собственные черты. Происходит межевание ЗУ, а вместе с этим, кроме
проблем описанных выше, также проблемы присвоения почтового адреса данному
объекту или группе объектов (зачастую речь идет о сдаче в эксплуатацию
многосекционных домов, имеющих общую отмостку).
Пристройки и встроено-пристроенные секции
После окончания строительства и сдачи объекта в эксплуатацию, здание получает
почтовый адрес. Но зачастую единый почтовый адрес выдаётся группам зданий, или
целым промышленным или имущественным комплексам. Что не позволяет установить
соответствие адреса объекта с конкретным объектом недвижимости.
Фактически все секции и пристройки имеют отдельную «историю». Они строятся
отдельно от здания, сдаются в эксплуатацию позже, могут иметь отличные от основного
здания материал стен и этажность, т.е. имеют ряд уникальных характеристик, не
совпадающих с характеристиками основного зданиями (да хотя бы год ввода в
эксплуатацию объекта).
Пристройки к основным зданиям или секции не являются однородными объектами, и
имеют собственную атрибутику, и наносятся на карту отдельными объектами.
Поэтому идентифицировать объекты на карте для нескольких зданий/сооружений,
имеющих один адрес не представляется возможным.
Ещё хуже обстоят дела с пристроями, предназначенными для торговли или
предоставления услуг. Такие пристрои практически всегда имеют свои собственные
параметры (материал стен, этажность, год постройки), и всегда наносятся на карту
отдельным объектом. Но адрес при этом зачастую получают от основного строения.
Такие данные в данный момент не принимаются в ЦКРД ввиду отсутствия в них
достаточной ключевой информации (Например, можно добавить в структуру адреса на
стороне поставщика данных атрибут «номер секции», для однозначной идентификации
объекта).
Дубликаты адресов и здания с несколькими адресами
Фактически при анализе существующих картографических данных удалось установить,
что из более чем 100 тысяч зданий и сооружений в г. Уфе, адреса имеют только 30 тысяч.
Притом есть на карте города как здания без адресов, так и сооружения с адресами. И это
ещё только малая часть проблем.
Основные же проблемы связаны с тем, что многие здания имеют два адреса (угловые
дома), но хуже всего то, что многие здания (или здания, построенные секциями –
фактически разные здания и разные объекты на карте), имеют один и тот же адрес.
Дополнительных данных, позволяющих отделить основное здание от пристроев к нему,
или секций, на карте города нет.
Фактически на карте не ведётся такой признак, как «Основное здание/пристрой». Хотя и
ведение такого признака также не решит всех проблем, так как существуют множество
зданий, имеющих целый ряд пристроев. Также непонятно что делать в ситуации, когда
была построена встроенная секция, соединяющая два строения.
Ввода адресных данных о контрагентах, находящихся за
пределами локальной (подконтрольной) территории
Отсутствие данных в ИС, и невозможность получения достоверных данных из открытых
источников (ОКАТО, КЛАДР и д.р.)
Система адресации отличная от системы адресации принятой в г. Уфе. Есть города,
имеющие простую систему адресации (например, г. Октябрьский РБ: номер микрорайона,
номер корпуса в микрорайоне). Примерно такая же система адресации применяется в
Зеленоградском АО г. Москвы. Ничего общего понятия «внутриквартальный корпус» с
понятиями «дом/строение» не имеет, а потому эти понятия несут различную
семантическую нагрузку и правила входного контроля, вследствие чего не могут быть
объединены.
Отсутствие прав доступа к адресному реестру сотрудников в организации или неверное
введение адресных данных не специалистами (человеческий фактор).
Фактически все строения и сооружения можно адресовать (только вот нужно ли это?).
Даже элементы коммуникаций, такие как столбы линии электропередач, имеют номер
столба. Зная номер столба и принадлежность его определенной трассе можно однозначно
идентифицировать его. Так же можно идентифицировать кабель, а именно участок кабеля,
проложенный от пикета №1 до пикета № N. В таком случае для идентификации столбов
воздушных линий электропередач или пикетов кабельных линий можно применять
обыкновенную систему адресации, где младшим адресным элементом будет
наименование или номер трасы, а номер столба или пикета фактически будет
соответствовать понятию «Номер дома/здания/сооружения».
Участки автодорог можно идентифицировать их километражем, или указанием двух
отметок километража, указанием направления движения, указанием номера полосы для
движения, и т.д.
Фактически введение в действие общероссийского ресурса АИС АР РФ, и принятие его за
единый стандарт для всех ИС России поможет решить проблемы, связанные с
недостаточностью структур адресных данных (в случае богатства этой структуры в АИС
АР РФ). Возможный отказ от централизации хранения и организации публичного доступа
такого ресурса приведёт к огромному числу сложностей, которые сведут все начинания по
организации АИС АР РФ к невозможности её использования.
Изменения границ городской черты
О расширение городской черты, путём ввода в состав города населённых пунктов некогда
находящихся в непосредственной близости от городской черты, напоминать не
приходится.
Также не стоит забывать и о добавлении названий линейных градостроительных
элементов (улиц) присоединенных населённых пунктов, в состав уже имеющихся в
городе. А в городе уже имеются улицы Ленина, Мира, Центральная и др. В результате
чего в реестре улиц города появляются «дубликаты» (по 4е улицы Центральных,
Революционных, Мира и т.д.). Переименование этих улиц дело трудо- и ресурсо- ёмкое,
да и не дешёвое.
На данный момент эти улицы можно идентифицировать по их принадлежности к
конкретному населённому пункту (например, город Уфа, улица Мира и город Уфа,
посёлок Чесноковка, улица Мира – это две различные улицы).
Вообще то, проблема нестыковки адресных элементов (и адресуемых объектов) в
различных ИС по большому счёту является обыкновенной проблемой интеграции данных
(интеграции, а значит сопоставления и синхронизации).
Общесистемные проблемы
Большинство проблем адресации также присуще и другим областям IT-индустрии.
Основными причинами, подталкивающими многих к организации крупных
общероссийских ресурсов являются проблемы, связанные с невозможностью переноса
данных из одной системы в другую, или проблемы, не позволяющие однозначно
идентифицировать тот или иной объект в различных ИС.
С большинством из этих проблем столкнулось и МУП МИТЦ при создании
централизованного ресурса ЦКРД. Основной задачей ЦКРД являлось и является
синхронизация данных между различными ИС различных подразделений Администрации
города, выявление нестыковок в таких данных, а также трансляция изменений
синхронизированных данных об объектах недвижимости между участвующими в проекте
ИС-донорами.
Анализ ситуации, сложившейся в различных ИС города Уфы позволяет, говорить об
общесистемных проблемах, проблемах идентификации, сопоставления и синхронизации
данных.
В числе прочих проблем есть так же и проблема российского законодательства, и
искажения общей терминологии, применяемой в российском законодательстве.
Синхронизация данных
Наличие счётчиков в различных системах метящих одинаковые объекты, а также
локализованность (замкнутость в одной ИС) этих счётчиков, приводит к проблемам
нестыковки одних и тех же данных в различных ИС. Один и тот же объект недвижимости
или линейный градостроительный адресный элемент, имеет различные идентификаторы в
разных системах (а иногда и в одной ИС – дубликаты). Эта проблема решается путём
выделения ключевой группы в объекте и сопоставлению данных из различных систем по
данным, входящим в состав этой ключевой группы.
Проблема остаётся для объектов, не имеющих ключевых данных в силу своей природы
(земельные участки) или не имеющих достаточных ключевых данных (несколько зданий,
с одним адресом, без указания номера секции или номера пристройки).
Таких проблем практически не наблюдается для реестра адресных элементов. В данном
случае ключевой группой для однозначной идентификации адресного элемента являются:
Наименование адресного элемента, Указатель на вышестоящий адресный элемент в
дереве, Указатель на вид адресного элемента (возможны одноимённые одноролевые
адресные элементы, имеющие разные виды – пример: переулок Мира, проспект Мира,
улица Мира).
В общем случае заменить уникальный идентификатор невозможно. Представляется
целесообразным генерировать такой идентификатор силами единого централизованного
механизма, с присвоением ему соответствующего статуса. Фактически предлагается
введение понятия «общероссийский реестровый номер (идентификатор) объекта».
Введение такого идентификатора позволит избавиться от нестыковок данных в различных
ИС на территории Российской Федерации.
Применение каскадированных счётчиков
Применение каскадированных счётчиков является довольно наглядным, когда увидев
один код, можно сразу понять о каком регионе и каком городе и районе города идёт речь.
Применение каскадированных счётчиков можно увидеть повсюду, будь то ОГРН, ИНН,
КПП, ОКАТО, КЛАДР или шифр подразделения МВД, осуществляющего паспортный
учёт.
Любой кадастровый номер, номер ОКАТО или КЛАДР, является стандартной группой
каскадированных счётчиков. Коды в таких древовидных справочников зависят от
положения элементов в её структуре. Зачастую эти коды разбиваются на код-группы,
имеющие различную мантиссу, а ограниченность мантиссы тоже порождает ряд проблем
при её переполнении (а переполнение мантисс бывает всегда).
Основным примером такого переполнения является система регистрации гос.номеров для
автотранспорта. В частности на Республику Башкортостан приходится теперь два кода
региона 02 и 102, ситуация с гос.номерами в г. Москве ещё хуже.
Основной же проблемой автоматизации генерации данных кодов является проблема
каскадированных счётчиков. Фактически каждая код-группа должна иметь свой счётчик
(да ещё конкретные значения этого счётчика сопоставляются конкретным адресным
элементам – регионам, районам). Таким образом, каждый более низкий в мантиссе
счётчик должен зависеть от значения вышестоящей код-группы. Т.е. если мы заполняли
коды для районов 01 региона, то при заполнении районов 02 региона, необходимо либо
сбросить значение счётчика, и, желательно, запомнить его значение где-то в хранилище
относительно старшей группы. Такая задача не просто не тривиальна, или сложна, она
вообще является огромнейшим источником ошибок. Фактически размещение нового
адресного элемента в таком справочнике требует предварительного анализа имеющихся
кодов.
Все элементы справочников, имеющих такую кодировку, получают её однократно. О
сохранности кодов и речи не может идти. Если попытаться перекодировать заново весь
этот справочник, то ни один из старых кодов не совпадёт с новыми. И причиной этому не
только динамика в изменении адресных элементов России, но и хотя бы банальная
очерёдность объектов при присвоении им кодов. Ещё одной причиной нестыковки кодов
является зависимость кода от положения кодируемого элемента в дереве.
Поэтому такие справочники поддерживаются вручную. А в случае если какой-либо
населённый пункт изменяет свою подчинённость (например, посёлок Уфимского района
включается в состав города Уфа), то вообще все коды его адресных элементов устаревают
и требуют назначения новых.
Кстати, в ГлавАрхитектуре г. Уфы применяется аналогичный способ идентификации
линейных градостроительных элементов в городе, а именно 5-и буквенный код, вводимый
сотрудниками ГлавАрхитектуры вручную. Ведение же справочника населённых пунктов,
включённых в состав города, на карте (адресном плане) города не предусмотрено.
Осознавая важность наглядности информации при предлагаемом отказе от использования
каскадированных счётчиков, предлагается повышать наглядность данных путём
повышения доступности общероссийского адресного реестра.
В предлагаемом подходе установить точный адрес объекта можно будет только при
наличии доступа к АИС АР РФ, или при наличии локальной копии данного ресурса путём
запроса адреса посредством ввода общероссийского идентификатора адреса.
Устаревшие реляционные подходы к проектированию
информационных систем, хранилищ и баз данных
Очень многие базы данных спроектированы на основе реляционных (строго
математических) моделей. В жизни всё не так. Реляционные теории не соответствую
потребности ИС. Например, при описании субъекта правового отношения в большинстве
реляционных систем заводится либо «строка свободного ввода», либо какой то
справочник контрагентов. Наверняка многие уже столкнулись с проблемами, связанными
с попыткой увязать, к примеру, физических лиц, организаций и юридических лица в
единый справочник. Атрибутика понятий человек, физическое лицо, организация и
юридическое лицо, совершенно различна. Поэтому «запихнуть» всё это в некий единый
«универсальный» справочник фактически не удалось никому.
Поэтому речь может идти только о реестровых объектно-ориентированных
информационных системах и базах данных. В развитой структурой данных, усложняющей
ввод данных (в силу своей высокой структурированности), но позволяющей вводить
входные контроли данных на атомарном уровне, а также позволяющей свободно
интегрировать данные с другими объектно-ориентированными информационными
системами.
На практике же каждый разработчик ИС «варится в собственном соку», и, конечно же,
является знатоком в своей прикладной и предметной области. Также очень часто
проектировщики денормализуют базу данных с целью ускорения и упрощения ввода
данных в ИС конечными пользователями.
Любой разработчик в конечном итоге строит свою ИС со стороны тех технологических
процессов, которые он автоматизирует. А потому корневыми для различных ИС являются
различные объекты, являющиеся стартовыми точками их технологических процессов. Или
просто являющиеся пустыми формулярами выходных документов, подлежащих выдачи
этим ведомством.
Например, здание. Вроде бы обособленный объект недвижимости. Но это ведь не так.
Здание имеет различные этапы жизненного цикла от проекта до сноса. И различные
ведомства, застают один и тоже объект в различных стадиях его жизненного цикла, и
совершенно по-разному строят свои ИС.
Например, БТИ может выдавать техпаспорт на: здание целиком, группу зданий, часть
здания, этаж, несколько этажей, помещение, несколько помещений, или вообще на целый
имущественный комплекс.
С чего же начинать работать БТИ? Со зданий?
Тут у БТИ применяется такое же решение, как и у всех – а именно ИС БТИ работает с
техпаспорта, а основными элементами техпаспорта являются экспликации (выписки о
конкретном помещении). Т.е. объектной ориентированности в системе нет. Как следствие
в системе нет таких понятий как «Земельный участок», «Здание», «Этаж», «Помещение»,
«Комната». Да они и не нужны в деятельности БТИ. Ведь деятельность БТИ
заканчивается выдачей техпаспорта на бумажном носителе. Говорить об истории
изменения каких-либо параметров одного и того же имущественно объекта уже не
приходится (наличие систем историзма предполагает наличие объектно-ориентированных
хранилищ). Максимум что можно получить из системы – это старый техпаспорт, в полях
экспликации которого возможно будут указаны те же номера объекта недвижимости (в
случае если не применялся «новый счётчик» для пометки помещений на поэтажном
плане).
А вот, например, КУМС сдаёт в аренду или продаёт уже конкретные объекты
недвижимости (земельные участки, здания, помещения).
А где же КУМСу взять данные об этих объектах недвижимости?
Естественно из первоисточника – организации вводящей эти объекты недвижимости в
эксплуатацию (БТИ, земельная палата, земельное агентство). Но опыт показывает, что у
организаций-первоисточников этих объектов недвижимости тоже нет. И существующие
ИС не позволяют вводить данные в объектно-ориентированном виде. Нежелание
развивать собственные системы до объектно-ориентированных тоже понятна и очевидна.
Основная причина этого – это глубокая и сложная структурированность данных,
снижающая их наглядность, и повышающая сложность при вводе этих данных, или
вообще блокирующая ввод некорректно-вводимых данных при наличии систем входного
контроля.
Такие же проблемы есть, например, и в картографической информации. Карта города
создаётся работниками ГлавАрхитектуры как наглядный ресурс. Именно эта наглядность,
реализованная упрощёнными способами (а именно хранением информации в
денормализованном виде) не позволяет говорить о каком-либо входном контроле данных
или о какой-либо их интеграции со структурно-развитыми системами. Зато
денормализованные «плакатные» данные позволяют простыми и быстрыми способами
вывести их на экран или бумажный носитель.
На данный момент, единственной гарантией качественности введённых на карту города
данных, является только личная ответственность работников ГлавАрхитектуры г. Уфы.
Отсутствие входного контроля данных
Более-менее ясным представляется только иерархия хранения (а также синхронизации,
интеграции) адресных элементов.
Но пока что не представляется ясным унифицированная структура хранения именно
адресного реестра (т.е. реестра фактических адресов объектов недвижимости).
Кроме ссылок на адресный элемент, объект «адрес» должен содержать в себе
взаимоисключающие наборы данных такие как:
 «Номер участка» («Номер [кадастрового] квартала» в данном случае будет
младшим адресным элементом);
 «Дом», «Строение», «Литера».
Таким образом, вводить в объект «Адрес» одновременно номер здания и номер
земельного (или садового) участка не должно представляться возможным. Фактически же
объект адрес имеет различную атрибутику, изменяющуюся в зависимости от «вида
адреса» (или объекта, адресуемого данным адресом).
Проблема трактовки понятий
Централизованно-распределённые системы
Что же это такое?
Наверное сразу стоит упомянуть, что многие всё-таки не понимают или не до конца
представляют себе что такое распределённые системы.
Итак, всем понятно, что распределённая система состоит из совокупности ИС,
соединённых между собой какими-либо телекоммуникационными сетями, например
глобальной сетью Интернет.
И на этом понимание распределённых систем у многих заканчивается.
Далее выдвигаются лозунги о наличии современных технологий, якобы позволяющих
общаться между собой различным ИС, посредством какого-то универсального
обобщённого языка и какой-то готовой единой технологии.
А где Вы видели этот язык? HTTP? E-mail? А может XML?
Все эти языки являются лишь «транспортным» уровнем. Язык XML вообще не имеет
спецификаций относительно структуры и состава данных в нём, в чём, собственно и есть
его основное преимущество, позволяющее передавать посредством XML данные в любых
структурах, любой сложности, иерархии и подчинённости.
Разработанный в МУП МИТЦ унифицированный формат обмена данными (УФОД) не
только не является каким-либо стандартом, а и того хуже, фактически является набором
определённых соглашений о том, как представить различные данные из различных систем
в XML’е таким образом, чтобы имеющаяся система конвертации данных в ЦКРД смогла
обработать эти данные и преобразовать к собственной структуре данных ЦКРД. Пример
разработки подобного языка не единичен, здесь он приведён просто для наглядности.
В чём же сложности разработки некой универсальной структуры данных? Или набора
структур данных для различных прикладных областей?
Основная проблема связанна с гетерогенностью различных систем. В большинстве ИС
просто отсутствуют данные (и поля для заведения данных), которые, к примеру,
понадобились сейчас для решения определённых проблем другому участнику проекта.
Практически все ИС не имеют систем входного контроля данных, что приводит к резкому
снижению качества таких данных. Многие ИС вообще не имеют возможности внедрения в
них входного контроля в виду отсутствия достаточной структурированности данных
(простой пример, хранение данных о номере, корпусе и литере здания в одном поле или
того хуже хранение всего адреса объекта в строчном виде, без какой-либо структуры).
Следующая проблема связана с динамикой структур данных. Очень многие структуры
данных меняются динамически, и меняются довольно часто. Даже хотя бы расширение
имеющейся структуры данных при добавлении одного нового атрибута не позволяет
разработать «и утвердить» единые стандарты для всего города (а уж тем более для всей
России).
Таким образом, любой крупный проект, ставящий себе первоочередной задачей
разработку некоего «стандарта» обмена данными обречён на провал даже не на этапе
согласования этих структур данных или их применения, а ещё на этапе попытки их
написания.
К тому же неизбежны ошибки при формировании структуры данных из-за отсутствия
учёта в этих структурах данных интересов всех прикладных областей.
В реальности вести речь об эталонных структурах данных тяжело, но концептуально
необходимо. Исходя из вышеизложенного, представляется возможным только описания
базовой версии основных структур данных на общероссийском уровне, и
стандартизированный системный подход к проектированию и расширению заданных
«стандартных» структур данных.
Фактически структуры данных являются такими же динамическими материями как и
обычные данные. Что предполагает такое же ведение истории за структурами данных, а
также ввода механизмов преобразования данных в различных структурах данных друг в
друга (определённые решения в этой области уже достигнуты сотрудниками МУП МИТЦ
при реализации проекта ЦКРД).
Искажения понятий в российском законодательстве
Следующая проблема, проблема законодательства, его влияния на работу специалистов, и
как следствие на структуры данных в ИС.
Для примера начнём с самого «известного» всем понятия «Организация». Что каждый из
нас первым делом отнесёт к атрибутам организации? Ну конечно полное и сокращённое
наименование, а также ИНН и КПП. Хотя на самом деле вся эта атрибутика вообще не
имеет никакого отношения к понятию «Организация».
Вся эта атрибутика принадлежит понятию «Юридическое лицо». И здесь налицо именно
несовершенство нашего законодательства, и систематические ляпы в трактовке понятий и,
как следствие, искажение нормальных понятийных аппаратов.
Отождествление понятий «Организация» (группа лиц) и «Юридическое лицо»
(физическое лицо или группа лиц, осуществляющих финансово-коммерческую
деятельность на территории РФ) совершенно не верно.
Изначально многие программисты понимают различия в этих понятиях, но в силу
рыночного закона «заказчик всегда прав» практически всегда искажают модель данных до
«законодательных» трактовок.
Во многих ИС когда-либо вставала проблема с идентификацией филиалов крупных
структурированных организаций. Проблема здесь также имеет глубокие корни, и сложные
решения. В частности организации с некоторых пор принято идентифицировать
составным ключом ИНН + КПП (есть даже ИС в которых эти данные хранятся в одном
20-и символьном поле).
Итак, а что же делать с организациями в других странах? Ведь они не состоят на
налоговом учёте РФ, и не имеют ИНН и КПП. Да и вообще понятия ИНН и КПП никакого
отношения к организациям то и не имеют. Эта атрибутика выдаётся налоговым органом
при постановке организации на налоговый учёт, и получении организацией статуса
юридического лица (вся данная атрибутика отражена в свидетельстве о постановке на
налоговый учёт).
На самом же деле к организациям относится любая группа лиц, имеющая (юридические
лица, обособленные филиалы) или не имеющая (филиалы без образования юридического
лица, иностранные организации, отделы предприятий, группы в отделах предприятий и
т.д.) регистрацию в налоговом органе.
Понятие «Юридическое лицо» относится так же и к частным предпринимателям - физ.
лицам. Но ведь согласитесь, даже частные предприниматели не родились с
свидетельством о постановке на налоговый учёт в руках. А потому и ИНН (бывший
социальный номер) тоже никакого отношения к людям не имеет.
Такие вот вещи, искаженно прописанные в наших законодательных актах и даже в
Конституции РФ, и приводят к различному толкованию одних и тех же понятий, и как
следствие к неверному проектированию структур данных, баз данных, хранилищ и
централизованно-распределённых систем.
Даже сейчас, читая всё вышеизложенное, многие сомневаются в правдивости
вышеописанных выводов. Потому как проблема не правильной, не систематизированной
трактовки понятий уже давно является сильно закоренелой.
Спорность некоторых выводов о структурах данных может привести к высокому
недоверию к этим структурам данных. А естественные ошибки в этих
«стандартизированных» структурах данных, утверждённых на общероссийском уровне,
могут привести к их полной компрометации, и полному отказу от их использования.
Преимущества централизованно-распределённых систем
Возвращаясь к централизованно-распределённым системам, хотелось бы спросить, зачем
же всё-таки нужны централизованно-распределённые системы (а не децентрализованораспределённые)?
Основными плюсами централизованной системы (и её распределённых копий, полных
или частичных) являются:
1. Возможность настройки и контроля прав доступа между всеми участниками,
заполняющими или изменяющими данные в централизованном ресурсе;
2. Возможность отчуждения полного справочника или интересующей части
справочника из единой точки – единого центрального сервера, к тому же 24 часа в
сутки 7 дней в неделю (в формате 24х7) – ведь обеспечить высокоскоростной
доступ необходимо только к централизованному ресурсу, а не ко всем частям
централизованно-распределённой системы;
3. Низкие затраты на сопровождение и обновление ресурса (ведь ресурс не
перегоняется каждый раз целиком, а к нему даётся доступ удалённым работникам
на добавление новых или изменение старых данных);
4. Возможность поддержания единого ресурса без обязательного требования наличия
развитых коммуникаций удалённых работников.
Проблемы при организации централизованных единых ресурсов:
1. Российское законодательство, запрещающее централизовать большинство данных
(вообще запрещающее какую-либо передачу большинства данных по любым
телекоммуникационным сетям);
Кстати, в дополнение о Российском законодательстве, запрещающим какую либо
передачу данных по телекоммуникационным сетям, хотелось бы добавить, фактически
локальная вычислительная сеть также является телекоммуникационной, а данные
например, о физ.лицах, хранятся на сервере локальной сети. Данные о физ.лице вводятся с
рабочей станции и потом отправляются на сервер, что фактически запрещено Российским
законодательством.
Так получается, что вся Россия теперь нарушает закон. И данный закон позволяет многим
чиновникам, скрываясь за лозунгами о безопасности и ссылаясь на такие вот законы,
фактически препятствовать и противодействовать интеграции, синхронизации и
централизации информационных ресурсов.
Почему нельзя создать даже с помощью новейших технологий децентрализованную
распределённую систему?
Для реализации децентрализованной распределённой системы необходимо:
1. Наличие бесперебойно работающих распределённых серверов в формате 24х7;
2. Наличие развитых и отказоустойчивых высокоскоростных телекоммуникационных
сетей, связывающих все распределённые сервера, также работающих безотказно в
формате 24х7;
3. Единый язык запросов и способ переадресации запросов в распределённые
системы;
4. Специальные модули запроса данных к распределенным серверам непосредственно
с рабочих мест всех ИС России, фактически требующей прямого доступа в
Интернет со всех АРМ всех ИС.
Понятно, что разработчикам любой ИС проще запросить (пусть даже из разрозненного
источника) все данные целиком, и создать собственный единый справочник, чем
пользоваться децентрализованным распределённым ресурсом.
Основными проблемами для невозможности реализации децентрализованной
распределённой системы являются:
1. Отсутствие развитых телекоммуникаций;
2. Отсутствие и невозможность создания единого языка общения всех ИС (тем более
гетерогенных ИС);
3. Не возможность получение сводного ресурса или любой его части в режиме 24х7;
4. Полное отсутствие управляемости системы (центрального сервера – «головы» ведь
нет);
5. Полное отсутствие контроля над тем, что делают работники, пополняющие данные
на собственном сервере – распределённом ресурсе;
6. Полное отсутствие какой-либо единой системы контроля прав доступа для данных,
размещаемых в данном эталонном общероссийском ресурсе.
Некоторые из этих проблем можно устранить, к примеру, разработав единую
общероссийскую (гомогенную) систему, и внедрив её по всей России.
Опыт показал, что все такие попытки заканчивались провалом. Программное обеспечение
быстро устаревало и использовало устаревшие технологии (DOS кодировки, DOS
приложения, не возможность печати данных, отсутствие интеграции с офисными
приложениями и др.)
Первоочередной проблемой оставалось именно развитие программного обеспечения и
рассылки его обновлений.
Даже сейчас есть общероссийские программы (например, ПФР), которые при одном их
упоминании вызывают ужас, как у программистов, так и у бухгалтеров и кадровых
работников любого предприятия.
Кстати программа ПФР является централизованно-распределённой, а утверждения
некоторых чиновников о её децентрализовано-распределённой структуре не
соответствуют действительности.
Опираясь на опыт России и зарубежных стран хотелось бы подчеркнуть следующее:
Многие страны имеют в своей работе централизованно-распределённые системы, да и
внутри нашей страны такие системы тоже существуют и таких систем не мало.
Примерами можно было бы назвать такие системы как база данных ФБР США,
хранящаяся в себе данные обо всех гражданах Америки с момента их рождения.
Аналогичная база данных есть в МВД РБ, в центральном сервере которой хранятся все
данные, касающиеся компетенции МВД РБ. Доступ к данному ресурсу организован из
удалённых населённых пунктов. Фактически удалённые подразделения МВД РБ получают
и отправляют запросы и данные с удалённых терминалов на единый сервер.
База данных МВД РБ не является децентрализованной и, фактически, не является
распределённой, что позволяет оперативно и качественно осуществлять поиск
необходимой информации и вводить новые данные о правонарушениях и
правонарушителях. Фактически БД МВД РБ – это центральная БД с организацией
терминального доступа.
Примеров централизованно-распределённых систем в России очень много – это и ИС
государственные органы и служб, оперативных спецслужбы, и ИС нефтегазовой
промышленности, энергетики, металлургии и ИС многих других крупных отраслей и
естественных монополий России.
Заключение
Хотелось бы подчеркнуть важность решения проблем, связанных с отсутствием такого
общероссийского ресурса как АИС АР РФ. Но также все участники такого рода дискуссий
должны осознавать ответственность перед недостаточно продуманными решениями и
поспешными выводами, при создании ресурсов такого рода, и подкреплении ведения
такого рода ресурсов законодательными актами.
Фактически всеми участниками дискуссии затронуты многие проблемы, требующие
дополнительного анализа методов их решения, а также риски, возникающие при
поверхностном подходе к решению проблем.
Также хотелось бы подчеркнуть невозможность создания АИС АР РФ без использования
централизованно-распределённых систем. При наличии децентрализации ресурса
возникает ряд неразрешимых проблем, фактически полностью умоляющих всей
эффективности от внедрения таких ИС.
В аспекте затронутой и освещённой ГИС-ассоциацией проблеме, а речь идет только об
адресном реестре Российской Федерации, и о различных адресных элементах всех
уровней, а также в разрезе отсутствия каких либо ограничений на распространение такой
информации, всё-таки представляется возможным создание централизованнораспределённой АИС АР РФ при наличии соответствующего системного подхода. Также
представляется возможным создание жёстких структур базовых иерархических адресных
справочников, и внедрения этих структур данных как единого стандарта для создания
адресного реестра РФ.
При отсутствии систем каскадированных счётчиков установить точный адрес объекта
можно будет только при наличии доступа к АИС АР РФ, или при наличии локальной
копии данного централизованного ресурса путём запроса адреса посредством ввода
общероссийского идентификатора адреса.
Применительность подходов централизованно-распределённых хранилищ в других
областях сомнительна, в силу несовершенства российского законодательства.
Документы, предлагаемые ГИС-ассоциацией на обсуждение, в конечном итоге
желательно бы реализовать в базовых государственных стандартах РФ (ГОСТ Р),
стандартизирующих термины и определения в области адресации объектов недвижимости
и субъектов вещных прав, правила написания географических названий (полигональных
и линейных градостроительных элементов – геонимов, топонимов, годонимов и т.п.), роли
отдельных адресных элементов. В стандарт желательно включить примеры форматов
описания адресов, допустимые и недопустимые символы (или их сочетания) для
отдельных адресных элементов. Проекты таких стандартов можно разместить на сайте
ГИС-ассоциации для широкого обсуждения.
В настоящее время строения и сооружения не адресуются, кроме части, относящейся к
зданиям. Тем не менее, эти объекты зачастую являются объектами вещных прав.
Отсутствие адресации таких объектов недвижимости зачастую приводит ко многим
юридическим проблемам, а также отсутствую возможности синхронизации данных об
этих объектах в различных гетерогенных ИС.