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

12.1.2 Атрибуты и шкалы измерения

Элементы данных, хранящиеся в базе, получаются в двух родственных процессах измерения и распознавания. Будем рассматривать процесс измерения как определение термина из словаря результатов измерений, который описывает результат измерения наилучшим, в некотором смысле, способом. Инвариантность результатов измерений определяют шкалы измерений. Формально шкала это отображение $$\phi : O\to R$$ действующее из множества $$О$$ измеряемых объектов в множество результатов измерений $$R$$. Определяющим компонентом шкалы является либо множество допустимых преобразований результатов измерений, либо обязательный набор отношений.

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

А нам зачем шкалы? За тем, что они дают еще один смысл, ограничивающий допустимую обработку данных хранящихся в базе.

Существует пять основных шкал — наименований, порядка, интервалов, отношений (подобий) и абсолютная шкала.

Шкала наименований

Допустимые преобразования — любые взаимно однозначные отображения.

Шкала порядка (она же ранговая)

Допустимые преобразования — любые монотонные отображения. Характеризующее множество отношений состоит из двух отношений — эквивалентности и порядка. Пример такой шкалы: бальные оценки успеваемости (например, неудовлетворительно, удовлетворительно, хорошо, отлично), шкала твердости минералов Мооса, в которой выбраны эталоны минералов, а принадлежность к классу определяется по царапанию поверхности.

Заметим, что для данных в шкале порядка среднее значение — неадекватная статистика. В теории функциональных уравнений показано, что, например, уравнение $$f((x+y)/2)=(f(x)+f(y))/2$$ выполняется только для линейной функции $$f$$, а в шкале порядка допустим более широкий класс монотонных преобразований.

Интервальная шкала (она же шкала разностей)

Часто употребляется для работы с субъективными оценками. Начало отсчета выбирается произвольно, единица измерения задана. Допустимое преобразование — линейное $$х' = х + с$$. В характеризующее множество отношений входят кроме отношения эквивалентности и порядка, еще отношение пропорциональности или суммирования интервалов (разностей). Типичный пример — темпоральные шкалы. В них интервалы времени можно суммировать или вычитать, но складывать даты бессмысленно. Другие примеры: шкалы температур по Цельсию и Фаренгейту. В интервальных шкалах для описания зависимостей можно использовать только отношения интервалов.

Шкала подобия

Допустимо преобразование подобия (умножение на положительную константу) $$х' = kх$$, где $$k > 0$$. В характеризующее множество отношений кроме эквивалентности, порядка, пропорциональности входит еще суммирование. Поэтому результаты таких измерений можно обрабатывать в рамках поля вещественных чисел, то есть, используя сложение, вычитание, умножение и деление. Нуль абсолютен и имеет определенный в предметной области смысл. Примеры измеряемых величин: масса, длина, сила, стоимость (цена), температура в абсолютной шкале (Кельвина).

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

Абсолютная шкала

Имеет единственную нулевую точку, характеризующую отсутствие чего-либо. Результат измерения однозначен, не подлежит изменению. Единственное допустимое преобразование тождественное. К множеству отношений шкалы подобия добавляется однозначность определения единицы измерений. Типичный пример — подсчет количества людей в группе.

Уже упоминалось, что шкала полностью определяет осмысленность методов обработки результатов измерения. Для классических шкал адекватны те статистики, которые инвариантны относительно допустимых преобразований используемой шкалы.

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

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

Возможны интерпретации результата измерения в моделях отличных от модели измерения и распадение измеряемой величины в семейство измеряемых величин.

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

Выпишем обычно неявно предполагаемые постулаты классической теории измерений, сделав упор на нюансы важные для рассматриваемого класса измеряемых величин:

Заметим, что, по крайней мере, в социологических измерениях невыполнение последних трех пунктов учитывается давно. В общем случае возможны нарушения всех перечисленных постулатов.

Система измеряемых величин может иметь сложную структуру, возможно зависящую от особенностей решаемой задачи и использованного инструментария. Например, план счетов управленческого бухгалтерского учета можно рассматривать как вмещающее пространство, определяющее каждый счет или субсчет как измеряемую величину. Этот план счетов может изменяться в зависимости от целей учета и/или особенностей бизнес-процессов.

Классическая измеряемая величина представляет концепт с двумя обязательными атрибутами:

имя_измеряемой_величины(модель_измерения, результат_измерения)

В общем случае измеряемая величина может иметь более сложную спецификацию:

имя_измеряемой_величины( область_применения, модель_измерения, модель_интерпретации, результат_измерения, параметры_измерения)

В ней атрибут "область_применения" характеризует ограничения на применимость величины, указание моделей измерения и интерпретации отражает различия между измерением и интерпретацией, атрибут "парамет-ры_измерения" характеризует условия, при которых выполнялось измерение.

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

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

12.2 Эмулирование моделей данных

Давно известно, что в реальных информационных системах трудно обойтись единственной моделью данных. В однослойной конструкции одна из моделей выбирается в качестве базисной. Именно она определяет структуры хранения данных. Остальные модели эмулируются, то есть реализуются через базисную модель. Мы уже представляли в реляционной модели древесные данные.

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

Мы попробуем бороться с почти очевидными недостатками, такими как неоптимальность хранения, сложность манипулирования данными и невысокое быстродействие. Будут отмечены возможные области применения и особенности эмулированных систем, которых нет в базисной модели данных. Это возможности работы с постоянно изменяемыми структурами данных, возможность реализации полуструктурированных, табличных, объектных, объектно-реляционных моделей, различных сетей и деревьев, возможность работы с базами, содержащими очень большое число таблиц, содержащих немногоданных.

12.2.1 Модели, эмулированные в табличной модели данных. Универсальная модель данных

Структуры данных во время работы базы изменяются довольно редко. Однако существует два типа систем, в которых схема базы перестраивается постоянно:

Подобные системы можно реализовать с помощью виртуальных баз данных со следующими свойствами:

Впрочем, последнее свойство не обязательное.

Базы с описанными свойствами принято называть универсальными (УБД), говорят и об универсальной модели данных (УМД).

Реализация УМД может быть выполнена в трех основных вариантах:

Выбор предпочтительного варианта зависит от того, насколько удается использовать возможность включающей СУБД. Например, для реализации УМД на основе XML необходимо, чтобы данные хранились в уже разобранном виде, а не цельным текстом. Кроме того, необходима поддержка языков для работы с XML: XPath, XQuery и т.п. Желательно, чтобы СУБД предоставляла средства для вставки и изменения в середине документа. Не все современные СУБД располагают перечисленными возможностями.

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

