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

 

Оглавление


Введение

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

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

.1 Общие сведения

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

.1.2 Хранение данных

.1.3 Анализ данных

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

.2.1 Серверные компоненты

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

.2.1.2 Oracle Business Intelligence Suite Enterprise Edition

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

.2.3 Метаданные

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

Глава 3

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

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

Глава 4: Практическая реализация

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

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

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

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

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

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

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

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

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

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

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

.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. Данные компании поставляют мощные решения для бизнес-аналитики, ориентированные на корпоративный уровень.Business Objects.Objects предлагает богатый набор зрелых решений бизнес-аналитики, и это один из немногих вендоров, предлагающих законченное решение Business Intelligence (BI), включая продукты по интеграции данных, качеству данных и текстовой аналитике. Есть и лучшие в своем классе инструменты для конкретного использования: Crystal для производственной отчетности, WebIntelligence для нерегламентированных запросов, Voyager для OLAP, Polestar для управляемого поиска в бизнес-аналитике, Xcelsius для интерактивных информационных панелей, и некоторые другие

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

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

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

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

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

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


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

IBM CognosSAP Business ObjectsMicroStrategyOracleАрхитектура3.5433.5Функциональность приложений4.54.52.54.5Интегрированность443.54.5Пользовательский интерфейс3.543.55Ценообразование и лицензирование2.5333.5Развитие продукта4.543.54Доля рынка4.54.52.54Все оценки находятся на шкале между 0 (слабая) и 5 (сильная).

Свой выбор я остановил на программных продуктах компании 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 системы для оператора мобильной связи я руководствовался следующими факторами:

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

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

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

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

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


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


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

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

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

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

Анализ данных (рабочие места пользователей)

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


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


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

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

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

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

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

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

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

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

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

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

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


.1.2 Хранение данных

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

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

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


.1.3 Анализ данных

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

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


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


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


.2.1 Серверные компоненты


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

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

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


.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.

BI Server занимает в архитектуре платформы центральное место. Через него реализуется весь доступ к разнообразным источникам данных. Этот сервер называют аналитическим сервером приложений (business intelligence application server), так как он поддерживает интерфейсы к реляционным и многомерным (OLAP) базам (ODBC, OCI, MDX, CLI), а также к плоским файлам, XML-документам и таблицам MS Excel. Также он исполняет роль интегратора, которая ранее традиционно была прерогативой промежуточной области (staging area) хранилища данных.BI Server обладает всей необходимой серверной инфраструктурой, включая управление сессиями, запросами, отменами и блокировками, ведением журналов и мониторингом активности, балансировкой нагрузки на сервер и, самое главное, эффективной системой кеширования запросов пользователей и их результатов. Ещё он централизованно хранит метаданные об источниках данных и бизнес-объектах (business definitions) в своем репозитории, доступном всем инструментам платформы Oracle BI EE. Для достижения высокой производительности и масштабируемости системы Oracle BI Server можно объединять в кластеры. Поддерживается возможность балансировки нагрузки, что позволяет распределять запросы и пользовательские сеансы на разные сервера.BI Web предоставляет интерфейсы для всех компонент системы, используемых для визуализации данных. Он взаимодействует с Oracle BI Server и выполняет ряд важнейших функций: отвечает за авторизацию пользователей и персонализацию интерфейса для них, генерацию логических запросов к аналитическому серверу, хранение и администрирование метаданных (Web-каталог) для отчетов и интерактивных панелей, осуществляет дополнительную пост-обработку данных.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 Клиентские приложения

Если способы доступа к источникам данных определяют архитектуру аналитических платформ, то функциональность клиентских приложений и аналитических средств определяет функциональные возможности системы. Большинство аналитических платформ предлагают ограниченный набор приложений, обычно состоящий из средств построения аналитических запросов и отчетов и неких панелей или книг для объединения связанных отчетов и представления их конечному пользователю. Если же платформа и обладает полным спектром аналитических возможностей, то часто у каждого ее компонента свои метаданные. В отличие от этого, в 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.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.4 Доступ к данным и обработка запросов

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

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

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

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

Глава 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 - суррогатный ключ, генерируется при создании новой записи о клиенте, призван обеспечить уникальность идентификаторов при совпадении идентификаторов в базах-источниках.

Измерение хранилища, связанное с географической распределенностью, также необходимо. Отчеты по различным показателям работы отдельных региональных представительств, а так же их сравнения, играют одну из первых ролей как на уровне топ-менеджмента, так и на уровне управления самих региональных представительств. Таблица измерений regions будет содержать следующие поля: region_id (уникальный идентификатор региона), region_name (название региона), filial_name (название филиала, функционирующего в данном регионе), begin_date (дата открытия филиала компании в данном регионе), end_date (дата закрытия филиала компании в данном регионе), record_date (дата внесения записи). Основными полями в таблице измерений regions являются идентификатор и название региона, однако, при условии функционирования нескольких филиалов в одном регионе, поле название филиала также необходимо для детальных аналитических отчетов.

