Создание хранилища данных и системы бизнес-аналитики

• Оглавление

Введение

Глава 1: Анализ средств реализации аналитической отчетности в различных средах. Выбор оптимального варианта решения поставленной задачи.

Глава 2: Архитектура и технология функционирования системы.

2.1 Общие сведения

2.1.1 Извлечение, преобразование и загрузка данных

2.1.2 Хранение данных

2.1.3 Анализ данных

2.2 Инструментальные средства

2.2.1 Серверные компоненты

2.2.1.1 Oracle Database для реализации хранилища данных

2.2.1.2 Oracle Business Intelligence Suite Enterprise Edition

2.2.2 Клиентские приложения

2.2.3 Метаданные

2.2.4. Доступ к данным и обработка запросов Глава 3

3.1 Анализ существующих систем-источников данных

3.2 Проектирование хранилища данных Глава 4: Практическая реализация

4.1 Создание структуры хранилища.

4.2 Разработка ETL-процесса

4.3 Разработка и настройка BI-системы

4.3.1 Создание физического слоя

4.3.2 Создание бизнес-модели

4.3.3 Создание презентационного слоя

4.3.4 Пользовательский интерфейс

4.3.4.1 Создание тестового отчета.

4.3.4.2 Создание региональной карты

4.3.5 Механизм работы системы

4.3.5.1 Механизм работы системы с точки зрения пользователя

4.3.5.2 Механизм работы системы с точки зрения платформы Заключение Список используемой литературы Приложение 1

Приложение 2

Цели и задачи:

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

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

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

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

· простота и удобство доступа к отчетам;

· хранение отчетных форм в едином репозитории;

· легкость навигации по множеству отчетов;

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

Для этого в ходе работы необходимо решить ряд проблемных вопросов и задач.

Во-первых, необходимо изучить принципы построения систем анализа данных на основе OLAP-технологий [5, 6, 7], их архитектуру, а также особенности механизмов работы.

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

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

Кроме того, необходимо разработать надстройку Business Intelligence, систему построения динамических отчетов и визуального представления информации. Основными требованиями к разрабатываемой системе BI будут простота в изучении и работе, скорость создания отчетов, а также наглядность представления результатов по запросам. В итоге, разработанная информационно-аналитическая система даст возможность быстрого и обоснованного решения широкого спектра аналитических и управленческих задач, обеспечит повышение эффективности контроля и управления компанией, а также облегчит процесс разработки уникальных маркетинговых стратегий, адекватных сложившейся ситуации и интересных различным группам потребителей услуг мобильной связи.

Глава 1: Анализ средств реализации аналитической отчетности в различных средах. Выбор оптимального варианта решения поставленной задачи

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

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

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

Способы доступа к источникам данных определяют архитектуру аналитических платформ. В соответствии с используемыми способами все аналитические платформы делятся на две группы.

Платформы первой группы ориентированы на работу с выделенными источниками данных — хранилищами и витринами данных, которые специально сформированы для аналитической обработки, что выражается и в особых структурах и моделях данных этих источников. В настоящее время наибольшее признание в качестве модели данных для анализа данных получила многомерная модель, которая может быть реализована и средствами реляционных СУБД, и средствами многомерных (OLAP) СУБД. Эффективность и удобство выполнения анализа при использовании последних значительно выше, чем при применении реляционных СУБД, поэтому OLAP-серверы является ядром аналитических платформ первой группы. К этой группе относятся аналитические платформы Microsoft, Hyperion Solutions, «старая» аналитическая платформа Oracle и др.

Платформы второй группы, а это, прежде всего, платформы компаний Business Objects, Cognos, Microstrategy и новая платформа Oracle, разработаны для работы с более широким кругом источников, в который помимо хранилищ и витрин данных (реляционных и многомерных) входят «обычные» базы данных, создаваемые транзакционными (класса OLTP) системами, и, возможно, другие источники данных: XML-файлы, плоские файлы, файлы MS Excel и т. д. Можно сказать, что эти платформы в принципе «равноудалены» от различных источников данных.

