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