Следующим типом измерений в хранилище будет «продукт»; в области предоставления услуг сотовой связи основными продуктами являются непосредственно тарифные планы, приобретаемые абонентами. Данное измерение должно содержать основные характеристики тарифных планов, связанные с ценами на различные услуги внутри плана. Такими характеристиками являются: цены за минуту разговора, смс-сообщение, интернет-трафик, а также абонентская плата, если она применима к определенному тарифному плану. Как и в таблицах измерений, описанных выше, в данной таблице должна также указываться информация о датах действия тарифного плана. Список полей таблицы tarifs выглядит следующим образом: tarif_id (уникальный идентификатор тарифа), tarif_name (название тарифа), cost_per_minute (цена за минуту разговора при исходящем вызове), cost_per_sms (цена за исходящее сообщение), cost_per_mb (цена за 1 мегабайт GPRS-трафика), abonent_payment (абонентская плата), begin_date (дата начала действия тарифа), end_date (дата окончания действия тарифа), record_date (дата внесения записи).

Таблица измерений tarifs имеет две ключевые особенности, которые будут учтены при разработке структуры хранилища и при организации процесса загрузки данных из баз-источников. Первая особенность - наличие сущности, родительской по отношению к тарифному плану, это тарифная группа. Данная сущность объединяет несколько тарифных планов по какому-либо параметру, например, по социальному позиционированию, тогда цены внутри тарифов одной группы формируются исходя из особенностей социальной группы. Еще одним примером группировки тарифов может быть форма платежа: тарифы бывают предоплатными и постоплатными. Учесть эту особенность просто необходимо, наилучший вариант - создать ещё одну таблицу tarif_groups как расширение измерения по тарифам. Выражаясь терминами хранилищ данных, данная таблица будет консольной (outrigger table), она будет содержать два основных поля, первичный ключ tarif_group_id и название тарифной группы tarif_group_name, также должны присутствовать дополнительные служебные поля: begin_date, end_date, record_date для определения сроков действия тарифной группы и даты внесения записи о конкретной группе. Таблица tarif_groups будет родительской для таблицы tarifs, их связь определена как один-ко-многим, следовательно, поле tarif_group_id должно содержаться и в таблице tarifs как внешний ключ.

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

Определившись со всеми таблицами хранилища, обратим внимание на связи между ними. Как уже упоминалось, таблица фактов (в нашем случае - facts) это главная таблица в схеме, все запросы к хранилищу направлены, в основном, на извлечение данных о событиях, хранящихся именно в ней. Таблица фактов и таблицы измерений связаны идентифицирующими связями, при этом первичные ключи таблиц измерений мигрируют в таблицу фактов в качестве внешних ключей. Совокупность этих ключей и будет уникальным составным ключом таблицы фактов, в нашем случае это совокупность ключей client_id, region_id, tarif_id, date_id.

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

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


Рис 3.5 Схема хранилища данных

данные загрузка хранилище пользователь

Глава 4: Практическая реализация


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


На основе схемы представленной на рис.3.5, средствами Oracle Database создаем таблицы хранилища и прописываем связи между ними. Данные действия выполняются в редакторе SQL запросов Oracle SQL Plus. (см. Приложение 1)


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


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

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

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

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


. источник данных, как совокупность таблиц оперативной системы и дополнительных справочников;

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

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

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

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

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

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

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

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

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

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

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

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

В ETL можно выделить следующую иерархию сущностей.

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

Сессия (Session) - сущность, включающая в себя один маппинг, физические указатели на таблицу-источник и таблицу-приемник, и интерфейсы доступа к БД источнику и приемнику. Промежуточный уровень.

Управляющий процесс (Workflow) - сущность, реализующая полный процесс переноса данных из источников в хранилище; состоит из последовательности всех сессий процесса, а также правил инициализации каждой сессии. Может содержать расписание запуска процесса и дополнительные характеристики. Высший уровень.

Основная сложность реализации ETL-процесса - это точная проработка каждого маппинга. Рассмотрим процесс реализации маппинга на общей схеме (Рис 4.2).

Рис 4.2 Схема маппинга


На данной схеме выделим 3 логические части: выгрузка данных, обработка и загрузка.

К выгрузке относятся сущности Select на схеме. В качестве источников маппинга выступают как таблица из БД (Source DB) - те поля, которые необходимо извлечь из базы-источника, так и Таблица из Хранилища (Source DWH) - данные извлекаются из таблиц хранилища для сравнения.

