Adattárházak


A következő fejezetben az adatbáziskezelés területén igen kurrens és egyre jobban 
elterjedő fogalmatm, az adattárházak fogalmát  vizsgálunk meg közelebbről. Az 
újságok hírdetéseit, a cégek bemutatót és a tudományos publikációkat figyelve, az 
adattárházak fogalma központi szerepet tölt be napjaink újdonságai között, s 
minden valószínűséggel a holnap mindennapjainak termékei között. Az adattárház 
azonban  nemcsak egy elképzelés, hanem már ma is létező rendszer. Több, köztük 
igen komoly szoftverfejlesztő cégek is, foglalkoznak adattárházak értékesítésével. 
Ez viszont azt mutatja, hogy az adattárházak fogalma nem valami most születő, új 
dolog, hiszen a tapasztalat szerint igen hosszú idő telik el, amíg egy elképzelés 
termék formájában a piacra kerül (az adatmodellek terén ez az idő 10-13 évet is 
kitett). Nézzük meg hát, mit is jelent és hogyan alakultak ki az adattárházak.

Az adatbázisok alkalmazási területeit vizsgálva, sokunknak  olyan klasszikus 
alkalmazási területek  jutnak az eszébe, mint egy könyvtári rendszer, 
jegynyilvántartás, számlák kezelése, termelési adatok, raktár nyilvántartása. Ha 
megpróbáljuk ezen alkalmazások közös jellemzőit megkereseni, akkor bizonyára 
fel fog tűnni, hogy e rendszerekben az adatbázis a vizsgált rendszer 
adminisztrálására szolgál, vagyis az adatbázisban a vizsgált rendszer leírása 
található, mégpedig az aktuális állapota. Egy raktári nyilvántartó rendszerben az 
adatbázis a raktár aktuális feltöltöttségét mutatja, megadva, hogy mely 
termékekből, mennyi és hol helyezkedik el. 

Az ilyen rendszerek nyugvó alkalmazásokra pedig az jellemző, hogy a lekérdezési 
funkciók mellett számos olyan funkciót is tartlmaznak, melyek megváltoztatják az 
adatbázis tartalmát. Ezek a funkciók a valóságban megjelenő folyamatokat képzik 
le a információs rendszer szintjén. Az előző példánál maradva a raktárnál 
előfordulnak be- és kiszállítások is. Mindkettő megváltoztatja a raktár állapotát. Az 
alkalamzásnak tehát tartalmaznia kell műveleti elemeket a beszállítás és a 
kiszállítás leképzésére, hogy az adatbázis mindíg az aktuális képet mutassa. Mivel 
információs rendszerek éppen az olyan területeken nyújtanak nagyobb segítséget, 
ahol a rendszerben gyakran történik változás, ezért a klassszikus alkalmazások is 
gyakran hívnak meg módosítási tevékenységeket.

A klasszikus alkalmazási területekre tehát az jellemző, hogy az adatbázisban a 
rendszer aktuális állapota tárolódik, az alkalamzások fő feladatai a valóságban 
bekövetkező események leképézése, adminisztrálása az adatbázisban és az 
aktuáléis állaporta vonatkozó lekérdezések megválaszolása.

Haátgondoljuk az általunk imsert más adatbázisokon nyugvó alkalmazások célját, 
működését, valószínűleg ez előbb leírt  megállapításokhoz fogunk jutni. De azért 
biztos lesznek olyan példáink is , melyekben nem teljesen érvényes a 
megállapításunk. 

Egy kazetta kölcsönző hallgatói mintafeladat tervezésénél már rögtön az elején fel 
szokott merülni az a kérdés, hogy egy kölcsönzés egyed mint jelentsen, egy létező, 
élő kölcsönzést vagy egy valamikor megtörtént kölcsönzést. Vagyis el kell 
dönteni. hogy az adatbázis csak az aktuális állapot nyilvántartására, vagy a korábbi 
állapotokot megőrzésére is vonatkozzon. Ez utóbbi esetnek is van értelme és célja, 
hiszen a múlbeli állapotok hasznos információkat adhatnak a felhasználó számára. 
Technikailag pedig az adatbázis korrábbi állapotainak megőrzése rendszerint nem 
igényel nagy programozói ráfordítást, csak rendelkezésre álló tárolói kapacitás 
szokott határt szabni az archív anyagok megőrzésének. 

Ugyan  a múltbeli adatok megőrzése nem okoz nagy gondot, mégis az archiválás 
nem egy öncélú tevékenység. Mindíg kell mögötte lenni valamilyen indoknak.  Ez 
az indok lehet például egy előírás, hogy rekonstruálhatóknak kell lenniük bizonyos 
multbeli események. Egy beléptető  rendszernél szükség lehet egy adott múltbeli 
időpontbn benn tartózkodó személyek listájára.

A letároltm, archív adatok azonban nemcsak az egyszerű visszaolvasásra 
használhatók föl. Már az információs rendszerek kialakulásának korai szakaszában 
rájöttek, hogy a letárolt adatokból a jelen helyzetben is hasznosítható információk 
nyerhetők ki. Egy video kazetta kölcsönző esetében például annak ismerete, hogy 
mely tipusú kazettákat igényelték a legtöbben, segítségül lehet abban, hogy a 
beszerzéseknél mely területekre koncentráljanak. A kölcsönzések volumene pedig 
a várható forgalomban, a beruházások méretezésében adhat támpontot.

A hagyományos, aktuális állapot lekérdezésére vonatkozó alkalmazások mellett 
kialakultak az információs rendszerek új elemei, melyek a múltbeli események 
elemzése alapján a jövőben várható folyamatok megterevezését segítik. Az így 
kialakuló alkalmazásokat szokás döntés támogató rendszereknek (DSS, Decision 
Sipport System) is nevezni. Az információs rendszerek felvázolt fejlődését 
szemlélteti a következő (  ) ábra. 

A DSS rendszerek nemcsak a alkalmazott műveleti lépésekben, a felhasznált 
adatmennyiségben különbözik a hagyományos alkalmazásoktól, hanem a 
felhasználói körében is. Mig a hagyományos alkalmazásokat az operatív 
tevékenységben résztvevő dolgozók használják, addig a DSS rendszerek a vállalat 
vezetőo számára készültek. A DSS rendszereket elsősorban a vállalat működését 
befolyásoló startégiai kérdések megoldásánál szokták alkalmazni.


 

A DSS rendszerek legfontosabb jellemzői az alábbi pontokban foglalható össze.

- A DSS működési algoritmusában az egyszerű adatolvasás és adatírások helyett az 
adatok analitikus, statisztikus elemzése dominál. Vagyis a DSS rendszernek a 
normál  adatkezelő utasítások mellett rendelkeznie kell adatelemző 
komponensekkel is. 
- Az egyik legfontosabb cél az adatok mögött húzódó trendek felderítése, vagyis az 
események változási irányát, a változás jellegét kell meghatározni.
- A DSS rendszerek csak olvasássák a letárolt adatokat, s nem tartalmaznak 
adatmódosítási elemeket. A döntéshozáshoz csak a meglévő információkat kell 
felderíteni. A rendszer  a döntés meghozatalát segíti, magát a döntést, avele járó 
változtatásokkal már  nem a DSS rendszer fogja meghozni.
- A  megfelelő minőségű,  megbízható előrejelzéshez kellő adatmennyiség 
szükséges. CSekély műltbeli adatokból nem lehet pontos elemzést, trend számítást 
végezni. Emiatt a DSS rendszerek igénylik a nagy adatmennyiséget. Az múltbeli 
állapotok megőrzése miatt a DSS rendszerek nagyobb adatmennyiséget tárolnak, 
mint az aktuális állapot adminisztrálását végző rendszerek.  
-  A DSS rendszerekben nagyobb szerepe jut az időbeliségnek, vagyis annak, hogy 
egy adateléem, mely időponbeli aktuális állapotnak felel meg. A hagyományos 
rendszerekben az időnek nem volt ilyen nagy szerepe, hiszen, minden adat az 
éppen aktuális időpontra vonatkozott. Most viszont szükségszerű minden 
adatelemet egy időértékkel is összekapcsolni, ha időbeli trendek figyelését is 
megkívánjuk a rendszertől
- A DSS rendszereknek egy felhasználóbarát, emberközeli kezelő felülettel kell 
rendelkezniük, hogy a számítástechnikában kevésbé járatos személyekis 
alkalamzni tudják. A kezelő felület egy másik jellegzetessége, hogy a lekérdezések 
terén viszont megfelelő rugalmasságot kell muttania, hiszen a gűdöntések 
meghozatalánál az a jó, ha problémát sok oldalról, többféle megközelítésben meg 
lehet vizsgáni, s ehhez a tárolt adatokból többféle szempont szerinti lekérdezésekre 
is szükség lehet. A DSS-nek tehát egy emberközeli és rugalmas lekérdező felületet 
kell tartalmaznia.

