Oracle Business Intelligence

Az adattárházakba bizonyos időközönként (tipikusan éjszaka, amikor az OLTP rendszerekre kisebb, vagy épp semmi terhelés jut) be kell tölteni az újonnan keletkezett vagy módosult adatokat. Tehát fontos feladat az új/módosult adatok azonosítása a forrásadatbázisokban. Ennek a megoldásában nyújthat segítséget a CDC (Change Data Capture).

CDC nélkül két féle módon juthatunk hozzá a változott adatokhoz:

• Különbségképzés (table differencing): a forrásadatbázisból a tábla teljes tartalmát a staging adatbázisba másoljuk, ahol az SQL MINUS operátorával lekérdezhetjük az újonnan beinsert-ált, illetve update-elt sorokat:

SELECT * FROM new_version

MINUS SELECT * FROM old_version

Vagy, ha a kitörölt sorokra vagyunk kiváncsiak:

SELECT * FROM old _version

MINUS SELECT * FROM new_version

Ennek a megközelítésnek a problémái nyilvánvalóak:

• Mivel a tábla teljes tartalmát át kell másolni a két adatbázis között, ez hatalmas overhead-del jár.

• Magának a MINUS operátor elvégzésének a számítási költsége is rendkívül nagy.

• Nem lehet azonosítani a megváltoztatott, majd az eredeti értékre visszaállított adatokat.

• Nem lehet megállapítani, hogy milyen változtatások történtek egy tranzakción belül.

• Change-value selection: egy, a forrástáblában levő speciális oszlop segítségével csak az előző betöltés óta megváltozott/újonnan létrehozott sorokat választjuk ki. Egy ilyen oszlop tipikusan valamilyen időpontot tárol, pl.: LAST_UPDATE_DATE.

Ezzel a következő problémák vannak:

• A megváltozott adatok azonosításával járó overhead a forrásadatbázist terheli.

• Ezzel a módszerrel sem lehet megállapítani, hogy milyen változtatások történtek egy tranzakcióban.

• A change-value alapján történő felosztás finomsága nem feltétlen megfelelő: például, ha másodperc finomságú, és az előző kinyerés mondjuk 10:15:33-kor történt, akkor a következő kinyeréskor a 10:15:33 utáni rekordokat fogjuk csak kiválasztani. Tehát ha ugyanabban a másodpercben történt módosítás, akkor az el fog veszni.

• Gyakorlati szempontból talán a legnagyobb hátrány az, hogy a kinyerő mechanizmust figyelembe véve kell megtervezni a forrástáblákat is, amik legtöbbször 3rd party adatbázisokban szerepelnek.

Megváltozott adatok kinyerése CDC-vel

Az Oracle CDC másfajta megközelítést követ: az INSERT, UPDATE, és DELETE utasítások következtében beállt változásokat rögzíti egy ún. change-table-ben, amiket utána ellenőrzött módon bocsát az alkalmazások számára.

A CDC-t két különböző módon lehet használni:

• Szinkron: a forrástáblákra elhelyezett triggerek segítségével a DML utasítások eredményét a módosítás tranzakciójának részeként rögzíti.

• Aszinkron: az elcommit-ált módosításokat tartalmazó redo log file alapján nyeri ki a módosult adatokat. Aszinkron módon háromféleképpen lehet a CDC-t megvalósítani: HotLog, Distributed HotLog, AutoLog.

Ezekről a módokról a későbbiekben részletesen be fogok számolni.

Forrás: Oracle Data Warehousing Guide

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