…………….

<TRANSFORMATION DESCRIPTION ="" NAME ="SQ_REGIONS" OBJECTVERSION ="1" REUSABLE ="NO" TYPE ="Source Qualifier" VERSIONNUMBER ="1">

<TABLEATTRIBUTE NAME ="Sql Query" VALUE ="SELECT &#xD;&#xA;REGIONS.REGION_ID, &#xD;&#xA;REGIONS.REGION_NAME,&#xD;&#xA;REGIONS.FILIAL_NAME, &#xD;&#xA;REGIONS.IN_SOURCE_UNIQUE_ID, &#xD;&#xA;REGIONS.END_DATE &#xD;&#xA;FROM REGIONS&#xD;&#xA;where REGIONS.END_DATE = to_date(&apos;31.12.9999&apos;, &apos;dd.mm.yyyy&apos;)&#xD;&#xA;and REGIONS.SOURCE_SYSTEM_ID = 1"/>

<TABLEATTRIBUTE NAME ="User Defined Join" VALUE =""/>

<TABLEATTRIBUTE NAME ="Source Filter" VALUE =""/>

<TABLEATTRIBUTE NAME ="Number Of Sorted Ports" VALUE ="0"/>

<TABLEATTRIBUTE NAME ="Tracing Level" VALUE ="Normal"/>

<TABLEATTRIBUTE NAME ="Select Distinct" VALUE ="NO"/>

<TABLEATTRIBUTE NAME ="Is Partitionable" VALUE ="NO"/>

<TABLEATTRIBUTE NAME ="Pre SQL" VALUE =""/>

<TABLEATTRIBUTE NAME ="Post SQL" VALUE =""/>

<TABLEATTRIBUTE NAME ="Output is deterministic" VALUE ="NO"/>

<TABLEATTRIBUTE NAME ="Output is repeatable" VALUE ="Never"/>

</TRANSFORMATION>

…………….

Далее идет обработка данных:

) Join - объединение двух таблиц для анализа. Здесь мы сводим в единую таблицу данные из источника и получателя, для определения тех данных, которые надо передать.

) exp_RECORD_DATE - заносим данные о дате создания записи.

........................

<TRANSFORMATION DESCRIPTION ="" NAME ="exp_RECORD_DATE" OBJECTVERSION ="1" REUSABLE ="NO" TYPE ="Expression" VERSIONNUMBER ="1">

<TRANSFORMFIELD DATATYPE ="decimal" DEFAULTVALUE ="" DESCRIPTION ="" EXPRESSION ="REGION_PK" EXPRESSIONTYPE ="GENERAL" NAME ="REGION_PK" PICTURETEXT ="" PORTTYPE ="INPUT/OUTPUT" PRECISION ="16" SCALE ="0"/>

<TRANSFORMFIELD DATATYPE ="date/time" DEFAULTVALUE ="ERROR(&apos;transformation error&apos;)" DESCRIPTION ="" EXPRESSION ="sessstarttime" EXPRESSIONTYPE ="GENERAL" NAME ="RECORD_DATE" PICTURETEXT ="" PORTTYPE ="OUTPUT" PRECISION ="19" SCALE ="0"/>

<TRANSFORMFIELD DATATYPE ="decimal" DEFAULTVALUE ="ERROR(&apos;transformation error&apos;)" DESCRIPTION ="" EXPRESSION ="1" EXPRESSIONTYPE ="GENERAL" NAME ="SOURCE_SYSTEM_ID" PICTURETEXT ="" PORTTYPE ="OUTPUT" PRECISION ="16" SCALE ="0"/>

<TABLEATTRIBUTE NAME ="Tracing Level" VALUE ="Normal"/>

........................

</TRANSFORMATION>

........................

) Routing - На данном этапе определяем метод внесения записи. Если запись существует в источнике, но ее нет в хранилище, выбираем метод Insert. Если запись существует и в источнике и в хранилище и при этом они отличаются, выбираем метод Update. Если запись есть в хранилище, а в источнике отсутствует, значит, применяем метод Delete.

........................

<TRANSFORMATION DESCRIPTION ="" NAME ="RTRTRANS" OBJECTVERSION ="1" REUSABLE ="NO" TYPE ="Router" VERSIONNUMBER ="1">

<GROUP DESCRIPTION ="" NAME ="INPUT" ORDER ="1" TYPE ="INPUT"/>

<GROUP DESCRIPTION ="" EXPRESSION ="not isnull (REGION_PK)&#xD;&#xA;and isnull(IN_SOURCE_UNIQUE_ID)" NAME ="INSERT" ORDER ="2" TYPE ="OUTPUT"/>