A újfajta műveleti igényrendszer az adatkezelés felé is kihatással van. A DSS 
rendszerek ugyanis egy olyan adatbáziskezelő rendszert igényelnek, melyben 
kevésbé fontosak a párhuzamos módosítások vezérlése, viszont hatékony és 
rugalmas adatlekérdezés, adatelemzési lehetőségeket kell biztosítania. Tehát a 
DSS-t támogató DBMS rendszereknek a DSS specifikus műveletekre 
optimalizáltan kell működni. Ehhez 

	- gyorsabban kell megvalósítania a nagytömegű adatok közötti kapcsolatok 
	kezelését
	- analítikus műveleteket kell tartalmaznia
	- fel kell készülnia a hosszabb, a nagyobb adatmennyiséget érintő 
	lekérdezési tranzakciók kezelésére

Mivel a klasszikus DBMS működési elvek egészen más tevékenységekre fektetik a 
hangsúlyt, ezért elnevezésben is eg szokták egymástól különböztetni az 
adatkezelés e két megvalósulási formátumát. A hagyományos adatkezelést nevezik 
OLTP (On Line Transaction Processing), azaz on-line tranzakció orientált 
rendszernek, míg a másik módszer az OLAP (On Line Analitical Processing), azaz 
on-line analitikus elemzés orientált adatkezelés.

Az OLTP rendszerekben a működés szokványos módja a több konkurrensen futó 
tranzakció.. Ezek a tranzakciók rendszerint adatmódosítási műveleteket 
tartalmaznak. Egy helyfoglalási rendszer esetén egy tranzakció magába foglalja az 
egy ügyfélhez kapcsolódó tevékenységeket: üres helyek lekérdezése, hely 
lefoglalása, visszaigazolás kinyomtatása. A rendszer egyidejűleg több tranzakciót 
futtahat, több száz bejelentkezett felhasználó lehet egyidejűleg. Ugyan sok 
tranzakció él egy időpillanatban, de e tranzakciók rendszerint rövid életűek. 
Például a helyfoglalás is csak pár percet vesz igénybe.Ezalatt a rövid futásidő alatt 
a tranzakció viszonylag kevés elemet érintő lekérdezéseket és módosításokat hajt 
végre. 

Az OLAP rendszereknél viszont lényegesen kevesebb a párhuzamosan futó 
lekérdezési műveletsor, viszont ezek igazán jól megtermett lekérdezések is 
lehetnek, melyek időben is lényegesen hosszabb időt igényelnek. Az OLAP 
rendszereknél nem ritka a több órás, a napos futási idejű lekérdezések sem, hiszen 
mögöttük hatalmas adatmennyiség áll. 

Az OLAP és az OLTP között lényeges különbséget fedezhetünk fel a kezelt  
adatok jellegében is. Az OLTP rendszereknél az adatok a vizsgált terület aktuális 
állapotát tartalmazták. A módosítások és a konzisztens állapot megőrzésének 
megkönnyítése végett az adatbázisban egy homogén modell szerint tárolódik az 
aktuális állapot. Vagyis a működési rendszer zömével egyetlen adatforásra épít. 
Ennek számos előnye van a fejlesztés munka és karbantartási tevékenységek 
vonatkozásában. 

Az OLAP rendszerek fő célja azonban nem egy konzisztens, aktuális kép minnél 
hatékonyabb biztosítása, hanem az hogy minnél több információt nyerjünk ki a 
rendszerből. Ennek egyik biztosítéka az, ha minnél szélesebb információ forrást 
bevonunk az értékelésbe. Mivel egy vállalati források formátumokban igen 
lényegesen eltérhetnek egymástól (adatok egyrésze pl. UNIX alattui 
munkaállomásokson RDBMS-ben,míg másik része PC-s xBAse rendszerben, 
harmadik része Pc-s táblázatkezelőkben tárolódik) szükség van a herterogén 
adatok egséges kezelésére, a heteregonén adatok összedolgozására.

A következő táblázatban áttekintjük az OLTP-OLAP összehasonlításás 
legfontosabb jellemzőt.

OLTP					OLAP
----------------------------------------------------------------------
kisebb adatmennyiség			nagyobb adatmennyiség
----------------------------------------------------------------------
módosítások				csak olvasás
----------------------------------------------------------------------
aktuális állapot a DB-ben		archivumok
----------------------------------------------------------------------
rövid, gyakoribb tranzakciók		ritkább, hosszabb tranzakciók
----------------------------------------------------------------------
kevés elemet érintő tr.			több elemet érintő tr.
----------------------------------------------------------------------
nagy konkurencia			kisebb konkurencia
----------------------------------------------------------------------
homogén adatforrás			heterogén adatforrás
----------------------------------------------------------------------


Az OLAP rendszerekkel kapcsolatosan az egyik legfonotsabb kérdés az, hogy 
hogyan lehet  minnél hatékonnyabban biztosítani a komplex lekérdezések 
végrehajtását. Itt a lekérdezés bioztosítása nemcsak a művelet optimalizálását 
jelenti, hanem annek eldöntését, hogy milyen kiegészítő információkra van 
szükség a hatékony kezelés megoldásához.

Mivel az eddig ismertett DBMS struktúrák a klasszikus, OLTP orientált 
adatkezeléshez lettek illesztve, az OLAP igényeket csak körülményesen, 
nehezebben lehet vele megvalósítani.Vagyis a klasszikus DBMS rendszerekkel 
ellentétben az OLAP rendszerek fejlesztésénél szinte minden OLTP specifikus 
tulajdonságot a fejlesztőnek kell megvalósítania az alkalmazásban. A legnagyobb 
hátránya ennek a megvalósításnak, hogy

	- a legfontosabb OLAP funckiók nem részei a DBMS-nek, így 
	megvalósításuk többletmunkát jelent és algoritmusok és funkcionalitásuk 
	alkalmazásról alkalmazásra változhat. 
	- az OLAP analitkus műveletek igen nagy időszükségletettel rendelekznek a 
	hagyományos DBMS tárolási struktúra mellett. Az OLAP lekérdezések 
	jellemzője ugyanis, hogy több változó kapcsolatát, a változókon értelemzett 
	különböző aggregációs értékeket és azok kapcsolatát vizsgálja. A klasszikus 
	elsődleges kulcs - idegen kulcs szerkezettel ezen kapcsolatok feltárása igen 
	hosszadalmas műveletnek bizonyul.

A felmerült hatékonysági problémák megoldására elindult a  fejlesztés a 
hagyományos DBMS-ek olyan irányú átalakítására, hogy a kapott  a rendszer 
alkalmas legyen az OLAP igények kielégítésére. A cél tehát egy, az OLAP 
igényekhez igazított DBMS rendszer kidolgozása.

E kutatások eredményeként létrejött adatbázis kezelő rendszer az adattárház 
elnevezést kapta, melyet a DW:(data warehouse) rövidítéssel is jelölhetünk. 

Az adattárházak szülőatyjának Inmon-t szokták tekinteni, aki hasonló szerepet 
játszott a DW kialakulásában, mint Codd a relációs modell megszületésében.  Az 
adattárházak fogalmának kialakulása az 1970-es évek vége körüli odőszakra 
tehető. Erre az időszakra már megjelentek az első nagy információs rendszerek, 
melyek elsődlegese a napi működési rendszer igényeit szolgálták ki. Az ezen 
rendszerekre felépített DSS alkalmazások két súlyos hiányossággal rendelkeztek:

	- lassú műveleti sebesség és
	- szétdarabolt adatszigetekből áll fenn a rendszer.

Ez utóbbi annak köszönhető, hogy a működési rendszernél minden nagyobb 
területnek megvolt a saját adatbázisa. A DSS rendszernek ezen adatbázisokból 
kellett összeszednie az elemzésre kerülő adatokat.

E hiányosságok leküzdésére megjelent egy új DSS orientált adatkezelő rendszer, 
az adatatárház. A hagyományos működési rendszereket a hagyományos RDBMS 
rendszerek, míg a DSS alapú funkciókat pedig az adattárház vette át. Az RDBMS 
és az adattárház szétválásának megoldotta az említett problémákát, s emellett még 
olyan pozitív hatásokkal i sjárt, hogy

	- elkülönítette  aműveleti rendszert a DSS elemektől (nagyobb védelem)
	- adatok egyesítését hozta magával.

