Атрибуты

· DID - (идентификатор документа), уникальный ключ для определения экземпляра сущности. В рамках одной подсистемы естественным ключом может являться комбинация атрибутов «тип документа - № документа - дата», однако для комплексного кадастра такая идентификация может оказаться неоднозначной, даже при подстановке к ключу поля «кем выдан». Поэтому в интеграционных целях можно использовать суррогатный ключ, в качестве типа данных, как и для класса KadastrObject, определяется тип GUID.

· typeDoc - вид документа

· number - регистрационный номер документа

· date - дата регистрации документа

Рисунок 3.8. Класс Document

В описании класса не вводятся атрибуты для связи с кадастровыми объектами. Документ является одним из аргументов для учетных функций f_i и функций состояния ц и ш (параграф 3.1), поэтому связи определяются непосредственно через данные функции. Как показывает практика, такой подход удобен в силу многообразия отношений между объектами кадастра. Действительно, чтобы описать сложные связи объектов через класс документа, следует вводить не только атрибуты ссылок на объекты, но и описание каждой такой связи, что в свою очередь уже определено посредством функций f, ц, ш.

Класс Address - («Адрес»)

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

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

В России для естественной формы адреса («почтовый адрес») принята следующая структура: страна, индекс, регион, район, город, населенный пункт, улица, дом, корпус, квартира. Общей привязкой для этих данных служит единый рубрикатор территориальной принадлежности - начиная от страны и заканчивая улицей.

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

Например, цепочка

«Объект кадастра»>»Реальный объект»>»Объект»

для земельного кадастра будет продолжена классом:

>»Земельный участок»,

для имущественного кадастра:

>»Недвижимость»>»Строение»>»Жилой дом»,

для водного кадастра:

>»Водный объект»> «Ограниченный водоем»>»Озеро».

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

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

Предположим, что для города принят следующий стандарт адреса:

· административный округ;

· населенный пункт;

· улица;

· дом;

· литер;

· корпус;

· строение;

· квартира;

· комната.

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

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

Предлагаемый автором подход заключается в следующем:

1) базовый класс формируется полным набором атрибутов (по стандарту страны, федерации, субъекта федерации, района, города, поселка и т.д.);

2) для каждой подсистемы определяется класс-прототип с необходимым набором предопределенных значений атрибутов базового класса. Такие атрибуты объявляются скрытыми (hidden), т.е. их значения присваиваются по умолчанию и не могут быть изменены в экземплярах класса-прототипа;

3) каждый атрибут может определяться упорядоченным набором своих значений;

4) класс содержит методы компоновки (build) и разбора (parsing) строкового значения адреса.

Рассмотрим подробнее 3 и 4 пункты. Например, почтовый адрес есть набор атрибутов класса Address:

· страна - Россия;

· индекс - 625035;

· субъект Российской Федерации - Тюменская область;

· район - Тюменский;

· город - Тюмень;

· улица - Ленина;

· номер дома - 14;

· литер - б;

· квартира - 50.

Метод build («скомпоновать») должен вернуть сформированную по определенным правилам строку, например в виде:

Россия, 625035, Тюменская область, Тюменский район, г. Тюмень, ул. Ленина, 14 б - 50

Обратную операцию - разобрать адрес на составляющие выполняет метод parsing («грамматический разбор»). Предполагается, что строка адреса составлена по общепринятым (согласованным на городском уровне) правилам, которые и должны быть заложены в реализацию методов build и parsing базового класса.

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

ул. Ленина - ул. Перекопская - ул. Республики - ул. Красина

или адрес углового строения определен как:

ул. Ленина, 35 / ул. Кирова, 10

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

Так, в примере с угловым зданием, адрес будет иметь вид:

улица[1] - Ленинадом[1] - 35

улица[2] - Кировадом[2] - 10

или улица - [Ленина,Кирова]

дом - [35,10]

Итак, базовый класс Address может быть определен следующим образом:

Атрибуты

· country - страна

· state - область

· province - район

· city - город

· point - населенный пункт

· street - улица

· numberHome - номер дома

· corps - корпус

· apartment - квартира

· room - комната

Методы

· build - собрать адрес из значений атрибутов

· parsing - произвести разбор адресной строки

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

Для примера определим класс-прототип адресной привязки участка в некоторой земельной службе города Тюмени (LandAddress):

Атрибуты

· country (страна) = Россия (hidden)

· state (область) = Тюменская (hidden)

· province (район) = Тюменский (hidden)

· city (город) = Тюмень (hidden)

· point - населенный пункт

· street - улица

· numberHome - номер дома

· corps - корпус

· apartment (квартира) = NULL (hidden)

· room (комната) = NULL (hidden)

Иначе говоря, адрес участка в данном подразделении города будет упорядоченный набор структур типа «населенный пункт» - «улица» - «номер дома» - «корпус».

На рисунке 3.9 приведен пример описания базового класса Address и класса-прототипа LandAddress.

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

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

Будем выделять еще один вспомогательный класс Qualifier (классификатор).

Структура справочников имеет иерархический вид - каждое значение принадлежит некоторой категории, и в свою очередь может являться разделом для дальнейшей детализации значений. Это свойство следует отметить в описании класса:

Атрибуты:

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

· value - текстовое описание значения справочника;

· parent - ссылка на «родительскую» категорию. Если атрибут имеет пустое значение, то считается, что он представляет последний уровень значений некоторой категории классификатора.

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

Итак, приведенная классификационная схема является общей объектной моделью (рис. 3.10, 3.11). Для кадастровых подсистем, с учетом специфики конкретной предметной области, строится дальнейшая иерархия объектов, основанная на описанных базовых классах.

Рисунок 3.10. Иерархия основных классов



Рисунок 3.11. Вспомогательные классы

К основным итогам данной главы следует отнести:

· формализацию понятий предметной области комплексного кадастра;

· построение и исследование математической модели комплексного кадастра с использованием теоретико-множественного аппарата;

· определение условий для применимости данной модели в качестве концептуальной основы для создания комплексной информационной кадастровой системы;

· описание базовых классов кадастровых объектов, их основных свойств и методов.

Итак, на начальном уровне моделирования мы рассматриваем общую кадастровую систему как совокупность взаимосвязанных систем. С другой стороны, элементы системы есть объекты, для каждого из которых определяющим фактором является принадлежность одному или нескольким подмножествам. Таким образом, кадастровые подсистемы являются связными по данным (а не функционально или логически), что делает общую систему инвариантной по отношению к подсистемам.

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

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

Глава 4. Разработка муниципальных кадастровых систем

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

4.1 Концепция «Кадастровый банк данных»

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

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

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

Иначе говоря, базы данных кадастровых подсистем существуют автономно, однако обмен информацией производят через некоторое общее хранилище данных. Перспективность создания интегрированных и специализированных хранилищ данных по всем аспектам городского хозяйства отмечается в работах российских [49,51,66-68] и зарубежных [69,71] специалистов.

Следует отметить, что хранилище данных (ХД) - это не просто очень большая база данных. В монументальной монографии Уильяма Г. Инмона «Building the Data Warehouse» хранилище определено как «предметно-ориентированная, интегрированная, вариантная по времени, не разрушаемая совокупность данных, предназначенная для поддержки принятия управленческих решений» [95]. Информационные ресурсы хранилища данных формируются на основе извлечения на протяжении продолжительного периода времени моментальных снимков баз данных оперативных информационных систем, каковыми обычно являются кадастровые системы для поддержки повседневной деятельности соответствующих подразделений.

Несмотря на различия в подходах и реализациях, всем хранилищам данных свойственны следующие общие черты [82]:

· Предметная ориентированность. Информация в хранилище данных организована в соответствии с основными аспектами деятельности предприятия - это отличает хранилище данных от оперативной БД, где данные организованы в соответствии с процессами. Предметная организация данных в хранилище способствует как значительному упрощению анализа, так и повышению скорости выполнения аналитических запросов. Выражается она, в частности, в использовании иных, чем в оперативных системах, схемах организации данных. В случае хранения данных в реляционной СУБД применяется схема «звезды» (star) или «снежинки» (snowflake). Кроме того, данные могут храниться в специальной многомерной СУБД в n-мерных кубах.

· Интегрированность. Исходные данные извлекаются из оперативных БД, проверяются, очищаются, приводятся к единому виду, в нужной степени агрегируются (то есть вычисляются суммарные показатели) и загружаются в хранилище. Такие интегрированные данные намного проще анализировать.

· Привязка ко времени. Информация в хранилище всегда напрямую связана с определенным периодом времени. Данные, выбранные иp оперативных БД, накапливаются в хранилище в виде «исторических слоев», каждый из которых относится к конкретному периоду времени.

· Неизменяемость. Оперативная система выполняет над хранимыми данными операции обновления, удаления и вставки, а данные, загруженные в определенный «исторический слой» хранилища, уже никогда не будут изменены.

На рисунке 4.1 приведена общая модель хранилища данных.

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

Таким образом, к основным компонентам хранилища данных относят:

· оперативные источники данных;

· средства проектирования/разработки;

· средства переноса и трансформации данных;

· СУБД;

· средства доступа и анализа данных;

· средства администрирования.

Для оперативных кадастровых систем важна «обратная связь» с ХД, т.е. необходимы службы подписки и публикации, которые позволяют «уведомлять» пользователя о появлении в хранилище необходимой ему информации и автоматически высылать эту информацию в виде, преобразованной к модели данных клиента.

Поэтому службы переноса и трансформации данных должны не только уметь извлекать и преобразовывать информацию, но и предоставлять (или автоматически загружать) требуемые данные из хранилища в оперативные системы, в «понятном» для них виде (рис. 4.2).

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

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

Таким образом, хранилище данных для предметной области городского кадастра должно удовлетворять следующим требованиям:

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

· обеспечивать долговременное хранение информации и ведение истории ее накопления;

· создавать и хранить схемы соответствий метаданных оперативных систем-источников и метаданных хранилища;

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

· защищать информацию от несанкционированного доступа;

· иметь открытую архитектуру, которая легко интегрируется и расширяется;

· предоставлять доступ к метаданным и данным со стороны аналитических информационных систем.

Итак, главное отличие от традиционного хранилища определяется в цели накопления информации - данные должны быть организованы в виде оптимальном не для анализа, а для консолидации информации различных гетерогенных кадастровых систем. На рисунке 4.3 показаны основные направления информационного взаимодействия ХД и внешних систем.



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

Банком данных принято называть систему специальным образом организованных баз данных, программных, технических, языковых и организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных [2].

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

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

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

При этом в существующих системах даже однотипные характеристики имеют различные наименования (например, признак «адрес» может иметь наименования «адрес постоянного местожительства», «местоположение земельного участка», «юридический адрес» и т.д.) и различную форму записи конкретных значений признаков.

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

· унифицированные идентификаторы информационных объектов;

· стандартные форматы описания данных;

· справочники информационных объектов;

· общесистемные классификаторы и словари.

Определим основные концептуальные принципы построения Кадастрового банка. Внутренняя архитектура системы организована на основе оптимальной модели КМК:

· основной элемент хранения - кадастровый объект;

· каждая кадастровая подсистема (клиент) проецируется на отдельный слой (сегмент);

· сегмент содержит локальную метаинформацию - схемы размещения данных сегмента на стороне клиенте (локальные метаданные);

· кадастровый объект в сегменте имеет активные и неактивные параметры;

· клиент в своем сегменте публикует активные данные и заявляет подписку на изменение данных для неактивных параметров;