<GROUP DESCRIPTION ="" EXPRESSION ="not isnull(REGION_PK) &#xD;&#xA;and not isnull(IN_SOURCE_UNIQUE_ID)&#xD;&#xA;and (REGION_NAME &lt;&gt; REGION_NAME1&#xD;&#xA; or ORG_NAME &lt;&gt; FILIAL_NAME)" NAME ="UPDATE" ORDER ="3" TYPE ="OUTPUT"/>

<GROUP DESCRIPTION ="" EXPRESSION ="isnull(REGION_PK)&#xD;&#xA;and not isnull(IN_SOURCE_UNIQUE_ID)" NAME ="DELETE" ORDER ="4" TYPE ="OUTPUT"/>

........................

</TRANSFORMATION>

........................

) exp_BEGIN/END_DATE - занесение данных о начале/конце актуальности записи.

) Непосредственно внесение данных в таблицу хранилища выбранным методом Insert? Update или Delete.

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

………………….

<SESSION DESCRIPTION ="" ISVALID ="YES" MAPPINGNAME ="m_CLISTG_REGION_STG_REGION" NAME ="s_m_CLISTG_REGION_STG_REGION" REUSABLE ="YES" SORTORDER ="Binary" VERSIONNUMBER ="1">

………………….

<SESSIONEXTENSION NAME ="Relational Writer" SINSTANCENAME ="STG_REGION" SUBTYPE ="Relational Writer" TRANSFORMATIONTYPE ="Target Definition" TYPE ="WRITER">

<CONNECTIONREFERENCE CNXREFNAME ="DB Connection" CONNECTIONNAME ="STG_PROD" CONNECTIONNUMBER ="1" CONNECTIONSUBTYPE ="Oracle" CONNECTIONTYPE ="Relational" VARIABLE =""/>

<ATTRIBUTE NAME ="Target load type" VALUE ="Bulk"/>

<ATTRIBUTE NAME ="Insert" VALUE ="YES"/>

<ATTRIBUTE NAME ="Update as Update" VALUE ="NO"/>

<ATTRIBUTE NAME ="Update as Insert" VALUE ="NO"/>

<ATTRIBUTE NAME ="Update else Insert" VALUE ="NO"/>

<ATTRIBUTE NAME ="Delete" VALUE ="NO"/>

<ATTRIBUTE NAME ="Truncate target table option" VALUE ="YES"/>

<ATTRIBUTE NAME ="Reject file directory" VALUE ="$PMBadFileDir&#x5c;"/>

<ATTRIBUTE NAME ="Reject filename" VALUE ="stg_region1.bad"/>

</SESSIONEXTENSION>

………………….

<ATTRIBUTE NAME ="Commit Type" VALUE ="Target"/>

<ATTRIBUTE NAME ="Commit Interval" VALUE ="10000"/>

<ATTRIBUTE NAME ="Commit On End Of File" VALUE ="YES"/>

<ATTRIBUTE NAME ="Rollback Transactions on Errors" VALUE ="NO"/>

<ATTRIBUTE NAME ="Collect performance data" VALUE ="NO"/>

<ATTRIBUTE NAME ="Write performance data to repository" VALUE ="NO"/>

</SESSION>

………………….

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

Организуем управляющий процесс и создаем расписание ежедневного запуска процесса, как один из его атрибутов.

………………….

<WORKFLOW DESCRIPTION ="" ISENABLED ="YES" ISRUNNABLESERVICE ="NO" ISSERVICE ="NO" ISVALID ="YES" NAME ="w_LOAD_DWH_INC" REUSABLE_SCHEDULER ="NO" SCHEDULERNAME ="Scheduler" SERVERNAME ="PowerCenter_Integration_Service" SERVER_DOMAINNAME ="Domain_DREW" SUSPEND_ON_ERROR ="NO" TASKS_MUST_RUN_ON_SERVER ="NO" VERSIONNUMBER ="1">

<SCHEDULER DESCRIPTION ="" NAME ="Scheduler" REUSABLE ="NO" VERSIONNUMBER ="1">

<SCHEDULEINFO>

<STARTOPTIONS STARTDATE ="12/12/2009" STARTTIME ="01:00"/>

<SCHEDULEOPTIONS SCHEDULETYPE ="RECURRING">

<RECURRING DAYS ="1" HOURS ="0" MINUTES ="0"/>

</SCHEDULEOPTIONS>

<ENDOPTIONS ENDTYPE ="RUNFOREVER" RUNFOREVER ="YES"/>

</SCHEDULEINFO>

</SCHEDULER>

………………….

</WORKFLOW>

………………….

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


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