Az induló lelkesedés után az adattárházak fogalma egy kicsit a háttérbe szorult az 
1980-es évek második felében, oly annyira, hogy 1991-ben sokan már az 
adattárházak halálát emlegették. A pesszimizmus oka az volt, hogy az akkori 
adattárház rendszerek igen merev struktúrájűak voltak, nem követték a 
felhasználói igények változását. 

Az 1990-es évek elejétől kezdve azonban újra megerősödött a DW technológia, ma 
már a legkorszerűbb technológiákat vonultatja fel, s olyan vezető cégek állnak 
mögötte, mint az Oracle, IBM, SAS. 

A DW rendszerek mára már piacérett termékek lettek, szerepük egyre nől az 
adatbáziskezelő rendszerek piacán. A DW termékek érettségét nemcsak az 
alkalmazások darabszámának emelkedése, hanem felhasználások méretének  
növekedése is jellemzi. Mára egyre nagyobb adatmennyiség feldolgozására 
képesek a megvalósított adattárház  rendszerek. A méretnökedés tendenciáját jól 
szemlélteti a következő ábra, melyben az új,installált  DW alkalmazások méret 
szerinti elosztását mutatja a 95-ös és a 96-os években. Látható,hogy egy év alatt is, 
mennyivel megnövekedett a nagyobb, a terrabyte nagyságrendbe eső rendszerek 
súlya.


 

Nézzük e rövid történelme áttekintés után, mi is értünk adattárház alatt, mi 
különbözttei meg a DW rendszereket a hagyományos relációs DBMS 
rendszerektől.

Inmon megfogalamzása, definíciója alapján az adattárház rendszerek egy 
témaorientált, integrált, időben változó adatrendszernek tekinthető, melynek 
elsődleges célja a stratégiai döntések támogatása.

A megfogalamzásból kiemelhető, hogy a DW-ben a tárolt adatrendszer  több 
helyről is származó, integrált adatokat tartalmazhat. Vagyis a DW egy gyüjtőhely, 
amelybe számtalan forrásból származó  adatelemek kerülhetnek bele. Emiatt is 
nevezik ezen adatrendszert adattárháznak, adat raktárnak. Az adattárház azonban  
több, mint  egyszerú adatlerakat, mivel a DW-ben nemcsak magát az adatelemeket, 
hanem a köztük fennálló kapcsolatokat is tárolják. Az egységes tárolás és 
értelmezés igényeinek megfelelően a DW egyik fontos funkcionális eleme a 
beérkező, különböző helyről származó  adatok integrálása.

Az integrált adatrendszer kialakításánál fontos, hogy csak megbízható információk 
kerüljenek be a rendszerbe. Ezért az adatok beolvasásánál az adatok helyességének 
az ellenőrzésére is törekedni kell, mely folyamtot szokás az aadtok tiszttításának is 
nevezni. A tisztitás során a megfelelő segédprogram segítségével  lehetőség van 
bizonyos értékhibák feltárására. Így például az életkor mező túl kicsi vagy túl nagy 
értéket tartalmazna, akkor ez a hiba a a tisztítás során kijelézésre fog kerülni. A 
fejlettebb ellenőrzési rendszerek nemcsak a statikus hibákat veszik észre, hanem 
alkalmasak explicite nem definiált szabályok feltárására is. A  szabálytól eltérő, 
gyanúsnak tartott  értékek esetén egy figyelmeztető üzenetet írnak ki a 
felhasználónak. Ha például minden forgalmazónál szokott lenni reklamáció, akkor 
a rendszer jelezést fog adni, ha olyan forgalmazót talál, akinél még nem fordult elő 
reklamáció.  


A adattárházak működésére áttérve előbb vizsgáljuk meg a DW rendszerek (DWS) 
működési környezetét. Mint ahogy  a következő ábra is mutatja, a DWS bementi 
oldalán a hagyományos adatforrások, az OLTP rendszerek és nem 
adatbáziskezelők állnak. A DWS a bemenő adatokat összegyüjti, tisztítja majd 
beintegrálja az adatbázisába. A DWS-en belül a hagyományos adatok mellett 
lényeges szerepet játszik az adatok struktúrájának a leírását tatalamazó repository 
is. A tárolt adatok lekérdezésére, elemzésésre a DWS-hez több különböző OLAP 
eszközök csatlakoznak.

Ezen klasszikus adatelemzési statisztikai módszereken kívül, úgynevezett data-
mining, azaz adat bányászási lehetőségek is rendelekzésre állhatnak. A data 
mining annyiban különbözik  a hagyományos adatkezeléstől, hogy itt nem a tárolt 
adatokat kérdezzük le közvetlenül, hanem a közvetlen adatokértékek mögött 
húzódó összefüggéseket, melyeket nem lehet közvetlenül látni az adatokból.


 


A DW rendszereknek a megkívánt funkcionális elemek biztosítására új struktúrális 
elemekkel is bővülniük kellett. Összehasonlítva  a hagyományos DBMS 
rendszerekkel,  az adattárház rendszerek egy újszerű működési struktúrájuk van, 
melyet a következő ábrában mutatunk be. 

 


A felvázolt modellben mintegy nyolc réteget különböztetnek meg a fontosabb 
struktúrális egységek szétválasztása alapján. E rétegek önálló algoritmussal 
rendelkeznek, önálló funkciókat látnak el, de a DWS működéséhez e rétegek 
együttműködésére van szükség. Az egyes rétegek jelentése a következőkben 
foglalható össze.

- Információ hozzáférési réteg
Ez a réteg azon OLAP eszközöket, lekérdező felületeket foglalja magába, melyek 
a felhasználók rendelkezésére állnak és  az adattárház adatain értelemzett 
adatelemző tevékenységek végrehajtására szolgálnak. Ezen réteghez elemei közé 
sorolhatók a különöző grafikus és táblázatszerű lekérdező, adatelemző és 
adatbányászó felületek. A felhasználó ezzel a felülettel fog kapcsolatot tartani az 
adatelemzési, adatlekérdezési  munkája során. Lényeges, hogy e felület 
funkcionálisan gazdag és korszerű legyen, hiszen a felhasználók e rétegen 
keresztül itélik meg a DW rendszerek korszerűségét és használhatóságát.

- Adathozzáférési réteg
Az adathozzáférési réteg egy kezelő nyelvet foglal magába, melyen keresztül 
elérhető az alatta elhelyezkedő adatkezelő rendszerek. Az RDBMS-re 
vonatkoztatva az adathozzáférési rendszer legismertebb eleme az SQL nyelv, 
hiszen e nyelven megfogalmazott utasításainkat a RDBMS értelemezni tudja és 
végre is hajtja. E réteg a kommunikációs nyelv mellett a kommunikációhoz 
szükséges értelmezőket is tartalmazza.  Az adathozzáférési réteg egyfajta 
homogenizálási funkciót is el kell látnia, hiszen az elemzésbe bevont adatok 
számos, különböző szintaktikával működő forrásokból is származhatnak. 

- Adattárház
Az adatok tényleges forrása. A vizsgált adatok együttese, a normál és meta 
adatokkal, a kapcsolatokkal és az integritási szabályokkal együtt. Az adatok 
tárolása sok esetben nem jelent fizikai szinten történő tartalmazást, ugyanis 
léteznek olyan tárházak is, melyek csak az adatok forrására utaló utalásokat, az 
adatok és kapcsolataik struktúráját tárolják. Maguk a tényleges adatok csak a 
forrásukban léteznek, nem kerülnek fizikailag át az adattárházba.

- Adatszótár
Az adattárház része, melyben a tárolt adatrendszer leírása, az adatrendszer 
struktúrája foglal helyet. Az adatszótárban tárolják a funkcionálisan teljes
adattárház megvalósításához szükséges metaadatokat, mint például  az adatok 
tipusairól, kapcsolatairól vagy az  adatok forrásáról. A felhasználónak úgy kell 
tudnia hozzáférni a DW-ben tárolt adatokról, hogy ne kelljen ismernie az adatok 
elsődléeges forrását és struktúráját.
 
- Processz menedzsment
A processz menedzsment réteg a DWS, azadattárház és az adatszótár fenntartása 
érdekében végrehajtandó taszkok, processzek időzítésében játszik szerepet. A 
lekérdezések ütemezése mellett a karbantartási funkciók, mint például az adatok 
frissítésének a vezérlését is ellátja.

- Adattovábbító réteg
E rétreg feladata az adatforrásokból származó adatoknak az adatattárházba történő 
integrálása. Ez az feladat magába foglalja az adatforrások kiválasztását, elérését; a 
kiejlölt adatok beolvasását; az adatok tisztítását, szintatktikai ellenőrzését; az 
adatok betöltését, a megfelelő tárolási struktúrák aktualizálását. Ezek a funkciók 
egy komplex programozási feladatot jelentenek, és a létező DW rendszerek egyre 
kényelmesebb és sokrétűbb szolgáltatást nyújtanak ezen a téren. 

