Oracle Business Intelligence

"Az adattárház lekérdezésekre és analízisre optimalizált adatbázis." Ezt a tömör definíciót kifejtve az alábbiakat lehetne mondani:

• Egy vagy több különböző, általában OLTP (on-line transaction processing) rendszerben különböző (általában tranzakciós) adatok keletkeznek, ezek a rendszerek vagy egymástól függetlenül, vagy integráltan működhetnek, egymás között adatokat cserélhetnek.

• Ezekből az adatforrásokból ún. ETL (Extraction-(Transportation)-Transformation-Loading) folyamat segítségével egy adattárházat táplálunk. Az Extraction folyamat során a szükséges adatokat a forrásadatbázisokban azonosítjuk, kinyerjük. A kinyert adatokat a célrendszerbe vagy egy átmeneti rendszerbe (staging area) szállítjuk (Transportation), ahol feldolgozzuk, konzisztens formára hozzuk (Transformation). A Loading a feldolgozott adatok adattárházba töltését takarja. Fontos megérteni, hogy az ETL egy átfogó folyamatot takar, nem pedig egy jól meghatározott lépéssorozatot.

• A cél az, hogy elsősorban üzleti felhasználók számára összesített, konszolidált formában egységes képet tudjunk adni a rendszerekben található adatok (a vállalat) egészéről.

Az ábrán egy lehetséges adattárház-architektúra szerepel: a forrásokból származó adatokat először egy ún. staging area-ba töltjük előfeldolgozás, tisztítás céljából (a staging area nem szükségszerűen része egy adattárháznak). Az adattárházaknak fontos részei az összesítések (Summaries), amiket az Oracle materializált nézeteknek hív. Az összesítések időigényes aggregálások, számítások előre letárolt eredményei. Végül az adatokat csoportosíthatjuk akár részlegek szerint is: specifikus adattárházakat (data marts) építhetünk a „fő” adattárházunkból.

Az adattárházaknak négy fontos tulajdonságuk van:

1. téma-orientált: egy vállalatot több szervezeti egységre oszthatunk, melyek döntéshozóinak más és más adatokra van szükségük az adott területet vagy a vállalat egészét érintő döntések meghozatalához
   
2. Vállalati szinten integrált: az adattárházakba különböző heterogén forrásokból kerülnek be az adatok, melyeket ahhoz, hogy egyetlen, konzisztens képet tudjanak adni a vállalat egészéről transzformálni, konvertálni kell.
   
3. El nem tűnő: szemben a tranzakciós rendszerekkel, ahol az adatok módosítása, törlése mindennapi művelet, az adattárházakban levő adatok a betöltés után csupán lekérdezhetőek.
   
4. Időben változó: minden adattárházban szereplő adat az időnek egy adott pillanatában érvényes
   

Fontos kihangsúlyozni, hogy végső soron az adattárházak felhasználói nem IT-s emberek, hanem általában controllerek, managerek, vezetők, ezért olyan technológiákra is szükség van, amik az adattárházakban levő információkat emészthető formában képesek „tálalni”, ad-hoc módon lekérdezhetővé teszik, azokból jelentéseket, riasztásokat képesek generálni, összefoglalva: az üzleti döntések meghozatalát támogatják.

Forrás: Oracle Data Warehousing Guide

Megkésve bár, de újult erővel én is ismét belevetem magam az Oracle technológiák gyönyöreibe :)

Tavaly decemberben abban maradtam Kardkovács Zsolttal, hogy a 2 kredites önálló labor tárgyat akkor nem teljesítem, hanem ebben a félévben a 8 kredites rendszertervezés mellett fogom azt is.

A rendszertervezés izgalmasnak ígérkezik, ugyanis mind a konzulensek, mind a kollégáim, és én is igen csak hajlok afelé, hogy összekössem a labortémámat a munkámmal: a cégnél fejlesztett szoftvert mint adatforrást felhasználva egy BI rendszert "fölé" tervezni, megvalósítani.

A következő hét végéig terveim szerint körvonalazódni fog a megvalósítandó feladat, a cél, addig is megpróbálok minél több ismeretet összeszedni az Oracle Data Integratorról, és erről a blogon be is számolnék.