Если некоторые сущности и/или связи в схеме базы могут изменяться в процессе работы, то представление ее в обычной СУБД становится невозможным. Необходимо перестроить базу, а затем продолжить работу в новой схеме.

Известные приемы борьбы с этим явлением сводятся к изменениям схемы, при которых часть метаданных переносится в саму базу и потому команды DDL могут заменятся несколькими командами DML. Естественно, при этом необходимо интерпретировать эти метаданные нужным образом.

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

В простейшем варианте, УМД представляет собой набор из четырех таблиц изображенный на рисунке 12.1.

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

Для включения сущности в виртуальную схему необходимо добавить одну строку в таблицу "Сущность", а для добавления атрибута добавить одну строку в таблицу "Атрибут". Количество строк в таблице "Данные", определяющих один экземпляр сущности равно числу атрибутов у этой сущности.

Например, для записи в УМД таблицы dept(deptno, dname, loc) из схемы scott, содержащей одну первую строку (10, 'ACCOUNTING', 'NEW-YORK') необходимо:

Для упрощения изложения здесь предполагались пустые комментарии к схеме и отсутствие описаний таблиц и столбцов. Понятно, что, например, удаление таблицы dept с ее содержимым не требует выполнения инструкции DROP TABLE. Достаточно удалить перечисленные выше семь строк, содержащих метаданные таблицы и ее содержимое.

Всегда инструкция DDL виртуальной базы заменяется транзакцией с несколькими инструкциями DML в реально существующих таблицах УМД.

Одной команде манипулирования виртуальными данными всегда соответствует транзакция с набором из нескольких инструкций DML для реальных таблиц УМД.

Обратите внимание на то, что предложенная схема денормализована и сильно избыточна. Можно было бы создать суррогатные ключи и не повторять атрибуты (четыре раза атрибут "Имя схемы", три раза атрибут "Имя сущности" и два раза атрибут "Имя атрибута"). Из-за повторов атрибутов принятый подход несколько усложняет выполнение инструкций DDL для виртуальной схемы. Однако, при выполнении инструкций DML и запросов к виртуальным таблицам следует обращаться только к таблице "Данные", что сокращает количество соединений таблиц и существенно повышает быстродействие, которого в УМД сильно не хватает.

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

Из-за недостаточной известности работ по УМД это направление несколько раз переоткрывалось повторно в 2000-х годах. Наиболее известны УМД, отображающие реляционную и объектную виртуальные модели на реляционную модель.

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

Основные недостатки УМД:

Падение быстродействия и усложнение инструкций происходит в первую очередь из-за того, что для извлечения одной строки виртуальной таблицы, хранящейся в УМД, необходимо выполнить N — 1 соединений таблицы "Данные" с собой, где N — число столбцов виртуальной таблицы.

Недостатки УМД частично преодолены в программе представленной на сайте книгиwww.database-model-lang-struct-semantic.ru.

Проблема сложности запросов решается обычно созданием транслятора с языка виртуальной базы в язык работы с УМД. Пользователь работает только с виртуальной базой, может быть ничего не зная об УМД. Пример QBE запроса к виртуальным таблицам приведен в таблице 12.1.

В традиционной базе реляционного типа этот запрос соответствовал бы следующему запросу на SQL:

SELECT emp.ename, emp.job, emp.sal,
emp.deptno, dept.dname FROM emp,dept
WHERE emp.deptno=dept.deptno AND emp.sal > 10000;

Существует два способа трансляции запроса к виртуальной базе. Оба они реализованы в созданной системе. Первый — наиболее распространенный метод работы с УМД — использование соединений JOIN в запросе к реальным таблицам УМД. Предыдущему запросу к виртуальной базе соответствует следующий сложный запрос к реальной базе, в которой таблица "Данные" для краткости переименована в "tc":

SELECT t1.val,t2.val,t3.val,t4.val,t5.val
FROM tc tl, tc t2, tc t3, tc t4, tc t5, tc t6, tc t7, tc t8 WHERE t1.column_name='ENAME'
AND t1.table_name='EMP'    AND t1.scheme_name='TEST'
AND t2.column_name='JOB'
AND t2.table_name='EMP'    AND t2.scheme_name='TEST' AND t3.column_name='SAL'
AND t3.table_name='EMP'    AND t3.scheme_name='TEST' AND t4.column_name='DEPTNO'
AND t4.table_name='EMP'    AND t4.scheme_name='TEST' AND t5.column_name='DNAME'
AND t5.table_name='DEPT' AND t5.scheme_name='TEST' AND t6.column_name='DEPTNO'
AND t6.table_name='EMP'    AND t6.scheme_name='TEST' AND t7.column_name='DEPTNO'
AND t7.table_name='DEPT' AND t7.scheme_name='TEST' 
AND t8.column_name='SAL'
AND t8.table_name='EMP' AND t8.scheme_name='TEST' 
AND t1.string_number=t2.string_number AND t1.string_number=t3.string_number 
AND t1.string_number=t4.string_number 
AND t1.string_number=t6.string_number AND t1.string_number=t8.string_number 
AND t2.string_number=t3.string_number AND t2.string_number=t4.string_number 
AND t2.string_number=t6.string_number AND t2.string_number=t8.string_number 
AND t3.string_number=t4.string_number AND t3.string_number=t6.string_number
AND t3.string_number=t8.string_number AND t4.string_number=t6.string_number 
AND t4.string_number=t8.string_number AND t5.string_number=t7.string_number 
AND t6.string_number=t8.string_number AND  (t6.val=t7.val AND to_number(t8.val)>10000);

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

Второй способ, более быстрый, основан на использовании метода Т. Кайта для транспонирования строк в столбцы с помощью функции DECODE (см. раздел 8.5.2).

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

Рассмотренный выше запрос к виртуальным таблицам emp и dept, после трансляции в запрос к реальным таблицам УМД будет иметь следующий вид:

SELECT t1.ename,t1.job,t1.sal,t1.deptno,t2.dname
FROM (SELECT string_number,
min(decode(column_name,'ENAME',val)) ename, 
min(decode(column_name,'JOB',val)) job, 
min(decode(column_name,'SAL',val)) sal, 
min(decode(column_name,'DEPTNO',val)) deptno FROM tc
WHERE table_name='EMP' AND scheme_name='TEST'
GROUP BY string_number) t1,
(SELECT string_number,
min(decode(column_name,'DNAME',val)) dname, min(decode(column_name,'DEPTNO',val)) deptno FROM tc
WHERE table_name='DEPT'
AND scheme_name='TEST' GROUP BY string_number) t2 WHERE t1.deptno=t2.deptno AND t1.sal>10000;