Разработка непосредственно системы анализа данных ведется в комплексном программном решении Oracle Business Intelligence Suite Enterprise Edition. Платформа для бизнес-аналитики OBIEE состоит из трех основных частей. Нижний уровень - это источники данных. На среднем находится аналитический сервер (Oracle BI Server), который выбирает данные из источников, обрабатывает их, кэширует и передает на верхний уровень. Верхний уровень - это аналитический веб-сервер (Oracle Analytics Web Server), который создает пользовательский интерфейс. Нижним уровнем в данном случае является созданное хранилище данных, также, при необходимости, на данном уровне можно задействовать любые другие источники.

Следующим этапом является настройка BI сервера как основной компоненты платформы. На сервере хранится репозиторий, который состоит из трех слоев:

физический слой (Physical layer); бизнес-модель или логический слой (Business model and mapping layer); презентационный слой (Presentation layer). Создание репозитория, а следовательно, и этих трех слоев - предмет рассмотрения данного раздела работы.


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

На данном этапе мы, в первую очередь, создаем новый репозиторий, настраиваем связь с хранилищем данных и импортируем таблицы хранилища и связи между ними в созданный репозиторий (Рис 4.3 и Рис 4.4).


Рис 4.3 Создание репозитория

Рис 4.4 Импортирование структуры и таблиц хранилища на физический слой репозитория

сервер получает доступ к хранилищу данных через интерфейс OCI (Oracle Call Interface). На физическом уровне также можно создавать несколько внешних физических источников, при этом СУБД источника не играет никакой роли, т.к. Oracle BI предоставляет полный набор интерфейсов доступа к различным сторонним базам данных.

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

Рис 4.5 Физическая структура импортированного хранилища


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


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

На данном этапе работы создаем логический слой репозитория, который обеспечивает уровень абстракции над физическим слоем и позволяет формировать логические «Предметные области». Данные предметные области - это логические таблицы, которые мы создаем на основе таблиц физического слоя. Они содержат правила выбора источников физического слоя, правила построения вычислений, агрегаций и временного анализа. При создании логического слоя мы определяем необходимые нам манипуляции с данными из хранилища; основным действием является вычисление выручки. В таблице фактов хранилища содержится информация обо всех действиях клиентов, на основе этих данных, а так же данных о стоимости определенного действия из таблицы tarifs, прописываем правила вычислений. Для этого создаем в таблице фактов логического слоя репозитория логические поля: Call_out_cost (стоимость исходящих вызовов), Sms_cost (стоимость смс-сообщений), Gprs_cost (стоимость интернет трафика)и summary (выручка). Прописываем для каждого из этих полей формулы вычисления, представляющие собой перемножение соответствующих количественных показателей в таблице фактов и ценовых показателей в таблице тарифов. Например, для логического поля Call_out_cost формула будет следующей:

MEGALINE.TARIFS.COST_PER_MINUTE * MEGALINE.FACTS.CALLOUT_TIME

(Рис 4.6 и Рис 4.7)


Рис 4.6 Создание логического поля таблицы фактов

Рис 4.7 Задание правил вычисления логического поля Call_out_cost


Выручка (summary) рассчитывается сложением всех вычисленных по формулам значений.

С учетом того, что временным промежутком, для которого создаются записи в таблице фактов хранилища данных, является день, то в созданных логических полях Call_out_cost, Sms_cost и Gprs_cost мы имеем суммарные значения затрат клиента на различные услуги связи за день, а в поле summary - общие затраты.

Для реализации определенного вида запросов, связанных с возрастными группами клиентов, нам необходимо еще одно вычисляемое поле - возраст клиент. В таблице CLIENTS создаем логическое поле Client_age и прописываем для него правило вычисления возраста из данных о дате рождения (Рис 4.8).


Рис 4.8 Задание правил вычисления логического поля Client_age


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


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

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

Для упрощения работы пользователей мы удаляем все поля, не несущие смысловой нагрузки для пользователей, и не используемые при создании отчетов. Это все поля, содержащие служебную информацию и идентификаторы, такие как BEGIN_DATE, END_DATE, RECORD_DATE, ключи в таблицах и т.д. Далее, в опциях полей прописываем русскоязычный Custom display name, это то как будет отображаться название поля в пользовательской среде (Рис 4.9).


Рис 4.9 Задание русскоязычного названия полей таблиц для пользовательской среды


После выполнения всех выше перечисленных действий репозиторий BI сервера создан; на основе репозитория, BI сервер будет создавать физические запросы к хранилищу данных, производить всю обработку этих данных и передавать результаты на верхний уровень аналитической системы Oracle Analytics Web Server.


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