Külön jó, hogy most tavasszal az Oracle Szemináriumsorozat témája is a nagyméretű adattárházak és BI rendszerek. Kíváncsian várom, hogy milyen lesz, habár a most csütörtöki számomra egy picit csalódás volt (nagyon semmitmondó volt az előadás).

Elkészült a két szükséges dokumentáció, ami a féléves munkámat tartalmazza. Sajnos az időhiány nagy úr, egyéb elfoglaltságaim (lakásvásárlás, munka) miatt közel sem sikerült olyan részletességgel feldolgozni a témát, mint ahogy azt eredetileg terveztem.

A tárgyfelelősnek készült dokumentum itt, a konzulenseknek készült pedig itt található.

Ebben a bejegyzésben az Oracle BI Publisher programjáról szerettem volna írni, de egy rejtélyes hiba ezt meghiúsította: egyszer már kipróbáltam (két kattintás erejéig) a Publisher-t, de mostanra a Microsoft Word-ből eltűnt a menüpontja.

Az újratelepítés részben segített, a menüpont visszakerült a helyére, de a Log On menüpontra kattintva az alábbi hibaüzenet fogad:


A Word súgója szerint ennek az lehet az oka, hogy egy szükséges DLL nincs regisztrálva. Az interneten rákeresve a hibaüzenetre, úgy tűnik, nem vagyok egyedül:

ahol egy hozzászóló ad is megoldást: Uninstalled everything including .net runtime, bip, word. Ehhez nekem most nincs időm/kedvem :)

A BI Publisher amúgy egy olyan eszköz lenne, amivel rendkívül rugalmas módon, többféle formátumban, többféle adatforrást felhasználva lehet sablon alapú jelentéseket készíteni. A képernyőmentésen jól látható módon a Microsoft Word-be integráltan lehetne használni, már amikor működik :)

Az Oracle Delivers egy olyan eszköz, aminek a segítségével bizonyos feltételek teljesülése esetén adott tartalmú üzeneteket lehet eljuttatni a címzetteknek.

A feltétel lehet időbeli – minden héten hétfőn reggel 7:30-kor – vagy logikai jellegű. Az időbeli feltételeket a Scheduler kezeli, a megadott időpontokban elindítja az iBot-nak nevezett „programokat”. Segítségével be lehet állítani, hogy mikortól kezdve hány órakor, milyen gyakorisággal (egyszeri, napi, heti, havi) és meddig indítsa el az iBot-ot, azaz mi az iBot élettartama.

Például lehet egy olyan – az Answers felületen összeállított – táblázatunk, amik az eladási statisztikák változásait mutatják havi bontásban. Valós igény lehet az, hogy bizonyos személyek e-mailben megkapják ezeket a táblázatokat, színkódokkal jelezve a kimagaslóan jó/rossz értékeket.

Logikai jellegű feltételek esetén (Conditional iBot) az iBot-hoz egy filtert lehet csatolni. A filterek az Answers felületen összeállított request-ek találatait szűkítik. Egy conditional iBot akkor fut le (akkor tekinthető triggereltnek), ha a request legalább egy találatot ad vissza.

Ennek a gyakorlati alkalmazására példa lehet a romló statisztikák esetén történő figyelmeztetés. Például minden hónap elején lehetőség van arra, hogy figyelmeztetést küldjünk az illetékes manager-eknek, ha valamilyen mutató (pl.: előző hónapban eladott mennyiség) egy adott érték alá csökken.


Az eddig említett lehetőségeken felül arra is mód van, hogy egy iBot bemenő feltétele egy másik iBot futási eredménye legyen (chained iBot). Ezt úgy lehetne gyakorlatiasabban megfogalmazni, hogy ha az első iBot feltétele nem teljesül (a filterrel ellátott request nem ad vissza egyetlen sort sem), akkor nem történik semmi. Ha ez a feltétel teljesül, akkor lefut az első iBot (pl.: e-mail értesítést küld), majd elindít egy másik iBot-ot.

"Az Üzleti intelligencia megoldások magukban foglalják tehát az adattárolási, a valós idejű lekérdezési, analitikai, előrejelzési és adatbányászati eljárások modern formáit."

