×
Traktatov.net » Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil » Читать онлайн
Страница 254 из 302 Настройки

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

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

* Table (таблица);

* View (представление);

* Trigger (триггер);

* Computed_field (вычисляемое поле);

* Validation (проверка);

* Procedure (процедура);

* Epression_index (вычисляемый индекс);

* Exception (исключение);

* User (польюватель),

* Field (поле);

* Index (индекс);

* Usei-Defined Function (UDF) - функция, определяемая пользователем.

Пока, может быть, не совсем очевидно назначение некоторых из этих объектов, но ясно, что их необходимо описывать и хранить в некотором виде, удобном как для пользователя, так и для доступа из ядра InterBase. Лучше всего это сделать, сохранив все эти объекты в системных таблицах. Их добавление и модификация производятся с помощью SQL-запросов. Не правда ли, элегантное решение>9 Реализация сервера полностью отделена от конкретной базы данных — все взаимосвязи описываются SQL и его расширениями - языком хранимых процедур и триггеров.

Итак, все объекты сервера хранятся в таблицах. Для каждого вида объектов существует таблица, описывающая все экземпляры, описанные в базе данных. Например, для триггеров есть таблица RDB$Triggers, для процедур - RDBSProcedures, а представления описываются в таблице RDBSRelations.

Рассмотрим подробнее структуру последней таблицы, описывающей все таблицы и представления в базе данных. Структура таблицы RDBSRELATIONS вта из Language Reference for InterBase 6 и приведена в Табл 4 25

Табл 4.25. Системная таблица RDB$Relations

Колонка

Тип данных

Длина

Описание

RDB$VIEW_BLR

BLOB

80

BLR: Для представлений (view), содержит BLR (Binary Language Representation) запроса, который InterBase осуществляет каждый раз, когда идет обращение к представлению

RDB$VIEW SO URGE

BLOB

80

Текст: Для представлений содержит код SQL-запроса, который реализует это представление

RDB$ DESCRIP TION

и

80

Пользовательское описание таблицы или представления

RDBSRELATIO NJD

SMALLINT


Содержит внутренний идентификатор таблицы/представления

RDB$SYSTEM FLAG

II


Определяет тип содержимого таблицы: Пользовательские данные - 0; Системная информация > 0

RDB$DBKEY LE NGTH

N


Длина db$key

RDB$FORMAT

II


Зарезервировано для внутреннего использования InterBase Содержит счетчик изменений метаданных для данной таблицы

RDB$FIELD_ID

u


Число полей в таблице

RDB$RELATIO N_NAME

CHAR

31

Уникальное имя таблицы

В описании этой системной таблицы встречается аббревиатура BLR Чтобы понять, что это такое, придется сделать небольшой экскурс в SQL. Как известно, представления, триггеры и хранимые процедуры - это код, написанный на расширении языка SQL (для каждого сервера СУБД существуют свои расширения. Он приближен к человеческому языку, что позволяет легко составлять на нем запросы Но InterBase, очевидно, преобразовывает его во что-то более "машинное", а именно в BLR (Binary Language Representation), "твоичное" представление языка (SQL, очевидно). Любой запрос, триггер, представление, хранимая процедура обязательно транслируются в BLR, а уж затем передаются для исполнения ядру InterBase.