Önálló laboratórium beszámoló BME TTT

Önálló laboratórium beszámoló — BME–TTT Készítette: Tánczos Zoltán, F966Q8 Szak: m˝uszaki informatika Szakirány: Infokommunikációs rendszerek biztonsága Email cím: [email protected] Konzulens: Kardkovács Zsolt Email cím: [email protected] 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˝o

3

2. Az adattárházak definíciója 2.1. Döntéstámogató rendszerek . . . . . . . . . . . . . . . . . . . . . . .

3 4

3. A dimenziós modellezés 3.1. Tények . . . . . . . . . . . . . . . 3.2. Dimenziók . . . . . . . . . . . . . . 3.3. Csillag séma . . . . . . . . . . . . . 3.3.1. Bitmap indexek . . . . . . . 3.3.2. Csillag transzformáció . . . 3.4. Hópehely séma . . . . . . . . . . . 3.5. Négy lépéses dimenziós modellezés

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

5 6 7 7 8 11 12 12

4. Esettanulmány 4.1. Informális leírás . . . . . . . . . . . . . . . . 4.2. Az üzleti folyamat kiválasztása . . . . . . . . 4.3. Granularitás meghatározása . . . . . . . . . . 4.4. A dimenziók meghatározása . . . . . . . . . 4.5. A tény táblák attribútumainak meghatározása

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

13 13 13 13 14 14

5. Egyéb adatmodellek adattárházakhoz 5.1. Multidimenziós E/R modell . . . . . . . . . . . . . . . . . . . . . . . 5.2. starER modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3. Objektum-orientált modellek . . . . . . . . . . . . . . . . . . . . . .

14 15 16 18

6. Összefoglalás

18

7. Irodalomjegyzék

19

2

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

2. AZ ADATTÁRHÁZAK DEFINÍCIÓJA

1. Bevezet˝o 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˝osorban a dimenziós modellezés módszertanán keresztül. Az els˝o 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˝u adatmodell szerepel, aminek az oka a modell egyszer˝usége, szemléletessége valamint a jó lekérdezési teljesítmény. A következ˝o részben egy leegyszer˝usített, képzeletbeli esettanulmányon keresztül bemutatom a dimenziós modellezés f˝obb 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˝oorientált halmaza, ami operatív adatokból származik, és els˝osorban 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˝ott célszer˝u azokat az alapvet˝o célokat áttekinteni, amikre az adattárházakat eredetileg kitalálták [12]. A kezdeti id˝okben az els˝o adattárház-szer˝u rendszerek kialakulásához nagyban hozzájárult az igen sz˝ukös tárolási és feldolgozási kapacitása az akkori számítógépeknek. Els˝odleges célként fogalmazódott meg az új, egyre széleskör˝ubben 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˝ol különböz˝o, egyedi architektúra szükséges az elemz˝o rendszerekhez. 1991-ben Bill Inmon kiadta az els˝o 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˝ofügg˝o és tartós adatgy˝ujtemény a vezet˝oi 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˝o 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˝o forrásrendszerb˝ol származhatnak. Ezek integrálása nem csupán annyit jelent, hogy összedrótozzuk a meglév˝o rendszereinket, 1 Központi Statisztikai Hivatal – Oracle Essbase; Magyar Külkereskedelmi Bank – SAS; FHB Bank – Oracle

3

2.1. Döntéstámogató rendszerek

2. AZ ADATTÁRHÁZAK DEFINÍCIÓJA

hanem hogy a különböz˝o kódokat, azonosítókat közös nevez˝ore hozzuk, szabványosítjuk, hogy az adattárházból kinyerhet˝o adatok a vállalatról egységes képet mutassanak. Ennek legegyszer˝ubb 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˝ore definiált módon egységesítjük az adattárházban. Az id˝ofügg˝oség, vagy id˝oorientáltság (time-variant) azt jelenti, hogy az adattárházban szerepl˝o minden adat az id˝onek valamilyen pillanatában érvényes. Például lehet, hogy a rekordok id˝opecsé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˝o m˝uveletekre 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˝uveleteivel. 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˝oségét nagy id˝oszakokat á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˝o embernek a nap végén le kell ellen˝oriznie a nála lev˝o 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˝o forrásból érkez˝o 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˝o szempontok szerint összehasonlító összefoglalás az 1. táblázatban látható [6]. Szempont Felhasználó Funkció

Operatív rendszer Adminisztrációt végz˝o személy Napi folyamatok követése

Adatbázis tervezés Adat

Alkalmazás-orientált Aktuális, friss, atomi, normalizált, izolált

Használat Hozzáférés

