Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

В основе Semantic Web лежит Linked open data (связанность открытых данных).

1. Linked Open Data

Linked Open Data (LOD) – проект, целью которого является наполнение сети Интернет данными в стандартных форматах Semantic Web, а так же установление связей между данными из различных источников.

Тим Бернерс-Ли сформулировал следующие четыре принципа связанных данных:

• использование URI для идентификации сущностей;

• использование HTTP URI, чтобы эти сущности могли быть найдены людьми;

• при обращении по URI предоставлять полезную информацию о сущности, используя стандартизованные форматы (RDF, SPARQL);

• предоставлять так же другие, связанные URI, для облегчения поиска.

На рисунке 4 показаны самые крупные проекты – связанных данных.

1. Крупные проекты Linked Data

В параллели с эволюцией Semantic Web и Linked Data развивались и различные NoSQL (нереляционные) базы данных. И эти самые БД и стали основой в технологическом прорыве Semantic Web и предоставления связных данных.

1. Нереляционные базы данных

Аббревиатура «NoSQL» появилась 11 июня 2009 года на конференции, посвященной «распределенным нереляционным базам данных с открытым исходным кодом» в Сан-Франциско, организованной Йоханом Оскарссоном (Oohan Oskarsson), разработчиком программного обеспечения.

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

Для начала отметим очевидный факт: базы данных NoSQL не используют язык SQL. Некоторые из них имеют свой язык запросов, похожий на SQL. К таким языкам относится SPARQL, CQL, RQL, RDQL.

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

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

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

Две основные причины применения технологии NoSQL. Первая причина – необходимость обеспечить доступ к данным, объем которых и требования к производительности вынуждают использовать кластеры; вторая причина – повысить производительность разработки приложений с помощью более удобного способа обеспечения обмена данными [9].

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

1. хранилище ключ-значение (key-value) – Berkeley DB, MemcacheDB, Redis, Riak, Amazon DynamoDB и др. (обычно хранят данные в памяти);

2. хранилище семейств колонок (Column-oriented) – Apache Cassandra, Apache Accumulo, Hypertable , SimpleDB и др. (для очень больших объёмов данных);

3. документо-ориентированные СУБД – BaseX, Clusterpoint, Apache Couchbase, eXist, Jackrabbit, Lotus Notes and IBM Lotus Domino LotusScript, MarkLogic Server, MongoDB, OpenLink Virtuoso, OrientDB, RavenDB, SimpleDB, Terrastore и др. (предназначены для хранения иерархических структур данных – документов);

4. БД на основе графов – AllegroGraph, DEX, FlockDB, InfiniteGraph, Neo4j, OpenLink Virtuoso, OrientDB, Pregel, Sones GraphDB, OWLIM, OntoQuad RDF Server и др.

Рассмотрим каждый тип NoSQL СУБД и выявим отличия.

Хранилище ключ-значение является основным решением из семейства NoSQL. Этот тип БД работает с данными типа ключ-значение. Здесь нет места ни структуре, ни связям. После подключения к серверу приложение может задать ключ и его значение, а в последствии получать эти данные по запросу. Такие СУБД используются для быстрого сохранения базовых данных. Они быстры, работоспособны или легко масштабируемы (подходят для хранения сессий, кэша, счётчиков посещений или просмотров).

Распределённое хранилище – следующий шаг после СУБД типа ключ-значение. Такие СУБД предназначены для создания коллекции из одного или нескольких пар ключ-значение, которые в сумме соответствуют одной записи. В отличие от привычных таблиц в реляционных моделях, эти СУБД не требует предварительного описания структуры данных. Каждая запись состоит из одного или нескольких столбцов содержащих данные, а каждый столбец разных записей может хранить разные типы данных. В целом, распределённое хранилище представляется как двумерный массив, где каждый ключ (запись) содержит одну или несколько пар ключ-значение привязанных к нему. Такая система позволяет хранить и использовать большие объемы неструктурированных данных. Одна из отличительных особенностей документо-ориентированных хранилищ это то, как они работают с другими приложениями: поддержка JSON, поддержка JavaScript.

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

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

