Adattárház módszertanok

Ez az oldal a korábbi SCH wiki-ről lett áthozva. Az eredeti változata itt érhető el.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor kérlek javíts rajta egy rövid szerkesztéssel.

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót

Üzleti életciklus

Az egyes módszerek közös pontja, hogy iteratívan képzeli el a DW kialakítását, fázisokat definiálnak.

• Hadden-Kelly: Preparing - Planning - Building - Operating
• HP Open Warehouse
• Oracle Warehouse Methodology
• Ralph Kimball
• SAS

Data Warehouse readiness Litmus test

Nagy adattárház gyakorlattal rendelkező szakértők állították össze, választ ad arra a kérdésre, hogy adott helyzetben, adott cégnek van-e szüksége DW használatára.

Ezen a helyen volt linkelve a(z) Lolopop.Readiness.Test.pdf nevű fájl ("Lolopop.Readiness.Test.pdf" link szöveggel) a régi wiki http://wiki-old.sch.bme.hu/bin/view/Infoszak/InfoMenDWModszert oldaláról. (Ha szükséged lenne a fájlra, akkor a pontos oldalmegnevezéssel együtt küldd el a wiki

Hiba a bélyegkép létrehozásakor: Nem lehet a bélyegképet a célhelyre menteni

@NO-SPAM.sch.bme.hu címre a kérésedet)

• Do You Have A Strong Business Management Sponsor?
• Is There A Compelling Business Motivation?
• Is There A Strong Information Systems (IT)/Business Partnership?
• What Is Your Current Analytic Culture?
• What Is The Feasibility For Undertaking A Data Warehouse Project?

A kérdéscsoprtok súlya: 60-15-5-5-15, 1-5-ös skála szerint kell osztályozni. A DW bevezetése célszerű, ha négynél nagyobb, három és négy között: nem rossz eredmény, de érdemes odafigyelni a 3-nál kisebb tételekre. Kettő és három közti érték esetén határeset, érdemes a céget fejleszteni olyan irányba, hogy jobb választ lehessen adni ezekre a kérdésekre. Kérdéses, hogy ez megéri-e. Kettőnél kisebb átlag elérése esetén egyáltalán nem ajánlott DW bevezetése a vizsgált környezetbe.

A teszt iránymutatásnak jó, a DW bevezethetőségét nem feltétlenül ez alapján érdemes eldönteni.

Pénzügyi megfontolások

A ROI (Return of Investment) határoz meg mindent. Költségek közt számolni kell a SW/HW vásárlásokkal, belső fejlesztésekkel, külső erőforrásokat veszünk igénybe, támogatással (support) és a növekedéssel (üzleti folyamatok optimalizálása, átalakítása). Ezek mennyiség és eloszlása igen jó becsülhető. Haszonként ezért cserébe bevételnövekedést (gyorsabb piacra jutás, forgalomnövekedés a jobb termék pozicionálás eredményeképp) és költségcsökkenést érhetünk el.

A projekt résztvevői

Heterogén csapat kialakítása a feladat:

• projektmanager
• főmérnök - architect (a technika összeálljon egy egésszé)
• üzleti analitikus (a folyamatokat átlássa)
• biztonság tervező (kritikus, üzleti titkok kezelése)
• adatgondnok (naprakész infó az adatok jelentéséről, elérhetőségéről... -> humán kiegészítésű metaadattár)
• (Adatgondnok == data steward?)
• adatmodellező (adatmodellezés a szemantikus modellektől kezdve az adatbázis adatmodellig, normalizálási, integritási és hatékonysági elemek meghatározása)
• betöltés tervező (ismerik adatforrások logikai és fizikai felépítését, betöltés során felmerülő konvertálási, adattisztítási feladatok megoldása)
• front-end tervező (végfelhasználók kiszolgálása)
• adatminőség biztosító ("rubish in - rubish out")
• oktatók (belső fejlesztő gárda szakmai képzése, a felhasználók oktatása)
• stb.

Követelmények összegyűjtése

alapelvek