Ismétl˝od˝o, rutin szer˝u Írás/olvasás, egyszer˝u tranzakciók (tipikusan pár tábla érintett)

Követelmények

Magas tranzakciós teljesítmény, adat-konzisztencia

Adattárház Döntéshozó, végrehajtó Döntéstámogatás, analitikus feldolgozás Téma-orientált Historikus, atomi és összegzett, multidimenziós, integrált Ad-hoc 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˝odleges célja a döntéstámogatás. Viszont nem csak ilyen jelleg˝u 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˝o 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˝o – akár papír alapú – dokumentumokhoz való hatékony hozzáférést segítik. • tudás orientált: szakért˝oi rendszerek. • modell orientált: egy folyamat valamilyen szempontból történ˝o modellezését, illetve a modell analízisét, szimulációját segít˝o 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˝oké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˝o dimenzió, akkor a változók egy adott (x0 , y0 , z0 ) é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˝o 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˝oen. Egy dimenzió mentén összesíthetjük (aggregálhatjuk) az adatainkat egy magasabb hierarchia szintig. Az aggregációt így írhatjuk le: X w′ = F (x, y, z ′ ) = f (x, y, z) z∈{z ′ }

A fenti kifejezés azt írja le, hogy összesítsük az eladási adatainkat az id˝o dimenzió mentén a havi szintr˝ol a következ˝o, 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˝oké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˝o, 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


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˝u 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˝o összes bejegyzésnek ugyanolyan felbontásúnak kell lennie. Egy adattárház szempontjából a leghasznosabb mértékek számszer˝uek é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˝o 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˝o), akkor nem összeadható (nonadditive) tényekr˝ol beszélünk. Ilyenre tipikus példa lehet valamilyen állapot-jellemz˝o: h˝omérséklet, nyomás, stb. A tény adatokat három alapvet˝o kategóriába sorolhatjuk: • tranzakciós tények (transaction facts): valamilyen tranzakció, esemény hatására keletkez˝o 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˝u tényeknek is, ugyanis tipikus példa lehet egy raktárkészlet, vagy számla egyenleg napi állapotát jelképez˝o tény adatok. Ilyen jelleg˝u tény adatokból a granularitásnak megfelel˝o id˝okö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˝u tény táblák hamar hatalmas méret˝ure 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˝u tény adatokhoz mindig több id˝opecsét tartozik, egy adott üzleti folyamat különböz˝o állomásainak megfelel˝oen. A periodikus pillanatképekhez hasonlóan itt is valaminek az állapotát reprezentálják a tény adataink, azzal az alapvet˝o különbséggel, hogy az üzleti folyamat el˝orehaladtá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.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˝u 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˝u 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˝oi. 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˝o 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˝oleg számszer˝uek és folytonos értékkészlet˝uek, addig a dimenzió attribútumok általában szövegesek, és diszkrétek. Elképzelhet˝o 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˝u 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˝u összekapcsolásából áll. A középen álló tény tábla tartalmazza a számszer˝u (lehet˝oleg összeadható) mértékeket, valamint a csillag-szer˝uen 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˝uen kapcsolódó dimenziók A legkézenfekv˝obb tulajdonságai a csillag sémának az egyszer˝uség, és a szimmetria. Talán már ránézésre is érthet˝ové 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


Az egyszer˝uség másik jelent˝os 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˝osorban a bitmap indexek teszik lehet˝ové, amikr˝ol b˝ovebben a 3.3.1. alfejezetben írok. A szimmetriának köszönhet˝oen 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˝o lekérdezéseket illet˝oen. Egy adattárházban modellezhetünk több üzleti folyamatot is. Az igényeknek megfelel˝oen több csillagot (multidimenziós szóhasználattal kockát, hiperkockát) is építhetünk. Az adattárházak id˝oorientáltságából is következ˝oen valószín˝u, hogy az összes tény adatunkhoz fog kapcsolódni valamilyen id˝o dimenzió (egy tényhez akár több is). Az egyik tényhez kapcsolva egy id˝o jelentheti mondjuk az eladás id˝opontjá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˝o legkonformabbra venni), és ezt illesztjük a különböz˝o tény táblákhoz, vagy akár egy tény tábla különböz˝o 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˝oségét a tények közötti átfúrásnak (drilling across). Ennek könny˝u nyilvántartásához egy mátrix-szer˝u 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.

Értékesítés Raktárkészlet Rendelések

Id˝o X X X

Termék X X X

Bolt X

Raktár 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˝o 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˝os 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˝ol is többféle létezik, a család legegyszer˝ubb tagja az egyszer˝u 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˝o), akkor az index egy két bitb˝ol álló vektor lenne, az egyik bit a férfiak esetén lenne 1-es, a másik pedig n˝ok esetében: 8


