Тикунов В.С. (ред.) Основы геоинформатики. В 2 книгах. Книга 1

Подождите немного. Документ загружается.

1) выполнение ГИС-процедур полностью через СУБД, тогда

доступ ко всем данным осуществляется только через СУБД и все

данные должны удовлетворять требованиям, заложенным при ее

разработке;

2) некоторые данные (обычно таблицы атрибутов и их отно-

шений) доступны через СУБД, поскольку они вполне соответ-

ствуют модели, а к некоторым данным (обычно пространственно

локализованным) доступ прямой, так как они не удовлетворяют

требованиям модели СУБД

ГИС добавляет географический аспект к уже существующим

методам поиска и запроса. Сложность и разнообразие представле-

ния данных в ГИС, различимость в представлении позиционной

и атрибутивной составляющей информации, необходимость ее

обработки в контексте пространственной близости предъявляют

своеобразные и повышенные требования к СУБД по сравнению с

традиционной формой их использования.

Функции СУБД. Каждую СУБД принято характеризовать спо-

собностью выполнять следующие основные функции [К. Дейт,

1980; Дж. Ульман, 1983]:

управление данными во внешней памяти;

управление буферами оперативной памяти;

операции над БД;

обеспечение надежности хранения данных в БД;

поддержка языка управления БД.

Управление данными во внешней памяти. Эта функция обес-

печивает организацию структуры внешней памяти как для хра-

нения данных, входящих в БД, так и для служебных целей,

например для убыстрения доступа к данным. В некоторых СУБД

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

производится на уровне функционирования устройств внеш-

ней памяти. В любом случае пользователи СУБД не обязаны

знать, какая структура используется или как организованы фай-

лы. Обычно в СУБД создается собственная система именования

объектов БД.

Управление буферами оперативной памяти. СУБД обычно ра-

ботают с БД значительного размера, существенно большего до-

ступного объема оперативной памяти. Чтобы СУБД не зависела

от скорости работы устройств внешней памяти, используется

организация собственных наборов буферов оперативной памя-

ти с определенными правилами замены и обновления буферов.

Операции над БД. Последовательность операций над БД, рас-

сматриваемых СУБД как единое целое, называется транзакцией.

При выполнении транзакции СУБД либо фиксирует во внешней

памяти изменения в БД, произведенные этой транзакцией, либо

не производит никаких изменений. Понятие транзакции важно

для сохранения логической целостности БД, особенно в много-

пользовательских СУБД. Каждая транзакция начинается при це-

лостном состоянии БД и оставляет это состояние целостным пос-

ле своего завершения. При эффективном управлении параллель-

но выполняющимися транзакциями со стороны СУБД каждый

из пользователей может ощущать себя единственным ее пользова-

телем.

Управление транзакциями в многопользовательской СУБД осу-

ществляется с помощью специальных операций, которые объе-

диняют транзакции одного пользователя в серии (сериализация

транзакций), при этом суммарный эффект смеси транзакций эк-

вивалентен эффекту их последовательного выполнения. Существует

несколько базовых алгоритмов сериализации транзакций, среди

которых наиболее распространены алгоритмы, основанные на

синхронизационных захватах объектов БД.

Обеспечение надежности хранения данных в БД. Одним из ос-

новных требований к СУБД является надежность хранения дан-

ных во внешней памяти, т.е. СУБД должна обладать способно-

стью восстановления последнего согласованного состояния БД

после любого аппаратного или программного сбоя. Возможны два

вида аппаратных сбоев: «мягкие» сбои, которые приводят к вне-

запной остановке работы компьютера (например, аварийное вык-

лючение питания), и «жесткие» сбои, характеризуемые потерей

информации на носителях внешней памяти. Программные сбои

—

это аварийное завершение работы СУБД или аварийное заверше-

ние пользовательской программы, в результате чего некоторая

транзакция остается незавершенной. Для восстановления БД нуж-

но располагать некоторой дополнительной информацией, что тре-

бует избыточности хранения данных. Наиболее распространенным

методом поддержания такой избыточной информации является

ведение журнала изменений БД.

Журнал — это особая часть БД, недоступная пользователям

СУБД и поддерживаемая с особой тщательностью (иногда под-

держиваются две копии журнала, располагаемые на разных физи-

ческих дисках), в которую поступают записи обо всех изменениях

основной части БД. Самая простая процедура обеспечения надеж-

ности восстановления БД — откат транзакции, выполненной

