Önálló laboratórium beszámoló BME TTT Készítette: Tánczos Zoltán, F966Q8 Szak: műszaki informatika Szakirány: Infokommunikációs rendszerek biztonsága Email cím: zoltan.tanczos@fx.hu Konzulens: Kardkovács Zsolt Email cím: kardkovacs@db.bme.hu Tanév: 2007/08. tanév, 2. félév Téma címe: Adattárházak tervezése Feladat: A feladat egy adattárház tervezési lépéseinek bemutatása a dimenziós modellezés lépéseit követve, egy konkrét demó adattárház megvalósításán keresztül. 1
Tartalomjegyzék 1. Bevezető 3 2. Az adattárházak definíciója 3 2.1. Döntéstámogató rendszerek....................... 4 3. A dimenziós modellezés 5 3.1. Tények................................. 6 3.2. Dimenziók................................ 7 3.3. Csillag séma............................... 7 3.3.1. Bitmap indexek......................... 8 3.3.2. Csillag transzformáció..................... 11 3.4. Hópehely séma............................. 12 3.5. Négy lépéses dimenziós modellezés.................. 12 4. Esettanulmány 13 4.1. Informális leírás............................. 13 4.2. Az üzleti folyamat kiválasztása..................... 13 4.3. Granularitás meghatározása....................... 13 4.4. A dimenziók meghatározása...................... 14 4.5. A tény táblák attribútumainak meghatározása............. 14 5. Egyéb adatmodellek adattárházakhoz 14 5.1. Multidimenziós E/R modell....................... 15 5.2. starer modell.............................. 16 5.3. Objektum-orientált modellek...................... 18 6. Összefoglalás 18 7. Irodalomjegyzék 19 2
2. AZ ADATTÁRHÁZAK DEFINÍCIÓJA 1. Bevezető Az adattárházak napjainkban már szerves részét képezik a vállalati döntéstámogatásnak. 1 Ebben a dokumentumban az adattárházak tervezését szeretném bemutatni elsősorban a dimenziós modellezés módszertanán keresztül. Az első részben definiálom az adattárház fogalmát, helyét a vállalati struktúrában illetve az egyéb döntéstámogató rendszerek között. Ezután részletesen bemutatom a Ralph Kimball féle dimenziós modellezés [1] terminológiáját, a módszertan lépéseit. Ennek középpontjában a csillag séma nevű adatmodell szerepel, aminek az oka a modell egyszerűsége, szemléletessége valamint a jó lekérdezési teljesítmény. A következő részben egy leegyszerűsített, képzeletbeli esettanulmányon keresztül bemutatom a dimenziós modellezés főbb lépéseit. Végül az 5. fejezetben egy magasabb absztrakciós szintre lépve az adattárházak modellezését három szinten tárgyalva (conceptual, logical, physical [6]) vázlatosan bemutatok a szakirodalmakban tárgyalt egyéb adatmodelleket is. 2. Az adattárházak definíciója Röviden megfogalmazva egy adattárház nem más, mint az adatoknak egy olyan integrált, időorientált halmaza, ami operatív adatokból származik, és elsősorban stratégiai döntéshozatalra használandó OLAP (on-line analytical processing) technikák felhasználásával [8]. A részletes definíció előtt célszerű azokat az alapvető célokat áttekinteni, amikre az adattárházakat eredetileg kitalálták [12]. A kezdeti időkben az első adattárház-szerű rendszerek kialakulásához nagyban hozzájárult az igen szűkös tárolási és feldolgozási kapacitása az akkori számítógépeknek. Elsődleges célként fogalmazódott meg az új, egyre széleskörűbben használt analitikus feldolgozás és a tranzakciós terhelés szétválasztása. Mivel ez a két terület annyira különbözik egymástól, már a 80-as években arra a konszenzusra jutott több gyártó, hogy a tranzakciós rendszerek tervezési elveitől különböző, egyedi architektúra szükséges az elemző rendszerekhez. 1991-ben Bill Inmon kiadta az első könyvét az adattárházakról [2]. Ebben a könyvben megalkotta az adattárházak azóta talán legtöbbet idézett definícióját: Az adattárház téma orientált, integrált, időfüggő és tartós adatgyűjtemény a vezetői döntéstámogatás szolgálatában. A téma, vagy tárgy orientáltság (subject-oriented) a tranzakciós rendszerek alkalmazás orientáltságával áll szemben: hagyományosan a rendszereket a funkciók, feladatok köré építjük, míg egy adattárház tervezésekor egy adott témakör áll a középpontban. Például egy termelő vállalatnak lehetnek a szállítást, számlázást, beszerzést támogató rendszerei (adott feladatot, funkciót valósít meg). Egy adattárház tervezésekor viszont az adatainkat egy témakör köré szeretnénk szervezni: termék, rendelés, szállító, stb. Inmon szerint az integráltság (integrated) a legfontosabb tulajdonsága egy adattárháznak. Az adatok számtalan különböző forrásrendszerből származhatnak. Ezek integrálása nem csupán annyit jelent, hogy összedrótozzuk a meglévő rendszereinket, Oracle 1 Központi Statisztikai Hivatal Oracle Essbase; Magyar Külkereskedelmi Bank SAS; FHB Bank 3
2.1. Döntéstámogató rendszerek 2. AZ ADATTÁRHÁZAK DEFINÍCIÓJA hanem hogy a különböző kódokat, azonosítókat közös nevezőre hozzuk, szabványosítjuk, hogy az adattárházból kinyerhető adatok a vállalatról egységes képet mutassanak. Ennek legegyszerűbb példája, hogy ha az egyik rendszerben a nemeket a {m,f} kódokkal azonosítjuk, egy másikban pedig a {0,1}-el, akkor ezeket valamilyen előre definiált módon egységesítjük az adattárházban. Az időfüggőség, vagy időorientáltság (time-variant) azt jelenti, hogy az adattárházban szereplő minden adat az időnek valamilyen pillanatában érvényes. Például lehet, hogy a rekordok időpecséttel vannak ellátva, vagy valamilyen módon jelezve van, hogy az adott adat mikortól meddig érvényes. Az utolsó tulajdonság az adattárházak tartóssága (nonvolatile), ami az ott tárolt adatokon végezhető műveletekre vonatkozik: az adatokat betöltjük (load), és lekérdezzük (query), szemben a tranzakciós rendszereken tipikusan végzett módosítás, törlés műveleteivel. Ha megváltozik valami, akkor az adattárházba tipikusan egy új rekordot szúrunk, és jelezzük, hogy mostantól fogva az az érvényes, így megteremtjük a lehetőségét nagy időszakokat átfogó, historikus elemzéseknek. Inmon azt feltételezi az adattárházakról, hogy azok a döntéshozatalt támogató adatok exkluzív tára. A definíciójában eleve kizárja, hogy az adattárházakat operatív riportok készítésére (operational reporting) használjunk. Példaként egy bankot hoz fel: a pénztárban ülő embernek a nap végén le kell ellenőriznie a nála levő pénz mennyiségét. Ehhez veszi a napi nyitó egyenleget, az adott napi tranzakciók listáját, és ezeket összeveti a záró egyenleggel. Ebben a példában a tranzakciós lista az operatív riport. Ezzel szemben ha a bank vezérigazgatója el szeretné dönteni, hogy az új szupermarketben hány ATM-et nyisson, akkor számos, akár különböző forrásból érkező jelentést néz végig, egy stratégiai döntés meghozatalára készül. Az adattárházakat és a tranzakciós, operatív rendszereket különböző szempontok szerint összehasonlító összefoglalás az 1. táblázatban látható [6]. Szempont Operatív rendszer Adattárház Felhasználó Adminisztrációt végző személy Döntéshozó, végrehajtó Funkció Napi folyamatok követése Döntéstámogatás, analitikus feldolgozás Adatbázis tervezés Alkalmazás-orientált Téma-orientált Adat Aktuális, friss, atomi, normalizált, izolált Használat Ismétlődő, rutin szerű Ad-hoc Hozzáférés Írás/olvasás, egyszerű tranzakciók (tipikusan pár tábla érintett) Követelmények Magas tranzakciós teljesítmény, adat-konzisztencia Historikus, atomi és összegzett, multidimenziós, integrált Olvasás, összetett lekérdezések (tipikusan sok tábla érintett) Magas lekérdezési teljesítmény, pontosság 1. táblázat. Különbségek az operatív rendszerek és az adattárházak között 2.1. Döntéstámogató rendszerek Az adattárházak elsődleges célja a döntéstámogatás. Viszont nem csak ilyen jellegű rendszereket lehet elképzelni. Hat kategóriát különböztethetünk meg: 4
3. A DIMENZIÓS MODELLEZÉS kommunikáció orientált: a helyes döntés már ott van valakinek a fejében. Az ilyen rendszerek azt támogatják, hogy több ember hatékonyan tudjon egyszerre dolgozni egy megosztott feladaton. adat orientált: alapelvük: több adat jobb döntés. Ezek a rendszerek a különböző forrásokból származó adatokhoz való hozzáférést segítik. Az adattárházakat is ebbe a kategóriába sorolhatjuk. dokumentum orientált: meglévő akár papír alapú dokumentumokhoz való hatékony hozzáférést segítik. tudás orientált: szakértői rendszerek. modell orientált: egy folyamat valamilyen szempontból történő modellezését, illetve a modell analízisét, szimulációját segítő rendszerek. spreadsheet orientált: számos helyen a mai napig varázs-excel táblázatok segítségével történik a döntések előkészítése. Emiatt nem véletlen, hogy szinte az összes nagyobb üzleti intelligencia rendszer rendelkezik valamilyen Excel interfésszel. 3. A dimenziós modellezés Egy analitikus feldolgozás statikus aspektusai az analízis tárgya és változók halmaza [6]. Az analízis tárgyát a változók egy függvényeként definiálhatjuk, ahol minden változó egy dimenziót reprezentál. Például, ha w = f(x,y,z), akkor f függvény értelmezési tartománya a három dimenzió (x,y,z) által kifeszített multidimenziós tér. Ebben az esetben ha w az eladásokat jelenti, és legyen x a termék, y a régió, és z az idő dimenzió, akkor a változók egy adott (x 0,y 0,z 0 ) értékére az f függvény értéke egy konkrét eladás. A dimenziók mentén hierarchiákat is definiálhatunk. Például, ha az idő dimenzió értelmezési tartománya {1,..,12}, ami az év hónapjait jelöli, akkor definiálhatunk egy ennél magasabb hierarchia-szintet: {1,.., 4} a negyedéveknek, vagy {1, 2} a féléveknek megfelelően. Egy dimenzió mentén összesíthetjük (aggregálhatjuk) az adatainkat egy magasabb hierarchia szintig. Az aggregációt így írhatjuk le: w = F(x,y,z ) = z {z } f(x,y,z) A fenti kifejezés azt írja le, hogy összesítsük az eladási adatainkat az idő dimenzió mentén a havi szintről a következő, negyedéves szintig. Persze ezt megtehetjük egyszerre több dimenzió mentén is. Ezt multidimenziós analízisnek nevezik. Egy adattárház, mint döntéstámogató rendszer, előkészíti az adatokat az analitikus feldolgozáshoz. Ezért az adattárházakban alkalmazott modellnek támogatnia kell a multidimenzionalitást [6]. A dimenziós (dimenzionális, multidimenziós, multidimenzionális) modellezés két alapeleme a tény és a dimenzió. A Kimball-féle módszertan [1] ezeket tény tábláknak és dimenzió tábláknak nevezi, ami abból a szempontból picit megtévesztő, hogy a fizikai modellnek relációs adatbázist sugall, pedig a tervezés ezen fázisában (conceptual modeling) közel sem eldöntött, hogy mi lesz a fizikai megvalósítás. 5
3.1. Tények 3. A DIMENZIÓS MODELLEZÉS Ennek ellenére én is a szakirodalom által általánosan elfogadott tény tábla és dimenzió tábla fogalmakat fogom használni. 3.1. Tények A tény táblák a dimenziós modellezés központi elemei: ezek azok a helyek, ahol az adott üzleti folyamat számszerű mértékei szerepelnek. A tény egy üzleti mértéket jelent. Például egy bolt adott napra vonatkozó eladási adatai lehetnek az eladott darab, ár, stb. Minden nap, bármelyik boltban bármelyik termék kerül értékesítésre, készül egy bejegyzés is. A dimenziók ezen listája határozza meg a tény tábla finomságát, felbontását. A tény táblában szereplő összes bejegyzésnek ugyanolyan felbontásúnak kell lennie. Egy adattárház szempontjából a leghasznosabb mértékek számszerűek és összeadhatóak, mivel igen ritka az az eset, amikor egyetlen sorra kiváncsi a felhasználó. Nem minden tényadat összeadható, léteznek részlegesen összeadható (semiadditive) mértékek, amelyeket csak bizonyos dimenziók mentén lehet összeadni. Például, ha a tényadatunk egy ügyfél adott napra vonatkozó számla egyenlege, akkor értelmetlen ezen egyenlegeket az idő dimenzió mentén összeadni, viszont annak már lehet üzleti értelme, hogy az ügyfél dimenzió mentén végezzük el ugyanezt (mekkora az ügyfeleink összegyenlege). Ha egy tényadat semmilyen dimenzió mentén nem adható össze (pontosabban összeadható, csak a kapott eredmény nem értelmezhető), akkor nem összeadható (nonadditive) tényekről beszélünk. Ilyenre tipikus példa lehet valamilyen állapot-jellemző: hőmérséklet, nyomás, stb. A tény adatokat három alapvető kategóriába sorolhatjuk: tranzakciós tények (transaction facts): valamilyen tranzakció, esemény hatására keletkező adatok (például értékesítés). periodikus pillanatképek (periodic snapshots): a tény adataink valaminek az állapotát mutatják egy adott pillanatban. Nevezhetjük ezeket készlet-jellegű tényeknek is, ugyanis tipikus példa lehet egy raktárkészlet, vagy számla egyenleg napi állapotát jelképező tény adatok. Ilyen jellegű tény adatokból a granularitásnak megfelelő időközönként mindig történik feljegyzés, ellentétben a tranzakciós tényekkel, ahol csak akkor szúrunk be új rekordot, ha történt valami. Emiatt az ilyen jellegű tény táblák hamar hatalmas méretűre duzzadnak, ezért kompromisszumos megoldásokat szokás alkalmazni: például az utolsó 60 nap adatait tároljuk csak napi szintre lebontva, a régebbi adatokat pedig magasabb aggregáltsági szinten, mondjuk heti összesítésben. halmozódó pillanatképek (accumulating snapshots): a halmozódó pillanatkép jellegű tény adatokhoz mindig több időpecsét tartozik, egy adott üzleti folyamat különböző állomásainak megfelelően. A periodikus pillanatképekhez hasonlóan itt is valaminek az állapotát reprezentálják a tény adataink, azzal az alapvető különbséggel, hogy az üzleti folyamat előrehaladtával ahogy egyre több információ áll rendelkezésünkre a tény adatainkat frissítjük, átértékeljük. Létezik még egy speciális konstrukció: a tény nélküli tény táblák (factless fact table). Az ilyen táblák több-több kapcsolatot reprezentálnak a dimenziók között. Például, 6
3. A DIMENZIÓS MODELLEZÉS 3.2. Dimenziók ha a tény adataink valamilyen eseményt jelentenek, mondjuk diákok órákra való jelentkezését, akkor nincs igazi tény adatunk, mértékünk, amit a tény táblába helyezhetnénk. Ilyenkor az információt az szolgáltatja, hogy van-e a dimenzióknak egy keresett konstellációja (adott diák adott tárgyra adott szemeszterben jelentkezett-e). Ezek a tény nélküli tény táblák az olyan jellegű kérdésekre adhatnak választ, hogy kik, hányan jelentkeztek valamire, de egy esemény nem-bekövetkezését nem tartalmazzák. Ilyen esetekben felvehetünk explicit sorokat egy bit jellegű oszloppal megkülönböztetve, hogy az adott sor azt jelenti, hogy az esemény bekövetkezett-e vagy sem. 3.2. Dimenziók A dimenziók a tények kísérői. Ezek tartalmazzák a szöveges leírásait az adott üzleti folyamatnak. Egy jól megtervezett dimenziós modellben a dimenzióknak a lehető legtöbb oszlopa vagy másnéven attribútuma van, ugyanis ezek az attribútumok játszanak a lekérdezéseknél, elemzéseknél csoportosító, megszorító, vagy magyarázó szerepeket. Emiatt létfontosságú, hogy minél több jól definiált, értelmes dimenzió attribútum legyen, mert ezek határozzák meg az adattárház használhatóságát. A dimenziók jelentik az interfészt az adattárház és a felhasználó között. Míg a tény adatok főleg számszerűek és folytonos értékkészletűek, addig a dimenzió attribútumok általában szövegesek, és diszkrétek. Elképzelhető olyan dimenzió, amihez nem tudunk értelmes leírást társítani. Ilyenre lehet példa egy forrás-rendszerbeli tranzakciós azonosító. Habár ez egy dimenzió jellegű adat, mégis a tény adatok közé vesszük fel, nem készítünk különálló dimenziót, ahol egyedüli attribútumként szerepelne. Ezeket elfajult (degenerate) dimenzióknak nevezzük. 3.3. Csillag séma A csillag séma a tények és a dimenziók csillag szerű összekapcsolásából áll. A középen álló tény tábla tartalmazza a számszerű (lehetőleg összeadható) mértékeket, valamint a csillag-szerűen kapcsolódó dimenzió táblákra való hivatkozásokat (távoli kulcsokat). 1. ábra. Csillag séma: középen álló tényekhez csillag-szerűen kapcsolódó dimenziók A legkézenfekvőbb tulajdonságai a csillag sémának az egyszerűség, és a szimmetria. Talán már ránézésre is érthetővé válik, hogy milyen üzleti folyamatot reprezentál a modell, még egy informatikában kevésbé jártas üzleti felhasználó számára is. 7
3.3. Csillag séma 3. A DIMENZIÓS MODELLEZÉS Az egyszerűség másik jelentős következménye a jó lekérdezési teljesítmény. Az adatbázis motor sokkal kevesebb join segítségével tudja végrehajtani a lekérdezéseket. Ezt elsősorban a bitmap indexek teszik lehetővé, amikről bővebben a 3.3.1. alfejezetben írok. A szimmetriának köszönhetően minden dimenzió teljesen ekvivalens, mindegy melyik dimenzió felhasználásával indít lekérdezéseket a felhasználó, nincs különbség. Nincsenek a modellbe épített feltételezések a leendő lekérdezéseket illetően. Egy adattárházban modellezhetünk több üzleti folyamatot is. Az igényeknek megfelelően több csillagot (multidimenziós szóhasználattal kockát, hiperkockát) is építhetünk. Az adattárházak időorientáltságából is következően valószínű, hogy az összes tény adatunkhoz fog kapcsolódni valamilyen idő dimenzió (egy tényhez akár több is). Az egyik tényhez kapcsolva egy idő jelentheti mondjuk az eladás időpontját, egy másik tényhez kapcsolva pedig a megrendelés napját. Az ilyen dimenziókat role-playing dimenzióknak nevezzük. Ezeket relációs fizikai modellben úgy valósíthatjuk meg, hogy egy táblát hozunk létre az adott dimenziónak (próbálva a lehető legkonformabbra venni), és ezt illesztjük a különböző tény táblákhoz, vagy akár egy tény tábla különböző oszlopaihoz. Kimball konform dimenziók felhasználásával úgynevezett adattárház busz-architektúra kialakítását javasolja [1]: szabványosított dimenziók és tények felállítását, amik értelmezése az egész vállalatra nézve egységes. Ezzel megteremthetjük a lehetőségét a tények közötti átfúrásnak (drilling across). Ennek könnyű nyilvántartásához egy mátrix-szerű leírást javasol: a mátrix soraiban a modellezett üzleti folyamatokat, az oszlopaiban pedig a konform dimenziókat írjuk. A 2. táblázatban ott szerepel X, ahol a folyamat rendelkezik az adott dimenzióval. Idő Termék Bolt Raktár Értékesítés X X X Raktárkészlet X X X Rendelések X X 2. táblázat. Adattárház busz-mátrix: mely tény-táblák milyen közös dimenziókkal rendelkeznek 3.3.1. Bitmap indexek Az indexek a lekérdezésekben szereplő szelekciós feltételek kiértékelésénél használatosak (pl.: WHERE T.A = 1000). Általános esetben egy lekérdezés végrehajtási ideje az indexek feldolgozásának és az adatok kinyerésének ideje. Ha egy lekérdezés eredményhalmazának mérete jelentős a tábla teljes méretéhez viszonyítva, akkor az adatelérés ideje megközelítheti egy teljes table scan (amikor a tábla minden során egyesével végigmegyünk) idejét. Ilyen esetekben az indexek használata épphogy lassítaná a lekérdezést. Erre a problémára az egyik elterjedt megoldás az ún. bitmap indexek, vagy magyarra fordítva bittérképes indexek használata. Bitmap indexekből is többféle létezik, a család legegyszerűbb tagja az egyszerű bitmap indexek (simple bitmap indexes). Például, ha az indexelni kívánt attribútum a nemek (ami tipikusan két értéket vehet fel: Férfi, Nő), akkor az index egy két bitből álló vektor lenne, az egyik bit a férfiak esetén lenne 1-es, a másik pedig nők esetében: 8
3. A DIMENZIÓS MODELLEZÉS 3.3. Csillag séma gender= M gender= F cust_id 70 0 1 cust_id 80 0 1 cust_id 90 1 0 cust_id 100 0 1 cust_id 110 0 1 cust_id 120 1 0 cust_id 130 1 0 cust_id 140 1 0 A fenti táblázat minden sora az Ügyfél (Customer) tábla egyik rekordjához tartozik. Az egyszerű bitmap indexek mérete az indexelendő attribútum kardinalitásának és a tábla méretének lineáris függvénye, és az index feldolgozás ideje az index méretének lineáris függvénye. Emiatt rögtön látszódik az egyszerű bitmap indexek egyik hátrányos tulajdonsága: ha az indexelendő attribútum sokféle értéket vehet fel, akkor a táblázat igen ritka lesz (sparsity problem), egy sorhoz tipikusan csak egy darab 1-es fog tartozni, a többi bit értéke 0 lesz. Ez pedig nem nevezhető hatékony tárhely-kihasználásnak. Erre megoldás lehet a bittérképek tömörítése (pl.: futáshossz kódolással), de így elveszítenénk a bitmap indexek egy igen kellemes tulajdonságát: ha több feltétel egyszerre történő teljesülését akarjuk vizsgálni, akkor a bittérképek adott oszlopainak logikai ÉS kapcsolatát kell csak kiszámolnunk: gender= M region= central cust_id 70 0 1 0 cust_id 80 1 1 1 cust_id 90 1 AND 0 = 0 cust_id 100 0 0 0 cust_id 110 1 1 1 azaz a 80-as és a 110-es ügyfél tartozik a központi régióban levő férfiak közé. Ming-Chuan Wu [4]-ban két olyan bitmap indexet is javasol, amik megőrzik a fent bemutatott előnyöket és mégis hatékonyabb tárhelykihasználtságot tesznek lehetővé. Bit-sliced indexing Az első az ún. bit-sliced indexelés. Egy attribútum bit-sliced indexe az attribútum értékének bitenkénti leképezése. Például, ha egy A attribútum egy 16-bites egész szám, és értékei 100 és 900 közötti értékeket vehetnek fel, akkor a hozzá tartozó index így nézhet ki: A b 15...b 10 b 9 b 8 b 7 b 6 b 5 b 4 b 3 b 2 b 1 b 0 201 0...0 0 0 1 1 0 0 1 0 0 1 100 0...0 0 0 0 1 1 0 0 1 0 0 900 0...0 1 1 1 0 0 0 0 1 0 0 A bitvektorok száma megegyezik az attribútum típusának méretével, a vektorok hossza pedig az indexelt tábla kardinalitásával. Egy bit-sliced indexnek nem feltétlen kell bináris alapúnak lennie, elképzelhető például decimális alapú bit-sliced index is. Az előző példában szereplő A attribútum tizes alapú indexe három komponensből állna, a helyiértékeknek megfelelően. A b 9 b 8 b 7 b 6 b 5 b 4 b 3 b 2 b 1 b 0 b 9 b 8 b 7 b 6 b 5 b 4 b 3 b 2 b 1 b 0 b 9 b 8 b 7 b 6 b 5 b 4 b 3 b 2 b 1 b 0 124 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 harmadik komponens második komponens első komponens 9
3.3. Csillag séma 3. A DIMENZIÓS MODELLEZÉS Ilyen típusú indexek esetén a kiválasztás a megfelelő bitvektorok kiolvasásával és össze-és-eléssükkel történik. Például az A=124 szűrőfeltétel esetén a b 1 b 2 b 4 vektorokat olvassuk ki rendre a harmadik, második illetve első komponensekből, és logikai ÉS kapcsolatba hozzuk őket. Az eredmény pedig azon sorokat tartalmazza, ahol az A értéke 124. Az alap kiválasztása a tárhelykövetelményeket és a feldolgozási sebességet befolyásolja. A fenti példában a bináris alapú index 16 bitvektorból áll, míg a tizes alapú 30-ból. Egy szűrő feltétel kiértékelése (pl.: A=124) bináris alapon 16 bitvektor végigpásztázását jelenti, decimális alapon viszont csak háromét. Encoded Bitmap Indexing Egy másik bitmap indexelést kódolt bitmap indexelésnek neveznek (encoded bitmap indexing, EBI). Az EBI az attribútum értelmezési tartományát leképezi egy kódoló függvény segítségével, és a kódolt értékeken felépít egy bináris alapú bit-sliced bittérképet. A bináris alap és kódolás segítségével hatékony tárhelykihasználtságot tesz lehetővé, ugyanakkor viszont megtartja a lekérdezés-optimalizálás lehetőségét jóldefiniált kódolás segítségével (well-defined encoding). Például, ha egy B attribútum értelmezési tartománya {a, b, c, d, e, f, t, u, v, w}, akkor egy M függvényt az alábbi módon definiálhatunk: B M(B) void 0000 NULL 0001 a 0010 b 0011 c 0100 d 0101 e 0110 f 0111 t 1000 u 1001 v 1010 w 1011 a void az adatbázisból törölt, a NULL pedig a NULL értékeket reprezentálja. A fenti táblázathoz tartozó minterm-ek: f void = b 3 b 2 b 1 b0 f b = b 3 b 2 b 1 b 0 f null = b 3 b 2 b 1 b 0 f c = b 3 b 2 b 1 b 0 f a = b 3 b 2 b 1 b 0 f d = b 3 b 2 b 1 b 0 f e = b 3 b 2 b 1 b 0 f u = b 3 b 2 b 1 b 0 f f = b 3 b 2 b 1 b 0 f v = b 3 b 2 b 1 b 0 f t = b 3 b 2 b 1 b 0 f w = b 3 b 2 b 1 b 0 EBI segítségével egy szűrés az alábbi módon hajtható végre: szűrőfeltétel: B {a,b,e,f} Ezekhez az elemekhez tartozó minterm-ek egy Boole függvényt alkotnak: f a + f b + f e + f f, amit tovább lehet egyszerűsíteni b 3 b 1 -re. Azaz, azon értékek elégítik ki a szűrőfeltételt, amik b 3 bitjét negálva majd b 1 bitjükhöz ÉS-elve 1-et kapunk. 10
3. A DIMENZIÓS MODELLEZÉS 3.3. Csillag séma Az EBI valójában nem más, mint egy bináris alapú bit-sliced bitmap index egy attribútum kódolt értelmezési tartományán. Az EBI-knek két előnyük van a bit-sliced indexek felett: a bitvektorok száma nem több, mint a bit-sliced esetében, hiszen a szükséges bitvektorok száma az adott attribútum számosságának kettes alapú logaritmusa (+2 a törölt és NULL értékek miatt, és ennek a felsőegészrésze). EBI esetében több optimalizálási lehetőség van "megfelelő" kódoló függvény kiválasztása esetén. Ilyen függvényeket Wu [5]-ben mutat be. 3.3.2. Csillag transzformáció Ezen kitekintő után térjünk vissza a csillag sémánkhoz. Például, egy szokásos értékesítési adatokat tartalmazó sales tény-tábla esetén dimenziók lehetnek: idő, ügyfél, termék, értékesítési csatorna. Tekintsük az alábbi lekérdezést: SELECT ch.channel_class, c.cust_city, t.calendar_quarter_desc, SUM(s.amount_sold) sales_amount FROM sales s, times t, customers c, channels ch WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id AND s.channel_id = ch.channel_id AND c.cust_state_province = CA AND ch.channel_desc in ( Internet, Catalog ) AND t.calendar_quarter_desc IN ( 1999-Q1, 1999-Q2 ) GROUP BY ch.channel_class, c.cust_city, t.calendar_quarter_desc; Oracle adatbáziskezelő alatt a csillag transzformáció feltétele [13], hogy minden illesztéshez használt oszlopon definiálva legyen egy bitmap index, ebben az esetben cust_id, time_id, channel_id. A lekérdezést két menetben hajtja végre az adatbáziskezelő motor. Az alábbi lekérdezés végrehajtásával csak azokat a sorokat gyűjti ki a tény táblából, amik valóban szükségesek: SELECT... FROM sales WHERE time_id IN (SELECT time_id FROM times WHERE calendar_quarter_desc IN( 1999-Q1, 1999-Q2 )) AND cust_id IN (SELECT cust_id FROM customers WHERE cust_state_province= CA ) AND channel_id IN (SELECT channel_id FROM channels WHERE channel_desc IN( Internet, Catalog )); Ebben a lekérdezésben a tény táblán a time_id-re definiált bitmap index segítségével kiválasztjuk azokat a sorokat, amik 1999. első negyedévére vonatkoznak. Ez valójában annyit jelent, hogy azokat a sorokat választjuk ki, amiknél a bittérképben 11
3.4. Hópehely séma 3. A DIMENZIÓS MODELLEZÉS az 1999-Q1 bit értéke 1-es értékű. Hasonlóan történik a második negyedév adatainak kiválasztása. A kettő bitenkénti VAGY kapcsolatba hozásával kapjuk meg a kívánt időszakot. Ugyanilyen módon történik az ügyfelekre és értékesítési csatornákra történő szűrőfeltételek kiértékelése. A kapott három bittérképet majd logikai ÉS kapcsolatba hozva csupán azon sorok esetén kapunk 1-es értéket, amik az összes feltételt kielégítik. A második lépésben történik meg a tény tábla kiválasztott sorainak a dimenzió táblákhoz történő illesztése. Mivel a dimenzió táblák relatíve kis méretűek a tény táblákhoz viszonyítva, az Oracle általában teljes "table scan"-t használ az elérésükhöz. 3.4. Hópehely séma A csillag séma egyik jellemzője, hogy az adott dimenzió minden hierarchia-szintjét egy struktúrában tároljuk, ezzel redundanciát víve a rendszerbe. Ennek kiküszöbölésére szolgál a hópehely séma (snowflake schema). A dimenziókat a hierarchia-szintek mentén normalizáljuk, tipikusan 3NF szintre. Például, egy termék dimenzióban, ahelyett, hogy minden hierarchiának megfelelő attribútumot egy táblában tárolnánk (termék - márka - kategória -..), ezeket szétbontjuk: lesz egy tábla a termék dimenziónak, amihez kapcsolódik a márka (több-egy kapcsolat), amihez a kategória, és így tovább. Ezzel csökkentjük a redundanciát, amivel tárhelycsökkenést érünk el. Viszont cserébe több join művelet válik szükségessé. Mivel kijelenthető, hogy a tárhely a számítási kapacitáshoz viszonyítva olcsó, ezért [1] nem ajánlja a hópehely sémát. Ezzel szemben [3] szerint ez a séma drámaian csökkenti az aggregátumok képzését és karbantartását. 3.5. Négy lépéses dimenziós modellezés Kimball által bevezetett modellezési módszertan középpontjában a négy lépéses dimenziós modellezés áll [1]: 1. Az üzleti folyamat kiválasztása: üzleti folyamat egy adott üzleti cél elérésének érdekében tett összefüggő cselekvések rendezett sorozata. Üzleti folyamat lehet például a termékek szupermarketekben történő értékesítése. 2. A granularitás meghatározása: pontosan definiáljuk, hogy egy tény-rekord mit jelent: az értékesítési adatokat napi, heti, havi, stb. összesítésben, termékenként, szupermarketenként. Ha részletes felbontást választunk, a tény táblánk nagy lesz, megnövelve a feldolgozás erőforrás-igényét. Ha pedig aggregáltan tároljuk az adatokat, akkor a lehetséges elemzések halmazát eleve leszűkítjük. 3. A dimenziók meghatározása: a tényekhez dimenziókat rendelünk, amik az egyes sorok szöveges leírását reprezentálják, vagyis a dimenziók az adattárház felé intézett lehetséges kérdések szempontjainak halmaza. 4. A tény adatok meghatározása: ebben a lépésben a Mit mérünk? kérdésre keressük a választ. Minden tény adatnak ugyanarra a granularitásra kell vonatkoznia. 12
4. ESETTANULMÁNY 4. Esettanulmány Ebben a fejezetben a 3.5. részben bemutatott dimenziós modellezés lépéseit illusztrálom egy képzeletbeli világban. 4.1. Informális leírás Vegyünk egy jelzálog-hitelezéssel foglalkozó pénzintézetet. Az ügyfeleinek ingatlanfedezet mellett hiteleket nyújt, melyeket összecsomagolja, értékpapírosítja, és jelzálogleveleket bocsát ki. A hitelek lehetnek forint, svájci frank és euró alapúak, a jelzáloglevelek pedig forintban és euróban denomináltak. A jelzáloglevelek fedezeteként a hitelek szolgálnak, melynek fedezetei az ingatlanok. A bank prudens módon napi szinten szeretné ellenőrizni, hogy a kibocsátott jelzálogleveleinek mekkora részére van hitel-fedezet. Sőt, túlfedezettséget vállal: ellenőrizni szeretné, hogy minden nap fennálljon az az összefüggés, hogy a kibocsátott hitelek 10%-ban meghaladják a kibocsátott jelzáloglevél állományt. A hitel-adatok egy fedezet-nyilvántartó rendszerből származnak, készlet-jelleggel, azaz minden nap kinyerhetjük a rendszerből, hogy mennyi a bank hitelállománya 2, devizánkénti és ügyfelenkénti bontásban. A jelzáloglevél-adatok egy másik rendszerben vannak nyilvántartva: minden egyes kibocsátáskor rögzítenek egy ügyletet, amiben szerepel, hogy kinek, mekkora mennyiségű, milyen jelzálog-levelet értékesített a bank. 4.2. Az üzleti folyamat kiválasztása Az informális leírásból kiderül, hogy két üzleti folyamat modellezésére lesz szükség. Az egyik a hitelezés, a másik a jelzáloglevél-kibocsátás. A hitelezés egy összetett folyamat, a felhasználói igényekből viszont kiderül, hogy csak az adott napon fennálló hitelek aggregált összegére esetleg devizanemenként megbontva lesz szükség. A jelzáloglevél-kibocsátásról tranzakció jellegű információk állnak rendelkezésre, viszont itt is készlet-jellegű adatokra lesz szükség. Ezt a betöltő folyamatban (ETL Extract, Transform, Load) lehet megvalósítani. 4.3. Granularitás meghatározása Ebben a lépésben meg kell határozni, hogy milyen felbontásban fogjuk a tényadatainkat eltárolni, azaz a tény táblában egy rekord mit jelent. A specifikációból adódik, hogy napi szinten kell tárolni az adatokat. Ennél részletesebb felbontás esetén fölösleges terhelést helyeznénk a rendszerre, magasabb aggregáltság esetén pedig elvesztenénk a napi analízis lehetőségét. A hitel adatok devizanemenkénti megbontása tervezési döntés. Üzleti igény jelenleg csak az összesített adatok lekérdezésére van, de mivel a devizánkénti bontás csupán háromszoros méretnövekedést jelent, ezért ennek megtartása mellett döntök. Hasonló kérdés az ügyfelenkénti bontás eldöntése. Gyakori szituáció, hogy a kezdeti, informális specifikációból nem derül ki egyértelműen, hogy milyen adatokra milyen formában lesz szükség. Az ilyen kérdéses eseteket még a tervezés megkezdése 2 nominálisan, azaz a kamatoktól eltekintünk 13
4.4. A dimenziók meghatározása 5. EGYÉB ADATMODELLEK ADATTÁRHÁZAKHOZ előtt interjúk segítségével kell eldönteni. Tegyük fel, hogy a felhasználói igények megkövetelik a hitel adatok ügyfelenkénti bontását. Összefoglalva, a hitel tény tábla a fennálló hitel állományt jelenti az adott napon, devizánkénti és ügyfelenkénti bontásban. A kibocsátott jelzáloglevél-portfóliót tároló tény tábla sorai hasonló megfontolásokból az adott napon fennálló jelzáloglevél állományt jelentik devizánkénti és ügyfelenkénti bontásban. 4.4. A dimenziók meghatározása Egy jelzálog-hitellel rendelkező magánszemély ritkán azonos egy jelzáloglevél vásárlójával (tipikusan intézményi befektető). Mégis, a modellünk szempontjából mindkettőt ügyfélnek tekintjük: role-playing dimenzió. A jelzáloglevél táblához kapcsolva a jelzáloglevél (elsődleges) megvásárlóját, a hitel táblához kapcsolva a hitel tulajdonosát jelenti. Univerzális dimenzió az idő. Az idő dimenzió mentén definiálhatunk hierarchiaszinteket: nap hónap negyedév év. Dimenzió jellegű adat még a devizanem. Viszont egy devizanemhez nehezen tudunk szöveges leíró jellemzőket társítani. Ezért a tény táblákban ezek elfajult (degenerate) dimenziók lesznek. 4.5. A tény táblák attribútumainak meghatározása A hitel tény táblánkban tény adat a fennálló hitelállomány összege: amount. A jelzálog tény táblánkban pedig a fennálló jelzáloglevél-állomány összege, pontosabban csak a kintlevő tőke-összeg: outstanding principal. A modell ezen a ponton két csillagból áll, a középpontokban a két tény tábla áll. Mivel gyakorlatilag minden dimenzió konform, ezért a modell eleget tesz azon követelménynek, hogy az egyik készlet-jellegű adatot összehasonlíthatjuk a másikkal az átfúrás (drill-through vagy drill-across) művelet segítségével. Fontos megjegyezni, hogy a tény adatok nem adhatóak össze az idő dimenzió mentén (semi-additive facts), csak az ügyfél és a deviza 3 dimenziók mentén. 5. Egyéb adatmodellek adattárházakhoz Számos egyéb modellezési megközelítést is lehet találni a szakirodalomban. Az adattárházak tervezésének folyamatának három részre tagolását javasolja [6]: koncepcionális, logikai és fizikai modellezés. [8] ezt annyiban egészíti ki, hogy a koncepcionális modellezést megelőzi a követelmény-analízis és specifikáció fázisa. Jens Lechtenbörger [7]-ben később azt írja, hogy az első, koncepcionális tervezési fázis tartalmazza a követelmény-analízist. Mivel az adattárház tervezés célja a meglévő forrás-rendszerek integrálása, ezért követelmény-analízis fázis fő bemenete a forrásrendszereket leíró sémadefiníciók [7]. Ebben a fázisban az adattárházat tervező mérnökök, végfelhasználók és üzleti szakértők kiválasztják a releváns attribútumokat, és meghatározzák a felhasználás célját: dimenzióként vagy tény jellegű mértékként fog szerepelni. A fázis kimenete egy táblázat- 3 egyszerűsítésként feltételezzük, hogy a devizánkénti bontás az adott devizában kintlevő tőke összegét forintban jelenti 14
5. EGYÉB ADATMODELLEK ADATTÁRHÁZAKHOZ 5.1. Multidimenziós E/R modell szerű felsorolása az attribútumoknak a multidimenziós modellben betöltött szerepük megjelölésével. A következő fázis a koncepcionális modellezés fázisa (conceptual design), amikor a félig-formális üzleti követelményeket formalizált multidimenziós sémává transzformáljuk [8]. Ennek eredménye egy grafikus diagram. A logikai fázis a koncepcionális sémát egy logikai modellé alakítja, leggyakrabban relációs vagy multidimenziós modellé. A csillag séma egy logikai modellnek tekinthető [9]. Az adattárház tervezés folyamata a logikai sémák fizikai megvalósításával ér véget. Ebben a fázisban az adatbázis rendszer által nyújtott optimalizációs megoldásokat (indexelés, partícionálás, stb.) finomhangoljuk. A következő fejezetekben vázlatosan bemutatok különböző koncepcionális modelleket. 5.1. Multidimenziós E/R modell [10] A multidimenziós E/R (röviden: ME/R) modell a hagyományos Entity-Relationship modell kiterjesztése. Tervezésének főbb szempontjai: E/R modell specializációja: minden új elem a natív E/R komponensek valamilyen speciális esete legyen. Az E/R modell minimális kiterjesztése: azok számára, akik tisztában vannak az E/R modellel, könnyű legyen a kiterjesztett változat megtanulása, ezért a bevezetett új elemek száma a lehető legkisebb legyen. Reprezentálja a multidimenziós szemantikát: rendelkezzen kifejezőerővel az alapvető multidimenziós elemek leírására: meg lehessen különböztetni a leíró és mérték-jellegű adatokat, és a leírások közötti hierarchiákat. Ezen alapelvek mentén az alábbi új elemeket vezették be: speciális entitás egy dimenzió adott szintjének leírására a dimenziók között több-több kapcsolatot megtestesítő reláció a tények leírására két dimenzió között egy bináris reláció a hierarchia-szintekben történő vándorlás (rolls-up) leírására Ezen konstrukciókat szemlélteti a 2. ábra. A rolls-up reláció jelentése: A hierarchiaszint magasabb absztrakciós szintje B (például: város rolls-up ország). A hierarchiaszintekből és rolls-up relációkból álló gráfnak aciklikusnak kell lennie (DAG). 2. ábra. A M/ER modellt alkotó új elemek 15
5.2. starer modell 5. EGYÉB ADATMODELLEK ADATTÁRHÁZAKHOZ A 3. ábra egy egyszerű modellt szemléltet: a tény-reláció az eladásokat (sales) reprezentálja, aminek egyetlen attribútuma az ár. Ehhez kapcsolódik az idő, a termék és a bolt dimenzió. Az idő dimenzió mentén két hierarchia-szint definiált: nap és hónap. 3. ábra. Egy egyszerű modell grafikus ábrázolása a ME/R segítségével 5.2. starer modell [11] A starer modell megalkotói szerint a legszéleskörűbben alkalmazott koncepcionális modellt, a hagyományos E/R modellt és az elterjedt új sémákat (csillag, hópehely) egy modellben kell egyesíteni. Ennek megfelelően a starer modell az alábbi építő elemekből áll: Tény halmaz: a világ olyan tényeinek halmaza, amik ugyanolyan tulajdonságokkal rendelkeznek. Egy tény halmaz egy olyan eseményre utal, ami bizonyos időközönként adatot termel. Ezen tulajdonság miatt egy tény halmaz mindig időhöz kötött. Például, egy jelzáloghitelt felvett személy havonta törleszt. Ebben az esetben az esemény a hitel törlesztése, a tény halmaz pedig a törlesztés. Grafikus jelölése egy kör. Entitás halmaz: olyan objektumok halmaza, amik ugyanolyan tulajdonságokkal rendelkeznek, hasonlóan a hagyományos E/R modell entitás fogalmához. A fenti hitelezés példában egy entitás halmaz lehet az Ügyfél. Grafikus jelölése egy téglalap. Reláció halmaz: entitás halmazok és tény halmazok, vagy entitás halmazok közötti kapcsolatot reprezentál. Számossága lehet több-több, több-egy, vagy egytöbb. Például a visszafizet reláció több-egy kapcsolatba hozhatja a törlesztés tényhalmazt és a hitel entitás halmazt. A grafikus jelölése egy rombusz. Az entitás halmazok közötti relációknak lehetnek specializált esetei az általánosítás, aggregáció illetve tartalmazás kifejezésére. Például: a személy entitás specializált változata az ügyfél entitás (specializáció), vagy két szemeszter összevonható egy évvé (aggregáció), vagy ország régiókból áll (tartalmazás). Ezek grafikus reprezentációját a 4. ábra mutatja. 16
5. EGYÉB ADATMODELLEK ADATTÁRHÁZAKHOZ 5.2. starer modell Attribútum: entitás, tény vagy reláció halmazoknak statikus tulajdonságai. Analóg módon a hagyományos E/R modellel a grafikus jelölése egy ellipszis. A modell megkülönböztet úgynevezett stock, flow és value-per-unit jellegű attribútumokat az összesíthetőségük szerint. A stock jellegű attribútumok valaminek az aktuális állapotát jelentik, például egy ingatlan ára. A flow jellegű attribútumok minden dimenzió mentén összeadható adatok, például a törlesztett pénz mennyisége. Az utolsó, value-per-unit attribútumok a nem összeadható adatok, például a kamatláb. Ezeket az attribútumot jelölő ellipszis bal oldalába írt "S", "F", és "V" betűkkel jelöljük. 4. ábra. A starer modellben a reláció halmazok specializált változatai A hitelek törlesztését modellező starer diagram az 5. ábrán látható. 5. ábra. Hitelek törlesztése starer-rel modellezve Az ábrán egyetlen tény halmaz szerepel, a hitelek törlesztése. Ehhez két dimenzió kapcsolódik: az idő (nap entitás) és az ügyfél (ügyfél entitás). A nap entitást tartalmazza a hónap entitás. A törlesztés attribútuma a törlesztett mennyiség, ami egy flow jellegű tény adat, azaz minden dimenzió mentén összeadható. Az ügyfél egy specializált változata a személy entitásnak. A starer modellek a dimenziók mentén definiált hierarchia-szinteket a tartalmazás 17
5.3. Objektum-orientált modellek 6. ÖSSZEFOGLALÁS reláció segítségével támogatják. Egy dimenzióra akár több hierarchiát is definiálhatunk. 5.3. Objektum-orientált modellek [9] Létezik objektum-orientált megközelítése is az adattárházak koncepcionális modellezésének. [9]-ben az UML nyelvet ajánlják ennek elérésére, mert szerintük az UMLel kézenfekvőbben modellezhetőek egy információs rendszer struktúrális és dinamikus tulajdonságai. Ezen kívül az UML a felhasználói követelményeknek megfelelő korlátozásokra olyan lehetőséget nyújt, mint az Object Constraint Language. A tényeket tény osztályokkal, a dimenziókat dimenzió osztályokkal modellezik. A tény osztály aggregációs relációban van a dimenzió osztályokkal. 6. ábra. Termékek eladását bemutató UML modell A 6. ábrán egy termékek eladását reprezentáló tény-osztály látható, amihez a dimenzió osztályok az aggregáció relációval kapcsolódnak. 6. Összefoglalás Az adattárházak tervezése egy igen összetett feladat. Az ebben a témában megjelent első könyvek ([2] [1]) közérthető módon, lépésről lépésre, szemléletes példákkal illusztrálva mutatták be a tervezés folyamatát. Azóta számos publikáció, könyv született a témában, amik azt célozták meg, hogy a tervezés ad-hoc jellegét jól definiált, formális alapokra helyezik. Több koncepcionális adatmodell született, melyekből párat az 5. fejezetben mutattam be. Több olyan terület kapcsolódik az adattárházak tervezéséhez, melyeket nem érintettem ezen dokumentumban. Ezekből kiemelendő az adattárházak töltésének (ETL) megtervezése, az adattárházak életciklusa, illetve mivel egy adattárház önmagában csupán az adatok halmaza a hozzá kapcsolódó prezentációs réteg: azon alkalmazások, segédeszközök köre, melyek az elemzéseket, riportkészítéseket segítik, azaz lehetővé teszik, hogy az adattárházat valóban döntéstámogatásra használhassuk. Ezt a csomagot üzleti intelligencia megoldásoknak nevezik. 18
7. IRODALOMJEGYZÉK 7. Irodalomjegyzék [1] Kimball, Ralph, Ross, Margy: The Data Warehouse Toolkit The complete guide to dimensional modeling (2002) második kiadás, Wiley & Sons [2] Inmon, William Harvey: Building the Data Warehouse (2002) harmadik kiadás, Wiley & Sons [3] Adamson, Christopher: Mastering Data Warehouse Aggregates Solutions for Star Schema Performance (2006), Wiley & Sons [4] Wu, Ming-Chuan: Query Optimization for Selections using Bitmaps (1999) [5] Wu, Ming-Chuan: Encoded Bitmap Indexing for Data Warehouses (1998) [6] Wu, Ming-Chuan, Buchmann, Alejandro P.: Research Issues in Data Warehousing (1997) [7] Lechtenbörger, Jens: Data Warehouse Schema Design (2003) [8] Hüsemann, Bodo, Lechtenbörger, Jens, Vossen, Gottfried: Conceptual Data Warehouse Design (2000) [9] Trujillo, Juan, Palomar, Manuel, Gomez, Jaime, Song, Il-Yeol: Designing Data Warehouses with OO Conceptual Models (2001) [10] Sapia, Carsten, Blaschka, Markus, Höfling, Gabriele, Dinter, Barbara: Extending the E/R Model for the Multidimensional Paradigm (1998) [11] Tryfona, Nectaria, Busborg, Frank, Christiansen, Jens G. Borch: starer: A Conceptual Model for Data Warehouse Design (1999) [12] Haisten, Michael: The Real-Time Data Warehouse: The Next Stage in Data Warehouse Evolution (1999) [13] Sz.n.: Oracle Database Data Warehousing Guide 11g Release 1 (11.1) Part Number B28313-02: Optimizing Star Queries http://download.oracle.com/docs/cd/b28359_01/server.111/b28313/schemas.htm hozzáférve: 2008-11-02 19