Такой запрос в СУБД Oracle выполняется гораздо быстрее, чем составленный по первому методу. Кроме того, можно повысить быстродействие путем добавления индексов на таблицу данных. Конечно, это частичное решение проблемы быстродействия, и рекомендация по использованию УБД остается прежней: только инструментальные средства и часть базы с постоянно меняющимися структурами данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

12.2.2 Полуструктурированные данные

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

В моделях, допускающих только обязательные атрибуты, схема данных определяется заранее, априорно, и только затем начинается работа с данными. В полуструктурированных моделях используются апостериорные схемы, называемые обычно руководствами по данным (Data Guide). Они могут быть не известны до ввода данных и, уж точно, могут изменяться в процессе работы.

СУБД предназначенные для работы с полуструктурированными моделями данных существуют, но во многих случаях удобнее использовать соответствующие расширения в традиционных СУБД.

Принято выделять тяжеловесные (heavyweight) или легковесные (lightweight) модели полуструктурированных данных. В первых пытаются для работы с хорошо структурированными данными использовать традиционные средства, а для остальных вырабатывать средства специфические для плохо структурированных данных. Легковесные модели не предполагают такого разделения данных и потому хуже оптимизированы.

Мы будем заниматься эмуляцией одной из легковесных моделей OEM (Object Exchange Model), созданной в Стэнфордском университете для СУБД Lore, предполагая, что запросы можно разделять по степени структурированности данных и потому проблемы с оптимизацией запросов для хорошо структурированных данных нет.

Модель OEM представляется ориентированным графом с именованными ребрами. Хранимые объекты, которые могут быть простыми (атомарными) или сложными, представляются вершинами графа, имеющими уникальные идентификаторы. Простые объекты принимают значения одного из базисных типов, но не имеют исходящих ребер, Сложные объекты, наоборот, имеют исходящие ребра, но не имеют значений. Некоторым вершинам приписываются имена, используемые как точки входа в граф. Такую вершину называют еще корнем.

Объект OEM имеет структуру, представленную в таблице 12.2. Object_ID — уникальный идентификатор или NULL, Label — имя объекта, записанное текстовой строкой, Туре — тип данных, Value — значение, записанное текстовой строкой.

Простейший пример полуструктурированной базы в модели OEM представлен на рисунке 12.8. Отображаются два объекта. Это лица, связанные отношениями "быть сыном" и "быть матерью". У объекта "мать" имеется атрибут "цвет волос", отсутствующий у объекта "сын".

Обычно путеводителем по данным (рисунок 12.9) называют граф, который для каждого вида объектов содержит единственный узел, с которым связаны все атрибуты, существующие хотя бы у одного объекта. Будем называть его путеводителем или максимальным путеводителем. Можно считать, что он образован объединением без повторений всех объектов базы.

Добавим еще минимальный путеводитель (рисунок 12.10), образованный пересечением всех объектов базы.

Для реализации модели OEM в Cache необходимо в глобалах, которые могут быть только деревьями, научиться представлять добавленные ветви ссылок, соединяющих узлы одного уровня. Можно ссылки (связи, дополняющие дерево) хранить как компоненты значения узла. Можно ориентированную ссылку, имеющую имя "пате" и действующую из узла ^P(a1,a2, . . . ,аn) в узел ^P(b1,b2, . . . ,bm), хранить как узел ^Р(a1, а2, . . ., аn, "_name", "b1, b2, . . ., bm" ). При этом, его родитель ^Р (a1, а2, . . ., аn, "_name " ) является виртуальным узлом.

На рисунке 12.11 показан пример реализации базы и путеводителя в одном глобале Cache. Имя узла и его номер относительно одноименных узлов хранятся в одном индексе. Виртуальные узлы не выделены.

Можно хранить в индексе не полные имена узлов, а номера их предков. Кроме того, узел путеводителя может хранить количество узлов данных соответствующего типа. Например, на рисунке 12.11 запись ^P("DataGuide", "Person", "аде" )="2;1,2" значит, что в базе есть два свойства "age" у узлов типа "Person", а именно: у узлов ^Р("Person#l") и ^P("Person#2").

В DataGuide можно включить частоту появления некоторого свойства у типа. Она может быть больше 1 (например, у человека может быть несколько номеров телефонов). Можно учитывать сам факт вхождения узлов некоторого типа: при этом из нескольких однотипных потомков учитывается только один.

Мы не будем обсуждать такие важные детали, как реализация автоматически перестраиваемого путеводителя, организация навигации по объектам и по связям, создание индексов на связи между узлами, необходимых для ускорения поиска путей между узлами и поддержания целостности данных.

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

12.2.3 Другие модели, эмулируемые в иерархической модели данных

СУБД Cache обладает уникальными особенностями, которые позволяют существенно расширить ее возможности. Использование двух моделей—объектной и реляционной, обычная вещь в сегодняшних базах данных. Неразрывная связь этих моделей и еще иерархической модели — явление уникальное. Еще важнее то, что имеет эффективный язык для работы с деревьями, позволяющий организовывать многопоточную работу, но иерархическая модель данных не организована. Это позволяет, используя COS, расширить возможности СУБД Cache за счет введения практически любых моделей данных и усилить технологическое оснащение программирования за счет разработки транслятора для любой парадигмы.

Как и в реализации полуструктурированной модели, описанной выше, для эмулирования других моделей в иерархической модели необходимо деревья Cache пополнить различными ссылками. При этом в двухсторонних (т.е. неориентированных) ссылках при добавлении ссылки из одного узла на другой в последнем должна автоматически появляться ссылка на первый узел. Это обеспечивает навигацию по любым путям.

Обратим внимание на то, что универсальная модель данных, представленная на рисунке 12.1, это дерево с четырьмя уровнями: "схема" (это корень), "таблица", "столбец", "данные" (имеется в виду значение в ячейке на пересечении строки и столбца). Отсюда понятно, как в иерархической модели эмулировать модели табличного типа, объектные и объектно-реляционные модели.

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

Во втором способе узлы сети и их значения находятся на первом уровне дерева. В первом подварианте (будем говорить о подходе от значений) информация о том, что элементы (a1,a2, . . . ,аn) находятся в ориентированном отношении с именем р, хранится как часть значения узла a1. Во втором подварианте (подход от индексов) эти сведения размещаются в индексах потомков узла aj. Если сеть хранится в глобале ^Р, то такое отношение будет храниться как узел ^P(a1,a2, . . . ,аn) со значением р. Если этот набор узлов связан несколькими отношениями, то они перечисляются в значении узла ^P(a1,a2, . . . ,аn) через запятую. Если отношение неориентированное, то информация о нем хранится в каждом из узлов, участвующих в отношении.

