Применение онтологий для созданияи эксплуатации хранилищ финансовых данных Текст научной статьи по специальности «Компьютерные и информационные науки»

№ 4 (52) 2014

С. А. Мещерин, аспирант Московского физико-технического института, sergey.metcherin@gmail.com Д. Г. Какауридзе, аспирант Московского физико-технического института, kakauridze.d@gmail.com А. И. Волков, генеральный директор ЗАО «РДТеХ Разумные информационные технологии», аспирант Московского физико-технического института, Anatoli.Volkov@rdtex.ru Е. Ю. Пустозеров, руководитель направления ЗАО «РДТеХ Разумные информационные технологии»,

Москва, Evgeny.Pustozerov@rdtex.ru

Применение онтологий для создания и эксплуатации хранилищ финансовых данных1

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

Ключевые слова: хранилища данных, СУБД, онтологии .

введение

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

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

1 Работа выполнена при поддержке РФФИ, проект № 14-07-31288.

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

Хранилища данных и витрины данных

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

Хранилища данных обладают следующими свойствами:

• предметная ориентации — данные в ХД объединяются по предметным категориям;

• интегрированность — данные в ХД поступают из различных источников, при этом устраняются конфликты имен, обеспечивается целостность данных;

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

• временная зависимость — специфика бизнес-анализа — изменение данных во времени, поэтому в ХД могут храниться большие объемы исторических данных.

Далее рассмотрим характерные особенности хранилищ данных, которые отличают их от OLTP-систем.

• Производительность. В OLTP осуществляются только предопределенные операции, в ХД — произвольные, поэтому производительность предсказать сложно.

• В ХД загрузка данных производится регулярно с заданной периодичностью (ETL-процесс) и в больших объемах, в OLTP — в виде относительно небольших по объему согласованных транзакций. Как правило, ХД обеспечивает высокую актуальность данных, но с некоторой задержкой после их возникновения в автоматизированной системе.

• Для ХД характерна схема данных «звезда» (рис. 1), или «снежинка», способствующая оптимизации производительности запросов по нескольким «измерениям». В OLTP-системах обычно используется нормализованная схема, рассчитанная на обеспечение оптимизации согласованных DML-операций (update, insert, delete).

• Типичный запрос. В ХД запрос подразумевает обработку =105-106 строк. Пример запроса: «Найти суммарные продажи за месяц по всем клиентам». OLTP-запросы, как правило, более специфичны и подразумевают обработку нескольких строк из связан-

№ 4 (52) 2014

Таблицы измерений Таблицы измерений

Рис. 1. Схема «звезда», типичная для ХД

ных таблиц. Пример запроса: «Извлечь текущий номер заказа для данного клиента».

• Исторические данные. OLTP-системы очень часто хранят данные за несколько дней или недель для выполнения текущих транзакций, в ХД — сведения для бизнес-анализа, полученные за месяцы и годы.

Архитектура ХД изображена на рис. 2. Рассмотрим назначение представленных на схеме блоков.

Предварительные данные — предварительно вычисленные значения (например, агрегации за месяц), увеличивающие производительность. Данные из таблиц — данные, например, из тех же OLTP БД.

Метаданные — формат данных для согласования источников данных, периодичности пополнения (облегчение стандартизации источников данных). Часто для подготовки данных перед загрузкой используется промежуточная область — область предварительной обработки. Такой подход реализован в ХД Oracle Data Warehouse (DWH).

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

Применение витрин данных имеет следующие преимущества:

• аналитики видят и работают только с теми данными, которые им реально нужны;

№ 4 (52) 2014

Исследование

Рис. 2. Базовая архитектура хранилища данных

• целевая БД максимально приближена к конечному пользователю;

• витрины данных обычно содержат тематические подмножества заранее агрегированных данных, их проще проектировать и настраивать;

• для реализации витрин данных не требуется высокопроизводительная вычислительная техника.

виды хранилищ данных

В отношении архитектуры существует два основных подхода к построению хранилищ данных. Это так называемая корпоративная информационная фабрика (Corporate Information Factory, сокращенно CIF) Билла Инмона (Bill Inmon), описанная в [3, 4], и ХД с архитектурой шины (Data Warehouse Bus, сокр. BUS) Ральфа Кимболла (Ralph Kimball), описанная в [5]. На рисунке 4 представлен

подход, используемый в хранилищах данных с архитектурой CIF.

Работа такого хранилища начинается с процесса извлечения данных из источников, например транзакционных систем банка. После этого загружается реляционная база данных с третьей нормальной формой, содержащая атомарные данные. Получившееся нормализованное хранилище используется для того, чтобы наполнить информацией дополнительные репозитории данных, подготовленных для анализа: специализированные хранилища для изучения и «добычи» данных (Data Mining), а также витрины данных.

В качестве отличительных характеристик подхода Билла Инмона к архитектуре хранилищ данных можно назвать следующие:

• использование реляционной модели организации атомарных данных и многомерной — для организации суммарных данных;

Источники данных

Область предварительной обработки

ХД

Витрины данных

Пользователи

Операционная система

Операционная система

—к *

Файлы данных