- Adatforrás réteg
Azon működési adatbázisokat és egyéb szöveges vagy táblázatszerű adatforrásokat 
foglalja össze ez a réteg, melyek az adattárházban tárolt adatok forrását jelentik. 
Az elsődleges adatok származási helye igen változatos képet mutathat, kezdve a 
hagyományos RDBMS rendszerektől egészen a távoli csomópontokon 
elhelyezkedő Excel, xBase állományokig.  Az adatforrások rendszerint csak az 
aktuális időpontra, állapotra vonatkozó adatokat tárolják, melyekből a frissítés 
vagy betöltés útján az aktuális állapot átkerül az adattárházba a korábbi állapotok 
adatai mellé.  

- Alkalmazás kommunikációs réteg
Az alkalmazás kommunikációs réteg elsődleges feladata a rendszer komponensei 
közötti hálózati kommunikáció biztosítása. Ennek ellenére mára már számos egyéb 
segédfunkciót is ellát ez a réteg,  így felhasználható  például az adatformátumok 
függetlenségének biztosítására vagy a  tranzakciók és az üzenetek összegyüjtésére, 
megadott helyre történő lehelyezésével. 

A felvázolt architektúra az adattárház rendszerekben  megvalósítandó funkciókat 
foglalja össze, megadva a funkcionálisan teljes adattárház rendszerek  
komponenseit. A funkcionális felsorolás alapján tudható, hogy mi e komponensek 
célja, rendeltetése, s hogyan kapcsolódnak össze ezek a komponensek, viszont 
nem mond semmit arról, hogy hogyan is valósulnak meg ezek a funkciók az egyes 
komponensekben. 

Mivel az összes komponens részletes tárgyalása meghaladná e jegyzet kereteit, 
ezért itt mi csak a legfontosabb elemre, a rendszer központi komponensére, magára 
az adattárház elemzésére térünk ki.

Az adattárház alapfunkcióiban egy adatkezelő, egy speciális adatbáziskezelő 
rendszer funkcionalitását kell biztosítani. A DW-k történetileg az RDBMS 
rendszerekből fejlődtek ki, s e szoros rokonság napjainkig is megmaradt. Ma is 
léteznek olyan adattárházak, melyek az átalakulás első lépcsőfokain állnak, vagyis 
szerkezetükben a relációs magokat őrzik. Ezen rendszerekben az adatok tárolása 
továbbra is a relációs modell formalizmusában történik. Ezen rendszereket nevezik 
relációs OLAP, vagyis ROLAP rendszereknek.

A ROLAP rendszerekben  az adattárház minden adata a jól ismert relációs 
struktúrákban, azaz táblázatokban történik, ahol az egyes rekordelőfordulások 
közötti kapcsolatokat a hagyományos elsődleges kulcs - kapcsoló kulcs párossal 
oldják meg. A műveleteket tekintve szintén a relációs algebrai műveletek 
fekszenek a működési rendszer aélján, mlyre speciális, OLAP igényeket kielégítő 
funkciók ülnek rá.

 E módszer előnye, hogy az adatbáziskezelés általános funkciót nem kell 
mégegyszer megvalósítani, e rendszerek úgymond ráülnek az RDBMS-re, 
felhasználják  az ott már megvalósított szolgáltatásokat. A DW feljesztők fő 
feladata egy OLAP lekérdező rendszer ráültetése az RDBMS-re. E megoldás 
további előnye a gyorsabb kifejlesztés mellett az, hogy így a DW is örökli 
mindazon megbízhatóságot, robosztusságot és piaci hátteret, amit a befutott 
RDBMS rendszerek biztosítanak.

A számos pozitív vonás mellett van azonban egy lényeges ellenvetés is e módszer 
ellen, nevezetes az, hogy a relációs modell nem kimondottan az OLAP igények 
kielégítésére készült (habár mégegyszer hangsúlyozzuk, hogy a relációs modellen 
alapuló OLAP is elterjedt, megoldható megolfádnak számít), aminek az a  
következménye, hogy a ROLAP rendszerekben az egyes OLAP műveletek 
hatékonysága nem a legoptimálisabb. Más, speciálisabb struktúrával gyorsabb 
műveleti végrehajtást lehetne lérni.

Hasonlóan problémát okozhat, hogy az OLAP terminológiák és műveletek igen 
eltérnek a relációs algebrai műveletektől és terminológiáktól. Az OLAP szintjén 
jóval magasabb szintű funkcionális elemkre van szükség, mint az  RDBMS 
szinten. Ezért célszerűbb lenne olyan adatmodellre építeni, amleyik jobban 
támaszkodik és megfelel a OLAP igényeknek. Így jött létre egy új adatmodell, a 
multidimenzionális adatmodell.

A multidimenzionális adatmodell nem egy most kipattant fogalom, már elég régóta 
ismert a létezése, igaz csak igen szűk körben. A multidimenzionális adatmodell 
első felbukkanási helyének az MIT egyetemet tartják, ahol 1972-ben 
(tehát szinte a relációs adatmodellel egyidőben),  elkészült egy kisérleti DSS 
rendszer, amely az adatkezelést már multidemenzionális alapokon valósította meg. 
Ugyan a rendszer sikerrel működött, azonban  nagyobb térhódítására elég sokat 
kellett várni, hiszen csak a 90-es évek elején jelentek meg a piacon a nagyobb 
szoftvercégek olyan multideminzionális alapokon nyugvó OLAP rendszerekkel, 
melyek már ütőképseseknek mutatkoztak (pl. SAS, Oracle Express). A 
multidimezionális OLAP rendszereket MOLAP rendszereknek nevezik.

Nézzük meg közelebbről, mi is vezett a multidimenzionális adatmodell (MD) 
kialakulásához. Ha egy vállalati vezető helyébe képzeljük magunkat, akinek 
sfontos stratégia kérdéseket kell hoznia, arról, hogy például mely régiókat, 
terméketet fejlesszen avgy reklámozzon, akkor érzékeljük a megfelelő információk 
fontosságát. Mint ahogy Murphi is megjegyezte, kellő információk birtokában 
mindenki jól tud dönteni, a jó vezető a kevés információk alapján is jól tud 
dönteni.  E mondás ellenére azt hiszem, a jó vezetők sem vetik meg a megfelelő 
információkat. A vezető számára azonban nem minden információ megfelelő, 
hiszen a túl részletes leírás, pl. az eddigi minden eladás listája, feldolgozhatatlan, 
hiszen túl sok olyan részletet tartalmaz, melyek eltakarják a fontos részletet. A 
vezetők  tehát összesítő információkat igényelnek.

Másrészt a vezetők nem a puszta tényekben, hanem a különböző tényezők 
kapcsolatára kiváncsiak. Egy döntéshez például nem pusztán azt kell isemrni,hogy 
mennyi volt a vállalat múltévi forgalma, hanem olyan finomabb ismeretekre van 
szükség, hogy hogyuan alakult például két termék vagy régió egymáshoz 
viszonyított forgalma. Tehát a vezetőt e mennyiségek kapcsolata, alakulása 
érdekli. A megfelelő adatmodellben e kívánalmaknak kell tükröződniük.

A multidimenzionális adatmodellben az adatokat úgy tárolják, hogy minnél 
könnyebben le lehessen kérdezni a különböző mennyiságek közötti kapcsolatot. A 
relációs modellell szemben, ahol a különböző mennyiségek adatai szeparált 
táblázkban kerültek elhelyezésre, az MD-ben a kapcsolódó adatok egy struktúra 
egységben  foglalnak helyet. Egy ilyen egységben több kapcsolódó mennyiség is 
helyet foglalhat. 

A MD-ben azt a tárolási egységet, mely a kapcsolódó mennyiségeket összefogja, 
kockának nevezik. A kocka minden éle egy-egy önálló mennyiségnek felel meg, 
míg a kocka belsejében azon mennyiség előfordulásai foglalnak helyet, melynek 
az élekben megdott mennyiségektől való függését vizsgáljuk.  A kockában az 
adatok, értékek több más mennyiség függvényében jelennek meg.

A kocka modellel  jelentősen javítható az összetartozó mennyiségek közötti 
kapcsolatok feltárása is, hiszen a kockában nem a puszta értékken keresztül 
kapcsolódik a kocka beljesében tárolt és a kocka élein elhelyezkedő mennyiség, 
hanem egy bonyolult pointer láncolatot hoznak létre, mely lehetővé teszi, hogy egy 
adott értékből közvetlenül elérjük  a hozzá kapcsolódó független menyiségeket.