На рисунке 12.12 в качестве примера показана сеть из трех узлов, представляющих трех человек — Алексея, Васю и Машу. На рисунке 12.13 изображено дерево, представляющее эту сеть при хранении ссылок в индексах дерева. Заметим, что отношения "родня" не ориентированное, так что можно было добавить еще пять узлов уровня 3 или ввести глобал справочника, позволяющий установить наличие такого отношения. На рисунке 12.14 —та же сеть, но расположенная в дереве с хранением информации о ссылках в значениях узлов. Первым элементом этого списка значений будет элемент, характеризующий узел сети, но не отношения, в которые он входит (на рисунках 12.13 и 12.14 эта часть представлена многоточием). На четных позициях, начиная со второй, помещаются имена отношений, на следующих за ними нечетных — списки узлов, входящих в отношения с предш ествующим именем. Выбор такого представления обусловлен тем, что поиск по равенству выполняется непосредственно функцией $LISTFIND.

Моделирование отношений произвольной арности позволяет представлять гиперграфы и семантические сети. Можно представлять наборы $$N=<A,B,T,U,f>$$, где

Как уже упоминалось, в неориентированных отношениях каждый узел содержит ссылки на все остальные узлы, связанные этим отношением. Из-за большой избыточности такого представления предлагается использовать вариант описанного выше представления с двумя поддеревьями: одно — для хранения узлов, другое —для неориентированных отношений. Ориентированные отношения хранятся как обычно, а неориентированные как ссылки на одноуровневые деревья, узлами которых являются имена узлов, состоящих в данном отношении.

На рисунке 12.15 изображен гиперграф, а на рисунке 12.16 — дерево, представляющее этот гиперграф. Ориентированные отношения хранятся в нем в узлах. На неориентированные отношения дается только ссылка. Эта ссылка представляет собой список из двух элементов: первый —это имя отношения, а второй — номер набора элементов для этого отношения.

На основе предложенного подхода в Cache могут быть реализованы двудольные графы сетей Петри. Необходимо организовать представление фишек и создать автомат, обеспечивающий работу сети.

Фишки, в том числе разносортные, представляются значениями узлов. В варианте с хранением сети в одном глобале индексы мест сети Петри получают префикс "Р_", а переходы снабжаются префиксом "В_". В результате автоматической сортировки узлов все переходы располагаются левее всех мест. Естественно, в реализации использовано ограничение "ребра между однотипными узлами не существуют". Возможны два варианта обхода сети — синхронный и асинхронный. Синхронный обход может быть реализован методом, использующим функцию $ORDER, которая в цикле перебирает всех потомков корневого узла, представляющих переходы сети. Для каждого такого узла анализируется возможность перехода и при положительном решении переход выполняется.

Для изменения порядка обхода узлов, представляющих переходы, достаточно расширить префикс. Изменение порядка обхода при необходимости может быть выполнено "на ходу" путем переписывания графа. Другой вариант — задание списка вершин для обхода параметром метода, выполняющего обход.

Асинхронный обход моделируется набором фоновых процессов, запускаемых операторами job. Каждый процесс следит за одним или несколькими переходами и через заданный интервал времени пытается выполнить свой переход. Для уменьшения нагрузки процессора, могут быть введены задержки.

Пример простой сети Петри, и ее представление в Cache приведены на рисунках 12.17 и 12.18. В значениях узла первый элемент для переходов—пустая строка, а для мест —количество фишек. "link" —имя отношения, необходимое для организации ссылки.

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

12.3 Данные и семантика данных

12.3.1 Данные и смыслы. Роль активности. Какие смыслы обычно используются

Обычно в базах данных семантика представляется тремя элементами: типами данных, ограничениями целостности и метаданными. Их реализация возможна благодаря свойству активности базы, реализуемому либо внутренними процедурами СУБД, либо триггерами. Промышленные СУБД реагируют на события из следующего набора: вставка, обновление и удаление записей и, может быть, так называемые серверные события, например, log in, log off и другие. В экспериментальных реализациях и исследовательских работах набор событий может быть значительно расширен за счет включения временн'ых, транзакционных событий, событий исполнения методов, чтения и доступа.

При изучении баз данных часто пренебрегают семантикой. Это затрудняет освоение и оперирование понятиями, основанными на смыслах, такими как, например, "аномалии" и "морфизмы моделей данных".

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

Смысл характеризуется интерпретатором смысла, местом нахождения, событиями, вызывающими активность, местом и/или способом прикрепления, особенностями активизации и сценарием реализации.

Роль интерпретатора, который распознает существование смысла и реализует его, может играть человек (пример такого смысла — комментарий в тексте программы при обычном его использовании), программа (пример — неявные преобразования типов), человек и программа (например, тройки RDF, ограничения целостности в базах данных или документирующий комментарий в языке Java).

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

Одно замечание о месте и/или способе прикрепления элементов семантики к фразам исходного языка или элементам данных. Так, в естественных языках семантические структуры прикрепляются к слову, словосочетанию, фразе, тексту или корпусу текстов. Процесс смыслообразования управляется ходом анализа фразы в некотором контексте. В языках программирования смыслы могут прикрепляться к токенам, конструкциям языка или программам. Роль контекста значительно ниже, но пренебрегать им не стоит.

Есть основания считать, что в современных базах данных смыслы более локализованы, чем в естественных языках, способы прикрепления семантики к данным проще, и процесс смыслообразования примитивен.

В базах данных семантика давно используется в геоинформационных системах. Правда, там понимают ее своеобразно — как слой неких ярлыков, размещенных поверх основного слоя базы. По-настоящему необходимость расширения семантики данных была понята в работах по консолидации гетерогенных баз данных и, особенно, с появлением семантического Web.

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

Мы покажем, что в базах данных можно существенно увеличить объем хранимой семантики, как интерпретируемой программой, так и совместно программой и человеком, рассмотрим классификации хранимых смыслов и способы реализации баз данных, насыщенных смыслами.

В базе данных хранятся только данные разных сортов. Одни используются как собственно данные, другие определяют смыслы этих данных, третьи определяют смыслы смыслов и т.д. Такое разделение возможно, если данные смыслов обладают активностью, позволяющей воздействовать на алгоритмы обработки данных, с которыми они связаны.

12.3.2 Классификация смыслов

Современные информационные системы (ИС), как правило, хранят лишь незначительную часть семантики моделируемой предметной области и решаемых задач. Большая часть информации, собранной в процессе анализа предметной области, в лучшем случае остается в документации, предназначенной для человека, в худшем —просто теряется. Приятное исключение — системы типа Oracle Designer и Unify.