В состав платформ второй группы не входят OLAP-серверы и другие средства непосредственного доступа к источникам данных, для доступа к данным в этих платформах используются в основном стандартные интерфейсы к соответствующим серверам: ODBC/JDBC для доступа к реляционным базам/хранилищам, MDX (MultiDimensional eXpressions) для доступа к многомерным (OLAP). Кроме того, в некоторых платформах используются и «родные» для конкретных источников интерфейсы. Например, интерфейс OCI (Oracle Call Interface) для доступа к базам данных Oracle, интерфейс XMLA (XML for Analysis) для доступа к многомерным хранилищам SAP BI/BW, интерфейсы к базам данных популярных пакетов.

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

Как уже было замечено, основными представителями второго подхода являются аналитические системы, разработанные на современных BI платформах компаний SAP Business Objects, IBM Cognos, Microstrategy и Oracle BI. Данные компании поставляют мощные решения для бизнес-аналитики, ориентированные на корпоративный уровень.

SAP Business Objects.

Business Objects предлагает богатый набор зрелых решений бизнес-аналитики, и это один из немногих вендоров, предлагающих законченное решение Business Intelligence (BI), включая продукты по интеграции данных, качеству данных и текстовой аналитике. Есть и лучшие в своем классе инструменты для конкретного использования: Crystal для производственной отчетности, WebIntelligence для нерегламентированных запросов, Voyager для OLAP, Polestar для управляемого поиска в бизнес-аналитике, Xcelsius для интерактивных информационных панелей, и некоторые другие Эти преимущества, конечно, сказываются на цене. К тому же, перевод всех продуктов SAP Business Objects на общую платформу для повышения безопасности и улучшения администрирования может потребовать значительных усилий, учитывая то, что у SAP не было ранее существенного опыта в интеграции крупных приобретений.

IBM Cognos BI

По функциональным характеристикам IBM Cognos BI — одна из самых мощных систем на рынке на сегодняшний день. Первое преимущество Cognos — это единая платформа, которая закрывает все вопросы управления эффективностью. Второе — ее легко внедрять, легко настраивать. Но есть немаловажный момент в работе конечных пользователей, который является весьма существенным для топ менеджмента. Система отчетности состоит из слишком большого набора отдельных элементов, которые обладают схожим функционалом. Например, Report Studio, Query Studio и Analysis Studio. По общему мнению экспертов эти три инструмента следовало бы объединить в один, для большей простоты и скорости использования. К тому же они не так просты в освоении, как хотелось бы.

Ещё одним недостатком Когнос является то, что он довольно медленно экспортирует данные из отчетов в Excel. Экспорт идет не массивами, а поячеечно и не напрямую в файл, а через COM. Т. е. на отчетах из десяти тысяч строк и больше потребуется довольно длительное время для загрузки Ну и в-третьих, не очень удачна, на мой взгляд, модель работы клиента с памятью. Данные закачиваются в отчет не сразу, а только для видимой области экрана. Соответственно, при попытке скроллинга программа будет каждый раз подгружать данные. Суммарное время загрузки отчета таким образом увеличивается.

MicroStrategy

Cчитается что продукт от Microstrategy ориентирован на работу с большими массивами в хранилище данных (как правило, речь идет о терабайтах). Принципы извлечения информации основаны на генерации обычных SQL-запросов, что делает этот инструмент наиболее привлекательным для формирования больших отчетов. Плюсом является то, что интегрированы средства доставки и формирования отчетов по расписанию.

Но, по сравнению с рассмотренными средствами, инструмент несколько необычен и следовательно более сложен в освоении. Также к недостаткам стоит отнести такие моменты, как невозможность напрямую работы с базой, в которой используются естественные ключи (например Аксапта). Нет возможности ручного тюнинга сгенерированного SQL

Сравнительную оценку ведущих BI-платформ можно увидеть в таблице 1.

Таблица 1. Сравнительная оценка ведущих BI-платформ.

