НАУКА и ОБРАЗОВАНИЕ

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

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

В настоящее время на предприятиях, предоставляющих телекоммуникационные услуги, статистическая информация собирается в ряд независимых регистрирующих систем, в том числе и OLTP-системы (On-Line Transaction Processing – оперативная обработка транзакций). Каждая система, в основном, обеспечивает сбор, хранение и ввод данных в реальном режиме времени информации, связанной непосредственно с объектом мониторинга [14].

Обычно аналитические возможности OLTP-систем сильно ограничены, они используются для того, чтобы способствовать повседневной деятельности корпорации, и опираются на актуальные для текущего момента данные. Эксплуатацией каждой (а нередко и нескольких сразу) системы самостоятельно занимается конкретная служба предприятия. Некоторые показатели могут фиксироваться в нескольких регистрирующих системах одновременно, что при отсутствии четкой синхронизации процесса фиксации и согласованности данных может привести к формированию неверной статистики, и как следствие - к принятию ошибочных решений по его результатам её анализа. Еще одной причиной неэффективности проведения анализа непосредственно из регистрирующих систем является то, что  сложные аналитические запросы к оперативной информации тормозят текущую работу компании, надолго блокируя таблицы и захватывая ресурсы сервера оперативной регистрации [1, 3].

Для удобства аналитика данные должны быть организованны в единое хранилище и оптимизированы для анализа. Оптимизация для анализа предполагает наличие в структуре базы данных средств для представления бизнес процессов предприятия. Требуемая организация и оптимизация достигается в системах оперативной аналитической обработки – OLAP (Online Analytical Processing – оперативная аналитическая обработка). Большинство современных OLAP систем работает с удобно организованным и оптимизированным хранилищем данных - DW (Data Warehouse – хранилище данных) [9, 12, 13, 16, 17].

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

Одним из способов поступления информации в хранилище данных является загрузка из автоматизированных регистрирующих систем. Основными этапами этого переноса являются: извлечение, преобразование и загрузка (ETL – Extract Transform Load) [11]. Для достижения успеха при переносе данных из одной системы в другую крайне важно четко представлять процессы ETL, а также структуру исходного приложения и приложения назначения.

В общем приложения ETL извлекают информацию из исходной базы данных регистрирующей системы, преобразуют ее в формат, поддерживаемый хранилищем данных, а затем загружают в него преобразованную информацию. Для того чтобы инициировать процесс ETL, применяются программы либо модули извлечения данных для чтения записей в исходной базе данных и для подготовки информации, хранящейся в этих записях, к процессу преобразования [15]. Причем данные модули могут быть реализованы как в составе OLTP-системы, так и являться частью OLAP-системы.

Рис. 1 Обобщенная схема ETL процесса

В общем случае объекты, участвующие в процессе ETL можно представить в виде совокупности трёх областей, представленных на Рис. 1:

1.               источник данных(совокупность таблиц оперативной системы и дополнительных справочников, позволяющая создать многомерную модель данных с требуемыми измерениями);

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

3.               приёмник данных – само хранилище данных.

Движение данных от источника к приёмнику называют потоком данных.

Процесс перегрузки данных - это реализация потока данных от единственного набора данных источника до наборов данных Хранилища Данных.

Различают следующие классы процессов:

1.               По характеру загрузки:

-        процесс начальной загрузки (Initial load);

-        процесс обновляющей загрузки (Refreshing load).

2.               По виду источника данных:

-        источник данных – структурированный текстовый файл;

-        источник данных – стандартный классификатор оперативной системы, пользовательский классификатор;

-        источник данных – таблица фактов оперативной системы;

-        источник данных – хранилище данных.

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

1.               Извлечение – стадия извлечения данных из источника и загрузки их в промежуточную область.

2.               Выявление ошибок – данные проходят проверку на соответствие спецификации и потенциальную возможность загрузки в Хранилище Данных

3.               Преобразование – данные группируются и приводятся к виду, конформному модели данных Хранилища данных

4.               Распределение  – данные распределяются на несколько потоков зависимости от способа, которым они должны быть загружены в Хранилище данных

5.               Вставка - подготовленные данные поступают в хранилище данных.

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

-        Выгрузка из структурированного источника данных. Как частный случай - выгрузка из СУБД. Такой вид выгрузки не вызывает затруднений, возможно использование утилит СУБД, либо воспользоваться JDBC или ODBC

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

Преобразование заключается  в отсеивании ненужных данных и преобразовании структуры данных исходной системы к структуре данных хранилища.

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

Примером организации эффективно функционирующего процесса ETL может служить организация взаимодействия регистрирующих и аналитических программ реализованная в региональном филиале ОАО «ЮТК» «Связьинформ» Астраханской области. Модули, участвующие в ETL процессе, показаны на Рис. 2.

В качестве OLTP системы выступает автоматизированная система электронного документооборота по представлению услуг широкополосного доступа в Интернет [2].