Использование онтологий для построения информационных систем и расширения возможностей запросов в базах данных существенно меняет ситуацию. Появляется возможность включения большого пласта семантики предметных областей. Но онтологии содержат лишь часть возможной семантики данных. Кроме того, использование онтологий из внешних источников может существенно снизить быстродействие.

Мы уже упоминали, что первое основание для классификации любых смыслов —это интерпретатор смыслов, то есть человек, программа или совместно человек и программа.

Второе основание для классификации — место нахождения. Это память человека, база данных, интерфейс пользователя и т.д. Здесь мы будем рассматривать только смыслы, размещенные в базе данных.

Среди смыслов, которые могут храниться в базе, и предназначены для интерпретации программой, выделим следующие три вида:

Поясним последний вид смыслов. Обычно неявно предполагается, что пользователь умный (а с другой стороны, усложнение программы нам ни к чему), то есть он, как сейчас говорят, "в теме" и правильно понимает семантику предметной области. Например, он не будет писать запрос, в котором складываются рост и вес сотрудников. А может быть, даже помнит, что измерение успеваемости выполняется в шкале порядка, а потому средний балл — это неадекватная статистика.

Третье основание классификации смыслов —это набор событий, вызывающих активность. Выделим четыре вида событий: задание и изменение структур данных, изменение данных, чтение данных, события связанные с работой системы управления базами данных и ее администрированием. Современные базы данных почти никогда не используют событие чтения данных и не всегда работают с событиями первого и последнего классов.

Четвертое основание классификации смыслов — место прикрепления. Учтем, что современные базы данных могут иметь многослойные модели. Например, данные столбца реляционной таблицы могут разбираться с помощью регулярных выражений, в столбце может храниться содержимое файла XML и т.д. Поэтому смыслы в табличных базах могут прикрепляться к следующим объектам:

Типичный пример смысла прикрепленного к задаче обнаруживается в запросах, расширяемых онтологией. В них исходный запрос, не выдавший ни одной строки результата, может быть видоизменен путем замены условий отбора строк.

Обратим внимание на то, что столбец, таблица, схема как элементы метаданных могли бы быть связаны со смыслами в словаре, если бы СУБД позволяла это.

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

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

Перечислим часть смыслов, которые могут быть прикреплены к столбцу:

К строке могут быть подключены смыслы, представляющие оценки строк, и структуры, построенные на этих строках, например:

Некоторые смыслы, прикрепляемые к таблице:

На уровне подсхемы могут прикрепляться сведения о ее назначении, об агрегатах и композициях, наследовании и других отношениях.

Последнее пятое основание классификации смыслов, хранящихся в базе данных — особенности активизации и сценарий реализации — мы рассмотрим для баз данных реляционного типа в разделе "Способы реализации смыслов".

Смыслы можно классифицировать еще по следующим основаниям:

Значениями признака "предметная область" являются модель предметной области, концептуальная модель базы, база (логическая или физическая модель), эмулированная структура данных, хранящаяся в базе, другие компоненты информационной системы — такие, как интерфейс пользователя, приложения middletier и т.п.

Смыслы, используемые в интерфейсах пользователя, больше ориентированы на человека и могут определять контекстные подсказки, группировку полей (по смыслу, назначению и роли), задавать порядок расположения групп полей и последовательность их обхода.

Если для реализации смысла не требуется использования других смыслов, то такой "независимый" смысл будем называть поверхностным. Остальные смыслы будут характеризоваться как глубинные.

На данных, представляющих смыслы, можно определить свои ограничения целостности, которые могут существенно отличаться от ограничений на собственно данных. Структура элемента смысла в соответствии с приведенной выше классификацией: <условие_применения> <характе-ристики_контекстности> <временные_характеристики> <вид_записи> <за-пись_контекста> <ограничение_целостности>.

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

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

12.3.3 Примеры смыслов

Рассмотрим четыре примера работы смыслов в табличных базах данных.

Ячеечный смысл "Единица измерения"

В таблице, хранящей сведения о товарах, имеются два столбца — "Вес" и "Единица измерения веса". Для определения весов партий товаров необходимо перемножить количество по каждой позиции на вес одной позиции и сложить результаты, учитывая, что вес может измеряться в разных единицах — граммах, килограммах, тоннах и т.д.

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

SELECT Бит(количество*вес) FROM...

Столбцовый смысл "Шкала измерения"

Смысл "Шкала измерения" характеризует все данные в столбце. Активизируется событием "чтение данных" и прикрепляется, естественно, к столбцу с характеризуемыми данными. Устанавливает ограничения на адекватные статистики.

Строчный смысл "Надежность экспериментальных данных"

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

Табличный смысл "Структура в таблице"

Табличный смысл "Структура в таблице" позволяет указать, какая именно структура хранится в таблице (например, дерево или сеть некоторого вида) и следить за ее целостностью при модификации данных. Пусть таблица содержит иерархию подчиненности сотрудников в организации. При модификации данных необходимо обеспечить сохранение структуры, то есть не должны появляться поддеревья, образующие лес, не должны образоваться циклы. Рассматриваемый смысл может быть связан со строковым смыслом "Роль в дереве". С помощью последнего можно указать, какие узлы являются — листьями, какой — корнем, а какие имеют и предков и потомков. Смысл активизируется событиями "удаление данных", "ввод данных", "обновление данных", а прикрепляется он к таблице.

Отметим, что смысл "Структура в таблице" глубинный, а предыдущие три смысла — поверхностные.

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.

Таким образом, для построения запросов при работе со смыслами в УМД достаточно немного модифицировать транслятор запросов для обычной базы.

12.3.6 Примеры реализации смыслов

На рисунке 12.25 представлен реализованный интерфейс системы для работы со смыслами в приложении, представленном на сайте книги www.database-model-lang-struct-semantic.ru. Запросы к виртуальной табличной базе данных пишутся на языке QBE. Показаны запрос на QBE, соответствующий ему сформированный запрос на SQL, его результат, а также набор смыслов, которые можно добавить на форму для уточнения запроса. Подобный результат пользователь увидит при работе с системой в "лояльном" режиме. При добавлении смыслов на форму пользователь автоматически переводится в "строгий" режим работы.

В этом режиме пользователю предоставляется дерево смыслов, которые он может добавить на форму. При выполнении запроса с учетом выбранных смыслов транслятор может переформулировать или отменить исходный запрос. В итоге запрос, извлекающий смыслы данных, объединяется с запросом, извлекающим сами данные, и выполняется, а результат и весь текст запроса предоставляются пользователю (рисунок 12.26).

