Авторизация

Логин:
Пароль:
Восстановить пароль
Регистрация
  • Форум
  • Блоги
  • Контакты
  • Новости
  • Продукты
  • Отрасли
  • Обучение
  • Поддержка
  • События
  • О компании
  • 1 (56) | 2011 Возможности моделирования данных в ГИС: попытка сравнения

    Андрианов В.Ю., ДАТА+, e-mail: vladimir_andrianov@dataplus.ru

     

    Data modeling in GIS

     

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

    Общаясь с действующими и потенциальными пользователями ГИС, часто приходится слышать мнение или отвечать на вопрос, какой ГИС-пакет лучше. Готового ответа на все случаи нет, поскольку производители программного обеспечения ориентируются на разные сегменты рынка и/или следуют разным стратегиям развития и продвижения своего продукта. Только вникнув в текущие и будущие потребности заказчика, можно определить, какой продукт будет для него наилучшим.

    Сравнения продуктов иногда проводят независимые издания и ассоциации, но проблема их в том, что сравнивается лишь то, что лежит на поверхности: наборы технических характеристик (data sheets), интерфейс, иногда – скорость выполнения операций. В реальном же применении обычно не эти факторы являются главными. Более важную роль играют фундаментальные различия, т.е. те принципы, которые положены в основу продукта и стратегию его развития. Соответственно, при выборе нужно проанализировать эти принципиальные позиции, и уже исходя из этого оценивать, насколько каждый продукт или технология хороши для той или иной задачи, для того или иного потребителя.

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

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

    Другой пример – уже упомянутые линейные координаты. Они широко используются на практике (дороги, трубопроводы, ЛЭП и т.д.), однако поддерживаются не всеми ГИС-пакетами. Много лет назад компания Esri поступила весьма дальновидно, включив поддержку линейных координат (m-values) и высот (z-values) в спецификацию шейп-файла, что способствовало этому формату (вместе с открытостью и простотой спецификации) стать обменным стандартом де-факто. У других крупных разработчиков тоже поддерживаются линейные координаты, но лишь в специальных надстройках, а не на уровне ядра системы: у Intergraph – в GeoMedia® Transportation и WebMap Professional, у Autodesk и MapInfo – в продуктах сторонних разработчиков (MapInfo включил поддержку в ядро лишь в этом году). С одной стороны, такой подход дает более сфокусированный на определенной отрасли продукт, с другой – отсутствие универсальности механизма, не позволяющее использовать его в других отраслях. Это, кстати, один из ключевых моментов в стратегии разработчика, позволяющий ему держаться в своей нише на поле конкуренции. Так, Esri ориентируется на создание небольшого числа максимально универсальных продуктов, Intergraph – на создание множества готовых отраслевых решений, Autodesk и MapInfo – на прикладные решения сторонних разработчиков. У каждого подхода есть свои плюсы и минусы в разных условиях. Например, во многих странах имеется своя отраслевая специфика, затрудняющая применение готовых прикладных решений, созданных для рынков других стран. В то же время, если есть готовое решение для вашей отрасли в вашей стране, конечно, удобнее использовать его, нежели заказывать его изготовление на стороне или делать самим.

    Все современные ГИС-пакеты позволяют подключать таблицы из внешних баз данных к слоям цифровой карты, расширяя таким образом состав атрибутов (так называемое реляционное соединение таблиц). Однако это вовсе не означает, что такая ГИС приобретает возможности СУБД по полноценному моделированию данных, контролю их целостности и даже по использованию всей модели данных подключаемой базы данных – подключается лишь одна таблица, а не вся база данных, в которую она входит. Эта функция характерна для ГИС-пакетов предыдущего поколения, основанных на геореляционной модели векторных данных, в которой геометрия и атрибуты хранились в отдельных файлах. Типичными представителями были ArcView GIS и MapInfo. Сейчас же разработчики ПО ГИС ориентируются на интегрированную модель данных, в которой геометрия и атрибуты размещаются в общем хранилище под управлением стандартной СУБД. Эта модель используется в базе геоданных ArcGIS, в хранилище GeoMedia, в Oracle Spatial и др. Однако насколько полно используются преимущества этой модели – сказать можно только про ArcGIS, поскольку издательство Esri Press выпустило несколько книг, посвященных этой теме. Ключевая из них – "Моделирование нашего мира" Майкла Зейлера, ее дополняют ряд других из серии "Проектирование баз геоданных". Из этих книг легко можно видеть, что схема базы геоданных может детально моделировать огромное многообразие различных явлений реального мира, и для этого не надо писать какой-то специальный программный код, достаточно использовать "обычные" среды проектирования баз данных, остальное возьмет на себя ArcObjects.

    Помянув среды проектирования, следует отметить вот еще какой момент. Сейчас практически все разработчики ПО ГИС перешли от использования собственных языков расширения и средств разработки приложений к использованию "стандартных" сред и языков. Рудимент в виде своего языка сохранился лишь у MapInfo в виде MapBasic и у прежней ArcView GIS в виде Avenue. Создание приложений на основе объектно-компонентной модели (COM) – не то же самое, что проектирование моделей данных. В первом случае создается программный код, который манипулирует данными, во втором – определяется структура хранилища данных и, возможно, некоторые функции обработки данных. То есть, программные объекты-компоненты – не то же самое, что и объекты модели данных, так же как и классы программных объектов не являются классами объектов данных.

    Сейчас стало модно говорить об "объектной ориентированности" моделей данных и геоинформационных систем, хотя не во всех случаях авторы таких заявлений и те, кто их слушает/читает одинаково и правильно понимают этот термин. Путаница возникает, видимо, из-за того, что элементарной единицей традиционных карт является объект местности. В векторной модели данных ему соответствует пространственный объект. И тогда получается, что любую векторную ГИС можно назвать объектно-ориентированной?... Конечно, это не так. Понятие это пришло из области проектирования информационных систем, а именно из объектно-ориентированного проектирования (ООП). Суть его в том, что информационная система (программный код, а не карта) строится из кирпичиков, называемых объектами, а выполнение алгоритма в традиционном программировании заменяется на взаимодействие объектов в объектно-ориентированном программировании. Ключевыми понятиями ОО-подхода являются абстрагирование, инкапсуляция, наследование и полиморфизм. Применительно к ГИС это значит, что:

    а) все пространственные объекты должны разбиваться на классы однородных объектов (такие как реки, населенные пункты, трубопроводы, озера, ЛЭП и т.д.);

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

    в) классы должны строиться в виде иерархии из более детальных и менее детальных (например, общий класс "дорога" разбивается на подклассы "автодорога" и "железная дорога");

    г) управление объектами подклассов должно быть возможно посредством методов надклассов (например, топология сети не зависит от того, какой это вид транспорта – автомобильный или железнодорожный).

    Первый принцип так или иначе реализован во всех ГИС-пакетах, а третий применяется при создании хранилищ пространственных данных в среде современных реляционных СУБД. К сожалению, мне не удалось найти информацию о реализации всех этих принципов в иных продуктах, нежели ArcGIS (раздел сервера Intergraph, в которых нашлись нужные ключевые слова, не был доступен). В базе геоданных – хранилище данных ArcGIS – класс объектов, как абстрактная сущность схемы базы данных, представляется в виде таблицы, каждая запись которой является объектом. А поведение этих объектов реализуется программным кодом ArcObjects. В ядре ArcGIS реализованы некоторые виды поведения, такие как контроль значений атрибутов и передача уведомлений между объектами. На основе этих механизмов построена активная функциональность базы геоданных: атрибутивные домены и классы отношений. Для их использования не надо ничего программировать, но если потребуются другие виды поведения, можно прибегнуть к программированию в "стандартных" средах типа Microsoft Visual Studio.

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

    Нормализация модели данных позволяет значительно повысить качество данных за счет средств контроля их целостности. Под целостностью понимается соответствие реальных элементов данных формальным правилам, установленным схемой (моделью) данных. Частным случаем является ссылочная целостность – обязательность ссылаться только на существующие объекты данных. Например, применение доменного класса улиц в ArcGIS позволяет гарантировать, что в атрибутах записей не будет ошибочных названий улиц, т.к. ввести можно только названия из домена (называемого также справочником или списком). Кстати, здесь надо учитывать, что нормализация модели данных (выполняется на этапе проектирования) – не то же самое, что нормализация самих данных (выполняется при вводе данных). Для первой нужны развитые средства проектирования, вторая может реализовываться разными средствами, одним из которых являются атрибутивные домены, поддерживаемые ArcGIS и промышленными СУБД типа Oracle.

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

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




    Версия для печати