Обзор основных компонентов субд

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

Часто СУБД поддерживает индексы данных. В этом случае индексы часть хранимых данных, а описание, указывающее, какие атрибуты имеют индексы,часть метаданных.

Рис.8. Главные компоненты СУБД

Диспетчер памяти

Задача диспетчера памятиполучать требуемую информацию из хранилища данных и изменять в нем информацию по требованию расположенных выше уровней системы.

Диспетчер памяти состоит из двух компонентов: диспетчера буфера и диспетчера файлов.

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

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

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

Процессор запросов

Следующий компонент называется процессором запросов. Это название не совсем точное, поскольку этот элемент не только обрабатывает запросы, но и запрашивает изменения данных или метаданных. Его задачанайти наилучший способ выполнения требуемой операции и дать соответствующие команды диспетчеру памяти.

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

Рассмотрим пример банковской БД, содержащий два файла:

1. Клиенты файл, содержащий записи с информацией об имени, регистрационном номере, паспортных данных и адресе клиента.

2. Счета файл, содержащий записи с информацией о номере счета, балансе и регистрационном номере владельца.

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

Для ответа на запрос нужно проверить файл Клиенты, чтобы найти регистрационный номер Петра Сергеевича Иванова (предполагается, что существует единственный клиент с таким именем, хотя на практике их может оказаться несколько). Затем следует проверить файл Счета, чтобы найти каждый счет с данным регистрационным номером и напечатать балансы этих счетов.

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

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

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

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

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