cust_id 70 cust_id 80 cust_id 90 cust_id 100 cust_id 110 cust_id 120 cust_id 130 cust_id 140

3.3. Csillag séma

gender=’M’ 0 0 1 0 0 1 1 1

gender=’F’ 1 1 0 1 1 0 0 0

A fenti táblázat minden sora az Ügyfél (Customer) tábla egyik rekordjához tartozik. Az egyszer˝u bitmap indexek mérete az indexelend˝o 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˝u bitmap indexek egyik hátrányos tulajdonsága: ha az indexelend˝o 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˝o 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˝o teljesülését akarjuk vizsgálni, akkor a bittérképek adott oszlopainak logikai ÉS kapcsolatát kell csak kiszámolnunk: cust_id 70 cust_id 80 cust_id 90 cust_id 100 cust_id 110

gender=’M’ 0 1 1 0 1

AND

region=’central’ 1 1 0 0 1

=

0 1 0 0 1

azaz a 80-as és a 110-es ügyfél tartozik a központi régióban lev˝o férfiak közé. Ming-Chuan Wu [4]-ban két olyan bitmap indexet is javasol, amik meg˝orzik a fent bemutatott el˝onyöket és mégis hatékonyabb tárhelykihasználtságot tesznek lehet˝ové. Bit-sliced indexing Az els˝o 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 201 100 900

b15 ...b10 0...0 0...0 0...0

b9 0 0 1

b8 0 0 1

b7 1 0 1

b6 1 1 0

b5 0 1 0

b4 0 0 0

b3 1 0 0

b2 0 1 1

b1 0 0 0

b0 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˝o például decimális alapú bit-sliced index is. Az el˝oz˝o példában szerepl˝o A attribútum tizes alapú indexe három komponensb˝ol állna, a helyiértékeknek megfelel˝oen. A 124

b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 0000000010 harmadik komponens

b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 0000000100 második komponens 9

b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 0000010000 els˝o komponens

3.3. Csillag séma


Ilyen típusú indexek esetén a kiválasztás a megfelel˝o bitvektorok kiolvasásával és össze-ÉS-eléssükkel történik. Például az A=124 sz˝ur˝ofeltétel esetén a b1 b2 b4 vektorokat olvassuk ki rendre a harmadik, második illetve els˝o komponensekb˝ol, és logikai ÉS kapcsolatba hozzuk o˝ 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˝ur˝o 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˝ové, ugyanakkor viszont megtartja a lekérdezés-optimalizálás lehet˝osé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 void NULL a b c d e f t u v w

M(B) 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 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: fvoid = b3 b2 b1 b0 fnull = b3 b2 b1 b0 fa = b3 b2 b1 b0

fb = b3 b2 b1 b0 fc = b3 b2 b1 b0 fd = b3 b2 b1 b0

fe = b3 b2 b1 b0 ff = b3 b2 b1 b0 ft = b3 b2 b1 b0

fu = b3 b2 b1 b0 fv = b3 b2 b1 b0 fw = b3 b2 b1 b0

EBI segítségével egy sz˝urés az alábbi módon hajtható végre: sz˝ur˝ofeltétel: B ∈ {a, b, e, f } Ezekhez az elemekhez tartozó minterm-ek egy Boole függvényt alkotnak: fa + fb + fe + ff , amit tovább lehet egyszer˝usíteni b3 b1 -re. Azaz, azon értékek elégítik ki a sz˝ur˝ofeltételt, amik b3 bitjét negálva majd b1 bitjükhöz ÉS-elve 1-et kapunk. 10


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˝onyü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˝oegészrésze). • EBI esetében több optimalizálási lehet˝oség van "megfelel˝o" 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˝o 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˝o, ü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˝o 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˝o motor. Az alábbi lekérdezés végrehajtásával csak azokat a sorokat gy˝ujti 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˝o 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