A relációs és a multidimenzionális  adatmodell áttakintő összehasonlítására 
vegyünk egy kereskedelmi vállalat forgalmát vizsgáló mintapéldát. A rendszerben 
a fogalomnak a  régiótól, a terméktől és az időtől való függését kívánjuk 
megvizsgálni. A következő ábra a kétféle tárolási mechanizmust szemlélteti.

 


A relációs modellben a forgalom táblában található a forgalom értéke, az eladás 
dátuma, illetve a kapcsoló kulcsok az eladásban szereplő termékre és eladóra. Ezen 
adatok a normalizálás folyamán kerültek át külön táblákba. A multidiemnzionális 
modell esetén a forgalom adati szerepelnek a kocka belsejében (mind egy-egy 
kocka cella), s a kocka élei a különböző régió, termék és időpont értékeket 
tartalmazzák.

A kétféle működési mód összehasonlítására vegyük azt az esetet, amikor egy adott 
termékre vonatkozó forgalmakat kívánjuk lekérdezni. A relációs modellben előbb 
meg kell keresni a termék kódját, majd át kell nézni a forgalom táblát az ilyan 
idegen kulccsal rendelkező rekordok felkutatására. Az MD-ben viszont előbb a 
kocka megfelelő élén előbb a termék kódjára kell ráállni, majd onnan már 
közvetlenül, pointereken keresztül eljuthatunk a termékhez tartozó cellákhoz. Ez a 
módszer még akkor is gyorsabb megvalósítást eredményez, ha a relációs 
modellben indexek segítenék a keresés munkáját.   

Az MOLAP rendszerekben az kockák egy vagy több dimenzióval is 
rendelkezhetnek, a dimenziók számára csak a kiválasztott DW rendszer ad 
megszorítást.

Az eddigiekben  említett adatkezelési tipusok áttekintésére álljon itt egy 
összehasonlító táblázat, mely az egyes tárolási módok jellegzeteségének 
kiemelésében segíthet.


Jellemző	OLTP		ROLAP			MOLAP
--------------------------------------------------------------------------
műveletek	DML		jelentés		analízis
--------------------------------------------------------------------------
felület		rögzített	felhasználó által 	felhasználó által
				definiált		definiált
--------------------------------------------------------------------------
érintett 
adatmennyiség	alacsony	nagy			nagy, közepes
--------------------------------------------------------------------------
adatok szintje	részletező	közepes			összegző
--------------------------------------------------------------------------
adatok kora	aktuális	vegyes			aktuális, korábbi 
							és jövőbeli
--------------------------------------------------------------------------
orientáltság	rekord		rekord			tömb, kocka
--------------------------------------------------------------------------



A MOLAP rendszerek megvalósításának részleteteire most nem térünk ki, csak két 
sajátosságot kívánunk kiemelni, melyek egyediek az MD modellre nézve, a 
relációs modellben nem találkozhattunk hasonló szerkezettekkel.

Az egyik újdonság az MD modellt megvalósító fizikai struktúrában a kapcsolatok 
tárolásának mechanizmusa. Az MD rendszerben a kapcsolódó rekordelőfordulások 
között  a pointer mechanizmussal történik a  kapcsolat tárolása. Azaz egy 
rekordból a pointer értéke alapján közvetlenül meghatározható a kapcsololódó 
másik rekord poziciója, ami sokkal gyorsabb elérést tesz lehetővé. 

A pointereknél az előnyőket elismerve, hiányosságként szokták felhozni, hogy 
rugalmatlanok, azaz ha megváltozik a tárolási mechanizmus, akkor módosítani kell 
a megadott pointereket is az új pozicióknak megfelelően. Ha egy objektumra több 
helyről is mutatnak, és az objektum poziciója megváltozik, akkor ez számos 
pointer  módosítását fogja maga után vonni. E módosítási munka könnyítésére egy 
kétszintű pointerezért szoktak megvalósítani, mely azt jelenti, hogy minden 
objektumnak lesz egy állandó postafiókja, s a kapcsolódó objektumok erre a címre 
mutatnak, míg a postafiókan egy újabb pointer található az aktuális tényleges 
címre.  Ezáltal az objektum áthelyezésekor csak egy helyen, a postafiókban kell 
módosítani a pointer értékét. 

Az adattárházak esetén a pointerezés másik sajátossága, hogy egyetten pointer lánc 
nem elegendő, mivel egy objektum cella több dimenzióhoz is kapcsolódik, s 
mindből elérhetőnek kell lennie. Emiatt egy cellának minimum annyi pointer 
láncban kell benne lennie, amennyi a kockához tartozó dimenziók száma, ha 
hatékony elérést kívánuynk biztosítani.

A MOLAP rendszerek másik, kiemelendő sajátossága, hogy a lekérdezések 
meggyorsítására még egy másik trükköt is bevet. A trükk abban áll, hogy a 
lekérdezésekkor megpróbálja a  hosszadalmas elemi műveleteket elkerülni, s 
amennyire csak lehet, előree kiszámított félkész számítási eredményeket használ 
föl. Természetesen kész válaszokat nem tudhatja az összes lehetséges lekérdezési 
utasításra, a könnyítés az egyes részeredmények terén érhető el.  Erre az egyes 
aggregációs lépésék terén van leehtőség. Vagyis az OLAP rendszer megpróbálja 
az egyes összegzési, átlagszámítási lépéseket (pl. az egyes termékek 
összaforgalma, az egyes hónapok összforgalma) előre kiszámítani, így amikor 
szükség van a részeredményre egy komplex lekérdezés során, akkor az érték 
rögtön rendelkezésre fog állni, nem kell hosszadalmas elemi számításokat végezni.

Természtesen az egeys előre kiszámított értékek csak addig lesznek jók és 
érvényesek, míg az adatbázisban nem történik változás. Ha ugyanis az elemi 
adatok  valamelyike módosul, akkor a kiszámmított aggregációs érték is 
módosulhat, emiatt újra kell értékelni a részereményt.

Mint látható ez a mechanizmus igen hasznos az ad-hoc lekérdezések 
vonakozásában, viszont lassítja az adatmódosítások végrehajtását. Az OLAP 
esetében viszont az segíti elő e mechanizmus használatát, hogy a módosítások 
viszonylag ritkábban és ellenőrzött körülmények között  mennek végbe, másrészt e 
módszer is rugalmasságot mutat abban a tekintetben, hogy az előszámítások 
mértékének tetzőleges szintje is elképzelhető. Vagyis lehet olyan eset, hogy az 
összes elképzelhető aggregációs értéket előre kiszámoljuk, ekkor teljes az 
előszámítás  mértéke, míg a másik végletet az jelenti,ha semmit nem számolunk 
előre, minden aggregációs értéket a lekérdezés feldolgozása során számítunk ki. E 
két változat között tetszőleges előszámítási szint képzelhető el. Hogy melyik 
szintet érdemes választani, az az alkalamzás jellegétől függ, aholz gyakoribb a 
módosítás és kevesebb a lekérdezés, ott a kisebb szintet, ahol viszont ritkább a 
módosítás és gyakoribb a lekérdezés, ott a ngyobb szintet érdemes kijelölni. A 
következő ábra a fellépő időköltségeket mutatja a módosításra, a lekérdezésre és a 
kettő eggyütesére különböző előszámítási szint mellett. Az ábrából jól látható, 
hogy az optimális szint valahol a két szélsőérték között helyezkedik el.

 


Az előbb elmondottakból következően az MOLAP rendszerek számos olyan 
kiegészítő adatelemet tartalmaznak,emlyek a lekérdezés hatékonyságának a 
növelésére szolgálnak. Ezen elemek azonban mind jelentős helyigénnyel 
rendelkeznek. Így például a letárolandó előszámítások és indexstruktúrák 
darabszáma a dimenziók számával hatványozottan nől, hiszen N dimenzió esetén a 
lehetséges aggregációs nézetek (hogy mely diomenziókra vonatkozzon az 
aggregáció), az N elemű halmaz részhalmazainak darabszámával egyezik meg, így 
étéke 2N-el arányos. Tehát a dimenzió kismértékű növelése is jelentősen megemeli 
a szükséges előszámnítási mennyiségek darabszámát. Emiatt a teljes MOLAP 
elterjedésének e méretkorlátok biznyos határt szabnak. E korlátot jól mutatja a 
következő ábra,melyből kiolvasható, hogy az igazi MOLAP rendszerek jelenleg 
még csak a kisebb dimenziószámú és kisebb méretű alkalmazások esetében 
bizonyul elsődleges eszköznek.


  


Az adattárházakra visszatérve nézzük meg, mik azok a speciális fogalmak,  
műveletek, melyek az adatárház fogalmához társíthatók és kapcsolhatók. Ítt az 
adatárház rendszerén belül lezajló speciális tevékenységek jelentését tekintjük át 
röviden.