Рис. 3. Архитектура ХД с витринами

Исследование

18

№ 4 (52) 2014

Подготовка данных

Представление

Витрина

продаж

Витрина

прибыли

Рис. 4. Нормализованное ХД с многомерными витринами итоговых данных (CIF)

• использование итеративного или «спирального» подхода при создании больших хранилищ данных, т. е. «строительство» хранилища не сразу, а по частям. Это позволяет при необходимости вносить изменения в небольшие блоки данных или программных кодов и избавляет от необходимости перепрограммировать значительные объемы данных в хранилище. То же самое можно сказать и о потенциальных ошибках: они также будут локализованы в пределах сравнительно небольшого массива без риска испортить все хранилище;

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

• ХД — это проект корпоративного масштаба, охватывающий все отделы и обслуживающий нужды всех пользователей корпорации;

• ХД — это не механическая коллекция витрин данных, а физически целостный объект.

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

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

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

В отличие от подхода Билла Инмона, многомерные модели строятся для обслуживания бизнес-процессов (которые, в свою оче-

19

№ 4 (52) 2014

Рис. 5. Подход Кимбалла, многомерное ХД

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

Первое существенное отличие между этими архитектурами — различные подходы к построению баз данных, составляющих основу хранилища. Если Ральф Ким-болл использует многомерную организацию баз данных (dimensional data bases) c так называемой архитектурой «звезда» как на стадии подготовки, так и презентации данных, то Билл Инмон комбинирует два подхода. В его модели атомарные данные организованы в реляционные базы и содержатся в нормализованном хранилище данных, причем суммарные данные доступны для

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

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

Второе принципиальное отличие этих двух подходов, отчасти вытекающее из первого, — физическая организация хранилища. Если у Инмона ХД — это физически целостный реально существующий объект, то хранилище Кимболла — скорее, «виртуальный» объект. Это коллекция витрин данных, которые могут быть разобщенными по нескольким измерениям.

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

онтологии и хранилища данных

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

ПРИКЛАДНАЯ ИНФОРМАТИКА /-

' № 4 (52) 2014

ХД

Реляционная СУБ,

Геоданные

Д

3D-модели

2D-модели

Аналитические данные

RDF-хранилище

Семантические данные

Импорт, преобразование координат

Ф

Модуль загрузки данных

GML-экспорт

KML-экспорт

3dsMax-экспорт

Импорт семантических данных

Рис. 6. Высокоуровневая архитектура хранилища с семантическими данными

диться в разных форматах — таблицы СУБД, плоские файлы, бинарные данные 3D-моде-лей и т. д. Таким образом, при проектировании современных хранилищ данных важно уметь работать с быстро изменяющимися гетерогенными данными, которые можно поделить на следующие группы:

• быстро меняющиеся финансовые данные (курсы валют, акций и т. д.);

• данные для расчета математических моделей и прогнозов;

• мультимедиаданные: графики, таблицы и т. д.

Для работы с такими данными единообразно из нескольких прикладных приложений необходимо описать смысл данных и взаимосвязи между ними на формальном языке [7]. В качестве такого языка хорошо подходит стек Semantic Web [8], в частности OWL-онтологии [9], для хранения схемы семантических данных и RDF для хранения собственно семантических данных. На рисунке 6 изображено, как выглядит высокоуровневая схема хранилища с использованием семантических данных.

Для работы с семантическими данными необходимо:

• создать онтологию предметной области;

• определить источники гетерогенных данных;

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

• организовать совместное использование реляционных и семантических данных.

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

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

2 http://ivfiztex.ru/ontologies/2014/2/person_ account.owl.

3 https: //developers.facebook.com/docs/graph-api/ reference/.

№ 4 (52) 2014

Class hierarchy Class hierarchy (inferred)

I сй» rwrwchy: Женщ«* ШВ№3

M*ll»l

Y ©Thing

Должность

местоположение

С Образование

©работа

▼ ©Счет

■ Страна

▼ пчеповек

Женщина

«Мужчина

Рис. 7. Онтология, описывающая клиента банка

данные в формате JSON и в рамках своей схемы данных, которая описывается в Graph API. Поэтому необходимо преобразовать данные так, чтобы они соответствовали онтологии, принятой в СУБД как по формату (RDF), так и по схеме данных. В целом для импорта гетерогенных данных в онтологию можно воспользоваться несколькими подходами:

1) разработать программу-конвертер, которая будет принимать на вход данные Facebook в JSON или ином формате и давать на выходе RDF-тройки, соответствующие онтологии;

2) выгрузить данные в формате RDF-троек «как есть» и использовать средства отображения данных из языка OWL, такие как owl: inverseFunctionalProperty, owl: equivalentClass и др. Такой подход работает, только если внешний источник поддерживает выгрузку данных в форматах Semantic Web (RDF и OWL). Подробнее об этом способе см. [10].

Второй способ видится предпочтительным, так как использует встроенные средства языка OWL и требует минимума ручной работы, однако далеко не все сервисы поддерживают выгрузку данных в формате Semantic Web. Поэтому для импорта данных из Facebook необходимо использовать первый подход. С примером программы, которая получает семантические данные из Facebook, можно ознакомиться по представленной ссылке4. Программа собирает данные о социальных связях задан-

