Оглавление
1. Семантические базы данных
1.1 Обеспечение безопасности семантических баз данных
1.2 Средства обеспечения безопасности
2. Определение уровней безопасности элементов, классов, свойств, индивидов и триплетов онтологий
2.1 Пример контроля результатов логических выводов в СБД
3. Предоставление доступа к хранилищам данных
Заключение
Список используемых источников
1. Семантические базы данных
Понятие семантической БД
Базой данных (БД) называется организованная в соответствии с определёнными правилами совокупность сведений об объектах, процессах, событиях или явлениях, относящихся к некоторой предметной области, теме или задаче. Она организована таким образом, чтобы обеспечить информационные потребности пользователей, а также эффективное хранение этой совокупности данных, как в целом, так и любой её части.
Под семантической БД (СБД) понимается база данных, в которой хранятся онтологии, семантические метаданные и множество логических правил. Она может быть описана, как DBS = {O, M, R}, где O - онтология, М - семантические метаданные, R - множество логических правил.
Множество логических правил R используется для получения логических выводов на основе известных данных. Данное множество может быть разделено на два подмножества R = {R1, R2}, где R1 - множество онтологических логических правил, включённых в язык описания онтологий; R2 - множество пользовательских логических правил, созданных разработчиками и/или пользователями для получения возможных логических выводов.
Основные элементы семантических БД показаны на рисунке 1.6.
Рисунок 1.6. Структура семантической базы данных
В семантических БД онтологии, метаданные представляются в виде множеств RDF-триплетов, хранящихся в RDF-хранилищах (RDF stores).
Изучению семантики данных в базах данных препятствует некоторая недовыясненность сути предмета, отсутствие единых признанных подходов и терминологическая путаница. Определенные затруднения вызывает увеличение количества предметных областей, с которыми необходимо работать, и неизбежное усиление роли лингвистического аспекта.
Полезно заимствовать опыт тех областей знания, в которых давно занимаются семантикой. Это лингвистика, исследующаяся естественные языки (ЕЯ), и теория языков программирования.
Прежде всего, отметим несоответствие некоторых терминов в лингвистике и информатике. Лингвисты выделяют два противопоставляемых вида элементов семантики - значения и смыслы. Значение лингвистического знака понимается как нечто стабильное, что можно сначала установить, выяснить, а затем знать. Смысл приходится всё время искать, устанавливать, разгадывать. В информатике термин "значение" уже занят. Говоря "переменная имеет значение" подразумеваем не семантику этой переменной, а присваивание ей конкретного экземпляра данных, или означивание, или создание экземпляра переменной, содержащего этот элемент данных. Поэтому элементы семантики мы всегда будем называть смыслами, а "стабильность" или "контекстность" или "вариативность" смыслов будем задавать через классификацию смыслов или вводя в них дополнительные свойства.
Давно известно, что значения и смыслы -- это внеязыковые сущности. В частности, для перевода с одного естественного языка на другой ЕЯ может создаваться специальный язык функций для представления семантики, в который транслируются фразы исходного языка. А уже с этого промежуточного языка осуществляется трансляция на второй ЕЯ. Тезис о внеязыковой природе смыслов мы трансформируем для баз данных в несколько смягчённую форму как утверждение о возможности разделения данных и смыслов.
В языках программирования обратим внимание на возможность выделения нескольких видов семантики: операционной (описывается в терминах перехода состояний некоторой абстрактной машины), денотационной (в языке для представления семантики используются математические структуры, позволяющие установить возможность вычисления конструкций языка посредством специализированных функций), дедуктивной (позволяет доказывать свойства программ, в первую очередь их правильность), трансляционной (использует правила перевода на язык, семантика которого известна), основанной на таблицах решений и т.д.
Вернемся к терминологии баз данных. Существует безосновательная, но устойчивая традиция выделять некоторые модели и базы данных как семантические (и мы тут не без греха). Так модель "сущность-связь" считается семантической моделью, по-видимому, по сравнению с табличными моделями данных. Однако, семантика, обычно ограниченная, есть в любых моделях данных. Поэтому, еще в 1988 году Э. Кодд отметил, что "ярлык "семантическое" не должен интерпретироваться в каком-либо абсолютном смысле". В тех же табличных базах семантику определяют, в частности, ключи и ограничения целостности. В базах данных с декларативными языками всегда реализуется операционная семантика, представляемая, например, планами исполнения SQL. Так что следует говорить только о большей или меньшей насыщенности моделей и баз данных семантикой.
Как же отделить элементы семантики, хранимые в базе, от обычных данных? По очень простому признаку: элементы семантики, они же смыслы, обладают активностью. Данные всегда пассивны.
Поясним сказанное на простом примере. Пусть, необходимо выбрать все записи из таблицы, например, инструкцией SELECT * FROM emp. Очевидно, СУБД должна сначала проверить существование таблицы emp по словарю и, может быть, установить, имеются ли у действующего пользователя необходимые права на эту таблицу. Если таблица не существует или недоступна, выдать сообщение об ошибке. В противном случае, установить список столбцов emp и только после этого приступить к выборке данных. Как много делается того, что прямо не было указано! Всё это обеспечивает активность, которой обладают метаданные.
Ещё один пример. Пусть мы вставляем строку в таблицу, имеющую первичный ключ. Поскольку ограничение "первичный ключ" активно, СУБД сначала проверит уникальность вводимого значения ключа, и только если это условие выполнено, сделает то, что ей приказали - введёт запись.
Заметим, что активность смыслов выводит модели данных со смыслами за рамки обычных чисто алгебраических моделей данных.
RDF-хранилища
Семантические БД строятся на основе RDF-хранилищ. Под RDF-хранилищем (RDF-Stores, RDF-triple store) понимается информационная подсистема, предназначенная для хранения и предоставления доступа к RDF-данным(триплетам).
По своей архитектуре RDF-хранилища делятся на два типа: реальные RDF-хранилища (native stores) и RDF-хранилища, поддерживаемые реляционными СУБД (DBMS-backed stores).
Реальные RDF-хранилища (native stores) полностью реализуют ядро БД, которое оптимизированно для обработки RDF-данных и работает независимо от любой другой системы управления базой данных (СУБД). В этих хранилищах данные хранятся непосредственно в файловой системе, в одном файле или разделяются на несколько файлов.
RDF-хранилища, поддерживаемые реляционными СУБД (DBMS-backed stores), используются для выполнения хранения и поиска данных существующих СУБД.
Различаются два вида модели хранения: общая схема и схема конкретной онтологии.
Общая схема RDF-хранилища может состоять из различных таблиц для хранения триплетов, например таблицы, состоящей из трёх столбцов: субъекта, предиката и объекта. При этом необходимо соблюдать принципы нормализации схемы такой БД путём хранения всех URI-идентификаторов и литералов в отдельных таблицах. Такой подход с использованием общей схемы обладает гибкостью представления схемы хранения, однако требует объединения большого количества таблиц для ответа на сложные запросы.
Подход на основе схемы конкретной онтологии заключается в хранении триплетов в наборе специальных таблиц, структура которых отражает структурные свойства конкретной онтологии. Можно выделить три различных вида схем:
§ Для каждого класса онтологии (горизонтальное представление) создаётся отдельная таблица, каждый столбец которой соответствует одному свойству класса, а каждая строка - одному экземпляру класса. Основным недостатком такого подхода является необходимость реструктуризации таблиц БД при изменении структуры онтологии.
§ Для каждого предиката создаётся отдельная таблица (вертикальное представление), содержащая два столбца: для субъекта и объекта. При использовании такого подхода значительно понижается эффективность выполнения сложных запросов в связи с необходимостью объединений таблиц, соответствующих свойствам, используемым в данном запросе.
§ Гибридные схемы - сочетают преимущества обеих предыдущих подходов, при этом каждый класс представляется в виде таблицы, которая содержит только идентификаторы экземпляров данного класса.
Известными реальными RDF-хранилищами (native stores) являются такие системы, как: 4/5store [46], AllegroGraph [47], OWLIM [48], А примерами RDF-хранилищ, основанных на реляционных СУБД, являются следующие: 3store [49], Jena SDB [39], Oracle 11g [50], а также гибридные хранилища - RedStore [51], Sesame [38], Virtuoso [52], BigData [53].
Области применения RDF:
объединение данных из различных источников, не прибегая к созданию специализированных программ.
необходимость дать другим доступ к вашим данным.
необходимость децентрализовать ваши данные так, чтобы ими всеми не "владел" кто-то один.
необходимость сделать что-то особенное с большими объёмами данных - вводить, извлекать, просматривать, анализировать, выполнять поиск, и т.д. Вы хотите создать (либо использовать готовый) универсальный инструмент, который бы позволял вам всё это делать, основываясь на модели данных RDF (имеющей то преимущество, что она не привязана к закрытым технологиям хранения и представления данных - в отличие от диалектов СУБД).
Имена бывают двух типов. Глобальные имена, имеющие всюду один и тот же смысл, всегда имеют вид URI (Универсальных Идентификаторов Ресурсов). Синтаксис (формат) URI может быть таким же, как у адреса веб-сайта; вы можете встретить RDF-файлы, где используются URI структурой напоминающие URL; такие URI задают глобальные имена для каких-нибудь сущностей. Тот факт, что это похоже по виду на веб-адрес - чистое совпадение. Может быть, действительно существует веб-сайт с таким адресом, а может быть, его не существует, - это не имеет значения. Есть и другие типы URI, не начинающиеся с http:. URN - один из подтипов URI, и он используется, например, для идентификации книг по их ISBN-номеру и т.п. Другой универсальный тип URI - это TAG; пример такого URI - tag:govtrack.us,2005:congress/senators/frist. URI используются для глобальных имён потому, что они позволяют разбить пространство всех возможных имён на блоки, за которыми закреплены владельцы.
Это очень важный принцип: какого бы типа они ни были, URI используются в RDF-документах только в качестве имён сущностей, и больше ни для чего.
Так как URI могут быть довольно длинными, то в форматах, используемых для представления RDF, они обычно сокращаются, используя перенятый из XML механизм "пространств имён". Именно поэтому в именах: john, :hasMother и других сущностей в приведённых примерах стоят двоеточия - они означают, что используются сокращённые имена. В примерах им соответствуют полные имена http://www.example.org/#john, http://www.example.org/#hasMother и т.д.
При записи URI обычно заключаются в угловые скобки, чтобы их можно было отличить от сокращённых имён.
Есть два взаимодополняющих способа рассматривать информацию, представленную в RDF. Первый способ - считать её набором утверждений, как в примерах выше: каждое утверждение представляет собой факт. Второй способ - считать её графом.
Граф - это то же самое, что и сеть. Граф состоит из узлов, соединённых рёбрами. Например, в Интернете узлы - это компьютеры, а рёбра - соединяющие их сетевые шнуры. В RDF узлы - это имена (но не сами сущности), а рёбра - утверждения. Каждая стрелка (ребро) - это RDF-утверждение: имя у начала стрелки - это подлежащее утверждения, имя у конца стрелки - его дополнение, и имя у самой стрелки - сказуемое[5]. Когда RDF представлен в виде графа, он содержит всю ту же информацию, что и выписанный в виде троек-утверждений; но графическое представление позволяет человеку легче увидеть структуру описываемых данных.
Для хранения RDF-данных используются два основных вида хранилищ: специализированные (native, "родные", "нативные") и не специализированные (non-native). Специализированные хранилища позволяют достичь большей степени оптимизации, но более трудоёмки в проектировании, так как строятся специально для работы с RDF. Остальные хранилища более просты в проектировании (например, за счёт использования механизмов реляционных СУБД или решений NoSQL), но менее оптимизированы под работу с RDF. Специализированные хранилища делятся по способности оперировать с данными, лишь целиком находящимися в оперативной памяти (in-memory) или же способные использовать и внешнюю память (например, жёсткий диск). Системы для работы с RDF разрабатываются как в рамках исследований, так и для производственного использования. К основным специализированным хранилищам, пригодным для производственного использования, относятся:
решения от Oracle
сервер приложений Virtuoso
4Store
Stardog
Blazegraph (ранее Bigdata)[7]
GraphDB (ранее OWLIM)
Sesame
Jena TBD
Allegrograph
Языки запросов к семантическим данным
Существуют много языков запросов к семантическим данным, таких, как N3QL [26], RDFQ [40], RDQL [41], SeRQL [42] и SPARQL [43].
Наиболее распространённым языком запросов к семантическим данным является язык SPARQL (Semantic protocol and RDF query language) разработанный организацией W3C. В сравнении с другими языками, SPARQL обладает следующими преимуществами [44]:
§ используется для представления запросов к разнообразным источникам данных независимо от того, хранятся эти данные непосредственно в RDF или представляются в виде RDF с помощью промежуточного программного обеспечения.