В качестве хранилища данных – темпоральное хранилище данных телекоммуникационной компании.

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

Рис. 2. Архитектура взаимодействия програмно-аппаратных модулей участвующих в ETL процессе

Описание модулей, приведенных на Рис. 2 приведено в Таблица 1.

Таблица 1.  Описание программно аппаратных модулей, участвующих в ETL процессе

В данной схеме взаимодействия участвуют OLTP система и темпоральное хранилище данных.

Темпоральное хранилище состоит из куба данных, элементы которого поддерживают идентификаторы времени валидности. Каждое изменение в структуре измерений многомерной модели порождает создание новой структурной версии. Для сравнения данных двух структурных версий данные одной приводятся к структуре второй [4, 5, 6, 7, 8, 10].

Для формирования связей между структурными версиями предлагается использовать матрицы трансформации.

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

 – куб в структурной версии ;

 – куб в структурной версии  ;

 – куб  в структурной версии ;

 – куб  в структурной версии ;

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

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

Операция перемножения в данной формуле означает обычное перемножение матриц (так при перемножении  на  получаем ;  – количество комбинаций членов измерений без , -количество элементов , -количество элементов измерения ).

Возможны следующие варианты:

 – перегруппировка мощности элементов измерения;

 – объединение элементов измерения;

 – дробление элементов измерения;

 – порождение нового измерения с k элементами;

 – вырождение одного измерения (в частном случае – агрегация).

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

Преобразование всего куба данных  в  можно описать следующей формулой:

;

где:

N– количество различных измерений двух структурных версий, то

есть если и  количество измерений в структурных версиях  и , то ;

Механизм матриц трансформации возможно применить и в ETL процессе при преобразовании данных исходной системы в структуру хранилища данных. Алгоритм ETL процесса с использованием матриц трансформации представлен на Рис. 3.

Рис. 3.  Алгоритм ETL процесса с использованием матриц транформации

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

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

ЛИТЕРАТУРА

1.               Ладыженский Г. Технология «клиент-сервер» и мониторы транзакций // Открытые системы № 3, 1994.

2.               Мирошников Г.Г. Концептуальная модель базы данных автоматизированной системы электронного документооборота по организации подключения пользователей к сети Интернет по технологиям xDSL // Известия ОГТУ. Информационные системы и технологии. Орел, 2006. №1. Т 4. С 131-134.

3.               Рузинкевич М., Цикоцки А. Определение и выполнение потоков транзакций // СУБД № 2, 1995.

4.               Спандерашвили Д.В. Механизмы отслеживания изменений в многомерных структурах данных // Инфокоммуникационные технологии в науке и технике: Материалы международной научно-технической конференции. Ставрополь: СКГТУ, 2006. Ч 1. С. 160-162.

5.               Спандерашвили Д.В. Объектная модель Темпорально многомерных данных и ее реализация средствами реляционной СУБД // Известия ОГТУ. Информационные системы и технологии. Орел, 2006. №1. Т 4. С 210-215.

6.               Спандерашвили Д.В. Особенности построения системы сбора статистики телекоммуникационной компании // Информатика: проблемы, методология, технологии: Материалы региональной научно-методической конференции. Воронеж: ВГУ, 2005. Ч 2. С. 136-141.

7.               Спандерашвили Д.В. Темпорально многомерная модель для контроля динамики данных региональной компании // Проблемы стратегии регионального развития: Материалы всероссийской научной конференции. Тамбов: ТГУ, 2006. С. 80-84.

8.               P. Chamoni and S. Stock . Temporal Structures in Data Warehouse . Data Warehousing and knowladge discovery, 1999, pp. 353-358

9.               E.F. Codd, S.B. Codd, C.T. Salley . Providing OLAP (On-Line Analytical Processing) to User-Analysts: An IT Mandate . E.F.Codd & Associates, 1993.

10.            C.S. Jensen C.E. Dyreson . Glossary of Temporal Database Concepts .  Springer-Verlag A consensus, 1998, pp. 367-405.

11.            Ralph Kimball, Joe Caserta . The Data Warehouse ETL Toolkit . Wiley Press, 2004.

12.            A. Kurz . Data Warehousing-Enabling Tachnology . MITP-Verlag . Bonn, 1999.   

13.            C. Liu X.Wang . A Data Model for Supporting On-Line Analytical Processing . ACM, CIKM, 1996

14.            Masaharu Murozumi. A Challenge To A High Transaction Volume Client/Server DB2 Data Shared OLTP System . IBM Corporation, 2000.

15.            Erhard Rahm, Hong Hai Do. Data Cleaning: Problems and Current Approaches. IEEE Data Engineering Bulletin №23(4), 2000.

16.            Eric Thomsen . OLAP Solutions: Building Multidimensional Information Systems . John Wiley, 1997.

17.            P. Vassiliadis, T.Sellis . A Survey of Logical Models for OLAP Databases .  SIGMOD records, 1999