Indirekt kérdezzünk rá a dolgokra, segíteni kell a stratégiai kezdeményezések felismerését. Meg kell határozni sikerességi mutatókat. Azokat a legfontosabb üzleti folyamatokat kell kiválasztani, melyeknek javítása jelentős kihatással jár (például a legtöbb pénzt mozgató folyamatok).

interjúk lebonyolítása

Az interjúkészítőnek beszélgető partnernek kell lenni: legyen tapaszalt és a tárgyterülettel kellően tisztában. Ugyanakkor az üzlethez kell érteni, nem a technológiához. Ismerje hogy milyen módszerrel állhat neki, milyen kérdéseket érdemes feltennie, milyen sorrendben. Az ötletelésnek nincs helye (drága a partner ideje...). Kiket kérdezzünk meg? A legfelsőbb vezetőket (stratégiai kérdésekben), üzleti kulcsszereplőket (a folyamatokról), a középvezetőket (ők a földön járnak...), az IT részleget (a környezet előkészítettsége rajtuk áll), illetve végül, akiket muszáj megkérdezni politikai okokból (megéri, különben kerékkötője lesz a projektnek).

szokásos kérdések egy interjún

• az adott vezető szervezetének mi a helye a cégben, a vezetőnek mi a felelőssége?
• az adott vezető szervezetének mi az üzleti célja?
• hogyan és milyen gyakran szokták mérni az eredményességet személyre, szervezetre vonatkozóan?
• milyen problémáik vannak?
• a tapasztalataik szerint mi akadályozza legfőképpen a céljaik elérésében?
• milyen rutinszerű analíziseket használnak ténylegesen?
• szoktak-e kérni ad-hoc elemzéseket?
• milyen akadályai vannak, hogy a megfelelő információkhoz hozzájussanak?
• milyen régi infókhoz szoktak hozzányúlni, minek van értelme, mennyire karakterisztikus a jövőre?
• milyen üzleti lehetőségekhez fogna, ha megfelelő infók állnának a rendelkezésre?

Sikerkritériumok meghatározása

Az adattárház folyamatosan fejlesztendő rendszer ("egy adattárház addig él, amíg változtatnak rajta"), ugyanis a környezet is folyamatosan változik. A folyamatos változás miatt a kezdeti elképzelés változhat. Bizonyos analízistípusokat le tud-e szállítani, célszerű ellenőrizni, hogy adott idő alatt lefut-e az analízis? Mennyi megfelelően transzformált adat áll a rendelkezésre? Ténylegesen hányan használják a rendszert?

• teljesítési, megvalósítási mérték: x db különböző lekérdezést lehet beadni a rendszernek
• használati mérték: x ember használja
• szolgálati szint, rendelkezésre állás: napi x órában elérhető
• adatminőség: x% adathiba bizonyos adatmennyiségen

konszolidálás, priorizálás, konszenzus kialakítása

Az igényeket érdemes csoportosítani és prioritásokat felállítani. Mit, mi mentén akarunk elemezni. A prioritás meghatározásának szempontjai

• érintett pénzvolumen
• milyen adatok, milyen rendszerekből szükségesek (a rendszerek legyenek jól dokumentáltak illetve a dokumentáció legyen konzisztens a valósággal).
• mennyire komplex, mekkora adatmennyiség

DW architektúra

nem feltétlenül formalizált

Feladatok:

