=+ @?+AB;-DC+EQ FE6LHG I+J+6 K+GHL4O 7?+ @=+<
'( 0+4@ +EAB?+ @M+3D0@ +4+6HLC
Kérdezhetnénk, hogy ha ennyi el nye van ennek a technikának, miért nem transzformáljuk minden relációs adatbázisunkat multidimenzióssá? Ennek az az oka, hogy vannak olyan relációs adatbázisok, melyeket szerkezetüknél fogva nem éri meg átalakítani, mert a teljesítmény ezzel romlik. Nézzük példának az alábbi relációs táblát:
SZEMÉLYI ADATOK VEZETÉKNÉV SMITH REGAN FOX WELD KELLY LINK KRANZ LUCUS WEISS
SORSZÁM 01 12 31 14 54 03 41 33 23
KOR 21 19 63 31 27 56 45 41 19
Megtehetnénk, hogy ebb l a 9 rekordból csinálunk egy többdimenziós tömböt, ahol a VEZETÉKNÉV és a SORSZÁM a két dimenzió. A KOR szerepelne a cellákban értékként. Megfigyelhetjük, hogy a VEZETÉKNÉV és SORSZÁM oszlopoknak nagy a szórása, nincsenek jellemz értékek. Ezért mindkét dimenzióban 9 elem lesz, és ennek következtében lesz egy 9×9-es, 81 elem tömbünk, melynek csak 9 cellájábn lesz KOR érték! Hasonlítsuk össze ezt az adatstruktúrát els példánkkal:
ELADOTT MENNYISÉG – GLEASON KERESKEDÉS MODELL
SZÍN
ELADOTT MENNYISÉG
MIKROBUSZ MIKROBUSZ MIKROBUSZ SPORT KUPÉ SPORT KUPÉ SPORT KUPÉ SEDAN SEDAN SEDAN
KÉK PIROS FEHÉR KÉK PIROS FEHÉR KÉK PIROS FEHÉR
6 5 4 3 5 5 4 3 2
!#"$ % &
''
Els példánkban szintén 9 rekord volt, de itt csak 3 lehetséges érték volt dimenziónként. Ezért itt egy 3×3-mas tömbünk van 9 cellával, mindegyikben egy elemmel. Az ábrán még szembet n bb a különbség:
M O D E L L
6
5
4
MIKRO BUSZ
3
5
5
KUPÉ
4
3
2
SEDAN
21 19 V E Z E T É K N É V
63 31 27
KÉK
PIROS
SZÍN
FEHÉR
56
SMITH REGAN FOX WELD KELLY LINK KRANZ LUCAS WEISS
45 41 19
31
41
23
01
14
54
03
12
33
SORSZÁM
A személyi adatokat tartalmazó adatbázisunk nem “eredend en” többdimenziós, mert a különböz rekordok adatai közt nincs természetes összefüggés. Mint láthatjuk, ennek eredménye egy meglehet sen hiányosan kitöltött 9×9-es tömb. A 3×3-mas tömbünkre nézve ellenben látszik, hogy minden MODELL-SZÍN kombinációhoz tartozik egy érték, ez tehát egy teljesen kitöltött tömb. Ilyen esetekben tehát hatékonysági megfontolásokból nem célszer többdimenziós struktúrára áttérni. Ha keresünk egy adatot, akkor itt 9 rekordot kell megnéznünk relációs táblánkban szemben a 9×9-es tömb 81 cellájával. Konklúzió: teljesítményünk tehát csökken, ha multidimenziós adatokat relációs táblákban tárolunk, illetve ha nemmultidimenziós adatokat töbdimenziós tömbökbe rendezünk. Ha eltekintünk a teljesítménybeli romlástól akkor sem célszer nem-multidimenziós adatokat multidimenziós adatbázisban tárolni, hiszen ezeket épp arra találták ki, hogy olyan adatok analízisét és manipulációját könnyítsék meg, melyek összefüggenek egymással. Konkrétumokra térve nem valószín , hogy egy felhasználó a személyi adatokat nagyon analizálni akarná. (összeadni az életkorokat, vagy esetleg megnézni,hogy a növekv SORSZÁM függvényében hogy változik a KOR eloszlása nem túl értelmes foglalatosság). Tekintve, hogy ebben az adatbázisban maguk az adatelemek hordozzák a f információt, és nem a köztük lev összefüggések, így ilyen esetben maradjunk a relációs sémáknál, ugyanis ezeket ilyen adatokra találták ki.
!#"$ % &
'R
Az eladási adatokat tartalmazó adatbázisban viszont sok értelmes összefüggés van. A felhasználója valószín leg gyakran fogja összehasonlítani két modell eladási adatait, adott színb l mennyit adtak el, vagy mennyit adtak el adott színb l és modellb l egy adott id periódusban. Az adatok közti összefüggések és összehasonlítások itt sokkal nagyobb jelent séggel bírnak, mint az adatok maguk. Az ilyen adatokat tehát érdemes multidimenziós tömbökbe szervezni. Ebb l lesz rhetünk egy fontos következtetést arra vonatokozólag, hogy egy üzleti vállalkozás számára a saját adatai milyen értékkel bírnak: Minél több eredend összefüggés van egy adathalmaz elemei közt, annál valószín bb, hogy az ezek közti kapcsolatok felderítése értékes üzleti információ lesz a vállalat számára. Általában minden cég er forrásai –ideértve az id t is – korlátozott számban állnak rendelkezésre adatanalízisre. Ezért kulcskérdés, hogy az ilyen, összefüggésekkel teli adathalmazokat multidimenzionális adatbázisokban tároljuk javítva ezzel a hozzáférést és az analízist.
S S
Tl VUXWZYN[@ +\D[+ @][+^O 7_P`+\] aDb+ @aD_P[+c+dkBaD-e+c+f@ +\DaD-gQh+b@ +hm i]j@ +f+dBkaDge+^@ +e+c TD-n+TV lo+e+ @pq+hi]f+g
Mint láttuk az el bbiekben, a multidimenziós adatbázisban az adatok elrendezése bizonyos “beépített” el nyöket foglal magában. A relációs tábláktól eltér en, egy tömbre ránézve azonnal láthatók a dimenziók, az elemek a dimenziók mentén, a metszetek, és a cellaelemek. A végfelhasználók általában nem kíváncsiak a konkrét táblákra, és nem a rekordokat böngészik, hanem egy összefoglaló kis táblában szeretik látni az adatokból kinyert összesített (aggregated) információkat. Vegyük példának ismét az autókereskedést. A nézetünk: ELADOTT MENNYISÉG MODELL/SZÍN alapján. Az adatok közvetlenül, ránézéssel megkaphatók. Ha relációs környezetben szeretnénk az adatok közt ugyanilyen módon böngészni, akkor bonyolult lekérdezésekre van szükség. Ha esetleg úgy döntünk, hogy hasznosabb lenne az adatokat SZÍN/MODELL nézetben vizsgálni, akkor elég csak az el bbi nézetünket “elforgatni”, míg relációs adatbázis esetén egy új, nem kevésbé komplex lekérdezést kell megírnunk. A nézetet tehát elforgatjuk 90 fokkal az óramutató járásával megegyez irányba, az adatok átrendezése nélkül! A könnyedség és gyorsaság, ahogy a forgatás megoldható multidimenziós környezetben, ismét csak azt bizonyítja, mennyire hasznos adatainkat így tárolni. Alább látható, hogy is néz ki egy forgatás többdimenziós módra:
rstu
vw x yz{|}~ |
y
#|y
O
90
6
5
4
MIKRO BUSZ
3
5
5
KUPÉ
4
3
2
SEDAN
KÉK
PIROS
M O D E L L
FEHÉR
6
3
4
KÉK
5
5
3
PIROS
4
5
2
FEHÉR
KUPÉ
MIKRO BUSZ
SZÍN
S Z Í N
SEDAN
MODELL
A fenti kétdimenziós tömbnek két lehetséges nézete van: MODELL×SZÍN és SZÍN×MODELL. Mindkét esetben a két dimenzió metszetében (cellában) az ELADOTT MENNYISÉG számai találhatók. El z példánkban 3 dimenzió szerepel: MODELL, SZÍN, KERESKEDÉS. Ennek a kockának 6 lehetséges nézete van: 1. 2. 3. 4. 5. 6.
MODELL×SZÍN (háttérben a KERESKEDÉS dimenzióval) SZÍN×MODELL (háttérben a KERESKEDÉS dimenzióval) SZÍN× KERESKEDÉS(háttérben a MODELL dimenzióval) KERESKEDÉS×SZÍN (háttérben a MODELL dimenzióval) KERESKEDÉS×MODELL (háttérben a SZÍN dimenzióval) MODELL×KERESKEDÉS (háttérben a SZÍN dimenzióval)
C G Cl
S KM
SZÍN
M K S
SZÍN
C G Cl
C G Cl
K P MK S
S
KERESKEDÉS
F
SZÍN MODELL
M K
KERESKEDÉS
KERESKEDÉS
KERESKEDÉS
C G Cl
K P F
Cl
MODELL
KERESKEDÉS
F P K
C G
MODELL
MODELL
K P F
K P F
SZÍN
M K S
SZÍN
MODELL
A következ ábra azt mutatja, hogy kaphatók meg ezek a nézetek többdimenziós (90 fokos) forgatások segítségével.
M K S
K P Cl G C
F
KERESKEDÉS SZÍN
SZÍN
rstu
vw x yz{|}~ |
y
#|y
[Rövidítések: MODELL – S: SEDAN, K: KUPÉ, M: MIKROBUSZ; SZÍN – K: KÉK, P: PIROS, F: FEHÉR; KERESKEDÉS – Cl: CLYDE, G: GLEASON, C: CARR] Az a lehet ség, hogy a különféle nézetek ilyen egyszer en megkaphatók, különösen fontos a sokféle üzleti beállítottságú felhasználónak, hiszen mindegyikük más kérdéseket tesz fel az adatbázisnak, különböz szempontok szerint. A fenti 6 nézet bármelyike könnyen megkapható egyszer forgatással. Mivel a multidimenziós adatbázis úgy tárolja az adatokat, hogy a forgatás egyszer legyen, így nincs szükség az adatok átrendezésére. A forgatást felfoghatjuk “szeletelésként” is, hiszen minden egyes forgatással egy “szeletet”, két dimenziós tömböt kapunk. Láttuk már, hogy a dimenziók számának növelésével a lehetséges nézetek (szeletek) száma exponenciálisan növekszik. Így a kétdimenziós tömbnek 2, a háromdimenziósnak 6, míg egy négydimenziósnak 24 nézete van, és bármelyik nézethez ugyanolyan könnyen és gyorsan hozzáférhetünk.
S S T TV ldBW+ @^+D] migQUX+ @p[+] [+dBk+g Egy jól implementált többdimenziós adtbázisban könny megvalósítani egy tömb átméretezését, redukálását. Tekintsük az el z háromdimenziós példánkat, melyben minden dimenzió mentén 10 elem található. Tegyük fel, hogy kíváncsiak vagyunk, hogy az új METÁLKÉK szín kocsik eladási statisztikája mit mutat a KÉK autókéval szemben. Tegyük fel, hogy az új színt csak a SPORT KUPÉ és a MIKROBUSZ típusokra használtuk, és hogy ezek csak a CARR és a CLYDE kereskedésekben kaphatók. A sz kítés nev m velettel választhatjuk ki a dimenziók szükséges elemeit: • • •
A MODELL dimenzióból SPORT KUPÉ és MIKROBUSZ A KERESKED K dimenzióból CARR és CLYDE A SZÍN dimenzióból pedig METÁLKÉK és KÉK
Ezt a következ képpen ábrázolhatjuk:
rstu
vw x yz{|}~ |
y
#|y
MIKROBUSZ
M O D E L L
KUPÉ CLYDE CARR NORMÁL METÁL KÉK KÉK CLYDE CARR NORMÁL KÉK
METÁL KÉK
KERESKED
SZÍN
A redukált tömböt ugyanúgy forgathatjuk és felhasználhatjuk számításaink során, mint el djét. A méretezés analógiája a relációs adatbázisban egy bonyolult lekérdezés. A méretezést úgy is felfoghatjuk, mint “adatszeletelést”, hiszen az adatoknak egy részhalmazát nézzük, melyet egyfajta felszabdalással nyerünk. Nem meglep módon a méretez m veletek sokkal gyorsabbak, mint a megfelel relációs adatbázisbeli lekérdezések. Az ok ismét az, hogy kevés er forrásigényes keresést kell végrehajtanunk, hogy a kívánt nézet el álljon.
S
TD-+TV laD[+ @ph+p mi+a-D^+`+ @gQ^+h@ +++ @ge+\-Dh+] e+^
Mint azt már említettük, a felhasználóknak az adatok különböz nézeteire van szükségük. (pl. ELADOTT MENNYISÉG KERESKEDÉS vagy éppen MODELL szerint). Gyakran ezek a nézetek nagyon hasonlóak (pl. ELADOTT MENNYISÉG KERESKEDÉS vagy KERÜLET szerint). Utóbbi nézetben a KERESKEDÉS és a KERÜLET hierarchikus viszonyban vannak egymással: egy kerületben több kereskedés is lehet. A kerületben eladott mennyiség a keresked k eladott mennyiségeinek összege. Kíváncsiak lehetünk például az eladási adatokra egy kerületben. Ha az adatok nem kielégít ek, akkor lejjebb megyünk a hierarchiában egy szinttel, hogy megnézzük, melyik kereskedés nem éri el a limitet, így finomítva a keresést, elemzést. A többdimenziós adatbázisok tervezése során mindig messzemen en figyelembe vesszük a természetes kapcsolatokat. Bár lehetséges volna két különálló tömböt létrehoznunk mind a KERESKEDÉS, mind a KERÜLET számára, elegánsabb és
rstu
vw x yz{|}~ |
y
#|y
hatékonyabb, ha két összefügg aggregátumot definiálunk ugyanabban a dimenzióban. Az egyik a KERESKEDÉS, a másik a KERÜLET lesz. A KERÜLET feletti egység a RÉGIÓ, mely mindkett t magába foglalja:
SZERVEZETI DIMENZIÓ
MIDWEST
RÉGIÓ
KERÜLET
KERESKEDÉS
CHICAGO
CLYDE
ST.LOUIS
GLEASON
CARR
GARY
LEVI
Relációs adatbázisban ezt úgy tudnánk megoldani, hogy a hierarchia minden szintjének definiálunk egy mez t, vagy külön táblát hozunk létre, amelyben leírjuk a kapcsolódásokat. Ez nem túl elegáns és nem is hatékony. A hierarchia szintjei mentén történ felfele/lefele irányuló mozgásra ezután mint “roll-up”, illetve “drill-down” hivatkozunk. SZÍN
M O D E L L
RÉGIÓ KERÜLET KERESKEDÉS
rstu
vw x yz{|}~ |
y
#|y
Minden nézetet, melyet a kiválasztott hierarchiaszintek jelölnek ki a dimenziók mentén, ugyanúgy forgathatjuk és méretezhetjük, ahogy azt korábban láttuk. Ha ezeket a m veleteket szeretnénk végrehajtani relációs adatbázisban, akkor a lekérdezést minden nézet esetén újra le kell futtatnunk. Az el nyök ismét a teljesítményben mutatkoznak meg f ként.
S
TD-+TV lUX`+\D-]aDb@ +a_P[+c+d a¡+ @gQ\D[@ +^++ @pb@ +[+dBk+g[+^
Mivel a többdimenziós adatbázisok magas szinten szervezettek, ezért a hozzájuk tartozó lekérdez nyelv könny és hatékony. Nem csak a lekérdez nyelv áttekinthet és egyszer azonban, hanem a lekérdezés eredménye is. Vegyük példának az autó eladási adabázisunkat 3 dimenzióval és bennük 3 elemmel. Ha meg szeretnénk jeleníteni az ELADOTT MENNYISÉG-et a MODELL alapján rendezve minden KERESKEDÉS-re, akkor a következ egyszer parancsot használhatjuk: PRINT TOTAL(ELADOTT_MENNYISEG KEEP MODELL KERESKEDES) Ezt a parancsot persze a magasabb szint grafikus felület adatbázis kezel k egy kattintásra végrehajtják. Mindkét esetben az eredmény valami hasonló lesz:
MODELL MIKROBUSZ SPORT KUPÉ SEDAN
CLYDE 7 4 3
GLEASON 5 6 8
CARR 6 8 12
A kimenet formailag megfelel a módnak, ahogy az adatainkat a tömbben tároljuk. Ez alapján már könny összehasonlításokat tenni és tendenciákat felfedezni. Most nézzük, milyen lenne egy relációs SQL lekérdezés, ha ugyanazt a választ szeretnénk megkapni: SELECT MODELL, KERESKEDES, SUM(ELADOTT_MENNYISEG) FROM ELADOTT_MENNYISEG GROUP BY MODELL, KERESKEDES ORDER BY MODELL, KERESKEDES Látható, hogy a lekérdezés komplexebb, és az eredmény sem felel meg az elvárásainknak:
rstu
vw x yz{|}~ |
y
#|y
MODELL MIKROBUSZ MIKROBUSZ MIKROBUSZ SPORT KUPÉ SPORT KUPÉ SPORT KUPÉ SEDAN SEDAN SEDAN
KERESKEDÉS CLYDE GLEASON CARR CLYDE GLEASON CARR CLYDE GLEASON CARR
¢ SUM(ELADOTT_MENNYISÉG) 7 5 6 4 6 8 3 8 12
Ez is ugyanaz az eredmény, de formailag nem olyan áttekinthet , mint az el z , a tendenciákat sem lehet kiolvasni bel le egykönnyen.
S
TD-£+TV l¤\DaD-[+c+gk¥D¦dBk[+pYN[@ +p© §h+pLH+ @+aD] [+ @^+]LH¨+ @ph
A jól implementált multidimenziós adatbázisok nagy el nye, hogy ugyanazokhoz az adatokhoz egyid ben több felhasználó is hozzáférhet. Mindenki definiálhatja a neki legmegfelel bb nézetet ugyanazon adatstruktúráról, forgathatja, méretezheti anélkül, hogy a többi felhasználó adatnézeteit zavarná. Mindemellett az adatbázis teljesítménye sem romlik a felhasználók szempontjából. A többdimenziós adatbázisoknak ugyanakkor nyitottnak kell lenniük, többszörös front-end eszközt biztosítva az alkalmazásfejlesztés számára, valamint a böngészést és az adatanalízist is támogatniuk kell. Végül, kliens/szerver módon kell m ködniük, támogatva az adatok megosztását és feldolgozását a kliens és a szervergépek közt.
S
TD-ª+TV lUX`+\D-]aDb@ +a_P[+c+d a¡+ @gQgi mdBkf+_PD]Lf+ge+^
Mint már említettük, az adatok tömbszer tárolásából fakadó magasszint szervezettség nagyban segíti az adatanalízist. Például a kétdimenziós példánkban, a SZÍN=KÉK feltételeknek megfelel ELADOTT MENNYISÉG adatok egy sorban szerepelnek. Ez a beépített szervezettség könny vé és gyorssá teszi az aritmetikai m veleteket az adatokon. Példának okáért az összes eladott kék autó számának meghatározásakor csak egy oszlop számait kell összeadnunk. Relációs rendszerben az összes rekordon végig kell menni, kigy jtve a feltételnek megfelel mennyiségi adatokat, majd összeadni ket. A használt matematikai m veletek ennél gyakran sokkal összetettebbek, a multidimenziós adatbázisok azonban szerkezetüknél fogva ezekkel is elboldogulnak. Az ilyen alkalmazásokban általában implementálva van egy “üzleti mértékek” dimenzió. Ebben a dimenzióban találunk olyan elemeket, mint: eladott mennyiség, tervezett költségvetés, profit, bevétel, stb. Helyezzük el ezt az “üzleti” dimenziót a mi háromdimenziós modellünk környezetébe, ahol az els két dimenzió a MODELL és a
rstu
vw x yz{|}~ |
y
#|y
«
SZÍN. Ebben a példában az ÜZLETI MÉRTÉKEGYSÉG minden pozíciója egy síkja (vagy két dimenziós szelete) az üzleti mértékegységek adatainak. Ilyen adatokat analizálva felmerül az igény az adatok összegezésére a sorok/oszlopok mentén. Legvalószín bb, hogy az ilyen jelleg aritmetikai m veleteket az üzleti mértékek szeletei mentén kezdeményezzük. Például kíváncsiak lehetünk a KÖLTSÉGVETÉS és AKTUÁLIS mez k különbségére. Többdimenziós tömbünkben ez a m velet elegánsan elvégezhet : az AKTUÁLIS tömböt elosztjuk a KÖLTSÉGVETÉS tömbbel. Multidimenziós adatbázisban ez a m velet nagyon hatékonyan hajtható végre, tekintve hogy a tömbök, ez esetben az AKTUÁLIS és a KÖLTSÉGVETÉS, önálló cellákként kezelhet k, így a matematikai operációk még extrém méret tömbökön is gyorsak. Ez még változó méret és alakú tömbök esetén is igaz. Például néhány autó csak valamely keresked nél kerül forgalomba. Ez esetben a KÖLTSÉGVETÉS és AKTUÁLIS tömbök kissé eltér en fognak kinézni MODELLenként. A hatékony többdimenziós adatbázisokban két tömb konformmá tehet az üres cellák kihagyásával. Relációs környezetben az olyan m veletek, mint pl. két tábla megfelel adatainak elosztása (AKTUÁLIS és KÖLTSÉGVETÉS) roppant mód er forrásigényes, mert két nagy táblát kell összekapcsolnunk. Nagy adatmennyiség esetén ez órákat, vagy akár napokat is igénybe vehet!
11 10 .1 16 12 .33 8 10 -.2 16 16 0
AKTUÁLIS
KÖLTSÉG VETÉS
ELTÉRÉS
Konklúzióként leszögezhetjük, hogy egy jól implementált multidimenzionális adatbázis, mindamellett, hogy sokkal hatékonyabb adathozzáférést biztosít, az adatbázis struktúrából adódóan mintegy integrálja az adatmanipulációhoz szükséges számítási eszközöket. Ez a fajta integráció nagyon ritka a relációs adabáziskezel rendszerekben.
S
TD-¬+T¯i° 1d± aD-b+®O 7b+a_P[+c@ +d a¡
A leggyakrabban felmerül üzleti kérdésekben általában nagy szerepe van az id nek, hiszen minden üzleti adat – keletkezésénél fogva – id höz köthet . A relációs rendszerekben nincs ehhez segítség, multidimenziós adatbázisokban viszont az ID
rstu
vw x yz{|}~ |
y
#|y
²³
dimenziója el re definiált, és rögzített a struktúrája is (nap, hét, hónap, negyedév, félév, év és egyéb speciális periódusok, mint holdhónap, vagy fiskális év). Ennek két el nye is van. El ször: ha felállítunk egy új adatbázist, nem kell minden alkalommal ezt az összetett hierarchikus struktúrát megvalósítanunk. Másodszor: mivel az id dimenzió a multidimenziós adatbázis engine-jében kódolva van, ezért az id vel kapcsolatos lekérdezések (amik egyébként talán a leggyakoribbak közé tartoznak) nagyon gyorsak lesznek.
S
TD-´+TV lµ¶º ·a-D]^+ @hi m¸» ¹h@ +b+h+ @]LHe+^7 O^+[@ +dB[+ @\D@ +g[7 Oh@ +c+b+ @\DaDc@ +q7 Og+h+pLgi m[> P@ +`+j+ @[+g
Egyik megel z példánkban láthattuk, hogy el fordulhatnak olyan tömbök is az adatbázis építése során, melyben nagyon kevés és szétszórt adat található. Másik extrém példa a teljesen kitöltött tömb, mikor minden cella tartalmaz értéket. A gyakorlatban általában a két széls ség közti, viszonylag egyenletesen kitöltött tömbök fordulnak el . Az üres helyek kitöltésére egy speciális NA érték kerül. Sajnos egy ilyen cella ugyanannyi tárolási és számítási er forrást igényel, mint az olyan, amelyikben értékes adat van. El fordulhat, hogy bizonyos tömbökben nagyon sok NA érték lesz. Ilyen szituáció el állhat pl. akkor, ha – autós példánknál maradva – valamelyik keresked egy id re bezár, ekkor a napi eladási adatok helyére NA kerül. Jól implementált többdimenziós adatbázisokban külön funkció szolgál az NA értékek kiküszöbölésére: megkeresi az összefügg , csupa NA érték blokkokat, és azokat elzárja a lekérdezések el l, ezzel is növelve a teljesítményt és csökkentve a szükséges tárhelyet.
+Tl V¼¿ 1ggdBk[Z½¾e+q+ @\Dh+\f+g A multidimenzinális adatbázisokról szóló rövid ismertet nk végéhez értünk. Az eddig megszerzett alaptudás birtokában most vizsgáljunk meg egy konkrét adatbáziskezel alkalmazást, a Microsoft OLAP Services-t, mely a Microsoft SQL Server 7.0 programcsomagon belül található meg. A fentiekhez képest el fordulnak kisebb különbségek, melyek a termék specifikus voltából adódnak.
rstu
vw x yz{|}~ |
y
#|y
²
mTZdÁÀ©ÂÃÅÄ7hi\hmÃÆÇhia Az alapvet OLAP struktúrák, amikr l szó lesz, a következ k: dimenziók, mért adatok (tényadatok), hierarchiák, szintek, kockák, cellák, formulák. Ezek együtt alkotják egy OLAP adatbázis logikai felépítését, és azokat a számításokat, amit támogatnak. A mért adatok azok az adatok, amiket analizálni, elemezni szeretnénk, míg a dimenziók definiálják a mért adatok felépítését. Például, ha az adatbázisunk tartalmazza egy cip polt eladási adatait (Sales), a területi adatokat (Location), az id t (Time), és a termékek leírását (Product), akkor ez esetben a tényadatnak az eladási adatok felelnek meg, a dimenziókat pedig a többi adat alkotja. Sorra a Location, Time és a Product. Látható, hogy az elemzend adat a cip bolt eladási adata, és a dimenziók határozzák meg, milyen szervez dés szerint tudom folytatni a vizsgálatomat. Nézhetem a mért adatokat, például id és termék vonatkozásában. A dimenziók elemeit tagoknak, elemeknek nevezzük, és általában valamilyen szervez dést mutatnak. Ezek a szervez dések a hierarchiák, amik mentén különféle összegzéseket, aggregációkat számíthatunk. A hierarchiák szintekre bonthatók. Leggtöbbször egy szintbe tartoznak azon tagjai egy dimenziónak, amik valamilyen közös tulajdonsággal rendelkeznek. Pl.: A terület (Location) dimenzió hierarchikusan épül fel az alábbi szintekb l: ország, megye, város. A szintekhez tartozó dimenzió elemek: Magyarország, Anglia, Dánia - Vas, Hajdú, Szabolcs-Szatmár-Bereg, Komárom-Esztergom - Nyíregyháza, Debrecen. A kockát dimenziók és tényadatok halmaza közötti kapcsolat írja le. A dimenziók elemeinek kombinációi definiálják azt a logikai teret, ahol a tényadatok értékei el fordulhatnak. Minden egyedi metszetet, amit minden dimenzió egy-egy eleme hoz létre, cellának nevezünk. Pl. egy cella az alábbi dimenzióelemek metszete: Tiszavasvári, Al Bundy Cip bolt, 1999. május, Nike Air Max 2 cip (by Location by Time by Product).
mTnmTÈbia_Q[mcidÉa¡i^±½H[m\im]HigZ[ Minden MS OLAP Services (MOS) dimenzió egy vagy több szintb l áll, és minden szintnek egy vagy több tagja van. Ha a dimenziónak egynél több szintje van, akkor az elemek hierarchiákba szervezhet ek. A hierarchia fastruktúrájú, azaz minden levél szinten lév elemnek pontosan egy szül je van, nincs gyermeke; a legfels szinten lév elemeknek nincs szül je, de egynél több gyermekük is lehet; a közbüls szinten lév elemeknek de egynél több gyermekük is lehet, és pontosan egy szül jük van.
rstu
vw x yz{|}~ |
y
#|y
²²
Az MOS az egyszer dimenziófelépítés mellet támogatja a többszörös dimenzió hierarchiákat is (multiple dimensional hierarchies). Többszörös hierarchiára példa az id dimenzió, ahol az adatainkat mind szokásos, mind költségvetési év alapján tudjuk elemezni. Vagyis egyazon dimenziónak különböz hierarchiái lehetnek, amik különböz , vagy közös szintekb l építkeznek.
Time
Time Fiscal Year
Calendar Year
Fiscal Year
Year 52
Quarter
Quarter 13
Month
Week
Calendar Year Quarter
Year 52
Quarter 13 Week
Month Day
Day
Az OLAP Services esetében van egy számottév különbség a többszörös dimenzió hierarchiáknál, attól függ en, hogy a kliens, vagy az adatbázis adminisztrátor (DBA) szemszögéb l nézzük azokat. Míg a kliens fel l vizsgálva a többszörös dimenzió hierarchiák egy dimenzió több hierarchiájának t nnek (teljesen transzparens), addig a DBA ezt különböz dimenzióknak látja (ahogyan a MOS kezeli). Ebb l is következik, hogy nem szükséges, hogy az eltér hierarchiáknak azonos dimenzióelemeik legyenek. Elképzelhet a következ többszörös dimenzió hierarchia ezekkel a szintekkel: üzlet (Store), város (City), állam (State), ország (Country), és hónap (Month), negyedév (Quarter), év (Year). Természetesen az ilyen jelentésbeli kéveredés kerülend , a MOS semmilyen szemantikai vizsgálatot nem végez ezzel kapcsolatban.
Time Fiscal Year
Time.Fiscal
Calendar Year
Year 52 Quarter 13
Quarter
Time.Calendar
Time.ByWeek
Fiscal Year
Calendar Year
Quarter
Quarter
Year 52 Quarter 13
Month
Month
Week
Week Month Day Day Client View
Day
Day
DBA View
S mT T Èbia_Q[mcidÉa¡i^Q]LhmqÃÆÇhia A dimenziók tagjai egyedileg azonosítható elemek a dimenzión belül. Minden tagnak szöveges neve van, bár ezek a nevek származhatnak számokból, dátumokból is. A tagok az egyedi azonosíthatóság miatt rendelkeznek kulcsokkal (tagkulcsokkal). Ez megegyezhet adott esetben a tag nevével is. Egy tag azonosítása úgy történik, hogy egymás után f zzük a tag kulcsának az értékét, majd a tag szül je kulcsának az értékét, egészen a legfels gyökér szintig. A fastruktúrából adódóan minden
rstu
vw x yz{|}~ |
y
#|y
²
dimenzióelemet egy kulcsérték sorozat azonosít, és egy kulcsérték sorozat egy elemet azonosít (aminek lehetnek még gyermekei).
Gyökér
Közepe
Levél
1
2
3 4
5
6 7
8
9 10
mTmT§Ê#a_Q[mcidÉa¡i[m\[i_Q[m^ËÆÇ[i\\Ì[+_QdÉ®maÍ·]H`i\h ÆbmeicigÎfiqmhia©ÏU [i_Qji[mp¹ÄVpHeim[ipÑÐ ]Ha[mgZÍZÅ]Ñ]LpHaji`m]L[mgZ A dimenziók elemeihez tartozó jellemz k olyan többletinformációk az elemr l, amik egyetlen dimenzió szerint rendez dnek. Egy megadott jellemz a dimenzió szintjének minden elemére vonatkozik. Ezen jellemz ket a MOS sztringként kezeli, de számos más típuson alapulhatnak, és nem ad számbeli korlátozást a definiálható dimenzióelem jellemz k számára. Az elemtulajdonságok adják az alapját a virtuális dimenzióknak, amik szintén hagyományos dimenzióként használhatók kockák építésénél. Ha egy kocka használja ezt a virtuális dimenziót, akkor a jellemz elérhet ezen kockán belül, mint dimenzióelem jellemz . Példaként, ha a Termék dimenziót vesszük alapul, a Termék Szín lehet egy dimenzióelem jellemz (a termék egy cip , és ennek a színe egy termék tulajdonság, ami lehet pl. kék). Felhasználva ezt, létrehozhatok egy Termék Szín virtuális dimenziót (elemei a rendelkezésre álló színek). A kocka, ami mindkét dimenziót használja, rendszerezheti az adatait mind a Termék hagyományos, mind a Termék Szín virtuális dimenzió szerint, akár egyszerre is (pl. kérem megadni az eladási adatokat fekete szín férfi b rcip kre).
mTmT@Ê#a_F[mcida¡i]Hm`igÎei^ A dimenziókat több szempont szerint rendszerezhetjük. Lehetnek megosztottak, vagy privátok, hagyományos vagy virtuális dimenziók. A típusokat nem nézve, a dimenziók közt nincs különbség a lekérdezéseknél, és bármelyikük használható hagyományos, vagy virtuális kockák építéséhez. Azon alkalmazások is egységesen
rstu
vw x yz{|}~ |
y
#|y
²
kezelik ket, amik a Microsoft OLAP Services-zel ‘OLE DB for OLAP’, vagy ‘ADO for MD’ felületen keresztül kommunikálnak. A megosztott dimenziók több kocka építéséhez is felhasználhatóak. Például az Id (Time) dimenzió megosztható az eladási, termelési, és készlet adatokat tartalmazó kockák között. Természetesen egy megosztott dimenziót nem feltétlenül kell több kockának használnia, elképzelhet , hogy egy kocka sem használja. Midemellett a megosztott dimenzió adatainak frissítése különválasztható az t tartalmazó kockák frissítési folyamatától. A privát dimenzió jellemz je, hogy egy, és csakis egy kockán belül definiált, és használt. Az adatbázis többi része számára viszont teljesen látható, a kliensek lekérdezéseket eszközölhetnek, használva a privát dimenziót, és dimenziója lehet olyan virtuális kockának, ami magában foglalja azt a kockát, aminek dimenziója ez a privát dimenzió. Frissítés szempontjából a privát dimenzió információi teljesen újraépülnek, ha az t tartalmazó kocka újraépül. Hagyományos dimenziók szintjeinek száma maximálisan 64 lehet. Egy kocka használhatja az összes szintjét a dimenziónak, de lehet ség van a szintek egy halmazának a használatára is. A hagyományos dimenziók elemeinek lehetnek tulajdonságaik (member properties), és a különböz szinteknek megfelel en a MOS aggregátumokat számol és tárol el re, hogy jobb válaszid t produkáljon, nagyobb tárigényért cserébe. Megkötés, hogy egy tagnak maximum 64000 közvetlen gyermeke lehet. A virtuális dimenzió egy hagyományos dimenzió adott szintjén elhelyezked elemek tulajdonságából (member property) épül fel. Ld. a példát a dimenzióelemek tulajdonságainál. Megkötés, hogy a virtuális dimenziónak 760 eleme lehet.
mT£mTÅdÁabm®Qbia_Q[mcidBa¡ A legtöbb multidimenzionális adatbázis esetében megtalálható a dimenziók között az id . A MOS külön támogatást biztosít arra, hogy egy dimenziót id dimenzióként kezelhessük. Az id típusú dimenzió több MDX funkció alapja lehet. Az MDX a Multidimensional Expression rövidítése, amit az OLAP Servicesben számítások és lekérdezések megfogalmazására használunk. Az ilyen dimenzió szintjei általában az Év, Félév, Negyedév, Hónap, Hét, Nap, Óra, Perc, Másodperc (Years, HalfYears, Quarters, Months, Weeks, Days, Hours, Minutes, Seconds). Sok olyan MDX funkció van, ami ezeket a szinteket, mint alapértelmezett szinteket használja. Sajnos a MOS nem figyeli azt, hogy milyen valójában az a dimenzió, amit id típusúnak definiáltunk. Megtehet tehát, hogy id típusúnak adunk meg nem id tartalmú dimenziót, ill. nem kezeljük id nek az id tartalommal bíró dimenziókat.
mTªmT@¤©eim^ifm^FmgX_QipL]Òhibmh@]Ñem^FÓ]Lic Ô+hmbihm]Lei^m
rstu
vw x yz{|}~ |
y
#|y
²
A Microsoft OLAP Servicesben a kocka tényadatok gy jteménye, amiket dimenziók egy halmaza rendszerez. Minden számítás a MOS-ban kockákon alapszik. Mivel a tényadatok a kockában vannak, az aggregátumok is ott helyezkednek el, és minden számítás, ami akár a tényadatokat, akár egy dimenzió elemeit érinti, szintén a kockában található. Ugyanígy az MDX lekérdezések is kockákra vonatkoznak. Az alap tényadatok definiáltan csak számszer ek lehetnek, de ezen belül több numerikus típusból válogathatunk (integer, float, stb.). A dátum is használható tényadatok esetén, ugyanis a dátum a bels ábrázolásban ugyancsak numerikus. Az alap tényadatok, mellett léteznek még számított tényadatok. Míg az el z egy olyan adat, amit egy adatbázis táblából nyerünk ki, addig az utóbbi különféle formulák segítségével kapható meg az el bbib l. Fontos megjegyezni, hogy ha a mért adatokat úgy tekintjük, mint egy dimenzió elemeit (mért adat dimenzió), akkor ez a dimenzió különbözik a többit l abban, hogy nem mutat hierarchikus felépítést. Ez annak tudható be, hogy csak egy szintje van, az amelyiken az összes eleme (tényadat) elhelyezkedik.
mT¬mTÅbmhi]Ljm[ÃYÕa]H[i\+fi\]Ñhi\fmciemgÖ^meim^ifi^Q[+gÎ[i]Ñijm[ic Az alap tényadatok, amiket egy kockába töltünk be egy bizonyos dimenzió szinten, automatikusan elérhet ek az adott szint feletti szinteken, mint összegzett (aggregált) adatok. Mindegyik alap tényadat a ténytábla egy oszlopából származik. (A ténytábla az a tábla, ahol a tényadatokat tároljuk, pl. egy RDBMS-ben). Az adatokat a dimenziók szintjeinek többféle kombinációjában tölthetjük be a kockába. Ez azt jelenti, hogy mindegyik dimenzióból kiválasztok egy szintet, és ezekre a szintekre töltöm be az adatot. Például nézzük a következ dimenziókat, és szintjeiket: Üzlet (Város, Üzlet, Pénztárgép), Termék (Osztály, Kategória, Egyedi Termék), Id (Év, Hónap, Nap). Az adat több módon is beléphet a kockába: Nap, Üzlet és Egyedi Termék szintek, illetve Nap, Pénztárgép, Kategória szintek kombinációjában, és innen összegz dnek a fölöttük lév szintekre, a legfels szintig. Egy kockába azonban csak egyféle szintkombinációban tölthetjük be az alap tényadatokat. Ha a szint alatt, ahova az adat beíródott, még vannak szintek, ezeket le kell tiltani, hogy a kliensek ne tudják azt elérni a lekérdezéseiken keresztül. Ez ugyanis problémát jelentene a rendszernek, mert nem lehet megmondani, hogy pl. egy hónap szinten belép adat milyen napi szint elemekb l tev dik össze, ha err l nincs információm. Itt tehát a hónap szint alatt le kell tiltanom a szinteket az id dimenzión belül.
rstu
Time
vw x yz{|}~ |
y
#|y
Store
Product
All
All
All
Year
City
Month
Store
Category
Register
SKU
²
Time
Store
Product
All
All
Year
City
Month
Store
Category
Register
SKU
Dept.
Day
All Dept.
Day
mT´mT×ÅapL]Ñ`ifm\agX^iei+^mfi^ A virtuális kockák egy vagy több általános (hagyományos) kocka nézetének összekapcsolásából állnak. A kliens képes arra, hogy metaadatok vizsgálatával eldöntse egy kockáról, hogy az virtuális-e vagy sem, de nincs különbség kezelés szempontjából a kockák között. A virtuális kockák nem tartalmazzák a tényadatokat magukat, hanem egy lekérdezés esetén azon kockákból nyerik az adatokat, amire épülnek. A MOS 32-re korlátozza a virtuális kockában szerepl kockák számát. Ezen kockák mért adatainak (tényadatainak) egy nem üres halmazából áll a virtuális kockák mért adata. Tehát a virtuális kocka a többi kocka adatait “egyesíti”. (Ezentúl báziskockáknak nevezzük a kockákat, amik a virtuális kockát építik fel.) Mint minden más kockának, a virtuálisnak is vannak dimenziói, amik a báziskockák dimenziói közül kerülhetnek ki (azok egy részhalmaza adja a dimenzióit a virtuális kockának). A virtuális kocka dimenziója lehet virtuális dimenzió is, még akkor is, ha a báziskockák nem használják ezt a virtuális dimenziót. Viszont feltétel az, hogy a virtuális kocka tartalmazza azt a dimenziót, amelyiknek a tagtulajdonságára épül a használni kívánt virtuális dimenzió. Tegyük fel, hogy a Földrajzi elhelyezkedés dimenzió Város szintjének van egy olyan tulajdonsága, ami a város méretét adja meg (kicsi, közepes, nagy). Erre építve létrehozzuk a Városméret virtuális dimenziót. A virtuális kockánkban szerepelhet ez a dimenzió, annak ellenére, hogy a báziskockáknál ez nem így van. A virtuális kockák esetében is megtehet , hogy bizonyos szinteket adott dimenziókból letiltsunk. Alapértelmezett esetben azok a szintek, amik tiltva vannak a báziskockákban, engedélyezettek a virtuálisban. Természetesen ezek a szintek nem fognak adatokat tartalmazni, ha nem tartalmazott a báziskocka sem, de meg van a lehet ség, hogy számított elemekkel töltsük fel ezen szinteket.
rstu
vw x yz{|}~ |
y
#|y
²
£mTZØU±aipHeigÎeýH]#À·Â ÄÙN[ip¦YÕam[igXhipHima]L[m^i]H¨ipÑfÃÆÇh Az architektúra három f területe: • • •
Alapkomponens architektúra Tároló és lekérdezés feldolgozó architektúra Kliens/szerver architektúra
£mTnmTÅ\hii^mei_Qiemci[mcigXhipHima]L[m^i]ѨipHh A Microsoft OLAP Services két alapkomponense az adatbázis szerver processz, és a Microsoft PivotTable Service. Másik két komponens még a Decision Support Object (DSO) library, és az OLAP Manager adiministration interface. Szintén az alapkomponensekhez tarozik az OLAP Services metadata repository.
Client OLE DB For OLAP Pivot Table Service Decision Support Objects (DSO) OLAP Manager
OLAP Services Server Metadata
RDBMS
Az OLAP Services adatbázis szerver része egy Windows NT service-ként fut (MSSQLServerOLAPServer), és a Windows NT szabványos interfészein keresztül lehet elindítani és megállítani. Amíg az MSSQLServerOLAPServer fut, er forrásokat foglal le a szerver gépen. A PivotTable Service egy kliens interfész az OLAP services számára. Ha egy kliens kapcsolódni kíván az OLAP Services szerverhez, akkor egy OLE DB for OLAP interfészen keresztül kommunikál a PivotTable Services-zel, ami a lekérdezéseit SQL és MDX nyelven továbbítja a szerverhez. A kliens és a PivotTable Services közötti kommunikáció az alapja a metaadatok lekérdezésének is.
rstu
vw x yz{|}~ |
y
#|y
²¢
Amikor az OLAP Services szervert telepítjük, telepítésre kerül egy ActiveX library is a szerver gépre, amit DSO-nak nevezünk. Ez biztosítja azt a programozói interfészt, amivel metaadatokat hozhatunk létre és felügyelhetünk a szerveren, és sok változatos feldolgozási m veletet irányíthatunk. Az OLAP services grafikus felhasználói felülete az OLAP Manager, ami a Microsoft Management Console-ban lett megvalósítva. A szerver és ez a felület a DSO interfészt használja kommunikációra.
S £mT @ T ÚlfipHei\¡FmgX\[m^iipHbi[mdÉig°½H[m\bmei\qmeid¡FhmpLmia]H[i^m]L¨ipÑh È]LfipÑem\]#hiqmqipH[iqifm]L`m_Fem^Qhi\hmÃÆhma A MOS adattárház alapú OLAP redszerekre optimalizált. Az ilyen redszerek jellemz je, hogy sok igényt kell kielégíteniük, amik nagy méret táblákban tárolt adatok változatos szintekre vonatkozó összegzett adataira (aggregátumokra) irányulnak. Az ilyen összegzések sok memóriát és CPU id t követelnek meg a szervert l. Mivel az érintett adatok mennyisége nagy, és a hálózatok sávszélessége nem kielégít , ezért költséghatékonyság szempontjából a legjobb megoldás az, ha az aggregátumokat a szerver számolja ki, ott, ahol az adatok is vannak. A legtöbb OLAP alkalmazással szembeni elvárás az, hogy gyorsan válaszoljon a kliensek azon kéréseire is, amik aggregátumokra vonatkoznak. El re kiszámítani az összes lehetséges aggregátumot a dimenziók szintjeinek kombinációira hatalmas háttértár felhasználást eredményezne. Viszont az sem jó megoldás, hogy az aggregátumokat érint lekérdezéseknél a kérés id pontjában számítom ki az aggregátumot. Ez ugyanis megnöveli a válaszid t. Az OLAP services azt a megoldást választja, hogy bizonyos aggregátumokat kiszámol el re és letárolja. Az ilyen kéréseket gyorsan kielégíti, míg a többi maradék aggregátumot és kalkulációt a kérés fellépésekor számítja ki. Az OLAP Servicesben csak alap tényadatokból számíthatunk el re és tárolhatunk aggregátumokat. Az aggregátumok alapja az, hogy a kockában lév dimenziókból különböz mélység szinteket választunk ki, és ennek megfelel en számítunk aggregáumokat. Az alábbi ábrán egy ténytáblát láthatunk, ami a legalsó elemi szinten tárol adatokat, mégpegig a Day, Store, Product SKU szinteken. Ezekb l a tényadatokból három el re számított aggregátumot jeleztünk. Ezek : All Time – Store – Product Brand, Month – State – Product SKU, Day – City – Product Category. Az All Time és a Month a Day adatok, a Product Brand és a Product Category a Product SKU, míg a State és a City a Store adatok összegzéséb l származik.
rstu
vw x yz{|}~ |
y
#|y
All Time Store Product Brand
Fact data by: Day Store Product SKU
Month State Product SKU
²«
Month State Category
Day City Product Category
Ha egy lekérdezés olyan aggregátumra vonatkozik, ami nincs el re kiszámítva, akkor az OLAP Services a már meglév aggregátumokból számítja ki azt. Ez látható a fenti ábrán is, ahol a Month – State – Category szint aggregátum két el z tárolt aggregátumból is kiszámítható. A számításokra jellemz , hogy csak a SUM, COUNT, MIN és MAX függvényeket alaklmazhatjuk. A magyarázat erre az, hogy ezek azok a számítások, amik nagyon egyszer en gy r zhetnek fölfelé a dimenziók szintjei mentén. Átlagot a SUM és COUNT adatokból nyerhetünk.
£mTmT@ÄlhipH]Lia¡m^ Egy kockában az adatok partíciókban tárolódnak. Minden kockának legalább egy partíciója van, de a több partíció további el nyöket biztosít. A partíció egy fizikailag elkülönül tárrész a kocka egy adathalmaza számára. Minden partíción belül egyedi aggregátumokat tárolhatunk a kocka tényadataiból. Amiért partíciókat használunk, az az, hogy a kocka adatainak bizonyos részeihez eltér fizikai hozzáférési mintákat biztosítsunk. Ilyen minták például az adatfrissítések, lekérdezések és tárolások. Tárolásnál gyakori megoldás, hogy id szerint particionálunk, és a tavalyi ill. annál régebbi adatokat a kocka másik partíciójában tároljuk. Ezt a partíciót fizikailag tárolhatjuk egy kisebb teljesítmény szerveren, feltételezve, hogy a régebbi adatokra nincs olyan gyakran szükségem. Másik példa a lekérdezések esetében, hogy van a kocka adatainak egy olyan részhalmaza, amit gyakran érintenek a lekérdezések, és viszonylag jól elhatárolható ez a halmaz. Ekkor ezt a halmazt kiválasztva egy partícióhoz, azon további aggregátumokat számíthatunk, növelve ezzel a válaszid t (a tárterület növekedése árán). Fontos megjegyezni, hogy a partícionálás a kliens felé teljesen átlátszó, nem vesz észre az egészb l semmit. A lekérdezéseit a rendszer képezi le a partíciókra. Egy partíció egy ténytáblára épülhet, de egy ténytábla több partíció alapja is lehet. Partíciókat definiálhatunk a kocka egy meghatározott része, egy tényadatokra
rstu
vw x yz{|}~ |
y
#|y
³
vonatkozó feltétel, vagy egyszerre mindkett alapján. A többszörös partíciókat csak a Microsoft SQL Server Enterprise Edition támogatja.
£mTmTniT+ÄlhipH]Lma¡m^F^meim^ifi^Q_Q[iqmihi]ÑfmpLemdÉei]H]#pÑ@gÎdÉ[Qhm\hi Æfmc A kocka egy szeletéhez partíciót rendelhetünk. A szeletet csak dimenziókon adhatjuk meg, nincs mód a mért adatok alapján szeletelni. A partíció hierarchikusan vonatkozik a szeleten belüli adatokra. Ha a szelet, amit kiválasztottunk, egy levél, a partíció csak arra az elemre vonatkozik. Viszont ha a szeletet nem levél típusú elemre választjuk ki, akkor a partíció erre az elemre, és az alatta lév leszármazottaira egyaránt vonatkozik. A … ábra a kocka egy olyan felosztását mutatja, ahol az id dimenzió szerinti 3 szelet adja a 3 partíció alapját. Sorra az 1997, 1998, 1999-es éveknek megfelel en. Egy partíció tehát egy évnek megfelel adatot tárol, éves, féléves, negyedéves, hónapos, napos szintekre lebontva, a másik két dimenzió pedig legfels szinten vesz részt a kialakításban. Itt említjük meg, hogy lehet ség van hierarchikusan átlapolódó partíciók definiálására.
S
£mTmT T+ÄlhipH]Lma¡m^F]ÑmcÃÔÕhibmhi]Lem^ipLh±YÕeicmhi]L^meid¡»½ [i\]Hi]Ñ[m\@hm\hmÃÆfmc A partíciónkat úgy is kialakíthatjuk, hogy azokat az adatokat vesszük bele a ténytáblából, amik egy bizonyos feltételt kielégítenek. Ezt a feltételt egy SQL szer szintaxisnak megfelelel WHERE állítás után adhatjuk meg. Így a partícióba kerül adatok a ténytáblának a megfelel soraira korlátozódnak. Példa : fact_table.store_id month=’June 1999’)
IN
(SELECT
store_id
FROM
top_sellers
WHERE
Ez a példa egy bizonyos részhalmazát választja ki az üzleteknek (store).
£mTmT@¶#À©ÂÃÛÄVÐU±À©ÂÃÛÄVЧÀ·Â ÅÄ Egy kocka partíciójának adatait többféle fizikai módon érhetjük el és tárolhatjuk. Ezen módok rövidítései a ROLAP-HOLAP-MOLAP. Mindegyik módozatnak megvannak a maga el nyei, annak megfelel en, hogy mekkora az adatbázis, amit használunk, és milyen gyakran használjuk azt.
rstu
vw x yz{|}~ |
y
#|y
MOLAP (Multidimensional OLAP): Ez egy nagy teljesítmény adattárolási forma. Ebben az esetben a tényadatok az OLAP szerveren tárolódnak, a ténytáblából a partícióba másolódnak be. Ez a tárolási mód adja a legjobb teljesítményt a multidimenzionális lekérdezésekhez. A legalkalmasabb olyan kis és közepes méret adathalmazok esetén használni, ahol az adatok multidimenzionális formába történ másolása nem okoz túl nagy teljesítményigényt.
ROLAP (Relational OLAP): Relációs tárolási módnál minden adat az eredeti táblákban marad az RDBMS-ben. Ezen kívül az OLAP Services készít néhány relációs táblát, amiben az aggregátumokat tárolja el. Jól alkalmazható nagy méret adatbázisoknál, illetve ott, ahol az adatokat viszonylag ritkán kérdezem le .
HOLAP (Hibrid OLAP): A HOLAP vegyíti a tulajdonságait az el z két módnak. A tényadatokat ugyanúgy tárolja, mint a ROLAP, tehát relációs táblák formájában, míg az aggregált adatok esetén kihasználja a MOLAP technikáját, azaz az ilyn adatokat multidimenzionális formában tárolja. Az el nyei ebb l adódóan, hogy nagy méret adatbázisokat is jól kezel, és nagyobb teljesítményre képes az aggregált adatokra vonatkozóan. Egy kockánál a partícióknak meglehet a saját tárolási módjuk a kockán belüli partícióktól függetlenül. Mint korábban már említve volt, ez a felhasználó felé teljesen átlátszó, neki nem kell tör dnie, ill. tudnia a partíciók létezésér l. Több partíció esetén a partíciók összefésülhet k eggyé, feltéve, hogy ugyanolyan tárolási módjuk van, és az aggregált adataik is egyforma séma szerint vannak számítva.
rstu
vw x yz{|}~ |
y
#|y
²
£mT£mTÜËpHa]L[QÝÒhii^QmhipL]Hma¡i^ Az OLAP Services lehet séget biztosít arra, hogy egy kocába a kliens adatokat írhasson be. Ez azonban nem a kockába íróik be. A kliens a PivotTable Service használatával levél szint adatokat írhat be. Ez az adat nem íródik be a kockába, hanem write-back partícióba kerül. Ez a partíció más, mint az eddig tárgyaltak. A write-back partíciónál az adat, amit a kliens írt be, egy RDBMS táblában tárolódik, amit az OLAP Services hoz létre. (Pontosabban szólva az adatok változása kerül eltárolásra, egy változási láncot tárolunk.)
£mTªmT@Ê#a_F[mcida¡i^±½H[m\bmei\qmeidBfigÎh Dimenziókat kétféle módon dolgozhatunk fel, újraépítés és inkrementális érvényesítés révén. Újraépítésnél a dimenzió teljes egészében törl dik és felépül az t alkotó adatbázis táblákból. Ha a dimenziót els alkalommal hozzuk létre, ha szinteket adunk hozzá vagy veszünk el a dimenzióból, ill. ha a dimenzió alapelemeit töröljük, szükség van az újraépítésre. A dimenzió újtaépítése magával vonja a rá épül kockák újbóli feldolgozását is. Inrementális érvényesítésnél a dimenzióra vonatkozó információk megmaradnak, és csak az új elemek íródnak be a dimenzióba. Amíg a dimenziót nem dolgozzuk fel, addig a kliensek a régi dimenziót látják, az új elemeket még nem.
£mT¬mT@¤©eim^ifm^»½ [i\bmei\qieidfigÎh Kockák feldolgozásának három változata: teljes, frissítés, inkrementális érvényesítés. Teljes feldolgozásnál a kocka összes pertícióját úrjaépíti a rendszer. Az összes tárolt aggregátumot újraszámolja, és ha van olyan dimenzió, amit szükséges feldolgozni, akkor azt is megteszi. Abban az esetben, ha egy kockák frissítünk, az összes partíciójának a tárolt aggregátumai törl dnek, és újra kiszámításra kerülnek. Viszont a dimenziók állapota változatlan marad. Egyedi partíció frissítésénél csak a partíciót érint tárolt aggregátumokat számolja újra a rendszer, a többi partíciótól függetlenül. Inkrementális feldolgozásnál az OLAP Services egy WHERE feltételt használ arra, hogy a ténytáblából adatokat válasszon ki. Ezen adatokból számít aggregátumokat, és módosítja az eddig tárolt aggregátumokat, az újaknak megfelel en. A módszer jól alkalmazható akor, ha új tényadatok állnak rendelkezésre, de a struktúra változatlan marad.
£mT´mT@¤©\a[icmgZÐVd[ip¦YÕ[ipV½H[m\bmei\qmeidÉfmg Amikor a PivotTable Service a Microsoft OLAP Serviceshez kapcsolódik, az MDX nyelven megfogalmazott lekérdezéseket el ször a PivotTable Service ellen rzi, és
rstu
vw x yz{|}~ |
y
#|y
ezután kerül sor a lekérdezés által érintett adatok halmazának a meghatározására. Ha a szükséges adatot a PivotTable cache tartalmazza, akkor a kívánt számítások a PivotTable Service részben mennek végbe, és innen jutnak vissza a klienshez. Ellenkez esetben, ha a kívánt adat nincs a cache-ben, akkor a PivotTable Service a szükséges adatokra vonatkozó kérést intéz a szerverhez, ami elküldi ezeket. A kapott adatokat a PivotTable Service a saját cache-ében eltárolja. Az OLAP Services a feldolgozást megpróbálja szétosztani a kliens és a szerver között, attól függ en, hogy milyen er forrásokra van ahhoz szükség. A szerveren tárolt kockánál, ha a hálózaton átküldend adat túl sok lenne, akkor a feldolgozás a szerver oldalon megy végbe, és csupán az eredményt küldi át a szerver a kliensnek. A kliens kérésére adott válaszid csökkentése érdekében többszint cache mechanizmus m ködik. A kérést el ször a PivotTable cache próbálja kielégíteni. Ha ez nem megy, akkor az OLAP szerverhez fordul. Az szintén a saját cache-éb l próbálkozik. Ha ez sem megy, akkor ROLAP és HOLAP esetén az RDBMS-hez fordul a szerver. Itt is létezik cache, és természetesen a rendszer ezt vizsgálja meg.
ªmT+oi[i\ihmgdÉcifm\]#apÑembihm\ei_
[1993-1995, Kenan Technologies] Erik Thomsen, George Spofford, Dick Chase: [1999, Wiley Computer Publishing]