Семантика баз данных
12.3.3 Примеры смыслов
Рассмотрим четыре примера работы смыслов в табличных базах данных.
Ячеечный смысл "Единица измерения"
В таблице, хранящей сведения о товарах, имеются два столбца — "Вес" и "Единица измерения веса". Для определения весов партий товаров необходимо перемножить количество по каждой позиции на вес одной позиции и сложить результаты, учитывая, что вес может измеряться в разных единицах — граммах, килограммах, тоннах и т.д.
В информационной системе, "понимающей" что такое единица измерения, можно написать запрос, представленный в листинге 12.1, а программа претранслятора входного запроса должна обнаружить смысл "Единица измерения" и автоматически перефразировать запрос с учетом использованных единиц измерения. Смысл активизируется событием "чтение данных" и всегда прикрепляется к столбцу.
SELECT Бит(количество*вес) FROM...Пример 12.1. Пример запроса в системе, "понимающей", что такое единица измерения
Столбцовый смысл "Шкала измерения"
Смысл "Шкала измерения" характеризует все данные в столбце. Активизируется событием "чтение данных" и прикрепляется, естественно, к столбцу с характеризуемыми данными. Устанавливает ограничения на адекватные статистики.
Строчный смысл "Надежность экспериментальных данных"
"Надежность экспериментальных данных" оценивается значениями перечислимого типа, например, в виде набора "надежные", "не надежные", "неизвестно". При запросе некоторой статистики программа должна обнаружить этот смысл и попросить пользователя уточнить задание ("Вывести только надежные данные или все?" или "Сравнить надежные и остальные данные?" и т.п.). Смысл активизируется событием "чтение данных". Может прикрепляться и к строке и к столбцам.
Табличный смысл "Структура в таблице"
Табличный смысл "Структура в таблице" позволяет указать, какая именно структура хранится в таблице (например, дерево или сеть некоторого вида) и следить за ее целостностью при модификации данных. Пусть таблица содержит иерархию подчиненности сотрудников в организации. При модификации данных необходимо обеспечить сохранение структуры, то есть не должны появляться поддеревья, образующие лес, не должны образоваться циклы. Рассматриваемый смысл может быть связан со строковым смыслом "Роль в дереве". С помощью последнего можно указать, какие узлы являются — листьями, какой — корнем, а какие имеют и предков и потомков. Смысл активизируется событиями "удаление данных", "ввод данных", "обновление данных", а прикрепляется он к таблице.
Отметим, что смысл "Структура в таблице" глубинный, а предыдущие три смысла — поверхностные.
12.3.4 Способы реализации смыслов
Было бы удобно добавлять информацию о смыслах к таблицам метаданных словаря, но СУБД не предоставляют такой возможности. Существует два основных способа прикрепления значений смысла к данным.
Рассмотрим первый вариант. Значения смыслов, прикрепляемых к части значения в столбце, к ячейке, к строке и группе строк, можно хранить непосредственно в таблицах с данными. На рисунке 12.20 к столбцу "Столбец n" прикреплен столбец со значением ячеечного смысла "Столбец со значением смысла". Вторая таблица представляет словарь смыслов, позволяющий определить связь столбцов данных и смыслов в таблицах, хранящих значения смысла, и указать имена этих смыслов. Предполагается, что со столбцом связан единственный смысл.
Строчные смыслы, значения которых прикрепляются каждое к одной строке или группе строк, реализуются почти такой же схемой, но в схеме таблицы со смыслами значения столбца смысла относятся к строке целиком, к группе строк, а не к столбцу или ячейке. Поэтому столбец "Имя столбца, к которому прикреплен смысл" необходимо убрать из таблицы словаря. Вместо него указывается набор имен столбцов, по которым выделяется группа строк или одна строка. Для группы строк указывается условие выделения группы.
Во втором варианте предлагается хранить смыслы изолированно от пассивных данных. Это облегчает организацию повторного использования смыслов и создание режима отказа от использования смыслов. Подсхема, содержащая словарь смыслов, хранит всю информацию, необходимую для работы со смыслами. Она представляет собой нечто вроде хранимой в БД онтологии смыслов, используемых в базе.
Онтологии, которые позволяют хранить свое содержимое в БД, зачастую настолько универсальны, что запросы для извлечения информации получаются очень сложными и медленными. Наша схема хранит только необходимый набор смыслов. Кроме того, обычные онтологии не предоставляют возможности описать активность смыслов и каким-либо образом ее вызывать.
Для того чтобы разрешить использование двух режимов — с использованием смыслов и без них — и не перегружать данными базу, не интерпретирующую семантику, следует весь семантический слой вынести в отдельную подсхему. Например, система, содержащая только смыслы, прикрепляемые к ячейке, будет выглядеть так, как показано на рисунке 12.21.
Для реализации смыслов в базах реляционного типа необходимо, чтобы СУБД предоставляла следующие возможности:
- хранение метаданных, отображающих специфику смыслов в словаре; в современных СУБД это невозможно;
- существование триггеров на события, активизирующие смыслы; проблема в том, что в современных СУБД нет триггеров на чтение данных;
- возможность реализации сценариев, связанных со смыслами и предусматривающих переформулирование исходной инструкции, может быть, в диалоге с пользователем, или отмену ее выполнения.
Возможности табличных СУБД в этом плане ограничены. Например, в Oracle, начиная с версии 1С^,существует ряд пакетов, позволяющих эмулировать триггер на SELECT и переписывать запрос частично или полностью. Для эмуляции триггера на событие SELECT можно использовать пакет DBMSRLS или DBMSFGA. Методы пакета DBMSRLS позволяют организовать поведение близкое к триггерам. Эмуляция триггера происходит путем создания так называемых процедур политики и задания времени их выполнения (например, на событие SELECT указанной таблицы).
Для перезаписи запросов "на лету" в Oracle предлагается использовать пакет DBMS_ADVANCED_REWRITE. Однако у него много ограничений, и его использование в процедурах политики пакета DBMS_RLS приводит к внутренней ошибке Oracle.
Известными нам средствами СУБД отменить текущий запрос в процедуре политики невозможно. Разве что переписать текущий запрос так, чтобы он не возвращал строк, например, добавив тождественно ложное условие (например, "1=2") или вызвать ошибку приложения с помощью процедуры RAISE_APPLICATION_ERROR.
В Oracle существует еще одна возможность переформулирования запроса, но она реализуется только оптимизатором. В настоящий момент пользователи не имеют возможности использовать ее непосредственно.
Если нет возможности изменить СУБД, остается создать клиент или специальное серверное приложение со встроенным транслятором для предварительной обработки команд языка (рисунок 12.22). В такой системе можно и переписывать исходный запрос, составляя новый запрос с учетом найденных смыслов, и отменять исходный запрос.
Кроме процессов определения вида инструкции и обнаружения смыслов, участвующих в выполнении этой инструкции, в сценариях, связанных со смыслами, должны использоваться:
- проверки возможности преобразования шкал измерения, единиц измерения и типов данных;
- организации диалога с пользователем, в том числе формирование дополнительной информации и подсказок;
- переписывание запроса, например, путем преобразования данных к одной шкале измерения, к одной единице измерения, реорганизация списка столбцов и т.д.
Рассмотрим возможную организацию схемы, хранящей смыслы изолированно от пассивных данных (рисунок 12.23). Таблицы в ней разделены на четыре группы. На рисунке каждая таблица отмечена номером группы, в которую она входит. Таблица "Связь таблиц данных и смыслов", хранящая значения смыслов и их привязку к данным составляет первую группу. Она соответствует таблице "Словарь смыслов" второго способа хранения смыслов (рисунок 12.21), используется при переписывании запроса и позволяет добавить условия на значения смыслов.
Вторая группа таблиц содержит в себе описание смыслов и состоит из четырех таблиц: "Смысл", "Место крепления смысла", "Группа смысла", "Уровень информирования пользователя". Таблица "Место крепления смысла" содержит возможные места крепления (например, таблица, столбец, строка и т.д.), которые являются одной из характеристик смысла. "Группа смысла" позволяет выделить набор смыслов, для обработки которых может использоваться один и тот же сценарий. Например, в группу "качества данных" входят смыслы "надежность данных", "состояние документа" и т. п. Таблица "Уровень информирования пользователя" содержит вид возвращаемого сценарием результата. Сценарий может вернуть информацию, необходимую для интерактивного общения с пользователем, информацию для сообщения о внесенных изменениях в запрос, или ничего не вернуть. В последнем случае, пользователь оказывается в неведении о внесенных изменениях в запрос или в БД. При этом вид возвращаемого результата зависит от рассмотренных ниже режимов работы со смыслами.
Третья группа таблиц содержит информацию о возможных наборах значений смыслов, а также соответствия значений из разных возможных наборов значений. В эту группу входят таблицы "Набор значений", "Шкала значений", "Значение", "Соответствие значений из разных наборов", "Связь смысла и наборов его возможных значений". Таблица "Набор значений" содержит возможные значения смысла. Таблица "Шкала значений" помогает определить что-то типа шкалы, в которой измеряется набор значений. Таблица "Значение" содержит все возможные значения смыслов для разных наборов этих значений. Можно указать соответствия значений из разных наборов, предназначенных для одного смысла, с помощью таблицы "Соответствие значений из разных наборов".
Четвертая группа таблиц содержит информацию о сценариях, выполняемых при активизации смысла. Она содержит таблицы "Сценарий", "Действие", "Вид результата действия" "Действия в сценарии". Действие — это строка, которая представляет собой код на одном из процедурных языков программирования (например, PL/SQL). При выполнении сценария каждое действие выполняется, например, с помощью динамического SQL.При описании сценария каждому действию ставится в соответствие идентификатор, задающий его место в сценарии (содержится в таблице "Действия в сценарии"). Некоторые действия могут использовать результаты, полученные предыдущим действием. Кроме того, результат действия, как и сценария в целом, может быть различный (таблица "Вид результата действия"). Виды результата действий совпадают с видами результата сценариев, описанных выше и хранящихся в таблице "Уровень информирования пользователя". Единственное отличие в том, что режим работы со смыслами не влияет на вид результата действия. Предлагается обрабатывать смысл, ориентируясь на эти виды результата действий, так как это позволяет более эффективно организовать код.
Можно использовать три режима работы со смыслами:
- работа со смыслами отключена — все как в обычных БД;
- работа со смыслами в "лояльном" режиме — пользователю только рекомендуется использовать найденные смыслы; все запросы, которые в соответствии со смыслами являются некорректными, выполняются, а пользователь лишь получает предупреждение о некорректности составленного запроса;
- работа со смыслами в "строгом" режиме — все запросы, которые в соответствии с используемыми смыслами считаются некорректными, отменяются и пользователю выдается сообщение о причинах такого поведения. Пользователь также может сразу добавлять смыслы к запросу и устанавливать на них условия.
Помимо описанных характеристик в схеме отражены также наборы возможных значений смыслов и соответствия между ними.
Рассмотренная схема позволяет хранить смыслы только одного приложения.
12.3.5 Смыслы в универсальной модели данных
Поскольку при работе с универсальной моделью клиентское приложение используется как транслятор с языка QBE обращающегося к виртуальной базе в язык SQL для реальной базы, то выполнение любой команды, в том числе и запроса, может быть событием, запускающим процедуру, играющую роль триггера. В частности, событием может быть запрос данных.
Если смыслы затрагиваются, то запрос может переписываться с учетом этих смыслов. Для построения такого запроса необходимо использовать данные из таблицы "Связь таблиц данных и смыслов", которая описывает элементы БД и прикрепляемые к ним значения смыслов.
Запросы для извлечения значений строковых смыслов очень похожи на обычные запросы, формируемые для работы с УМД. Действительно, сравним таблицы "Связь таблиц данных и смыслов" (рисунок 12.26) и таблицу "Данные" варианта УМД, изображенного на рисунке 12.1. При построении запроса, содержащего условия на значения строковых смыслов (например, "надежность данных"), используются столбцы "Имя схемы данных", "Имя таблицы с данными", "Имя столбца данных", "Идентификатор строки", "Идентификатор смысла", "Значение смысла". Таким образом, таблица "Связь таблиц данных и смыслов" представляет собой, в сущности, таблицу данных в УМД, разработанной для хранения смыслов, а все остальные таблицы, изображенные на рисунке 12.1, представляют собой описание смыслов и сценариев при их активизации. Соответствия столбцов таблицы "Связь таблиц данных и смыслов" и таблицы "Данные" показаны на рисунке 12.24.
Таким образом, для построения запросов при работе со смыслами в УМД достаточно немного модифицировать транслятор запросов для обычной базы.