WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 | 2 || 4 | 5 |   ...   | 6 |

«ББК 32.973 43 Скляр А.Я. ...»

-- [ Страница 3 ] --

int for(int if(t>='a' t<='z') else if(t>=224) t-=32;

a[i]=t;

} return } Особенности представления данных в InterBase При работе с данными различных типов необходимо учитывать осо бенности их представления в InterBase.

Таблица 6.10. Соответствие типов данных в InterBase и С Тип InterBase Объявление данных в С (C++) SMALLINT short int p;

INTEGER int p;

FLOAT float p;

DOUBLE PRECISION double p;

172 Глава Тип InterBase Объявление данных в С (C++) n) / DECIMAL(m, n) если m<5, то short p;

если 5

Для версий до если double p Для версий от 6. если 10

значение задается с масштабирующим множителем DATE массив из 2 int p[2];

р[0] - количество дней с 17 ноября 1858;

р[1] - количество секунд* 10000 от на чала суток CHARACTER(n) / CHAR(n) char p[n];

(двоичный 0 в конце не пред полагается, заполняются пробелами справа до явно указанной длины) VARYING CHARACTER / struct / VARCHAR(n) short int char p2[n];

- фактическая длина поля;

p.p2 - символьная строка (двоичный 0 в конце не предполагается) CSTRING(n) char p[n+l];

(с двоичным 0 в конце в качестве ограничителя) BLOB см. ниже пример для работы BLOB Пример UDF для работы с BLOB Данная функция читает содержимое BLOB и записывает его в файл COPYBLOB.ooo. В данном случае используется явный вызов функций API, о котором говорилось в разделе 6.2, для доступа к данным InterBase.

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

Пример 6. // описание управляющей структуры BLOB Расширенные возможности для работы с базой struct blobs ( void *,long, int *blob_handle;

long number_segments;

long long total_size;

void struct blobs* SBLOB;

extern "C" int bl) ;

int bl) { long char FILE *out;

return 0;

// проверка, что действительно передан BLOB return -1;

// проверка успешности создания файла ;

// создание буфера для чтения цикл чтения BLOB и записи его в файл 1, length, out);

fclose(out);

6.4. Фильтры BLOB buffer;

Фильтры BLOB (Binary Large Object - большой двоичный объект) return 1;

это программы на базовом языке, которые конвертируют данные BLOB из } одного формата в другой. К фильтрам BLOB можно обращаться через isql Отметим, что практическая ценность программы невелика, но она ил люстрирует механизм чтения данных из BLOB.

или из программ на базовом языке.

Замечание. Фильтры BLOB не поддерживаются на серверах NetWare.

174 Глава б ФИЛЬТРАЦИЯ ДАННЫХ BLOB Понимание роли подтипов BLOB особенно важно при работе с фильтрами BLOB. Фильтр BLOB - подпрограмма, которая транслирует данные BLOB одного подтипа в другой. InterBase включает набор специ альных внутренних фильтров BLOB, которые конвертируют подтип О в подтип 1 (текст), и подтип 1 (текст) в подтип 0. В дополнение к стан дартным фильтрам можно запрограммировать собственные внешние фильтры для обеспечения конвертирования других типов данных. Напри мер, можно запрограммировать фильтр для трансляции растровых изо бражений или медиаданных одного формата в другой (другой вопрос, для чего это нужно делать именно в базе).

Замечание Фильтры BLOB можно использовать для баз данных на всех плат формах сервера InterBase, кроме Netware, где фильтры BLOB не поддер живаются.

Использование стандартных текстовых фильтров InterBase Стандартные фильтры InterBase конвертируют данные BLOB подтипа 0 или любого другого системного типа InterBase в подтип 1 (текст).

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

Для конвертирования любого нетекстового подтипа в текст следует объявлять его FROM-подтип как подтип 0, а его ТО-подтип как подтип Использование внешних фильтров BLOB В отличие от стандартных фильтров InterBase, которые выполняют трансляцию подтипов 0 и внешний фильтр BLOB - вообще часть биб лиотеки подпрограмм, которая создается для конкретных приложений.

Чтобы использовать внешний фильтр, необходимо сначала запро граммировать его, откомпилировать, поместить в библиотеку (DLL в сис теме Windows), затем объявить в базе данных, содержащей данные BLOB, которые должны обрабатываться.

Расширенные возможности для работы с базой Объявление внешних фильтров в базе данных Для объявления внешних фильтров в базе данных используется ко манда DECLARE FILTER. Например, следующая команда объявляет фильтр Пример 6. EXEC SQL DECLARE FILTER TFILTER -1 - "_TFilter" В примере, входной подтип фильтра определен как выходной как 2. В этом примере, INPUTTYPE определяет текст нижнего регистра, a определяет текст верхнего регистра. Цель фильтра TFILTER, таким образом, состоит в том, чтобы конвертировать данные BLOB из текста в нижнем регистре в текст верхнего регистра.

Параметры и определяют внеш нюю подпрограмму, которую InterBase вызывает, когда запрашивается фильтр. Параметр определяет MYDLL.dll, динамически загружаемую библиотеку, содержащую выполнимый код фильтра. Пара метр определяет точку входа в DLL. В примере указана та же библиотека, что и для UDF, но можно поместить фильтры и в другую.

Никаких ограничений на этот счет нет.

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

Рис. 6.3. Схема работы фильтра BLOB (строчные в прописные).

Точно так же при чтении данных фильтр TFILTER может читать дан ные BLOB подтипа -2 и преобразовать их в подтип -1.

176 Глава Вызов фильтра в приложении Для вызова фильтра в приложении используется опция FILTER при объявлении курсора BLOB. Тогда при выполнении приложением опера ций, использующих курсор, InterBase автоматически вызывает фильтр.

Например, следующее определение курсора INSERT означает, что фильтр SAMPLE, должен использоваться в любых операциях с курсором Пример 6. EXEC SQL DECLARE CURSOR FOR INSERT BLOB INTO TABLE FILTER FROM -1 TO -2;

Когда InterBase обрабатывает это объявление, он ищет в списке фильтров, определенных в текущей базе данных, фильтр с соответствием подтипов FROM и ТО. Если такой фильтр существует, InterBase вызывает его при операциях с BLOB, использующих курсор Если InterBase не может найти такой фильтр, приложению возвращается сообщение об ошибке.

НАПИСАНИЕ ВНЕШНИХ ФИЛЬТРОВ Для написания собственных фильтров необходимо детальное пони мание структуры транслируемых данных. InterBase не выполняет провер ки данных BLOB, но требует совместимости типов исходного и результи рующего BLOB. Поддержание совместимости лежит на разработчике фильтра.

Типы фильтров Фильтры разделяются на два типа: те, которые преобразовывают дан ные по одному сегменту, и те, которые преобразовывают данные множе ства сегментов одновременно.

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

Read-only и write-only фильтры Некоторые фильтры могут поддерживать только чтение из BLOB или только запись в BLOB, но не обе операции. При попытке использовать фильтр BLOB для операции, которую он не поддерживает, InterBase воз вращает приложению сообщение об ошибке.

Создание функций фильтров При создании фильтра необходимо указать точку входа, задающую имя функции фильтра в разделе объявлений программы. InterBase вызыва ет функцию фильтра, когда приложение выполняет операции с BLOB. Все связи между InterBase и фильтром реализуются функцией фильтра. Функ ция самого фильтра может вызывать другие функции, которые необходи мы для выполнения программы фильтра. Далее фильтр должен быть объ явлен в базе данных командой DECLARE FILTER с указанием параметров В Функция фильтра должна иметь следующую сигнатуру:

action, isc_blob_ctl control);

Параметр action определяет одно из восьми возможных макроопреде лений действия, параметр control определяет управляющую структуру isc_blob_ctl данных BLOB. Определение структуры isc_blob_ctl дано в заголовочном файле InterBase ibase.h. Эти параметры будут рассмотрены ниже. Приведем теперь основные декларативные элементы функции фильтра Пример 6. #define SUCCESS FAILURE ISC_STATUS action, isc_blob_ctl control) { ISC_STATUS status = SUCCESS;

switch (action) { case 178 Глава б case break;

case isc_blob_filter_create:

break;

case break;

case case case break;

case break;

default:

status = isc_uns_ext /* unsupported action value */ break;

} return status;

} InterBase передает одно из восьми возможных действий (параметр action) функции фильтра () и экземпляр управляющей структу ры BLOB (параметр isc_blob_ctl).

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

lsc_blob_ctl - управляющая структура BLOB;

содержит основные данные для управления обменом между InterBase и фильтром.

Определение управляющей структуры BLOB Управляющая структура isc_blob_ctl обеспечивает базовые методы обмена данными между InterBase и фильтром. Объявление управляющей структуры находится в заголовочном файле InterBase ibase.h. Для его под ключения к программе используется инструкция Расширенные возможности для работы с базой .

typedef struct ISC_STATUS *ctl_source)();

/* Source filter */ struct isc_blob_ctl ISC_FAR *ctl_source_handle;

/* Argument to pass to source */ /* filter */ short ctl_to_sub_type;

Target type */ short /* Source type */ unsigned short /* Length of buffer */ unsigned short ctl_segment_length;

/* Length of current segment */ unsigned short ctl_bpb_length;

/* Length of blob pa rameter */ block */ char *ctl_bpb;

/* Address of blob parameter */ /* block */ unsigned char ISC_FAR /* Address of segment buffer */ Length of longest seg ment */ /* Total number of segments */ ctl_total_length;

/* Total length of blob */ ISC_STATUS ISC_FAR Address of status vec tor */ long [8];

/* Application specific data */ Структура isc_blob_ctl используется двумя способами:

Когда приложение исполняет операцию доступа к BLOB, InterBase вызывает функцию фильтра и передает ей экземпляр isc_blob_ctl.

2. Функции фильтра могут передавать экземпляр isc_blob_ctl под программам доступа к данным InterBase.