пользователем, для чего все записи от одной транзакции связыва-

ют обратным списком от конца к началу (аналог Undo).

При «мягком» сбое во внешней памяти основной части БД

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

не закончившимися к моменту сбоя, и могут отсутствовать объек-

ты, модифицированные транзакциями, которые к моменту сбоя

успешно завершились (по причине использования буферов опе-

ративной памяти, содержимое которых при «мягком» сбое про-

падает). В таком случае во внешней памяти журнала должны обя-

зательно находиться записи, относящиеся к операциям моди-

фикации обоих видов объектов. Для восстановления БД после

жесткого сбоя используют журнал и архивную копию БД.

Поддержка языков управления БД. Для работы с базами данных

используются специальные языки, называемые языками баз дан-

ных. Первоначально в СУБД поддерживалось несколько специали-

зированных по функциям языков. В современных СУБД обычно под-

держивается единый интегрированный язык, содержащий все не-

обходимые средства для работы с БД, начиная от ее создания, и

обеспечивающий базовый пользовательский интерфейс с базами

данных. Стандартным^язы^ом наиболее распространенных в насто-

ящее время реляционных СУБД является язык SQL (Structured Query

Language). Он позволяет определять схему реляционной БД и мани-

пулировать данными. При этом именование объектов БД (таблиц и

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

что компилятор языка SQL производит преобразование имен объек-

тов в их внутренние идентификаторы на основании специально

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

СУБД (ядро) вообще не работает с именами таблиц и их столбцов.

Язык SQL содержит специальные средства определения огра-

ничений целостности БД, которые тоже хранятся в специальных

таблицах-каталогах. Обеспечение контроля целостности БД про-

изводится на языковом уровне. Компилятор SQL для операторов

модификации БД на основании имеющихся в БД ограничений

целостности генерирует соответствующий программный код.

Специальные операторы языка SQL позволяют определять так

называемые представления БД, фактически являющиеся храни-

мыми в БД запросами (результатом любого запроса к реляцион-

ной БД является таблица) с именованными столбцами. Для пользо-

вателя представление является такой же таблицей, как любая ба-

зовая таблица, хранимая в БД, но с помощью представлений

можно ограничить или, наоборот, расширить «видимость» БД для

конкретного пользователя. Поддержание представлений произво-

дится также на языковом уровне.

Наконец, авторизация доступа к объектам БД производится

также на основе специального набора операторов SQL. Идея со-

стоит в том, что для выполнения операторов SQL разного вида

пользователь должен обладать различными правами доступа к БД.

Пользователь, создавший таблицу БД, обладает полным набором

прав для работы с этой таблицей, в том числе правом разрешения

доступа другим пользователям. Контроль прав доступа поддержи-

вается на уровне языка.

Типовая организация СУБД. Организация типичной СУБД и

состав ее компонентов соответствуют рассмотренному набору фун-

кций. СУБД представляет собой три взаимосвязанные компонен-

ты: командный язык для выполнения требуемых операций с дан-

ными (ввод, вывод, модификация), интерпретирующую систему

(или компилятор) для обработки команд и перевода их на язык

машины, интерфейс пользователя для формирования запросов к

БД (выборки нужных данных).

Логически в реляционной СУБД можно выделить:

внутреннюю часть

—

ядро СУБД (часто его называют Data Base

Engine);

компилятор языка БД (обычно SQL);

подсистему поддержки времени выполнения;

набор утилит.

В некоторых системах эти части выделяются явно, в других —

нет, но логически такое разделение можно провести во всех СУБД.

Ядро СУБД отвечает за управление данными во внешней па-

мяти, буферами оперативной памяти, транзакциями, а также за

ведение журнала. Компоненты ядра — это соответственно менед-

жер данных, менеджер буферов, менеджер транзакций и менед-

жер журнала. Для обеспечения корректной работы СУБД все эти

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

ванным протоколам. Ядро СУБД является основной резидентной

частью СУБД, а в архитектуре «клиент—сервер» — главной со-

ставляющей серверной части системы.

Важной функцией компилятора языка БД является перевод опе-

раторов языка БД в некоторую выполняемую программу. Резуль-

татом компиляции является выполняемая программа, представ-

ляемая в некоторых системах в машинных кодах, но более часто

во внутреннем машинно-независимом коде.

В отдельные утилиты БД обычно выделяют такие процедуры,

которые слишком затратно выполнять с использованием языка

БД; например, загрузка и выгрузка БД, сбор статистики, гло-

бальная проверка целостности БД и т.д. Утилиты программиру-

ются с использованием интерфейса ядра СУБД.

К числу достоинств реляционного подхода можно отнести:

— наличие небольшого набора приемов для простого абстрак-

тного представления объектов большинства распространенных

областей применения БД с интуитивно понятными и достаточно

точными формальными определениями;

— наличие простого математического аппарата, опирающего-

ся на теорию множеств и математическую логику, обеспечива-

ющего основу реляционного подхода к организации баз данных;

— возможность манипулирования данными без необходимости

знания конкретной физической организации баз данных во внеш-

ней памяти.

Отмеченные преимущества и постепенное накопление мето-

дов и алгоритмов организации реляционных баз данных и управ-

ления ими привели к тому, что уже в середине 80-х годов реляци-

онные системы практически вытеснили с мирового рынка ран-

ние СУБД.

К недостаткам реляционных СУБД относятся некоторая огра-

ниченность (как следствие простоты) их использования при слож-

ных структурах данных, в том числе пространственно-определен-

ных данных разных моделей, а также невозможность адекватного

отражения семантики предметной области.

Базовые понятия реляционных баз данных. В преобладающем

большинстве ГИС используются реляционные базы данных, под-

держиваемые такими СУБД, как dBase, INFO, ORACLE, INFOR-

MIX и т.п. Такие БД позволяют разработчикам ГИС разделить

проблему управления пространственными данными на две части:

как представлять геометрию объектов и топологию пространствен-

ных объектов (вектор или растр) и как работать с атрибутами

этих объектов. Для этого годятся реляционные СУБД, а управляе-

мые ими модели данных иногда называют геореляционными мо-

делями. Основные их преимущества:

— нет необходимости хранить атрибуты с пространственными

данными, но они всегда могут содержаться где-нибудь в системе

или поставляться, например, по сети;

— атрибуты могут быть изменены или удалены без изменения

пространственной БД;

— коммерческие реляционные СУБД стандартны и могут управ-

ляться стандартными запросами;

— хранение атрибутивных данных в реляционных БД не про-

тиворечит основным принципам слоев в ГИС;

— атрибуты могут быть привязаны к пространственным едини-

цам и представлены разными способами.

Основными понятиями реляционных баз данных являются: тип

данных, домен, атрибут, кортеж, первичный ключ и отноше-

ние.

Понятие «тип данных» полностью адекватно понятию типа дан-

ных в языках программирования. Обычно в реляционных БД до-

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

специализированных числовых данных (таких, как «деньги»), а

также специальных данных — дата, время, временной интервал.

Развивается подход к расширению возможностей реляционных си-

стем абстрактными типами данных.

Понятие «домен» имеет некоторые аналогии с подтипами в

некоторых языках программирования. В самом общем виде домен

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

рому относятся элементы домена и произвольного логического

выражения, применяемого к элементу типа данных. Если вычис-

ление этого логического выражения дает результат «истина», то

элемент данных является элементом домена. Наиболее правиль-

ное интуитивное понимание домена

—

допустимое множество зна-

чений данного типа. Данные считаются сравнимыми только в том

случае, когда они относятся к одному домену.

Отношение — это именованное множество пар {имя атрибута,

имя домена (или типа)}. Если все атрибуты одного отношения

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

именования атрибутов имена соответствующих доменов.

Кортеж, соответствующий данной схеме отношения, — это на-

бор именованных значений заданного типа.

Обычным представлением отношения является таблица, заго-

ловок которой — именование отношения, а строки — кортежи; в

этом случае имена атрибутов именуют столбцы этой таблицы.

Поэтому иногда говорят «столбец таблицы», имея в виду «атрибут

отношения». Такой терминологии придерживаются в большинстве

коммерческих реляционных СУБД.

Реляционная модель данных. Модель данных с точки зрения

СУБД описывает некоторый набор родовых понятий и призна-

ков, которыми должны обладать сама СУБД и управляемые ею

базы данных, если они основываются на этой модели. Наличие

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

используя один общий язык.

Реляционная модель состоит из трех частей, описывающих раз-

ные аспекты реляционного подхода: структурной, манипуляци-

онной и целостной.

В структурной части модели фиксируется, что единственной

структурой данных, используемой в реляционных БД, является

нормализованное отношение — некоторый определенный набор

ограничений, свойственный этому отношению. Нормализация

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

жества данных и имеет дело с зависимостью между атрибутами;

она позволяет избежать потери общей информации при удалении

или вводе записей. Существует несколько формальных типов нор-

мализации (более 5).

Манипуляционная часть модели определяет механизм манипу-

лирования реляционными БД — реляционная алгебра и реляци-

онное исчисление, базирующиеся на теории множеств и логиче-

ском аппарате исчисления отношений.

В целостной части реляционной модели данных фиксируются

два базовых требования целостности: целостности сущностей и

целостности по ссылкам. Объекту, или сущности, реального мира

в реляционных БД соответствуют записи (кортежи) отношений,

и требование целостности состоит в сохранении отличий разных

записей этого отношения; говорят, что любое отношение должно

обладать первичным ключом.

Второе требование более сложно. Сложные сущности реально-

го мира представляются в реляционной БД в виде нескольких за-

писей нескольких отношений. Для связи отношений используется

атрибут, который служит внешним ключом. Отношение, опреде-

ляющее внешний ключ, ссылается на соответствующее отноше-

ние, в котором такой же атрибут является первичным ключом.

Требование целостности по ссылкам состоит в том, что для каж-

дого значения внешнего ключа должна найтись запись с таким же

значением первичного ключа в отношении, на которое ведет ссыл-

ка, либо значение внешнего ключа должно быть неопределенным

(т.е. ни на что не указывать).

Выполнение таких требований чрезвычайно важно при моди-

фикации отношений или удалении записей. Поддержке целостно-

сти при удалении кортежа служат: запрет на удаление кортежа, на

который существуют ссылки; автоматическая замена значения

внешнего ключа на'неопределенное во всех ссылающихся корте-

жах; автоматическое удаление всех ссылающихся кортежей.

Реляционные СУБД обладают рядом особенностей, влияющих

на организацию внешней памяти. К наиболее важным особенно-

стям можно отнести следующие:

— наличие двух уровней системы: уровня непосредственного

управления данными во внешней памяти и языкового уровня (на-

пример, уровня, реализующего язык SQL); тогда подсистема ниж-

него уровня должна поддерживать во внешней памяти набор ба-

зовых структур, конкретная интерпретация которых входит в чис-

ло функций подсистемы верхнего уровня;

— информация, связанная с именованием объектов базы дан-

ных и их конкретными свойствами (например, структура ключа-

индекса), поддерживается подсистемой языкового уровня;

— регулярность структур данных во внешней памяти, посколь-

ку основным объектом реляционной модели данных является плос-

кая таблица;

—

для выполнения операторов языкового уровня как над одним,

так и над несколькими отношениями во внешней памяти поддер-

живаются дополнительные «управляющие» структуры — индексы;

— для выполнения требования надежного хранения баз данных

поддерживается избыточность хранения данных во внешней памяти.

Следует подчеркнуть, что, как бы ни были организованы ин-

дексы в конкретной СУБД, их основное назначение состоит в

обеспечении эффективного прямого доступа к кортежу отноше-

ния по ключу. Обычно индекс определяется для одного отноше-

ния и ключом является значение атрибута (возможно, составно-

го). Организация индексов в больших БД представляет сложную

проблему. Все более популярным подходом к организации индек-

сов является использование техники хэширования. Общей идеей

методов хэширования является применение к значению ключа

некоторой функции свертки (хэш-функции), вырабатывающей

значение меньшего размера. Свертка значения ключа затем ис-

пользуется для доступа к записи. В самом простом случае свертка

ключа используется как адрес в таблице, содержащей ключи и

записи.

Язык реляционных баз данных SQL. Функции и основные воз-

можности. Язык для взаимодействия с БД

—

SQL (Structered Query

Language) появился в середине 70-х годов, и сейчас распростра-

нена его версия 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) имеет вид NUME-