· метаданные об объектах формируются эволюционно, по мере сегментации КБнД, образуя общий для всей системы словарь данных;

· при создании сегмента параметры объектов выбираются из словаря данных, определение новых классов объектов и их параметров происходит посредством расширения существующих описаний («корневые» классы всегда заданы - это элементы классификационной объектной схемы, рассмотренной в предыдущей главе), при этом описание введенных дополнительных атрибутов или классов объектов помещается также в словарь;

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

· в системе определены сервисы нотификации, которые активизируются при изменении активных параметров объектов и оповещают все сегменты, заявившие эти параметры как неактивные;

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

На рисунке 4.5 отражены основные элементы Кадастрового банка.



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

Таким образом, Кадастровый банк, обеспечивает интегрированное хранение исторической непротиворечивой и полной информации, а также реализует механизмы обмена и актуализации данных в клиентских кадастровых системах.

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

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

4.2. Формирование автоматизированной информационной системы земельного и имущественного кадастров

В настоящее время зарубежные специалисты не всегда понимают сложившуюся ситуацию в России в вопросах создания земельно-имущественного кадастра. Действительно, в странах с рыночной экономикой вся земля давно поделена на земельные участки и сформированы права на объекты недвижимости - в начале на земельные участки, а затем на здания и постройки. Поэтому кадастры в странах с развитой рыночной экономикой земельные, а здания входят в состав комплекса недвижимости земельного участка. Там право на земельный участок первично и предполагает право на все постройки земельного участка, а в ряде стран - и на полезные ископаемые. В этих странах земельный кадастр развивался для информационной поддержки рынка недвижимости. Для этой же цели и создана система регистрации прав на недвижимость [71].

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

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

Информационная система формируется как совокупность автоматизированных рабочих мест (АРМ), предназначенных для автоматизации кадастрового учета (АРМ-Жилой фонд, АРМ-Предприятия, АРМ-Сады, АРМ-Аренда, АРМ-Инвентаризация и т.д.). Основная привлекательность такого подхода это возможность автоматизировать нужный именно сейчас участок кадастровой деятельности (например, инвентаризацию) относительно дешево, а с появлением новых задач приобретать (разрабатывать) новые АРМ. Недостатки таких систем - дублирование информации по АРМ, и трудности с созданием единых точек входа. Например, определив несколько арендаторов, трудно получить все их сады, гаражи и участки под строительством, выданные в собственность.

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

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

Начиная с 1997 года, автором ведется активная практическая разработка программного обеспечения для кадастровых систем (имущественные комплексы, земельные ресурсы). Личный опыт и эмпирические наработки создателей подобных систем показывают, что наиболее «жизнеспособным» является третий из описанных способов. Формализация этого подхода была отражена в предыдущих главах данной работы.

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



Рисунок 4.6. Принципиальная схема функционирования автоматизированного земельного кадастра поселения.



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

· земельные дела (инвентаризация),

· подготовка документов,

· межевое дело (геодезия),

· экспликация земель,

· садоводческие товарищества,

· гаражные кооперативы,

· овощехранилища,

· аренда,

· инспекция (учет правонарушений),

· реклама,

· руководитель.

Информационная схема объектов кадастра имущества представлены на рисунке 4.8.



На рисунке 4.9 показаны программные блоки информационной системы имущественного кадастра (пример основан на реально действующей схеме организации ИС «Учет и управление муниципальной собственностью» в г.Тюмени).

Условно, в кадастровой базе данных можно выделить следующие основные разделы:

· описательный - содержит технические, экономические характеристики кадастровых объектов;

· правовой - содержит информацию о владении, обременении, аренде, залогах и других отношениях права на объекты;

· документальный - реквизиты документов, на основании которых было получено право, а также постановления, распорядительные акты, служебные и межведомственные документы, письма, заявки и т.д., связанные с объектами кадастра;