В любом случае назначение некоторых полей isc_blob_ctl зависит от выполняемого действия (параметр action). Например, когда приложение делает попытку вставки BLOB, InterBase передает функции фильтра дей ствие-вставку (параметр action Функция фильтра передает экземпляр управляющей структуры InterBase.

структуры содержит сегмент данных, которые должны быть записаны согласно команде INSERT BLOB приложения. Поскольку буфер содержит информацию для передачи в функцию, это поле является входным. В случае то есть для выполнения записи в базу данных, функция фильтра должна включить команды в кон струкции case.

180 Глава б В другом случае, например, когда приложение делает попытку вы полнить команду FETCH, действие - выборка (параметр action = В функцию фильтра должна включаться группа команд для заполнения данными сегмента из базы дан ных для его возврата приложению, вызвавшему функцию. Здесь буфер используется в функции фильтра как выходной.

В таблице ниже описываются поля управляющей структуры BLOB iscblobctl и характер их использования в функции фильтра (входные IN, выходные - OUT).

Таблица 6.10. Управляющая структура BLOB isc_blob_ctl Имя поля Описание Указатель на внутреннюю подпрограмму InterBase досту (*ctl_source)() па к BLOB. (IN) *ctl_source_handle Указатель на экземпляр который передается внутренней подпрограмме InterBase доступа к BLOB. (IN) ctl_to_sub_type Указывает подтип BLOB-результата. Информационное поле. Необходимо для многоцелевых фильтров, которые могут исполнять несколько видов преобразований. Это и следующее поля дают возможность такому фильтру опре делить, какую именно трансляцию следует выполнить. (IN) ctl_frora_sub_type Указывает подтип BLOB-источника. Информационное по ле. Необходимо для многоцелевых фильтров, которые мо гут исполнять несколько видов преобразований. Это и пре дыдущее поля дают возможность такому фильтру опреде лить, какую именно трансляцию следует выполнить. (IN) Для поле - входное (IN), со держащее длину сегмента данных в Для isc blob filter get segment поле - входное (IN), устанавли вающее размер буфера (адресованного ctlbuffer) для со хранения полученных из BLOB данных ctl_segment_length Длина текущего сегмента. Это поле не используется для Для segment поле - выходное (OUT) устанавливается в длину сегмента полученных из BLOB данных (или части сегмента, если длина буфера ctl buffer length меньше фактической длины сегмента) ctl_bpb_length Длина буфера параметров BLOB. Зарезервировано для будущего расширения Расширенные возможности для работы с базой поля Описание *ctl_bpb Указатель на буфер параметров BLOB. Зарезервировано для будущего расширения *ctl_buffer Указатель на буфер сегмента. Для поле - входное (IN). Содержит данные сегмента. Для isc blob filter get segment поле выходное (OUT), функция фильтра заполняет его данными сегмента для возврата вызвавшему фильтр приложению Длина самого большого сегмента в BLOB. Начальное зна чение - 0. Это поле устанавливает функция фильтра. Поле только информационное ctl_number_segments Начальное значение - 0. Это поле устанавливает функция фильтра. Поле только информационное ctl_total_length Полная длина BLOB. Начальное значение - 0. Это поле устанавливает функция фильтра. Поле только информационное *ctl_status Указатель на вектор состояния InterBase. (OUT) ctl_data[8] Массив из 8 элементов. Зависит от приложения. Можно использовать это поле, например, для хранения указателей на ресурсы, типа указателей памяти и дескрипторов файла, созданных isc blob filter open. Тогда при следующем вызове функции фильтра указатели ресурсов будут доступны для использования. (IN/OUT) Установка значений полей управляющей структуры Структура isc_blob_ctl содержит три поля, сохраняющие информацию о BLOB, к которому осуществляется доступ: ctl_max_segment, и Необходимо контролировать правильность значений этих полей в функции фильтра всегда, когда это возможно. В зависимости от назна чения фильтра поддержка правильности значений этих полей не всегда возможна. Например, фильтр, который сжимает данные посегментно, не может определять размер пока не обработаны все сегменты.

Эти поля носят только информационный характер. InterBase не ис пользует значения этих полей во внутренней обработке.

ПРОГРАММИРОВАНИЕ ДЕЙСТВИЙ ФУНКЦИИ ФИЛЬТРА Когда приложение выполняет операцию доступа к BLOB, InterBase передает функции фильтра соответствующее сообщение о действии в па 182 Глава раметре action. Имеются восемь возможных действий, каждое из которых является следствием специфической операции доступа. Следующий спи сок макроопределений действий объявлен в заголовочном файле ibase.h:

#define #define #define #define #define #define Приводимая таблица описывает операции доступа к BLOB, которые соответствуют каждому действию (параметр action).

Таблица 6.10. Операции доступа к BLOB в зависимости от параметра action Действие Условие вызова Назначение isc_blob_filter_open Приложение открывает Установка информационных BLOB курсор на чтение полей управляющей струк туры BLOB. Выполняет за дачи инициализации, типа распределения памяти или открытия временных файлов.

Устанавливает в случае не обходимости переменную состояния. Значение пере менной состояния становит ся возвращаемым значением функции фильтра Приложение выполняет Заполнение полей и команду FETCH для ctlsegment length управ BLOB ляющей структуры BLOB содержанием сегментов от транслированных данных для возврата функцией фильтра.

Выполняет конвертирование данных, если фильтр обраба тывает BLOB посегментно.

Устанавливает переменную состояния. Ее значение ста новится возвращаемым зна чением функции фильтра Расширенные возможности для работы с базой Условие вызова Назначение Приложение закрывает Выполняется задача выхода, типа освобождения распреде курсор BLOB ленной памяти, закрытия или удаления временных файлов isc_blob_filter_create Приложение открывает Установка информационных курсор вставки BLOB полей управляющей струк туры BLOB. Выполняются задачи инициализации, типа распределения памяти или открытия временных файлов.

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

Если процесс трансляции изменяет длину сегмента, новое значение длины долж но быть отражено в парамет рах, передаваемых функции записи. Устанавливает пере менную состояния. Значение переменной состояния стано вится возвращаемым значе нием функции фильтра InterBase инициализи- Установка информационных рует работу фильтра;

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

Установка в случае необхо димости переменной состоя ния. Значение переменной состояния становится воз вращаемым значением функции фильтра Глава Условие вызова Назначение isc_blob_filter_free InterBase завершает Выполнение задачи выхода, обработку фильтра;

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

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

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

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

Таблица 6.12. Коды состояния, возвращаемые функциями фильтра Константа Величина Содержание Макроса SUCCESS 0 Указывает, что фильтр отработал успешно.

При операции чтения BLOB (isc get segment) указывает, что сегмент прочитан полностью FAILURE 1 Указывает на неудачную операцию. В боль шинстве случаев состояние более определен но указывает на тип ошибки isc_uns_ext См. ibase.h Указывает, что предпринятое действие не поддерживается фильтром. Например, фильтр только для чтения возвратил бы isc uns ext для действия Расширенные возможности для работы с базой Константа Величина Содержание Макроса isc_segment См. ibase.h Указывает, что при операции чтения BLOB выделенный буфер слишком мал для хране ния оставшихся байтов текущего сегмента.

В этом случае только байтов скопировано, а остаток сегмента должен быть получен через дополнительные запросы isc_segstr_eof См. ibase.h Указывает, что при операции чтения BLOB был достигнут конец BLOB и нет более ника ких дополнительных сегментов для чтения Глава Организация хранения метаданных 7.1. Назначение и порядок использования описаний данных В InterBase описания данных, или метаданные, хранятся вместе с пользовательскими данными. Чтобы система заранее могла знать, что это за данные и как ими пользоваться, имена соответствующих таблиц заранее определены. Внешне все объекты системного характера можно легко отличить от пользовательских - они имеют стандартный префикс RDB$;

следовательно, имена, создаваемые пользователем, не должны иметь такого префикса. Правда, если об этом не предупреждать заранее, трудно вообразить, что кто-либо стал бы придумывать подобные имена.

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

Кроме системных таблиц в базе можно создавать и системные обзо ры. Автоматически они не создаются, но можно использовать готовый SQL для создания стандартных обзоров, регламентированных стандартом SQL-92. При желании можно также создать и свои собственные обзоры для обеспечения более удобного доступа к описаниям данных и коммен тариям к Организация хранения метаданных 7.2. Системные таблицы Системные таблицы InterBase содержат метаданные базы данных.

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

Прежде всего, дадим перечень этих таблиц с их описанием.

RDB$DATABASE RDB$FIELDS RDB$FILES RDB$SECURITY_CLASSES RDB$TRIGGER_MESSAGES RDB$TR1GGERS RDB$TYPES RDB$INDEX_SEGMENTS RDB$USER_PRIVILEGES RDB$CHARACTER_SETS Описывает доступные для InterBase наборы символов. Общее коли чество таких наборов - несколько десятков. В таблице задаются комбина ции значений по умолчанию. Для использования с русскоязычными дан ными в среде Widows следует либо указывать NONE, либо применять набор (Character set) В первом случае никаких преобразований данных не производится, а сортировки выполняются в порядке возраста ния кодов, что обеспечивает алфавитную сортировку текстов сначала по прописным, а затем по строчным буквам. Во втором случае, если необхо димо сортировать текстовые данные вне зависимости от регистра, то сле дует задавать упорядочением (Collation) Изменить непо средственно в таблице значение Rdb$default_collate_name с на PXW_CYRL нельзя. Необходимо задавать упорядочение при описании таблиц или доменов.

Таблица 7.1. Структура набора символов InterBase Имя столбца и Комментарий длина данных Char(31) Наименование кодовой таблицы рас познаваемой InterBase Rdb$form_of_use Char(31) Зарезервировано для внутреннего использования Rdb$number_of_characters Integer Число символов кодовой таблицы (например, для японского языка) Rdb$default_collate_name Char(31) Последовательность сравнения для кодовой таблицы по умолчанию Smallint Уникальный идентификатор кодовой таблицы Признак типа кодовой таблицы:

Определенный пользователем (0 или NULL) Системный (1) Rdb$description BLOB 80 Содержит пользовательский коммен тарий Char(31) Зарезервировано для внутреннего использования Rdb$bytes_per_character Smallint Размер символа в байтах Содержит данные об ограничениях логической целостности и NOT NULL. Данная таблица может быть полезна для получения информа ции об используемых в базе ограничениях NOT NULL (кроме явно описанных при задании доменов).

Таблица 7.2. Ограничения логической целостности Имя столбца Тип и дли- Комментарий на данных Rdb$constraint_name Char(31) Имя CHECK или NOT NULL ограниче ния Rdb$trigger_name Имя триггера, требующего СНЕСК ограничение;

для NOT NULL - имя столбца в Содержит данные о порядке (последовательности) сравнения сим вольных данных. Из таблицы видна связь между допустимыми комби нациями SHAR SET и COLLATION. В частности видно, что для ко довой таблицы (ее идентификатор 52) допустимы упорядоче ния, задаваемые только Winl251 и см. также таблицу 7.1.

Структура набора символов InterBase.

Таблица 7.3. Последовательность (порядок) сравнения символьных данньа Имя столбца Тип и длина Комментарий данных Rdb$collation_name Char(31) Имя последовательности сравнения Rdb$collation_id Уникальный идентификатор последо вательности сравнения Rdb$character_set_id Smallint Идентификатор кодовой таблицы для последовательности сравнения. Тре буется перед выполнением сравнения.

Определяет используемую кодовую таблицу.

Связан со столбцом RDB$CHARACTER_SET_ID в таблице RDB$CHARACTER_SETS Rdb$collation_attributes Smallint Зарезервировано для внутреннего ис пользования Smallint Указывает, является ли генератор определенным пользователем (значе системным (значение>0) Имя столбца Тип и длина Комментарий данных Rdb$description BLOB 80 Комментарий пользователя Char(31) Зарезервировано для внутреннего ис пользования RDB$DATABASE Содержит описание базы данных. Поле со держит имя кодовой таблицы, используемой по умолчанию.

Таблица 7.4. Описание базы данных Имя столбца и Комментарий длина данных Rdb$description BLOB 80 Комментарий пользователя Rdb$relation_id Зарезервировано для внутреннего ис пользования Rdb$security_class Char(31) Класс секретности, определенный в таблице ограничения управления доступом, описанные в указанном классе секрет ности, применяются во всей базе Rdb$character_set_name Char(31) Имя кодовой таблицы RDB$DEPENDENCIES Содержит описание зависимостей между объектами базы данных.

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

Таблица 7.5. Описание зависимостей между объектами базы данных Имя столбца Тип и Комментарий длина данных Rdb$dependent_name Char(31) Имя объекта, зависимости (обзор, триг гер, вычисляемый столбец) Организация хранения метаданных Имя столбца Тип и Комментарий длина данных Char(31) Имя объекта, аргумента зависимости Char(31) Имя столбца объекта, аргумента зависи Rdb$field_name мости Тип объекта зависимости:

• 0 - таблица • 1 - обзор • 2 - триггер • 3 - вычисляемое поле • 4 - контроль • 5 - процедура • 6 - индексное выражение • 7 - исключение • 8 - пользователь • 9 - поле • Rdb$depended_on_type Smallint Тип объекта, аргумента зависимости 0-10 (см. выше) Содержит описание исключений в базе данных. Таблица может быть использована, как для выборки текстов исключений, так и для формиро вания исключений «на Например, в триггере можно сформировать текст исключения, выполнить команду изменения соответствующей строки таблицы а затем команду исключения. В ре зультате будет выдано сообщение с измененным текстом. После выдачи исключения происходит откат транзакции, а значит и таблица исключе ний вернется в прежнее состояние.

Таблица 7.6. Описание исключений в базе данных Имя столбца Тип и длина Комментарий данных Rdb$exception_name Char(31) Имя исключения Integer № исключения Rdb$message Varchar(78) Текст сообщения исключения 192 Глава Имя столбца Тип и длина Комментарий данных Rdb$description BLOB 80 Комментарий Тип исключения:

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

Таблица 7.7. Описание размерностей массивов Имя столбца Тип и Комментарий длина данных Rdb$field_name Char(31) Имя массива (должно быть и в Rdb$dimension Smallint Указывает на измерение массива (нумерация с 0) Integer Нижняя граница данного измерения Rdb$upper_bound Integer Верхняя граница данного измерения RDBSFIELDS Содержит описание доменов, используемых в базе. Любое поле таб лицы обязательно имеет доменное имя. Это либо имя явно описанного домена, либо имя домена, автоматически формируемого при создании таблицы. Таким образом, используя эту таблицу можно получить описа ние любого поля базы данных.

Таблица 7.8. Описание полей Имя столбца Тип и длина Комментарий данных Char(31) Уникальное имя домена или сгенери рованного системой имени Организация хранения метаданных Имя столбца Тип и длина Комментарий данных Char(31) используется для SQL объектов Rdb$validation_blr BLOB 80 используется для SQL объектов Rdb$validation_source BLOB 80 используется для SQL объектов Rdb$computed_blr BLOB 80 Для вычисляемых столбцов содержит BLR (Binary Language Representation) выражение, вычисляемое в базе во время выполнения Rdb$computed_source BLOB 80 Для вычисляемых столбцов содержит исходное символьное выражение для столбца BLOB 80 Содержит выражение по умолчанию (BLR) Rdb$default_source BLOB 80 Символьное представление значения по умолчанию Smallint Длина поля столбца (для несимволь ных: 8 - точка двойн., дата, BLOB, Quad;

4 - Long, Float;

2 Short) Содержит длину дробной части чисел Smallint Задает тип поля: SMALLINT - 7;

INTEGER - 8;

- 9;

FLOAT 10;

CHAR - 14;

DOUBLE - 27;

DATE - 35;

VARCHAR - 37;

BLOB Smallint Подтип для BLOB: 0 - unspecified;

1 - text;

2 - BLR и т.д.

Rdb$missing_value BLOB 80 используется для SQL объектов Rdb$missing_source BLOB 80 используется для SQL объектов Rdb$description BLOB 80 Содержит пользовательский коммен тарий Rdb$system_flag Smallint Только для системных таблиц Rdb$query_header BLOB 80 Не используется для SQL объектов Глава Имя столбца Тип и длина Комментарий данных Smallint Длина сегмента (только для BLOB) Rdb$edit_string Varchar(125) используется для SQL объектов Rdb$external_length Smallint Длина поля во внешней таблице, для внутренних - Rdb$external_scale Smallint Масштабированная дробная часть (для целых) Rdb$external_type Smallint См.

Smallint Указывает количество измерений для массивов, иначе Smallint Пусто - может быть NULL, 1 - не NULL Rdb$character_length Smallint Длина символа в байтах (важно для иероглифов) Rdb$collation_id Идентификатор последовательности сравнения Smallint Кодовая таблица Содержит описание файлов базы данных. Таблица описывает вто ричные и теневые файлы базы данных. В тех случаях, когда база реализу ется в виде одного файла, данная таблица пуста.

Таблица 7.9. Описание файлов Имя столбца и Комментарий длина данных Rdb$file_name Varchar(2 Имя вторичного или теневого файла базы 53) Rdb$file_sequence Smallint Порядковый номер вторичного или тене вого файла базы Начальная страница вторичного или тене вого файла базы Организация хранения Имя столбца Тип и Комментарий длина данных Integer Длина файла в блоках Зарезервировано за системой Rdb$shadow_number Указывает № набора теневых файлов, иначе 0 (вторичный) RDB$FILTERS Содержит описание фильтров BLOB. С каждым фильтром BLOB связана строка таблицы, в которой задается имя фильтра и его характери стики. См. также таблицу описывающую функции пользователя.

Таблица 7.10. Описание фильтров BLOB Имя столбца Тип и длина Комментарий данных Rdb$function_name Char(31) Уникальное имя фильтра Rdb$description BLOB 80 Пользовательский комментарий Rdb$module_name Varchar(253) Имя библиотеки, содержащей испол нимый фильтр point Char(31) Имя точки входа для фильтра BLOB Rdb$input_sub_type Smallint Подтип BLOB для ввода Rdb$output_sub_type Smallint Подтип BLOB для вывода Rdb$system_flag Smallint Для пользовательского фильтра - 0, системного - больше Содержит описание истории изменения форматов столбцов таблицы.

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

Глава Таблица 7.11. Описание истории изменения форматов таблицы Имя столбца и Комментарий длина данных Определяет таблицу в Smallint Определяет номер формата таблицы;

таблица может иметь любое количество форматов в зависимости от числа обновлений таблицы BLOB 80 Содержит список всех столбцов таблицы с указанием их типа, длины и т.д.

Содержит описание параметров пользовательских функций (UDF).

Каждому параметру UDF соответствует одна строка таблицы.

Таблица 7.12. Описание параметров пользовательских функций Имя столбца Тип и дли- Комментарий на данных Rdb$function_name Char(31) Уникальное имя функции Rdb$argument_position Smallint Номер аргумента в списке аргументов функции Rdb$mechanism Smallint Тип передачи аргумента: 0 - по значению, 1 - по ссылке Smallint Тип аргумента (SMALLINT - 7;

INTEGER 8;

QUAD - 9;

FLOAT - 10;

CHAR - 14;

DOUBLE - 27;

DATE - 35;

VARCHAR - 37;

BLOB Rdb$field_scale Smallint Масштабный множитель (дробная часть) для данных, представленных целыми Rdb$field_length Smallint Длина параметра (в соответствии с типом) Smallint Зарезервировано Rdb$character_set_id Smallint Целый идентификатор кодовой таблицы Организация хранения метаданных Содержит описание пользовательских функций (UDF). Для получе ния полного описания UDF необходимо также использовать и таблицу описания параметров UDF. Связать их можно по имени функции: = Таблица 7.13. Описание пользовательских функций (UDF) Имя столбца Тип и дли- Комментарий на данных Rdb$function_name Уникальное имя функции Зарезервировано Char(31) Альтернативное имя функции, которое мо жет быть использовано в Rdb$description BLOB 80 Пользовательский комментарий Rdb$module_name Varchar Имя библиотеки, содержащей исполнимую (253) функцию Rdb$entrypoint Char(31) Имя точки входа для функции Rdb$return_argument Smallint № возвращаемого значения в списке аргу ментов Rdb$system_flag Smallint Для пользовательской функции - 0, для системной Содержит описание генераторов. Помимо пользовательских генера торов содержит и ряд системных, необходимых для генерации уникаль ных номеров для объектов базы данных.

Таблица 7.14. Описание генераторов Имя столбца Тип и дли- Комментарий на данных Rdb$generator_name Char(31) Уникальное имя генератора Rdb$generator_id Smallint Уникальный системный номер генератора 198 Глава Имя столбца Тип и дли- Комментарий на данных Генератор создан пользователем - 0, сис темный - RDB$INDEX_SEGMENTS Содержит описание полей, составляющих индекс. Для каждого декса содержит столько строк, из скольких полей состоит индекс.

док следования полей в индексе задается в столбце Rdb$index_name.

Таблица 7.15. Описание полей индекса Имя столбца Тип и дли- Комментарий на данных Rdb$index_name Имя индекса, частью которого является данный поле Char(31) Smallint № данного сегмента индекса в соответствии с сортировкой в индексе RDB$INDICES Содержит описание индексов таблиц базы данных. Таблица связыва ет индекс с таблицей, для которой он создается, а также содержит ряд данных, необходимых для оптимизации работы системы.

Таблица 7.16. Описание индексов таблиц Имя столбца Тип и Комментарий длина данных Rdb$index_name Char(31) Имя индекса Rdb$relation_name Char(31) Имя индексируемой таблицы Rdb$index_id Smallint Внутренний идентификатор Rdb$unique_flag Smallint 0 - допускает дубликаты, 1 - нет Организация хранения метаданных Имя столбца Тип и Комментарий длина данных Rdb$description BLOB 80 Комментарий пользователя Rdb$segment_count Количество сегментов в индексе (1 - про стой индекс) Rdb$index_inactive Smallint 0 - индекс активен, 1 - нет Rdb$index_type Smallint Зарезервировано Rdb$foreign_key Char(31) Имя внешнего ключа, для которого ис пользуется индекс Smallint Индекс определен пользователем = 0, сис темой > BLOB 80 Содержит BLR для выражения, вычисляе мого СУБД во время выполнения Rdb$expression_source BLOB 80 Содержит исходный текст вычисляемого выражения Rdb$statistics Double Коэффициент селективности;

используется оптимизатором для формирования страте Precision гии выборки используется.

RDB$PAGES Хранит историю выделения страниц в базе данных. Может быть ис пользована для анализа интенсивности работы с таблицами базы данных.

В основном ориентирована на внутренние нужды.

Таблица 7.17. Описание истории выделения страниц Имя столбца Тип и Комментарий длина данных Rdb$page_number Integer № физически выделенной страницы Rdb$relation_id Smallint Идентификационный № таблицы, для кото рой выделена страница Глава Имя столбца и Комментарий длина данных Rdb$page_sequenc Integer Порядковый № страницы в таблице ранее е выделенных страниц Тип страницы (только для внутреннего ис пользования) Содержит описание параметров хранимых процедур. Каждому пара метру хранимой процедуры соответствует одна строка таблицы.

Таблица 7.18. Описание параметров хранимых процедур Имя столбца Тип и Комментарий длина данных Char(31) Имя параметра Rdb$procedure_name Char(31) Имя процедуры Smallint Порядковый № параметра Rdb$parameter_type Smallint Тип параметра: 0 - входной, 1 - выход ной Char(31) Глобальное имя столбца Rdb$description BLOB 80 Комментарий пользователя Smallint Определен пользователем - 0, системой - больше Содержит описание хранимых процедур. Для получения полного описания хранимой процедуры необходимо также использовать и табли цу описания параметров хранимых процедур. Связать их можно по имени хранимой процедуры:

rdb$procedure_name.rdb$parameter_name = См. также - описание пользовательских функций (UDF).

Организация хранения метаданных Таблица 7.19. Описание хранимых процедур Имя столбца Тип и Комментарий длина данных Char(31) Имя процедуры Rdb$procedure_id Smallint № процедуры Rdb$procedure_inputs Smallint Количество входных параметров Rdb$ procedure_outputs Smallint Количество выходных параметров Rdb$description BLOB 80 Комментарий пользователя BLOB 80 Исходный текст кода процедуры Rdb$procedure BLOB 80 код процедуры Rdb$security_class Char(31) Класс секретности процедуры Rdb$owner_name Char(31) Имя владельца (создателя) процедуры blob BLOB 80 Описание метаданных процедуры Smallint Определен пользователем - 0, системой больше Содержит описание ограничений логической целостности данных.

В частности здесь описываются все вешние (FOREIGN) ключи.

Таблица 7.20. Описание ограничений логической целостности данных Имя столбца Комментарий длина данных Char(31) Имя ограничения Rdb$const_name_uq Char(31) Имя ограничения первичного или уни кального ключа Rdb$match_option Char(7) Зарезервировано (по умолчанию FULL) Rdb$update_rule Char(ll) Задает тип действия с вторичным клю чом при изменении первичного (допус 202 Глава Имя столбца Тип и Комментарий длина данных тимые значения: NO ACTION, CASCADE, SET NULL, SET DEFAULT) Задает тип действия с вторичным клю чом при изменении первичного (допус тимые значения: NO ACTION, CASCADE, SET NULL, SET DEFAULT) Содержит описание ограничений для таблиц. Для каждого ограниче ния указывается его тип (RIMARY KEY, UNIQUE, FOREIGN KEY, NOT NULL), если ограничение связано с индексом, то обозна чение индекса в таблице указывается в поле Rdb$index_name, обеспечи вая связь с таблицей RDBSINDICES.

Таблица 7.21. Описание ограничений для таблиц Имя Тип и дли- Комментарий на данных Rdb$constraint_name Имя ограничения Тип ограничения таблицы (RIMARY KEY, UNIQUE, FOREIGN KEY, PCHECK, NOT NULL) Rdb$relation_name Char(31) Имя таблицы Rdb$deferrable Char(3) Зарезервировано умолчанию - No) Rdb$initially_deferred Char(3) Зарезервировано (по умолчанию - No) Rdb$index_name Char(31) Имя индекса, используемого ограни чениями UNIQUE, PRIMARY KEY, FOREIGN KEY Содержит описание столбцов таблиц базы данных. По каждому столбцу указана таблица, в которой он используется и доменное имя, та ким образом, используя данную таблицу вместе со связанными с ней, можно восстановить полное описание столбца.

Организация хранения метаданных Таблица 7.22. Описание столбцов таблиц базы данных Имя столбца Тип и Комментарий длина данных Char(31) Char(31) Имя таблицы Rdb$field_source Char(31) Имя описания поля в таблице RDBSFIELDS Rdb$query_name Char(31) Альтернативное имя поля для использования в замещает значение в RDBSFIELDS Char(31) Только в обзорах;

имя столбца из RDBSFIELDS в таблице или обзоре, который является базовым для данного. Для базового столбца:

обеспечивает имя столбца, - столбец в этой таблице задает имя исходной таблицы Rdb$edit_string Char (125) Не используется в isql Rdb$field_position Smallint № столбца в списке (используется в isql для задания порядка вывода столбцов, в gpre в командах SELECT и INSERT;

если не сколько столбцов имеют один номер, поря док их вывода не определен) Rdb$query_header BLOB 80 Не используется в isql Smallint используется в InterBase Smallint Идентификатор для использования в BLR для именования столбца Rdb$view_context Smallint Псевдоним, используемый для уточнения столбца обзора, указывая на столбец базовой таблицы;

имеет то же значение, что и псев доним, используемый в BLR Rdb$description BLOB 80 Комментарий пользователя Rdb$default_value BLOB 80 Описание столбца (BLR) Smallint Определен пользователем - 0, системой больше 204 Глава Имя столбца Тип и Комментарий длина данных Rdb$security_class Char(31) Класс секретности в Rdb$complex_name Char(31) Зарезервировано Rdb$null_flag Определяет, может ли столбец содержать NULL Rdb$default_source BLOB 80 Описание столбца (текст) Rdb$collation_id Smallint Идентификатор последовательности сравне ния Содержит описание таблиц и обзоров базы данных. Если строка опи сывает обзор, то поле Rdb$view_source содержится текст команды SELECT, соответствующей обзору. Например, для обзора RUBRICS на шей тестовой базы значением этого поля будет текст:

sel ect UNIKEY, from where (matherkey=0) Таблица 7.23. Описание таблиц и обзоров базы данных Имя столбца Тип и дли- Комментарий на данных Rdb$view_blr BLOB 80 Для обзоров. Содержит BLR запроса Rdb$view_source BLOB 80 Для обзоров. Содержит текст запроса Rdb$relation_id Smallint Внутренний идентификатор для BLR Smallint Определен пользователем - 0, системой больше Rdb$dbkey_length Smallint Длина ключа базы данных: для таблиц 8;

для обзоров - 8*количество таблиц в обзоре Rdb$format Smallint Только для внутреннего использования InterBase Smallint Количество столбцов в таблице Rdb$relation_name Smallint Имя таблицы Организация хранения метаданных Имя столбца Тип и дли- Комментарий на данных Rdb$security_class Char(31) Имя класса секретности, определенного в таблице RDB$SECURITY_CLASSES Rdb$external_file Varchar Имя файла, содержащего внешнюю таб (253) лицу Rdb$runtime BLOB 80 Содержит описание метаданных Rdb$external_description BLOB 80 Пользовательское описание внешнего файла Rdb$owner_name Char(31) Имя владельца (создателя) таблицы Rdb$default_class Char(31) Класс секретности по умолчанию Содержит список ролей, определенных в базы данных и их владельцев.

Таблица 7.24. Описание ролей в базы данных Имя столбца Тип и дли- Комментарий на данных Char(31) Имя роли Rdb$owner_name Char(31) Имя владельца (создателя) роли RDB$SECURITY_CLASSES Задает список для управления доступом к таблицам, обзорам и их столбцам. По значению поля Rdb$security_class с данной таблицей связа ны таблицы описания базы данных - RDB$DATABASE, описание таблиц и обзоров базы данных - и описание столбцов таблиц базы данных Глава Таблица 7.25. Описание ограничений доступа к объектам базы данных Имя столбца Тип и дли- Комментарий на данных Char(31) Имя класса секретности Rdb$acl BLOB 80 Список управления доступом, опреде ляющий пользователей, и переданных им прав Rdb$description BLOB 80 Комментарий пользователя Хранит историю транзакций, работающих с несколькими базами данных. При работе с одной базой таблица пуста.

Таблица 7.26. Описание истории транзакций, работающих с несколькими базами данных Имя столбца Тип и Комментарий длина данных Rdb$transaction_id Integer Идентификатор multi-database тран закции Rdb$transaction_state Smallint Состояние: 0 - limbo;

1 - committed;

2 - rolled back Rdb$timestamp Date Зарезервировано Rdb$transaction_description BLOB 80 Описывает подготовленную multi database транзакцию, доступную при неудаче повторного соединения Описывает сообщения системных триггеров с привязкой к конкретному триггеру. Пользовательские триггеры создают свои сообщения, используя механизм исключений, и в этой таблице не появляются.

Организация хранения метаданных Таблица 7.27. Описание сообщения триггеров Имя столбца Тип и длина Комментарий данных Rdb$trigger_name Char(31) Имя триггера Rdb$message_number Smallint № сообщения Rdb$message Varchar(78) Текст сообщения RDB$TRIGGERS Содержит описание всех триггеров базы данных. Использую текст, хранимый в поле Rdb$trigger_source можно получить исходный текст тела триггера. Заголовочную часть триггера может быть определена по значе ниям полей Rdb$trigger_source, Rdb$trigger_type, Rdb$trigger_inactive, смысл которых ясен из приведенной ниже таблицы.

Таблица 7.28. Описание триггеров Имя столбца Тип и дли- Комментарий на данных Rdb$trigger_source Char(31) Имя триггера Rdb$relation_name Char(31) Имя таблицы Rdb$trigger_sequence Smallint Порядковый триггера (определяет последовательность выполнения тригге ров) Rdb$trigger_type Smallint Тип триггера: 1 - BEFORE INSERT;

2 AFTER INSERT;

3 - BEFORE UPDATE;

4 - AFTER UPDATE;

5 - BEFORE DELETE;

6 - AFTER DELETE Rdb$trigger_source BLOB 80 Текст триггера (исходный) Rdb$trigger_blr BLOB 80 Текст триггера (BLR) Rdb$description BLOB 80 Комментарий пользователя Smallint 0 - триггер активен, 1 - не активен Smallint Определен пользователем - 0, системой - больше Smallint 208 Глава RDB$TYPES Содержит перечень типов данных и алиасов символьных наборов и последовательностей сравнения символьных наборов. В версии 5 недос тупна. В версии 6 может использоваться. Для каждого типа данных задает возможные его значения, например для типа поля - это TEXT, SHORT, BLOB, CSTRING, TIME и т.д. Для подтипа - ACL, и т.д. Для механизма передачи данных BY_VALUE, BY_REFERENCE и т.д. Для типа триггера и т.д. Для типа объекта VIEW, TRIGGER, и т.д. Для состояния транзакции LIMBO, COMMITTED, Для набора символов - NONE, OCTETS, и т.д.

Таблица 7.29. Описание типов данных, кодовых таблиц и последовательностей сравнения Имя столбца Тип и дли- Комментарий на данных Char(31) Имя поля, для которого Rdb$type Smallint Внутренний код, идентифицирующий тип поля:

внутри каждого типа собственная нумерация, синонимичные наименования name) имеют одинаковые коды.

Rdb$type_name Char(31) Текст, соответствующий внутреннему коду Rdb$description BLOB 80 Комментарий пользователя Rdb$system_flag Smallint Определен пользователем - 0, системой больше RDB$USER_PRIVILEGES Содержит сведения о выдачи прав пользователям на основе команд GRANT. Таким образом, таблица может быть использования для восста новления команд выдачи привилегий (GRANT) на использование объек тов базы данных.

Организация хранения метаданных Таблица 7.30. Описание прав пользователей Имя столбца Тип и Комментарий длина данных Rdb$user char Char(31) Имя пользователя, которому выделены привилегии Rdb$grantor Char(31) Имя пользователя, который выдал приви легии Rdb$privilege Char(6) Привилегия: ALL;

SELECT;

DELETE;

INSERT;

UPDATE;

REFERENCE;

MEMBER OF (for roles) Привилегия выдана опции WITH GRANT OPTION -1, нет - Rdb$relation_name Char(31) Определяет таблицу, для которой дана привилегия char Char(31) Для привилегий update - имя поля, для которого дана привилегия Rdb$user_type Smallint Rdb$object_type Smallint Описывает обзоры. Для каждого обзора содержит перечень, исполь зуемых ими таблиц. Собственно текста SQL для обзора не содержит.

Таблица 7.31. Описание обзоров Имя столбца Тип и Комментарий длина данных Rdb$view_name Char(31) Имя обзора Rdb$relation_name Char(31) Имя таблицы, используемой в обзоре.

Комбинация RDB$VIEW_NAME и RDBSRELATIONNAME должна быть уни кальной Rdb$view_context Smallint Код (порядковый номер алиаса), используе мый для имен полей Глава Имя столбца и Комментарий длина данных Char(31) Алиас (текстовая версия в SELECT). Эта переменная должна:

•Соответствовать значению столбца в •Быть уникальной в обзоре 7.3. Системные обзоры Используя приведенный ниже SQL script, можно создать четыре об зора, содержащих информацию об ограничениях логической целостности в базе данных. Предварительно, конечно, должна быть создана сама база данных. Системные SQL-обзоры являются подмножеством системных обзоров, определенных стандартом SQL-92. Поскольку они определены в соответствии с ANSI SQL-92, сами имена системных обзоров и их столб цов не начинаются с RDB$.

ОБЗОР CREATE VIEW ( CHECK_CLAUSE ) AS SELECT FROM RC, RDB$TRIGGERS RT WHERE = Описывает все СНЕСК-ограничения, определенные в базе.

Таблица 7.32. Описание СНЕСК-ограничений, определенных в базе Имя столбца Тип и дли- Описание на данных Constraint_name Char(31) Имя CHECK ограничения (уникальное) Check_clause BLOB 80 Текстовый BLOB. Исходный текст опреде ления триггера (столбец SOURCE в таблице rdb$TRIGGERS) Организация хранения метаданных ОБЗОР CREATE VIEW ( ) AS SELECT FROM RC, RDB$INDEX_SEGMENTS WHERE = Описывает столбцы, используемые в ограничениях PRIMARY KEY и UNIQUE. Для внешних ограничений (FOREIGN KEY) этот обзор описы вает столбцы, определяющие ограничение.

Таблица 7.33. Описание столбцов, используемых в ограничениях PRIMARY KEY и UNIQUE таблиц базы данных Имя столбца Тип и Описание длина данных Table_name - Char(31) Имя таблицы, для которой создано огра ничение Column_name Char(31) Имя столбца, используемого в ограничении Char(31) Уникальное имя ограничения ОБЗОР CREATE VIEW ( DELETE_RULE ) AS Описывает все ссылочные ограничения, определенные в базе.

212 Глава Таблица 7.34. Описание ссылочных ограничений, определенных в базе Имя столбца и Описание длина данных Constraint_name Char(31) Уникальное имя ограничения Unique_constraint_name Char(31) Имя ограничения уникального (UNIQUE) или первичного (PRIMARY KEY) ключа, связанное с указанным списком столбцов Match_option Char(7) Зарезервировано для последующего ис пользования (устанавливается FULL).

Update_rule Char(ll) Зарезервировано для последующего ис пользования (устанавливается RESTRICT) Delete_rule Char Зарезервировано для последующего использования (устанавливается RESTRICT) ОБЗОР CREATE VIEW ( ) AS SELECT RDB$DEFERRABLE, FROM Описывает все ограничения, определенные в базе для таблиц.

Таблица 7.35. Описание ограничений, определенных в базе для таблиц Имя столбца Тип и дли- Описание на данных Constraint_name Char(31) Уникальное имя ограничения Table_name Char(31) Имя таблицы, для которой создано ограничение Организация хранения метаданных Имя столбца Тип и дли- Описание на данных Constraint_type Char(31) Допустимые значения: UNIQUE, PRIMARY KEY, FOREIGN KEY или CHECK Char(3) Зарезервировано для последующего использования (устанавливается No) Initially_deferred Char(3) Зарезервировано для последующего использования (устанавливается No) Если для прикладных целей нужно часто использовать данные сис темных таблиц, то создание собственных обзоров с нужным составом параметров и наименованиями полей является хорошим решением. Такие обзоры хороши также тем, что позволяют защитить данные, собрать их в удобном виде независимо от того в скольких системных таблицах они хранятся. Точно также можно создать и хранимые процедуры.

7.4. Использования описаний данных для прикладных целей Данные, хранимые в системных таблицах, могут быть использованы в приложениях для получения и обработки информации о составе, струк туре и используемых методах контроля и обработки данных в базе, вклю чая и тексты создания объектов на SQL.

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

Рассмотрим решение подобных задач на примерах.

Пример 7. Выведем список таблиц нашей базы с их описаниями select Rdb$description FROM where NOT Like "RDB$%" and is NULL Если воспользоваться пакетом типа работа с которым будет рассмотрена в главе «Инструментальные средства для работы с InterBase», то можно увидеть таблицу следующего вида.

Глава Таблица 7.36. Список таблиц тестовой базы по примеру Список книг (рубрик) Список авторов TPLACE Список места хранения TREADER Список читателей Описание связей авторов и книг Описание связи книга - место Описание связи книга - читатель TABLEARR E_LIST I_LIST Если использовать инструментарий типа WinSQL или IBConsole, то увидеть второй столбец в таком виде не удастся, поскольку в базе это по ле хранится, как BLOB.

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

Пример 7. Помещаем на форму объекты: TQuery, TDBGrid (DataSourcel, 1, DBGridl).

Устанавливаем свойство объекта Forml Caption = "Список таблиц".

Устанавливаем свойство объекта DataSet 1.

Устанавливаем свойство объекта DBGridl DataSource = DataSourcel.

Устанавливаем свойство объекта AutoCalcFields = true.

Устанавливаем свойство объекта DataBase = TESTLIBR (али нашей тестовой базы).

Устанавливаем свойство объекта SQL = «select Rdb$relation_name, Rdb$description FROM where Rdb$relation_name NOT Like and Rdb$view_source is NULL» Организация хранения метаданных Вызываем добавляем в все выбираемые поля, а так же добавляем новое вычисляемое поле DESCRIPTION, как строковое данное длиной байтов.

Выбираем событие OnCalcFields. После двойного «клика» у нас соз дается заголовок обработчика событий Теперь набираем текст обработки события, содержащий текст преоб разования BLOB в символьную строку. При этом в строке нужно убрать коды «возврат каретки» и «перевод строки».

Текст будет иметь вид void fastcall *DataSet) { * tt= *> TStringList;

// Настраиваемся на работу с BLOB TBlobStream *bs = new // Создаем поток для чтения из выбранного BLOB // Записываем данные BLOB в объект TStringList // (список строк) AnsiString SText=TS->Text;

|| // Убираем коды «возврат каретки» и «перевод строки».

// «Записываем» в Query delete bs;

// удаляем поток В ColumnEditor для объекта DBGridl задаем заголовки столбцов «Имя таблицы», «Описание таблицы», удалив предварительно столбец Устанавливаем свойство объекта Active = true и запускаем приложение на выполнение. В режиме проектирования вычисляемые по ля, в данном случае «Описание таблицы», не видны, так как для их за полнения необходимо выполнить записанный нами код.

В результате получим картинку, представленную на рисунке 7.1.

Глава 7.1. Представление данных с BLOB в табличном виде Такой подход удобен, если нужно однократно в какой-либо форме представить данные BLOB. Если же данные BLOB удобно регулярно преобразовывать в символьные строки, то можно написать специальную UDF, выполняющую подобные действия.

Пример 7. Для преобразования BLOB в строку создадим UDF blob_str. Текст ее может быть, например, следующим.

declspec(dllexport) Ы) char long length=100;

char curpos=0;

retstr=(char return retstr;

for(int for(int {t=buffer[i];

t==13) •;

} } Организация хранения метаданных delete!] buffer;

return retstr;

Описание UDF в базе тогда будет:

DECLARE EXTERNAL FUNCTION BLOB RETURNS CSTRING(255) FREE_IT '_blob_str' Пример 7. После создания подобной UDF наша выборка будет выглядеть select Rdb$relation_name, FROM where Rdb$relation_name NOT Like "RDB$%" and Rdb$view_source is NULL Поскольку в выбираемых полях уже нет BLOB, то такая выборка бу дет пригодна как для интерактивных утилит, так и для любых приложе ний. Нужно только помнить, что она обрезает хранимый текст до байт.

Результат такой выборки уже показан в таблице 7.36.

Рассмотрим теперь выборку списка полей из таблицы вместе с их описаниями.

Пример 7. select Rdb$field_position+1 NUMBER, Name, BLOB_STR(Rdb$description) Description FROM where Rdb$relation_name = "TBOOK" Теперь добавим к ним сведения о типе полей, их длине и точности.

select NUMBER, Name, b.Rdb$field_type FieldType, b.Rdb$field_length FieldLength, Rdb$field_scale Scale, BLOB_STR(a.Rdb$description) Description 220 Глава Аналогичным образом непосредственно или с соответствующей об работкой в программе можно получить описание, как для наглядного представления, так и для получения собственно команд SQL, практически всех объектов базы данных.

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

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

Пример 7. CREATE TRIGGER FOR TBOOK ACTIVE BEFORE INSERT POSITION as begin if (new.UNIKEY is NULL) then (new.MATHERKEY is NULL or then BEGIN update SET Rdb$message='He указана рубрика для <' || || where exception END if then if (NOT EXISTS (select * from TBOOK where then exception ERR_RUBRIC;

if (new.BOOKNM is NULL) then exception end В данном примере при недопустимом значении поля MATHERKEY формируется исключение, но с той особенностью, что в текст исключения добавляется наименование книги - поле Для этого сначала изменяется строка таблицы исключений, а затем выдается само исключе ние (уже измененное). Его текст и получит конечный пользователь. Далее выдача исключения вызывает откат транзакции, в результате все измене ния, сделанные транзакцией, следовательно, и изменения в таблице ис ключений будут отменены, а само исключение сохранится в первона чальном виде, то есть как раз то, что нам и нужно.

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

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

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

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

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

Здесь рассматриваются только основные задачи. Мы оставляем в сто роне проблемы, возникающие в крупных системах.

222 Глава 8.1. Установка InterBase IB Database устанавливается запуском setup с дистрибутива. После запуска установки в Windows выводится картинка, содержащая перечень компонент, включенных в дистрибутив, и предлагаемую директорию для установки.

Указываем требуемую директорию, если предлагаемая не устраива ет, и помечаем компоненты, которые хотим включить в установку. Прак тически можно рекомендовать полную установку, учитывая, что зани маемый объем не превышает 30 Мб (вместе с Adobe Acrobat Reader - 36), из них около 20 занимают документация и примеры.

После ответов на вопросы о каталоге установки и устанавливаемых компонентах появляется картинка-заставка процесса установки InterBase.

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

IB Database динамически настраивается на количество дисковой и оперативной памяти или на количество работающих пользователей, поэтому нет необходимости настраивать сервер для получения макси мальной производительности.

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

Установка клиента осуществляется аналогично установке сервера, только задается меньше вопросов и заканчивается быстрее. Для размеще ния клиентской части требуется чуть более 2 Мб дисковой памяти.

Установка на платформах, отличных от Windows / Windows NT, име ет некоторую специфику, что отражено в соответствующей документа ции, но также не займет более минут.

В целом можно сказать, что установка InterBase больше похожа на установку программ в среде DOS, а не Windows NT. Правда, надо ясно понимать, что установить InterBase и научиться эффективно использовать его возможности, это не одно и то же.

Чтобы настроить сервер, запускаем утилиту InterBase Configuration (regcfg.exe) и выбираем желаемые режимы запуска (рис. 8.1).

Настройка и обслуживание базы с помощью диспетчера серверов Настройка базы данных и ее обслуживание, включая резервное ко пирование и восстановление базы данных, осуществляется другой утили Администрирование базы данных той - диспетчером серверов: InterBase Server Manager (ibmgr32.exe).* Его окно представлено на рис. 8.2.

8.1. Задание конфигурации сервера InterBase.

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

Оставаясь в диспетчере серверов, можно выполнить копирование ба зы данных выбором пунктов меню Tasks, Backup. Восстановление базы по копии - выбором пунктов меню Tasks, Restore.

В версии InterBase 6 для реализации этих функций используется утилита интегрирующая ряд утилит предыдущих версий.

224 Глава 8.2. Окно диспетчера серверов.

Изменение периодичности чистки базы (см. гл. 9 о работе с транзак циями) можно выполнить выбором пунктов меню Maintenance, Database Properties. После этого можно явно указать периодичность чистки (Sweep Interval). Значение по умолчанию - 20000. Данная величина уста новлена на основе опытных данных, поэтому менять ее без особых на то оснований не стоит.

Иногда может быть полезным выполнить саму чистку (например, по окончании сеанса работы или просто в конце рабочего дня). Для этого следует выбрать пункты меню Maintenance, Database Sweep.

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

8.2. Создание базы данных Создание базы данных удобнее всего произвести, используя либо WinSQL в InterBase 5, либо утилиту IBConsole в InterBase 6 с переходом в ней в Interactive SQL.

Далее выполняем команду CREATE DATABASE.

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

Для хранения данных на русском языке пригодны два варианта. Рассмот рим преимущества и недостатки каждого из них.

Создание базы данных без кодовой таблицы.

Администрирование базы данных Пример 8. CREATE DATABASE USER "SYSDBA" PASSWORD В этом случае символьные данные хранятся в базе в том виде (DEFAULT CHARACTER SET NONE), как они были загружены, без ка ких-либо преобразований. Сортировка данных осуществляется в порядке возрастания кодов хранимых символов. Например, если столбец таблицы C_FIELD таблицы содержит значения F, f, g, G, Ц, ц, Б, б, то в ре зультате сортировки SELECT C_FIELD FROM ABC ORDER BY C_FIELD получим F, G, g, Б, Ц, б, ц.

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

Для сортировки вне зависимости от регистра можно воспользоваться функцией UPPER.

SELECT C_FIELD FROM ABC, ORDER BY в результате сортировки получим:

F F f F G g G G Б Б Ц Ц ц ц Почти хорошо, но UPPER с кириллицей не работает. К сожалению, этот факт не зависит от используемой кодовой таблицы. Однако проблема эта легко решается с помощью подключения соответствующей UDF.

В приложении приведен текст такой функции на С и ее объявление в базе.

Функция названа RUPPER. Воспользуемся ей.

SELECT C_FIELD FROM ABC, ORDER BY в результате сортировки получим:

F F f F G g G G Б Б Б Ц Ц ц Ц Глава Следует отметить, что функция типа RUPPER нужна не только для сортировки, но и для сравнения данных, например в условиях, если необходимо устранить зависимость результата от регистра.

Создание базы данных с кодовой таблицей Пример 8. CREATE DATABASE USER "SYSDBA" PASSWORD DEFAULT CHARACTER SET WIN1251;

Значение для упорядочения (COLLATE) при этом будет также Сортировка данных осуществляется в порядке возрастания ко дов хранимых символов, если при описании данных (доменов) не указана конструкция COLLATE. Например, если столбец таблицы C_FIELD таб лицы содержит значения F, f, g, G, Ц, ц, Б, б, то в результате сорти ровки SELECT C_FIELD FROM ABC ORDER BY C_FIELD получим F, G, f, g, Б, Ц, б, ц.

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

Рассмотрим соответствующий пример SELECT C_FIELD FROM ABC ORDER BY C_FIELD COLLATE PXW_CYRL в результате сортировки получим: f, F, g, G, б, Б, ц, Ц.

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

Еще раз отметим, что функция UPPER и в этом случае не будет рабо тать для кириллицы, так что от UDF функций типа RUPPER все равно не уйти.

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

Полный синтаксис команды CREATE DATABASE приведен в при ложении.

Администрирование базы данных 8.3. Настройка BDE Назначение BDE и организация связи с ним приложения Проблемы настройки BDE (Borland Database Engine) при работе с InterBase возникают, прежде всего, в системах, работающих с и Delphi. Последние, однако, являются, пожалуй, наиболее распростра ненными средствами для разработки систем, работающих с СУБД, по этому этот вопрос представляется достаточно важным.

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

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

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

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

Рассмотрим подробнее реализацию разработки вторым способом на основе использования средств BDE.

Схема взаимодействия приложения с базой данных приведена рис. 8.3.

Глава | Приложение | | Borland Database Engine IDAPI32.DLL Local SQL | QBE Драйвер InterBase Oracle DAO Paradox SQL Link SQL Link R 8.З. Взаимодействие приложения с базой данных.

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

Итак, рассмотрим задачу настройки описаний базы данных для BDE.

Для идентификации базы данных используется ее символьный иден тификатор - алиас базы данных. Алиас известен приложению и с алиа сом связано описание, используемое BDE.

С каждым алиасом необходимо связать:

• тип базы данных;

• фактическое имя и путь доступа к базе;

• дополнительные характеристики базы, необходимые для настрой ки на работу с ней.

Настройка BDE для работы с базой InterBase (использование BDE Administrator) Наиболее удобным и естественным способом настройки BDE для ра боты с конкретным приложением является использование утилиты BDE Administrator (bdeadmin.exe).

Стартуем BDE Administrator. Получаем окно, показанное на рис. 8.4.

Администрирование базы данных items in Рис. 8.4. Главное окно администратора баз данных.

Выбираем пункт меню Object, подпункт New (то же самое можно сделать и другими способами, но, чтобы не загромождать описание, огра ничимся Получаем окно с заголовком New Database Alias. В нем выбираем из предлагаемого списка драйверов (Database Driver Name) драйвер для InterBase - INTRBASE. Нажимаем Получаем новое окно (рис. 8.5).

8.5. Окно настройки баз данных администратора баз.

Вводим имя для алиаса, в нашем случае - вместо 1. На пример, TESTLIBR. В окне справа вводим в поле SERVER NAME факти ческий путь доступа к базе данных. В поле USER NAME указываем имя 230 Глава пользователя. Нажимаем на голубую стрелку - Apply. Описание базы создано.

Теперь можно открыть базу. Для этого щелкаем мышью на знаке '+' перед именем алиаса. Вводим имя пользователя и пароль. Соединение с базой выполнено. Еще раз выберем пункт меню Object.

Теперь можно перейти к работе с базой, вызвав, например, диспетчер серверов - пункт меню Server Manager или утилиту для работы с базой данных WinSQL для InterBase 5 или IBConsole для InterBase 6, далее пункт меню для работы с ISQL.

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

В процессе работы средства BDE читают или пишут данные из базы.

При этом при необходимости производится перекодирование данных.

Внутри Windows-приложения символьные данные хранятся в теку щей кодировке, для русскоязычных приложений Итак, если мы имеем, например файлы DBF в кодировке DOS 866, то для их штатного прочтения необходимо ее задать. Для этого надо войти в BDE Administrator в подменю Configuration, выбрать Native, DBASE и задать LANGDRIVER dBASE RUS cp866. В этом случае производится перекодирование данных как при чтении, так и при записи, таким обра зом можно «забыть», что на диске данные хранятся в кодировке DOS, а в приложении - в кодировке Windows. Но в данном случае сами файлы не содержат информации об используемой кодовой странице.

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

В InterBase задано CHARACTER SET NONE Здесь возможны 2 случая.

Вариант В BDE не указан LANGDRIVER (поле пусто).

В этом случае перекодировка данных при чтении и записи не произ водится. При работе с InterBase никаких проблем не возникает.

Теперь читаем данные из файла DBASE (LANGDRIVER dBASE RUS cp866) в приложение. Данные перекодируются. Далее из приложения за писываем построчно в InterBase (NONE). Перекодировки не происходит.

Записано все правильно и в нужной нам кодировке.

Теперь проделываем то же самое, но в один прием, используя ло кальный SQL.

Администрирование базы данных Пусть файл FILET.DBF в директории E:\userdos содержит два сим вольных поля: ТХТ1 и ТХТ2.

Создадим в нашей базе таблицу TABL1.

CREATE TABLE ( ТХТ TXT Тогда данные из файла DBASE - FILET.DBF в нашу таблицу можно поместить с помощью средств локального SQL BDE в нашу базу сле дующей командой.

insert into select cast(TXTl as varchar(5)), cast(TXT2 as Промежуточного перекодирования теперь нет, данные попали в базу, но вместо кириллицы появились #.

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

То же можно сказать и о выгрузке данных из базы.

Вариант 2.

В BDE указан LANGDRIVER Pdox ANSI Cyrillic. Это соответствует кодировка При обращении к базе получаем сообщение:

General SQL error.

arithmetic exeption, numeric overflow, or string truncation Cannot transliterate character between character sets.

Проще говоря, этот вариант непригоден. BDE не умеет выполнять перекодировки с NONE.

В InterBase задано CHARACTER SET Здесь возможны 2 случая.

Вариант В BDE не указан LANGDRIVER (поле пусто).

Проведем те же манипуляции, что и раньше.

Чтение из базы прошло, поскольку при чтении перекодировки нет.

Запись идет из NONE в - BDE этого не умеет.

Прямая запись также не прошла. Здесь перекодировки DOS 866 NONE - результат тот же, что и при установке в базе кодовой таблицы NONE. Этот вариант также непригоден.

Вариант 2.

В BDE указан LANGDRIVER Pdox ANSI Cyrillic. Это соответствует кодировка Глава Чтение из базы прошло, поскольку кодовые страницы совместимы.

Записи, как в построчном режиме, так и с помощью SELECT прошли правильно. DOS 866 - Pdox ANSI Cyrillic Возникают ли здесь какие-либо проблемы. Увы, да. Если посмотреть системные таблицы, то можно увидеть, что в них явно указана кодовая таблица character set Для приложений, это не беда, но, если нужно пользоваться утилитой SQL Explorer, то при попытке про смотра списка таблиц базы он выдаст сообщение, которое мы уже видели:

Cannot transliterate character between character sets. Связано это с тем, что для получения этого списка SQL Explorer пытается читать системные таблицы, а они как раз «не в той кодировке». Беда, конечно не так велика, но к ней нужно быть готовым.

Подведем итоги.

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

Первый способ является более простым. При создании базы данных DEFAULT CHARATER SET ни для базы данных, ни для символьных по лей не указывается. В BDE в поле параметра LANGDRIVER задаем зна чение пусто. В этом случае в БД можно записывать символы в любой кодировке.

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

Другой способ предполагает задание при создании БД дополнитель ного параметра DEFAULT CHARACTER SET При работе с использованием BDE необходимо выполнить его на стройку. Удобнее всего воспользоваться утилитой администратора баз данных (bdeadmin.exe), описанной выше. Для этого достаточно на стра ничке System для драйвера INTRBASE (чтобы потом не делать то же са мое каждый раз при создании нового псевдонима) или для псевдонимов INTRBASE установить параметр LANGUAGE DRIVER = Pdox ANSI Cyrillic.

При установке кодировки collation устанавливается умолчанию также в сортировка текстов (так же, как и при пер вом способе) будет выполняться по возрастанию кодов символов. Для обеспечения сортировки независимо от регистра необходимо при описа нии доменов (полей таблиц) или непосредственно в конструкции коман ды SELECT после имени поля в ORDER BY указать collate PXW_CYRL.

Рассмотрим результаты сортировок на примерах.

Администрирование базы данных Пример 8. CREATE TABLE TAUTH0R1 ( AUTHOR VARCHAR(60) COLLATE PXW_CYRL, COMMENT Зададим следующие значения.

Таблица. 8.1. Содержимое таблицы для примера 8. AUTHOR AUNAME COMMENT 19 Дашкова Полина Первый 20 Иоанна второй 21 Ладыжинская Ольга Александровна Третий четвертый 22 Бурова И.И.

24 без авторов Пятый Применим команду:

Пример 8. select * from tauthor order by AUNAME;

Результат представлен в табл. 8.2.

Таблица 8.2. Результат выборки с сортировкой при наличии опции COLLATE AUTHOR AUNAME COMMENT 24 без авторов Пятый 22 Бурова И.И. четвертый 19 Дашкова Полина Первый Ладыжинская Ольга Александровна Третий Хмелевская Иоанна Второй 234 Глава Сортировка выполнена по 2 столбцу, причем регистр текста не учи тывается.

Теперь выполним такую же операцию, но по третьему столбцу, по которому COLLATE не задана.

Пример 8. select * from order by COMMENT;

Таблица 8.З. Результат выборки с сортировкой при отсутствии опции COLLATE AUTHOR AUNAME COMMENT 19 Дашкова Полина Первый 24 без авторов Пятый 21 Ладыжинская Ольга Александровна Третий 20 Иоанна второй 22 Бурова И.И. четвертый Здесь также выполнена сортировка, но уже только по возрастанию кодов символов, а это означает, что вначале идут прописные буквы, а уже потом строчные.

Чтобы провести сортировку, аналогичную первой, достаточно сде лать следующее.

Пример 8. select * from tauthor order by COMMENT COLLATE Таблица 8.4. Результат выборки с сортировкой с опцией COLLATE в запросе AUTHOR AUNAME COMMENT 20 Хмелевская Иоанна Второй 19 Дашкова Полина Первый 24 без авторов Пятый 21 Ладыжинская Ольга Александровна Третий 22 Бурова И.И. четвертый Администрирование базы данных В списке кодировок Borland InterBase есть еще одна русскоязычная CYRL (866), соответствующая кодировке в DOS, однако ее лучше не ис пользовать, поскольку это немедленно приведет либо к проблеме со шрифтами в приложении, либо к необходимости в постоянной перекоди ровке данных. Тем более что какой-либо необходимости в этом не видно, разве что при использовании старых баз, созданных в DOS. Но и в этом случае проще перекодировать их при перемещении в InterBase.

Следует, правда, отметить, что собственно утилиты BDE не всегда корректно ведут себя с упомянутыми кодировками, особенно, если необ ходимо одновременно работать с базами InterBase и локальными табли цами Paradox или dBASE. В этом смысле работа без явного указания CHARACTER SET предпочтительнее. На сегодняшний день здесь не воз никает никаких проблем.

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

Для этого формируется список пользователей и каждому пользовате лю предоставляются права на доступ к определенным данным.

Управление доступом к данным включает, прежде всего, управление списком пользователей и правами их доступа к данным и процедурам.

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

Для регулирования доступа таких групп в InterBase предусмотрен механизм «ролей».

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

Создание списка пользователей Рассмотрим выполнение этой работы в среде Windows. Для создания списка пользователей можно воспользоваться диспетчером серверов InterBase Server Manager (ibmgr32.exe) при работе с InterBase версий 4 и 5, либо IBConsole.exe для версий 6.

В первом случае стартуем диспетчер серверов.

Глава Соединяемся с конкретной базой. Выбираем пункт меню File и внут ри него пункт Server Login. Вводим пароль. Если данные введены пра вильно, то происходит соединение с базой. Для обеспечения работы по созданию пользователей необходимо иметь права администратора базы данных. При первом соединении: пользователь - SYSDBA, пароль masterkey.

Далее выбираем пункт меню Tasks и внутри него пункт User Security. Добавляем нового пользователя, выбрав Add User. Указываем имя пользователя (User Name), используемое для его идентификации, и пароль. При желании можно задать дополнительные данные о пользо вателе: фамилию, имя.

Во втором случае стартуем IBConsole.

Входим в режим регистрации сервера. Аналогично первому случаю вводим имя пользователя и пароль.

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

Пользователь создан. При необходимости данные пользователя мож но модифицировать или удалить. Единственное, что не рекомендуется, это удаление пользователя SYSDBA. Последнее связано с необходимо стью переустановки InterBase для восстановления базы поддержания сек ретности isc4.gdb.

Задание прав. Команда GRANT Создание пользователя само по себе не дает ему никаких прав на доступ к объектам базы данных.

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

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

Для доступа к таблице или обзору пользователь или объект нуждает ся в правах на SELECT, INSERT, UPDATE, DELETE или REFERENCES.

Все права могут быть даны опцией ALL.

Для вызова процедуры в приложении пользователь должен иметь права на EXECUTE.

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

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

Перечень прав приведен в табл. 8.5.

Таблица 8.5. Перечень прав Право Позволяет пользователям ALL SELECT, DELETE, INSERT, UPDATE, и REFERENCES (последнее только для версий позже 4) SELECT Дает право выбирать строки из таблицы или представления DELETE Дает право удалять строки из таблицы или представления INSERT Дает право добавлять строки в таблицу или представления UPDATE Дает право изменять строки в таблице или представлении.

Может быть ограничено только определенным набором столбцов REFERENCES Дает право ссылаться при работе с внешним ключом на специфицированные столбцы;

как минимум это должны быть все столбцы первичного ключа EXECUTE Выполнять хранимую процедуру Права могут быть ликвидированы пользователем, выдавшим их, че рез команду REVOKE. Если права были выданы с помощью ALL, то и ликвидированы они могут быть только в режиме ALL, если права были выданы с помощью PUBLIC, то и ликвидированы они могут быть только в режиме PUBLIC.

Синтаксис:

] / ON ] / TO / / GROUP /EXECUTE ON PROCEDURE procname TO / GRANT OPTION./} TO {PUBLIC / LIST_ } ;

Глава SELECT / DELETE / INSERT / UPDATE ] REFERENCES [ ] PROCEDURE TRIGGER VIEW / PUBLIC rolename :;

= username Таблица 8.6. Описание синтаксических элементов команды GRANT Аргумент Описание privilege Имя предоставленного права. Допустимые значения:

SELECT, DELETE, INSERT, UPDATE, REFERENCES Col Имя столбца, на который выдаются права.

Tablename Имя существующей таблицы, на которую распростра няются права Viewname Имя существующего обзора, на который распространя ются права Имя существующего объекта базы (процедуры, обзора, триггера), на который распространяются права username Имя пользователя, которому передаются права WITH GRANT Передает права на передачу прав пользователям, пере OPTION численным в списке rolename Имя существующей роли, созданной командой CREATE ROLE Пользователь, которому передаются права роли. Список пользователей должен быть задан в isc4.gdb (создан, например утилитой IBConsole) GROUP unix_group Имя группы в UNIX, заданной в /etc/group Администрирование базы данных Следующая команда передает права пользователю на SELECT и DELETE. Опция WITH GRANT OPTION дает права на их дальнейшую передачу.

Пример 8. GRANT SELECT, DELETE ON TBOOK WITH GRANT OPTION;

А эта команда дает право на выполнение процедуры другой проце дуре и пользователю.

Пример 8. GRANT EXECUTE ON PROCEDURE PAUTHOR PROCEDURE PBOOKAUTHOR, MISHA;

В данном случае передача прав процедуре PBOOKAUTHOR в нашей базе бессмысленна, поскольку она просто не использует процедуру PAUTHOR, но синтаксически она вполне корректна.

Следующая команда по содержанию полностью аналогична примеру 8.5., но ориентирована на использование внедренного SQL.

Пример 8. EXEC SQL GRANT SELECT, DELETE ON TBOOK TO MISHA WITH GRANT OPTION;

Ликвидация прав. Команда REVOKE REVOKE ликвидирует права доступа к объектам базы данных. Права это действия с объектом, которые разрешены пользователю. SQL-права описаны в табл. 8.7.

Таблица 8.7. Перечень прав Право Запрещает пользователям ALL SELECT, DELETE, INSERT, UPDATE и EXECUTE SELECT Выбирать строки из таблицы или представления DELETE Удалять строки из таблицы или представления INSERT Вставлять строки в таблицу или представления UPDATE Изменять строки в таблице или представлении. Может быть задано для определенного набора столбцов EXECUTE Выполнять хранимую процедуру 240 Глава Право Запрещает пользователям GRANT Делегирование прав другим пользователям OPTION FOR Отметим некоторые ограничения при использовании команды REVOKE. Ликвидировать права может только тот пользователь, кто их выдал. Одному пользователю могут быть переданы одни и те же права на объект базы данных от любого числа разных пользователей. Команда REVOKE влечет за собой лишение выданных ранее именно этим вателем прав. Права, выданные всем пользователям опцией PUBLIC, мо гут быть ликвидированы командой REVOKE только с опцией PUBLIC.

Синтаксис:

REVOKE [GRANT OPTION FOR./ ON J FROM { / EXECUTE ON PROCEDURE FROM / ;

: = SELECT / DELETE / INSERT / ] REFERENCES [ ] PROCEDURE procname / TRIGGER / VIEW viewname / username / PUBLIC : ;

= /"USER7 username Таблица 8.8. Описание синтаксических элементов команды REVOKE Аргумент Описание GRANT OPTION Отменяет у перечисленных пользователей права на FOR вание прав на объекты базы данных. Неприменим по отно шению к объектам базы данных Имя столбца, на который выдаются права Администрирование базы данных Аргумент Описание Имя существующей таблицы, на которую распространя ются права Имя существующего представления, на которое распро страняются права Имя существующего объекта базы, на который распро страняются права Пользователь, у которого ликвидируются права Следующая команда ликвидирует у пользователя права на удаление из таблицы (см. пример 8.5, в этом случае права на чтение у него остают ся).

Пример 8. REVOKE DELETE ON ТВООК FROM MISHA;

А эта команда отменяет право на выполнение процедуры другой процедуре и пользователю (см. выделение соответствующих прав в при мере 8.6) Пример 8. REVOKE EXECUTE ON PROCEDURE PAUTHOR FROM PROCEDURE PBOOKAUTHOR, MISHA;

Создание группы управления правами - роли.

Прежде всего, разберемся с понятием роли. Рассмотрим некоторое множество команд предоставления прав (GRANT) и дадим ему имя.

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

Процедура работы с ролями включает несколько этапов.

• Создание роли, то есть объявление ее в базе (создание имени и пустого множества).

Глава • Формирование списка прав, связанных с ролью (включение эле ментов - прав в множество).

• Формирование прав пользователей на основе ролей • Связывание пользователей с ролями, то есть передача им множе ства прав, описанных в роли.

Команды CREATE ROLE, DROP ROLE Команда CREATE ROLE реализует первый этап действий при рабо те с ролями: создает (объявляет) роль в базе данных.

Синтаксис:

CREATE ROLE rolename;

Таблица 8.9. Опции команды CREATE ROLE Параметр Описание Rolename Имя роли;

должно быть уникальным среди функциональных имен в базе данных Пример 8. Следующая команда создает роль, называемую "bibrole".

CREATE ROLE bibrole;

Команда DROP ROLE выполняет действия, обратные CREATE ROLE - удаляет роль из базы данных.

Синтаксис:

DROP ROLE rolename;

Таблица 8.10. Опции команды DROP ROLE Параметр Описание Rolename Имя существующей роли, которая удаляется из базы данных Роль может быть удалена либо ее создателем, либо пользователем SYSDBA, либо другим пользователем с аналогичными правами.

Администрирование базы данных Пример 8. Следующая команда удаляет роль, называемую " bibrole ".

DROP ROLE bibrole;

Формирование списка прав, связанных с ролью Ролям, созданным командой CREATE ROLE, могут быть предостав лены права так же, как и пользователям.

Предоставление прав ролям осуществляется командой GRANT. Об щий синтаксис команды GRANT уже приводился. Тем не менее, приве дем его еще раз применительно к предоставлению прав ролям.

GRANT / ON ] / TO /EXECUTE ON PROCEDURE procname TO / SELECT / DELETE / INSERT / UPDATE ] REFERENCES [ (LIST_col) ] / / Отметим, что одной командой GRANT права могут предоставляться и ролям и пользователям.

Таблица Описание синтаксических элементов команды GRANT для ролей Аргумент Описание privilege Имя предоставленного права. Допустимые значения:

SELECT, DELETE, INSERT, UPDATE, REFERENCES Col Имя столбца, на который выдаются права.

Tablename Имя существующей таблицы, на которую распростра няются права Глава Аргумент Описание Имя существующего обзора, на который распространя ются права Имя пользователя, которому передаются права WITH GRANT Передает права на передачу прав пользователям, пере OPTION численным в списке Имя существующей роли, созданной командой CREATE ROLE Рассмотрим пример предоставления прав (привилегий) роли "bibrole" (см. примеры 8.6 и 8.10) на выполнение процедуры Пример 8. CREATE ROLE bibrole;

GRANT EXECUTE ON PROCEDURE PAUTHOR TO bibrole;

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

GRANT / /WITH ADMIN } ;

username Таблица 8.11. Описание синтаксических элементов команды GRANT для передачи прав ролей пользователям Аргумент Описание username Имя пользователя, которому передаются права rolename Имя существующей роли, созданной командой CREATE ROLE Администрирование базы данных Рассмотрим передачу пользователям прав, присвоенных ролям.

Пример 8. GRANT bibrole Связывание пользователей с ролями В InterBase с пользователем во время его сеанса работы с базой мо жет быть связана только одна роль. В то же время команд GRANT на пе редача прав от ролей пользователю может быть несколько.

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

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

Реализация такой связи осуществляется командой CONNECT.

Базовый синтаксис команды CONNECT для нашего случая выглядит сле дующим образом:

CONNECT USER PASSWORD 'password' ROLE ' rol e name ' ;

Таким образом, один и тот же пользователь при входе в систему мо жет получать различные наборы прав.

Пример 8. CONNECT USER 'MISHA' PASSWORD ' 12345' ROLE ' b i b r o l e ' ;

MISHA получил права на процедуру PATHOR CONNECT USER 'MISHA' PASSWORD '12345';

MISHA не получил права на процедуру PATHOR 246 Глава 8.5. Копирование и восстановление базы данных Регулярное выполнение операций копирования базы предназначено, прежде всего, для обеспечения возможности восстановления данных по сле сбоев. Учитывая, что база данных InterBase физически организована в виде одного файла (при наличии файлов тени - нескольких файлов), проблем с копированием базы нет. Единственно, о чем следует помнить, так это о том, что при проведении копирования внешними программами все пользователи должны быть отключены от базы.

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

Использование резервной копии InterBase и особенности восстанов ления утилитой gbak или диспетчером серверов (Server Manager в InterBase 4-5 или IBConsole в InterBase 6) дают ряд преимуществ. При резервном копировании и восстановлении помимо собственно копирова ния выполняется также ряд дополнительных действий, а именно:

• Выполняется сборка "мусора" (удаляются устаревшие версии за писей) и чистка таблицы транзакций от транзакций, завершенных откатом (rollback).

• Балансируются индексы.

• Освобождается пространство, занимаемое удаленными записями, и упаковываются оставшиеся данные.

Это позволяет несколько уменьшить размер базы данных и ускорить работу с данными.

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

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

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

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

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

1. Перед установкой новой версии InterBase скопировать базы дан ных, использующие старую версию утилит копирования.

2. Установить новую версию сервера InterBase.

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

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

• Копирование можно выполнить диспетчером серверов (Server Manager) или IBConsole в зависимости от используемой версии.

Для этого используются пункты меню Tasks - Backup. Далее вы бираются нужные режимы копирования.

• Для восстановления используются пункты меню Tasks - Restore.

Далее выбираются нужные режимы копирования.

• Можно также использовать утилиту командной строки хотя при работе в среде Windows это весьма неудобно.

Синтаксис утилиты для копирования имеет следующий вид:

gbak [-B] [options] database target Синтаксис утилиты для восстановления имеет следующий вид.

gbak [options] source database же, но для баз с несколькими файлами gbak source primary secon dary2 [n2]] 248 Глава Таблица 8.11. Описание синтаксических элементов командной строки GBAK Параметр Описание Database Имя копируемой или восстанавливаемой базы данных Source Имя запоминающего устройства или файла с резервной копи ей. В UNIX это может также быть stdin, когда gbak читает со стандартного ввода Target Имя запоминающего устройства или файла с резервной копи ей. В UNIX это может также быть stdout, когда gbak пишет в стандартный файл вывода Primary Первичный файл при восстановлении с множественными фай лами базы данных M Длина первичного файла в страницах базы данных;

минималь ное значение - secondary 1 Первый вторичный файл при восстановлении с множествен ными файлами базы данных Длина 1. Если используется только один вторичный файл, то необязателен secondary2 Следующий вторичный файл, если задано несколько вторич ных файлов n2 Длина secondary2. Длину последнего вторичного файла опре делять не нужно Опции gbak при копировании приведены в следующей таблице.

Таблица 8.12. Описание опций утилиты при копировании Опция Описание -b[ackup_database] Копирует базу данных vert] Конвертирует внешние файлы как внутренние табли цы -e[xpand] Не создает сжатой копии -fa[ctor] n Использует блокирующий коэффициент п для вывода -g[arbage_collect] Не "собирает мусор" при копировании Администрирование базы данных Опция Описание Игнорирует контрольные суммы при копировании Игнорирует транзакции в «неопределенном состоя нии» при копировании Копирует только метаданные -nt Создает копию в непереносимом формате Копирует метаданных в формате старого стиля -pa[ssword] text Проверяет текст пароля перед доступом к базе данных -role name Соединяется с указанием роли Создает копию в переносимом формате (значение по умолчанию) -u[ser] name Проверяет имя пользователя перед доступом к уда ленной базе данных Показывает действия -y [file | sup- Подавляет сообщения вывода press_output] -z Показывает версию gbak и InterBase Опции gbak при восстановлении приведены в следующей таблице.

Таблица Описание опций утилиты GBAK при восстановлении Опция Описание -c[reate_database] Восстанавливает базу данных как новый файл Размер кэша для восстановленной базы данных Делает индексы неактивными после восстановления Не создает никаких ранее определенных теней -n[o_validity] Удаляет ограничения целостности из восстановлен ных метаданных;

позволяет восстановить данные, которые иначе вызвали бы нарушение ограничений -o[ne_at_a_time] Восстанавливает по одной таблице;

полезно для час тичного восстановления, если база содержит повреж денные данные Глава Опция Описание -p[age_size] n Устанавливает размер страницы к п байтам 2048, или значение по умолчанию - -pa[ssword] text Проверяет текст пароля перед доступом к базе дан ных -r[eplace_database] Восстанавливает базу данных как новый файл или заменяет существующей файл Проверяет имя пользователя перед доступом к уда ленной базе данных;

требуется при использовании с клиентской машины -use_[all_space] Восстанавливает базу данных со % заполнением на каждой странице данных, вместо значения по умолчанию (коэффициент заполнения 80 %) Показывает действия gbak -y [file | Подавляют сообщения вывода -z Показывает версию gbak и InterBase Кроме того, следует отметить, что для выполнения сервисных функ ций с базами данных можно использовать также утилиты третьих фирм, которые в ряде случаев заметно проще и удобнее в работе (см. гл.

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

Глава Транзакции. Механизм транзакций в InterBase 9.1. Понятие транзакции. Назначение транзакций Транзакции и поддержание логической целостности данных Прежде всего, определимся с понятием транзакции (transaction). При внесении изменений в базу данных возникает ряд проблем, даже если с базой работает только один пользователь. Данные одного документа могут в базе храниться в различных таблицах, кроме того, они могут ис пользовать другие данные, логически связанные с ними. Если обработка документа будет по тем или иным причинам прервана, то это может при вести не только к неполноте данных, но и к нарушению их логической целостности. Например, агрегированные данные могут разойтись с ис ходными данными, на основе которых они были получены. При обработ ке множества строк таблицы возможна ситуация, когда часть строк обра ботана, а другая нет, например изменение размера пенсий для определен ной группы. Простой повтор таких операций невозможен, поскольку неизвестно в какие именно строки были внесены изменения, а какие из менены не были. Другими словами неполный ввод (модификация или Удаление) логически связанных групп данных чреват большими трудно стями по восстановлению целостности и непротиворечивости информа ции. Для решения этой проблемы и предусматривается использования Механизмов управления транзакциями.

Глава Транзакция - это группа операций с базой данных, выполняемых как единое целое. Запись данных в базу производится только при успешном выполнении всех операций группы. Если хотя бы одна из операций груп пы завершается неуспешно, то база данных возвращается к тому состоя нию, в котором она бьша до выполнения первой операции группы (произ водится откат всех изменений). Таким образом, после устранения причи ны неудачного выполнения групповой операции с базой ее можно просто повторить. То есть механизм транзакций позволяет обеспечить логиче скую целостность данных в базе. Другими словами, транзакции - это ло гические единицы работы, после выполнения которых база данных оста ется в целостном состоянии. Транзакции также являются единицами вос становления данных. После сбоев - восстанавливаясь, система ликвидирует следы транзакций, не успевших успешно завершиться в ре зультате программного или аппаратного сбоя. Эти два свойства транзак ций определяют атомарность (неделимость) транзакции.

Логическая целостность базы включает два уровня: формальную це лостность и семантическую (смысловую) целостность.

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

• ограничения первичных ключей (PRIMARY KEY);

• ограничения уникальных ключей (UNIQUE KEY);

• ограничения внешних ключей (FOREIGN KEY);

• ограничения, задаваемые конструкциями CHECK;

• ограничения, задаваемые используемыми триггерами.

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

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

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

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

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

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

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

Рассмотрим сначала возможные конфликты доступа к данным:

• Первая транзакция изменила объект и не закончилась. Вторая транзакция пытается изменить этот объект.

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

• (Чтение-Запись). Первая транзакция прочитала объект и не закончилась. Вторая транзакция пытается изменить этот объект.

Результат - данные, полученные первой транзакцией, не соответ ствуют хранимым в базе. При повторном чтении они могут ока заться другими. Расчеты, сделанные на их основе, могут оказаться неверными. Сами данные в базе при этом остаются согласованны ми. В качестве примера рассмотрим следующую ситуацию. Пер вый пользователь (транзакция 1) считал из базы данных какие либо данные, например свободные места на авиарейс. Пока он смотрит эти данные, второй пользователь (транзакция 2) может их изменить и зафиксировать изменения (транзакция 2 уже закончи лась, а транзакция 1 еще думает). Например, продать билет на этот рейс. В этом случае первый пользователь видит несуществующие данные. Чтобы полностью исключить подобные ситуации, нужно блокировать доступ к данным, если они были запрошены каким 254 Глава либо пользователем даже только для чтения, но такая блокировка может сильно тормозить работу системы.

• W-R Первая транзакция изменила объект и не закончилась. Вторая транзакция пытается прочитать этот объект. Результат - чтение неподтвержденных данных. В случае отката первой транзакции, это означает, что были прочитаны данные, которых в базе вообще никогда не было.

Конфликты типа R-R (Чтение-Чтение) возникнуть не могут, по скольку данные при чтении не меняются.

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

Отметим, что в случае успешности всех операций транзакции изме нения фиксируются (commit, committed) в базе, в противном случае они отменяются (rollback, rolled back) и база "откатывается" к состоянию, в котором она была перед началом транзакции.

Стандартом ANSI SQL-92 предусматривается 4 стандартных уровня изолированности транзакций:

• Dirty Read - "грязное" (или "незафиксированное") чтение. Тран закция может читать не подтвержденные изменения, сделанные в других транзакциях. Например, если транзакции А и В стартова ли, и поменяли записи, то они обе видят изменения друг друга.

InterBase не поддерживает уровень изоляции транзакций Dirty Read.

• Read Committed - невоспроизводимое (или неповторяемое) чте ние. Транзакция может читать только те изменения, которые были подтверждены другими транзакциями. Например, если транзакции А и В стартовали и поменяли записи, то они не видят изменения друг друга. Транзакция А увидит изменения транзакции В только тогда, когда транзакция В завершится commit. Повторное чте ние данных транзакцией А при этом приведет к тому, что она уви дит, вообще говоря, уже другие данные. InterBase полностью поддерживает уровень изоляции транзакций Read Committed.

• Repeatable Read - воспроизводимое (или повторяемое) чтение.

Транзакция видит только те данные, которые существовали на момент ее старта. При повторном чтении будут видны те же самые данные, хотя они могли за это время и измениться. Уровень изо ляции Repeatable Read в чистом виде не поддерживается InterBase.

Транзакции. Механизм транзакций в InterBase Вместо него InterBase поддерживает уровень SNAPSHOT (сни мок), который хотя и близок к Repeatable Read, но несколько "сильнее". Последнее связано с тем, что InterBase использует "вер сии" данных, а не их блокировку, действительно гарантируя по вторное считывание тех же самых данных.

• Serialized - Транзакции выполняются так, как будто никаких других транзакций в этот момент не существу ет. Или, другими словами, транзакции выполняются так, как будто они выполняются последовательно.

Каждый из уровней изоляции имеет свои достоинства и недостатки.

Dirty Read позволяет оперативно отслеживать все изменения в базе, но это всегда "предварительные результаты" и надо быть готовым к их от мене. Кроме того, при просмотре данных из нескольких таблиц нельзя быть уверенным в согласованности данных (логическая целостность обеспечивается только по завершении транзакции).

Следующий уровень изоляции Read Committed гарантирует согласо ванность всех данных, но не может гарантировать их актуальности, дан ные могли быть уже изменены, но соответствующая операция еще не бы ла подтверждена (Committed). Для получения обновленных данных необ ходимо выполнять операции повторного чтения. Неповторяемость в общем случае результатов чтения может рассматриваться и как досто инство и как недостаток. Кроме того, при сложной выборке возможно получение и просто неверных данных. Рассмотрим это на примере.

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

Таблица 9.1. Конфликт между конкурирующими транзакциями, невер ная сумма Этап работы по времени Первая транзакция Вторая транзакция Старт Подсчет запаса на первом складе (300 единиц) Старт Подсчет запаса на втором складе (200 единиц) 256 Глава Этап работы по времени Первая транзакция Вторая транзакция 5 Первый этап перемеще ния с первого склада на пятый. Уменьшение запаса на первом на единиц 6 Подсчет запаса на третьем складе (50 единиц) 7 Второй этап перемеще ния с первого склада на пятый. Увеличение за паса на пятом на единиц (180+50=230) 8 Подсчет запаса на четвертом складе единиц) 9 - Завершение транзакции 10 Подсчет запаса на пятом складе (230 единиц) 11 Завершение транзак- ции В итоге первая транзакция насчитала 300 + 200 + 50 + 150 + 230 = = 930. На самом же деле, общий запас составляет 880, причем все опера ции суммирования проводились с данными, которые были подтверждены.

Уровень изоляции Read жестко связан с состоянием базы на момент своего старта. Это обеспечивает возможность почти всегда при повторном чтении видеть те же самые данные. В системах с блокировкой данных это достигается запретом изменения данных, прочитанных тран закцией. В то же время такая блокировка не гарантирует от появления "фантомных данных". Пусть первая транзакция читает из таблицы дан ные, удовлетворяющие некоторому условию р. Другая транзакция после этого уже не может менять данные, удовлетворяющие условию р, однако, она может работать с другими данными. В результате она вносит в свои данные изменения, после которых они уже удовлетворят условию Транзакция, внесшая изменения, успешно завершается, изменения сохра нены в базе. После этого первая транзакция вновь читает свои данные и ожидает, что они будут теми же. Но не тут-то было. В результате Транзакции. Механизм транзакций в InterBase | она получит и «добавок» в виде данных, внесенных второй транзакци ей. В системах с хранением версий данных, к которым относится InterBase, такого рода фантомов не будет, но и уровень изоляции называется иначе - SNAPSHOT (снимок). Данный уровень гарантирует полную со гласованность всех полученных данных, но не может гарантировать их "свежести". Часть данных может оказаться устаревшей, все данные были | актуальными на момент старта транзакции.

Выбор конкретного уровня изоляции зависит от задач, решаемых | транзакцией.

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

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

При обновлении (update) строки таблицы InterBase сохраняет сначала старое значение строки, а точнее (для экономии объема хранимых дан ных), разницу между новой и старой строками. Копия сохраняется, если это возможно, на той же странице, что и основные данные, обеспечивая минимизацию времени доступа к сохраненной версии. Затем InterBase заменяет исходную строку новой версией и создает указатель на старую версию (копию). В главную версию строки записывается идентификатор создавшей ее транзакции. Вообще, любая строка таблицы содержит иден тификатор создавшей ее транзакции: при создании новой строки в нее помимо самих данных помещается идентификатор создавшей ее транзакции.

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

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

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

Чтобы правильно работать с версиями, необходимо располагать ин формацией о текущем состоянии транзакций. InterBase хранит сведения о текущем состоянии транзакций на специальных страницах базы данных Transaction Inventory Page (TIP). Транзакция вне зависимости от ее уровня изоляции может находиться в одном из четырех состояний: active, committed, rolled back или in limbo. Текущее состояние транзакции всегда отражается в глобальной TIP. Помимо глобальной TIP существуют также и локальные TIP, используемые транзакциями уровня SNAPSHOT, отра жающие состояние TIP на момент их старта.

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

Работа с версиями данных в InterBase В предыдущем разделе мы говорили о механизме создания версий.

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

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

Пусть какая-либо транзакция успешно завершилась {commit). Можно ли удалить после этого версии строк таблиц, предшествующих зафикси рованному транзакцией состоянию? Ответ будет отрицательным, по скольку SNAPSHOT-транзакции, стартовавшие до завершения данной транзакции, должны использовать именно их. Старые версии, конечно, должны быть удалены, поскольку замусоривают базу, но сделать это можно только тогда, когда будет точно известно, что более они никому не нужны.

Если какая-либо транзакция завершилась аварийно {rollback), то можно ли удалить версии строк таблиц, созданных данной транзакцией?

Да, можно. Пока она была активна, никто не мог использовать ее версии, а теперь они вообще не нужны. Нужно ли выполнять откат немедленно?

Наверное, нет. Процедура эта довольно громоздка, а мусор в базе все рав но сохраняется, и его сборка должна проводиться, так что целесообразнее поручить это процедуре сборки мусора, чем строить еще одну процедуру, что на самом деле и реализовано в InterBase.

В какой же момент можно установить, какие версии потеряли акту альность. Рассмотрим эту проблему подробнее.

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

Транзакция читает данные. Рассмотрим ее действия при чтении в за висимости от того, какой транзакцией была создана считанная строка (за пись), успешно ли завершилась создавшая ее транзакция и какие версии имеет считанная запись.

• Запись создана транзакцией, завершенной rollback (это прове ряется TIP). Удаляем строку и записываем на ее место предше ствующую версию. Здесь мы выполняем часть действий по откату транзакции, причем никакой поиск нам не нужен, а значит, дейст вие может быть выполнено очень быстро. После этого вновь по вторяем анализ состояния версий строки.

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

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

• Для транзакций с уровнем изоляции SNAPSHOT можно читать только записи, существовавшие на момент старта транзакции.

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

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

Активная транзакция. Транзакция, которая стартовала и не была завершена commit - фиксация или rollback - отмена).

Заинтересованная транзакция. Транзакция, которая не была за вершена фиксацией commit).

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

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