RIC ([precision], [scale]). Специфицируются точные числа, пред-

ставленные с масштабом scale и точностью, равной или большей

значения precision.

INTEGER специфицирует тип данных точных чисел с масшта-

бом 0 и определяемой в реализации точностью. SMALLINT спе-

цифицирует тип данных точных чисел с масштабом 0 и определяе-

мой в реализации точностью, не большей, чем точность чисел

типа INTEGER.

Хотя правила встраивания SQL в программы на языке СИ не

определены в SQL/89, в большинстве реализаций, поддержива-

ющих такое встраивание, имеется следующее соответствие между

типами данных SQL и типами данных СИ: CHARACTER соот-

ветствует строкам СИ; INTEGER — long; SMALL1NT — short;

REAL — float; DOUBLE PRECISION — double (именно такое со-

ответствие утверждено в стандарте SQL/92).

Описанный набор операторов SQL предназначен для встраи-

вания в программу на обычном языке программирования. Поэто-

му в этом наборе перемещаны операторы «истинного» реляцион-

ного языка запросов и операторы работы с курсорами, позволя-

ющими обеспечить построчный доступ к таблице — результату

запроса. В диалоговом режиме набор операторов SQL и их синтак-

сис несколько другие, более сложные и динамичные. Примером

может служить реализация языка в СУБД Oracle.