Следующим этапом работы является организация работы Oracle Analytics Web сервера платформы и создание пользовательского интерфейса. В первую очередь налаживаем взаимодействие аналитического web-сервера с BI сервером. Для этого в конфигурационном файле прописываем путь к репозиторию, созданному на сервере BI (Рис 4.10).


Рис 4.10 Назначение пути к репозиторию BI сервера


Теперь подключаемся к Oracle Analytics Web, и выбираем любое из возможных клиентских приложений. Сразу хочу отметить, что благодаря технологии AJAX, конечному пользователю на рабочем компьютере не требуется ничего кроме web-браузера. Не надо устанавливать ни клиента, ни апплеты, ничего. Достаточно просто подключить, например, ноутбук к сети, открыть окно браузера, ввести адрес, и все возможности системы готовы к использованию. Это называется «чистая» web-среда. Основными приложениями, предоставляемыми для работы, являются «Ответы» (OracleBI Answers) и «Информационные панели <#"justify">.3.4.1 Создание тестового отчета

После подключения к web-серверу Oracle Analytics Web, можно приступать непосредственно к работе, связанной с анализом данных. Протестируем систему, для этого создадим тривиальный отчет, например, «Выручка по регионам и тарифным группам». Для создания отчета, выбираем приложение «Ответы» (OracleBI Answers). Слева мы видим нашу предметную область, столбцы которой являются критериями создания отчетов и ссылаются на сущности презентационного слоя BI сервера

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

В качестве отображения отчета выбираем вид: «Таблица Среза» (Pivot Table), настраиваем отображение показателей по строкам и столбцам таблицы для наиболее удобного просмотра, в нашем случае: Столбцы - Группы Тарифов, Строки - Регионы, Показатели - Общая Выручка. Предварительные результаты можно просмотреть, отметив флаг «Показать результаты»


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

Таким образом, можно составить отчет любой сложности в кратчайшие сроки. Сохраненные отчеты для быстрого и удобного использования помещаются в приложение «Информационные панели <#"justify">4.3.4.2 Создание региональной карты

Мы протестировали систему, создав отчет о выручке по регионам и тарифным группам. Отчеты, связанные с представлением различных показателей (выручка, количество клиентов и т.д.) по регионам, будут одними из самых востребованных при использовании системы. Связано это с широким региональным распределением компании Мегалайн. Для наибольшей наглядности подобного рода отчетов создадим интерактивную карту регионов, на которой будут отображаться значения исследуемых показателей. Для этого средствами Macromedia Flash MX [10] рисуем интерактивную карту регионов покрытия сотовой связи Мегалайн. Помещаем файл map.swf в папку …\OracleBI\oc4j_bi\j2ee\home\applications\analytics\analytics\

для возможности использования флэш-объекта как метода отображения отчета и настраиваем флэш-объект на обмен данными с сервером

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

Данный отчет сохраняем в «Информационные панели <#"justify">4.3.5 Механизм работы системы

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

Система построения отчетов, построенная на платформе Oracle BI, имеет два неоспоримых плюса для конечных пользователей. Во-первых, это чистая web-среда, позволяющая работать, откуда угодно, где есть доступ в интернет, можно даже использовать мобильные средства, например КПК. Во-вторых, простота, позволяющая пользователям, не имеющим навыков написания запросов к базам данных, создавать отчеты любой сложности буквально на лету. Пользователь оперирует известными ему понятиями и логикой, комбинируя критерии отчета, он создает запрос, настраивает визуальное представление отчета и получает результат в течение нескольких секунд. При этом он не задумывается о физической структуре данных в источниках и методах их изъятия.


.3.5.2 Механизм работы системы с точки зрения платформы

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

Когда начинается сеанс пользователя, Oracle Analytics Web представляет OracleBI Server идентификационную информацию пользователя (имя пользователя/пароль), опознает пользователя, а затем запрашивает OracleBI Server о предоставлении "баз данных", "таблиц" и "столбцов", к которым у пользователя есть доступ. Такие объекты отображаются пользовательским интерфейсом в виде предметных областей, папок и столбцов. OracleBI Server также обеспечивает Oracle Analytics Web метаданными, включающими такие свойства столбцов, как вид данных, правила агрегации и может ли пользователь иметь доступ к детализации данных столбца - каждый из этих элементов также будет влиять на то, как будут отображаться данные в интерфейсе пользователя.

