Атрибутивная информация

Структура

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

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

Обработка

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

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

Логический запрос. Предположим, мы обрабатываем базу данных по ряду квартир. Нам нужно выбрать все те, у которых число комнат более 2-х.

На языке SQL этот запрос выглядел бы так:

SELECT ( FROM Sells

WHERE Roomcount > 2

В ArcView (а его язык запросов базируется на SQL) этот же запрос задается следующим образом:

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

Анализ

Атрибутивные базы данных не только помогают по-разному отобразить объекты с различными свойствами. При выполнении пространственных запросов атрибутика помогает более точно идентифицировать объект - в самом простом случае мы можем указать объект на карте и получить о нем подробную информацию (номер, имя, размер и т.д.) Можно, разумеется, организовывать выбор объектов на карте посредством запросов к атрибутивной таблице, так как мы знаем, что выделение объектов связано с выделением их атрибутивных записей. В любой ГИС можно организовать запрос к атрибутике. Предпочтение отдается двум формам: языку запросов наподобие SQL (Structured Query Language), или шаблону, совпадающие с которым записи и выделяются. Последний называется QBE (Query By Example).

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

Подходы

В наиболее простом случае используются внутренние базы данных - то есть ГИС работает с ними на уровне файлового обмена, и поддерживает только несколько определенных. Это почти всегда dBase, более экзотичны Paradox и R:Base. Применение ASCII Delimited хотя и обеспечит восприятие Вашей базы данных большинством систем, однако скоростные характеристики при работе с ним весьма низки. У наиболее популярного в ГИС формата dBase II есть серьезное ограничение в 65 тыс. записей и размер одной записи не более 4 Кб, у других форматов ограничения также реальны. Чтобы избежать проблем при росте БД, можно прибегнуть к помощи внешних баз данных.

Внешние базы данных

Технология обмена с внешними базами данных заключается не в работе с их файлами напрямую, а в обращении к интегратору баз данных. В среде Windows из таких наиболее известный ODBC (Open DataBase Connectivity), другой интегратор - IDAPI производства Borland. Суть состоит в том, чтобы уже интегратор брал на себя проблемы работы или с файлами баз данных, или выполнял свою работу через "большие" СУБД, такие как Oracle, Informix и т. д. Во-первых, "верхняя планка" размерных ограничений таких баз гораздо выше, а во вторых, в руки ГИС дается простое и эффективное средство работы практически с любой БД. Однако взаимодействие с внешней базой все же сильно отличается от внутренней. Самым лучшим вариантом для ГИС было бы, несомненно, если бы работа с внешней БД проходила идентично внутренней, реально же в каждой геоинформационной системе оно имеет свою специфику. Так, ArcView, Atlas GIS, скажем, ограничиваются копированием по SQL-запросу части внешней базы данных во временную внутреннюю, что, конечно, не является удовлетворительным решением для серьезных задач анализа информации. Такая система обмена является по сути и односторонней - об обновлении данных из ГИС во внешнюю базу речь не идет.