4 http://1drv.ms/1fsYZ7U

Листинг 1

@prefix nsl: <http: //ivfiztex.ru/

ontologies/2 014/2/person_account.

owl#> .

ns1:698331935 a nsl :Man ;

ns1:hasFirstName "Сер-

re^'AAxsd:string ;

ns1:hasLastName " Меще-

рин"ллxsd:string .

ного пользователя и создает RDF-тройки, совместимые с онтологией, разработанной на первом этапе. Пример экспортируемых данных в формате Turtle представлен на листинге 1.

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

Основная проблема, возникающая при загрузке данных в хранилище, это осуществление связи сущностей ХД и сущностей онтологии. Например, запись из справочника клиентов банка необходимо связать с соответствующим набором утверждений в онтологии. Один из вариантов решения данной проблемы — использование сквозных идентификаторов (ключей) для объектов, которые будут одинаковыми и в ХД, и в семантических данных. Заметим, что в рамках концепции Semantic Web каждый объект семантических данных обязан иметь IRI6, т. е. все имена в семантических данных являются глобальными. При этом допускается наличие у одного и того же объекта семантических данных нескольких IRI. Логично в качестве уникальных ключей записей БД и объектов использовать IRI из онтологии.

5 http://docs.oracle.com/cd/E11882_01/appdev. 112/ e25609/sdo_rdf_concepts. htm#RDFRM100.

6 http://en.wikipedia.org/wiki/Internationalized_ Resource_Identifier.

№ 4 (52) 2014

После того как семантические данные из онтологии загружены в ХД и должным образом связаны с записями ХД посредством IRI, можно использовать их непосредственно в запросах к ХД. С помощью Oracle можно применять SPARQL-запросы непосредственно в SQL-запросах (см. оператор SEM_MATCH7). Возвращаясь к примеру c Facebook, с помощью данных по друзьям клиентов построить отчет с рекомендациями по потенциальным заемщикам, где данные о социальных связях между заемщиками получены из внешних источников (Facebook Graph API).

Заключение

В статье рассмотрены вопросы организации хранилищ данных с особенностями, выделяющими их среди обычных СУБД. Авторы пришли к выводу, что «традиционные» хранилища данных могут быть существенно обогащены семантическими данными из открытых источников, позволяя взглянуть на данные с другой стороны и осуществлять поддержку в принятии оперативных и управленческих решений. Было показано, что для импорта гетерогенных данных в хранилище и их последующего анализа хорошо подходят технологии Semantic Web, в частности OWL-онтологии в качестве схе-

7 http://docs.oracle.com/cd/E11882_01/appdev.112/ e25609/sdo_rdf_concepts. htm#RDFRM593.

мы данных и RDF-тройки в качестве самих данных.

Список литературы

1. Волков А. И, Рейнгольд Л. А. Открытые данные: проблемы и решения // Прикладная информатика. 2014. № 3 (51). С. 5-12.

2. Волков А. И. Методологические и программно-технологические аспекты внедрения процессного управления в ИТ-компании // Прикладная информатика. 2014. № 2 (50). С. 6-13.

3. Inmon Bill. Building the Data Warehouse. QED/Wiley, 1991.

4. Drewek K. Data Warehouse: Bill Inmon's Vision // http://www.b-eye-network.com/view/727.

5. DrewekK. Data Warehouse: Ralph Kimball's Vision // http://www.b-eye-network.com/view/713.

6. Drewek K. Data Warehousing: Similarities and Differences of Inmon and Kimball // http://www.b-eye-network.com/view/743.

7. Мещерин С. А., Кириллов И. А., Клименко С. В. Разработка интегрированной системы управления кризисной ситуацией на базе формализованной онтологии // Труды Международной научной конференции MEDIAS2012, 7-14 мая 2012 г., Лимассол, Республика Кипр: Изд. ИФТИ. С. 276-283.

8. Semantic Web Stack // http://en.wikipedia.org/wiki/ Semantic_Web_Stack.

9. Web Ontology Language // http://en.wikipedia.org/ wiki/Web_Ontology_Language.

10. Ontology alignment // http://en.wikipedia.org/wiki/ Ontology_alignment.

S. Mescherin, Graduate Student, Institute of Physics and Technology, Moscow, sergey.metcherin@gmail.com

D. Kakauridze, Graduate Student, Institute of Physics and Technology, Moscow, kakauridze.d@gmail.com

A. Volkov, Master Degree, CEO, CJSC RDTEX, Graduate Student, Institute of Physics and Technology, Moscow, Anatoli.Volkov@rdtex.ru

E. Pustozerov, Chief of Direction, CJSC RDTEX, Moscow, Evgeny.Pustozerov@rdtex.ru

Using ontologies for creation and operation of financial data warehouses

This article is dedicated to analytical review of data warehouses technology and loading of heterogeneous data into it. Article describes how OWL ontologies could be used to facilitate operations with heterogeneous data. Our approach extensively uses ontology during loading external data phase and during obtaining analytical data phase. Keywords: data warehouses, DBMS, ontologies.