Свой выбор я остановил на программных продуктах компании Oracle. Для этой компании направление хранилищ данных и аналитических систем уже несколько лет является одним из самых приоритетных. Oracle, на данный момент, по праву считается одним из лидеров на рынке BI-платформ, в последние годы компания приобрела несколько производителей аналитических систем, и сейчас активно использует их разработки, постоянно дополняя функциональность своих решений. Гибкость и простота интеграции платформы Oracle, не в последнюю очередь, обусловлена тем, что её аналитический сервер реализован на основе разработок компании Siebel, влившейся в Oracle в 2006 году. Продукты Siebel, в частности Siebel Analytics, изначально проектировались с упором на легкую интеграцию с различными гетерогенными источниками данных. Эта особенность была унаследована и новейшей платформой Oracle.

Ключевые отличия BI-платформы Oracle от конкурирующих продуктов:

· Унифицированное представление информации — позволяет объединять данные из множества СУБД, корпоративных приложений, OLAP-источников и неструктурированных источников данных.

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

· Прогнозирование в реальном времени — позволяет бизнес-пользователям комбинировать исторические данные и информацию в реальном времени.

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

· Развитые возможности администрирования.

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

Наряду с привычными таблицами, крос-таблицами и графиками есть такие весьма выразительные средства как индикаторы, бегущие строки, возможности интеграции с картографическими средствами. Возможность быстрого создания очень качественных с точки зрения пользовательского интерфейса аналитических информационных панелей также является существенным преимуществом Oracle BI Enterprise Edition. Но основные преимущества Oracle BI Enterprise Edition заключаются, конечно, в его архитектурных решениях. Oracle BI Enterprise Edition может легко интегрироваться в сложные системы. В качестве источника данных может использоваться не только сервер баз данных Oracle, а любой ODBC-доступный источник данных. Более того, сам Oracle BI Enterprise Edition может служить источником как на уровне ODBC, так и как web-service. При этом в Oracle BI Enterprise Edition очень отчетливо разделены вопросы представления данных от их логического и физического представления. Причем не только на уровне метаданных, но и на архитектурном уровне — отдельные BI сервер для работы с данными (формирование запроса, исполнение и т. п.) и презентационный сервер, ответственный за представление результатов запроса. Именно эти особенности позволяют говорить об Oracle BI Enterprise Edition не как о продукте, а о платформе для BI приложений, в которую могут интегрироваться различные продукты.

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

Все перечисленные аспекты позволяют считать аналитическую платформу Oracle наилучшим средством разработки корпоративной аналитической системы в рамках данной дипломной работы.

Хотя решение от IBM не только не уступает, а в некоторых задачах и превосходит Oracle BI, ключевую роль в выборе сыграло наличие у заказчика системы управления взаимодействием с клиентами Siebel CRM и возможность тесной интеграции этой системы с модулем построения маркетинговых сегментов в Oracle BI.

Вывод

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

1. оценками профессионалов в данной области, касательно удобства разработки и интеграции аналитической системы на той или иной платформе.

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

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

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

Глава 2. Архитектура и технология функционирования системы

2.1 Общие сведения

В настоящее время существуют фактические стандарты построения корпоративных информационно-аналитических систем, основанных на концепции хранилища [6, 7]. Эти стандарты опираются на современные исследования и общемировую практику создания хранилищ данных и аналитических систем.

В общем виде архитектура корпоративной информационно-аналитической системы описывается схемой с тремя выделенными слоями (Рис 2.1):

— Извлечение, преобразование и загрузка данных

— Хранение данных

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

Рис 2.1 Архитектура корпоративной информационно-аналитической системы

2.1.1 Извлечение, преобразование и загрузка данных

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

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

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

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

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

— извлекать данные из различных баз данных, текстовых файлов;

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

— преобразовывать данные при перемещении их от источников к хранилищу;

— загружать согласованные и «очищенные» данные в структуры хранилища.

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

2.1.2 Хранение данных

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

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

