загрузка...

Базы данных и управление ими

  Совокупность цифровых данных о пространственных объектах образует множество пространственных данных и составляет содержание баз географических данных, определяет принципы построения информационного обеспечения ГИС.
Анализ общего состава данных необходим уже на этапе проектирования ГИС и требует ответа, по крайней мере, на ряд основных вопросов:
— имеется ли возможность сбора, хранения и обновления географических данных? каковы ожидаемые объемы данных и их форматы? какой объем данных необходимо преобразовать в цифровую форму, сколько времени это займет и сколько будет стоить? каковы качество и надежность данных? какого рода затруднения могут возникнуть при обработке собранных данных?
Проектирование географических баз и банков данных. Выявление географических объектов и явлений и последующий выбор адекватного представления данных о них являются составной частью процесса, именуемого проектированием базы данных (БД).
В ГИС пользователь рассматривает реальный мир через призму тематической базы данных. Измерения и выборки, содержащиеся в базе данных, должны как можно полнее и точнее соответствовать предмету исследования и его основным характеристикам. Представление данных должно учитывать типы их возможных преобразований. К созданию БД ГИС предъявляются высокие требования, связанные с пространственной формой организации и представления данных [И. К. Лурье, 2002].
Требования к базе данных. База данных должна быть: согласованной по времени — хранящиеся в ней количественные данные должны соответствовать определенному времени, быть актуальными; полной, достаточно подробной для предполагаемого создания ГИС или картографического произведения; категории данных и их подразделения должны включать все необходимые сведения для осуществления анализа или математико-картографического моделирования исследуемого объекта или явления; позиционно точной, абсолютно совместимой с другими данными, которые могут добавляться в нее; достоверной, правильно отражающей характер явлений, для этого необходимо четко определить включенные в нее атрибуты явлений; легко обновляемой; доступной для любых пользователей.
Проектирование базы данных. В процессе проектирования БД обычно выделяют три основных уровня: концептуальный, логический и физический.
Концептуальный уровень не зависит от имеющихся аппаратных и программных средств. Для БД ГИС он связан с концептуальной моделью географических данных и включает: описание и определение рассматриваемых объектов; установление способа представления географических объектов в базе данных; выбор базовых типов пространственных объектов — точки, линии, ареалы, ячейки растра; решение вопроса о способе представления размерности и взаимосвязей реального мира в БД (например, следует ли показать здание в виде ареала или точки). На концептуальном уровне опре-



Город

Численность населения, чел.

.ЛГ-координата

У-координата

Страна
/>Вена
1875000

16,320990

48,202120

Австрия

Лондон

11100 000

-0,177998

51,487910

Велико
британия

Амстердам

1860000

4,894833

52.373040

Нидерланды

Осло

720000

10,712310

59,937930

Норвегия

Москва

13100000

37,938250

55,764230

Россия

Вашингтон

3221400

-76,953830

38,890910

США

в
Рис. 16. Модели баз данных: а — иерархическая; б — сетевая; в — реляционная

