Создание хранилища данных и системы бизнес-аналитики
Архитектура и технология функционирования системы. Извлечение, преобразование и загрузка данных. Oracle Database для реализации хранилища данных. Создание структуры хранилища. Механизм работы системы с точки зрения пользователя и с точки зрения платформы.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | русский |
Дата добавления | 22.02.2013 |
Размер файла | 2,2 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Измерение хранилища, связанное с географической распределенностью, также необходимо. Отчеты по различным показателям работы отдельных региональных представительств, а так же их сравнения, играют одну из первых ролей как на уровне топ-менеджмента, так и на уровне управления самих региональных представительств. Таблица измерений 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: Практическая реализация
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 процесса
1. источник данных, как совокупность таблиц оперативной системы и дополнительных справочников;
2. промежуточная область, которая представляет собой совокупность таблиц, использующихся исключительно в качестве промежуточного хранилища при загрузке хранилища данных;
3. приёмник данных - само хранилище данных.
Движение данных от источника к приёмнику называют потоком данных.
Процесс перегрузки данных - это реализация потока данных от единственного набора данных источника до наборов данных Хранилища Данных. Он может включать следующие операции:
1. Извлечение - стадия извлечения данных из источника и загрузки их в промежуточную область.
2. Выявление ошибок - данные проходят проверку на соответствие спецификации и потенциальную возможность загрузки в Хранилище Данных
3. Преобразование - данные группируются и приводятся к виду, конформному модели данных Хранилища данных
4. Распределение - данные распределяются на несколько потоков зависимости от способа, которым они должны быть загружены в Хранилище данных
5. Вставка - подготовленные данные поступают в хранилище данных.
Самый первый этап перегрузки данных - выгрузка информации из источника данных для программы-обработчика, аналитика или на сервер перегрузки данных. Выгрузка из структурированного источника данных не вызывает затруднений, возможно использование утилит СУБД, либо воспользоваться 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 
REGIONS.REGION_ID, 
REGIONS.REGION_NAME,
REGIONS.FILIAL_NAME, 
REGIONS.IN_SOURCE_UNIQUE_ID, 
REGIONS.END_DATE 
FROM REGIONS
where REGIONS.END_DATE = to_date('31.12.9999', 'dd.mm.yyyy')
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>
…………….
Далее идет обработка данных:
1) Join - объединение двух таблиц для анализа. Здесь мы сводим в единую таблицу данные из источника и получателя, для определения тех данных, которые надо передать.
2) 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('transformation error')" DESCRIPTION ="" EXPRESSION ="sessstarttime" EXPRESSIONTYPE ="GENERAL" NAME ="RECORD_DATE" PICTURETEXT ="" PORTTYPE ="OUTPUT" PRECISION ="19" SCALE ="0"/>
<TRANSFORMFIELD DATATYPE ="decimal" DEFAULTVALUE ="ERROR('transformation error')" DESCRIPTION ="" EXPRESSION ="1" EXPRESSIONTYPE ="GENERAL" NAME ="SOURCE_SYSTEM_ID" PICTURETEXT ="" PORTTYPE ="OUTPUT" PRECISION ="16" SCALE ="0"/>
<TABLEATTRIBUTE NAME ="Tracing Level" VALUE ="Normal"/>
........................
</TRANSFORMATION>
........................
3) 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)
and isnull(IN_SOURCE_UNIQUE_ID)" NAME ="INSERT" ORDER ="2" TYPE ="OUTPUT"/>
<GROUP DESCRIPTION ="" EXPRESSION ="not isnull(REGION_PK) 
and not isnull(IN_SOURCE_UNIQUE_ID)
and (REGION_NAME <> REGION_NAME1
 or ORG_NAME <> FILIAL_NAME)" NAME ="UPDATE" ORDER ="3" TYPE ="OUTPUT"/>
