126

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

Служебная информация

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

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

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

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

8.2.Оптимизация работы с БД

8.2.1.Оптимизация работы с таблицами

Существует несколько возможностей оптимизировать работу с таблицами.

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

данных.

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

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

При выборе типа данных, используемых в поле, необходимо учитывать следующее:

127

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

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

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

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

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

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

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

ких данных, как документы Microsoft Word или Microsoft Excel, рисун-

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

8.2.2. Ограничения целостности

В разделе 4.2.4 мы подробно рассматривали характеристики реляционных отношений. Здесь же отметим еще одно определение целостности и опишем некоторые важные моменты, связанные с этим понятием. Будем считать, что целостность понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных. Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1, 2, 3, 4, 5, 6, 7).

128

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

Выделяют три группы правил целостности:

1)по сущностям;

2)по ссылкам;

3)целостность доменов или целостность, определяемая пользователем.

Существует два правила целостности, общих для любых реляци-

онных баз данных:

1)не до пускается, чтобы атрибут, находящийся в первичном ключе, принимал неопределенное значение;

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

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

−уникальность тех или иных атрибутов;

−диапазон значений;

−принадлежность набору значений (пол «М» или «Ж»).

8.2.3. Сжатие данных

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

Естественно, что механизм сжатия данных должен быть обратим. Преимущества СУБД, используемых сжатие данных [6]:

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