Мир InterBase
         

Логическая структура базы данных InterBase


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

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

Довольно забавно в первый раз узнать, что все метаданные, - как пользовательские таблицы, триггеры, представления, так и все системные объекты, - хранятся в таких же точно таблицах, из которых можно читать и писать данные с помощью обычных SQL-запросов. Эти таблицы "визуально" отличаются только тем, что их имена начинаются с RDB$. Эти 4 символа зарезервированы для имен системных объектов, ни одна пользовательская таблица, столбец или другой объект не имеют права обладать именами, начинающимися с этих символов. Формально ничто не мешает создать вам таблицу, название которой начинается с зарезервированных символов, однако документация InterBase настойчиво не рекомендует этого делать.

Возникает вопрос: если данные о структуре таблиц базы данных хранятся в точно таких же таблицах, как и пользовательские, то где хранится информация о самих этих таблицах, которые описывают таблицы? Классический пример проблемы "курицы и яйца" - как одно могло появиться раньше другого, если они взаимозависимы? Решение состоит в том, что системные таблицы в их первозданном состоянии "прошиты" в исходных кодах 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.


    Содержание раздела