Доступ к Oracle BI Server предоставляется через стандартный, совместимый с ODBC 2.0 интерфейс. Упрощенно, сервер выполняет две основных функции: компиляция входящих запросов в исполняемый код и исполнение этого кода. Клиенты Oracle BI сервера, в данном случае Oracle Analytics Web, видят логическую схему данных, независимую от физической структуры данных в источнике. Клиенты Oracle BI сервера посылают упрощенный логический SQL запрос, который преобразуется сервером в комбинацию физического SQL, посылаемого к различным источникам данных и промежуточного кода, который выполняется внутри Oracle BI Server Execution Engine. Также Oracle BI Server имеет необходимую серверную инфраструктуру для управления сессиями и запросами, отменами, ведением журналов, мониторинга и другие административные серверные функции. Компиляция запроса состоит из следующих стадий: синтаксический анализ, генерация логического запроса, навигация и генерация кода. На выходе компилятора запроса - исполняемый код. Код передается механизму исполнения, который отвечает за исполнение кода. Генерация кода включает формирование запросов специфичных для конкретного типа СУБД (т.е. генерации физического SQL).

Далее физический SQL запрос идет на обработку непосредственно в СУБД, в нашем случае это Oracle Database. Полученные результаты отправляются обратно в той же последовательности, где агрегируются в соответствии с правилами, прописанными в репозитории BI Server, и передаются аналитическому web-серверу для формирования отчета.

Список используемой литературы


1.Эрик Спирли - Корпоративные хранилища данных. Планирование, разработка и реализация. - 2001. - 400с.

2.Лисянский К. - Архитектурные решения и моделирование данных для хранилищ и витрин данных. - Статья.

.Кэти Бон - Конвертация данных для хранилищ. - Статья.

.Lilian Hobbs, Susan Hillson, Shilpa Lawande - Oracle9iR2 Data Warehousing. - 2003. - 519с.

5.<#"justify">Приложение 1


. SQL коды создания таблиц хранилища данных

Таблица календаряtable calendar as_number(to_char(daterange, yyyy)) as year,_number(to_char(daterange, yyyymmdd)) as date_id,_char(daterange, month) as month,_number(to_char(daterange,mm)) as month_id,_number(to_char(daterange,dd)) as day_id,_char(daterange,day) as day,as calendar_date(DateRange

(to_date(01.01.2001,dd.MM.YYYY)-1 + level as DateRangedual(to_date(01.01.2001,dd.MM.YYYY)-1+level) <= last_day(to_date(1 2010,MM YYYY))by level<=9999

)BY DateRange )

Таблица группы тарифовtable tariff_groups

(_group_id varchar2 (20 char),_group_name varchar2 (100 char),_date date,pk_tarif_groups primary key (_ariff_group_id)

)

Таблица тарифовtable tariffs

(

_tariff_id number,

_tariff_name varchar2 (100 char),

_tariff_group_id number,_per_minute number,_per_sms number,_date date,pk_tarifs primary key (tariff_id)

)

;

Таблица клиентовtable clients

(_id varchar2(20 char),_name varchar2(20 char),_phone number,_address varchar2(20 char),_email varchar2(20 char),_passport varchar2(100 char),_birth_date date,_date date,_date date,pk_clients primary key (client_id)

)

;

Таблица регионовtable regions

(_id varchar2(20 char),_name varchar2(100 char),_name varchar2(100 char),pk_regions primary key (region_id)

)

;

Таблица показателей (фактов)table facts

(_id number,_id varchar2(20 char),_group_id varchar2(20 char),_id varchar2(20 char),_id varchar2(20 char),_amount number,_amount number,_time number,_time number,_amount number,_amount number

)

;

2.Код создания интерактивной карты на флеш (Actionscript 2.0).

stop();

//Принимает навигационную ссылкуhost;link;year;

//порог срабатывания окрашиванияthreshold = -10;

//Делаем навигационную ссылку глобальной для документа

_global.nav_link_p1 = "#"justify">_global.nav_link_p2 = link;

_global.nav_link_p3 = "&Action=Navigate&p0=2&p1=eq&p2=date.Year&p3="+year+"&p4=eq&p5=regions.ROW_WID&p6=";

//парсер XML, загружаемого через Narrative из BIxml_data;my_xml = new XML();_xml.parseXML(xml_data);len = my_xml.childNodes[0].childNodes.length;

//присваиваем значения переменным по регионам(i=0; i<len; i++) {(my_xml.firstChild.childNodes[i].nodeName) { "2" :_Kavkaz = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;

_root.tKavkaz.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%"; ;"3" :_Sibir = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;

_root.tSibir.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%";;"4" :_Vostok = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;

_root.tVostok.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%";;"5" :_Centr = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;

_root.tCentr.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%";;"6" :_Moscow = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;

_root.tMoscow.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%";;"7" :_Ural = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;

_root.tUral.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%";;"8" :_Volga = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;

_root.tVolga.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%";;"9" :_NW = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;

_root.tNW.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%";;

}

