XVI Konferencja PLOUG Kościelisko Październik 2010 Oracle Hyperion Essbase Paweł Chomicz Dyrektor Centrum Kompetencyjnego Oracle w BizTech S.A. pawel.chomicz@biztech.pl; pch64@o2.pl 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 wartość 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ę.
Oracle Hyperion Essbase 195 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: F-K System analityczno-raportowy CRM HR ETL Hurtownia danych Strategiczna karta wyników Data mining SO 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, prognozowania 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 wielowymiarowej 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 algorytmó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.