Чтобы следить за состоянием версий в базе данных, сведения о те кущем состоянии транзакций в TIP должны содержать объединение мно жества заинтересованных транзакций и множества актуальных транзак ций. Особую роль в этих множествах играют граничные транзакции.

Старейшая активная транзакция. Это такая активная транзакция, которая стартовала раньше всех других, или, что то же самое, активная транзакция с наименьшим номером.

Старейшая заинтересованная транзакция. Это такая заинтересо ванная транзакция, которая стартовала раньше всех других, или, что то же самое, заинтересованная транзакция с наименьшим номером.

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

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

Старейшая заинтересованная транзакция - это либо старейшая ак тивная транзакция, либо старейшая из отмененных транзакций (rollback).

При старте каждой транзакции N фиксируется транзакция, которая является на момент ее старта старейшей активной f(N), а для транзакций с уровнем изоляции SNAPSHOT - полный список активных транзакций на момент ее старта. Это необходимо для того, чтобы определить, версиями каких транзакций можно пользоваться. При этом версии более старых транзакций для данной заведомо не нужны. Пусть - старейшая ак Транзакции. Механизм транзакций в InterBase тивная транзакция на момент времени t. Тогда можно утверждать, что версии транзакций, более старых, чем не нужны ни для од ной транзакции, а значит, могут быть удалены. Транзакция и будет старейшей актуальной. Можно сказать, что старейшая актуальная тран закция на заданный момент времени - это транзакция, которая была ста рейшей активной на момент старта старейшей активной на данный мо мент времени транзакции.