· фискальный - расчеты арендных ставок, суммы налогов, фактические и плановые поступления, оценка объектов;

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

· справочный - содержит классификаторы, общесистемные справочники, нормативы и стандарты;

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

Программные модули, автоматизирующие определенные задачи кадастровой системы также можно классифицировать по типам:

· инструментальные - содержат функции поиска, добавления, удаления и редактирования кадастровой информации, обычно имеют набор методов, необходимых для решения конкретных задач (например, АРМ «Рекламные установки», АРМ «Инвентаризация», АРМ «Учет арендных поступлений» и т.д.);

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

· аналитические - расчет плановых показателей, прогнозы и ретрогнозы, многомерный анализ, сводная отчетность, графики, диаграммы; как правило, используются обобщенные (агрегированные) данные кадастровой базы.

Следует также выделить методы формирования выходных документов в зависимости от функциональной нагрузки:

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

· Связанные документы - хранимые в системе статичные документы, полученные из внешних источников и связанные с объектами системы. Например, в земельном кадастре для каждого участка хранятся провоподтверждающие и правоустанавливающие документы. Для каждого документа, помимо стандартных атрибутов (№, дата, тип документа, выдавший орган) хранится либо отсканированная копия бумажного носителя, либо электронная версия документа.

· Отчеты имеющие табличную структуру служат для вывода набора данных, удовлетворяющего заданным условиям. Такие документы удобно формировать в MS Excel посредством использования механизмов OLE-автоматизации. Преимущество использования такого подхода особенно проявляются при работе квалифицированных пользователей.

· Формируемые хранимые документы - создаются на основе заготовленных шаблонов, с внесением данных из системы и последующим хранением и редактированием. Здесь организованы такие методы, как поиск контекста в документах, создание новой формы для документа.

Для реализации последнего метода был разработан класс, поддерживающий работу с текстовыми RTF строками [44]. Класс для работы с RTF строками имеет следующие свойства:

количество полей в документе-форме;

количество таблиц в документе-форме;

количество столбцов в объекте «таблица» формы.

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

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

· загрузить шаблон;

· в цикле, перебрать все строки документа и записать их в отчет, предварительно установив нужные значения переменных.

· сохранить результат в файл.

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

Помимо стандартных свойств - предварительный просмотр и печать итогового документа, здесь организованы такие методы как поиск контекста в документах, редактирование документа перед печатью, создание новой формы для документа. При этом предполагается, что пользователь владеет навыками редактирования текстов в MS WORD и его фантазия по поводу формы документа ограничивается только возможностями этого редактора.

Документы и их шаблоны хранятся в поле типа TEXT одной из таблиц базы данных, что обеспечивает эффективный поиск контекста.

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

1. Программа должна быть монолитная («все в одном»), автоматизирующая все информационные процессы подразделения, а необходимые модули расширения реализуются в виде динамически загружаемых библиотек (dll) или COM-объектов.

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

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

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

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

4.3 Программная реализация объектных схем в информационных системах земельного и имущественного кадастров

В разделе 3.4 были предложены следующие «стартовые» классы для кадастровых систем:

· Объект

· Субъект

· Право

· Документ

· Классификатор

· Адрес

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

Рассмотрим набор атрибутов и методов вспомогательного класса «Адрес» (на примере адресной организации г.Тюмени):

Таблица 4.1. Класс «Адрес»

	Название	Описание
Атрибуты	страна
	индекс
	область
	район
	город
	населенный пункт	используется для поселений в пределах городской черты или микрорайонов застройки
	административный округ
	улица
	номер дома
	литер
	корпус
	номер помещения
Методы	разобрать	производит грамматический разбор заданной строки по элементам адреса, используя установленные формы записи
	собрать	возвращает «склеенную» адресную строку из значений атрибутов объекта
	сравнить	возвращает индекс ревалентности (соответствия) другому объекту типа «Адрес», либо строке адреса; используется для поиска или анализа положения объектов.
	добавить элемент	для нелинейного адреса увеличивает размерность на 1
	удалить элемент	для нелинейного адреса уменьшает размерность на 1