Существуют и гибридные NoSQL СУБД, такие как Hadoop, HBase. Эти СУБД объединяют в себе традиционные структурированные данные (реляционные БД) и неструктурированные.

Рассмотрим языки описания знаний (метаданных и онтологии), принятых W3C. Для этого можно рассмотреть схему логическую зависимость языков описания знаний представленную на рисунке 3.

					OWL
				RDF Schema
		RDF/XML, N3, RDFa, Turtle, N-triples, JSON LD, RDF/JSON
	XML, JSON, INI, TREE

1. Логическая структура языков описания онтологии и метаданных

Нижние элементы структуры служат форматами для обмена данными. Самые распространенные XML и JSON.

XML (Extensible Markup Language) – расширяемый язык разметки, основанный на тэгах для описания иерархической структуры с помощью линейного синтаксиса. Визуально структура XML-файла представляется в виде дерева элементов, записанных строго определенным образом, некоторой предметной области. Элементы в XML описываются тегами, так же как и в HTML.Описание структуры XML-документа осуществляется с помощью языка XSD (XML Schema) [11]. Пример кода XML:

<?xml version="1.0" encoding="UTF-8" ?>

<logs_files>

<logs>

<Date_create>2014-07-18 23:06:19</Date_create>

<catalog>C:/Documents and Settings/doronin</catalog>

<date_time_use>17.07.2014 17:25</date_time_use>

<domen>DAP</domen>

<name_file>NTUSER</name_file>

<size_file> 1835008</size_file>

<type_file>.DAT</type_file>

</logs>

</logs_files>

JSON (JavaScript Object Notation) – простой формат обмена данными, основан на подмножестве языка программирования JavaScript. Представляет собой одну из двух структур: набор пар ключ-значение или упорядоченный набор значений. За счёт своей лаконичности по сравнению с XML, формат JSON подходит для создания более сложных структур. Пример того же кода что и для XML, записанного в JSON:

{

"logs_files": {

"logs": {

"Date_create": "2014-07-18 23:06:19",

"catalog": "C:/Documents and Settings/doronin",

"date_time_use": "17.07.2014 17:25",

"domen": "DAP",

"name_file": "NTUSER",

"size_file": " 1835008",

"type_file": ".DAT"

}

}

}

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

1. Процесс формирования и интеграции данных в NoSQL БД

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

На начальном этапе происходит накопление знаний автоматизированными системами (АСУ, АИС и прочие). Далее с помощью модуля или веб-приложения происходит сериализация данных из автоматизированных систем в NoSQL хранилище, где происходит десериализация. Все десериализованные данные представлены одним форматом в зависимости от типа NoSQL хранилища (JSON,RDF,XML,INI, TREE). После из NoSQL хранилища производится выборка необходимых данных. Эти данные преобразуются в форматы принятые W3C. Для JSON применяется расширение JSON LD или RDF/JSON, для XML – RDF/XML. При преобразовании к каждому объекту присваивается URI. Далее используя RDF Schema и OWL можем связать наши данные в семантической паутине с одинаковыми URI.

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

1. СИСТЕМА СБОРА И АНАЛИЗ ИНФОРМАЦИИ О РАБОТЕ ПОЛЬЗОВАТЕЛЯ

Работа над системой «Сбора и анализ информации о работе пользователя» началась во время прохождения летней практики после окончания 3 курса в компании Дальаэропроект. В ходе прохождения данной практики была разработана система мониторинга действий пользователя. Функционал данной системы заключался в том, что во время работы запускался командный скрипт, который формировал список всех объектов файловой системы на компьютере пользователя. Далее протокол выполнения помещался в отдельный текстовый файл на сервере.

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

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

1. Система контроля действия пользователя

Рассмотрим основной функционал необходимый для доработки программного комплекса:

Мониторинг рабочего стола является одним из основных способов контроля действий пользователя. Реализуется двумя способами – администратор видит всё то, что сейчас видит пользователь, или просматривает сохранённые снимки экрана. Они могут быть использованы как вещественные доказательства нарушения трудового договора.

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

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

Характеристики

Список файлов ВКР