деляется и содержание базы данных, в свою очередь определяемое сутью явления, характером его пространственного распространения и задачами, для которых создается БД. Здесь следует выделить задачи создания одной или серии карт, комплексного картографирования, создания синтетических карт для многоцелевого и многократного использования.
Логический уровень определяется имеющимися программными средствами и практически не зависит от технического обеспечения. Он включает разработку логической структуры элементов базы данных в соответствии с системой управления базами данных (СУБД), используемой в программном обеспечении. Наиболее распространенными логическими структурами — моделями БД и их СУБД — являются иерархическая, сетевая, реляционная (рис. 16).
В иерархической модели (рис. 16, а) записи данных образуют древовидную структуру, при этом каждая запись связана только с одной записью, находящейся на более высоком уровне. Доступ к любой записи осуществляется по строго определенным «веткам» и узлам такого дерева. Иерархические модели хорошо подходят для задач с явно выраженной иерархически соподчиненной структурой информации и запросов. Они обладают низким быстродействием, трудно модифицируемы, но эффективны с точки зрения организации машинной памяти.
В сетевых моделях (рис. 16, б) каждая запись в каждом из узлов сети может быть связана с несколькими другими узлами; кроме данных записи содержат указатели, определяющие местоположение других записей, связанных с ними. Такие модели очень трудно редактировать, например удалять записи, так как вместе с данными нужно редактировать и указатели. Подобные модели хорошо работают в случае решения сетевых, коммуникационных задач.
В иерархической и сетевой моделях для поиска конкретной записи необходимо вначале определить путь доступа к записи, а затем просмотреть все записи, находящиеся на этом пути.
Реляционные СУБД завоевали самую широкую популярность. Они свободны от всех ограничений, связанных с организацией хранения данных и спецификой запоминающих устройств. Эти модели имеют табличную структуру (рис. 16, в): строки таблицы соответствуют одной записи сведений об объекте, а столбцы — поля — содержат однотипные характеристики всех объектов. Всевозможные способы индексации данных существенно сокращают время поиска и запроса к данным. К числу наиболее известных СУБД реляционного типа относятся dBASE, Clipper, Foxbase, Paradox, ORACLE (последняя особенно подходит для больших объемов данных).
Физический уровень связан с аппаратными и программными средствами. На этом уровне определяются объемы хранимой в БД информации и необходимые объемы памяти компьютера (оперативной и долговременной), рассматриваются вопросы о структурировании файлов на диске или других носителях информации для обеспечения программного доступа к ним, представления данных в памяти компьютера (целые, действительные числа, байты или буквенно-цифровые характеристики).
Позиционная и атрибутивная составляющие данных. Пространственные данные, как упоминалось ранее, традиционно подразделяются на две взаимосвязанные составляющие — позиционные и непозиционные.
Позиционная составляющая характеризует положение географических объектов (или пространственную форму) в координатах двух- и трехмерного пространства — декартовых (х,у, z) или географических (ф, X).
Непозиционная составляющая данных включает качественную характеристику пространственных объектов (семантику) и статистику; эта информация называется атрибутивной и представляется в виде текстовых или числовых параметров. Она соответствует тематической форме данных или кодированному представлению взаимосвязей объектов (топологии). Почти всегда тип объекта маркируется и опознается по его атрибутивным параметрам (дорога имеет название и идентифицируется по ее классу — грунтовая, с асфальтобетонным покрытием). Обычно атрибутивная информация не имеет пространственного характера, хотя некоторая ее часть может быть связана с пространственной природой изучаемого объекта, например, площадь, периметр.
В качестве атрибутивной информации часто выступает время (временная форма), которое может отражаться несколькими способами: указанием временного периода существования объектов, соотнесением информации с определенными моментами времени, указанием скорости движения объектов.
Количественные атрибуты создаются в соответствии с номинальными, порядковыми, интервальными или пропорциональными шкалами измерений. Важно знать, какие шкалы измерений использованы для данных, поскольку это определяет характер возможных математических операций с ними.
Как упоминалось ранее, составляющие пространственных данных кратко называют геометрией и атрибутами.
Представление тененных, линейных и площадных объектов в базе данных и на цифровой карте. В БД ГИС картографические источники и итоговые карты представляются в виде цифровых карт (см. 2.1.3) [Геоинформатика, 1999].
Любая БД состоит из цифровых представлений дискретных объектов. Содержание карты можно хранить в БД в виде цифровой карты, превратив объекты карты в объекты базы данных. Правда, всегда нужно помнить о том, что многое из показанного на картах умозрительно не представлено в реальном мире: горизонтали в природе не существуют, а вот дома и озера — это реальные объекты.
Итак, географические объекты, моделируемые с помощью карты или ГИС, имеют три формы представления: объект в действительности; объект, представленный в базе данных (некоторые авторы вводят для таких объектов наименование «предмет»!: знак, который используется для показа объекта (предмета) на карте или на другом графическом изображении.
Мы будем во всех случаях использовать наименование «объект», поскольку о чем идет речь, обычно понятно из контекста.
Предназначенный для отражения в БД или цифровой карте объект — это явление действительности, последнее в ряду подразделения однотипных явлений при выборе «элементарных кирпичиков» для информационного моделирования [А. В. Кошкарев, 2000]; например, город можно считать объектом, при его подразделении на составные части они уже будут не городами, а районами, кварталами и т.п.
Объект в БД — это цифровое представление всего реального объекта или его части. Способ цифрового представления объекта зависит от назначения ГИС, масштаба исследования, его задач и других факторов, например, географически город может бьггь представлен в виде точки, если рассматриваемая территория имеет масштабы материка; если речь идет о базе географических данных области, тот же город может быть представлен ареалом.
Сходные явления, информация о которых хранится в базе данных, определяются как типы объектов — любая группа сходных явлений, которые должны иметь одинаковую форму хранения и представления, например дороги, реки, высоты, растительность; тем самым обеспечивается основа для формирования общего атрибута явлений. Каждый тип объектов должен быть точно определен, что помогает выявить перекрывающиеся категории данных и вносит ясность в содержание базы данных.
Основные элементы базы данных. Для цифрового представления типов реальных объектов необходимо выбрать подходящую форму объектов, являющихся представителями первых (кодами) в базе пространственных данных. Их классификация может быть основана на представлении пространственной размерности (см. 2.1.2).
Такие объекты хорошо отражают тип пространственной локализации реальных объектов. Они могут быть объединены в классы,' например множество точек для представления множества городов.
Пространственные типы объектов БД могут группироваться в слои, именуемые также покрытиями или темами. Один слой представляет один тип объектов или группу концептуально взаимосвязанных типов объектов. Например, слой может включать только отрезки водотоков, или же водотоки, озера, береговую линию и болота. Возможны самые разные варианты системы слоев, как и модели данных. Некоторые базы пространственных данных создаются путем объединения всех объектов в один слой.
Одни и те же географические явления можно представить в разных масштабах и с разной точностью. Переход от одного представления к другому достаточно сложен, например переход от мелкого масштаба (1:250000) к крупному (1:10000). Поэтому часто встречаются базы данных, содержащие множественные представления одних и тех же явлений. Это неэкономно, но избежать этого пока не удается, ибо соответствующие методы перехода еще недостаточно разработаны.
Системы управления базами данных в ГИС. Как правило, ГИС создаются на основе уже существующих систем управления базами данных (СУБД), приобретение или аренда СУБД составляет основную часть затрат на программное обеспечение системы. СУБД выполняет множество функций, которые в противном случае следовало бы программировать в ГИС. Различают два пути использования СУБД в ГИС: выполнение ГИС-процедур полностью через СУБД, тогда доступ ко всем данным осуществляется только через СУБД и все данные должны удовлетворять требованиям, заложенным при ее разработке; некоторые данные (обычно таблицы атрибутов и их отношений) доступны через СУБД, поскольку они вполне соответствуют модели, а к некоторым данным (обычно пространственно локализованным) доступ прямой, так как они не удовлетворяют требованиям модели СУБД.
ГИС добавляет географический аспект к уже существующим методам поиска и запроса. Сложность и разнообразие представления данных в ГИС, различимость в представлении позиционной и атрибутивной составляющей информации, необходимость ее обработки в контексте пространственной близости предъявляют своеобразные и повышенные требования к СУБД по сравнению с традиционной формой их использования.
Функции СУБД. Каждую СУБД принято характеризовать способностью выполнять следующие основные функции [К. Дейт, 1980; Дж.Ульман, 1983]: управление данными во внешней памяти; управление буферами оперативной памяти; операции над БД; обеспечение надежности хранения данных в БД; поддержка языка управления БД.
Управление данными во внешней памяти. Эта функция обеспечивает организацию структуры внешней памяти как для хранения данных, входящих в БД, так и для служебных целей, например, для ускорения доступа к данным. В некоторых СУБД используются возможности файловых систем, в других работа производится на уровне функционирования устройств внешней памяти. В любом случае пользователи СУБД не обязаны знать, какая структура используется или как организованы файлы. Обычно в СУБД создается собственная система наименования объектов БД.
Управление буферами оперативной памяти. СУБД обычно работают с БД значительного размера, существенно большего доступного объема оперативной памяти. Для того чтобы СУБД не зависела от скорости работы устройств внешней памяти, используется организация собственных наборов буферов оперативной памяти с определенными правилами замены и обновления буферов.
Операции над БД. Последовательность операций над БД, рассматриваемых СУБД как единое целое, называется транзакцией. При выполнении транзакции СУБД либо фиксирует во внешней памяти изменения в БД, произведенные этой транзакцией, либо не производит никаких изменений. Понятие транзакции важно для сохранения логической целостности БД, особенно в многопользовательских СУБД. Каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения. При эффективном управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может ощущать себя единственным ее пользователем.
Управление транзакциями в многопользовательской СУБД осуществляется с помощью специальных операций, которые объединяют транзакции одного пользователя в серии (сериализация транзакций), при этом суммарный эффект смеси транзакций эквивалентен эффекту их последовательного выполнения. Существует несколько базовых алгоритмов сериализации транзакций, среди которых наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД.
Обеспечение надежности хранения данных в БД. Одним из основных требований к СУБД является надежность хранения данных во внешней памяти, т.е. СУБД должна обладать способностью восстановления последнего согласованного состояния БД после любого аппаратного или программного сбоя. Возможны два вида аппаратных сбоев: «мягкие» сбои, которые приводят к внезапной остановке работы компьютера (например, аварийное выключение питания), и «жесткие» сбои, характеризуемые потерей информации на носителях внешней памяти. Программные сбои — это аварийное завершение работы СУБД или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Для восстановления БД нужно располагать некоторой дополнительной информацией, что требует избыточности хранения данных. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.
Журнал — это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических лисках), в которую поступают записи обо всех изменениях основной части БД. Самая простая процедура обеспечения надежности восстановления БД — откат транзакции, выполненной пользователем, для чего все записи от одной транзакции связывают обратным списком от конца к началу (аналог Undo).
При «мягком» сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при «мягком» сбое пропадает). В таком случае во внешней памяти журнала должны обязательно находиться записи, относящиеся к операциям модификации обоих видов объектов. Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД.
Поддержка языков управления БД. Для работы с базами данных используются специальные языки, называемые языками баз дан-
ных. Первоначально в СУБД поддерживалось несколько специализированных по функциям языков. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language). Язык SQL позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов.
Язык SQL содержит специальные средства определения ограничений целостности БД, которые тоже хранятся в специальных таблицах-каталогах. Обеспечение контроля целостности БД производится на языковом уровне. Компилятор SQL для операторов модификации БД на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код.
Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить «видимость» БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне.
Наконец, авторизация доступа к объектам БД производится также на основе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными правами доступа к БД. Пользователь, создавший таблицу БД, обладает полным набором прав для работы с этой таблицей, в том числе правом разрешения доступа другим пользователям. Контроль прав доступа поддерживается на уровне языка.
Типовая организация СУБД. Организация типичной СУБД и состав ее компонентов соответствуют рассмотренному набору функций. СУБД представляет собой три взаимосвязанные компоненты: командный язык для выполнения требуемых операций с данными (ввод, вывод, модификация), интерпретирующую систему (или компилятор) для обработки команд и перевода их на язык машины, интерфейс пользователя для формирования запросов к БД (выборки нужных данных).
Логически в реляционной СУБД можно выделить:
. внутреннюю часть — ядро СУБД (часто его называют Data Base Engine);
. компилятор языка БД (обычно SQL); подсистему поддержки времени выполнения; набор утилит.
В некоторых системах эти части выделяются явно, в других — нет, но логически такое разделение можно провести во всех СУБД.
Ядро СУБД отвечает за управление: данными во внешней памяти, буферами оперативной памяти, транзакциями, а также за ведение журнала. Компоненты ядра — это соответственно менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала. Для обеспечения корректной работы СУБД все эти компоненты должны взаимодействовать по тщательно организованным протоколам. Ядро СУБД является основной резидентной частью СУБД, а в архитектуре «клиент-сервер» — основной составляющей серверной части системы.
Основной функцией компилятора языка БД является перевод операторов языка БД в некоторую выполняемую программу. Результатом компиляции является выполняемая программа, представляемая в некоторых системах в машинных кодах, но более часто во внутреннем машинно-независимом коде.
В отдельные утилиты БД обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка БД, например загрузка и выгрузка БД, сбор статистики, глобальная проверка целостности БД и т.д. Утилиты программируются с использованием интерфейса ядра СУБД.
К числу достоинств реляционного подхода можно отнести: наличие небольшого набора приемов для простого абстрактного представления объектов большинства распространенных областей применения БД с интуитивно понятными и достаточно точными формальными определениями; наличие простого математического аппарата, опирающегося на теорию множеств и математическую логику, обеспечивающего основу реляционного подхода к организации баз данных; возможность манипулирования данными без необходимости знания конкретной физической организации баз данных во внешней памяти.
Отмеченные преимущества и постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привели к тому, что в середине 80-х годов XX в. реляционные системы практически вытеснили с мирового рынка ранние СУБД.
К недостаткам реляционных СУБД относятся некоторая ограниченность (как следствие простоты) их использования при сложных структурах данных, в том числе пространственно-определенных данных разных моделей, а также невозможность адекватного отражения семантики предметной области.
Базовые понятия реляционных баз данных. В преобладающем большинстве ГИС используются реляционные базы данных, поддерживаемые такими СУБД, как dBase, INFO, ORACLE, INFORMIX и т. п. Такие БД позволяют разработчикам ГИС разделить проблему управления пространственными данными на две части: как представлять геометрию объектов и топологию пространственных объектов (вектор или растр) и как работать с атрибутами этих объектов. Для этого пригодны реляционные СУБД, управ-» ляемые ими модели данных иногда называют геореляционнымя моделями. Основные их преимущества таковы: нет необходимости хранить атрибуты с пространственными данными, но они всегда могут содержаться где-нибудь в системе или поставляться, например, по сети; атрибуты могут быть изменены или удалены без изменения пространственной БД;
. коммерческие реляционные СУБД стандартны и могут управляться стандартными запросами; хранение атрибутивных данных в реляционных БД не противоречит основным принципам слоев в ГИС; атрибуты могут быть привязаны к пространственным единицам и представлены разными способами.
Основными понятиями реляционных баз данных являются: тип данных, домен, атрибут, кортеж, первичный ключ и отношение.
Понятие тип данных полностью адекватно понятию типа данных в языках программирования. Обычно в реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких, как «деньги»), а также специальных данных — дата, время, временной интервал. Развивается подход к расширению возможностей реляционных систем абстрактными типами данных.
Понятие домен имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат «истина», то элемент данных является элементом домена. Наиболее правильное интуитивное понимание домена — допустимое множество значений определенного типа. Данные считаются сравнимыми только в том случае, когда они относятся к одному домену.
Отношение — это именованное множество пар {имя атрибута, имя домена (или типа)}. Если все атрибуты одного отношения определены на разных доменах, целесообразно использовать для наименования атрибутов имена соответствующих доменов.