Пользователь может сразу перейти в "строгий" режим работы, если он знает, какие смыслы ему нужны для составления запроса. Таким образом, с каждым смыслом можно связать два сценария — для "строгого" и "лояльного" режимов.

Заметим, что некоторые сценарии с учетом смыслов могут выполняться автоматически, без обращения к пользователю.

Как уже упоминалось, предусмотрен вариант отказа пользователя от работы со смыслами. В этой ситуации семантику интерпретирует сам пользователь.

Остановимся на возможностях повторного использования смыслов. Поскольку смыслы, помещаемые в базу, определяются в основном предметной областью и в меньшей мере — базой данных, желательно смыслы выделить и обеспечить их повторное использование. Такую возможность предоставляет схема, приведена на рисунке 12.27.

В схему хранения смыслов, представленной на рисунке 12.23, добавлена таблица "Приложение", отмеченная на рисунке 12.27 цифрой 5, которая позволит выделить информацию о смыслах из разных приложений.

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

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

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

Для создания семантических расширений СУБД реляционного типа и объектно-реляционных необходимо:

12.3.7 Семантика задачи

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

Релевантность определяет степень соответствия смыслового содержания ответа семантике запроса. Именно так, расплывчато, мы и будем понимать термин "релевантность" далее. Пертинентность это соотношение объема полезной информации к общему объему полученной информации. Не будем вдаваться в тонкости определений этих понятий и, тем более, производных понятий, таких как точность поиска (отношение числа выданных релевантных фактов к общему числу ответов) и полнота поиска (отношение числа выданных релевантных фактов к общему числу имеющихся в базе релевантных фактов).

В базах данных насыщенных семантикой исполняемый запрос может перестраиваться, уточняться. При этом релевантность ответа повышается за счет дополнительной информации извлекаемой либо из пользователя, либо из хранимой семантики. Возможно как расширение, так и сужение запроса. Если, например, ищутся люди с указанной заработной платой, скажем, 10000, то может быть уместным уточнение смысла запроса. Выясним, мы ищем человека, про которого не известно ничего кроме зарплаты, или нам нужны люди с зарплатой примерно 10000. В последнем случае запрос может быть расширен путем замены точного значения на интервал, например, [9900, 10100].

В обычной базе нетрудно найти человека с фамилией Иванов, если в одной из таблиц есть столбец "Фамилия". В двухслойной базе, работающей с регулярными выражениями, Иванова можно найти даже в столбце "Фамилия, имя, отчество", а вот найти людей с "лошадиными" фамилиями не удастся. Необходимо иметь семантическую сеть с концептом "лошадь", сведения о том, как строятся фамилии в русском языке, и, может быть справочник фамилий. Необходимо также представлять какие именно понятия связываются у человека с лошадью непосредственно. Транслятор исходного запроса, написанного на некотором фрагменте естественного языка, должен трансформировать его с учетом указанных сведений о предметной области и схемы базы. Заметим, что результат будет очень похож на ответ поисковой системы. И обычные для поисковых систем оценки релевантности и пертинентности здесь будут вполне уместны.

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

12.4 Темпоральные данные

12.4.1 Время в базах данных

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

С точки зрения логики данные в базе представляют истинные высказывания. Отсутствие учета потока времени может создавать серьезные проблемы из-за того, что такие базы хранят только факты (они же высказывания) истинные в настоящий момент времени или в некотором интервале включающем настоящее время. Например, в таблице Счет(НомерСчета, Сальдо) хранится только текущий остаток на счете и нет возможности просмотреть состояние счета в прошедший момент времени или движение средств за период времени.

Время, интерпретируемое пользователем, на которое СУБД не реагирует, давно реализуется за счет введения интервальных типов данных таких, как DATE или TIMESTAMP. Интереснее СУБД или их расширения, которые способны сами интерпретировать темпоральные данные.

Темпоральные или хронологические базы данных отличаются включением утверждений о свойствах, зависящих от времени и интерпретируемых СУБД. Иначе говоря, в них содержатся наборы записей, в которых имеются элементы, представляющие метки времени или временные интервалы, и эти элементы играют существенную роль в интерпретации данных, которую выполняет СУБД.

Например, нашу таблицу emp (таблица 7.1) не стоит считать темпоральной только из-за того, что столбец hiredate в ней имеет тип DATE. Ведь СУБД не интерпретирует смысл этого столбца как даты, с которой вновь принятый сотрудник начинает работу. Кроме того, хорошо бы в emp иметь столбцы, фиксирующие даты увольнений (firedate) и переводов на другие должности (transferdate). Иначе создается нереалистическая картина организации, которая только принимает на работу, но не увольняет и не перемещает сотрудников. Вспоминая Стругацких, это список сотрудников, допущенных к получению зарплаты посмертно.

Отметим, что не только модель бизнеса отражается в схеме базы, но и проектные решения, принятые при проектировании базы, задают особенности бизнеса. Например, если считать, что ключ образуют столбцы табельного номера и даты приема, то у повторно принятого сотрудника желательно сохранить табельный номер. Тогда при смене фамилии сведения о нем будет легче найти.

Если темпоральная модель данных работает с некоторыми интервалами времени, говорят об интервальном подходе. При точечном подходе факты рассматриваются в определенные моменты времени. Реализация точечного подхода требует гораздо большего объема памяти.

Различают еще модельное и транзакционное время. Модельное время — это время моделируемой предметной области. Например, в таблице emp в столбце hiredate фиксируется дата, в которую сотрудник приступил к работе. Транзакционное время определяется промежутком времени, в который некоторая запись была представлена в базе данных, то есть периодом между добавлением и удалением записи. При этом операция обновления понимается как последовательность из удаления старой записи и добавления новой. Транзакционное время может быть не доступно пользователю и используется администраторами для работы с журналом и историей изменений записей (аудитом).

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

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

Транзакционных времен может быть несколько. Имеются успешные попытки создания темпоральных баз данных (TimesDB, например), которые учитывают ряд тонких свойств и множественность времен. Однако, эти разработки не смогли успешно конкурировать с известными СУБД, которые в какой-то мере пополнялись темпоральными опциями.

12.4.2 Темпоральные данные интерпретируемые пользователем

Рассмотрим, не претендуя на всеобщность, как некоторые темпоральные свойства могут быть реализованы в обычных базах табличного типа. Пусть имеется таблица $$T1$$ с ключом содержащим столбцы $$K_1,\dots,K_n$$ и неключевыми столбцами $$C_1,\dots,C_m:T1(K(K_1,\dots,K_n),C_1,\dots,C_m)$$.