<GROUP DESCRIPTION ="" EXPRESSION ="isnull(REGION_PK)
and not isnull(IN_SOURCE_UNIQUE_ID)" NAME ="DELETE" ORDER ="4" TYPE ="OUTPUT"/>
........................
</TRANSFORMATION>
........................
4) exp_BEGIN/END_DATE - занесение данных о начале/конце актуальности записи.
5) Непосредственно внесение данных в таблицу хранилища выбранным методом 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\"/>
<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). Создание репозитория, а следовательно, и этих трех слоев - предмет рассмотрения данного раздела работы.
4.3.1 Создание физического слоя
На данном этапе мы, в первую очередь, создаем новый репозиторий, настраиваем связь с хранилищем данных и импортируем таблицы хранилища и связи между ними в созданный репозиторий (Рис 4.3 и Рис 4.4).
Рис 4.3 Создание репозитория
Рис 4.4 Импортирование структуры и таблиц хранилища на физический слой репозитория
BI сервер получает доступ к хранилищу данных через интерфейс OCI (Oracle Call Interface). На физическом уровне также можно создавать несколько внешних физических источников, при этом СУБД источника не играет никакой роли, т.к. Oracle BI предоставляет полный набор интерфейсов доступа к различным сторонним базам данных.
По сути репозиторий BI сервера на уровне физического слоя хранит записи обо всех внешних источниках данных и интерфейсах доступа к этим источникам. Также он хранит данные о структуре источников, таблицах и связях между ними. В данном случае мы получаем список всех таблиц хранилища и входящих в их состав полей. Связи между таблицами можно просмотреть, вызвав функцию «физическая диаграмма» (Рис 4.5).
Рис 4.5 Физическая структура импортированного хранилища
Именно этот слой BI сервера участвует в генерации прямых запросов к хранилищу данных.
4.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) и «Информационные панели» (OracleBI Interactive Dashboard).
OracleBI Answers обеспечивает конечных пользователей полным спектром возможностей для выполнения произвольных запросов и анализа. Приложение работает в чистой Web-среде и разработано для пользователей, желающих создавать новые аналитические запросы с нуля или модифицировать и изменять уже существующие аналитические запросы, отображающиеся на странице информационной панели.
OracleBI Interactive Dashboard - это инструмент создания интерактивных информационных панелей, на которых могут быть размещены все регламентные отчеты, а также отчеты по произвольным запросам, созданным в OracleBI Answers.
4.3.4.1 Создание тестового отчета
После подключения к web-серверу Oracle Analytics Web, можно приступать непосредственно к работе, связанной с анализом данных. Протестируем систему, для этого создадим тривиальный отчет, например, «Выручка по регионам и тарифным группам». Для создания отчета, выбираем приложение «Ответы» (OracleBI Answers). Слева мы видим нашу предметную область, столбцы которой являются критериями создания отчетов и ссылаются на сущности презентационного слоя BI сервера
Развернув столбцы предметной области, получим списки всех полей каждой из таблиц; создание отчета заключается в переносе требуемых полей в область генерации запроса, задании необходимых фильтров и настройке представления отчета
В качестве отображения отчета выбираем вид: «Таблица Среза» (Pivot Table), настраиваем отображение показателей по строкам и столбцам таблицы для наиболее удобного просмотра, в нашем случае: Столбцы - Группы Тарифов, Строки - Регионы, Показатели - Общая Выручка. Предварительные результаты можно просмотреть, отметив флаг «Показать результаты»
Для большей наглядности в отчет наряду с таблицей среза можно вставить диаграмму. Диаграмма также требует отдельной настройки; будем считать критерий «Регион» более важным для анализа в данный момент, настроим диаграмму таким образом, чтобы на ней выручка отображалась только в зависимости от региона, т.к. слишком насыщенные диаграммы трудны для восприятия. После настройки сохраняем и просматриваем общий отчет
Таким образом, можно составить отчет любой сложности в кратчайшие сроки. Сохраненные отчеты для быстрого и удобного использования помещаются в приложение «Информационные панели», после чего все пользователи, для которых доступна та или иная панель, могут использовать их в работе. Иллюстрации с настройкой отображения отчетов см. в приложении к дипломному проекту.
4.3.4.2 Создание региональной карты
Мы протестировали систему, создав отчет о выручке по регионам и тарифным группам. Отчеты, связанные с представлением различных показателей (выручка, количество клиентов и т.д.) по регионам, будут одними из самых востребованных при использовании системы. Связано это с широким региональным распределением компании Мегалайн. Для наибольшей наглядности подобного рода отчетов создадим интерактивную карту регионов, на которой будут отображаться значения исследуемых показателей. Для этого средствами Macromedia Flash MX [10] рисуем интерактивную карту регионов покрытия сотовой связи Мегалайн. Помещаем файл map.swf в папку …\OracleBI\oc4j_bi\j2ee\home\applications\analytics\analytics\
для возможности использования флэш-объекта как метода отображения отчета и настраиваем флэш-объект на обмен данными с сервером
После настройки карты включим ее в отчет «Выручка по регионам за год». Поставим фильтр на поле «год» с возможностью выбора значений. По умолчанию значение фильтра установим на 2009, для отображения ситуации по текущему году
Данный отчет сохраняем в «Информационные панели» для возможности использования его всеми пользователями системы.
Система бизнес-аналитики для оператора мобильной связи готова к использованию. Руководящий состав и аналитический штаб имеет полный инструментарий для доступа ко всей необходимой для анализа информации, также пользователи системы имеют возможность быстро и без привлечения программистов создавать все необходимые отчеты и использовать их для анализа текущей ситуации. Также есть возможность сохранять эти отчеты в «Информационные панели» как индивидуальные, так и общего пользования, что исключает необходимость множественного создания одинаковых отчетов.
4.3.5 Механизм работы системы
4.3.5.1 Механизм работы системы с точки зрения пользователя
Система построения отчетов, построенная на платформе Oracle BI, имеет два неоспоримых плюса для конечных пользователей. Во-первых, это чистая web-среда, позволяющая работать, откуда угодно, где есть доступ в интернет, можно даже использовать мобильные средства, например КПК. Во-вторых, простота, позволяющая пользователям, не имеющим навыков написания запросов к базам данных, создавать отчеты любой сложности буквально на лету. Пользователь оперирует известными ему понятиями и логикой, комбинируя критерии отчета, он создает запрос, настраивает визуальное представление отчета и получает результат в течение нескольких секунд. При этом он не задумывается о физической структуре данных в источниках и методах их изъятия.
4.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. Лисянский К. - “ Архитектурные решения и моделирование данных для хранилищ и витрин данных”. - Статья.
3. Кэти Бон - “ Конвертация данных для хранилищ”. - Статья.
4. Lilian Hobbs, Susan Hillson, Shilpa Lawande - “Oracle9iR2 Data Warehousing”. - 2003. - 519с.
5. http://www.olapcouncil.org/research/resrchly.htm - глоссарий OLAP-терминов
6. http://www.bi-verdict.com/ - информация по OLAP-технологии
7. http://olap.ru - портал, посвященный OLAP-технологиям
8. http://citforum.ru - библиотека по информационным технологиям
9. http://www.oracle.com - информация по программным продуктам Oracle.
10. Лещев Д.В. Flash MX 2004/ Теория и практика. Самоучитель. - СПб.: Питер, 2004.
11. Bill Inmon - “Building the Data Warehouse”
Приложение 1
1. SQL коды создания таблиц хранилища данных
Таблица календаря
create table calendar as
select
to_number(to_char(daterange, `yyyy')) as year,
to_number(to_char(daterange, `yyyymmdd')) as date_id,
to_char(daterange, `month') as month,
to_number(to_char(daterange,'mm')) as month_id,
to_number(to_char(daterange,'dd')) as day_id,
to_char(daterange,'day') as day,
daterange as calendar_date
from (
SELECT DateRange
FROM
(
select to_date(`01.01.2001','dd.MM.YYYY')-1 + level as DateRange
from dual
where (to_date(`01.01.2001','dd.MM.YYYY')-1+level) <= last_day(to_date(`1 2010','MM YYYY'))
connect by level<=9999
)
ORDER BY DateRange )
Таблица группы тарифов
CREATE table tariff_groups
(
tariff_group_id varchar2 (20 char),
tariff_group_name varchar2 (100 char),
record_date date,
constraint pk_tarif_groups primary key (_ariff_group_id)
)
Таблица тарифов
create table tariffs
(
_tariff_id number,
_tariff_name varchar2 (100 char),
_tariff_group_id number,
cost_per_minute number,
cost_per_sms number,
record_date date,
constraint pk_tarifs primary key (tariff_id)
)
;
Таблица клиентов
create table clients
(
client_id varchar2(20 char),
client_name varchar2(20 char),
client_phone number,
client_address varchar2(20 char),
client_email varchar2(20 char),
client_passport varchar2(100 char),
client_birth_date date,
begin_date date,
end_date date,
constraint pk_clients primary key (client_id)
)
;
Таблица регионов
create table regions
(
region_id varchar2(20 char),
region_name varchar2(100 char),
filial_name varchar2(100 char),
constraint pk_regions primary key (region_id)
)
;
Таблица показателей (фактов)
create table facts
(
date_id number,
region_id varchar2(20 char),
tariff_group_id varchar2(20 char),
tariff_id varchar2(20 char),
client_id varchar2(20 char),
callin_amount number,
callout_amount number,
callin_time number,
callout_time number,
smsin_amount number,
smsout_amount number
)
;
2. Код создания интерактивной карты на флеш (Actionscript 2.0).
stop();
//Принимает навигационную ссылку
var host;
var link;
var year;
//порог срабатывания окрашивания
var threshold = -10;
//Делаем навигационную ссылку глобальной для документа
_global.nav_link_p1 = "http://"+host+"/analytics/saw.dll?GO&path=";
_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 из BI
var xml_data;
var my_xml = new XML();
my_xml.parseXML(xml_data);
var len = my_xml.childNodes[0].childNodes.length;
//присваиваем значения переменным по регионам
for (i=0; i<len; i++) {
switch (my_xml.firstChild.childNodes[i].nodeName) {
case "2" :
v_Kavkaz = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;
_root.tKavkaz.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%";
break;
case "3" :
v_Sibir = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;
_root.tSibir.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%";
break;
case "4" :
v_Vostok = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;
_root.tVostok.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%";
break;
case "5" :
v_Centr = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;
_root.tCentr.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%";
break;
case "6" :
v_Moscow = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;
_root.tMoscow.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%";
break;
case "7" :
v_Ural = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;
_root.tUral.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%";
break;
case "8" :
v_Volga = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;
_root.tVolga.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%";
break;
case "9" :
v_NW = my_xml.firstChild.childNodes[i].childNodes[1].childNodes[0].nodeValue;
_root.tNW.text = my_xml.firstChild.childNodes[i].childNodes[0].childNodes[0].nodeValue+"%";
break;
}
//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);
}
import flash.geom.ColorTransform;
import flash.geom.Transform;
//Раскраска по регионам в зависимости от входного параметра
//порог срабатывания задаётся переменной "Threshold"
var Vostok:Transform = new Transform(this.MV_VOSTOK);
var Sibir:Transform = new Transform(this.MV_SIBIR);
var Moscow:Transform = new Transform(this.MV_MOSCOW);
var Centr:Transform = new Transform(this.MV_CENTR);
var Ural:Transform = new Transform(this.MV_URAL);
var Volga:Transform = new Transform(this.MV_VOLGA);
var Kavkaz:Transform = new Transform(this.MV_KAVKAZ);
var NW:Transform = new Transform(this.MV_NW);
//вызов функций раскрашивания
cVostok (v_Vostok);
cSibir (v_Sibir);
cUral (v_Ural);
cVolga (v_Volga);
cKavkaz (v_Kavkaz);
cCentr (v_Centr);
cMoscow (v_Moscow);
cNW (v_NW);
//vostok
function cVostok (v_Vostok){
//Red
if (v_Vostok <= threshold) {
var colorVostok:ColorTransform = new ColorTransform();
colorVostok.redOffset = 50;
colorVostok.greenOffset = -150;
colorVostok.blueOffset = -100; }
//Yellow
else if (v_Vostok > threshold && v_Vostok < 0 ) {
var colorVostok:ColorTransform = new ColorTransform();
colorVostok.redOffset = +180;
colorVostok.greenOffset = +100;
colorVostok.blueOffset = -5; }
Vostok.colorTransform = colorVostok;
}
//sibir
function cSibir (v_Sibir){
//Red
if (v_Sibir <= threshold) {
var colorSibir:ColorTransform = new ColorTransform();
colorSibir.redOffset = 50;
colorSibir.greenOffset = -150;
colorSibir.blueOffset = -100; }
//Yellow
else if (v_Sibir > threshold && v_Sibir < 0 ) {
var colorSibir:ColorTransform = new ColorTransform();
colorSibir.redOffset = +180;
colorSibir.greenOffset = +100;
colorSibir.blueOffset = -5; }
Sibir.colorTransform = colorSibir;
}
//ural
function cUral (v_Ural){
//Red
if (v_Ural <= threshold) {
var colorUral:ColorTransform = new ColorTransform();
colorUral.redOffset = 50;
colorUral.greenOffset = -150;
colorUral.blueOffset = -100; }
//Yellow
else if (v_Ural > threshold && v_Ural < 0 ) {
var colorUral:ColorTransform = new ColorTransform();
colorUral.redOffset = +180;
colorUral.greenOffset = +100;
colorUral.blueOffset = -5; }
Ural.colorTransform = colorUral;
}
//volga
function cVolga (v_Volga){
//Red
if (v_Volga <= threshold) {
var colorVolga:ColorTransform = new ColorTransform();
colorVolga.redOffset = 50;
colorVolga.greenOffset = -150;
colorVolga.blueOffset = -100; }
//Yellow
else if (v_Volga > threshold && v_Volga < 0 ) {
var colorVolga:ColorTransform = new ColorTransform();
colorVolga.redOffset = +180;
colorVolga.greenOffset = +100;
colorVolga.blueOffset = -5; }
Volga.colorTransform = colorVolga;
}
//kavkaz
function cKavkaz (v_Kavkaz){
//Red
if (v_Kavkaz <= threshold) {
var colorKavkaz:ColorTransform = new ColorTransform();
colorKavkaz.redOffset = 50;
colorKavkaz.greenOffset = -150;
colorKavkaz.blueOffset = -100; }
//Yellow
else if (v_Kavkaz > threshold && v_Kavkaz < 0 ) {
var colorKavkaz:ColorTransform = new ColorTransform();
colorKavkaz.redOffset = +180;
colorKavkaz.greenOffset = +100;
colorKavkaz.blueOffset = -5; }
Kavkaz.colorTransform = colorKavkaz;
}
//centr
function cCentr (v_Centr){
//Red
if (v_Centr <= threshold) {
var colorCentr:ColorTransform = new ColorTransform();
colorCentr.redOffset = 50;
colorCentr.greenOffset = -150;
colorCentr.blueOffset = -100; }
//Yellow
else if (v_Centr > threshold && v_Centr < 0 ) {
var colorCentr:ColorTransform = new ColorTransform();
colorCentr.redOffset = +180;
colorCentr.greenOffset = +100;
colorCentr.blueOffset = -5; }
Centr.colorTransform = colorCentr;
}
//moscow
function cMoscow (v_Moscow){
//Red
if (v_Moscow <= threshold) {
var colorMoscow:ColorTransform = new ColorTransform();
colorMoscow.redOffset = 50;
colorMoscow.greenOffset = -150;
colorMoscow.blueOffset = -100; }
//Yellow
else if (v_Moscow > threshold && v_Moscow < 0 ) {
var colorMoscow:ColorTransform = new ColorTransform();
colorMoscow.redOffset = +180;
colorMoscow.greenOffset = +100;
colorMoscow.blueOffset = -5; }
Moscow.colorTransform = colorMoscow;
}
//North-West
function cNW (v_NW){
//Red
if (v_NW <= threshold) {
var colorNW:ColorTransform = new ColorTransform();
colorNW.redOffset = 50;
colorNW.greenOffset = -150;
colorNW.blueOffset = -100; }
//Yellow
else if (v_NW > threshold && v_NW <
0 ) {
var colorNW:ColorTransform = new ColorTransform();
colorNW.redOffset = +180;
colorNW.greenOffset = +100;
colorNW.blueOffset = -5; }
NW.colorTransform = colorNW;
}
Размещено на Allbest.ru
Подобные документы
Построение схемы хранилища данных торгового предприятия. Описания схем отношений хранилища. Отображение информации о товаре. Создание OLAP-куба для дальнейшего анализа информации. Разработка запросов, позволяющих оценить эффективность работы супермаркета.
контрольная работа [1,9 M], добавлен 19.12.2015Методы построения хранилища данных на основе информационной системы реального коммерческого предприятия. Основные аналитические задачи, для решения которых планируется внедрение хранилищ данных. Загрузка процессоров на серверах. Схемы хранения данных.
контрольная работа [401,0 K], добавлен 31.05.2013Метод извлечения информации о личностных характеристиках пользователя с помощью технологии распознавания лица. Разработка алгоритма работы рекомендательной системы, основанной на психологическом портрете пользователя, хранилища баз данных и интерфейса.
курсовая работа [815,2 K], добавлен 21.09.2016Описание разрабатываемой программы с точки зрения пользователя и программиста. Поэтапная разработка программной системы. Создание базы данных в Access. Разработка структуры классов. Создание структуры для хранения данных. Проектирование интерфейса.
курсовая работа [1,4 M], добавлен 07.08.2013Рассмотрение OLAP-средств: классификация витрин и хранилищ информации, понятие куба данных. Архитектура системы поддержки принятия решений. Программная реализация системы "Abitura". Создание Web-отчета с использованием технологий Reporting Services.
курсовая работа [2,7 M], добавлен 05.12.2012Вечное хранение данных. Сущность и значение средства OLAP (On-line Analytical Processing). Базы и хранилища данных, их характеристика. Структура, архитектура хранения данных, их поставщики. Несколько советов по повышению производительности OLAP-кубов.
контрольная работа [579,2 K], добавлен 23.10.2010Понятие и структура хранилища данных, его составные элементы и назначение. Технологии управления информацией. Методика создания базы данных и составления ее схемы, пользовательские формы, структура и содержание таблиц. Программная реализация базы данных.
дипломная работа [1,4 M], добавлен 13.04.2010Определение многомерной модели данных для удовлетворения основных информационных потребностей предприятия. Экстракция, загрузка и перенос данных из различных источников данных. Разработка собственных ETL–систем. Оптимизация работы хранилища данных.
презентация [9,1 M], добавлен 25.09.2013Файловая организация баз данных. Взаимодействие администратора баз данных с пользователями. Иерархическая и сетевая даталогические модели системы управления базами данных. Принципиальная организация системы обработки информации на основе БД-технологии.
реферат [762,0 K], добавлен 23.12.2015Разработка программного обеспечения для анализа полученных из хранилища данных. Система SAS Enterprise Miner и система Weka. Расчёт капитальных затрат на создание ПМК для анализа полученных из хранилища данных с использованием библиотеки XELOPES.
дипломная работа [1,4 M], добавлен 07.06.2012