Data Cleaning:
Az adatok tisztítása (data cleaning)  alatt azon tevékenységek értendők, mellyel az 
adatforrásból származó adatok olyan formát vesznek fel, mely már beültethető az 
adattárházba. E lépés fő nehézsége abban áll, hogy a DW nyitott szintre minden 
más rendszer felé, így igen heterogén könrnyezetből kell összegyüjtenie az 
adatokat. Az adatoknak nemcsak a forrása, hanem az adatértékek formátuma, sőt 
sokszor az adatelemek jelentése is igen eltérő lehet attól, amit a DW vár és 
tartalmaz. Az adattisztítás során a bejöző adatokat olyan formátumúra hozzuk, ami 
megfelel a DW követelményeinek. A tisztítás során a bejövő értékeken  különböző 
szintű ellenőrzési tevékenységek  is végrehajthatók:  
	- data migration: az adatokat egy egyszerű értékhelyettesítési szabállyal 
hozzuk a DW által megkívánt formátumra (pl. a nem mezőnél a Y értéket az N 
értékkel kell helyettesíteni). Ekkor feltehető, hogy minden bejövő adatnak van 
egyértelmű megfelelője a DW-ben és az adatértékek is a DW által megkívánt 
alakra konvertálhatók.
	- data scrubbling esetén az egyes elemi adatok ellenőrzésénél egy szabállyal 
leírjuk, hogy milyen formai követelményeknek kell eleget tenni egy értéknek, s a 
bejövő értékeknél ellenőrzésre kerül, hogy megfelelnek-e a kívánt 
követelményeknek. 
	- data auditing során a tárolt adatok alapján bizonyos belső korrelációkat tár 
fel a rendszer, s figyeli, hogy a bejövő adatok mennyire felelnek meg a feltárt 
szabályszerűségeknek. Ha egy bejövő adatérték lényegesen eltér a felállított 
szabálytól, akkor a rendszer figyelmeztető üzenetet küld a programozó számára az 
észlelt hibáról. 

Loading:
Az adatok betöltése (load) többet jelent mint egyszerű adatbevitelt. A betöltési  
tevékenység magja az adatérték  elhelyezése az adattárházban. Mint ahogy a 
RDBMS esetében egy adat beszúrása is több elemi tevékenységet válthat ki, így itt  
is egyéb kisérő tevékenységeket kell elvégezni ahhoz, hogy a DW a szabályainak 
megfelelően tartalmazza az új értéket. A betöltés folyamán az alábbi kiegészítő, 
kisérő tevékenységekre lehet szükség:
  		- az adatok integritásának ellenőrzése. 
		- az adatértékek rendezése, a megfelelő tárolási pozició kikeresése
		- az adatértékek indexelése, azaz az indexek aktualizáslása
		- a kiszámítandó értékek frissítése


Refresh:
Az adattárház frissítésének folyamata. A frisssétés során az adatforrásokban 
bekövetkezett változások átkerülnek a DW-be is. A frissítés során a DW tartalma 
megváltozik, így az egy módosítási tranzakcióként jelenik meg. A frissítés  fő 
kérdése, hogy mikor és hogyamn történjen. A túl gyakori frissítés nagyon 
lefoghatja a lekérdezési műveleteket, míg a ritka frissítés esetén az adatértékek 
elavulttá válhatnak. A leggyakoribb megoldás a napi vagy heti frissítési 
mechanizmus. A frissétés módjára ugyancsak számos variáció létezik. A teljes 
frissítés nagyon költséges,de biztos és egyszerű megoldás. Az inkrementális 
frissítétésnél nagyobb az adminisztrációs igény és bonyolultabb a frissítés 
folayamtának a megszervezése, viszont az igényelt időtartam lényegesen 
csökkenthető.    

A multidimenzionális adatmodell alapvető tárolási egysége a  kocka. Ebben 
foglalnak helyet a  vizsgált mennyiségek és kapcsolataik. A kocka azonban nem 
egy homogén szerkezet, hiszen számos szerkezti eleme van,, mint a cellák és az 
élek is. E szerkezeti elemek leírására a multidimenzionális adatmodell saját 
terminológiát használ, melyet most mi is röviden átveszünk. 

Cella,:
A kockában  a vizsgált adatmennyiséget tartalmazzó tárolási egység. A forgalom 
pédánál maradva egykonkrét eladás forgalmi adatait leíró tárolási egység a cella. A 
cellában elemi és összetett adatok is szerepelhetnek. A kocka a cellák szabályos 
rendszerét tartlamazza.

Dimenziók:
a kocka éleihez rendelt mennyiségek, amitől a cella értékek függnek. Egy kocka 
több dimenziót is tartalmazhat. Egy cellának a kockéában elfoglalt helyét a 
dimenziók segítségével lehet megadni. 

Változó:
A cella leírására szolgáló összetett adatstuktúra egy eleme. Azon adatokat foglalja 
megába, melyekre a lekérdezéseknél, a dimenziók függvényében szükség lehet. A 
forgalom esetén, aholegy cella egy vásárlást reprezentál, a cella dimenziói lehetnek 
például az eladott mennyiség és az aladási ár.

Attributumok:
A dimenziók jellemzői, leírói adatai jelenti. A dimenziók ugyanis nem pusztán 
egyetlen egy elemi adattal lírható mennyiségek lehetnek, hanem tetszőlegesen 
összetett struktúrák is. Ekko egy ettributum a dimenzióhoz tartozó mennyiség egye 
mezőjét azonosítja. Igy egy termék dimenzió esetén a terméket leíró adatok, minmt 
pl. a termék neve, egységára, stb, egy-egy attributumot jelentenek. 

Tag:
A  dimenzió egy értékelőfordulása, azaz egy koordináta érték a dimenzió él 
mentén. A termék dimenziónál egy konkrét terméket tagnak nevezünk. Minden 
cellához egyértelműen tartozik a egy tag n-es, ahol n a kockához definiált 
dimenziók darabszámát jelenti. 

Hierarchia:
Adott dimenzió esetén az egyes  tagok közötti heirarchikus kapcsolatrendszert irja 
le. Az idő dimenziót véve, egy időszakasz értéket sokféleképpen megadhatunk. Így 
például megadhatjuk a mostani órát, a mai napot, január 5-ét, aezen hetet, Február 
hónapot, tavaszt, 1995-öt. Ezek az értékek,mint látható nem egészen 
egyenrangúak, hiszen vannak olyan értékek, melyek magukba foglalalnak más 
értékeket. A mai hónap pédául magába foglalja a mai napot. De például a tavasz 
nem foglalja magába a november hónapot. Az idő esetén az értékek között egy 
hierarchikus  struktúra építhető fel, mely megadja, hogyaz értékek hogyan 
tartalmazzák egymást. 

A felvázolt hierarchia más mennyiségek, diemnziók esetében is elképzelhető. A 
hagyományos rendszerekben minden érték önááló, független érték volt, az 
MOLAP segítségével azonban egy hierarchikus érték viszony építhető fel, amely  
nagyban segíti a kérdések feltevésénél  a finomítás vagy az összevonás műveleteit 
(vagyis amikor tavaszról áttérek Márciusra).

A következő ábra a fenti fogalmakatr foglalja össze a forgalom adatbázisra 
vonatkozólag.



 


Az adattárházakhoz nemcsak az adatelőkészítés, betöltés és tárolás során fordulnak 
elő egyedi, DW specifikus műveletek, hanem a lekérdezési tevékenység során, az 
információs réteg keretén belül is. A lekérdezés során a hagyományos aggregációs, 
elemzési funkciók néhány, a multidimenzionális  modellhez kapcsolódó  
tevékenységgel is kibővülnek. 

A MOLAP lekérdező felületének jellemzője, hogy a lekérdezések rendszerint csak 
egy vagy két diemnzió mentén történnek, amikoris az adatok egy grafikon vagy 
egy táblázat segítségével megjeleníthetők. Mivel egy háromdimenziós 
eredményhalmaz megtekintése és kijelzése igencsak nehézkes és körülményes 
lenne, s igen nehezen lehetne átlátni, ezért a részletes cellaadatokra vonatkozó 
lekérdezéseknél a teljes kockának egy maximum kétdimenziós szeletét igénylik a 
felhaználók. A kocka különböző szeletei a különnböző felhasználói igényekeknek 
felel meg. A forgalom példánál maradva például egy terméknek a különböző 
régiókban és időszakokban eladásai a kiválasztott termék termékmenedzserének az  
érdeklődési körébe tartozik. Ebben a nézetben nem szerepelnek a többi termékre 
vonatkozó adatok, hiszen azok egy másik termékmenedzser számára lesznek 
fontosak. Hasonlóan a kockának egy adott régió szerinti  leszűkítése a regiót 
vezető menedzser számára adnak értékelendő információt. A kockák különböző 
szempont és hatáskör szerinti felbontását mutatja be a következő ábra.

 