az 1999-Q1 bit értéke 1-es érték˝u. Hasonlóan történik a második negyedév adatainak kiválasztása. A kett˝o bitenkénti VAGY kapcsolatba hozásával kapjuk meg a kívánt id˝oszakot. Ugyanilyen módon történik az ügyfelekre és értékesítési csatornákra történ˝o sz˝ur˝ofelté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˝o illesztése. Mivel a dimenzió táblák relatíve kis méret˝uek 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˝oje, 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˝o 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˝uvelet válik szükségessé. Mivel kijelenthet˝o, 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˝o cselekvések rendezett sorozata. Üzleti folyamat lehet például a termékek szupermarketekben történ˝o é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˝oforrás-igényét. Ha pedig aggregáltan tároljuk az adatokat, akkor a lehetséges elemzések halmazát eleve lesz˝ukí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˝orizni, hogy a kibocsátott jelzálogleveleinek mekkora részére van hitel-fedezet. S˝ot, túlfedezettséget vállal: ellen˝orizni 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˝ol származnak, készlet-jelleggel, azaz minden nap kinyerhetjük a rendszerb˝ol, hogy mennyi a bank hitelállománya2 , 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˝u, 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˝ol 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˝u információk állnak rendelkezésre, viszont itt is készlet-jelleg˝u adatokra lesz szükség. Ezt a betölt˝o 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˝osé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˝uen, 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˝ott 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˝o magánszemély ritkán azonos egy jelzáloglevél vásárlójával (tipikusan intézményi befektet˝o). Mégis, a modellünk szempontjából mindkett˝ot ügyfélnek tekintjük: role-playing dimenzió. A jelzáloglevél táblához kapcsolva a jelzáloglevél (els˝odleges) megvásárlóját, a hitel táblához kapcsolva a hitel tulajdonosát jelenti. Univerzális dimenzió az id˝o. Az id˝o dimenzió mentén definiálhatunk hierarchiaszinteket: nap → hónap → negyedév → év. Dimenzió jelleg˝u adat még a devizanem. Viszont egy devizanemhez nehezen tudunk szöveges leíró jellemz˝oket 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˝o t˝oke-ö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˝u adatot összehasonlíthatjuk a másikkal az átfúrás (drill-through vagy drill-across) m˝uvelet segítségével. Fontos megjegyezni, hogy a tény adatok nem adhatóak össze az id˝o dimenzió mentén (semi-additive facts), csak az ügyfél és a deviza3 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˝ozi a követelmény-analízis és specifikáció fázisa. Jens Lechtenbörger [7]-ben kés˝obb azt írja, hogy az els˝o, 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˝o forrás-rendszerek integrálása, ezért követelmény-analízis fázis f˝o bemenete a forrásrendszereket leíró sémadefiníciók [7]. Ebben a fázisban az adattárházat tervez˝o mérnökök, végfelhasználók és üzleti szakért˝ok 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˝u mértékként fog szerepelni. A fázis kimenete egy táblázat3 egyszer˝ usítésként feltételezzük, hogy a devizánkénti bontás az adott devizában kintlev˝o t˝oke összegét forintban jelenti

14

5. EGYÉB ADATMODELLEK ADATTÁRHÁZAKHOZ 5.1. Multidimenziós E/R modell

szer˝u felsorolása az attribútumoknak a multidimenziós modellben betöltött szerepük megjelölésével. A következ˝o 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˝o [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˝o fejezetekben vázlatosan bemutatok különböz˝o 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˝obb 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˝u legyen a kiterjesztett változat megtanulása, ezért a bevezetett új elemek száma a lehet˝o legkisebb legyen. • Reprezentálja a multidimenziós szemantikát: rendelkezzen kifejez˝oer˝ovel az alapvet˝o multidimenziós elemek leírására: meg lehessen különböztetni a leíró és mérték-jelleg˝u 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˝o 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˝o „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˝ol é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˝u 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˝o, a termék és a bolt dimenzió. Az id˝o dimenzió mentén két hierarchia-szint definiált: nap és hónap.

3. ábra. Egy egyszer˝u 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˝ubben 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˝oen a starER modell az alábbi épít˝o elemekb˝ol á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˝oközönként adatot termel. Ezen tulajdonság miatt egy tény halmaz mindig id˝ohö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˝u attribútumokat az összesíthet˝oségük szerint. A stock jelleg˝u attribútumok valaminek az aktuális állapotát jelentik, például egy ingatlan ára. A flow jelleg˝u 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˝o ellipszis bal oldalába írt "S", "F", és "V" bet˝ukkel jelöljük.

4. ábra. A starER modellben a reláció halmazok specializált változatai A hitelek törlesztését modellez˝o 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˝o (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˝u 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˝obben modellezhet˝oek 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˝o korlátozásokra olyan lehet˝osé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˝o könyvek ([2] [1]) közérthet˝o módon, lépésr˝ol 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˝ol 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˝ol kiemelend˝o 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˝ové 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 Wa-

rehouse 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: Exten-

ding the E/R Model for the Multidimensional Paradigm (1998) [11] Tryfona, Nectaria, Busborg, Frank, Christiansen, Jens G. Borch: starER: A Con-

ceptual Model for Data Warehouse Design (1999) [12] Haisten, Michael: The Real-Time Data Warehouse: The Next Stage in Data Wa-

rehouse 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

Önálló laboratórium beszámoló BME TTT

Recommend Documents