122

совместно используемые таблицы в пределах одного блока. Кластеризация таблиц дает значительный эффект в том случае, если в системе приходится оперировать запросами, которые требуют совместной обработки данных из нескольких таблиц. В кластере таблицы хранятся ключ кластера (столбец, который используется для объединения таблиц) и значения из столбцов в кластеризованных таблицах. Поскольку кластеризованные таблицы хранятся в одном блоке БД, время на выполнение операций ввода-вывода заметно сокращается [18].

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

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

8.1.4.Управление индексами

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

8.1.5. Словарь данных

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

123

интересующую информацию о БД, а именно — информацию о таблицах, индексах, представлениях, пакетах и процедурах [18].

Например, словарь данных СУБД ORACLE может предоставлять следующую информацию:

−имена пользователей ORACLE

−привилегии и роли, которые были предоставлены каждому пользователю;

−имена объектов схем (таблиц, представлений, снимков, индексов, кластеров, синонимов, последовательностей, процедур, функций, пакетов, триггеров и т.д.);

−информацию об ограничениях целостности;

−умалчиваемые значения для столбцов;

−сколько пространства было распределено и в настоящее время используется объектами в базе данных;

−информацию аудита, например, кто обращался к различным объектам и обновлял их другую общую информацию о базе данных.

Доступ к словарю данных возможен только в режиме чтения. Одной из составляющих словаря данных и ключевым компонен-

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

Словарь данных призван помочь пользователю в выполнении следующих функций [7]:

−установлении связи с другими пользователями;

−осуществлении простого и эффективного управления элементами данных при вводе в систему новых элементов или изменения описания существующих;

−уменьшении избыточности и противоречивости данных;

−определении степени влияния изменений в элементах данных на всю БД;

−централизации управления элементами данных с целью упрощения проектирования БД и расширения.

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

иобъектами БД.

Такой словарь должен [7]:

124

1)поддерживать концептуальную, физическую и внешние модели данных;

2)быть интегрированным в СУБД;

3)должен поддерживать возможность хранения нескольких версий программной реализации;

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

8.1.6. Прочие объекты БД

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

Триггеры (triggers) — это хранимые процедуры, которые запускаются при выполнении определенных действий с таблицей. Можно создать триггеры, которые будут запускаться при операциях вставки, удаления или обновления данных. Возможны варианты создания таких триггеров, которые будут выполняться при обращении к каждой строке или при каждом запросе к таблице. Триггеры представляют удобное средство для обеспечения логической целостности данных.

Хранимые пакеты, процедуры и функции

Хранимые пакеты, процедуры и функции хранятся в словаре дан-

ных. Там же сохраняется их исходный код. Хранимая процедура — это

125

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

Последовательности — это объекты БД, введенные в некоторые СУБД нового поколения (Oracle, MS Access 97 и др.), которые используются для формирования уникальных числовых величин. При каждом извлечении очередного числа из последовательности происходит его приращение. Последовательности используются при формировании уникальных чисел для конкретного поля таблицы, являющегося первичным ключом.

Журнальная информация

Журнал обычно представляет собой чисто последовательный файл с записями переменного размера, которые можно просматривать в прямом или обратном порядке. Обмены производятся стандартными порциями (страницами) с использованием буфера оперативной памяти. Cтруктура журнальных записей известна только компонентам СУБД, ответственным за журнализацию и восстановление. Поскольку содержимое журнала является критичным при восстановлении базы данных после сбоев, к ведению файла журнала предъявляются особые требования по части надежности [1]. Обычно поддерживается две копии журнала на разных дисках.

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

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