• front-end manager (Mc Donald's-ban a pultos, eladó): kapcsolattartás a végfelhasználókkal
• back-end: a termékek előállítása, átmeneti tárolóba töltése

Dimenziós modellezés

előnyök

• lekérdezés könnyen optimalizálható
• a modell bővítése egyszerű, nem kell átstrukturálni az adatbázist, ha új adatot veszünk fel
• laikusok által is könnyen lekérdezhető
• a lekérdezést nem kell megváltoztatni, ha az adattárház bővül

négylépéses dimenziós modellezés

• 1. üzleti folyamat azonosítása

Példák:

• • szolgáltatás használata
  • hitelek igénylése, felvétele
  • bevéltelek alakulása
  • kinnlévőségek
  • rendelések
  • személyzeti ügyek
  • számlázás
  • javítások és reklamációk
• 2. tényadat granularitásának megválasztása - milyen részletes adatok tárolását támogatjuk
  • túl részletes (sok adat, nagy diszk-, CPU-igény)
  • nem elég részletes (elemzéseket akadályozhat meg)
  • le kell írni a tényrekord pontos jelentését
• 3. dimenziók azonosítása - mi alapján akarunk rendezni, lekérdezni, csoportosítani a tényadatokat?
  • sok és részletes dimenzió => változatosabb analízisek, sok erőforrásigény
  • az igényeket szembesíteni kell az üzleti lehetőségekkel
• 4. tények azonosítása - általában numerikusak és folytonos értékkészletűek pl.: eladott áru darabszáma, eladási ár forintban, átlagos kisker ár

dimenziós tervezési elvek

Ismerjük meg és értsük pontosan a kezelt adatokat.

ténytáblák

A ténytáblában legyenek rövid rekordok (lehető legkisebb granularitás), kódokkal teli, rendelkezzen azonosítókkal.

• additív tényadatok: általában összegezhető adatokat kell választani
• nem additív tényadatok: egyáltalán nem összegezhetőek, egyetlen dimenzió mentén sem
• szemi-additív tényadatok: minden dimenzió szerint összegezhető, kivéve az időt. (általánosabban: egyes dimenziók szerint összegezhető, mások szerint nem).

Ténynélküli ténytáblák Előfordulhat, hogy a ténytáblának csak egy tény-oszlopa lenne, amiben csak egy 1-es van, pl. egy sor a ténytáblában azt jelenti, hogy a diák látogatott egy órát, de ehhez nem tartozik mennyiség, hiszen csak egyszer lehet egy órát meglátogatni, a külső kulcs mutatja, h melyik órát. Ilyenkor felesleges felvenni ezt a tény-oszlopot.
Ezek valójában klasszikus több-több kapcsolatok, pl.:

• óralátogatási szokás ( ==időpont, tárgy, terem, diák, tanár== ) vagy
• egy termék-kampány lefedettségi táblái ( ==eladás, termék, bolt, idő, kampányjellemzők== )
  

Ez utóbbi viszont nem ad választ arra, hogy mit nem adtak el abból, amiről a kampány szólt. Hogy ezt az információt kinyerhessük, szükségünk van egy másik ténytáblára, melynek rekordjai a kampányban való részvételt jelentik.

Az esemény-tények egyetlen időponthoz köthetőek, az állapot tény viszont két időponthoz (kezdet+vég). Itt azonban új tényrekord beszúrása egy másik lezárásával jár, ez egyrészt alacsonyabb hatékonyságú másrészt valószínűsíthető az információveszteség. Ugyanakkor egymásba átalakíthatók.

Pl. tárolhatjuk egy szerződésről

• a megkötésének és felbontásának idejét külön sorokban (esemény): betöltésre optimalizált, lassabb lekérdezni
• a szerződés fennállását egy sorban (állapot): lekérdezésre optimalizált, lassabb betölteni

dimenziós táblák

A dimenziós táblákban foglalnak helyet a leíró attribútumok (a rekordok hossza kevésbé kritikus, akár igen sok mezője is lehet). Ha lehet, konform dimenziókat használjunk, azaz több ténytáblához alkalmazzuk ugyanazt a dimenziós táblát, ha ezt a típusok lehetővé teszik. (Pl több tánytáblához egy idő dimenziós táblát.) A felesleges dimenziók teljesítményveszteséget eredményeznek. A dimenziós adatok nem feltétlenül nyerhetők ki valamely forrásrendszerből. Az ==idő, termék, hely és ügyfél== a leggyakoribb dimenziók.

Minden dimenzió rendelkezzen egy surrogate kulccsal , mely anonym, kiegészítő, jelentés nélküli, mesterséges. A surrogate kulcs használatával elég jó méretcsökkentést tudunk elérni a ténytáblákban. A forrásrendszeri kulcs változásaitól függetlenek lesz a rendszerünk, sőt az entitások időbeli változásait is le tudjuk így írni. Hátránya ugyanakkor, hogy a tény és dimenziós rekordok újrakulcsolával jelentős betöltési overheadet kapunk.

• Role-playing dimenziók többféle jelentést is hordozhatnak a tényadathoz kapcsolódóan, például egyetlen fizikai idődimenzió több kulccsal kapcsolódhat a tényrekordhoz (Számlázás ideje, fizetés ideje, szállítás ideje)
• Degenerált dimenziók olyan leíró (rövid dimenziós jellegű) adatok, melyeket a ténytáblában helyezünk el különösebben kapcsolódó dimenzió nélkül. Például egy dokumentumunk egyedi sorszáma, számlaszám. Velük a forrásrendszerben könnyen lehet azonosítani valamit, így egyedi megfontolásból kerülnek be.
• Junk dimenziók - egyes elemek nem mindig szervezhetők dimenziókba, egy vagy néhány jelentés nélküli dimenziót alkotó elemeket nevezzük így, melyeket a ténytáblában nem célszerű elhelyezni: flag-ek, szöveges leírók.
• idővel változó dimenziók SCD (slowly changeing dimensions) kezelésére három módszert használhatunk:
  • felülírás : egyszerűen megvalósítható, de adatvesztéssel jár.
  • old mező létrehozása : szintén gyorsan implementálható, de korlátozott history.
  • új dimenziós rekord beillesztése : teljes history építhető fel vele, nehézkesebb keresési műveletek.

Összegzések tervezése

Összegzésnek nevezzük azokat az előre kiszámított speciális lekérdezéseket, melyekben a ténytábla tényadatait összegezzük bizonyos feltételek mentén. Azaz a dimenziókban lévő hierarchiákat összenyomjuk és a tényadatokat ennek megfelelően összegezzük. Ezáltal elérhetjük a meglévő teljesítményi korlátok betartását. Egyszerre akár 1000 összegzés is létezhet. Ehhez azonban mind a fizikai adatszervezést, mind az összegzéseket terveznünk kell, illetve a lekérdezést a végletekig optimalizálnunk.

Az összegzéseket új ténytáblákban ildomos tárolni, ehhez azonban új dimenziós táblák is kellenek (+ a hozzájuk tartozó surrogate kulcsok). Az új ténytáblák és dimenziós táblák (granularitás csökkentésével) szerkezetének kialakításakor a már meglévőkből is képezhetjük. Pédldául ==termékek== helyett ==márkákra== aggregálunk. Ezáltal egy új ==márka== kulcs jön létre.

Az összegzések méretezésekor célszerű legalább 10:1 arányú rekordszámcsökkenést eszközölni. Ennek mérőszámai a dimenzió kompressziója és az együttes előfordulási gyakoriság (density). Az előző példánál maradva

• ha egy márkához átlagosan 50 termék tartozik, akkor a márkán definiált összegzés 50x kompresszióval bír
• ==termék, bolt, nap== előfordulási gyakoriság: egy adott boltban, azon a meghatározott napon a termékek 10%át adták el átlagosan
• ==márka, bolt, nap== előfordulási gyakoriság: egy adott boltban, azon a meghatározott napon a márkák 50%át adták el átlagosan

Az összegzések közti navigációt egy külön rétegnek kell kiszolgálnia, mely meghatározza, hogy melyik a legalkalmasabb összegzés a felhasználói lekérdezés kiszolgálására, ezáltal növelve a rendszer teljesítőképességét és kényelmes használhatóságát. Igyekezni kell kerülni a túl sok összegzés definiálását, hiszen nem mindegyik összegzés fogja jelentősen csökkenteni a lekérdezett sorok számát. Ennek kiszámítása futás-idejű feladat.

-- adamo - 2007.11.26.

-- habib - 2008.01.08. - javítgatta, (belekavart :))