Теперь рассмотрим порядок обновления данных.

Прежде всего, как уже отмечалось выше, нельзя обновлять версию незавершенной транзакции (конфликт W-W, или Запись-Запись). Но это не все. Транзакция не может обновить версию другой, даже завершенной транзакции, если она стартовала раньше ее, поскольку она при обновле нии базируется на более старых данных. Это, естественно, относится только к транзакциям уровня SNAPSHOT. Транзакции уровня READ видят самые свежие версии незавершенных транзакций.

Проиллюстрируем все вышесказанное на Таблица 9.2. Пример работы с версиями данных в InterBase Старейшая Событие Комментарий Транзакция N N N n=f(N)=N f(N)=N стартует Транзакция N N N N Это простая вставка. Сервер находит создает запись страницу с достаточным местом для хранения записи и ее заголовка и по мещает на ней запись, маркируя ее идентификатором транзакции N (TID) Транзакция N N N f(N+l)=N N+1 стартует Транзакция N N+1 N+1 n=f(N+l)= завершается N commit Приведенный пример базируется на материале опубликованной в статьи Ann Harrison «Как работает данных» с комментариями Д. См.

ib.demo.ru.

сованная активная заинтере актуальная 262 Глава Старейшая Событие Комментарий Транзакция N+1 N+1 N f(N+2)=N+l N+2 стартует Транзакция N+1 N+1 N f(N+3)=N+l N+3 стартует Транзакция N+1 N+1 N Это простая вставка. Создается запись N+2 создает и маркируется идентификатором тран запись закции N+2 (TID) Транзакция N+1 N+1 N Транзакция N+3 создает копию суще N+3 модифи- ствующей записи, то есть вычисляет цирует запись, разницу для воспроизведения версии, созданную созданной транзакцией N, помечает транзакцией N обратную версию записи номером транзакции N и записывает ее на сво бодное место. Затем заменяет исход ную запись, сохраненную транзакцией N (и маркированную идентификатором новой версией записи, маркирован ной идентификатором транзакции N+3.

Pages:     | 1 | 2 || 4 | 5 |   ...   | 6 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.