Технология использования метаописаний для формирования хранилищ данных и анализа многомерных данных

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

Редко встречается ситуация, когда данные, характеризующие целую предметную область, хранятся в одном месте, чаще они разделены, и пользователи тратят много времени на ручной поиск, сбор и сопоставление релевантной информации, вместо того, чтобы использовать полученную информацию в непосредственной деятельности [1]. Таким образом возникает проблема интеграции данных: они могут манипулироваться различными системами управления базами данных (СУБД), быть противоречивыми, несогласованными, не иметь единого логического взгляда, содержать значительную часть информации, неважную для анализа и тем самым его замедлять.

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

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

• 1.    Структура ХД

• 2.    Инструменты извлечения, преобразования и загрузки данных

Основными составляющими структуры типичного ХД являются таблица фактов (fact table) и таблицы измерений (dimension tables) [3]. Таблица фактов является основной таблицей ХД. Как правило, она содержит сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться, технически это уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Чаще всего это целочисленные значения либо значения типа «дата/время». Помимо этого таблица фактов содержит одно или несколько числовых полей, на основании которых в дальнейшем будут получены агрегированные данные.

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

Существуют 2 основные схемы типичного ХД: «звезда» и «снежинка». Схема звезда – это логическая модель организация ХД, когда таблица фактов непосредственно соединена со всеми зависящими от неё таблицами измерений. Недостатком схемы «звезда» является неудобство работы с иерархическими измерениями, т.е. когда вся информация об измерениях содержится в одной таблице. Это вызывает рост избыточности и повышает вероятность возникновения противоречий. Поэтому для более эффективной работы с иерархическими измерениями используется модификация схемы «звезда», которая получила название «снежинка».

Схема снежинка (snowflake schema) – это логическая модель организации ХД. Особенностью схемы «снежинка» является то, что таблицы измерений могут быть соединены с таблицами измерений других иерархических уровней непосредственно, минуя таблицу фактов. Если же хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема ХД носит название «снежинка». Данную схему рекомендуется использовать при наличии иерархии измерений.

Недостатками схемы «снежинка» по сравнению со схемой «звезда» является более трудная для понимания и реализации структура данных, а также более сложная процедура добавления значений в измерения, а ее преимуществом – большее соответствие представлению данных в многомерной модели, намного более низкая вероятность появления ошибок несоответствия данных и большая (по сравнению со схемой «звезда») компактность представления иерархических данных, поскольку все значения измерений представляются только один раз [4].

Следует отметить, что даже при наличии иерархических измерений с целью повышения скорости выполнения запросов к ХД нередко предпочтение отдается схеме «звезда» [5].

После создания структуры ХД его следует заполнить тематическими данными. Для этого можно использовать встроенные возможности СУБД или, что предпочтительнее, специализированное ПО – ETL. Это инструменты для извлечения, преобразования и загрузки (extraction, transformation, loading). Как правило, с качественными коммерческими решениями в области ХД поставляется свой инструментарий для такого рода задач. Под аббревиатурой ETL понимается составной процесс переноса данных одного приложения или автоматизированной информационной системы в другие. Процесс ETL состоит из трех основных стадий:

• 1.    Извлечение данных

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

• -    извлечение данных при помощи приложений, основанных на выполнении SQL-команд. Эти приложения функционируют совместно с другими приложениями систем источников данных;

• -    извлечение данных при помощи встроенных в СУБД механизмов импорта/экспорта данных. Использование таких механизмов, как правило, обеспечивает более быстрое извлечение данных, чем с помощью команд SQL;

• -    извлечение данных с помощью специально разработанных приложений.

• 2.    Преобразование данных

• 3.    Загрузка данных

• 3.    Анализ данных

• 4.    Использование метаописаний для формирования ХД

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

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

Конечной целью использования ХД является анализ данных и представление результатов этого анализа в виде, удобном для восприятия и принятия решений. После завершения этапа загрузки становится возможным проведение аналитических исследований с использованием тематического ПО, учитывающего специфику конкретной предметной области. Основополагающим видом анализа в ХД является OLAP анализ. Основная идея OLAP заключается в построении многомерных кубов, которые будут доступны для пользовательских запросов [6]. Существующие подходы анализа многомерных данных предполагают использование ПО ориентированного на структуру ХД конкретного производителя.

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

Под метаописанием БД понимаются заданная по определённым правилам информация, описывающая структуру этой БД, и способы взаимодействия пользователя с БД. Элементы метаописаний состоят из секций о таблицах, их полях, связях между таблицами и представлениях [8]. Они позволяют описать любую БД, использующую современную СУБД, формируя связующее звено между БД и ПО, достаточное для их совместной работы. Применение технологии метаописаний БД открывает возможность использования специализированного ПО для анализа различных ХД, удовлетворяющих ряду требований и управляемых одной или разными СУБД (без перекомпиляции ПО). Неоспоримым преимуществом данной технологии также является сокращение сроков создания реальных информационных систем по сравнению с традиционными подходами, связанными с описанием объектов ХД и связей между ними средствами визуального программирования или в коде приложения.

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

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

Для OLAP анализа многомерных данных с помощью технологии “кросс-таблиц” разработано универсальное ПО “MDAttr” [9], которое выступает в качестве клиента к ХД и алгоритмы которого используют метаописания ХД для работы с его измерениями. Система реализует:

• -    унифицированный доступ к ХД;

• -    простоту настройки и хорошие времена отклика при работе с агрегированными данными;

• -    анализ набора числовых показателей, которые могут быть собраны в различных разрезах, т.е. могут зависеть от различного числа характеристик;

• -    многопользовательский доступ к данным;

• -    экспорт данных в Microsoft Excel для дальнейшей обработки.

Хранилище данных может быть сконфигурировано администратором под конкретный набор показателей и разрезов, а ПО “MDAttr” дает пользователю гибкий доступ к данным хранилища с использованием интуитивно-понятного интерфейса, построенного по принципу систем многомерного анализа данных (OLAP). Пользователь имеет возможность выбирать интересующие его данные, после чего эти дан- ные сохраняются в электронных таблицах для дальнейшего анализа средствами специализированных статистических пакетов. Для использования данного ПО должны соблюдаться определённые соглашения:

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

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

H i = T0 m *12 + 12 - dT m ,                                (1)

где Hi обозначает код интервала времени;

T0_m - начало интервала в месяцах (T0_m = Год *12 + №Месяца , при этом январю соответствует 0);

dTm – протяжённость интервала времени в месяцах (год – 12, полугодие – 6, квартал – 3, месяц – 1).

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

• -    Значения показателей должны храниться в числовых полях.

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

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

Система может быть настроена на использование любых таблиц, созданных с соблюдением описанных соглашений.

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

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