Добавим столбцы в которых могут быть записаны моменты времени, определяющие создание объекта ($$T_С$$), возможные его изменения разных видов ($$T_{И1},\dots$$) и ликвидацию ($$T_Л$$). Теперь ключ таблицы должен содержать столбец $$T_С$$, но не столбцы $$T_{И1},\dots, Т_Л$$, возможно содержащие неопределенные значения: $$T1(K(K_1,\dots,K_n),C_1,\dots,C_m,T_{И1},\dots,T_Л)$$.

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

Покажем это на примере. Имеется справочник цен, которые могут изменяться неоднократно. В таблице pricel (таблица 12.3) указывается только начало действия цены. Семантика известная пользователю, но не прописанная в базе, определяет, что срок действия цены заканчивается в день, предшествующий назначению новой цены на этот товар.

Первичный ключ образуют столбцы price_code и start_date. Запрос, позволяющий узнать цену товара "А" действующую на указанную дату, требует использования подзапроса:

SELECT price FROM pricel WHERE price_code = 'A'
AND start_date = (SELECT MAX(start_date) FROM pricel WHERE price_code = 'A' AND start_date <= требуемая_дата)

Указание только начальной даты периода можно рекомендовать при интенсивной вставке записей и при отсутствии частых запросов по периодам времени, вроде приведенного выше.

Таблица price2 (таблица 12.4) определяет и начало и конец действия цены. Первичный ключ по-прежнему образуют столбцы price_code и start date.

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

SELECT price 
FROM price2 
WHERE price_code = 'A'
AND заданная_дата BETWEEN start_date AND end_date;

Если обновления данных будут происходить не часто, то скорость запросов может оказаться важнее.

12.4.3 Модальные и темпоральные данные как смыслы

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

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

Алетическими, тот есть трактующими истинность, называются модальности логические и каузальные, то есть причинные.

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

Каузальные операторы по именам те же, что логические, но по своей сути они отражают причинность, законы природы и социальных систем. То, что возможно каузально, то возможно логически. То, что необходимо или невозможно логически, то необходимо или невозможно каузально.

Алетические модальности могут быть временными ("в будущем", "в прошлом", "всегда" и т. п.) и пространственными ("здесь", "где-нибудь", "близко" и т. д.)

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

ее высказывания не представляют повествовательных предложений, которые в принципе можно проверить на соответствие действительному положению дел.

Обычно вводят основной оператор модальности, обозначаемый $$\Box$$ и двойственный к нему оператор $$\Diamond$$, связанные отношением $$\Diamond A=\urcorner \Box \urcorner A$$. Их смысл свой для конкретной логики. Например $$\Box$$, может иметь смысл "обязательно", а $$\Diamond$$ "возможно".

Темпоральные логики это частный случай логик модальных. В них могут в качестве $$\Box$$ и $$\Diamond$$ , использоваться символы будущего и прошлого, обозначаемые [F] и [Р].

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

Существует возможность реализовать модальности с использованием предикатов и кванторов, но реализация получается обычно слишком сложной.

Возможны две шкалы времени:

Интерпретацию темпоральных данных программой можно реализовать двумя основными способами:

Понятно, что второй вариант, скорее всего, будет иметь ограниченное применение.

12.5 Встроенные дедуктивные системы

Настало время вспомнить, что язык SQL основан на исчислении на кортежах и потому должен обладать дедуктивными возможностями, которые нами до сих пор не использовались.

В самом деле, что нам мешает рассуждать с помощью SQL? Как ни странно, ничего и не мешает. Просто раньше мы об этом не задумывались, так как слишком увлеклись выборками данных.

12.5.1 Продукции и их реализации в SQL

Продукции

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

Еще нам понадобится понятие продукции — средства описания продукционных знаний. Простейшая продукция это импликация

$$A\Rightarrow K$$

В ней условие (антецедент) А определяет некоторую ситуацию предметной области, некоторый факт или набор фактов. Заключение (консеквент) К это предикат, истинный, если подходящий факт в условии найден.

Следуя Поспелову Д.А. , будем использовать продукции общего вида:

$$ИП;О;У;A\Rightarrow K;П$$

где $$ИП $$— идентификатор продукции, $$О$$ —область применимости, $$У$$ — условие применимости, $$П$$ —последействие. Сама импликация $$A\Rightarrow K$$ называется ядром продукции.

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

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

Запрос, реализующий ядро продукции

Ядра продукции могут быть детерминированными (продукция обязательно исполняется) и недетерминированными (продукция может быть исполнена). Детерминированные продукции могут быть однозначными (с единственным следствием) и альтернативными (с возможностью выбора следствия).

Рассмотрим простейший пример. Пусть задан единственный набор фактов в виде таблицы $$БО$$ со схемой $$БО(сын, отец)$$, описывающей отношение "быть отцом", (таблица 12.5) и существует единственная продукция, опред еляющая отношение "быть дедом" как "отец отца есть дед":

$$БО(Сын,Х)\wedge БО(Х,Отец)\Rightarrow БД(Сын~AS~"Внук",Отец~AS~"Дед")$$

$$БО(Сын,Х)\wedge БО(Х,Отец)\Rightarrow БД(Сын~AS~"Внук",Отец~AS~"Дед")$$

В ней в соответствии с традициями языка Пролог имена переменных начинаются с заглавной буквы.

Для тех, кто не изучал логического программирования и продукционных систем, опишем работу продукции. Подбираем два факта описываемых предикатом $$БО$$ так, чтобы значение атрибута "Отец" из первого факта было равно значению атрибута "Сын" из второго факта. О необходимости такого действия говорит общая переменная X в первом и втором предикатах $$БО$$, стоящая, соответственно, на втором и первом местах. Следствием будет факт, описываемый предикатом БД (то есть, быть дедом), причем сын из первого предиката $$БО$$ теперь играет роль внука, а отец из второго $$БО$$ оказывается дедом. Для этого в консеквенте следует выполнить переименования, заменив "Сын" на "Внук", а "Отец" на "Дед".

На языке SQL рассмотренной продукции соответствует запрос, порождающий временное отношение "быть дедом":

SELECT Б01.Сын AS "Внук",  Б02.0тец AS "Дед" 
FROM БО Б01,  БО Б02 
WHERE Б01.0тец = Б02.Сын

Если не нужны все деды, то дополним фразу WHERE условием, присоединенным через конъюнкцию и позволяющим, например, найти деда конкретного человека: Б01.0тец = Б02.Сын AND Б01.Сын = 'ИВАНОВ'.