Хранилище может быть реализовано на основе как реляционной, так и многомерной технологии баз данных, работающей под управлением достаточно мощной СУБД. Такая СУБД должна поддерживать эффективную работу с терабайтными объемами информации, иметь развитые средства ограничения доступа, обеспечивать повышенный уровень надежности и секретности, соответствовать необходимым требованиям по восстановлению и архивации и т. п. Обычно для достаточно большой части аналитических приложений оказывается удобной и эффективной технология интерактивного многомерного анализа и в этом случае хранилище представляет собой многомерную базу данных, реализованную в архитектуре OLAP, ROLAP или HOLAP.

2.1.3 Анализ данных

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

Аналитическая деятельность в рамках корпорации достаточно разнообразна и определяется характером решаемых задач, организационными особенностями компании, уровнем и степенью подготовленности аналитиков. В связи с этим современный подход к инструментальным средствам анализа не ограничивается использованием какой-то одной технологи. В настоящее время принято различать четыре основных вида аналитической деятельности (Рис 2.2): стандартная отчетность, нерегламентированные запросы, многомерный анализ (OLAP) и извлечение знаний (data mining). Каждая из этих технологий имеет свои особенности, определенный набор типовых задач и должна поддерживаться специализированной инструментальной средой.

2.2 Инструментальные средства

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

2.2.1 Серверные компоненты

2.2.1.1 Oracle Database для реализации хранилища данных

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

Также в состав Oracle Database входит Enterprise Manager — мощное графическое средство, специально разработанное для эффективного администрирования. С его помощью можно управлять всеми объектами базы данных и автоматизировать основные административные задачи.

2.2.1.2 Oracle Business Intelligence Suite Enterprise Edition

В качестве аналитической среды выступает платформа Oracle BI Suite EE, которая является представителем наиболее прогрессивного подхода к способам доступа к источникам данных.

Основными архитектурными компонентами системы являются: Oracle BI Server, Oracle BI Web и Oracle Delivers Server.

Рис 2.2 Архитектура платформы Oracle BI.

Oracle BI Server занимает в архитектуре платформы центральное место. Через него реализуется весь доступ к разнообразным источникам данных. Этот сервер называют аналитическим сервером приложений (business intelligence application server), так как он поддерживает интерфейсы к реляционным и многомерным (OLAP) базам (ODBC, OCI, MDX, CLI), а также к плоским файлам, XML-документам и таблицам MS Excel. Также он исполняет роль интегратора, которая ранее традиционно была прерогативой промежуточной области (staging area) хранилища данных.

Oracle BI Server обладает всей необходимой серверной инфраструктурой, включая управление сессиями, запросами, отменами и блокировками, ведением журналов и мониторингом активности, балансировкой нагрузки на сервер и, самое главное, эффективной системой кеширования запросов пользователей и их результатов. Ещё он централизованно хранит метаданные об источниках данных и бизнес-объектах (business definitions) в своем репозитории, доступном всем инструментам платформы Oracle BI EE. Для достижения высокой производительности и масштабируемости системы Oracle BI Server можно объединять в кластеры. Поддерживается возможность балансировки нагрузки, что позволяет распределять запросы и пользовательские сеансы на разные сервера.

Oracle BI Web предоставляет интерфейсы для всех компонент системы, используемых для визуализации данных. Он взаимодействует с Oracle BI Server и выполняет ряд важнейших функций: отвечает за авторизацию пользователей и персонализацию интерфейса для них, генерацию логических запросов к аналитическому серверу, хранение и администрирование метаданных (Web-каталог) для отчетов и интерактивных панелей, осуществляет дополнительную пост-обработку данных.

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

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

Современная тенденция интеграции приложений с Internet-технологиями находит свою полную поддержку в Oracle BI Suite EE. Так, Oracle BI Web предлагает интерфейс на основе Web-сервисов. В целом вся платформа Oracle BI SuiteEE построена на SOA (Service Oriented Architecture) архитектуре.

2.2.2 Клиентские приложения

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