Ebben a bejegyzésben az adattárolás, adatokhoz való hozzáférés, és a megjelenítés lehetőségeit szeretném bemutatni Oracle Business Intelligence Challenge 2 Go Enterprise Edition (BIC2G) környezetben.

A BIC2G egy előre telepített, konfigurált üzleti intelligencia csomag, számos kulcsra kész példával, amik közül a Sales History-n (SH) keresztül a legegyszerűbb az alapok bemutatása.

A Sales History adatbázis-séma - mint ahogy a neve is mutatja - értékesítési adatokat tartalmaz különféle termékekre vonatkozóan. A példában ezt egy Oracle 10g adatbázis-szerver tárolja, de tetszőleges ODBC vagy XML adatforrást is választhattunk volna. Az adatbázisban a termékeket a PRODUCTS tábla tartalmazza, fontosabb mezők: PROD_ID, PROD_NAME, PROD_CATEGORY, PROD_SUBCATEGORY, ..., az eladási információkat pedig a SALES tábla: PROD_ID, CUST_ID, TIME_ID, QUANTITY_SOLD, AMOUNT_SOLD


A fizikai adattárolás és a megjelenítés közötti kapcsolatot az Oracle BI Administration segédprogram segítségével teremthetjük meg:


Például érdekelhet minket az összes eladott termék darabszáma, vagy a különböző vásárlók száma. Ezeket a fogalmakat az Administration Tool segítségével képezhetjük le az adatbázis megfelelő relációira: SUM(SALES.AMOUNT_SOLD) és COUNT(DISTINCT SALES.CUST_ID).

Vagy egy kicsit összetettebb példa lehet az eladott termékek számának százalékos változása az előző hónaphoz képest:

case    when sum(SALES.AMOUNT_SOLD) <> 0
and (sum(SALES Mago.AMOUNT_SOLD) = 0
or sum(SALES Mago.AMOUNT_SOLD) is null)
and not sum(SALES.AMOUNT_SOLD) is null
then 100.0
when (sum(SALES.AMOUNT_SOLD) = 0
or sum(SALES.AMOUNT_SOLD) is null)
and (sum(SALES Mago.AMOUNT_SOLD) = 0
or sum(SALES Mago.AMOUNT_SOLD) is null)
then 0.0
when sum(SALES Mago.AMOUNT_SOLD) <> 0
and not sum(SALES Mago.AMOUNT_SOLD) is null
and sum(SALES.AMOUNT_SOLD) is null
then -100.0
else (sum(SALES.AMOUNT_SOLD) - sum(SALES Mago.AMOUNT_SOLD))
  * 100.0 / nullif( sum(SALES Mago.AMOUNT_SOLD) , 0)

Az Oracle Answers segítségével reportokat készíthetünk, amiknek az eredményét az interaktív Dashboard felületen tekinthetjük meg: például lekérdezhetjük azon termékeket, amiknek a neve "Mini DV"-vel kezdődik:




Ennél egy fokkal hasznosabb példa lehet az egyes kategóriákban szereplő termékek eladási mennyiségeinek változását egy diagrammon megjeleníteni az elmúlt 12 hónapra vetítve. Ehhez szükségünk van az alábbi megjelenítési rétegbeli fogalmakra: termék kategória (Prod Category), hónap (Calendar Month Name a megjelenítéshez ill. Desc a rendezéshez), eladott mennyiség (Amount Sold), illetve egy szűrőre, ami azt mondja meg, hogy csak az utolsó 12 hónap adataira vagyunk kiváncsiak. Ezt úgy írhatjuk le SQL nyelven, hogy Calendar."Calendar Month Id" between VALUEOF(maxMonthID)-11 and valueof(maxMonthID), ahol a maxMonthID egy ún. Repository Variable, ami az értékét egy függvénytől (Repository Variable Init Block) kapja: select TIME_ID, CALENDAR_YEAR, CALENDAR_MONTH_DESC, CALENDAR_MONTH_ID from TIMES WHERE TIME_ID = (select max(TIME_ID) from SALES), azaz azon legutolsó hónap azonosítója, amire van értékesítési adat (a SALES táblában).

Ezeket az elemeket az Answers felület Criteria részén pillanatok alatt össze tudjuk kattintani:


Megjelenítésnek egy vonalas Chart-ot választva szemléltethetjük a legjobban az eladási statisztikák alakulását:


A különféle chart-ok (Vertical/horizontal bar, bubble, line, pareto, pie, radar, scatter, area) helyett választhatunk akár szöveges táblázatokat is.

,,Az üzleti intelligencia a rend és a tisztánlátás megteremtésén keresztül a megértés és a tudás megszerzésének az eszköze egy vállalaton belül.''

Ezt a definíciót Sipos Ferenc, az IQSYS Informatikai Rt. igazgatója adta a Napi Gazdaság egyik interjújában. Ahhoz, hogy megérthessük ezt az igencsak jól hangzó mondatot, először tisztán kell látni, hogy mi is történik egy vállalaton belül, mik is azok az üzleti folyamatok.

Már Magyarországon is bő 10-15 éve meghatározó szerepe van az informatikának a vállalatok - elsősorban a pénzintézetek - életében. Ma egy cég sem tud versenyképesen működni informatika nélkül, már 1-2 hetes rendszerleállás is komoly (fatális) veszteségeket okoz. Ennek köszönhetően egyre több gyártó készít "üzleti" (business) szoftvereket, amiknek a célja a vállalat folyamatainak irányítása, menedzselése. Vagy nem.

Ugyanis - ahogy Alexander Ryan egy publikációjában rámutat - az informatikában és az üzleti világban az "üzleti folyamat" (business process) mást jelent. Talán a legáltalánosabb tévedés az, amikor a "munkafolyamattal" (workflow) keverik össze, ami egy manuális folyamat automatizálása egy vagy több szoftver segítségével. Például egy pénzügyi rendszerben egy ügylet rögzítésekor, vagy könyveléskor számtalan folyamat indulhat meg a háttérben, amiket az adott program menedzsel.

Ezzel szemben az üzleti folyamat egy adott üzleti cél elérésének érdekében tett összefüggő cselekvések rendezett sorozata. Az üzleti folyamatoknak három típusát különböztethetjük meg:

• irányító folyamatok (management processes): azok a folyamatok, amik a cég működését irányítják. Például: stratégiai tervezés, operatív irányítás, pénzügyi menedzsment
• alapfolyamatok (operational processes): ezek azok a folyamatok, amik az elsődleges értéket (primary value) állítják elő egy cégen belül. Ilyenek például: beszerzés, termelés, marketing, sales.
• támogató folyamatok (support processes): tipikusan az alapfolyamatokat támogatják. Például: IT-support, könyvelés, munkaerő toborzás.

Jelentős különbség a munkafolyamatokkal szemben az, hogy az üzleti folyamatok tipikusan egy magasabb absztrakciós szintet képviselnek.

Itt jön a képbe az üzleti intelligencia (business intelligence) fogalma: Korcsmáros István szerint amikor egy vállalat az üzletmenetük automatizálásán (workflow) túl döntéshozatali eljárásaik (management processes) elősegítése céljából is igénybeveszi az informatikát, akkor már üzleti intelligenciáról beszélhetünk. Ez valójában csak egy része azon területeknek, amikről az üzleti intelligencia szól.

Az ugyanis egy ún. ernyő-fogalom, ami csomó technológiát és megoldást foglal magába. A Controlling Portál az alábbi definíciót adja: ,,olyan alkalmazások és technológiák, amik a szükséges adatokhoz való hozzáférés biztosításával, ezen adatok megfelelő tárolásával, valamint sokoldalú elemzési lehetőségekkel támogatják a vállalati döntéshozatalt. Az Üzleti intelligencia megoldások magukban foglalják tehát az adattárolási, a valós idejű lekérdezési, analitikai, előrejelzési és adatbányászati eljárások modern formáit.''

Az elkövetkezendő félévben ezeket a megoldásokat fogom részletesebben megvizsgálni, elsősorban az Oracle által készített (vagy felvásárolt) termékekre koncentrálva.

Kapcsolódó linkek:

• http://www.napi.hu/default.asp?cCenter=article.asp&nID=242582
• http://www.visualocity.net/articles/whatIsABusinessProcess.jsp
• http://www.fn.hu/cikk/00140000/145435/uzleti_intelligencia_mar_nem_titkos.php
• http://www.controllingportal.hu/?doc=it_olap