СУБД в архитектуре «клиент—сервер». Архитектура «клиент—

сервер» обеспечивает простое и относительно дешевое решение

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

сети, создавая некоторое подобие распределенных систем БД.

Реальное распространение архитектуры «клиент

—

сервер» стало

возможным благодаря развитию и широкому внедрению в прак-

тику концепции открытых систем. Основой этой концепции яв-

ляется упрощение комплексирования вычислительных систем при

международной и национальной стандартизации аппаратных и про-

граммных интерфейсов. Стимулом для развития концепции яви-

лись, с одной стороны, широкое внедрение локальных компью-

терных сетей с комплексированием аппаратно-программных

средств, с другой — бурное развитие технологий глобальных ком-

муникаций. Реальностью становятся и открытые ГИС-системы,

несмотря на существующие проблемы в области стандартизации.

Ключевой позицией открытых систем, ориентированной на

пользователей, является независимость от конкретного разработ-

чика аппаратного и программного обеспечения. Приобретая лю-

бой продукт компании, придерживающейся стандартов открытых

систем, потребитель не становится полностью от нее зависимым.

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

другой компании, соблюдающей стандарты. Причем это касает-

ся как аппаратных, так и программных средств и не является

необоснованной декларацией. Примерами всестороннего иссле-

дования и реализации подходов к созданию открытых ГИС-сис-