Для класса-прототипа «Адрес субъекта» предустановленными будут атрибут «страна»=Россия.

На рисунке 4.10 приведена экранная форма программной реализации «Адреса субъекта» для реестра балансодержателей. В данном случае адрес является одномерным, поэтому при создании объекта метод «добавить элемент» вызывается автоматически один раз, для пользователя же он явно не доступен.

Рисунок 4.10. Фрагмент модуля формирования адреса субъекта

Класс «Субъект» является производным для классов «Юридические лица» и «Физическое лицо». «Физическое лицо» в свою очередь имеет расширяющий класс «Предприниматели» (рис. 4.11). В таблицах 4.2-4.5 приведены общие описания данных классов.

Рисунок 4.11. Иерархия классов (в нотации UML)

Таблица 4.2. Класс «Субъект»

	Название	Описание
Атрибуты	Наименование полное	необходимо для печатных форм, поиска
	Наименование краткое	используется в отчетах, экранных формах
	ИНН	идентификационный номер налогоплательщика, может использоваться как естественный ключевой атрибут
	Адрес	объект типа «Адрес субъекта»
	Телефон
	Банковские реквизиты	объект включает необходимые атрибуты банковских счетов субъекта, методы добавления/удаления и редактирования этих параметров.
Методы	Добавить	конструктор класса
	Внести изменения	обычно с этим методом связаны процедуры ведения журналов изменений (кто, что и когда исправил), а также проверка на корректность изменяемой информации.
	Удалить	деструктор класса
	Сравнить	возвращает степень соответствия экземпляра заданному субъекту, необходим для поиска информации, обнаружения дублирования субъектов

В дочерних классах унаследованные поля и методы будут опускаться.

Таблица 4.3. Класс «Юридичекое лицо»

	Название	Описание
Атрибуты	Адрес юридический	переопределен атрибут «Адрес»
	Адрес почтовый	объект типа «Адрес субъекта»
	Коды статистики	ОКОНХ, ОКПО, СООГУ, СОАТО и др.
	Правовая форма	для значений необходимо использовать общероссийский классификатор; можно ограничить список значений лишь необходимыми в конкретной системе (с сохранением общих кодов)
	Форма собственности
	Руководитель	должность и ФИО руководителя
	Главный бухгалтер
	Признак субъекта малого предпринимательства	показывает, определено ли данное юридическое лицо как субъект малого предпринимательства

Таблица 4.4. Класс «Физическое лицо»

	Название	Описание
Атрибуты	Адрес прописки	переопределен атрибут «Адрес»
	Адрес фактического проживания	объект типа «Адрес субъекта»
	Дата рождения	является неизменным атрибутом физического лица, поэтому
	Паспортные данные	объект

Таблица 4.5. Класс «Предприниматель»

	Название	Описание
Атрибуты	Свидетельство о предпринимательской деятельности	объект, содержащий регистрационные атрибуты соответствующего свидетельства

На рисунках 4.11, 4.12 показаны экранные формы программной реализации описанных классов в модуле реестра арендаторов.

Для базового класса «Объект» в имущественно-земельной системе объектная схема может быть продолжена следующим образом (рис.4.13):

Детализация класса «Право» приведена на рис. 4.14:



Рассмотрим, например, подробнее методы работы с информационным объектом земельный участок.

Можно выделить следующие основные характеристики:

· Кадастровый №

· Адрес участка

· Классификация

· Экспликация

· Планшеты

· Топография

· Сервитуты

Для Адреса участка (уровень города) класс-прототип предопределен по параметрам: «страна»=Россия, «область»=Тюменская, «район»=Тюменский, «город»=Тюмень, «номер помещения»=NULL. Адрес земельного участка чаще всего является многомерным, такая особенность должна учитываться при заполнении адресных характеристик.