В состав платформы Oracle BI Suite EE входит следующий набор инструментов (клиентских приложений):

-BI Answers — инструмент для выполнения произвольных (ad hoc) запросов и анализа;

-BI Interactive Dashboard — интерактивные информационные Web-панели, отображающие персонализированную информацию;

-BI Publisher — масштабируемое средство формирования регламентированных отчетов в разных форматах на основе данных из множества источников и их рассылки по различным каналам;

-BI Disconnected Analytics — средство доступа пользователей к возможностям BI Answers и BI Interactive Dashboard при работе в режиме офлайн, предусматривает полную и инкрементальную синхронизацию данных мобильной среды с корпоративными источниками данных;

-BI Office Plug-In — инструмент работы с аналитическим сервером через такие приложения, как MS Word, Excel и Powerpoint;

-BI Delivers — механизм распространения по различным каналам сообщений о событиях.

Все клиентские приложения реализованы в чистой Web-среде, на основе HTML, DHTML, JavaScript — пользователю не придется выполнять загрузку какого-либо клиента, использовать программные расширения, элементы управления на базе ActiveX или Java-апплеты. Это позволяет пользователю работать с системой откуда угодно где есть подключение к глобальной сети.

2.2.3 Метаданные

Аналитический сервер Oracle BI Server представляет данные пользователям согласно логической бизнес-модели — корпоративной семантической модели (Enterprise Semantic Model). Эта модель имеет три слоя (Рис 2.3): физический, содержащий метаданные о физических источникам данных, имена таблиц, первичные и внешние (primary and foreign) ключи, статистики по количеству строк (row counts), правила доступа к таблицам, а также пул соединений; бизнес-слой, содержащий описания измерений и иерархий, логические таблицы, правила выбора источников данных, правила построения вычислений, агрегаций и временного анализа, а также правила детализации; слой представления — упрощенное, персонализированное представление данных, к которым ссылаются с применением «логического SQL».

Рис 2.3 Корпоративная семантическая модель

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

Бизнес-слой обеспечивает уровень абстракции над физическими объектами и позволяет администратору группировать данные в логические тематические области (logical subject areas). «Направления детализации» (Drill paths) могут быть установлены с применением определений измерений и размерностей. Они могут использовать преимущества встроенного «движка» вычислений (in-built calculation engine) в аналитическом сервере.

Слой представления определяет, что конечные пользователи увидят, когда они начнут выбирать данные в клиентском приложении. Это может быть полный набор данных в бизнес-слое или просто поднабор, и вы можете применять фильтры и ограничения (scoping), так что отдельные департаменты/сотрудники увидят только «свои», непосредственно для них предназначенные, данные.

2.2.4 Доступ к данным и обработка запросов

Oracle BI Server в части обработки запросов выполняет две основные функции: компиляцию входящих запросов (от пользователей) в исполняемый код и непосредственно исполнение этого кода. Важным моментом является возможность оптимизации запросов с учетом специфики каждого конкретного источника. Механизм объединения данных учитывает физическое расположение данных (таблица базы данных или, например, плоский файл), особенности функциональности SQL, поддерживаемого базой данных, а также аналитической сложности запроса.

В платформе Oracle BI Suite ЕЕ обработка запросов к данным максимально переносится на серверы источников данных, так как при работе со сверхбольшими наборами данных лучше использовать высокопроизводительный сервер СУБД. Поэтому, когда возможно, для обработки используются именно эти технологии, а не аналитический сервер, роль которого в этом случае заключается в принятии запросов от инструмента (клиентского приложения) и их трансляции в предложения SQL (или MDX) к базам исходных данных. Когда база-источник возвращает результаты, аналитический сервер сводит данные, если нужно, сам выполняет некоторые вычисления, форматирует эти данные и возвращает их клиентскому приложению.

В целом, Oracle BI Server предоставляет очень широкие возможности настройки доступа к данным и их обработки с максимальным использованием метаданных, за что этот сервер некоторыми аналитиками именуется «интеллектуальным» (intelligent).

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

