12.3 Данные и семантика данных
Данные и смыслы. Роль активности. Какие смыслы обычно используются.
Обычно в базах данных семантика представляется тремя элементами: типами данных, ограничениями целостности и метаданными. Их реализация возможна благодаря свойству активности базы, реализуемому либо внутренними процедурами СУБД, либо триггерами. Промышленные СУБД реагируют на события из следующего набора: вставка, обновление и удаление записей и, может быть, так называемые серверные события, например, log in, log off и другие. В экспериментальных реализациях и исследовательских работах набор событий может быть значительно расширен за счёт включения временн’ых, транзакционных событий, событий исполнения методов, чтения и доступа.
При изучении баз данных распространено пренебрежение семантикой, затрудняющее освоение и оперирование понятиями, основанными на смыслах, такими как, например, «аномалии» и «морфизмы моделей данных».
Рассмотрим семантику данных как систему частных смыслов. Будем называть смыслами данных (сокращенно – смыслами) любые фрагменты семантики, которые могут быть выделены, запомнены и использованы при интерпретации данных. Смыслы данных – это частный вид элементов семантики, но не любой элемент семантики есть смысл данных. Иначе говоря, мы можем достаточно четко определить смыслы данных и показать, как их реализовывать, но не утверждаем, что других элементов семантики в базах данных не существует.
Смысл характеризуется интерпретатором, местом нахождения, событиями, вызывающими активность, местом и/или способом прикрепления, особенностями активизации и сценарием реализации.
Роль интерпретатора, который распознает существование смысла и реализует его, может играть человек (пример такого смысла– комментарий в тексте программы при обычном его использовании), программа (пример – неявные преобразования типов), человек и программа (например, тройки RDF, ограничения целостности в базах данных или документирующий комментарий в языке Java).
Элементы семантики, интерпретируемые программой, должны быть активны во время исполнения программы. Смыслы в базах данных это вид данных, прикрепленных к другим данным и отличающийся от обычных пассивных данных своей активностью, то есть способностью инициировать работу некоторого программного или человеко-программного интерпретатора смысла (рис. 12.6).
Рис. 12.6. Данные и смыслы
Одно замечание о месте и/или способе прикрепления элементов семантики к фразам исходного языка или элементам данных. Так, в ЕЯ семантические структуры прикрепляются к слову, словосочетанию, фразе, тексту или корпусу текстов. Процесс смыслообразования управляется ходом анализа фразы в некотором контексте. В языках программирования смыслы могут прикрепляться к токенам, конструкциям языка или программам.
Есть основания считать, что в современных базах данных смыслы более локализованы, чем в ЕЯ, способы прикрепления семантики к данным другие, а процесс смыслообразования упрощен. Ниже эти особенности рассматриваются подробно.
В базах данных семантика давно используется в геоинформационных системах. Правда, там понимают ее своеобразно – как слой неких ярлыков, размещенных поверх основного слоя базы. По-настоящему необходимость расширения семантики данных была понята в работах по консолидации гетерогенных баз данных и, особенно, с появлением семантического Web’а.
Обычно декларативные языки, используемые в информационных системах, весьма бедны семантикой, а программа-интерпретатор не имеет за душой ничего, кроме операционной семантики, позволяющей реализовать правильное исполнение инструкций и выбрать оптимальный вариант. Можно расширить семантику базы, добавляя элементы семантики, полученные отображением каких-то моделей предметной области. Такой процесс мы будем называть насыщением базы данных смыслами. Нетрудно догадаться, что использование и частных элементов семантики, и общих, присущих достаточно большим предметным областям, может быть весьма полезным. К сожалению, язык описания предметной области обычно не формализован, типология предметных областей не определена или неизвестна.
Мы покажем, что в базах данных можно существенно увеличить объем хранимой семантики, как интерпретируемой программой, так и совместно программой и человеком, рассмотрим классификации хранимых смыслов и способы реализации баз данных, насыщенных смыслами.
В базе данных хранятся только данные разных сортов. Одни используются как собственно данные, другие определяют смыслы этих данных, третьи определяют смыслы смыслов и т.д. Такое разделение возможно, если данные смыслов обладают активностью, реализуемой с помощью триггеров или другими способами, и позволяющей воздействовать на алгоритмы обработки данных, с которыми они связаны.
Классификация смыслов
Современные информационные системы (ИС), как правило, хранят лишь незначительную часть семантики моделируемой предметной области и решаемых задач. Бóльшая часть информации, собранной в процессе анализа предметной области, в лучшем случае остается в документации, предназначенной для человека, в худшем – просто теряется. Приятное исключение – системы типа Oracle Designer иUnify.
Использование онтологий для построения информационных систем и расширения возможностей запросов в базах данных существенно меняет ситуацию. Появляется возможность включения большого пласта семантики предметных областей. Но онтологии содержат лишь часть возможной семантики данных. Кроме того, использование онтологий из внешних источников может существенно снизить быстродействие.
Мы уже упоминали, что первое основание для классификации любых смыслов – это интерпретатор смыслов, то есть человек, программа или совместно человек и программа.
Второе основание для классификации – место нахождения. Это память человека, база данных, интерфейс пользователя и т.д. Здесь мы будем рассматривать только смыслы, размещенные в базе данных.
Среди смыслов, которые могут храниться в базе, и предназначены для интерпретации программой, выделим следующие три вида:
смыслы, которые не могут быть реализованы в базе данных непосредственно (например, смыслы, относящиеся к интерфейсам пользователя или связанные со сценариями, реализуемыми вне базы данных);
смыслы, внесение которых в базу уже предусмотрено используемыми языками или СУБД (например, в SQL это метаданные, а именно: схема базы, типы данных, ключи, домены, процедурные и декларативные ограничения целостности);
смыслы, которые могут быть внесены в базу данных, но обычно передаются в ведение пользователя.
Поясним последний вид смыслов. Обычно неявно предполагается, что пользователь умный (а с другой стороны, усложнение программы нам ни к чему), то есть он, как сейчас говорят, «в теме» и правильно понимает семантику предметной области. Например, он не будет писать запрос, в котором складываются рост и вес сотрудников. А может быть, даже помнит, что измерение успеваемости выполняется в шкале порядка, а потому средний балл – это неадекватная статистика.
Третье основание классификации смыслов – это набор событий, вызывающих активность. Выделим четыре вида событий: задание и изменение структур данных, изменение данных, чтение данных, события связанные с работой системы управления базами данных и ее администрированием. Современные базы данных почти никогда не используют событие чтения данных и не всегда работают с событиями первого и последнего классов.
Четвертое основание классификации смыслов – место прикрепления.
Учтем, что современные базы данных могут иметь многослойные модели. Например, данные столбца реляционной таблицы могут разбираться с помощью регулярных выражений, в столбце может храниться содержимое файла XML и т.д. Поэтому смыслы в табличных базах могут прикрепляться к следующим объектам:
часть структуры, хранящейся в столбце в соответствии с ее шаблоном;
ячейка таблицы;
столбец;
строка;
группа строк, которую можно выделить через условия на значения в каких-то столбцах;
таблица;
группа таблиц, которую можно выделить по связям или соединениям;
схема базы;
атрибут связи;
связь;
задача.
Типичный пример смысла прикреплённого к задаче обнаруживается в запросах, расширяемых онтологией. В них исходный запрос, не выдавший ни одной строки результата, может быть видоизменён путём замены условий отбора строк.
Обратим внимание на то, что столбец, таблица, схема как элементы метаданных могли бы быть связаны со смыслами в словаре, если бы СУБД позволяла это.
Вспомним, что связи в СУБД реляционного типа не представляются отдельными хранимыми объектами базы, а выражаются через ключи – первичный и внешний – которые являются атрибутами таблиц-сущностей. Поэтому традиционно реализуются только бинарные ассоциации кратностей «один-ко-многим» и «один-к-одному», а т акже некоторый примитивный вариант обобщения. Используя смыслы можно представлять связи таблицами, у которых ключ составляют столбцы привязки к таблицам-сущностям. Смыслы в таблицах-связях задаются эмерджентными атрибутами или прикрепленными к ним другими атрибутами. Появляется возможность реализовать связи с произвольной арностью, агрегаты, композиции и ряд полноценных вариантов обобщения. Возможно более детальное задание кратности связи.
Отметим, что строки и значения в выбранной строке и столбце, то есть ячейки таблицы, в метаданных не представляются. Пары понятий «строка – таблица» и «ячейка – столбец» интересны тем, что они представляют каждая экстенсионал и интенсионал одного и того же понятия. У любого элемента такой пары могут быть свои смыслы. Например, столбец «Дата рождения» в некоторой таблице представляет интенсионал понятия «Время начала существования». Если имеется смысл «Надежность сведений о дате рождения», то его значения относятся к конкретным значениям дат, представляющим экстенсионал понятия, а не ко всему столбцу «Дата рождения». Поскольку прикрепление возможно только к элементам схемы, описываемым метаданными, то столбец смысла «Надежность сведений о дате рождения» будет прикрепляться к столбцу «Дата рождения», но интерпретироваться будет в соответствии с его назначением на ячейку.
Перечислим часть смыслов, которые могут быть прикреплены к столбцу:
тип данных (пользовательский или для второго слоя базы);
шкала измерений и/или интерпретации данных;
единица измерения;
наличие функциональных зависимостей, например, выводимые столбцы;
контекст, в котором используются данные;
темпоральные свойства, например, столбцы начала и конца существования;
указатели роли атрибута в какой-нибудь структуре на атрибутах.
К строке могут быть подключены смыслы, представляющие оценки строк, и структуры, построенные на этих строках, например:
оценки надежности данных;
характеристики источника данных.
Некоторые смыслы, прикрепляемые к таблице:
роль таблицы (сущность, атрибут, связь, таблица в составе индекса полнотекстового поиска, таблица итоговых данных, таблица dimension и т.д.) и свойства этой роли;
наличие структур хранимых в таблице (деревья, сети, в том числе семантические, сети Петри и т.д.).
На уровне подсхемы могут прикрепляться сведения об их назначении, об агрегатах и композициях, наследовании и других отношениях.
Последнее пятое основание классификации смыслов, хранящихся в базе данных – особенности активизации и сценарий реализации – мы рассмотрим для баз данных реляционного типа в разделе “Способы реализации смыслов”
Смыслы можно классифицировать еще по следующим основаниям:
предметная область, к которой относится смысл;
глубина смысла, определяемая возможным использованием других смыслов при его интерпретации;
тип значений смысла, домен и шкала измерений признака, реализованная на этом типе.
Значениями признака «предметная область» являются модель предметной области, концептуальная модель базы, база (логическая или физическая модель), эмулированная структура данных, хранящаяся в базе, другие компоненты информационной системы – такие, как интерфейс пользователя, приложения middletier и т.п.
Смыслы, используемые в интерфейсах пользователя, больше ориентированы на человека и могут определять контекстные подсказки, группировку полей (по смыслу, назначению и роли), задавать порядок расположения групп полей и последовательность их обхода.
Если для реализации смысла не требуется использования других смыслов, то такой «независимый» смысл будем называть поверхностным. Остальные смыслы будут характеризоваться как глубинные.
На данных, представляющих смыслы, можно определить свои ограничения целостности, которые могут существенно отличаться от ограничений на собственно данных. Структура элемента смысла в соответствии с приведенной выше классификацией:
<условие_применения><характеристики_контекстности> <временные_характеристики><вид_записи><запись_контекста> <ограничение_целостности>.
Будем называть задачей любое действие, возникающее вне базы данных и реализуемое с использованием данных и смыслов базы. С задачей может быть связана своя система смыслов. Несовместимость смыслов задачи и базы может привести к появлению решений, не имеющих предметного смысла. Так, в таблице, содержащей два столбца “Рост” и “Вес”, можно предположить наличие дерева, связанного этими столбцами, и получить результаты с непонятной интерпретацией.
Введённое понятие смыслов локально. Это позволяет расширить и уточнить понятие “аномалии”, представляя его как несоответствие между смыслами модели задачи в некоторой части предметной области и модели информационной системы, существенное для обеих сторон отображения из задачи в предметной области в модель информационной системы.
Примеры смыслов
Рассмотрим четыре примера работы смыслов в табличных базах данных.
Ячеечный смысл ”Единица измерения”
В таблице, хранящей сведения о товарах, имеются два столбца – “Вес” и “Единица измерения веса”. Для определения весов партий товаров необходимо перемножить количество по каждой позиции на вес одной позиции и сложить результаты, учитывая, что вес может измеряться в разных единицах – граммах, килограммах, тоннах и т.д.
В информационной системе, “понимающей” что такое единица измерения, можно написать запрос, представленный в листинге 1, а программа претранслятора входного запроса должна обнаружить смысл “Единица измерения” и автоматически перефразировать запрос с учетом использованных единиц измерения. Смысл активизируется событием “чтение данных” и всегда прикрепляется к столбцу.
-Листинг 1
SELECT sum(количество*вес) FROM...
Столбцовый смысл “Шкала измерения”
Смысл “Шкала измерения” характеризует все данные в столбце. Активизируется событием “чтение данных” и прикрепляется, естественно, к столбцу с характеризуемыми данными.
Строчный смысл “Надежность экспериментальных данных”
“Надежность экспериментальных данных” оценивается значениями перечислимого типа, например, в виде набора “надежные”, “не надежные”, “неизвестно”. При запросе некоторой статистики программа должна обнаружить этот смысл и попросить пользователя уточнить задание (“Вывести только надежные данные или все?” или “Сравнить надежные и остальные данные?” и т.п.). Смысл активизируется событием “чтение данных”. Может прикрепляться и к строке и к столбцам.
Табличный смысл “Структура в таблице”
Табличный смысл “Структура в таблице” позволяет указать, какая именно структура хранится в таблице (например, дерево или сеть некоторого вида) и следить за ее целостностью при модификации данных. Пусть таблица содержит иерархию подчиненности сотрудников в организации. При модификации данных необходимо обеспечить сохранение структуры, то есть не должны появляться поддеревья, образующие лес, не должны образоваться циклы. Рассматриваемый смысл может быть связан со строковым смыслом “Роль в дереве”. С помощью последнего можно указать, какие узлы являются – листьями, какой – корнем, а какие имеют и предков и потомков. Смысл активизируется событиями “удаление данных”, “ввод данных”, ”обновление данных”, а прикрепляется он к таблице.
Отметим, что смысл “Структура в таблице” глубинный, а предыдущие три смысла – поверхностные.
Способы реализации смыслов
Было бы удобно добавлять информацию о смыслах к таблицам метаданных словаря, но СУБД не предоставляют такой возможности. Существует два основных способа прикрепления значений смысла к данным.
Рассмотрим первый вариант. Значения смыслов, прикрепляемых к части значения в столбце, к ячейке, к строке и группе строк, можно хранить непосредственно в таблицах с данными. На рис. 12.7. к столбцу «Столбец n» прикреплен столбец со значением ячеечного смысла «Столбец со значением смысла». Вторая таблица представляет словарь смыслов, позволяющий определить связь столбцов данных и смыслов в таблицах, хранящих значения смысла, и указать имена этих смыслов. Предполагается, что со столбцом связан единственный смысл.
Рис.12.7. Подсхема БД при хранении смыслов в таблице с данными
Строчные смыслы, значения которых прикрепляются каждое к одной строке или группе строк, реализуются почти такой же схемой, но в схеме таблицы со смыслами значения столбца смысла относятся к строке целиком, а не к столбцу или ячейке. Поэтому столбец “Имя столбца, к которому прикреплен смысл” необходимо убрать из таблицы словаря. Вместо него указывается набор имен столбцов, по которым выделяется группа строк или одна строка. Для группы строк указывается условие выделения группы.
Во втором варианте предлагается хранить смыслы изолированно от пассивных данных. Это облегчает организацию повторного использования смыслов и создание режима отказа от использования смыслов. Подсхема, содержащая словарь смыслов, хранит всю информацию, необходимую для работы со смыслами. Она представляет собой нечто вроде хранимой в БД онтологии смыслов, используемых в базе.
Онтологии, которые позволяют хранить свое содержимое в БД, зачастую настолько универсальны, что запросы для извлечения информации получаются очень сложными и медленными. Наша схема хранит только необходимый набор смыслов. Кроме того, обычные онтологии не предоставляют возможности описать активность смыслов и каким-либо образом ее вызывать.
Для того чтобы разрешить использование двух режимов – с использованием смыслов и без них – и не перегружать данными базу, не интерпретирующую семантику, следует весь семантический слой вынести в отдельную подсхему. Например, система, содержащая только смыслы, прикрепляемые к ячейке, будет выглядеть так, как показано на рис. 12.8/
Рис.12.8. Подсхема БД при хранении смыслов изолировано от данных
Для реализации смыслов в базах реляционного типа необходимо, чтобы СУБД предоставляла следующие возможности:
хранение метаданных, отображающих специфику смыслов в словаре; в современных СУБД это невозможно;
существование триггеров на события, активизирующие смыслы; проблема в том, что в современных СУБД нет триггеров на чтение данных;
возможность реализации сценариев, связанных со смыслами и предусматривающих переформулирование исходной инструкции, может быть, в диалоге с пользователем, или отмену ее выполнения.
Возможности табличных СУБД в этом плане ограничены. Например, в Oracle, начиная с версии 10g,существует ряд пакетов, позволяющих эмулировать триггер на select и переписывать запрос частично или полностью. Для эмуляции триггера на событие select можно использовать пакет DBMS_RLS или DBMS_FGA. Методы пакета DBMS_RLS позволяют организовать поведение близкое к триггерам. Эмуляция триггера происходит путем создания так называемых процедур политики и задания времени их выполнения (например, на событие select указанной таблицы).
Для перезаписи запросов «на лету» в Oracle предлагается использовать пакет DBMS_ADVANCED_REWRITE.Однако у него много ограничений, и его использование в процедурах политики пакета DBMS_RLS приводит к внутренней ошибке Oracle.
Известными нам средствами СУБД отменить текущий запрос в процедуре политики невозможно. Разве что переписать текущий запрос так, чтобы он не возвращал строк, например, добавив тождественно ложное условие (например, «1=2») или вызвать ошибку приложения с помощью процедуры RAISE_APPLICATION_ERROR.
В Oracle существует еще одна возможность переформулирования запроса, но она реализуется только оптимизатором. В настоящий момент пользователи не имеют возможности использовать ее непосредственно.
Если нет возможности изменить СУБД, остается создать клиент или специальное серверное приложение со встроенным транслятором для предварительной обработки команд языка (рис. 12.9). В такой системе можно и переписывать исходный запрос, составляя новый запрос с учетом найденных смыслов, и отменять исходный запрос.
Рис.12.9. Работа клиента с претранслятором.
Кроме процессов определения вида инструкции и обнаружения смыслов, участвующих в выполнении этой инструкции, в сценариях, связанных со смыслами, должны использоваться:
проверки возможности преобразования шкал измерения, единиц измерения и типов данных;
организации диалога с пользователем, в том числе формирование дополнительной информации и подсказок;
переписывание запроса, например, путем преобразования данных к одной шкале измерения, к одной единице измерения, реорганизация списка столбцов и т.д.
Рассмотрим возможную организацию схемы, хранящей смыслы изолированно от пассивных данных (рис. 12.10). Таблицы в ней разделены на четыре группы. На рисунке каждая таблица отмечена номером группы, в которую она входит. Таблица “Связь таблиц данных и смыслов”, хранящая значения смыслов и их привязку к данным составляет первую группу. Она соответствует таблице “Словарь смыслов” второго способа хранения смыслов (рис. 12.8), используется при переписывании запроса и позволяет добавить условия на значения смыслов.
Вторая группа таблиц содержит в себе описание смыслов и состоит из четырех таблиц: “Смысл”, “Место крепления смысла”, “Группа смысла”, “Уровень информирования пользователя”. Таблица “Место крепления смысла” содержит возможные места крепления (например, таблица, столбец, строка и т.д.), которые являются одной из характеристик смысла. “Группа смысла” позволяет выделить набор смыслов, для обработки которых может использоваться один и тот же сценарий. Например, в группу “качества данных” входят смыслы “надежность данных”, “состояние документа” и т. п. Таблица “Уровень информирования пользователя” содержит вид возвращаемого сценарием результата. Сценарий может вернуть информацию, необходимую для интерактивного общения с пользователем, информацию для сообщения о внесенных изменениях в запрос, или ничего не вернуть. В последнем случае, пользователь оказывается в неведении о внесенных изменениях в запрос или в БД. При этом вид возвращаемого результата зависит от рассмотренных ниже режимов работы со смыслами.
Третья группа таблиц содержит информацию о возможных наборах значений смыслов, а также соответствия значений из разных возможных наборов значений. В эту группу входят таблицы “Набор значений”, “Шкала значений”, “Значение”, “Соответствие значений из разных наборов”, “Связь смысла и наборов его возможных значений”. Таблица “Набор значений” содержит возможные значения смысла. Таблица “Шкала значений” помогает определить что-то типа шкалы, в которой измеряется набор значений. Таблица “Значение” содержит все возможные значения смыслов для разных наборов. Можно указать соответствия значений из разных наборов, предназначенных для одного смысла, с помощью таблицы “Соответствие значений из разных наборов”.
Рис. 12.10. Схема хранения данных смыслов
Четвертая группа таблиц содержит информацию о сценариях, выполняемых при активизации смысла. Она содержит таблицы «Сценарий», «Действие», «Вид результата действия» «Действия в сценарии». Действие – это строка, которая представляет собой код на одном из процедурных языков программирования (например,PL/SQL). При выполнении сценария каждое действие выполняется, например, с помощью динамического SQL.При описании сценария каждому действию ставится в соответствие идентификатор, задающий его место в сценарии (содержится в таблице «Действия в сценарии»). Некоторые действия могут использовать результаты, полученные предыдущим действием. Кроме того, результат действия, как и сценария в целом, может быть различный (таблица «Вид результата действия»). Виды результата действий совпадают с видами результата сценариев, описанных выше и хранящихся в таблице «Уровень информирования пользователя». Единственное отличие в том, что режим работы со смыслами не влияет на вид результата действия. Предлагается обрабатывать смысл, ориентируясь на эти виды результата действий, так как это позволяет более эффективно организовать код.
Можно использовать три режима работы со смыслами:
работа со смыслами отключена – все как в обычных БД;
работа со смыслами в «лояльном» режиме – пользователю только рекомендуется использовать найденные смыслы; все запросы, которые в соответствии со смыслами являются некорректными, выполняются, а пользователь лишь получает предупреждение о некорректности составленного запроса;
работа со смыслами в «строгом» режиме – все запросы, которые в соответствии с используемыми смыслами считаются некорректными, отменяются и пользователю выдается сообщение о причинах такого поведения. Пользователь также может сразу добавлять смыслы к запросу и устанавливать на них условия.
Помимо описанных характеристик в схеме отражены также наборы возможных значений смыслов и соответствия между ними.
Рассмотренная схема позволяет хранить смыслы только одного приложения.
Смыслы в универсальной модели данных
Работа со смыслами в приложении, основанном на универсальной модели данных
На основе варианта системы, описанного в [6], разработано клиентское приложение, использованное как претранслятор при работе со смыслами в табличной модели данных. Единственный транслятор интерпретирует и запросы, и команды DDL и DML. Поэтому выполнение любой команды, в том числе и запроса, может быть триггерным событием, запускающим процедуру, играющую роль триггера. В частности, событием может быть запрос данных.
При работе со смыслами запрос может переформулироваться так, чтобы он содержал не только данные, но и значения смыслов. Для построения такого запроса необходимо извлекать данные из таблицы «Связь таблиц данных и смыслов», которая содержит элементы БД и прикрепляемые к ним значения смыслов.
Запросы для извлечения значений строковых смыслов очень похожи на запросы, формируемые для работы с УМД. Действительно, сравним таблицы «Связь таблиц данных и смыслов» (рис. 4) и таблицу «Данные» варианта УМД, изображенного на рис. 5. При построении запроса, содержащего условия на значения строковых смыслов (например, «надежность данных»), используются столбцы «Имя схемы данных», «Имя таблицы с данными», «Имя столбца данных», «Идентификатор строки», «Идентификатор смысла», «Значение смысла». Таким образом, таблица «Связь таблиц данных и смыслов» представляет собой, в сущности, таблицу данных в УМД, разработанной для хранения смыслов, а все остальные таблицы, изображенные на рис. 4, представляют собой описание смыслов и сценариев при их активизации. Соответствия столбцов таблицы «Связь таблиц данных исмыслов» и таблицы «Данные» показаны на рис.6. Таким образом, для построения запросов при работе со смыслами был всего лишь немного модифицирован пакет, транслирующий запросы при работе с УМД.
Рис. 6. Соответствия столбцов таблиц «Связь таблиц данных и смыслов» и «Данные»
Примеры реализации смыслов
Примеры реализации смыслов
На рис. 7 представлен интерфейс системы для работы со смыслами. Запросы к табличной базе данных осуществляются с помощью конструкций языкаQBE. На рис. 7 показаны запрос на QBE, соответствующий ему сформированный запрос на SQL, его результат, а также набор смыслов, которые можно добавить на форму для уточнения запроса. Подобный результат пользователь увидит при работе с системой в «лояльном» режиме. При добавлении смыслов на форму пользователь автоматически переводится в «строгий» режим работы.
Рис.7. Выполнение запроса в «лояльном» режиме работы со смыслами
В «строгом» режиме работы пользователю предоставляется дерево смыслов, которые он может добавить на форму. При выполнении запроса, учитывая выбранные смыслы, транслятор может переформулировать или отменить исходный запрос. В итоге запрос, извлекающий смыслы данных, объединяется с запросом, извлекающим сами данные, и выполняется, а результат и весь текст запроса предоставляются пользователю (рис.8).
Рис.8. Выполнение запроса в «строгом» режиме работы со смыслами
Пользователь может сразу перейти в «строгий» режим работы, если он знает, какие типы смыслов ему нужны для составления запроса. Разделение на режимы работы учитывается системой при выборе сценария работы. Таким образом, для каждого смысла можно предусмотреть два сценария – для «строгого» и «лояльного» режимов.
Заметим, что некоторые сценарии с учетом смыслов могут выполняться автоматически, без обращения к пользователю.
Как уже упоминалось, предусмотрен вариант отказа пользователя от работы со смыслами.
Повторное использование смыслов
Поскольку смыслы, помещаемые в базу, определяются в основном предметной областью и в меньшей мере – базой данных, желательно смыслы выделить и обеспечить их повторное использование. Схема, предоставляющая такую возможность, приведена на рис.9.
Рис.9. Упрощенное добавление соответствия смыслов из разных приложений и их значений
К схеме хранения смыслов, представленной на рис. 4, добавлена таблица «Приложение», отмеченная на рис. 9 цифрой 5, которая позволит выделитьинформацию о смыслахразных приложений (рис. 9). Информация о приложении, использующем смыслы, будет влиять только на таблицы «Связь таблиц данных и смыслов», «Сценарий», «Связь смысла и наборов его возможных значений», «Соответствие значений из разных наборов». Остальные таблицы содержат данные, описывающие смыслы и не зависящие от приложения.
Не вдаваясь в подробности, отметим, что такая система представляет некоторую разновидность базы знаний предметной области, ориентированной на реализацию в базах данных. Понятно, что для эффективного ее использования необходимо решить целый ряд теоретических проблем, связанных с заданием сходства и связанности смыслов, их контекстности. Предлагаемый подход существенно расширяет семантику,реализуемую в базах данных.В базе появляются связи, которые ранее не могли быть созданы. Можно считать, что введены семантические расширения реляционных и объектных моделей, реализуемые программно.
Базы данных, насыщенные семантикой,можно эмулировать за счет использования претрансляторов, которые в исходной инструкции обнаруживают прикрепленные смыслы и реализуют их, преобразуя исходную инструкцию автоматически или после диалога с пользователем, а затем передавая полученный результат на исполнение.
Для создания семантических расширенийСУБД реляционного типа и объектно-реляционных необходимо:
обеспечить хранение метаданных смыслов в словаре (не обязательное условие);
добавить триггеры на чтение данных;
разрешить пользователю создание и использование сценариев, связанных со смыслами, предусматривающих переформулирование исходной инструкции, может быть, в диалоге с пользователем, и отмену выполнения исходной инструкции.
Мы полагаем, что производителям СУБД было бы нетрудно внести необходимые изменения. Возможность работы с использованием и без использования смыслов не ухудшит быстродействия в обычном режиме.
Основные проблемы баз данных насыщенных семантикой связаны с необходимостью создания таксономии смыслов, разработкой типовых шаблонов реализации смыслов и организацией повторного использования смыслов, по возможности независимого от СУБД. Поскольку объем информации в предметных областях, отображаемых в базах данных, громаден,подобная работа может быть выполнена только коллективно.]