Классификация участка проводится по следующим параметрам:

· целевому назначению;

· типу использования;

· типу (качеству);

· форме собственности;

· зоне градостроительной ценности;

Эти данные являются информационной основой для «формы 22» (основной государственный отчет о наличии земель и распределении их по формам собственности, категориям, угодьям и пользователям), поэтому все изменения, связанные с данной информацией об участке должны храниться в хронологическом порядке.

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

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

Сервитуты включает следующие позиции: номер изменения данных о сервитутах; классификатор сервитутов; площадь сервитута; текстовая информация (описание сервитута); дата начала; дата окончания; признак действия сервитута.

Участок имеет следующие топографические характеристики: номер точки на границе участка; Х-координата; Y-координата.

Для работы с топогеодезическими данными была выбрана технология использования методов обеспечивающих визуализацию участка с помощью OLE встраивания объекта MapInfo или MapX. Поскольку это предполагает дублирование координат участка в базе и специфической внутренней таблице встроенного объекта, то здесь приходится разрабатывать собственные средства контроля за совместным доступом к координатам и их множественному обновлению. На рисунке 4.14 представлены фрагменты автоматизированного рабочего места использующего информационный объект земельный участок. В частности показана работа таких методов как редактирование координат, земельного участка, визуализация, поиск атрибутивных данных. При вызове соответствующего метода информационного объекта земельный участок происходит переадресация к соответствующим процедурам СОМ сервера MapInfo или MapX.

На рисунке 4.15 демонстрируется результат работы метода информационного объекта земельный участок - печать топоплана.



Информационный объект Земельное дело (рис. 4.16) содержит данные об юридических отношениях субъектов и земельных участков, а также документы, на основании которых было получено право владения, номер заявки, даты регистрации, сделки, заключения договора, тип владения, номер земельного дела, количество долей во владении, общее количество долей на участке. Стандартные для информационного объекта методы создания, обновления и удаления экземпляра содержат многочисленные проверки, гарантирующие целостность базы данных.



Далее рассмотрим расширение виртуального объекта «Право» классом «Аренда». Данный класс описывает вид арендного обязательства, сроки договора, назначение, сведения государственной регистрации, документы и т.д. Для него определяются методы: заключить, перезаключить, пролонгировать, аннулировать, расторгнуть. С объектами этого класса тесно связан информационный объект «Лицевой счет», в котором отражается финансовая сторона: расчет арендной платы, отслеживание платежей, зачетов, перемещений, взысканий по суду, расчет недоимки и начисление штрафных санкций (рис. 4.17).

На рисунках 4.18-4.21 представлены формы программной реализации учета договоров аренды, которая является специализированным модулем на информационной базе имущественного кадастра.

Объект «Лицевой счет» и порождаемые им объекты являются вспомогательными (вторичными) по отношению к кадастровым объектам. Действительно, с точки зрения объекта «Аренда» классу «Лицевой счет» делегировано управление его свойствами «Сумма аренды» и «Сальдо». «Лицевой счет» для определения значений этих атрибутов должен вызвать свои методы «рассчитать сумму за весь срок договора» и «рассчитать общее сальдо», которые в свою очередь вызывают методы реализующих эти функции классов (в нашем случае классов «Арендная ставка» и «Сводная ведомость»).

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

4.4 Экономическая эффективность внедрения кадастровых информационных систем

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

· снижения стоимости обработки и ввода-вывода данных в системе, предусматривающей однократный ввод данных и многократное их использование;

· устранение дублирования информации при ее сборе, обработке и хранении;

· повышения оперативности обслуживания потребителей информации, качества документов, достоверности информации;

· обеспечения полной комплектности представления документации для осуществления и регистрации различных сделок с кадастровыми объектами;

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

· возможный экономический эффект за счет информационного обслуживания на платной основе организаций и физических лиц.