Блог

Теленков О.С., Гребенникова Л.Н., Дутиков Д.Н., Нерослов Ю.М.
Предложения по инфраструктуре базовых пространственных данных в Уральском федеральном округе

Предложены основные принципы построения архитектуры “сервер баз данных – сервер приложений” для сбора, хранения и использования базовых пространственных данных

Для реализации проекта создания инфраструктуры пространственных данных необходимо определиться по следующим основным вопросам:

1. Выбор реализации архитектуры “сервер баз данных – сервер приложений”
2. Организация распределенного хранения данных
3. Способы предоставления данных к использованию в прикладных информационных системах

Выбор реализации архитектуры “сервер баз данных – сервер приложений”

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

 http://www.cnews.ru/reviews/free/infrastructure2005/articles/service_desk.shtml 

“….Логическая архитектура всех программных решений Service Desk построена на двух основных подсистемах — организации данных и реализации логики обработки этих данных. Первая выполняет расширенные задачи СУБД и отвечает на вопросы о том, какие данные нужны для работы системы, какие данные необходимы для работы пользователям, какова структура и взаимные отношения этих данных, как эти данные хранятся, как обеспечивается их целостность и другие. Вторая подсистема выполняет функции сервера операций и контролирует, в частности, взаимодействие различных пользователей системы, механизмы автоматизации процедур и характер изменения данных.

С технической точки зрения базовой здесь является архитектура «сервер приложений-сервер баз данных», и в основном решения отличаются друг от друга тем, как распределены функции по обслуживанию структуры данных и обеспечена логика работы между сервером приложений и сервером баз данных. Рассмотрим с этих позиций решения HP Service Desk, Peregrine Service Center и BMC Remedy ITSM.

Три решения Service Desk: ловим ньюансы:

В решении НР для размещения данных, а также их структуры и логики обработки используются ресурсы промышленных СУБД. Сервер приложений в этом случае используется лишь как средство визуализации данных и частично для балансировки нагрузки, то есть фактически HP Service Desk является СУБД-ориентированной системой.

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

В архитектуре Remedy ITSM реализована прямо противоположная концепция: БД выступает в качестве простого хранилища данных, а вся информация об их структуре, а также логика обработки перенесены на сервер приложений. Основой же решения является многофункциональная платформа разработки систем автоматизации процессов Remedy Action Request System (ARS), которая обеспечивает создание как централизованных, так и распределенных систем. Наличие в качестве ядра мощного средства разработки обеспечивает широкие возможности по интеграции с различными внешними системами и модернизации ПО под уникальные требования заказчика. В то же время подобная гибкость имеет и свои отрицательные стороны, поскольку всегда есть опасность автоматизировать неэффективные ИТ-процессы или же бесконечно затянуть проект внедрения, постоянно внося различные дополнения и улучшения. В этом случае успех во многом зависит от четкой проработки будущих ИТ-процессов, квалификации команды инсталляторов и твердой позиции руководителя ИТ-службы. К тому же на управление проектом накладываются требования жесткого контроля уровня и числа переделок и доделок. Вместе с тем эффект от внедрения решения Remedy может значительно перекрывать подобные издержки.

Компания Peregrine Systems реализовала компромиссный вариант, разместив данные и их структуру на сервере БД, а логику — на сервере приложений. Таким образом, изменения структуры данных оказывают слабое влияние на логику их обработки. Поэтому риски, связанные с адаптацией этого программного продукта в соответствии с условиями заказчика, значительно ниже, чем в HP Service Desk, хотя и выше, чем у Remedy. В то же время у Peregrine Service Center опасность впасть в бесконечные переделки ниже, чем в случае с Remedy, поскольку создание распределенных конфигураций обеспечивается специальными модулями синхронизации данных между различными компонентами. К слову, те же средства используются и для интеграции с внешними системами….”

Для формирования инфраструктуры пространственных данных предлагается принять архитектуру, подобную  Remedy ITSM, что обеспечит свободу в выборе СУБД для информационного хранилища и платформ для реализации серверов приложений. В Институте минералогии УрО РАН такой подход реализуется уже на протяжении многих лет, в том числе, и для разработки систем, использующих пространственные данные. Для упрощения (стандартизации) разработки серверов приложений в части организации логической структуры данных в различных предметных областях, предлагается использование некоторых соглашений при формировании набора таблиц в базе данных для хранения пространственной привязки объектов и прочих их свойств и атрибутов:

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

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

Группа проектов (группа карт, карты)
Группа карт (карты)
Карта (слои)
  Слои (слой данных, объединение слоев, раздел-заголовок, присоединенная карта)
   Слой данных (вектор, растр)
   Oбъединение слоев (слой1, …слой n)
   Pаздел-заголовок
   Присоединенная карта

1. Использование единой системы стандартных справочников и базовых данных. Неполный (пополняемый) перечень которых приведен ниже со ссылками на web-интерфейсы отображения их содержания:

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

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

   В итоге сводная схема хранения пространственных данных должна выглядеть так:

   

   Организация распределенного хранения данных

   Способы предоставления данных к использованию в прикладных информационных системах

   Конвертирование в стандартные и нестандартные структуры

   Сервисы на портале базовых пространственных данных (конструктор ГИС-проектов)