Кортеж, соответствующий данной схеме отношения, — это набор именованных значений заданного типа.
Обычным представлением отношения является таблица, в заголовке которой указывают наименование отношения, а в строках — кортежи; в этом случае имена атрибутов именуют столбцы таблицы. Поэтому когда говорят «столбец таблицы», имеют в виду «атрибут отношения». Такой терминологии придерживаются в большинстве коммерческих реляционных СУБД.
Реляционная модель данных. Модель данных с точки зрения СУБД описывает некоторый набор родовых понятий и признаков, которыми должны обладать сама СУБД и управляемые ею базы данных, если они основываются на этой модели. Наличие модели данных позволяет сравнивать конкретные реализации, используя один общий язык.
Реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной, манипуляционной и целостной.
В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное отношение — некоторый определенный набор ограничений, свойственный этому отношению. Нормализация связана с поиском наиболее простой структуры для данного множества данных и имеет дело с зависимостью между атрибутами; она позволяет избежать потери общей информации при удалении или вводе записей. Существует несколько формальных типов нормализации (более пяти).
Манипуляционная часть модели определяет механизм манипулирования реляционными БД — реляционная алгебра и реляционное исчисление, базирующиеся на теории множеств и логическом аппарате исчисления отношений.
В целостной части реляционной модели данных фиксируются два базовых требования целостности: целостности сущностей и целостности по ссылкам. Объекту, или сущности, реального мира в реляционных БД соответствуют записи (кортежи'» отношений, и требование целостности состоит в сохранении отличий разных записей этого отношения; говорят, что любое отношение должно обладать первичным ключом.
Второе требование более сложно. Сущности реального мира представляются в реляционной БД в виде записей нескольких отношений. Для связи отношений используется атрибут, который служит внешним ключом. Отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом. Требование целостности по ссылкам состоит в том, что для каждого значения внешнего ключа должна найтись запись с таким же значением первичного ключа в отношении, на которое указывает ссылка, либо зна-
чение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать).              *
Выполнение таких требований чрезвычайно важно при модификации отношений или удалении записей. Поддержке целостности при удалении кортежа служат: запрет на удаление кортежа, на который существуют ссылки; автоматическая замена значения внешнего ключа на неопределенное во всех ссылающихся кортежах; автоматическое удаление всех ссылающихся кортежей.
Реляционные СУБД обладают рядом особенностей, влияющих на организацию внешней памяти. К наиболее важным особенностям можно отнести следующие: наличие двух уровней системы: уровня непосредственного управления данными во внешней памяти и языкового уровня (например, уровня, реализующего язык SQL); тогда подсистема нижнего уровня должна под держивать во внешней памяти набор базовых структур, конкретная интерпретация которых входит в число функций подсистемы верхнего уровня; информация, связанная с наименованием объектов базы данных и их конкретными свойствами (например, структура ключа- индекса), поддерживается подсистемой языкового уровня; регулярность структур данных во внешней памяти, поскольку основным объектом реляционной модели данных является плоская таблица; для выполнения операторов языкового уровня над одним или несколькими отношениями во внешней памяти поддерживаются дополнительные «управляющие» структуры — индексы; для выполнения требования надежного хранения баз данных поддерживается избыточность хранения данных во внешней памяти.
Следует подчеркнуть, что как бы ни были организованы индексы в конкретной СУБД, их основное назначение состоит в обеспечении эффективного прямого доступа к кортежу отношения по ключу. Обычно индекс определяется для одного отношения, и ключом является значение атрибута (возможно, составного). Организация индексов в больших БД представляет сложную проблему. Бее более популярным подходом к организации индексов является использование техники хэширования. Общей идеей методов хэширования является применение к значению ключа некоторой функции свертки (хэш-функции), вырабатывающей значение меньшего размера. Свертка значения ключа затем применяется для доступа к записи. В самом простом случае свертка ключа используется как адрес в таблице, содержащей ключи и записи.
Язык реляционных баз данных SQL. Функции и основные возможности. Язык для взаимодействия с БД — SQL (Structered Query Language) — появился в середине 70-х годов XX в. В настоящее время распространена его версия SQL/92. Язык ориентирован главным образом на удобную и понятную пользователям формулировку запросов к.реляционной БД и содержит, помимо операторов формулирования запросов и манипулирования БД, средства для определения схемы БД, ограничений целостности, структуры БД физического уровня, авторизации доступа к отношениям и их полям, позиций сохранения транзакции и откатов. Двумя фундаментальными языками запросов к реляционным БД являются языки реляционной алгебры и реляционного исчисления. Самый общий вид запроса на языке SQL представляет теоретико-множественное алгебраическое выражение, составленное из элементарных запросов.
В настоящее время SQL реализован практически во всех коммерческих реляционных СУБД, все фирмы провозглашают соответствие своей реализации стандарту SQL, и на самом деле реализованные диалекты SQL очень близки. Особенностью большинства современных коммерческих СУБД, затрудняющей анализ существующих диалектов SQL, является отсутствие полного описания языка.
В языке SQL поддерживаются следующие типы данных: CHARACTER, NUMERIC, DECIMAL, INTEGER, SMALLINT, FLOAT, REAL, DOUBLE PRECISION.
К первому типу относится CHARACTER. Спецификатор типа имеет ввд CHARACTER (length), где length задает длину строк данного типа. В SQL/89 нет строк переменного размера, хотя во многих реализациях они допускаются. Литеральные строки символов изображаются в виде «последовательности символов» (например, «example»).
Представителями второго типа являются NUMERIC, DECIMAL (или DEC), INTEGER (или INT) и SMALLINT. Спецификатор типа NUMERIC имеет вид NUMERIC ([precision], [scale]). Специфицируются точные числа, представляемые с точностью precision и в масштабе scale. Здесь и далее, если не указан масштаб, то он полагается равным 0, а если не указана точность, то ее значение по умолчанию определяется в реализации.
Спецификатор типа DECIMAL (или DEC) имеет вид NUMERIC ([precision], [scale]). Специфицируются точные числа, представленные в масштабе scale с точностью, равной или большей значения precision.
INTEGER специфицирует тип данных точных чисел в масштабе 0 с определяемой в реализации точностью. SMALLINT специфицирует тип данных точных чисел в масштабе 0 с определяемой в реализации точностью, не большей, чем точность чисел типа INTEGER.
К третьему типу относятся FLOAT, REAL, DOUBLE PRECISION.
Несмотря на то, что правила встраивания SQL в программы на языке Си не определены в SQL/89, в большинстве реализаций, поддерживающих такое встраивание, имеется следующее соответствие между типами данных SQL и типами данных Си: CHARACTER соответствует строкам Си; INTEGER — long;.SMALLINT — short; REAL — float; DOUBLE PRECISION — double (именно такое соответствие утверждено в стандарте SQL/92).
Описанный набор операторов SQL предназначен для встраивания в программу на обычном языке программирования. Поэтому в этом наборе перемешаны операторы «истинного» реляционного языка запросов и операторы работы с курсорами, позволяющими обеспечить построчный доступ к таблице — результату запроса. В диалоговом режиме набор операторов SQL и их синтаксис несколько другие, более сложные и динамичные. Примером может служить реализация языка в СУБД Oracle.
СУБД в архитектуре «клиент-сервер». Архитектура «клиент-сервер» обеспечивает простое и относительно дешевое решение проблемы коллективного доступа к базам данных в локальной сети, создавая некоторое подобие распределенных систем БД. Реальное распространение архитектуры «клиент-сервер» стало возможным благодаря развитию и широкому внедрению в практику концепции открытых систем. Основой этой концепции является упрощение комплексирования вычислительных систем при международной и национальной стандартизации аппаратных и программных интерфейсов.
Стимулом д ля развития концепции явились, с одной стороны, широкое внедрение локальных компьютерных сетей с комплексированием аппаратно-программных средств, с другой — бурное развитие технологий глобальных коммуникаций. Реальностью становятся и открытые ГИС-системы, несмотря на существующие проблемы в области стандартизации.
Ключевой позицией открытых систем, ориентированных на пользователей, является независимость от конкретного разработчика аппаратного и программного обеспечения. Приобретая любой продукт компании, придерживающейся стандартов открытых систем, потребитель не становится полностью от нее зависимым. Он может развивать свою систему, приобретая продукты любой другой компании, соблюдающей стандарты. Причем это касается как аппаратных, так и программных средств и не является необоснованной декларацией. Примерами всестороннего исследования и реализации подходов к созданию открытых ГИС-систем являются программные и технологические разработки крупнейших фирм- конкурентов ESRI и Intergraph — GEONET и GeoMedia соответственно.
Основой системных и прикладных программных средств открытых систем является стандартизованная операционная система. Технологии и стандарты открытых систем обеспечивают возможность производства программных средств, обладающих свойствами мобильности (portability) и интероперабельности (interoperability). Свойство мобильности означает сравнительную простоту перено-
са программной системы в различные аппаратно-программные среды, соответствующие стандартам. Интероперабельность означает упрощение разработки новых программных систем на основе комплексирования готовых компонентов со стандартными интерфейсами.              '
Использование подхода открытых систем выгодно и производителям, и пользователям. Прежде всего открытые системы решают проблемы поколений и версий аппаратных и программных средств. Все производители обязаны только обеспечивать некоторую стандартную среду. Преимуществом для пользователей является то, что они могут постепенно заменять компоненты системы более совершенными, не утрачивая работоспособности системы, решать проблемы постепенного наращивания вычислительных, информационных и других мощностей компьютерной системы.
В основе широкого распространения локальных сетей компьютеров лежит известная идея разделения ресурсов. Высокая пропускная способность локальных сетей обеспечивает эффективный доступ из одного узла локальной сети к ресурсам, находящимся в других узлах.
Развитие этой идеи приводит к функциональному выделению компонентов сети: разумно иметь не только доступ к ресурсам удаленного компьютера, но также получать от этого компьютера некоторый сервис, который специфичен для ресурсов данного рода и программные средства для обеспечения которого нецелесообразно дублировать в нескольких узлах.
Рабочая станция предназначена для непосредственной работы пользователя или категории пользователей и обладает ресурсами, соответствующими локальным потребностям данного пользователя. Специфическими особенностями рабочей станции являются: объем оперативной памяти (далеко не все категории пользователей нуждаются в наличии большой оперативной памяти); наличие и объем дисковой памяти (достаточно популярны бездисковые рабочие станции, использующие внешнюю память дискового сервера); характеристики процессора и монитора (некоторым пользователям нужен мощный процессор, других в большей степени интересует разрешающая способность монитора, для третьих обязательно требуются средства ускорения графики и т.д.). При необходимости можно использовать ресурсы и/или услуги, предоставляемые сервером.
Сервер локальной сети должен обладать ресурсами, соответствующими его функциональному назначению и потребностям сети. Заметим, что в связи с ориентацией на открытые системы, правильнее говорить о логических серверах (имея в виду набор ресурсов и программных средств, обеспечивающих услуги над этими ресурсами), которые располагаются не обязательно на разных компьютерах. Особенностью логического сервера в открытой системе является то, что если по соображениям эффективности сервер целесообразно переместить на отдельный компьютер, то это можно проделать без реконструкции как его самого, так и использующих его прикладных программ.
Примерами серверов могут служить: сервер телекоммуникаций, обеспечивающий услуги по связи данной локальной сети с внешним миром; вычислительный сервер, дающий возможность производить вычисления, которые невозможно выполнить на рабочих станциях; дисковый сервер, обладающий расширенными ресурсами внешней памяти и предоставляющий их в использование рабочим станциям и, возможно, другим серверам; файловый сервер, поддерживающий общее хранилище файлов для всех рабочих станций; сервер баз данных — фактически обычная СУБД, принимающая запросы по локальной сети и возвращающая результаты.
Сервер локальной сети предоставляет ресурсы рабочим станциям и другим серверам.
Принято называть клиентом локальной сети запрашивающего услуги у некоторого сервера и сервером — компонент локальной сети, оказывающий услуги некоторым клиентам.
Хотя обычно одна база данных целиком хранится в одном узле сети и поддерживается одним сервером, серверы баз данных представляют собой простое и дешевое приближение к распределенным базам данных, поскольку общая база данных доступна для всех пользователей локальной сети.
Доступ к базе данных от прикладной программы или пользователя производится путем обращения к клиентской части системы. В качестве основного интерфейса между клиентской и серверной частями выступает язык баз данных SQL. Собирательное название SQL-сервер относится ко всем серверам баз данных, основанных на SQL. Соблюдая предосторожности при программировании, можно создавать прикладные информационные системы, мобильные в классе SQL-серверов.
Одним из перспективных направлений СУБД является гибкое конфигурирование системы, при котором распределение функций между клиентской и пользовательской частями СУБД определяется при установке системы.
Особенно важны в системах управления базами данных, основанных на архитектуре «клиент-сервер», протоколы удаленного вызова процедур. Использование механизма удаленных процедур позволяет перераспределять функции между клиентской и серверной частями системы, а также скрывать различия между взаимодействующими компьютерами. Физически неоднородная локальная сеть компьютеров приводится к логически однородной сети взаимодействующих программных компонентов. В результате пользователи не обязаны заботиться о разовой закупке совместимых серверов и рабочих станций.
Обычно на стороне клиента СУБД работает только такое программное обеспечение, которое не имеет непосредственного доступа к базам данных, а обращается для этого к серверу с использованием языка SQL. С другой стороны, иногда хотелось бы перенести большую часть прикладной системы на сторону сервера.
Очевидно, что требования к аппаратуре и программному обеспечению клиентских и серверных компьютеров различаются в зависимости от вида системы.
Распределенные БД. Основная задача систем управления распределенными базами данных состоит в обеспечении средствами интеграции локальных баз данных, располагающихся в некоторых узлах вычислительной сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим базам данных как к единой базе данных.
Возможны однородные и неоднородные распределенные базы данных. В случае однородных БД каждая локальная база данных управляется одной и той же СУБД. В неоднородной системе локальные базы данных могут относиться даже к разным моделям данных. Сетевая интеграция неоднородных баз данных — очень сложная проблема. Более успешно практически решается промежуточная задача — интеграция неоднородных SQL-ориентированных систем.
Интегрированные и мультибазы данных. Проблема интегрированных (федеративных) неоднородных БД и мульти-БД возникла в связи с необходимостью комплексирования систем БД, основанных на разных моделях данных и управляемых разными СУБД.
Основной задачей интеграции неоднородных БД является предоставление возможности автоматического преобразования операторов манипулирования БД глобального уровня в операторы, понятные соответствующим локальным СУБД.
При строгой интеграции неоднородных БД локальные системы БД утрачивают свою автономность. После включения локальной БД в федеративную систему все дальнейшие действия с ней, включая администрирование, должны вестись на глобальном уровне. Поскольку пользователи часто не соглашаются утрачивать локальную автономность, желая, тем не менее, иметь возможность работать со всеми локальными СУБД на одном языке и формулировать запросы с одновременным указанием разных локальных БД, развивается направление мульти-БД.
В системах мульти-БД не создается глобальная схема интегрирования, а применяются специальные способы наименования для доступа к объектам локальных БД. В таких системах на глобальном уровне допускается только выборка данных. Это позволяет сохранить автономность локальных БД.
Как правило, интегрировать приходится неоднородные БД, распределенные в вычислительной сети, а это в свою очередь приводит к дополнительным проблемам интеграции: управление глобальными транзакциями, сетевая оптимизация запросов и т.д.
Для внешнего представления интегрированных и мульти-БД обычно используется реляционная модель данных, но в настоящее время все чаще предлагаются объектно-ориентированные модели.
Объектно-ориентированные структуры БД. В последнее время, особенно в разработках фирмы ESRI, большое внимание стало уделяться четвертому типу СУБД — объектно-ориентированному (здесь этот термин имеет отношение только к структуре БД и языку программирования, а не к объекту как реальности). Применение таких СУБД направлено на снижение объемов хранимой информации и времени последовательного поиска в БД. В ГИС такие структуры применяются, когда появляется необходимость управления сложными реальными объектами более разумным способом, чем простыми точками, линиями и полигонами, а также модификация БД при оверлее полигонов.
В объектно-ориентированных БД требуется, чтобы географические данные представляли собой совокупность элементов. При этом они характеризуются серией атрибутов и параметров поведения, которые определяют их пространственные, графические, временные, текстовые/численные размерности. Примерами таких элементов могут служить: участок железной дороги и связанное с ним здание вокзала; узел трубопровода с ответвлениями из труб разного диаметра и т.п. Такая структура позволяет унифицировать хранение геометрии и атрибутов при отображении взаимосвязанных объектов.
Направление объектно-ориентированных баз данных (ООБД) возникло сравнительно давно. Первые публикации появлялись уже в середине 80-х годов XX в., однако наиболее активно это направление развивается в последние годы. Возникновение направления ООБД определяется прежде всего потребностями практики: необходимостью разработки сложных информационных прикладных систем, для которых технология предшествующих систем БД не была вполне удовлетворительной.
Основу развития ООБД обеспечивают как предыдущие работы в области БД, так и давно развивающиеся направления языков программирования с абстрактными типами данных и объектноориентированных языков программирования. Исключительное влияние на концепции ООБД и всего объектно-ориентированного подхода оказал переход к семантическому моделированию данных.
При наличии большого количества функционирующих проектов и коммерческих систем (пример — разработки ESRI) отсутствует общепринятая объектно-ориентированная модель данных по причине отсутствия общего согласия о принятии какой-либо модели. Имеются и более конкретные проблемы, связанные с разработкой декларативных языков запросов, выполнением и оптимизацией запросов, формулированием и поддержанием ограничений целостности, синхронизацией доступа и управлением транзакциями и т.д.
В наиболее общей и классической постановке объектно-ориентированный подход базируется на следующих концепциях: объекта и идентификатора объекта; атрибутов и методов; классов; иерархии и наследования классов.
Любая сущность реального мира в объектно-ориентированных языках и системах моделируется в виде объекта. Любой объект при своем создании получает генерируемый системой уникальный идентификатор, который связан с объектом все время его существования и не меняется при изменении состояния объекта.
Каждый объект характеризуется состоянием и поведением. Состояние объекта — набор значений его атрибутов. Поведение объекта — набор методов (программный код), оперирующих над состоянием объекта. Значение атрибута объекта — это тоже некоторый объект или множество объектов. Состояние и поведение объекта инкапсулированы в объекте; взаимодействие объектов производится на основе передачи сообщений и выполнении соответствующих методов.
Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов. Объект должен принадлежать только одному классу (если не учитывать возможности наследования). Допускается наличие примитивных предопределенных классов, объекты-экземпляры которых не имеют атрибутов: целые, строки и т.д. Класс, объекты которого могут служить значениями атрибута объектов другого класса, называется доменом этого атрибута.
Допускается порождение нового класса на основе уже существующего класса — наследование. В этом случае новый класс, называемый подклассом существующего класса, наследует все его атрибуты и методы. Различаются случаи простого и множественного наследования. В первом случае подкласс может определяться только на основе одного класса, во втором случае классов может быть несколько.
При таком наборе базовых понятий (кроме наследования) объектно-ориентированный подход очень близок к подходу языков программирования с абстрактными (или произвольными) типами данных.
С другой стороны, если абстрагироваться от поведенческого аспекта объектов, объектно-ориентированный подход весьма близок к подходу семантического моделирования данных. Фундамен-
тальные абстракции, лежащие в основе семантических моделей, неявно используются и в объектно-ориентиробанном подходе. На абстракции агрегации основывается построение сложных объектов, значениями атрибутов которых могут быть другие объекты. Абстракция группирования — основа формирования классов объектов.              ,
Наиболее важным качеством ООБД является поведенческий аспект объектов. В прикладных системах с традиционной организацией БД существовал принципиальный разрыв между структурной и поведенческой частями. Структурная часть системы поддерживалась всем аппаратом БД, ее можно было моделировать, верифицировать и т.д., а поведенческая часть создавалась изолированно. В среде ООБД проектирование, разработка и сопровождение прикладной системы становятся процессом, в котором интегрируются структурный и поведенческий аспекты. Конечно, для этого нужны специальные языки, позволяющие определять объекты и создавать на их основе прикладную систему.
Специфика применения объектно-ориентированного подхода для организации и управления БД потребовала уточненного толкования классических концепций и некоторого их расширения. Эти потребности касаются спецификации знаний при определении класса (ограничений целостности, правил дедукции и т.п.), определении разного рода семантических связей между объектами, вообще говоря, разных классов и пересмотра понятия класса. В контексте ООБД оказывается более удобным рассматривать класс как множество объектов данного типа, т.е. одновременно поддерживать понятия типа и класса объектов.
Основные трудности объектно-ориентированного моделирования данных проистекают из того, что такого развитого математического аппарата, на который могла бы опираться общая объектно-ориентированная модель данных, не существует.
Принято выделять два уровня моделирования объектов: нижний (структурный) и верхний (поведенческий). На структурном уровне поддерживаются сложные объекты, их идентификация и разновидности связей. База данных — это набор элементов данных, связанных отношениями «входит в класс» или «является атрибутом». Важными моментами являются поддержание наряду с понятием «объект» понятия «значения», а также, четкое разделение схемы БД и самой БД.
Качество данных и контроль ошибок. Представления о качестве данных, их точности и оценке погрешности становятся чрезвычайно важными при создании баз и банков данных ГИС. Существует практически всеобщая тенденция забывать об ошибках в данных, если последние представлены в цифровой форме. Все пространственные данные до некоторой степени неточны, но в цифровой форме они обычно представляются с высокой точностью, определяемой параметрами памяти компьютера. Необходимо каждый раз рассматривать два вопроса: насколько правильно представляемые в БД цифровые структуры отражают реальный мир; насколько точно алгоритмы позволяют рассчитать истинное значение результата.
Методы расчета точности определений по картам рассматриваются в курсе картографии, с понятиями надежности и качества географических данных можно ознакомиться в работе [Б. Б. Сера- пинас, 1983]. Показатели качества данных определяются стандартами [И. К. Лурье, 2002]. Основные из них: позиционная точность и точность атрибутов объектов, а также логическая непротиворечивость, полнота, происхождение, относящиеся к базе данных в целом.
Позиционная точность данных и типы ошибок. Позиционная точность определяется как величина отклонения измерения данных о местоположении (обычно координат) от истинного значения. При ее определении, как правило, исходят из масштаба исследования или первичного материала, например в данных о природных ресурсах стремятся достичь точности карты заданного масштаба. Обеспечение большей точности требует более качественных исходных материалов, но всегда следует задаться вопросом, оправданны ли дополнительные затраты задачами исследования.
Точность координат определяется по-разному в растровом и векторном представлении.
Точность растра зависит от размера ячеек сетки. Для избежания потери информации можно использовать ячейки меньшего размера с тем, например, чтобы показать искусственные объекты, но следует оценить, что будет представлять из себя выбранная ячейка в заданном масштабе. В большинстве случаев неясно, относятся ли координаты, представленные в растровом формате, к центральной точке ячейки или к одному из ее углов; точность привязки, таким образом, составляет 1/2 ширины и высоты ячейки.
Координаты в векторном формате могут кодироваться с любой мыслимой степенью точности; она ограничивается возможностями внутреннего представления координат в памяти компьютера. Обычно для представления используется 8 или 16 десятичных знаков (одинарная или двойная точность), что соответствует ограничению по точности соответственно до 1/10® и 1/1016 измерения на местности. Для получения такой же точности растра необходимо, соответственно, 10® х 10® или 10,6х 1016 ячеек, что невозможно даже При специальном сжатии данных. Но лишь некоторые классы данных соответствуют такой точности векторного представления: данные, полученные точной съемкой, карты небольших участков, составленные на основе крупномасштабных топографических карт; лишь для немногих природных явлений характерны четкие границы, которые можно представить в виде математически определенных линий. Поэтому можно утверждать, что тонкие линии в векторном формате дают ложное ощущение точности. Обычно на карте толщина линии отражает неопределенность положения объекта. Поэтому в векторной системе фиксируется неопределенность положения векторного объекта, а не точность координат. В растровой системе эта неопределенность автоматически выражается размером ячейки, который и дает действительное представление о точности.
Точность базы данных. Практически на каждом этапе создания БД возможно внесение ошибок.
Карты имеют погрешности, которые при цифровании автоматически переносятся в базу данных; из-за генерализации они не всегда точно фиксируют информацию о местоположении объекта; несоответствия на границах листов могут обусловить несоответствия в базе данных.
Ошибки характерны для данных, взятых из некартографических источников. Они могут появиться и при проведении инвентаризации по аэрофотоснимкам, если изображения дешифрированы неверно, часто возникают потому, что слишком велико доверие к базовым картам. Другие ошибки связаны с проблемой границ и погрешностями классификации. Многие ошибки обусловлены особенностями сбора данных. Ручной ввод цифровых данных весьма утомителен, и трудно сохранять необходимое качество работы на протяжении долгого времени.
Для снижения ошибок в измерении местоположения используют геодезический контроль и системы спутникового позиционирования, а также создание массивов данных географической привязки. К последним предъявляют особенно высокие требования по точности и достоверности еще на этапе сбора исходной информации. Их применение в качестве основы для интеграции данных в известных оригинальных масштабах и проекциях не вызывает затруднений. Во всех других случаях требуется преобразование информации, которое должно выполняться по правилам картографической генерализации и согласования.
Большая часть данных о местоположении объектов берется с аэроснимков, при этом точность зависит от правильного размещения контрольных точек. Данные космической съемки труднее расположить с большой точностью — не позволяет разрешение снимка.              '
На весь набор данных влияют: ошибки регистрации и определения контрольных точек, преобразования координат, особенно когда неизвестна проекция исходного документа; ошибки обработки данных, неправильный логический подход, генерализация и проблемы интерпретации; математические ошибки; потеря точности представления из-за невысокой точности вычислений; перевод векторных данных в растровый формат.
В БД обычно используются данные из разных источников с разной степенью точности. При наложении множества карт точность результирующего материала может оказаться очень низкой. Однако больший интерес представляет показатель пригодности полученной карты. ДДя некоторых типов операций степень пригодности карт определяется точностью наименее точного слоя БД. Показатель пригодности можно оценить также по его устойчивости при смене порядка ввода данных или изменении веса атрибута.
Часто возникают искусственные признаки ошибок (артефакты) — нежелательные последствия применения высокоточных процедур для обработки пространственных данных, имеющих небольшую точность. Использование растровых данных позволяет застраховаться от артефактов до тех пор, пока размер элемента растра больше или равен позиционной точности данных. При работе с векторными данными артефакты возникают при кодировании (цифровании) и наложении полигонов.
Чтобы проверить позиционную точность, нужно использовать независимый, более точный источник, например, карту более крупного масштаба, данные спутникового позиционирования, первичные («сырые») данные съемки. Для контроля можно использовать и внутренние признаки: незамкнутые полигоны, линии, проходящие выше или ниже узловых точек, и т. п. Величина этих погрешностей может служить мерой позиционной точности.
Наиболее надежным путем создания качественных БД, особенно для ее многократного и многопользовательского применения, является хранение информации о точности в самой БД в виде атрибутов или метаданных.
Точность атрибутивных данных. Точность атрибутов определяется как близость их к истинным показателям (на данный момент времени). В зависимости от природы данных точность атрибутов может быть проанализирована разными способами.
Для непрерывных атрибутов, представляющих модель поверхности, например ЦМР, точность определяется как погрешность измерений по этой модели.
Для атрибутов объектов, выделяемых в результате классификации, точность выражается в оценках соответствия, определенности или правдоподобия. В случае двух объектов ситуация, в которой они представлены сочетанием 70 % атрибута объекта А и 30 % атрибута В, выгоднее, чем когда объекты А и В недостаточно определены, что не позволяет четко разграничить их. В общем случае для оценки точности атрибутов полезно составить матрицу ошибок классификации. Для этого нужно взять несколько случайных точек, определить их категорию по базе данных, затем на местности определить истинный класс и заполнить матрицу классификации (соответствия). Если, например, число классов 4, а число об-
Таблица 2.1
Матрица классификации '

