Файл: Базы данных - уч. пособие.pdf

126

Глава 6. Физическая организация баз данных

6.1.5 Прочие объекты базы данных

Остановимся более подробно на других объектах БД, кратко представленных

в 6.1.1.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Представления (views) — это хранимые предложения SQL, кото-
рые можно запросить. Они используются из соображений рас-
пределения предоставляемых пользователю определенных данных.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

С помощью представлений возможно упростить сложные запросы и сделать их

более понятными, а также появляется возможность скрыть распределенные объек-
ты БД. Любое выражение, представленное в виде SQL-запроса на выборку, можно
оформить в виде представления.

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

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

При формировании представлений можно оптимизировать структуру проме-

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

Фактически, любой запрос на выборку, представленный в разделе 5, Вы мо-

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Можно создать триггеры, которые будут запускаться при операциях вставки,

удаления или обновления данных.

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

при обращении к каждой строке или при каждом запросе к таблице. Триггеры
представляют удобное средство для обеспечения логической целостности данных.

Одна из важных возможностей триггеров — это возможность реализации с их

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

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

же сохраняется их исходный код.

6.1 Структуры внешней памяти, методы организации индексов

127

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

Следует отметить, что принципы реализации хранимых процедур различаются

для каждой конкретной СУБД, однако в основе всех принципов лежит использо-
вание процедурного расширения языка SQL.

Хранимые процедуры и функции могут также содержать аргументы ввода,

необходимые для формирования динамического запроса. Хранимые процедуры
и функции могут определяться относительно одной или нескольких таблиц БД [18].

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

При каждом извлечении очередного числа из последовательности происходит

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

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

Журнал обычно представляет собой чисто последовательный файл с запися-

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

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

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

Во втором варианте поддерживается общий журнал изменений БД, использу-

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

128

Глава 6. Физическая организация баз данных

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

Служебная информация
Как отмечалось выше, для корректной работы подсистемы управления данны-

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

• внутренних каталогов, описывающих физические свойства объектов БД,

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

• описателей свободной и занятой памяти в страницах отношения. Такая ин-

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

• связывания страниц одного отношения. Если в одном файле располагаются

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

Например, в СУБД MS Access существуют служебные (системные) таблицы,

в которых хранится, в том числе, информация обо всех объектах, созданных в базе
данных. На рисунке 6.4 приведена структура системной таблицы MSysObjects БД
СУБД MS Access.

Рис. 6.4 – Структура таблицы MSysObjects БД СУБД MS Access

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

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

6.2 Оптимизация работы с базами данных

129

6.2 Оптимизация работы с базами данных

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

1. Создавайте таблицы, не содержащие избыточных данных, — стремитесь к нор-

мализации.

2. Создавайте индексы для сортируемых и объединяемых полей, а также для

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

3. Определяйте тип данных полей с учетом максимально точно подходящего

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

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

• тип значений, которые должны отображаться в поле (например, нельзя

хранить текст в поле, имеющем числовой тип данных);

• размер данных для хранения значений в поле;

• возможность применения математических и других операций со зна-

чениями в поле (например, суммировать значения можно в числовых
полях и в полях, имеющих валютный формат, а значения в текстовых
полях и полях объектов OLE — нельзя);

• необходимость сортировки или индексирования поля (сортировать и ин-

дексировать поля MЕМО, гиперссылки и объекты OLE невозможно);

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

сах или отчетах. Поля MЕМО, гиперссылки и объекты OLE исполь-
зовать для группировки записей нельзя;

• порядок сортировки значений в поле. Числа в текстовых полях сорти-

руются как строки чисел (1, 10, 100, 2, 20, 200 и т. д.), а не как чис-
ловые значения. Для сортировки чисел как числовых значений необ-
ходимо использовать числовые поля или поля, имеющие денежный
формат (если СУБД поддерживает такой тип данных). Также многие
форматы дат невозможно отсортировать надлежащим образом, если
они были введены в текстовое поле.

Поля с типом данных объект OLE используются для хранения таких данных,

как документы Microsoft Word или Microsoft Excel, рисунки, звук и объекты других
программ. Объекты OLE могут быть связаны или внедрены в поля таблиц СУБД,
поддерживающих возможность работы с OLE-объектами.

130

Глава 6. Физическая организация баз данных

5. Первичные и внешние ключи следует по возможности определять только

на числовых полях либо на полях типа Дата/время, если это поле входит
в составной первичный ключ.

6. Если первичный ключ может быть построен не менее чем на четырех по-

лях — следует заменить его суррогатным ключом.

7. Таблицы справочники-классификаторы создавайте только для реально по-

вторяющихся значений — например, нет смысла в базе данных создавать
отдельные справочники-классификаторы для фамилий, имен и отчеств, до-
статочно в таблице с описанием людей выделить три отдельных поля: Фа-
милия, Имя, Отчество.

8. Необходимо периодически производить сжатие базы данных.

При наличии запоминающих устройств с большим объемом памяти проблема

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

Естественно, что механизм сжатия данных должен быть обратим. Преимуще-

ства СУБД, использующих сжатие данных [6]:

• в территориально удаленных СУБД передача данных от одного узла к дру-

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

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

ше устройств резервного копирования;

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

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

В различных СУБД могут существовать свои алгоритмы сжатия данных, одна-

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

9. Следует удалять индексы, необходимость в которых отсутствует (см. раз-

дел 6.1.3).

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