//trace(my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue);

//trace(my_xml.firstChild.childNodes[i].nodeName);

//trace(my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue);

}flash.geom.ColorTransform;flash.geom.Transform;

//Раскраска по регионам в зависимости от входного параметра

//порог срабатывания задаётся переменной "Threshold"Vostok:Transform = new Transform(this.MV_VOSTOK);Sibir:Transform = new Transform(this.MV_SIBIR);Moscow:Transform = new Transform(this.MV_MOSCOW);Centr:Transform = new Transform(this.MV_CENTR);Ural:Transform = new Transform(this.MV_URAL);Volga:Transform = new Transform(this.MV_VOLGA);Kavkaz:Transform = new Transform(this.MV_KAVKAZ);NW:Transform = new Transform(this.MV_NW);

//вызов функций раскрашивания(v_Vostok);(v_Sibir);(v_Ural);(v_Volga);(v_Kavkaz);(v_Centr);(v_Moscow);(v_NW);

//vostokcVostok (v_Vostok){

//Red(v_Vostok <= threshold) {colorVostok:ColorTransform = new ColorTransform();.redOffset = 50;.greenOffset = -150;.blueOffset = -100; }

//Yellowif (v_Vostok > threshold && v_Vostok < 0 ) {colorVostok:ColorTransform = new ColorTransform();.redOffset = +180;.greenOffset = +100;.blueOffset = -5; }.colorTransform = colorVostok;

}

//sibircSibir (v_Sibir){

//Red(v_Sibir <= threshold) {colorSibir:ColorTransform = new ColorTransform();.redOffset = 50;.greenOffset = -150;.blueOffset = -100; }

//Yellowif (v_Sibir > threshold && v_Sibir < 0 ) {colorSibir:ColorTransform = new ColorTransform();.redOffset = +180;.greenOffset = +100;.blueOffset = -5; }.colorTransform = colorSibir;

}

//uralcUral (v_Ural){

//Red(v_Ural <= threshold) {colorUral:ColorTransform = new ColorTransform();.redOffset = 50;.greenOffset = -150;.blueOffset = -100; }

//Yellowif (v_Ural > threshold && v_Ural < 0 ) {colorUral:ColorTransform = new ColorTransform();.redOffset = +180;.greenOffset = +100;.blueOffset = -5; }.colorTransform = colorUral;

}

//volgacVolga (v_Volga){

//Red(v_Volga <= threshold) {colorVolga:ColorTransform = new ColorTransform();.redOffset = 50;.greenOffset = -150;.blueOffset = -100; }

//Yellowif (v_Volga > threshold && v_Volga < 0 ) {colorVolga:ColorTransform = new ColorTransform();.redOffset = +180;.greenOffset = +100;.blueOffset = -5; }.colorTransform = colorVolga;

}

//kavkazcKavkaz (v_Kavkaz){

//Red(v_Kavkaz <= threshold) {colorKavkaz:ColorTransform = new ColorTransform();.redOffset = 50;.greenOffset = -150;.blueOffset = -100; }

//Yellowif (v_Kavkaz > threshold && v_Kavkaz < 0 ) {colorKavkaz:ColorTransform = new ColorTransform();.redOffset = +180;.greenOffset = +100;.blueOffset = -5; }.colorTransform = colorKavkaz;

}

//centrcCentr (v_Centr){

//Red(v_Centr <= threshold) {colorCentr:ColorTransform = new ColorTransform();.redOffset = 50;.greenOffset = -150;.blueOffset = -100; }

//Yellowif (v_Centr > threshold && v_Centr < 0 ) {colorCentr:ColorTransform = new ColorTransform();.redOffset = +180;.greenOffset = +100;.blueOffset = -5; }.colorTransform = colorCentr;

}

//moscowcMoscow (v_Moscow){

//Red(v_Moscow <= threshold) {colorMoscow:ColorTransform = new ColorTransform();.redOffset = 50;.greenOffset = -150;.blueOffset = -100; }

//Yellowif (v_Moscow > threshold && v_Moscow < 0 ) {colorMoscow:ColorTransform = new ColorTransform();.redOffset = +180;.greenOffset = +100;.blueOffset = -5; }.colorTransform = colorMoscow;

}

//North-WestcNW (v_NW){

//Red(v_NW <= threshold) {colorNW:ColorTransform = new ColorTransform();.redOffset = 50;.greenOffset = -150;.blueOffset = -100; }

//Yellowif (v_NW > threshold && v_NW <

) {colorNW:ColorTransform = new ColorTransform();.redOffset = +180;.greenOffset = +100;.blueOffset = -5; }.colorTransform = colorNW;

}



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

Больше работ по теме:

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