A kocka szeletekre bontásának műveletét az MOLAP angol terminológiájában 
'slice and dice' műveletnek nevezik. 

Az egyes dimenziókhoz tartozó hierarchiák lehetővé teszik, hogy adott tagérték 
esetén az oda vonatkozó összesített adatokat kifejtsük az értékek egy alacsonyabb 
szinjén is. Így például előbb a forgalomnak a területi bontását nézve, feltúnhet egy 
régió, ahol kimagaslóan magas volt a forgalom. Ekkor a régiónak a városokra való 
bontásával információt nyerhetünk arról, hogy ez a forgalom növekedés 
egyenletesen, minden városnál bekövetkezett-e vagy vannak olyan városok, 
melyeknek köszönhető e nagy fogalom növekedés. Az egy adott tagértékre 
vonatkozó aggregált adatoknak a tagérték alatt elhelyezkedő  értékekre történő 
dimenzió finomítását  angolul  'drill down' műveletnek nevezik. E művelet során 
növeljük a aggregációs szint finomságát, azaz egyre mélyebbre kerülünk a 
dimenzióhoz tartozó hierarchia szintjén is. A dimenzió finomítás eredményeként 
az induló szint tagértékekei helyett az eggyel lentebb elhelyezkedő szint tagértékei 
kerülnek fel a dimenzió tengelyekre.

A dimenzió finomítás, a lefelé bontásnak az ellentetje a dimenzió tömörítés, 'drill 
up' művelet, mely során egy részletesebb felbontású statisztikából egy durvább 
felbontású statisztikára lépünk át. Ígyenkor egy adott értékszinten megadott 
felbontásról felfele, egy összesítettebb értékszintre lépünk a dimenzióhoz tartozó 
értékhierarchiában. 

A lefele lépésre ad egy példát az alábbi ábra, melyben az idő dimenziót véve, a 
havi bontásban megadott statisztikáról áttérünk a heti felbontásban megadott 
statisztikára, vagyis  hónapok szintjéről az elemzés során átlépünk a heti szintre. A 
nyíl tehát egy drill down műveletet jelöl, míg a fordított irányú nyil egy drill up 
funkciót ad meg.

 

Egy másik speciális művelet a  kocka átdimenzionálása. Az átalakítás során a 
kocka eredeti cella értékeinek segítségével egy módosított kockát hozunk létre, 
melyben csökkentjük a dimenziók számát, s az új kocka celláinak értékét az 
eredeti cella értékek aggregációjával származtatjuk. A forgalom példát 
felhasználva az a művelet, amikor olyan új kockát hozunk létre, melyben már csak 
két dimenzió, az idő és régió fog szerepelni, s egy adott időszakasz és régió 
előforduláshoz tartozó cella az eredeti kocka ezen poziciójára vonatkozó termék 
oszlop összesített foprgalmát jelenti, egy ilyen átdimenzionálást reprezentál. 
Vagyis összesítve az összes termékre vonatkozó forgalmat egy adott időszakasz és 
régió esetén megkapjuk az új kocka ugyanezen idő és régió tagjaihoz tartozó cella 
tartalmát. A következő ábra az átalakítás sémáját szemlélteti.

 


A multidimenzionális adatmodell fontosabb struktúrális és műveleti elemeinek 
áttekintése után rátérünk az MD modellek fejlesztésének kérdéseire. A modell 
fejlesztés fontosabb lépéseit kiemelve megadjuk a tervezés fázisait, és a tervezési 
lépések szokásos sorrendiségét. Ez az ismertető nem olyan egzakt és kimerítő, 
mint a relációs modellben tanult fejlesztési módszertan, célja inkább csak ízelítő 
bemutatása a tervezés folyamatáról.

A tervezés első lépése, hasonlóan az álatános  információs rendszerekhez,  itt is a   
lehetséges információigények meghatározása és elemzése. Ennek során kell 
feltárni az adattárházban elhelyezendő adatelemeket, a felhasználók igényeinek 
elemzésével. Meg kell győződni arról, hogy a megkívánt információ igények 
mindegyike kielégíthető a modellbe bevont adatelemekkel.

A tervezés második lépése a  normalizált SDM modell felépítése. Ennek során egy 
kiválasztott szemantikai modell segítségével felvázoljuk a modellben előforduló 
egyedeket és  a köztük fennálló kapcsolatokat. A modell leírásához 
felhasználhatjuk a már ismert SDM rendszereket, így például az ER modell is 
alkalmazható e célra.

A tervezés harmadik lépése a tényadatok, vagyis a cellákba tárolandó adatelemek 
kiválasztása. A tényadatoknak olyan mennyiségeknek kell lenniük, melyek értéke 
igen vontos, meghatározó a vizsgált problématerület szempontjából, s amelynek 
más mennyiségektől való függését vizsgáljuk. 

A következő lépés a dimenziók feltárása. Ennek során kiválasszuk azon 
mennyiségeket, melyek meghatározzák a cellák tartalmát. A cellaértékeknek ezen 
mennyiségektől való függőségénekl a vizsgálata,eélemzése lesz majd elkérdezések 
fő célja.

Eztkövetően kidolgozásra kerül az egyes dimenziókhoz tartozó  hierrachia 
rendszer. Fel kell deríteni, hogymely dimenzióknál van lehetőség és szükség a 
többszintű tagértékek kijelölésére. Ha definálható ilyen értékhierarchia, akkor meg 
kell határozni az egyes szinteket leíró mennyiségeket, az egyes szintek 
azonosítását.

A dimenziók vizsgálatának utólsó lépése az attributumok meghatározása. Ennek 
érdekében meg kell vizsgálni, hogy milyen információkra van szüksége a 
felhasználónak az egyes dimenziókat illetően, vagyis milyen struktúrát célszerű 
felvenni a dimenzió tagértékek tárolására. 

A tervezés utólsó lépése a változók megadása, vagyis a cellában tárolt tényadatok 
struktúrájának leírása. A struktúra szerkezetéhez  a felhasználói igények elemzésén 
keresztül juthatunk el.  

Az elkészült leírás már alkalmas arra, hogy elviekben megalkossuk a MD-t alkotó 
kockákat, létrehozzuk a multidimenzionális adatmodellt. Ugyan a DBMS-ek döntő 
töübbsége egy szöveges parancsnyelv segítségével tartja a kapcsolatot az 
alkalmazásokkal, így egy szöveges parancsnyelvet kell majd alkamazni a 
multidimenzionális modell megadására, de a létrehozott modell nemcsak a DBMS 
számára fog információt hordozmi, hanem más hiumán személyeknek is.

Az elkészített modellt tehát célszerű olyan alakban is megadni, mely a többi 
fejlesztő és a külső olvasó számára is könnyen áttekinthető és érthető. Erre a célra, 
egy grafikus, funkciójában az ER modellhez hasonló formátum alkalmazása  tűnik 
a legalkalmasabbnak.

Az igényeknek megfelelően létre is jöttek ilyen grafikus séma leíró nyelvek, 
melyek  között a két legismertebb a csillag modell és a hópehely modell. 
Mindkettő az elkészített  leírás alakjáról kapta a nevét. A két modell azonos 
alapokon és formalizmuson nyugszik,  az egyedüli különbség a kétféle leírás 
között, hogy  a csillag modellben nincs lehetőség a dimenziókhoz tartozó 
hierarchiák definíálására, míg a hópehely modellben a hierarchiákat is kijelezzük. 
E két modell formalizmusát egy-egy példán keresztül mutatjuk be. 

A tényadatok vonatkozzanak a már ismertett forgalom értékekre, tehát egy cella 
egy vásárlás adatait fogja tartalmazni. A cellában szereplő forgalom leírására 
változóként az érték és darabszám mennyiségeket adjuk meg. A forgalom értékét a 
következő dimenzióktól való függőségében vizsgáljuk:  időszak, eladó, termék és 
régió. Az áru esetén egy termékkategóra-termék kétszintű hierarchiát definálunk, 
míg a regió esetén az ország-megye-járás szinteket hozzuk be, azaz itt már 
háromszintű a dimenzió hierarchia.  Az egyes dimenziókhoz a következő 
attributumokat csatoljuk:
	termék: termékkód,megnevezés,egységár
	időszak: év, hó, nap
	eladó: név, fizetés
	régió:  név