тем являются программные и технологические разработки круп-

нейших фирм-конкурентов ESRI и Intergraph — GEONET и

GeoMedia соответственно.

Основой системных и прикладных программных средств от-

крытых систем являетсОя стандартизованная операционная си-

стема. Технологии и стандарты открытых систем обеспечивают

возможность производства программных средств, обладающих

свойствами мобильности (portability) и интероперабельности

(interoperability). Свойство мобильности означает сравнительную

простоту переноса программной системы в различные аппарат-

но-программные среды, соответствующие стандартам. Интеро-

перабельность означает упрощение разработки новых программ-

ных систем на основе комплексирования готовых компонентов

со стандартными интерфейсами.

Использование подхода открытых систем выгодно и произво-

дителям, и пользователям. Прежде всего открытые системы обес-

печивают решение проблемы поколений и версий аппаратных и

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

чивать некоторую стандартную среду. Преимуществом для пользо-

вателей является то, что они могут постепенно заменять компо-

ненты системы более совершенными, не утрачивая работоспо-

собности системы, решать проблемы постепенного наращивания

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

терной системы.

В основе широкого распространения локальных сетей компью-

теров лежит известная идея разделения ресурсов. Высокая пропуск-

ная способность локальных сетей обеспечивает эффективный до-

ступ из одного узла локальной сети к ресурсам, находящимся в

других узлах.

Развитие этой идеи приводит к функциональному выделению

компонентов сети: разумно иметь не только доступ к ресурсам

удаленного компьютера, но и также получать от этого компьюте-

ра некоторый сервис, который специфичен для ресурсов данного

рода и программные средства для обеспечения которого нецеле-

сообразно дублировать в нескольких узлах.

Рабочая станция предназначена для непосредственной работы

пользователя или категории пользователей и обладает ресурсами,

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

теля. Специфическими особенностями рабочей станции являют-

ся: объем оперативной памяти (далеко не все категории пользова-

телей нуждаются в наличии большой оперативной памяти); нали-

чие и объем дисковой памяти (достаточно популярны бездиско-

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

сервера); характеристики процессора и монитора (некоторым

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

пени интересует разрешающая способность монитора, для треть-

их обязательно требуются средства убыстрения графики и т.д.).

При необходимости можно использовать ресурсы и/или услуги,

предоставляемые сервером.

Сервер локальной сети должен обладать ресурсами, соответ-

ствующими его функциональному назначению и потребностям сети.

Заметим, что в связи с ориентацией на подход открытых систем