Реляционные СУБД обладают рядом особенностей, влияющих на организацию внешней памяти. К наиболее важным можно отнести следующие:

•наличие двух уровней системы: уровня непосредственного управления данными во внешней памяти и языкового уровня (например, уровня, реализующего язык SQL); тогда подсистема нижнего уровня должна поддерживать во внешней памяти набор базовых структур, конкретная интерпретация которых входит в число функций подсистемы верхнего уровня;

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

•регулярность структур данных во внешней памяти, поскольку основным объектом реляционной модели данных является плоская таблица;

•для операций языкового уровня над одним или несколькими отношениями во внешней памяти поддерживаются дополнительные «управляющие» структуры — индексы;

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

Внутренняя архитектура различна в разных реляционных СУБД, но все они основаны на общих логических принципах функционирования.

2.4.3. Базовые понятия реляционных баз данных

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

•внутреннюю часть — ядро СУБД (часто его называют Data Base Engine);

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

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

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

В некоторых системах эти части выделяются явно, в других — нет, но логически такое разделение можно провести во всех СУБД.

Ядро СУБД отвечает за управление данными во внешней памяти, буферами оперативной памяти, транзакциями, а также за ведение

62 Глава 2. Представление и организация географической информации

журнала. Компоненты ядра — это соответственно менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала. Для обеспечения корректной работы СУБД все эти компоненты должны взаимодействовать по тщательно организованным протоколам. Ядро СУБД является основной резидентной частью СУБД, а в архитектуре «клиент-сервер» — основной составляющей серверной части системы.

Главной функцией компилятора языка БД является перевод (компиляция) операторов языка БД в некоторую выполняемую программу, представляемую в некоторых системах в машинных кодах, но более часто во внутреннем машинно-независимом коде.

В отдельные утилиты СУБД обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка Б Д например, загрузка и выгрузка БД, сбор статистики, глобальная проверка целостности БД и т. д. Утилиты программируются с использованием интерфейса ядра СУБД.

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

Основными понятиями реляционных баз данных являются: тип данных, отношение, кортеж, атрибут, домен, первичный ключ, внешний ключ, нормализация. Такой терминологии придерживаются в большинстве коммерческих реляционных СУБД.

Понятие тип данных полностью адекватно понятию типа данных в языках программирования. Обычно в реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как «деньги»), а также специальных данных — дата, время, временной интервал. Развивается подход к расширению возможностей реляционных систем абстрактными типами данных.

Отношение — это таблица, образуемая упорядоченными записями каждого типа, заголовком которой является наименование отношения. Записи образуют строки, или кортежи; каждая запись имеет набор атрибутов, а имена атрибутов именуют столбцы таблицы. Поэтому иногда говорят «столбец таблицы», имея в виду

«атрибут отношения». Число атрибутов в таблице характеризует связь между записями — степень отношения.

Понятие домен имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат «истина», то элемент данных является элементом домена. Наиболее правильное интуитивное понимание домена — допустимое множество значений данного типа; оно определяется для каждого атрибута. Данные считаются сравнимыми только в том случае, когда они относятся к одному домену. Если все атрибуты одного отношения определены на разных доменах, целесообразно использовать для именования атрибутов имена соответствующих доменов.

Ключ отношения — это подмножество атрибутов, имеющее следующие свойства:

•уникальность идентификации;

•уникальность значения ключа для каждого кортежа; невозможность удаления ни одного из атрибутов ключа без нарушения его уникальности;

•выполнение функции обеспечения неизбыточности и целостности БД.

Например, уникальным ключом в телефонном справочнике может быть номер телефона; если атрибуты ключа — фамилия, имя, адрес, то при пропуске в записи адреса ключ теряет уникальность.

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

Существует несколько форм нормализации (более пяти). Первая из них (1NF) связана с требованием, согласно которому

для каждой записи значение атрибута в столбце может быть только одно, чтобы не привести к неоднозначности ответа на запрос по этому атрибуту.

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

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

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

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

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

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