A modell most egyetlen kockát tartalmaz, melynek grafikus leírása a csillag 
modell segítségével a következő alakot ölti.


 

A grafikus leírásban szerepel minden MD struktúra elem, kivéve a dimenzió 
hierarchiákat. A tényadatok, vagyis a cella struktúra  egy dupla vonallal keretezett 
téglalapban szerepel, felül a mennyiség azonosítása, alatta a változók listája. A 
dimenziók normál téglalapban kerültek megadásra, itt is fenn a mennyiség, majd 
alatta az attributumok helyezkednek el. A felvázolt modell egyetlen egy kockát 
reprezentál.
 
A hópehely modell annyiban különbözik az előző modelltől, hogy itt már a 
dimenzió hierarchiák is megjelennek. 

 

A hópehely modellben dimenzió hierarchia több szintű is lehet. A dimenziókhoz 
tartozó attributumok rendszerint csak a hierarchia alján elhelyezkedő  elemeknél 
jelenik meg. 

A gyakorlatban számos olyaneset van, amikor az adattárházat nem újonnan, a 
semmiből kell felépíteni,hanem már van valamilyen előzménye az 
adatrendszernek. Ez az alőzmény legtöbbször egy relációs OLTP rendszerben 
testesül meg. A következőkben azt nézzük át, hogy milyen sajátságai vannak egy 
relációs modellből induló tervezésnek. 

A tervezés ekkor az első lépésekben különbözik csak a normál, tiszta lappal induló 
tervezéstől. Az ilyenkor használatos lépések a következők:

	- relációs modell elemzése, a fűüggőségi kapcsolatok feltáráa
	- modell kiterjesztése a szükséges új elmekkel
	- tényadatok kiválasztása
	- dimenziók meghatározása
	- dimenzió hierarchia kijelölés
	- attributumok megadása
	- változók meghatározása
	- séma felrajzolása

A tervezés menetének bemutatására vegyünk egy példát, amelyben adott egy 
induló relációs adatmodell a következő szerkezettel:

	termék[tid,megn,ear,szin]
	tétel[rid,tid,db,ar]
	rendelés[rid,datum,vid,ertek]
	vevő[vid,nev,cim,forg,uid]
	ügynök[uid,nev,fiz,eid]
	egység[eid,cim,hely,vezeto]
	bemutató[uid,datum,letszam,forg]

A rendszer egy ügynök hálózaton keresztül értékesítő cége egyszerűsített 
adatmodelljét tartalmazza. Ebben  a rendszerben szerepelnek a termékek, a 
rendelések és a rendelési tételek, a vevők, az ügynökök és a megtartott bemutatók 
adatai.

Első lépésben a felvázolt relációs modellt kell elemezni, hogy feltárjuk a 
tartalmazott egyedeket, kapcsolataikat és a tulajdonságokat. A kapcsolatok 
feltárásánál az elsődleges kulcs és kapcsoló kulcs alapján megjelenő függőségeket 
kell meghatározni. A példában például egy rendelési tétel meghatároz egy 
terméket, hiszen minden tétel rekordban szerepel egy kapcsolókulcs a termékek 
táblára vonatkozóan. A többi kapcsolat hasonló módon történő felderítése után 
kapott függőségi grafikont az alábbi ábra mutatja.

 

Ezután kibővítjük a modellt az újonnan jelentkező adatigényekkel. Ha most az 
időszak és terület jelenik m,eg mint új fogalom, akkor az előző ábra következő 
alakra módosul.

 

A tényadatok kiválasztásánál olyan adatokat célszerű kiemelni, melyek 
előfordulásainak számossága magas, és melyek  a függőségi rendszerek 
centrumaibanhelyezkednek el. A példánkban két ilyen centrumot célszerű 
kiemelni:

	- tétel
	- bemutató.

A mintapélda tehát két kockát fog tartalmazni, melyek celláiban a rendelési tételek 
illetve a bemiutató adatai lesznek.

A dimenziól kiválasztásánál a fő irányelvek a következőkben foglalhatók össze:
	- az egyedbe mutasson függőség
	- viszonylag kisméretű
	- nem cella

A következő dimenziókat célszerű lefektetni az egyes kockákhoz.

	rendelési tétel:
		- termék
		- vevő
		- régió
		- időszak
		- ügynök
		
	bemtató
		- ügynök
		- időszak
		- régió

Az dimenzió hierarchiák megadásánál a régió, az időszak, az ügynök és a termék 
vonatkozásában lehetséges szintekre vonást végezni:
	
	termék:
		kategória * termék
	eladó:
		egység * ügynök
	idő:
		év * hó * nap
	régió
		megye * város
	
A hierarchia bevezetése miatt egy új fogalom került be a modellbe, az eladó, 
amely megába foglalja az ügynököt és az egységet is.
  
Az attributumok és a változók kijelölésénél a relációs modellben megjelenő 
mezőkre alapozunk. Természetesen azt nem lehet megkövetelni, hogy a relációs 
modellben megadott mezők pontosan egyezzenek  meg a felvett attributumokkal. 
Ez azért sem várható el, mivel a multidimenzionális modellből kihagyhatók az 
olyan mezők, melyekre az újabb elemzés szerint nincs már szükség, illetve 
kerülhetnek be olyan attributumok is, melyekre viszont szükség mutatkozott. Így 
például a dimenzió hierarchia megvalósítása miatt is jöhetnek be új mennyiségek 
az adatmodellbe.       

Az induló relációs modell és az elemzés alapján a változók listája a rendelési 
tételnél a
	- darabszám
	- ár
míg a bemutató esetén a
	- létszám
	- forgalom
mennyiségeket tartalmazza.

Az attributumok listájába a következő elemek kerülnek be a forgalomhoz tartozó 
kocka esetében:
	termék:
		- ear (egységár)
		- megn (megnevezés)
		- szín
		- kategória
	vevő:
		- név
		- cím
		- forg (forgalom)
	régió:
		- megye
		- város
	idő:
		- év
		- hó
		- hét	
	eladó
		- név
		- fiz
		- egység

Az elmondottakhoz hasonlóan származtathatók a bemutató kockához tartozó 
dimenziók attributumai is. 

Az így elkészült sémát előbb a csillag, majd a hópehely modellben mutatjuk be.


 


 

Az elkészült hópehely modell már a létrehozott dimenzió hierarchia elemekkel 
kibővítve mutatja be a létrehozott multidimenzionális adatmodellt, pontosabban 
annak rendelési tétel kockáját. A bemutatóhoz tartozó hópehely modellt is 
hasonlóan készíthetjük el, kifejtve az a régióhoz, eladóhoz és az időszakhoz 
tartozó hierarchiát. A modellből is megfigyelhető, hogy attributumokat csak a 
hiararchia aljánelhelyezkedő mennyiségekhez szoktak rendelni.  

 

Az elkészült multidimenzionális modell valójában még csak egy elvont modell, 
mely közvetlenül nem használható fel  MOLAP objektumok létrehozására. A séma 
funkcinálisan egy relációs modellhez hasonlít, amely szintén nem alkalams 
közvetlenül az RDBMS objektumok létrehozására. Mint ahogy az RDBMS is 
rendelkeznek egy, a relációs modellt leképzeő nyelvvel, az SQL-lel a tényleges 
RDBMS tevékenységek végrehajtására, az MOLAP rendszerekhez is tartozik egy 
szöveges parancsnyelv, melyben a séma elemeket az MOLAP számára ios érthető 
formátumban lehet leírni. Az Oracle Express esetén például a bemutatóhoz tartozó 
kocka definiálása, az alkotó elemek megadása után a következő utasítással 
történik:

	DEFINE bemutató VARIABLE DECIMAL 

Megfigyelhetjük, hogy az alkalmazott szintaktika sok közös vonást hordoz az 
SQL-ben megismert szintaktikával. A minta utasításban a bemutató az 
ténymennyiség, a cella tartalma, míg a kocka dimenziói az időszak, régió és eladó 
mennyiségek lesznek.

A MOLAP rendszerek felhasználó által is érzékelhető előnye, a lekérdezés 
gyorsabb végrehajtása  mellett, a lekérdezések egyszerűségében  nyilvánul meg. A 
MOLAP egy céloreinetált, speciális lekérdező nyelvvel rendelkezik, amely az SQL 
eleminek tekinthető műveletei mellett a bonyolultabb elemzési tevékenységeket is 
magába foglalja. Így például igen egyszerű formalizmussal lehet a lekérdezési 
tartományt kijelölni, illetve magát a lekérdezést elindítani. Azon lekérdező 
elemzések, amik a PL/SQL nyelvben több oldalas utasítássort igényelnének, a 
MOLAP lekérdező nyelvében egyetlen egy utasítással meghívhatók.