Глава 3 Анализ и проектирование проектирования источников данных

3.1 Анализ существующих систем-источников данных

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

Компания Мегалайн, для которой разрабатывается система бизнес-аналитики, имеет две рабочие учётные системы, распределенные по регионам; каждая из систем имеет по две базы: одна из которых содержит данные по клиентам и их контрактам, другая — данные по всем событиям/транзакциям по каждому клиенту, снятые с аппаратной части биллинговой системы.

Ниже представлены схемы каждой из этих баз, они будут использованы для анализа систем-источников.

Источник 1: «Мегалайн-Центр»

Рис 3.1 Схема базы учета клиентских контрактов «Мегалайн-Центр»

Рис 3.2 Схема базы учета событий «Мегалайн-Центр»

Источник 2: «Мегалайн-Сибирь»

Рис 3.3 Схема базы учета клиентских контрактов «Мегалайн-Сибирь»

Рис 3.4 Схема базы учета событий «Мегалайн-Сибирь»

Как видно из этих схем, учётные системы компании Мегалайн схожи, но не идентичны. Первая разрабатывалась и заполнялась данными при функционировании и развитии Мегалайна на территории центральных округов России (название источника «Мегалайн-Центр»), вторая была преобразована из базы данных сибирского регионального оператора при его покупке Мегалайном (название источника «Мегалайн-Сибирь»). Анализируя эти источники, решаем следующие вопросы: во-первых, определяемся с возможными проблемными местами, т. е. особенностями источников, которые могут затруднить разработку хранилища и/или ETL-процесса; во-вторых, выделяем из таблиц баз-источников те ключевые для нас данные, которые необходимы для обеспечения потребностей организации в аналитике.

Исходя из представленных схем, можно отметить ряд особенностей:

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

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

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

В связи с этим, выбираем лишь те сущности из баз-источников и те поля, которые относятся к рассматриваемой области. Из баз учета клиентских контрактов обоих источников нам, очевидно, понадобятся таблицы с информацией о клиентах, регионах, предоставляемых продуктах и те поля таблиц контрактов, в которых содержится информация о номере телефона абонента, датах открытия/закрытия контракта, а также поля привязки к региону и тарифу. Из баз учета событий обоих источников необходимо выбрать те сущности, где содержится информация о действиях клиента, связанных с затратой средств на услуги, т. е. таблицы с информацией о звонках, смс-сообщениях и GPRS-трафике абонентов. Здесь нельзя забывать о том, что в биллинговой системе данные, например, о звонках абонента хранятся в следующем виде: факт начала звонка фиксируется с точностью до секунды, так же фиксируется и факт окончания звонка, причем для каждого абонента записываются как входящие, так и исходящие звонки. При этом единственное событие порождает несколько строк с детализированной информацией в базе данных; за день для одного абонента может быть создано до нескольких десятков строк. Такой способ хранения не актуален для общего хранилища данных, здесь нам интересно количество звонков абонента и их время, именно то, что можно использовать при расчете различного рода выручек и чем удобно манипулировать в отчетах. Эту особенность, также, учтем при организации ETL-процесса, чтобы обеспечить агрегацию данных о звонках, смс и GPRS-трафике за тот временной интервал, который на следующих этапах разработки будет выбран как критерий историчности хранилища.

3.2 Проектирование хранилища данных

Вторым этапом разработки аналитической системы является проектирование хранилища данных. К проектированию хранилищ данных обычно предъявляются следующие требования:

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

— Данные в хранилище должны регулярно пополняться. Требуется тщательно документировать правила пополнения и резервного копирования данных.

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

— Должны быть выделены статические данные, которые регулярно модифицируются: ежедневно, еженедельно, ежеквартально.

— Обработка запросов к хранилищу должна быть проведена с высокой производительностью, желательно в реальном масштабе времени, поэтому должна быть обеспечена поддержка сложных запросов SQL, которые требуют последовательной обработки тысяч или миллионов записей.

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

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

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