Класс на местности

Класс в БД

А

В

С

D

Всего

А

12

7

3

3

25

В

3

10

3

2

18

С

3

5

15

1

24

D

4

4

4

21

33

Всего

22

26

25

27

100

следованных точек 100, из них на местности определено 25 точек класса А, 18 точек — В, 24 — С и 33 — D (табл. 2.1).
В идеале все точки должны располагаться по диагонали матрицы; это показывает, что на местности и в базе данных зафиксирован один и тот же класс. Ошибка пропуска возникает в тех случаях, когда точки класса на местности неправильно зафиксированы в базе данных. В матрице число ошибочных точек класса В равно сумме записей в столбцах А, С и D строки В (числу точек, относящихся на местности к классу В, а в базе данных — к другим классам). Ошибка добавления (ложного класса) имеет место в случаях, когда в базе данных зафиксирован класс, которого нет на местности, например, для класса А — это сумма записей в строках В, С и D столбца А (соответствует числу точек, неправильно отнесенных к классу А в базе данных).
Для обобщения матрицы соответствия используют показатель достоверности классификации — количество правильно классифицированных точек, расположенных по диагонали матрицы (в %). На самом деле это число может быть случайным. Чтобы учесть этот факт, часто при обобщении результатов используют индекс к (каппа Коэна), вносящий поправку на случайность. Он вычисляется по формуле
к = (d-q)/(N-q),              (2.6)
где d — число случаев правильного получения результата (сумма значений, стоящих на диагонали матрицы соответствия); q — число случайных результатов, вычисляемое через число случайных результатов в столбцах пс и истинных — в строках пг матрицы соответствия как q = ^ncttr/N; N — общее число точек. Для абсолютно точных результатов (все Сточек на диагонали) к= 1, а при чисто случайном попадании к=0. В приведенном примере
к = (22 • 25/100 + 26 • 18/100 + 25 • 24/100 + 27 • 33/100) = 25,09;
к = (58 - 25)/(100 - 25) = 0,44.
Показатель достоверности классификации равен 44 %, что меньше значения, полученного по диагональным элементам (58 %).
Неопределенность атрибутов каждого элемента растра постоянна для каждого из представленных классов объектов, а позиционная неопределенность постоянна для всего растра — фиксируется один раз для всей карты.
Для социальных данных основной источник неточности в атрибутах — недоучет данных. Например, при проведении переписи в некоторых районах и по некоторым социальным группам недоучет может быть очень высоким (gt; 10 %).
Логическая непротиворечивость, полнота, происхождение. Эти элементы качества данных относятся к базе данных в целом, а не к объектам, атрибутам или координатам.
Логическая непротиворечивость связана с внутренней непротиворечивостью структуры данных, с топологическим представлением данных, что означает наличие исчерпывающего списка взаимоотношений между связными геометрическими представлениями данных без измерения хранимых координат пространственных объектов. Она обычно заключается в ответах на вопросы: замкнуты ли полигоны, нет ли полигонов без меток или с несколькими метками, есть ли узлы на всех пересечениях дуг. Логические противоречия могут быть вызваны проблемами согласования информации и географических границ при совмещении данных из разных источников.
Полнота связана со степенью охвата данными множества объектов, необходимых для представления реальности или отображения на результирующей карте (все ли соответствующие объекты включены в базу данных?). Она зависит от правил отбора объектов или явлений, генерализации и масштаба.
Происхождение включает сведения об источниках данных, времени сбора данных, точности источников и цифровых данных, организации, которая их собирала, об операциях по созданию базы данных (как кодировались данные и с какого исходного материала, как происходила их обработка). Обычно эта информация содержится в специальных файлах метаданных.
Особенности интеграции разнотипных данных. Новые виды и типы цифровых данных требуют разработки методов их совместного использования, оценки пригодности для создания ГИС и составления карт. Создание проблемно-ориентированных банков географических и картографических данных и знаний способствует не только накоплению информации и обмену ей, но и повышению качества и достоверности результатов, получаемых ГИС. Особенно возрастает роль таких банков для интеграции, пространственного и тематического согласования информации.
Проблемы интеграции данных особенно остро встали в связи с широким использованием уже существующих цифровых карт (см.
2.1.4), содержащихся в разнообразных базах пространственных данных и распространяемых по телекоммуникационным сетям. Они могут быть слоями проблемно-ориентированных ГИС, представлять результаты компьютерного дешифрирования аэро- и космических снимков, цифрового моделирования объектов или явлений. Информация относительно их происхождения, методов создания, точности и достоверности часто отсутствует или недоступна. Технология создания цифровых карт часто определяется временными, не устоявшимися, разрозненными, не всегда профессионально составленными инструкциями и техническими заданиями, разработанными производителем или заказчиком работ, ведомственными инструкциями. Все чаще появляются в публикациях сообщения об ошибках в цифровых картах, а иногда об их полной непригодности к использованию или ненадежности как источников данных.
При традиционном (бумажном) создании карт разнотипные данные применяются давно и методы их совместного использования хорошо разработаны. Современное техническое и программное обеспечение позволяет на основе любых доступных данных создавать сколь угодно сложные по содержанию карты и делать их легко доступными для использования и модификаций. Но часто это происходит без учета картографических традиций, в то время как доверие к цифровым картам велико.
Решение проблем интеграции данных при создании и использовании цифровых карт лежит в области разработки инфраструктуры пространственных данных (на национальном, межгосударственном уровнях) [А. В. Кошкарев, 2000], четкой структуры метаданных и картографически обоснованного применения ГИС-тех- нологий при работе с разнотипными данными.
Под формированием инфраструктуры пространственных данных подразумевается разработка механизма их обмена и накопления (доступность, стоимость, система стандартов на данные и обмен ими, метаданные), а также определение единой — базовой — пространственной информации, к которой, в первую очередь, следует отнести геодезическую основу, рельеф, гидрографию, транспортную сеть, административные границы.
Преимущество геоинформационных методов заключается в возможности оценить пригодность данных для совместного использования и осуществить их интеграцию на основе выполнения пространственного анализа с помощью ГИС-технологий. Однако основное правило при интеграции информации таково: качество данных должно быть определено скорее во время получения данных, чем при попытке применить эти данные. Тогда указанные технологии могут существенно облегчить их корректировку для поставленной задачи.
Основные проблемы, возникающие при совместном использовании разнотипных данных: отображение положения границ в разных цифровых источниках, временные параметры данных и способ отражения структуры геосистем. Необходимо каждый раз рассматривать два вопроса: насколько правильно и сопоставимо представляемые в базах данных цифровые структуры отражают реальную ситуацию (моделируют реальность); насколько точно используемые алгоритмы позволяют рассчитать истинное значение результата совмещения данных.
Хорошим технологическим приемом интеграции разнотипных данных произвольных источников может стать создание специализированных экспертных систем. Их задача — выполнение оценок качества и пригодности таких данных, опирающееся на три базовые составляющие системы: метаданные; логические процедуры, учитывающие характер проявления основных источников возможных ошибок в цифровых пространственных данных; ГИС-техно- логии, реализующие традиционные и современные приемы совмещения информации для(Создания БД.
Контрольные вопросы Каким образом обеспечивается надежность хранения данных в БД? Какие свойства реляционной модели обусловили ее широкое распространение? В чем отличие баз данных ГИС от баз данных других информационных систем? Что подразумевается под целостностью данных в пространственной базе данных? Приведите примеры того, каким образом может нарушиться целостность пространственной базы данных без соответствующего контроля за доступом. Определите разницу между чувствительностью к ошибкам в теории и на практике. Каковы пути устранения последствий ошибок в данных? Каковы преимущества создания объектно-ориентированных БД при работе с пространственными данными?
<< | >>
Источник: Е. Г. Капралов,  А. В. Кошкарев, В. С. Тикунов. Геоинформатика: Учеб, для студ. вузов. 2005

Еще по теме Базы данных и управление ими:

  1. Базы данных сети мониторинга
  2. Похищением базы данных ЦБ занялась Госдума
  3. Функциональные требования к серверу Интегрированной первичной базы данных
  4. Структура информационных объектов и показателей Интегрированной первичной базы данных ИКС
  5. Особенности реализации прав при коллективном управлении ими
  6. Авторское право охраняет произведения науки, литературы (в том числе программы для ЭВМ и базы данных) и искусств
  7. 4.5. СБОР ДАННЫХ 4.5.1. Общее понятие о данных
  8. Деятельность ледников и перенос ими продуктов разрушения
  9. Статья 39. Освобождение и отстранение опекунов и попечителей от исполнения ими своих обязанностей
  10. Осмотр базы
  11. ВЗАИМОСВЯЗЬ МЕЖДУ ЭЛЕМЕНТАМИ УПРАВЛЕНИЯ И ИНФОРМАЦИЕЙ КАК СРЕДСТВОМ УПРАВЛЕНИЯ
  12. ПОИСК И ДОРАЗВЕДКА БАЗЫ
  13. РАЗДЕЛ IV ПРАВОВАЯ ОХРАНА СРЕДСТВ ИНДИВИДУАЛИЗАЦИИ УЧАСТНИКОВ ГРАЖДАНСКОГО ОБОРОТА И ПРОИЗВОДИМОЙ ИМИ ПРОДУКЦИИ (РАБОТ, УСЛУГ)
  14. Отход БРГ с захваченной базы
  15. Охрана базы
  16. З.6. СТРУКТУРА НЕЗАКОННЫХ ВООРУЖЕННЫХ ФВРМИРПВАПИЙ В ЧЕЧНЕ Н ОСОБЕННОСТИ ТАКТИКИ ПРИВЕДЕНИЯ ИМИ ТЕРРОРИСТИЧЕСКИХ И ДИВЕРСИОННЫХ АКЦИЙ
  17. 1.4.1 Создание базы оценивания
  18. Ведение поиска базы НВФ