Oracle Hyperion Essbase

XVI Konferencja PLOUG
Kościelisko
Październik 2010
Oracle Hyperion Essbase
Paweł Chomicz
Dyrektor Centrum Kompetencyjnego Oracle w BizTech S.A.
[email protected]; [email protected]
Abstrakt. Wraz z Hyperionem Oracle kupił całą masę produktów do analiz danych. Zakup w sposób zasadniczy dopełnia Oraclową
ofertę Business Intelligence. Baza danych Hyperion Essbase to wielowymiarowa baza danych o olbrzymich możliwościach analitycznych. Wielowymiarowy Essbase jest zupełnie innym produktem w stosunku do relacyjnej Oracle Database, również z opcją OLAP:
inaczej organizuje i przechowuje dane i ich strukturę, ma inny interfejs do zarządzania. Inny jest cykl produkcji aplikacji i bazy danych.
Inne procesy obsługujące dane w systemie. To wszystko jest specyficzne i nie intuicyjne do opanowania nawet dla dobrych administratorów i deweloperów relacyjnej bazy Oracle. Do tego dochodzą zagadnienia zasilania danymi struktur wielowymiarowych oraz prezentacja
sprawozdań i export danych do postaci relacyjnej.
Referat prezentuje: różnice pomiędzy relacyjnymi i wielowymiarowymi bazami danymi; filozofię i rozwiązania zastosowane w środowisku Hyperion Essbase; miejsce Essbase wśród innych rozwiązań Oracle Bussines Intelligence; cykl planowanie i tworzenie kompletnej
aplikacji i bazy danych; inne rozwiązania Oracle Bussines Intelligence umożliwiające powiązanie Essbase z danymi relacyjnymi.
Artykuł został opracowany na podstawie informacji pozyskanych z Internetu: list dyskusyjnych, prezentacji Oracle, Hyperion, Sunopsis
i innych, oraz dokumentacji produktów i książek. Między innymi „Teoria relacyjnych baz danych” – Edgar Frank Codd.
Informacja o autorze. Autor w latach 1992-1999 prowadził szkolenia IT oraz szkolenia dla trenerów. W latach 1999-2004 zbudował
i prowadził zespół Oracle w Altkom Akademii. W latach 2005-2006 zbudował i prowadził Zespół Aplikacji Oracle w Matrix.pl. Aktualnie jest Dyrektorem Centrum Kompetencyjnego Oracle w BizTech S.A.
Oracle Hyperion Essbase
191
1. Wstęp
Podstawę systemów BI stanowi hurtownia danych, która jest bazą zintegrowanych, oczyszczonych i poddanych transformacji danych. Na takiej bazie danych kierownictwo, dyrektorzy i analitycy mogą wykonywać wiele różnego typu analiz i raportów, które pomagają szybciej i skutecznie
podejmować decyzje.
Podstawowym celem systemów BI jest dostarczenie właściwych informacji właściwym kosztem, we właściwym miejscu i czasie.
Trzeba jednak mieć na uwadze, że definicja hurtowni danych podana powyżej nie jest już teraz
taka oczywista. Na przykład narzędzia takie jak ODI umożliwiają transformacje danych już na ich
źródle.
System BI w zależności od potrzeb przedsiębiorstwa mogą składać się z różnych elementów
i posiadać różną funkcjonalność. Mogą mieć charakter rozwiązań typu CPM bądź postać systemów złożonych z kilku modułów o określonej funkcjonalności.
Systemy BI mogą zawierać elementy oparte o podstawowe technologie:
• OLAP – analizy wielowymiarowe;
• Data mining – eksploracja danych;
i inne, uzupełniające lub dziedzinowe np.:
• GIS – gromadzenie i analiza informacji przestrzennych.
Przed kupieniem w 2007 roku za 3,3 mld USD firmy Hyperion, Oracle oferował co prawda
rozwiązania typu OLAP i DM ale nie były to rozwiązania doskonałe. Zakup Hyperiona radykalnie
zmienił ofertę Oracle. Z odpowiednio dobranych komponentów Siebel Analytics (Obecnie Oracle
BI), Hyperion OLAP (obecnie Oracle Essbase) oraz EL-T Sunopsis (obecnie ODI – Oracle Data
Integrator) Oracle stworzył wyjątkowe i niezwykle skuteczne, kompletne środowisko BI.
Dla uproszczenia dalej pojęcia Hyperion OLAP, Hyperion i Essbase stosowane są zamiennie.
1.1. Model relacyjny i wielowymiarowy
Model relacyjny:
Zazwyczaj mylimy pojęcia: relacją nazywamy referencje a nie tabelę. Dla uporządkowania
wiedzy i nazewnictwa dalej opisano podstawy teorii relacyjnych baz danych którą opracował
przez nieżyjący już Edgar Frank Codd. Teoria ta została opublikowana w roku 1970.
Relacja R – tabela.
Krotka t – wiersz.
Atrybut A – kolumna.
Liczebność relacji m – liczba krotek w tabeli.
Stopień relacji n – liczba atrybutów.
Klucz główny K – jednoznaczny identyfikator tabeli.
Dziedzina D – zbiór dopuszczalnych wartości atrybutu.
Schemat relacji R(A1,A2, ...,An).
Baza danych – zbiór relacji.
192
Paweł Chomicz
Schemat bazy danych – zbiór schematów relacji.
Dziedzina D to zbiór wartości skalarnych tego samego typu. Dziedzina atrybutu – każdy atrybut A wywodzi sie z dokładnie jednej dziedziny D.
Relacja r(R) o schemacie R(A1,A2, ...,An) na zbiorze dziedzin {D1,D2, ...,Dn} jest zbiorem
krotek r = {t1, t2, ..., tm} postaci t =< v1, v2, ..., vn >, będących uporządkowana lista, gdzie vi, dla
0 < i ¬ n należy do zbioru Di [ {NULL}, n jest stopniem relacji R, zaś m jej liczebnością.
Każda relacja ma właściwe sobie znaczenie, które formalnie można przedstawić w postaci predykatu bądź funkcji logicznej. Predykat dla danej relacji stanowi kryterium zgody na jej uaktualnienie.
Rodzaje relacji:
• nazwane;
• podstawowe;
• pochodne;
• perspektywy;
• perspektywy materializowane (migawki);
• wyniki zapytań;
• wyniki pośrednie.
Własności obiektów relacyjnych:
• nie istnieją podwójne krotki (powtarzające się);
• krotki nie są uporządkowane (ich kolejność nie ma znaczenia);
• atrybuty nie są uporządkowane (jw.);
• wszystkie wartości atrybutów są atomowe;
• w ramach bazy danych dziedziny maja jednoznaczne nazwy;
• w ramach bazy danych relacje nazwane maja jednoznaczne nazwy;
• w ramach relacji atrybuty posiadają jednoznaczne nazwy.
Integralność danych relacyjnych:
Reguły integralności pomagają SZBD nadzorować poprawność danych wprowadzanych do bazy. Mogą one dotyczyć pojedynczego atrybutu bądź całej relacji.
Wyróżniamy ograniczenia:
• klucze kandydujące;
• klucze główne (PRIMARY KEY);
• klucze alternatywne;
• klucze obce (FOREIGN KEY);
• unikalność (UNIQUE);
• zawężenie dziedziny (CHECK);
• wartość niepusta (NOT NULL).
Oracle Hyperion Essbase
193
Klucz kandydujący:
Niech R będzie relacja. Klucz kandydujący w relacji R jest podzbiorem K zbioru atrybutów
relacji R posiadającym własność jednoznaczności i nieredukowalności. Klucz kandydujący zawierający więcej niż jeden atrybut nazywa sie kluczem złożonym, natomiast zawierający dokładnie jeden atrybut - kluczem prostym. Klucze kandydujące zapewniają mechanizmy adresowania na
poziomie krotek.
Klucz główny i alternatywny
W sytuacji, w której relacja posiada wiele kluczy kandydujących, jeden z nich powinien być
wybrany jako klucz główny, pozostałe natomiast określa się mianem kluczy alternatywnych.
Klucz obcy:
Niech R2 będzie relacja. Klucz obcy relacji R2 jest to podzbiór FK zbioru atrybutów R2,
taki że:
• istnieje relacja R1 (relacje R1 i R2 nie musza być różne) z kluczem kandydującym CK oraz:
• w każdej chwili każda wartość FK w aktualnej wartości relacji R2 jest taka sama jak war-
tość CK w pewnej krotce aktualnej wartości relacji R1.
Wartość klucza obcego stanowi referencje do krotki docelowej zawierającej wartość odpowiadającego mu klucza kandydującego.
Ograniczenia atrybutu:
Na każdy atrybut relacji można narzucić ograniczenia dotyczące:
• dziedziny (określenie typu);
• niepowtarzalności wartości (UNIQUE);
• nie dopuszczania wartości pustej (NOT NULL);
• dowolny warunek logiczny ograniczający dziedzinę (CHECK).
Integralność:
Integralność referencyjna:
Integralność referencyjna zapewnia, ze baza nie zawiera żadnych niedopuszczalnych wartości
klucza obcego i narzuca je poprzez tzw. więzy referencyjne.
Integralność encji:
Żaden składnik klucza głównego relacji podstawowej nie może akceptować wartości pustej.
Integralność atrybutu:
Wartości atrybutu są pobierane z odpowiedniej dziedziny.
Model wielowymiarowy:
Miary albo fakty:
• wartości ciągłe, numeryczne
• typowe miary: wartość sprzedaży, koszt, zysk, sprzedana ilość
• miary mogą być:
ƒ addytywne (we wszystkich wymiarach) – np. liczba sprzedanych sztuk;
194
Paweł Chomicz
ƒ częściowo addytywne (addytywne w niektórych wymiarach) – np. stan w magazynie
sklepu;
ƒ nieaddytywne.
Wymiary:
• wartości dyskretne, niezmienne lub rzadko zmienne;
• nadają znaczenie danym (miarom, faktom);
• typowe wymiary: sklep, faktura, klient, czas, produkt;
• hierarchie umożliwiają organizację danych na różnych poziomach agregacji; doskonałym
przykładem jest czas: rok, miesiąc, dzień itd.;
• poziomy reprezentuje pozycję w hierarchii;
• atrybuty dostarczają dodatkowych informacji o danych, np. kolor, waga, tydzień roku.
Kostki:
Dane na potrzeby przetwarzania OLAP są reprezentowane właśnie w postaci wielowymiarowej: kostki 3 lub więcej wymiarowe. Takie właśnie logiczne kostki stanowią sposób organizacji
miar mających te same wymiary.
1.2. OLAP
Rozwiązanie to umożliwia użytkownikom biznesowym wykonanie analiz wielowymiarowych.
Typowym przykładem takich analiz są:
• zapytanie o sprzedaż produktów jaką odnotowało przedsiębiorstwo w kolejnych tygodniach,
miesiącach, latach,
• zapytanie o sprzedaż produktów z podziałem na rodzaje produktów,
• zapytanie o sprzedaż produktów z podziałem na oddziały Odpowiedzi tego typu zapytania
wspomagają kadrę kierowniczą w procesie podejmowania decyzji mającym przynieść poprawę sytuacji przedsiębiorstwa. Umożliwiają wykrycie wąskich gardeł sprzedaży, wykrycie produktów przynoszących największy zysk lub stratę.
195
Oracle Hyperion Essbase
Rozwiązania tego typu oparte są o model przetwarzania danych, nazwany „przetwarzaniem
analitycznym on-line” (ang. OnLine Analytical Processing OLAP). Analiza danych polega tu na
obliczaniu agregatów dla zadanych „wymiarów”. Proces analizy jest całkowicie sterowany przez
użytkownika. i nazywany jest analizą danych sterowaną zapytaniami.
Centralnym elementem systemu jest baza danych. System złożony jest z szeregu warstw. Dane
z wielu źródeł np. z systemów produkcyjnych przedsiębiorstwa (np.: F-K i CRM). Przenoszone są
do pierwszej warstwy. Następnie są poddawane procesom integracji, oczyszczania, transformacji,
po czym są ładowane do kolejnej warstwy zawierającej struktury wielowymiarowe (kostki, tabele
połączone w schematy płatka śniegu czy gwiazdy). Kolejnym elementem systemu jest warstwa,
która przekłada struktury informatyczne na struktury biznesowe zrozumiałe dla użytkowników
systemu. Warstwa ta zawiera również interfejs umożliwiający użytkownikom nieznającym technologii informatycznych wykonywanie skomplikowanych analiz i raportów. Ogólny schemat pokazany jest na rysunku poniżej:
System
analityczno-raportowy
F-K
Strategiczna karta wyników
CRM
ETL
HR
SO
Hurtownia
danych
Data mining
Planowanie i budżetowanie
1.3. Data mining
Analiza danych z wykorzystaniem systemów zgodna z modelem OLAP, jest sterowana zazwyczaj przez analityka. Analityk formułuje szczegółowe zapytania i na ich podstawie dokonuje analizy danych zawartych w hurtowniach danych. Analiza tego typu zakłada, że użytkownik, posiada
pełną wiedzę o przedmiocie analizy oraz potrafi sterować procesem. W przeciwieństwie do rozwiązań OLAP, technologie data mining (eksploracja danych) opierają się o całkowicie inne rozwiązania. Technologie te umożliwiają wykonanie zadań polegających na znajdowaniu nieznanych
dotychczas zależności i związków pomiędzy danymi. Eksploracja danych umożliwia rozwiązywanie zadań, które ze względu rozmiar są trudne do przeprowadzenia oraz rozwiązywanie tych problemów, dla których nie dysponujemy pełną wiedzą, gdyż wiedzę tę chcemy wydobyć z danych.
Technologie eksploracji danych umożliwiają dostęp do danych w przypadku, kiedy nie potrafimy sformułować zapytania z wykorzystaniem języka dostępu do bazy danych.
196
Paweł Chomicz
Zapytania formułowane są na znacznie wyższym poziomie abstrakcji niż pozwala na to standard SQL. Przy wykorzystaniu technologii eksploracji danych formułowane zadania rozwiązywane są automatycznie.
Eksploracja danych wiąże się z kilkoma typami działań. Są to między innymi: klasyfikacja,
grupowanie pojęciowe, zbiory przybliżone, reguły asocjacyjne.
Bardzo prostym przykładem zastosowania eksploracji danych może być wykorzystanie klasyfikacji do udzielenia odpowiedzi na pytanie „Czy klient w przyszłości może przestać kupować
produkt V?”. Przyjmijmy, jako model eksploracji danych funkcję liniową (y = Ax + B).
Załóżmy, że posiadamy w bazie danych następujące informacje o klientach:
• wartość cechy A klienta,
• wartość cechy B klienta,
• czy klient kupował produkt V w przeciągu ostatnich dwóch miesięcy ? (TAK - trójkąty /
NIE - kółka).
Wybieramy pewną reprezentacyjną grupę klientów. System eksploracji danych opierając się
o ww. informacje o klientach oraz o model eksploracji danych wyznaczy współczynniki A i B.
Następnie eksperci powinni zinterpretować otrzymane wyniki.
Po wykonaniu powyższych kroków otrzymujemy algorytm eksploracji danych pozwalający
określić, którzy klienci skłonni są przestać kupować produkt V, co pozwala wcześniej podjąć
działania zapobiegające takiej sytuacji.
.
Oracle Hyperion Essbase
197
2. Podstawowe cechy Hyperion OLAP
Baza danych Hyperion Essbase to wielowymiarowa baza danych o olbrzymich możliwościach
analitycznych.
Wielowymiarowy Essbase jest zupełnie innym produktem w stosunku do relacyjnej Oracle
Database, również z opcją OLAP: inaczej organizuje i przechowuje dane i ich strukturę, ma inny
interfejs do zarządzania. Inny jest cykl produkcji aplikacji i bazy danych. Inne procesy obsługujące
dane w systemie. Essbase ma również wbudowane algorytmy do Data Mainingu. To wszystko jest
specyficzne i choć intuicyjne, to nie proste bez właściwego przygotowania do opanowania nawet
dla dobrych administratorów i deweloperów relacyjnej bazy Oracle. Do tego dochodzą zagadnienia zasilania danymi struktur wielowymiarowych oraz prezentacja sprawozdań i export danych do
postaci relacyjnej.
Podstawowe cechy Essbase:
• Platforma dedykowana do raportowania, analiz, modelowania i planowania.
• Wykorzystanie kategorii biznesowych zamiast np. nazw pól i tabel (np. taryfa, jednostka
biznesowa, pozycja budżetowa, typ zadania remontowego itp.).
• Możliwość dalszego przetwarzania danych (np. wyliczania wskaźników, alokacji, progno-
zowania itp.).
• Łatwość tworzenia scenariuszy analitycznych „co-jeśli” bez konieczności modyfikowania
danych w systemach źródłowych.
• Dane w postaci zagregowanej gotowe do prezentacji – brak konieczności czasochłonnego
generowania raportów za pomocą zapytań.
• Przejrzysta struktura inteligentnych wymiarów w postaci drzewa z możliwością tworzenia
alternatywnych struktur, nieaddytywnych ścieżek agregacji, wykorzystania wbudowanych
mechanizmów inteligencji finansowej i czasowej.
• Unikalna możliwość bezpośredniego zapisu danych do bazy wielowymiarowej – np. przy
użyciu dodatku do MS Excel.
• Unikalna możliwość ładowania dużych ilości danych detalicznych do bazy wielowymiaro-
wej z niespotykaną dotąd na rynku wydajnością – nawet do poziomu wielu milionów pojedynczych klientów, faktur, transakcji itp.
• Intuicyjne narzędzia raportujące i administracyjne – Hyperion Analyzer, Hyperion Reports,
Hyperion Performance Suite, MS Excel Add-in.
• Możliwość załączania dowolnych plików i komentarzy do dowolnych komórek w bazie
wielowymiarowej.
• Wbudowane algorytmy realizujące Data Mining, możliwość dołączania własnych algoryt-
mów.
• System bezpieczeństwa zintegrowany z systemami korporacyjnymi (np. NTLM, LDAP,
MSAD) ograniczający dostęp do dowolnego obszaru bazy niezależnie od narzędzia dostępowego.
• Obsługa standardów MDX, XMLA, wielowalutowość, trigery.
198
Paweł Chomicz
3. Dostęp do danych wielowymiarowych Essbase. Zasilanie danymi. Konwersja na dane relacyjne
Zagadnienie nie jest proste. Poniżej zostaną zaprezentowane dwa rozwiązania: przy użyciu
Oracle Warehouse Builder – OWB oraz pakietu Oracle Business Intelligence. Z powodu ograniczonego miejsca a także aby nie dublować informacji poniżej zostaną przedstawione jedynie odpowiednie odnośniki, w trakcie referatu omówione będą natomiast kluczowe momenty procesu.
Oracle Warehouse Builder – OWB:
OWB 11gR2 umożliwia dostęp do wielowymiarowych struktur Essbase i konwersję ich do postaci relacyjnej. Realizuje się to za pośrednictwem drivera JDBC Essbase oraz odpowiedniego
modułu RKM z pakietu Oracle Data Integrator – ODI. Odpowiedni moduł RKM definiują 4 pliki:
• ess_es_server.jar;
• ess_japi.jar;
• odihapp_common.jar;
• 4. odihapp_essbase.jar.
Szczegółowo procedura jest opisana na: http://www.rittmanmead.com/2010/03/17/oraclewarehouse-builder-11gr2-importing-essbase-cubes-using-odi-knowledge-modules-part-1/. Tam też
znajdują się konieczne skrypty które należy uruchomić w OMB Plus.
Oracle Business Intelligence:
Podłączenie się do Essbase w warstwie fizycznej narzędzia Administration Tool wchodzącego
w skład pakietu Oracle Business Intelligence umożliwia wykonanie inżynierii odwrotnej na schemacie Essbase oraz użycie modelu i danych w warstwach logicznej i prezentacji.
Kompletny przykład wraz ze zrzutami ekranów znajduje się pod adresem:
http://st-curriculum.oracle.com/obe/fmw/bi/biee/r1013/fed_data/fed_data.html.
4. Podsumowanie
Dobrze się dzieje, że Oracle ma bardzo dużo pieniędzy i bardzo dobrych specjalistów do pozyskiwania gotowych technologii. Prowadzone przez ostatnie lata zakupy pozwoliły Oracle stworzyć
bardzo dobre, wydajne i ergonomiczne rozwiązania do przetwarzania, przechowywania i udostępniania informacji. Środowisko analityczne oparte o Siebel Analytics (Obecnie Oracle BI), Hyperion OLAP (obecnie Oracle Essbase) oraz EL-T Sunopsis (obecnie ODI – Oracle Data Integrator)
nie ma sobie obecnie równych.