Схема звезда обычно содержит одну большую таблицу, называемую таблицей фактов (fact table), помещенную в центр, и окружающие ее меньшие таблицы, называемые таблицами измерений (dimensional table), соединенными с таблицей фактов в виде звезды радиальными связями. В этих связях таблицы измерений являются родительскими, таблица фактов — дочерней. Схема звезда может иметь также консольные таблицы (outrigger table). Консольные таблицы могут быть связаны только с таблицами измерений, причем консольная таблица в этой связи родительская, а таблица размерности — дочерняя. Связь может быть идентифицирующей или неидентифицирующей. Консольная таблица не может быть связана с таблицей факта. Она используется для частичной нормализации данных в таблицах измерений [1, 11].

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

Для расчета выручки за определенный временной интервал будем учитывать данные о звонках, их количество и длительность, данные об смс-сообщениях и интернет трафике. Таким образом, основными полями таблицы фактов будут: callin_amount (количество входящих звонков), callin_time (общее время входящих звонков), callout_amount (количество исходящих звонков), callout_time (общее время исходящих звонков), smsin_amount (количество входящих смс-сообщений), smsout_amount (количество исходящих смс-сообщений), а так же gprs_mb (количество мегабайт GPRS-трафика). В этом случае, возможно не только рассчитывать затраты клиентов на услуги, а следовательно и выручку компании, связанную непосредственно с их предоставлением. Появляется возможность создавать отчеты о количествах различных действий клиентов и соотношении количества этих действий с выручкой, что тоже необходимо, например, при просчете новых маркетинговых стратегий, или разработке новых тарифных планов. Таким образом, в таблицу фактов регулярно будет заноситься агрегированная информация обо всех транзакциях, детализированность этой информации будет не столь сильной как в базах биллинговой системы, что обеспечит серьезную экономию места на носителях информации, однако, достаточной для проведения качественно-количественного анализа.

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

Основным измерением для аналитических хранилищ является время. Следовательно, в разрабатываемом хранилище должна быть таблица-календарь. Измерения, как правило, имеют многоуровневую иерархическую структуру. Структура измерения «время» в нашем хранилище будет иметь следующий вид: год — квартал — месяц — день. Однако это не значит, что таблица календарь будет содержать 4 поля, здесь гораздо актуальнее ввести большую детализацию, во-первых, для ускорения запросов и упрощения группировок по периодам, во-вторых, для более адекватного представления информации в отчетах. Таким образом, в календаре будет 8 полей: date_id (уникальный идентификатор даты), calendar_date (полное отображение даты в привычном виде: dd.mm.yyyy), calendar_year (год), calendar quarter (номер квартала), calendar_month (название месяца), calendar_month_id (номер месяца в году), calendar_day (название дня недели), calendar_day_id (номер дня в неделе).

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

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

Измерение типа «клиент», вне всякого сомнения, более чем актуально. Таблица с данными по клиентам и их контрактам необходима, например, для отчетов о количестве абонентов, тенденциях изменения этого количества во времени. Также, зачастую, необходима детальная информация о возрастных группах абонентов, их предпочтениях в использовании определенных мобильных услуг и т. д. На основе этого создаем таблицу измерений clients. Она будет содержать поля характеристик самих абонентов и их контрактов: client_id (уникальный идентификатор клиента), client_name (ФИО клиента), client_address (полный адрес), client_e_mail (адрес электронной почты), client_passport (паспортные данные), client_phone (телефонный номер), client_birth_date (дата рождения), begin_date (дата заключения контракта), end_date (дата расторжения контракта), in_source_client_id (идентификатор клиента в базе-источнике), source_system_id (идентификатор базы-источника), record_date (дата внесения записи). Поля in_source_client_id, source_system_id — это служебные поля, определяющие принадлежность клиента базе-источнику. Поле client_id — суррогатный ключ, генерируется при создании новой записи о клиенте, призван обеспечить уникальность идентификаторов при совпадении идентификаторов в базах-источниках.