Семантика баз данных

Интерфейс прототипа использующего метод Кайта представлен на рисунке 12.2. В окне слева представлен набор виртуальных таблиц, входящих в схему (в примере это TEST), в которой он в данный момент работает. Справа находится область построения запросов на языке QBE. Внизу пользователь видит транслированный запрос на языке SQL, метод по которому проводилась трансляция, количество строк результата и сам результат. Имеется возможность экспорта и импорта виртуальной базы в реальную.

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

Используя пункт меню "УСБД" (Универсальная Схема Базы Данных) пользователь имеет возможность:

• загружать/выгружать таблицы РМД в/из УСБД;
• открывать и использовать другие схемы УМД;
• создавать и удалять схемы УМД.

В позиции меню Файл > Настройки пользователь может изменять метод трансляции и другие опции системы.

В системах управления базами данных реляционного типа активность проявляется при наступлении события из некоторого жестко заданного списка. Приспособить ее для работы в УМД невозможно, т.к. событий, связанных с виртуальной схемой во вмещающей СУБД не существует. Для реализации декларативных ограничений целостности в УМД необходимо добавить таблицу с описанием этих ограничений, информация в которой аналогична описанию декларативных ограничений в словаре системы управления реляционными базами данных (рисунок 12.3). Она содержит следующие поля: владелец, имя_ограничения, тип_ограничения, имя_таблицы_для_которой_действует_ограничение, условие_поиска, пра-вило_удаления, статус, связано_с_представлением. Для таблиц Таблица и Данные необходимо добавить триггеры на события DML. В зависимости от обрабатываемой виртуальной таблицы эти триггеры вызывают процедуры, реализующие декларативные ограничения целостности на виртуальные таблицы. Для каждого типа декларативного ограничения целостности определена одна параметрическая процедура, реализующая это ограничение.

Рис. 12.3. УМД с поддержкой декларативных ограничений целостности

Процедурные ограничения целостности в виртуальной базе представлены триггерами. Каждый триггер можно привязать только к одной таблице или представлению. В Oracle для реализации процедурных ОЦ в УМД предлагается два варианта. В первом используется пакет DBMS_SQL. К УМД добавляется таблица описания триггеров, в которую записываются транслированные триггеры при загрузке таблицы из РМД в УМД. Трансляции в теле триггера подвергаются только SQL-выражения, а также ссылки на реальные таблицы. Остальной код на PL/SQL остается в прежнем состоянии. Для таблиц Таблица и Данные создается по одному триггеру на каждый из возможных двенадцати типов триггеров или 4 триггера виртуальных (с фразой "inserting or updating or deleting"), которые будут находить соответствующие типы триггеров по таблице Триггер (рисунок 12.4), проверять соответствие условию и исполнять тело триггера с помощью пакета DBMS_SQL. Если тело триггера представляет собой вызов процедуры, то для процедуры РМД создается аналог в схеме УМД с транслированным телом по тем же правилам, что и для триггера. В таблице Триггер хранится информация, аналогичная хранимой в словаре СУРБД.

Рис. 12.4. Первый вариант УМД с поддержкой процедурных ОЦ

При втором подходе для каждого триггера из РМД создается соответствующий триггер в УМД. Так же, как и в первом подходе, изначально к УМД добавляется таблица описания триггеров, которая будет использоваться только для обратной выгрузки триггера в РМД. В ней хранится информация, аналогичная хранимой в словаре СУРБД. Для каждого триггера РМД в схеме УМД создается аналогичный триггер, но при этом транслируется часть when и тело триггера. Триггерам РМД на события DDL в УМД соответствуют триггеры на события DML. В части when всегда будет условие на то, что в текущем запросе участвует виртуальная таблица и схема. Если часть when триггера РМД непустая, то она транслируется и добавляется к условию. Тело триггера также необходимо транслировать, причем трансляции необходимо подвергнуть только SQL-выражения, а также ссылки на реальные таблицы. Остальной код на PL/SQL остается в прежнем состоянии. Если тело триггера представляет собой вызов процедуры, то для процедуры РМД создается аналог в схеме УМД с транслированным телом по тем же правилам, что и для триггера. Схема реализации получается довольно близкой к предыдущей.

Для реализации представлений в УМД также необходимо добавить таблицу описания представлений. При загрузке представления его запрос транслируется в запрос к УМД и записывается в таблицу Представление (рисунок 12.5). Так же, как в случае с триггерами, с реализацией представлений возможны два варианта. Первый вариант основан на триггере с событием select. Наличие претранслятора в архитектуре системы позволяет определять эквиваленты триггеров на любые события, в том числе и на выборку данных. При выполнении запроса транслятор заменяет название представления в части from на inline-view с запросом, записанным в таблице Представление, который был транслирован для УМД. Далее запрос исполняется как обычно.

Рис. 12.5. Первый вариант УМД с поддержкой представлений

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

Рис. 12.6. Второй вариант УМД с поддержкой представлений

В УМД можно также реализовать пользователей и сегментирование таблиц.

Полная схема УМД, включающая все расширения, представлена на рисунке 12.7.

Рис. 12.7. Расширенная УМД

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

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

Частично или полностью можно преодолеть три основных недостатка УМД:

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

работы в этой модели невозможна: ограничения целостности, триггеры, представления, схемы и пользователи (устранено). Отметим, что описанная реализация УМД потребовала использования весьма нестандартной семантики.