Семантические базы данных Бессарабов Н. В. bes@fpm. kubsu. ru 2012 г.
• СЕМАНТИКА – анализ отношения между языковыми выражениями и миром, реальным или воображаемым, а также само это отношение (ср. выражение типа семантика слова) и совокупность таких отношений (так, можно говорить о семантике некоторого языка). Данное отношение состоит в том, что языковые выражения (слова, словосочетания, предложения, тексты) обозначают то, что есть в мире, – предметы, качества (или свойства), действия, способы совершения действий, отношения, ситуации и их последовательности. Термин «семантика» образован от греческого корня, связанного с идеей «обозначения» (ср. semantikos «обозначающий» ). Отношения между выражениями естественного языка и действительным или воображаемым миром исследует лингвистическая семантика, являющаяся разделом лингвистики. Семантикой называется также один из разделов формальной логики, описывающий отношения между выражениями искусственных формальных языков и их интерпретацией в некоторой модели мира. В данной статье речь идет о лингвистической семантике.
Обязательные и необязательные атрибуты • Обычно для описания концепта (сущности) задается её уникальное имя и один или более атрибутов. В описаниях экземпляров обязательное задание значений классифицирующих атрибутов. Значения некоторых атрибутов может быть неизвестно, и тогда им присваивается символ отсутствующего значения NULL. Атрибуты рассмотренного вида будем называть обязательными. Долгое время все атрибуты считались обязательными, что соответствовало идеологии и духу учётных систем. Трудно представить себе, например, ведомость на выплату зарплаты, в которой для некоторых работников не обязательно указание фамилии. • В полуструктурированных данных часть атрибутов обязательна, а другие атрибуты, не обязательные, могут существовать у одних экземпляров сущности и отсутствовать у других. Представим, что необходимо выяснить круг лиц интересующихся некоторым сайтом. Можно, конечно, запретить вход на сайт лицам, которые точно не укажут имена, явки, пароли, серию, номер паспорта и массу других нужных нам сведений. Но ведь они могут просто отказаться от посещения сайта? Так что лучше уж разрешить посетителям сообщить о себе что-нибудь и добавить сведения, которые они сочтут важными. Если кто-то сам добавит атрибут ”цвет глаз” со значением “голубые”, то это повод выделить подкатегорию лиц, для которых цвет глаз важен. • Переход от хорошо структурированных данных с обязательными атрибутами к полуструктурированным данным -- это движение от систем с обученными и ответственными пользователями к системам с неквалифицированными (в рамках системы) и безответственными пользователями.
Концепты о сложными системами атрибутов • Существуют концепты без атрибутов. Их часто используют философы, создавая некоторые структуры из двух и более концептов, например, используя противопоставления или перечни альтернатив. С концептами без атрибутов можно работать, используя естественные для человека рассуждения на примерах. • В общем случае можно предположить существование концептов со сложно структурированными системами разносортных атрибутов. Достаточно широкое определение концепта можно получить, выделив пять классов атрибутов – обязательные, необязательные, состояния, ресурсы и смыслы. Предполагается, что в моделях понятий допускаются некоторые структуры на атрибутах, и явно заданы пути сужения/обобщения понятий. Могут использоваться ограничения на значения атрибутов и их комбинаций. • Кроме приведенной классификации по сортам атрибутов можно разбить концепты предметной области по их назначению на предметные (вещные, энергетические, информационные) сущности, сущности-связи и сущности-процессы.
Связи и процессы • Связи рассматриваются как концепты с двумя основными видами атрибутов. Первые определяют стороны связи, а вторые эмерджентные свойства, появляющиеся только при наличии связи. Понятия-связи могут уточняться добавлением атрибутов, определяющих возможность задействования связи, в частности, задающих нелинейности, и атрибутов, определяющих состояние и историю связи. • Конечно, создать, например, таблицу, хранящую атрибуты такой связи недостаточно. Необходимо обеспечить её активность. • Сущности-процессы можно определить как связи особого вида с четырьмя группами атрибутов, определяющих то, что действует (субъект), то, над чем выполняется действие (объект), какое действие (сценарий) выполняется и, наконец, при каких условиях, с какими ограничениями и свойствами идёт процесс. Под сценарием следует понимать связный и взаимно обусловленный набор действий.
Ресурсы • Для открытых систем выделяется класс сущностей-ресурсов. Желательно определить для них характеристики доступности и, если это возможно, законы сохранения и преобразования, хотя бы локальные. Используются ограничения на ресурсы и атрибуты любых концептов. • Сами ресурсы многосортны, а ресурсы некоторых сортов могут порождать ресурсы других сортов. Важно понимать, что ресурс может быть доступен экземпляру сущности или всему классу, но не является их свойством. • По-видимому, наиболее естественный подход к моделированию систем с ресурсами это разработка системы концептов, позволяющих описывать вмещающие пространства, существующие в них потоки ресурсов и распределенные объекты изучаемой системы.
Концепты и атрибуты в экономическом анализе (1/2) Любой хозяйственный механизм это система представляющаяся с одной стороны единым целым, с другой стороны как совокупность связанных и взаимодействующих между собой составных частей. Информационное отображение физических объектов или процессов называют информационным объектом. Совокупность информационных объектов, отображающих свойства системы и протекающие в ней процессы, называют информационным пространством (ИП). ИП это набор кластеров информации интерпретируемых машиной и фиксированных на носителях информации кодов, а также устных и визуальных сообщений интерпретируемых человеком. Все виды сообщений могут быть сохранены на носителях информации и при необходимости могут воспроизводиться. Элементы ИП структурируются в разной степени – от неструктурируемых (например, картина) до жёстко структурированных.
Концепты и атрибуты в экономическом анализе (2/2) Единица информации это “набор символов, которому придаётся определённый смысл”. По возрастанию содержательности понятия выделяют следующие уровни единиц информации: • Реквизит (атрибут), • составная единица информации (СЕИ), • показатель, • база данных. Реквизит - это информационное отображение свойства объекта, какого-либо процесса или явления. Реквизит – это логически неделимый элемент показателя, который отражает определенные особенности объекта или процесса. Составная единица информации собирается из набора реквизитов объекта и представляет собой информационное отображение объекта или его части.
Показатели и реквизиты Показатель это разновидность составной единицы информации. Определение показателя с формально-структурной точки зрения “Показатель представляет высказывание с законченным смыслом, включающее как название переменной величины, так и её конкретное количественное значение со всеми качественными признаками, необходимыми для идентификации последнего”. Показатель образуется на основе некоторого набора реквизитов или терминов. Другое определение: Совокупность логично связанных реквизитов-признаков и реквизитов-оснований, имеющая экономическое содержание, создают показатель. Реквизиты составляют две группы: • реквизиты-признаки, выражающие качественные отличия показателя, его смысловое содержание, в частности экономическое; • реквизиты-основания, содержащие количественные значения показателя. При структуризации информационного пространства создаётся система показателей, анализируется их структура. Необходимо выявить категории показателей, может быть, создать их онтологию.
Структура показателя (1/2) Каждый показатель состоит из одного реквизита-основания и одного или нескольких реквизитов-признаков, что позволяет давать полное представление об экономических объектах или процессах как с количественной, так и с качественной сторон. Показатель в экономической информации обладает внутренними качествами: формой – названием и содержанием - значением. Последнее отражает конкретную величину показателя за определенный отрезок времени, в конкретной экономической системе. Дополнительные признаки Q могут состоять из единиц измерения Е, уровня показателя У, времени В, субъекта С: Q=>(E, C, B, У), таким образом И => (S, (E, C, B, У)), где И - набор реквизитов (терминов), идентифицирующих смысловое значение показателя. Наименование показателя может быть слитным (определённым одним реквизитом) или иметь свою структуру и в свою очередь состоять из реквизитов, таких как: Ф -- формальная (вычисляемая) характеристика показателя; П -- обозначение отображаемого бизнес-процесса; О -- объект измерения.
Структура показателя (2/2) Итак, S=>(Ф, П, О). Таким образом общая структурная формула показателя примет вид: И=>(S, Q), S=>(Ф, П, О), Q=>(Е, С, В, У), С => ((Ф, П, О), (Е, С, В, У), значения) Данная структура может отображать документ или таблицу вида И Ф S П Q О Е С В У И - набор реквизитов (терминов), идентифицирующих смысловое значение показателя; S - составленное из реквизитов наименование показателя, выявляющее его предметный смысл;
Атрибуты и шкалы измерения • Элементы данных, хранящиеся в базе, получаются в двух родственных процессах измерения и распознавания. Будем рассматривать процесс измерения как определение термина из словаря результатов измерений, который описывает результат измерения наилучшим, в некотором смысле, способом. Инвариантность результатов измерений определяют шкалы измерений. Формально шкала это отображение : O R действующее из множества O измеряемых объектов в множество результатов измерений R. Определяющим компонентом шкалы является либо множество допустимых преобразований результатов измерений, либо обязательный набор отношений. • Шкала определяет допустимые способы обработки данных – адекватные статистики, а для некоторых областей, например, социологии может задавать более тонкие свойства, например, существенность, значимость результата измерений. • А нам зачем шкалы? За тем, что они дают ещё один смысл, ограничивающий допустимую обработку данных хранящихся в базе. • Существует пять основных шкал -- наименований, порядка, интервалов, отношений и абсолютная шкала.
Шкала наименований (номинальная) • Это самая слабая шкала. Значением признака, измеряемого в этой шкале (или качественного признака) является имя класса эквивалентности, к которому принадлежит объект при анализе по измеряемому признаку. Допустимые преобразования – любые взаимно однозначные отображения. Характеризующее множество отношений состоит из единственного отношения – эквивалентности. При большом числе классов используют иерархические шкалы наименований. Наиболее известными примерами таких шкал являются таксономии в биологии. Допустимая операция одна. Это проверка совпадения или несовпадения. Можно дополнительно вычислять вероятности заполнения для различных классов или количества элементов в классах. • Примеры признаков в шкале наименований: имена собственные, названия городов, номера игроков команды.
Шкала порядка (ранговая) • Допустимые преобразования – любые монотонные отображения. Характеризующее множество отношений состоит из двух отношений – эквивалентности и порядка. Пример такой шкалы: бальные оценки успеваемости (например, неудовлетворительно, хорошо, отлично), шкала твердости минералов Мооса, в которой выбраны эталоны минералов, а принадлежность к классу определяется по царапанию поверхности. • Заметим, что для данных в шкале порядка среднее значение -неадекватная статистика. В теории функциональных уравнений показано, что, например, уравнение f((x+y)/2) = (f(x)+f(y))/2 выполняется только для линейной функции f, а в шкале порядка допустим более широкий класс монотонных преобразований.
Интервальная шкала (шкала разностей). • Часто употребляется для работы с субъективными оценками. Начало отсчёта выбирается произвольно, единица измерения задана. Допустимое преобразование – линейное x = x + c. В характеризующее множество отношений входят кроме отношения эквивалентности и порядка, ещё отношение пропорциональности или суммирования интервалов (разностей). Типичный пример – темпоральные шкалы. В них интервалы времени можно суммировать или вычитать, но складывать даты бессмысленно. Другие примеры: шкалы температур по Цельсию и Фаренгейту. В интервальных шкалах для описания зависимостей можно использовать только отношения интервалов.
Шкала подобия и абсолютная шкала • Ш. подобия. Допустимо преобразование подобия (умножение на положительную константу) x = kx, где k>0. В характеризующее множество отношений кроме эквивалентности, порядка, пропорциональности входит ещё суммирование. Поэтому результаты таких измерений можно обрабатывать в рамках поля вещественных чисел, то есть, используя сложение, вычитание, умножение и деление. Нуль абсолютен и имеет определённый в предметной области смысл. Примеры измеряемых величин: масса, длина, сила, стоимость (цена), температура в абсолютной шкале (Кельвина). • Поскольку в классической физике и инженерном деле предполагается, что все измерения выполняются в шкале подобия, то иногда проявляется странная склонность рассматривать любые измерения как выполненные в этой шкале. Вот тогда школы начинают бороться за неадекватную статистику ”средний балл”, а недостаточно подготовленные аналитики удивляются тому, что в социологии измеримая величина в некоторых обстоятельствах оказывается незначимой. • Абсолютная шкала. Имеет единственную нулевую точку, характеризующую отсутствие чего-либо. Результат измерения однозначен, не подлежит изменению. Единственное допустимое преобразование тождественное. К множеству отношений шкалы подобия добавляется однозначность определения единицы измерений. Типичный пример – подсчет количества людей в группе.
Измеряемая величина • Шкала полностью определяет осмысленность методов обработки результатов измерения. Для классических шкал адекватны те статистики, которые инвариантны относительно допустимых преобразований используемой шкалы. • Понятие “измеряемая величина” можно обобщить на признаки сложных открытых объектов, используемых в общественных и компьютерных науках, в частности в администрировании программных продуктов и в адаптивных программах. Особенности рассматриваемого класса измеряемых величин связаны с невозможностью адекватного моделирования описываемого объекта вне контекста или вмещающей среды. Зависимость результата измерения от времени, состояния объекта и системы в целом, от ресурсов имеющихся в распоряжении измеряемого объекта и, наконец, ограниченность размеров ресурсов совместно используемых объектом измерения, другими объектами и измерителем приводят к существенному усложнению модели измеряемой величины.
Распадение измеряемой величины Возможны интерпретации результата измерения в моделях отличных от модели измерения и распадение величины в семейство величин. Пример разделения измеряемой величины “размер таблицы” для СУБД Oracle. Для размещения таблицы выделяется структура данных называемая сегментом. Сегмент состоит из экстентов, которые представляют набор непрерывно размещенных блоков базы имеющих фиксированный размер. В этом вмещающем пространстве “размер таблицы” распадается в следующее семейство измеряемых величин: • “Размер таблицы” как место, которое не могут занять другие таблицы. Он равен размеру сегмента. • “Размер таблицы” как количество экстентов занятых данными таблицы. • “Размер таблицы” как количество блоков занятых данными таблицы. • “Размер таблицы” как количество байтов занятых данными таблицы. • “Размер таблицы” как количество символов, выданных при распечатке таблицы. Из-за возможности кодирования, сжатия числовых данных и возможности шифрования “на лету” не совпадает со значением предыдущего параметра. • “Размер таблицы” определенный как значение параметра High. Water. Mark, указывающего на последний блок, когда-либо занятый данными таблицы. Величины описанного выше семейства, за исключением размера определяемого через число символов, вне базы смысла не имеют.
Постулаты классической теории измерений Выпишем обычно неявно предполагаемые постулаты классической теории измерений, сделав упор на нюансы важные для рассматриваемого класса измеряемых величин: • Измеряемый объект есть замкнутая система. Он не взаимодействует с другими объектами и, в частности, с измерителем. Отсюда следует, что его можно без ущерба извлечь из контекста (системы) или вмещающего пространства, и что влиянием измерителя можно пренебречь. • Измеряемый объект не меняется вообще и тем более во время измерения. Это означает, что результаты измерений выполненных в разное время и с разной длительностью совпадают с точностью до погрешности измерений, и что интерпретация измерения не зависит от времени начала измерения и его длительности. • Измеряемая величина не имеет ограничений на применимость. • Результат измерения интерпретируется непосредственно в рамках модели измерения. • Измеритель и алгоритм измерения не рассматриваются в рамках теории, то есть считаются всегда существующими или, по крайней мере, не заслуживающими внимания. Заметим, что, по крайней мере, в социологических измерениях невыполнение последних трёх пунктов учитывается давно. В общем случае возможны нарушения всех перечисленных постулатов.
Система измеряемых величин может иметь сложную структуру, возможно зависящую от особенностей решаемой задачи и использованного инструментария. Например, план счетов управленческого бухгалтерского учёта можно рассматривать как вмещающее пространство, определяющее каждый счёт или субсчёт как измеряемую величину. Этот план счетов может изменяться в зависимости от целей учета и/или особенностей бизнес-процессов. Классическая измеряемая величина представляет концепт с двумя обязательными атрибутами: • имя_измеряемой_величины(модель_измерения, результат_измерения). В общем случае измеряемая величина может иметь более сложную спецификацию: • имя_измеряемой_величины(область_применения, модель_измерения, модель_интерпретации, результат_измерения, параметры_измерения). В ней атрибут “область_применения” характеризует ограничения на применимость величины, указание моделей измерения и интерпретации отражает различия между измерением и интерпретацией, атрибут “параметры_измерения” характеризует условия, при которых выполнялось измерение.
Области существования Ограничения областей существования измеряемых величин одна из основных причин локальности используемых моделей. В отличие от известной практики, когда кусочные описания вызываются техническими причинами, в основном желанием упрощения используемых моделей, в общем случае причины явления лежат глубже, в свойствах самой изучаемой системы. Существенные ограничения на применение моделей делают получаемые знания менее универсальными и выдвигают на первый план аспекты, связанные с классификациями и идентификацией системы и ее признаков. Очевидно, что сведения о шкалах и особенностях измерений данных, содержащихся в базе, во многих случаях желательно хранить в базе и сделать их доступными информационной системе, основой которой эта база является. В последующих разделах станет понятно, что дополнительная информация об измерениях может храниться как один из элементов семантики данных в виде смыслов.
Полуструктурированные данные Модель полуструктурированных данных, допускающая необязательные атрибуты, может использоваться для интегрирования данных, полученных их разных источников, и для представления данных с нечётко определённой или меняющейся структурой. В моделях, допускающих только обязательные атрибуты, схема данных определяется заранее, априорно, и только затем начинается работа с данными. В полуструктурированных моделях используются апостериорные схемы, называемые обычно руководствами по данным (Data Guide). Они могут быть не известны до ввода данных и, уж точно, могут изменяться в процессе работы. СУБД предназначенные для работы с полуструктурированными моделями данных существуют, но во многих случаях удобнее использовать соответствующие расширения в традиционных СУБД. Принято выделять тяжеловесные (heavyweight) или легковесные (lightweight) модели полуструктурированных данных. В первых пытаются для работы с хорошо структурированными данными использовать традиционные средства, а для остальных вырабатывать средства специфические для плохо структурированных данных. Легковесные модели не предполагают такого разделения данных и потому хуже оптимизированы.
Легковесная модель OEM Мы будем заниматься эмуляцией одной из легковесных моделей OEM (Object Exchange Model), созданной в Стэнфордском университете для СУБД Lore, предполагая, что запросы можно разделять по степени структурированности данных и потому проблемы с оптимизацией запросов для хорошо структурированных данных нет. Модель OEM представляется ориентированным графом с именованными ребрами. Хранимые объекты, которые могут быть простыми (атомарными) или сложными, представляются вершинами графа, имеющими уникальные идентификаторы. Простые объекты принимают значения одного из базисных типов, но не имеют исходящих ребер, сложные объекты, наоборот, имеют исходящие ребра, но не имеют значений. Некоторым вершинам приписываются имена, используемые как точки входа в граф. Такую вершину называют ещё корнем. • Структура объекта OEM: Object. ID Label где Object_ID Label Type Value – уникальный идентификатор или NULL, – имя объекта, записанное текстовой строкой, – тип данных, -- значение, записанное текстовой строкой.
Простейший пример полуструктурированной базы в модели OEM Отображаются два объекта. Это лица, связанные отношениями ”быть сыном” и “”быть матерью. У объекта ”мать” имеется атрибут ”цвет волос”, отсутствующий у объекта ”сын”.
Data Guide Обычно путеводителем по данным называют граф, который для каждого вида объектов содержит единственный узел, с которым связаны все атрибуты, существующие хотя бы у одного объекта. Будем называть его путеводителем или максимальным путеводителем. Можно считать, что он образован объединением без повторений всех объектов базы. Добавим ещё минимальный путеводитель (на рис. справа), образованный пересечением всех объектов базы.
Реализация модели OEM в Caché Для реализации модели OEM в Caché необходимо в глобалах, которые могут быть только деревьями, научиться представлять добавленные ветви ссылок, соединяющих узлы одного уровня. Можно ссылки (связи, дополняющие дерево) хранить как компоненты значения узла. Можно ориентированную ссылку, имеющую имя “name” и действующую из узла ^P(a 1, a 2, …, an) в узел ^P(b 1, b 2, …, bn), хранить как узел ^P(a 1, a 2, …, an, ”_name”, ”b 1, b 2, …, bn”). При этом, его родитель ^P(a 1, a 2, …, an, ”_name”) является виртуальным узлом. Можно хранить в индексе не полные имена узлов, а номера их предков. Кроме того, узел путеводителя может хранить количество узлов данных соответствующего типа. Например, на рис. 12. 5 запись ^P(“Data. Guide”, ”Person”, ”age”)=” 2; 1, 2” значит, что в базе есть два свойства “age” у узлов типа “Person”, а именно: у узлов ^P(“Person#1”) и ^P(“Person#2”). В Data. Guide можно вычислить частоту появления некоторого свойства у типа. Она может быть больше 1 (например, у человека может быть несколько номеров телефонов). Можно учитывать сам факт вхождения узлов некоторого типа: при этом из нескольких однотипных потомков учитывается только один.
Пример реализации базы и путеводителя в одном глобале Caché Имя узла и его номер относительно одноименных узлов хранятся в одном индексе. Виртуальные узлы не выделены Такая реализация полуструктурированной модели Стала возможной в первую очередь благодаря заданию своеобразной семантики элементов представляющего глобала.
Активность базы данных База данных называется активной, если она способна выполнять не только те действия, которые требует пользователь, но и дополнительные действия, прямо им не указанные. В курсе баз данных рассматривалось использование активности для поддержки ограничений целостности. Как вы помните, необходимая активность обеспечивалась за счёт использования триггеров и хранимых процедур. Ограниченные возможности баз данных в отношении использования активности связаны с тем, что в них интенсионал (средства интерпретации) и экстенсионал (сами данные) разделены, причем интенсионал используется программой весьма ограничено, в надежде, что программист умный и всё интерпретирует сам и все сделает правильно. Выход из сложившейся ситуации – переход к базам данных насыщенным семантикой, но не моделям знаний, как может показаться на первый взгляд. Конечно, в моделях знаний интенсиональная информация хранится и интерпретируется программой без отрыва от самих данных. Но базы знаний качестве баз данных слишком не эффективны, особенно при больших объёмах. Можно допустить активность вообще не предполагающую каких-либо действий пользователя. (Что может делаться? )
Ранние реализации активности Активная база данных в общем случае реализует правила типа Событие-Условие-Действие. Система Starburst фирмы IBM основана на понятии переходов состояний и представляет деятельность базы как цепь таких переходов. Имеется возможность выполнять предопределённые правила, создавать правила, изменять приоритеты или дезактивировать правила. Система Postrgres предусматривает правила “Do Instead” (выполнить вместо) и “Do refuse” (отвергнуть выполнение если не выполняется некоторое ограничение). Заметим, что такие базы данных становятся очень похожими на продукционные системы.
Продукционная система Продукционная модель знаний это система основанная на правилах имеющих в общем случае вид: И; О; У; А К; П где И – идентификатор продукции; О – область применения; У – условие применения; А – антецедент (условие); К – консеквент (следствие); П – последействие. Более точно, ядро продукции следовало бы записать в виде: АХ КУ. А К Где x, y {W, R, K} По Поспелову Д. А.
Классификация продукций • Ядро продукции вида АW КR. Информация АW поступает из внешнего мира, а следствие КR представляет изменения в рассуждающей системе. • Ядро вида АW КK. . Ситуация передачи сообщения из внешнего мира в базу знаний. • Ядро вида АK КW. . Выдача сообщения из базы знаний во внешний мир. • Ядро вида АK КK. Полученный факт КK передается на хранение в базу знаний . • Ядро вида АK КR. Действует из базы знаний в рассуждающую систему. • Ядро вида АW КW. Продукция непосредственного отклика. • Ядро вида АR КW. Из рассуждающей системы во внешний мир. • Ядро вида АR КK. Внутренние продукции рассуждающей системы. • Ядро вида АK КK. Преобразования в базе знаний.
А если система продукций будет встроена в базу данных? Челове к Рассуждающая система БД БЗ А если нам удастся встроить продукционную систему непосредственно в базу данных? Какие виды продукций появятся и будут представлять практический интерес? Какие задачи они смогут решить?
Эмулирование универсальной модели данных Структуры данных во время работы базы изменяются редко. Однако существует два типа систем, в которых схема базы перестраивается постоянно: • Информационные системы (ИС) с данными, структуры которых невозможно предусмотреть заранее. Типичный пример – медицинские данные. • Средства разработки ИС. Особый интерес представляют инструментальные средства, в которых структуры данных или же весь прототип ИС собирается “на ходу” в процессе сбора сведений о предметной области и решаемой задаче, причём иногда необходимы откаты создаваемых архитектур. Подобные системы можно реализовать с помощью виртуальных баз данных со следующими свойствами: • Виртуальные структуры данных, включая словарь и сами данные, хранятся в фиксированном наборе таблиц вмещающей базы и могут изменяться в процессе работы. Допускаются откаты команд языка определения данных (DDL), чего нет в обычных базах данных. • Словарь вмещающей базы не содержит данных словаря виртуальной базы. • Возможен экспорт и импорт из виртуальной базы во вмещающую базу или базу с другой моделью данных.
Реализации УМД Базы с описанными свойствами принято называть универсальными (УБД), говорят и об универсальной модели данных (УМД). Реализация УМД может быть выполнена в трёх основных вариантах: • с использованием инвариантных структур в обычной базе, например, реляционного типа; • на основе XML-баз или XML-опций баз данных; • на основе иерархических моделей. Выбор предпочтительного варианта зависит от того, насколько удается использовать возможность включающей СУБД. Современные реляционные базы данных редко имеют мощные средства для работы с XML. Для реализации УМД на основе XML необходимо, чтобы данные хранились в уже разобранном виде, а не цельным текстом. Кроме того, необходима поддержка языков для работы с XML: XPath, XQuery и т. п. Желательно, чтобы СУБД предоставляла средства для вставки и изменения в середине документа. Не все СУБД располагают такими возможностями.
УМД на основе табличной модели состоит из фиксированного набора таблиц. Она может хранить в себе и данные, и метаданные нескольких виртуальных схем базы. В простейшем варианте УМД представляет собой фиксированный набор из четырех таблиц: Этот набор не меняется при любых изменениях виртуальной схемы данных и самих данных. Для добавления имени таблицы в виртуальную схему необходимо добавить одну строку в таблицу “Таблица”, а для добавления столбца – добавить одну строку в таблицу “Столбец”. Количество строк в таблице “Данные”, определяющих одну строку таблицы, равно числу столбцов у этой таблицы. Тип столбца может быть описан в колонке “Описание” таблицы “Столбец”, но может быть добавлен в дополнительном столбце. Заметим, что может быть создана не только пустая виртуальная схема, но и таблица без столбцов, не существующая в реляционной модели.
Особенности и недостатки реализации Схема УМД сделана ненормализованной для того, чтобы при запросах к виртуальным таблицам обращаться к единственной таблице “Данные” и тем самым сократить количество соединений таблиц. Число соединений таблицы данных с собой на единицу меньше числа столбцов в соответствующей виртуальной таблице. Одной команде DML для виртуальной таблицы соответствует транзакция в виде набора из однотипных команд записи, обновления или удаления данных для реальной таблицы данных из УМД. Их число также на единицу меньше числа столбцов в соответствующей виртуальной таблице. Как уже упоминалось, УМД обладают следующими недостатками: • очень сложные запросы; • низкое быстродействие; • отсутствие во многих реализациях ограничений целостности (ОЦ) (декларативных и процедурных), индексов, пользователей, ролей, представлений.
Как устранить недостатки Проблема сложности запросов в одной из наших реализаций была решена за счёт создания претрансляторов из языка Query-by-Example (QBE) для виртуальной базы в запросы к реальным таблицам для СУБД Oracle и Caché. Запросы всегда пишутся в виртуальной базе, и имеется возможность проконтролировать исполняемый запрос. Заметим, что можно было бы использовать претранслятор из языка SQL и транслировать запрос в любой язык, принятый во вмещающей СУБД. Важно лишь, чтобы пользователь обращался непосредственно только к виртуальной базе. Пример запроса на языке QBE к виртуальным таблицам УМД в реализованном варианте транслятора в Oracle. Имена с двумя знаками подчеркивания в первой и последней позиции обозначают переменные.
Как это работает (1/3) Транслятор создаёт запрос к виртуальным таблицам УМД на языке SQL: SELECT emp. ename, emp. job, emp. sal, emp. deptno, dept. dname FROM emp, dept WHERE emp. deptno=deptno; А он транслируется в представленный ниже запрос к реальным таблицам УМД, использующий соединения таблиц:
Как это работает (2/3) Начало запроса: SELECT T 1. VAL, T 2. VAL, T 3. VAL, T 4. VAL, T 5. VAL FROM TC T 1, TC T 2, TC T 3, TC T 4, TC T 5, TC T 6, TC T 7, TC T 8 WHERE T 1. COLUMN_NAME='ENAME' AND T 1. TABLE_NAME='EMP' AND T 1. SCHEME_NAME='SCOTT' AND T 2. COLUMN_NAME='JOB' AND T 2. TABLE_NAME='EMP' AND T 2. SCHEME_NAME='SCOTT' AND T 3. COLUMN_NAME='SAL' AND T 3. TABLE_NAME='EMP' AND T 3. SCHEME_NAME='SCOTT' AND T 4. COLUMN_NAME='DEPTNO' AND T 4. TABLE_NAME='EMP' AND T 4. SCHEME_NAME='SCOTT' AND T 5. COLUMN_NAME='DNAME' AND T 5. TABLE_NAME='DEPT' AND T 5. SCHEME_NAME='SCOTT' AND T 6. COLUMN_NAME='DEPTNO' AND T 6. TABLE_NAME='EMP' AND T 6. SCHEME_NAME='SCOTT' AND T 7. COLUMN_NAME='DEPTNO' AND T 7. TABLE_NAME='DEPT' AND T 7. SCHEME_NAME='SCOTT'
Как это работает (3/3) Конец запроса: AND T 8. COLUMN_NAME='SAL' AND T 8. TABLE_NAME='EMP' AND T 8. SCHEME_NAME='SCOTT' AND T 1. STRING_NUMBER=T 2. STRING_NUMBER AND T 1. STRING_NUMBER=T 3. STRING_NUMBER AND T 1. STRING_NUMBER=T 4. STRING_NUMBER AND T 1. STRING_NUMBER=T 6. STRING_NUMBER AND T 1. STRING_NUMBER=T 8. STRING_NUMBER AND T 2. STRING_NUMBER=T 3. STRING_NUMBER AND T 2. STRING_NUMBER=T 4. STRING_NUMBER AND T 2. STRING_NUMBER=T 6. STRING_NUMBER AND T 2. STRING_NUMBER=T 8. STRING_NUMBER AND T 3. STRING_NUMBER=T 4. STRING_NUMBER AND T 3. STRING_NUMBER=T 6. STRING_NUMBER AND T 3. STRING_NUMBER=T 8. STRING_NUMBER AND T 4. STRING_NUMBER=T 6. STRING_NUMBER AND T 4. STRING_NUMBER=T 8. STRING_NUMBER AND T 5. STRING_NUMBER=T 7. STRING_NUMBER AND T 6. STRING_NUMBER=T 8. STRING_NUMBER AND (T 6. VAL=T 7. VAL AND TO_NUMBER(T 8. VAL)>10000);
Метод Т. Кайта Транспонирование строк в столбцы. Рассмотренный выше запрос к виртуальным таблицам emp и dept транслируется в: SELECT T 1. ENAME, T 1. JOB, T 1. SAL, T 1. DEPTNO, T 2. 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) T 1, (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) T 2 WHERE T 1. DEPTNO=T 2. DEPTNO AND T 1. SAL>10000;
Активность и ограничения целостности В современных СУБД активность задана для событий из заданного списка. В УМД событий, связанных с виртуальной схемой не существует. Для реализации декларативных ограничений целостности в УМД необходимо добавить таблицу с описанием этих ограничений, информация в которой аналогична описанию декларативных ограничений в словаре системы управления реляционными базами данных: Она содержит следующие поля: владелец, имя_ограничения, тип_ограничения, имя_таблицы_для_которой_действует_ограничение, условие_поиска, правило_удаления, статус, связано_с_представлением. Для таблиц Таблица и Данные необходимо задать сложные триггеры на все события DML. В зависимости от обрабатываемой виртуальной таблицы эти триггеры вызывают процедуры, реализующие декларативные ограничения целостности на виртуальные таблицы. Для каждого типа декларативного ограничения целостности определена одна параметрическая процедура, реализующая это ограничение.
УМД с процедурными ОЦ (Oracle) Процедурные ограничения целостности в виртуальной базе представлены триггерами. Каждый триггер привязан к одной таблице или представлению. Для реализации процедурных ОЦ в УМД предлагается два варианта. В первом используется пакет DBMS_SQL. К УМД добавляется таблица описания триггеров, в которую записываются транслированные триггеры при загрузке таблицы из РМД в УМД. Трансляции в теле триггера подвергаются только SQL-выражения, а также ссылки на реальные таблицы. Остальной код на PL/SQL остается в прежнем состоянии. Для таблиц Таблица и Данные создаётся по одному триггеру на каждый из возможных двенадцати типов триггеров или четыре триггера (с фразой “inserting or updating or deleting”), которые будут находить соответствующие типы триггеров по таблице Триггер, проверять соответствие условию и исполнять тело триггера с помощью пакета DBMS_SQL. Если тело триггера представляет собой вызов процедуры, то для процедуры РМД создается аналог в схеме УМД с транслированным телом по тем же правилам, что и для триггера. В таблице Триггер хранится информация, аналогичная хранимой в словаре СУРБД.
Скачать презентацию Семантические базы данных Бессарабов Н В bes fpm kubsu
Семантические базы данных.ppt