Условие продукции может представлять собой конъюнктивную, а может быть и дизъюнктивную, форму. Очевидно, что если две или более частей условия соединены связкой "ИЛИ", то такую продукцию можно разбить на две или более продукций. Например, продукция

$$(P1(\dots)\wedge P2(\dots))\vee P3(\dots) \Rightarrow P4(\dots)$$

эквивалентна совокупности продукций:

$$\begin{bmatrix} P1(\dots)\wedge P2(\dots) \Rightarrow P4(\dots) \\ P3(\dots) \Rightarrow P4(\dots) \end, $$

Прямая скобка, как в школьной математике обозначает совокупность (а не систему) продукций. С ними следует работать независимо.

В итоге получаем, что можно ограничиться продукциями, у которых условие представляется конъюнкцией некоторых предикатов.

Заметим, что в первом примере все аргументы посылок использовались либо для соединения предикатов (у нас переменная X), либо передавались в результат (у нас "сын" в первом предикате и "отец" во втором). В общем случае могут существовать еще, так называемые, безразличные имена, не представленные в результате и не используемые в соединении. Будем обозначать их традиционным для логического программирования знаком подчеркивания "_".

Например, если таблица БО станет такой как в таблице 12.6, то продукция перепишется так:

$$БО(Сын, \_, X,\_ )\wedge БО(Х, \_, Отец, \_) \Rightarrow БД(Сын AS "Внук", Отец AS "Дед") $$

а соответствующий запрос SQL не изменится.

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

Система продукций

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

Если данные заносятся в существующие таблицы, необходим механизм их очистки по завершении вывода.

Отметим, что уже здесь проявляется конфликт между процедурностью продукций общего вида и декларативностью SQL. Именно поэтому в схеме продукции мы используем последействие, расшифровываемое в процедурном смысле.

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

Таблица, хранящая произвольную систему продукций, может иметь спецификацию изображенную в таблице 12.7.

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

Прямой вывод в системе продукций это движение от посылок к заключениям. Пусть имеется несколько простейших продукций (например, $$A(X=1)\Rightarrow B(Y=3),B(Z)\Rightarrow C(Z)$$) и имеется некоторый исходный факт "Х=1 в таблице А". Машина вывода будет просматривать продукции в порядке записи. В первой продукции условие $$А(Х=1)$$ согласуется с исходным фактом. Значит истинно заключение $$B(Y=3)$$. Его используем как очередной текущий факт. Проверяя продукции, начиная с первой, видим, что предикат В имеется в условии второй продукции. $$B(Z)$$ согласуется с $$B(Y=3)$$ при $$Z = 3$$. Поэтому в предикате $$C(Z)$$ переменная $$Z = 3$$.

Обратный вывод предполагает движение в обратном направлении от цели (заключения) к условиям. Он используется в языке Пролог.

Такие важнейшие для продукционных систем знаний вопросы, как устранение противоречий и управление фронтом одиночных продукций мы не рассматриваем потому, что собираемся сосредоточиться на таблицах принятия решений. Это еще один подход к построению продукционных систем.

12.5.2 Таблицы принятия решений

Известно, что в продукционных системах с большим числом продукций (порядка 1000) очень трудно обнаружить противоречия, избавиться от избыточных продукций, которые никогда не работают, добиться правильного порядка исполнения продукций. Таблицы принятия решений, или сокращенно, таблицы решений облегчают структурирование больших продукционных систем, уменьшают количество продукций, задействованных на каждом этапе вывода.

В представлении предназначенном для восприятия человеком, в таблице решений существуют четыре основные области — условия, действия, варианты выполнения условий и необходимость действия (таблица 12.8).

Выделяют три типа таблиц:

Для того, чтобы быстро сориентироваться в сути вопроса рассмотрим простейший пример таблицы, заимствованной из Википедии (таблица 12.9).

Для работы с таблицей решений в табличной базе данных транспонируем представляющую матрицу, меняя столбцы и строки местами (таблица 12.10).

Получилась реляционная таблица с шестью столбцами и тремя строками.

Каждой строке этой таблицы соответствует продукция. Например, для первой строки:

Свет_в_соседней_комнате_горит(Да) $$\wedge$$ Свет_у_соседей_горит(Безразлично) $$\Rightarrow$$ Поменять_лампочку(Да)

Теперь для решения задачи прямого вывода достаточно написать простой запрос для поиска строки, соответствующей заданным условиям. Обратный доступ реализуется столь же простым запросом, выбирающим строки в зависимости от заданных действий.

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

Но мы не будем заниматься, ни оптимизацией структур систем принятия решений, ни оптимизацией самих таблиц, предоставив любознательному читателю самому во всем разобраться.

На сайте книги представлен реализованный вариант интеллектуального расширения СУБД Cache, полученного за счет подключения инструментального средства для создания и эксплуатации систем таблиц решений. Для хранения произвольных наборов таких таблиц в нем использован упрощенный вариант универсальной модели данных. Таким образом, и система искусственного интеллекта у вас теперь имеется, и, надеюсь, работу ее вы почти поняли.

12.6 Замечание об использованных моделях

Давайте, не вдаваясь в подробности, взглянем на модели, которые были использованы в книге.

Нетрудно заметить, что в литературе по базам данных давно под словом "модель" понимается некоторое семейство, а не четко определенная математическая конструкция. В самом деле, не считать же версию SQL с функцией DUMP() каким-то другим языком.

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

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

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

Мы расширили понятие модели данных за счет допущения многосортно-сти атрибутов. Изучение активности в базах данных позволило существенно пополнить семантику данных, за счет введения смыслов, представляемых активными данными.

Наконец, возврат к истокам, то есть воспоминание о том, что SQL произошел от исчисления на кортежах, позволил встроить в СУБД дедуктивную модель данных продукционного типа или модель, основанную на таблицах принятия решений.

Все это позволяет существенно расширить семантику данных и создает предпосылки для более активного использования онтологий.

Что же касается самого понятия модели, то мы достаточно далеко ушли от моделей в математическом смысле. Это естественно, так как основная задача в области баз данных — обеспечить моделирование некоторого бизнеса, хранение и обработку его данных, а не получение конструкций, "правильных" с некоторой теоретической точки зрения.

В качестве полезного упражнения предлагается самостоятельно разобраться с направлением NoSQL, которое трактуется либо как No SQL, либо как Not Only SQL. При этом в обсуждении вопроса о сложности SQL используйте пару терминов "сложность" и "адекватность задаче" а в качестве побудительной причины к изменениям рассматривайте, естественно, возросшие потоки данных, снизившуюся сложность обработки данных в новых задачах и необходимость обеспечить горизонтальное масштабирование аппаратной платформы.