2004. augusztus

Nem végleges!

Összefoglaló az adattárházak témaköréről

/ Sidló Csaba, ELTE /

Tartalom:

1. Bevezetés

Data Warehouse, adattárház: az információtechnológia viszonylag frissen önálló életre kelt ága, kevesebb mint egy évtizedes múltra visszatekintő területe. Rohamléptekkel, egyszerre több irányzat mentén fejlődő, már bizonyított és kiforratlan technológiák halmaza, kevés elismert szabvánnyal, rengeteg kapcsolódó termékkel és szolgáltatással, sok kis, néhány nagyobb piaci szereplővel, valamint nem utolsósorban meggyőző piaci adatokkal.
De mit is jelent valójában az adattárház kifejezés?

A következőkben megvizsgáljuk az adattárház technológiák alkalmazásának mozgatórugóit, felhasználói körét, alkalmazásának környezetét. Induljunk ki ehhez először tetszőleges vállalatból valamely gazdasági tevékenységgel, versenyhelyzetben a többi hasonló vállalattal. A piaci kihívásokra, a dinamikusan változó gazdasági környezetre az adott vállalat lehetőségei szerint reagál, rövid- közép- és stratégiai céljainak megfelelően. Ezeket a reakciókat, lépéseket (akárcsak a célokat) a vállalat vezetése határozza meg. A vállalat vezetésének folyamata felfogható tehát (az egyik elterjedt vállalatvezetési modell szerint) döntéshozatalként, döntések sorozatainak meghozatalaként. A vállalat eredményessége a reakciók, vagyis a döntések minőségén, sebességén múlik. Érthető tehát, hogy a vállalatok (az egyébként mind kritikusabb) kihívásokra válaszképp mindinkább szeretnék ezeket a döntéseket és velük együtt a vállalat vezetőit, a döntéshozókat eszközökkel, módszerekkel támogatni, naprakész, jól használható információval ellátni. Egy adattárház megoldás megvalósításával ilyen, döntések információs hátterét biztosító adat- és tudásbázishoz juthatunk.

A vállalat működéséhez elengedhetetlenül szükségesek bizonyos adathalmazok, nyilvántartások. Ilyenek pl. a könyvelések, a számlázások, személyi nyilvántartások, stb. Ezek az adatok valamilyen formában (elektronikusan vagy akár papíron) mindig rendelkezésre állnak, de amellett, hogy a működéshez szükségesek, önmagukban még nem feltétlenül segítik elő a megfelelő döntéshozatalt. A megfelelő információk előállítását, szolgáltatását célozza meg többek közt a controlling (v. kontrolling) mint közgazdasági irányvonal, részfeladatként a vállalatirányítás folyamatának racionalizálásában, megfelelő információs alapra helyezésében. Másrészről, ugyancsak ezekre a célokra, csak információs technológiák irányából közelítve ezért jelentek meg a különböző döntéstámogató rendszerek (Decision Support Systems, DSS), melyek az információ-ellátás informatikai hátterét hivatottak biztosítani.
Gyakran rengeteg adat halmozódik fel a működési adatokból egy-egy vállalatnál. A vállalatoknak a kiélezett piaci versenyben törekedniük kell arra, hogy ez az adattömeg ne csak haszontalan ún. adattemetőként (data puddle) halmozódjon egyre nagyobb és nagyobb mennyiségekben, aminek fenntartása fölösleges költségeket jelent. Lehetőség szerint az adattömegekben rejlő információkat, összefüggéseket, trendeket, "tudást" ("knowledge") meg kell határozni, hiszen ezek konkrét piaci előnyökként realizálhatók (és így értéket képviselnek).

1943-ban Maslow angol szociológus megalkotta az emberi szükségletek hiearchiájának elméletét. Ez egy igen egyszerű elmélet, amely szerint az emeri szükségleteket alapvetőtől az önmegvalósító tevékenységek igényéig sorba rendezhetjük. A sor jellemzője, hogy a következő szintű igények csak akkor jelentkeznek, ha a hierarchiában alatta lévőt már kielégítettük. Így először az alapvető fizikai szükségleteknek megfelelően eszünk, iszunk, ezután foglalkozhatunk a biztonságunkkal, ha ez is teljesül, sorra jönnek a szociális, majd az önkiteljesítést szolgáló öncélú igények.
Ez a hierarchikus igény szép párhuzam egy tetszőleges vállalatnál jelentkező információs igényekhez, melyet az ábra szemléltet. (Információs igény alatt a vállalat irányításához szükséges adatokra, tudásra való igényt értem.) A piramis szintjeibe beírva az adott igényeknek megfelelő adatelőállítási módszer neve található.

1.ábra: Vállalati adatszükségleti hierarchia

A piramis alján foglalnak helyet a vállalat működéséhez feltétlenül szükséges adatok. (pl. számlák, szállítások adatai, megrendelések, gyártási adatok, stb.) A feljebb mind bonyolultabbá és összetettebbekké váló kérdésekre csak egyre összetettebb módszerekkel, technológiákkal lehetséges választ adni. Tulajdonképp a felső két-három szint stabil információszolgáltató háttereként születtek meg az adattárház technológiák.

2. Vállalatirányítási és döntéstámogató rendszerek evolúciója

60-as évek: Executive Information Systems (EIS)

• maiframe környezet, operatív rendszereken alapuló statikus lekérdezések, minőségi információszolgáltatás döntéshozóknak
• az OLTP környezeten belüli modulok, egységek

80-as évek: Management Information Systems (MIS)

• leginkább statikus beszámológenerálás
• hiearchiaszintek bevezetése a mutatószámokhoz (lefúrás, roll-up lehetséges)
• kliens-szerver környezet, GUI, Windows, Apple

1992: W.H.Inmon bevezeti az adattárház fogalmát úttörő munkájával

• redundáns adattárolás, a forrásrendszerektől elválasztva
• analízis célú adattárolás

1993: OLAP célok, követelményrendszer bevezetése (E.F.Codd)

• dinamikus, multidimenzionális analízis

3. Az adattárház koncepció

Próbálkozzunk meg az adattárház definíciójával. Bár mára a kifejezés értelmezésében viszonylag nagy az egyetértés, kisebb értelmezésbeli, nézőpontbeli különbségek még mindig jelen vannak. Nézzük először, hogy az adattárház elmélet két evangelistájának mondott űttörőnk Ralph Kimball és Bill Inmon hogyan is fogja meg a fogalmat: (Az idézett könyvek ([1][2]) egyébként egyelőre kiállták az idő próbáját, és még ma is a két alapműként tartják számon a témában - 1996 óta, ami persze nem nagy idő.)

Idézet Ralph Kimballtól: Data Warehouse: "The conglomeration of an organization's data warehouse staging and presentation areas, where operational data is specifically structured for query and analysis performance and ease-of-use." [2] Az adattárház fogalma itt tehát egy adott szervezet azon adatgyűjtő és szolgáltató részeit foglalja magában, ahol a működési adatokat újrastrukturálják riportkészítési, jó teljesítményű és egyszerűen kezelhető elemzésekhez. Kimball ezen definícióját főleg azért szokták kedvelni és idézni, mert sok mindent nem határoz meg, pl. az adattárház nem feltétlenül döntéstámogatási célú.
Ebből átmenetként foghatjuk fel a következő változatot (már nem Kimballtól), mely az adattárházat technológiák gyűjteményének definiálja: "A data warehouse is a collection of technologies aimed at enabling the knowledge worker (executive, manager, analyst) to make better and faster decisions." [6]

Kimball az adattárházat máshol egyszerűbben a vállalati tranzakciós adatok egy speciális, elemzési és beszámoló-készítési célra átstrukturált változatának tartja, egy speciális adatbázisnak. Ez az adatbázisként való megközelítés már csak egy pontatlanabb változata Bill Inmon általánosan elfogadott és az irodalomban leginkább idézett definíciójának:
"A data warehouse is a subject oriented, integrated, nonvolatile, and time variant collection of data in support of management's decisions." [1]

Nézzük végig az említett (elemzési céloknak alárendelt) jellemzőket!

• Subject oriented (tárgyorientált, tematikus, esetleg témaorientáltnak is szokás fordítani)
  Hagyományosan az alkalmazásainkat annak funkcióit, feladatait szem előtt tartva tervezzük, azok köré építjük. Az adattárház tárgy-orientáltságát, tematikus felépítését ehhez képest olyan értelemben szokás használni, miszerint most adott tárgyterületek köré, a meglévő és kapcsolódó adatokat szem előtt tartva ("data driven") tervezünk. Példaként nézzünk egy vállalatot, aki kábeltévés szolgáltatást nyújt. Hagyományos rendszerei megvalósítanak sok feladatot, a számlázás folyamatát, a beszerzést, a karbantartást és így tovább. Minden ilyen alkalmazás támogatott valamilyen saját adathalmazzal. Az adattárház építésénél azonban szeretnénk a meglévő adatokat a vevő szerint csoportosítva, összegyűjtve kezelni, vagy más hasonló tárgyterület köré csoportosítva látni (mint például az adás-kimaradások). Az adattárházban minden adatunkat ezek köré a tárgyterületek köré csoportosítjuk, gyűjtjük. Megjegyzem gyakran ezek a forrásrendszerek funkcióinak központi szereplői, mint pl. számlázási rendszerből a számlák, a raktárkészlet-nyilvántartásból a termékek, stb.

• Integrated (integrált)
  Az előző pontban említett tárgyorientált, adatvezérelt tervezéshez szorosan kapcsolódik az integráltság fogalma a következő értelemben: az adattárház az említett tárgyterületekhez kapcsolódó adatokat az érintett adatforrásokból szabványosított formára alakítva egy helyre gyűjti és egységbe rendezve kezeli.

• Nonvolatile (nem illékony, vagyis tartós)
  Jelenti ez azt, hogy az adattárházban jelen lévő adatok alapvetően változatlanok. Ha a forrásrendszer adatai változnának, az adattárház a változást követi, de úgy, hogy a bentlévő adatot megfelelő időbélyeggel (érvényességi idővel) látja el, majd felveszi az új állapotot is, megfelelő időbélyeggel. A bekerült adatok tehát tartósan meg is maradnak.

• Time variant (időfüggő)
  A forrásrendszereink adatai nagyrészt egy adott időre vonatkoznak, a jelen pillanatra, tehát, az adott érvényes állapotokat tárolják. Ehhez képest a megcélzott elemzések leginkább történeti adatokon és adatok idősorain használatosak. Az adattárház ennek megfelelően az adatokat időfüggően, az adatokat időpontok és időintervallumok szerint tárolják és kezelik, a forrásrendszerek változását nyomon követve. Például, képzeljünk el egy raktárkészlet nyilvántartást. Ennek adatai ha megjelennek az adattárházban, ott nyomonkövethetők és elemezhetők a raktárkészlet változásai.

Data Warehousing alatt értjük adott szervezet adatainak adattárház eszközzel való kezelésének folyamatát, az adatok keletkezésének helyétől indulva egészen az elemzési célú megjelenítésig.
"Data Warehousing is the process, whereby organizations extract value from their informational assets through the use of special stores called data warehouses." [3]
Ennek megfelelően az adattárház működése három fontos kulcsmozzanat köré szerveződik, ezek:

1. Adatkinyerés a tranzakciós (vagy más vállalat-működtetési) rendszerekből

2. A kinyert adatok átformálása riport (beszámoló) készítés számára

3. A riportok, beszámolók elérhetővé tétele a döntéshozók számára.

A Business Intelligence (BI), üzleti intelligencia fogalámát Howard Dresner (Gartner Group) definiálta 1989-ben, azóta általánosan elfogadott fogalommá vált. Olyan módszerek, fogalmak halmazát jelenti, melyek a döntéshozás folyamatát javítják adatok és ún. tényalapú rendszerek használatával. A "tényalapú rendszer" a következő alrendszereket foglalja magába:

• Vezetői információs rendszerek (Executive Information Systems)

• Döntéstámogató rendszerek (Decision Support Systems, DSS)

• Vállalati információs rendszerek (Enterprise Information Systems)

• Online Analitical Processing (OLAP)

• Adat- és szöveg-bányászat

• Adatvizualizáció

• Geográfiai információs rendszerek (Geographic Information Systems, GIS)

Az üzleti intelligencia fogalmát gyakran említik együtt az adattárházak fogalmával, mivel az lefedheti ezen részrendszereket, valamint kiszolgálhat ilyen rendszereket. Leginkább azonban tekinthetjük az adattárház megoldásokat az üzleti intelligencia megoldások egy szeletének.

4. Az adattárház architekrúra

Az adattárház megoldás mérete és célja szerint széles skálán mozog, ezekre szokás külön elnevezéseket használni.

Data mart (adatpiac): A data mart egy lokális, a vállalat valamely felhasználói csoportja, szakterülete számára készült, konkrét feladatot ellátó, kisebb adattároló és analizáló egységet jelent, amely már önmagában is adattárház funkciókat láthat el.
Operational Data Store (ODS): Az ODS a tranzakciós adatok egy olyan nagy részletezettségű gyűjtőheje, amit az adatok egyesítésére és tisztítására használhatunk, esetleg a teljes részletezettségű adatok elérésére.
Az adattárház fogalmat akkor használjuk, ha vállalati szinten lát el adatgyűjtő, adatszolgáltató funkciókat, ehhez általában több adatforrást felhasználva.
Extraprise Data Warehouse: Egy jövőbe mutató trend szerint az Extraprise DW olyan világméretű adatgyűjtő hely, ahol összefutnak Business to Business (B2B), Business to Customer (B2C) adatok.
Virtuális adattárház: Ez a fogalom már nem az adattárház méretével függ össze. Virtuális adattárházról akkor beszélünk, ha az operációs (forrás) adatbázisokon túl nem épül adatbázis az adattárház adatai számára. Az adattárház ekkor az operációs adatok megfelelő nézetére biztosít felületet. Hátránya a gyenge válaszidő-teljesítménye és az forrás adatbázisok folyamatos terhelése.

Ebben a pontban kicsit részletesebben foglalkozunk az adatok 3.2 pontban (Data Warehousing fogalma) leírt háromlépcsős útjának megvalósításával. Az adattárház felépítését, építőelemeit tekintve egy kliens-szerver rendszer. Jelenti ez azt, hogy a felhasználó egy kliensen keresztül kiszolgáló, kiszolgálók szolgáltatásait használja. A munkamegosztást tekintve a megvalósítások széles skálán mozognak, kezdve az egy gépen futó kliens-szerver párostól a sok gépre, különböző stratégiák szerint elosztott kliens-szerver rendszerekig. Ezeknek nézzük most meg alapvető változatait.

2.ábra: Architektúra típusok

5. OLTP és OLAP rendszerek

OLTP: On Line Transaction Processing, azaz online tranzakciófeldolgozás. OLTP rendszerek alatt értjük általában az adatbázis rendszerek hagyományos alkalmazásait. Ide sorolhatók pl. a raktárnyilvántartások, szállítási nyilvántartások, könyvtár kölcsönzési adatbázisa, számlanyilvántartó rendszerek, filmkatalógusok és így tovább. Központi fogalmuk a tranzakció végrehajtás, a következő értelemben: az adatbázis objektumainak állapotát a felhasználók konkurens módon végrehajtott és egyenkénti, kis tranzakciók gyakori végrehajtásával módosítják és kérdezik le.

OLAP: On Line Analitical Processing, az online analitikai feldolgozás. A kilencvenes évek elején erősödött fel az igény az elemző, analitikai alkalmazások iránt, és ezzel együtt egy egységes módszertan és követelményrendszer felállítására. 1992-ben megjelent E.F.Codd cikke, melyben bevezeti az OLAP fogalmát, és 12 pontban definiál egy általa felállított követelményrendszert. Ez a definíció az online analitikai rendszerekre az idők során általánosan elfogadottá vált.

Codd OLAP szabályai:

1. Multi-dimenzionális nézet

2. Transzparencia (itt most technikai részletek ismerete nélküli könnyű elérhetőség, tehát áttekinthetőség értelemben)

3. Elérhetőségek (jogosultságok) beállíthatósága

4. Állandó riportozási (lekérdezési) teljesítmény

5. Kliens-szerver architektúra

6. Általános dimenzió fogalom

7. Dinamikus ritka-mátrix kezelés (ez a multidimenzionális modell tárolására vonatkozik, megvalósításra megkötés)

8. Több konkurens felhasználó támogatása

9. Korlátozás nélküli dimenzióműveletek

10. Intuitív adatkezelés (a végfelhasználó számára)

11. Rugalmas riportozás (vagyis beszámoló-készítés, lekérdezés)

12. Korlátlan dimenziószám és aggregációs szint szám

Sajnos az is nyilvánvaló azonban, hogy Codd definíciója iránymutató ugyan, de ugyanakkor elég pontatlan. Különböző OLAP alkalmazás szállítók gyakran értelmezik különbözőképp Codd pontjait. Annyi azonban biztos, hogy az OLAP mindig magában foglalja adatok interaktív lekérdezését, melyet az adatok analízise követ. Központi fogalma az adatok multidimenzionális nézete, amire még részletesen kitérünk.
Az OLAP és az adattárház fogalmak erősen összefonódtak. Ennek oka, hogy az adattárház döntéstámogatási, információszolgáltató feladatát általánosan elfogadott módon OLAP elemzések és adatbányász feladatok információellátó feladataként értelmezhetjük, konkretizálhatjuk.

Szokás összehasonlítani az OLTP és OLAP alkalmazások tulajdonságait. Ezt megtesszük mi is, ld. ábra. Jól látszanak a követelmények közti különbségek. Mostanra általánosan elfogadottá vált az a nézet, miszerint a két rendszer különbözik annyira céljaiban, felhasználóiban, módszereiben, hogy érdemes az online elemző alkalmazásokat és rendszereket teljesen külön, független rendszerként megvalósítani.

2.ábra: OLTP és OLAP rendszerek összehasonlítása

6. Adatmodellezés

Az adatmodell kifejezést most a következő értelemben fogjuk használni: az adatmodell olyan fogalmak halmaza, melyek az adatbázis struktúrájának leírására használhatóak. A következőkben áttekintjük az adattárházzal kapcsolatos adatmodellezési módszereket.
A következő ábrán nem szerepelnek az OLTP rendszerek mellett más adatforrások. Ennek oka nem az, hogy az adattárház koncepciójába esetleg csak online tranzakciófeldolgozó rendszerek férnének bele mint adatforrások, a koncepcióba bármilyen ad atforrás belefér. Tetszőleges adatforrás viszont tetszőleges adatmodellel épülhet (gondolhatunk itt Excel táblázatokra, textfile-okra, vagy akár szöveges beszámolókra is), így erre most nem térünk ki. Az alábbi ábra az adat útját követve nevezi meg az adatok megfelelő nézeteit.

5.ábra: Adattárház: tároló a tranzakciós és OLAP feldolgozás között

Az adatbázis adatmodelljeit három kategóriába soroljuk:

1. A koncepcionális (vagy szemantikai) szintű adatmodellek a felhasználók adatleíró módszereit takarják, függetlenek a konkrét implementációtól.
2. A logikai szintű adatmodellek már függnek az adatbázisszervertől, de még mindig egy absztrakt, bár alacsonyabb rendű felhasználói nézetet biztosítanak.
3. A fizikai szint adatmodelljei már teljesen a konkrét adatbázis implementációtól függnek, azt írják le, hogyan is tároljuk fizikailag az adott adatokat.

6.ábra: Adatmodellezés rétegei

Az OLTP rendszerek nagy múltra tekintenek vissza, ennek megfelelően jól bevált modellrendszerekkel és jól kidolgozott eméleti háttérrel dicsekedhetnek (ez sajnos az adattárházakra még nem mondható el tiszta szívvel). A legelterjedtebb módszer a tárolandó objektumok leírására az Egyed/Kapcsolat diagramm (Entity/Relationship Diagram) ami aztán könnyen transzponálható az adatbázis relációs adatmodelljébe.

Ebben a pontban az adattárház felhasználóinak fogalmi, elméleti (conceptual) adatmodelljét tekintjük át. Egy adattárház felhasználói általában nem elsősorban informatikusok, informatikai, matematikai felkészültségük sem feltétlenül mély. A felhasználóknak éppen ezért biztosítani kell egy könnyen kezelhető, rugalmas felületet, mellyel anélkül, hogy technikai részletekben kellene elmerülniük, tetszőlegesen lekérdezhetik, elemezhetik adataikat. Ehhez biztosít egy általánosan elfogadott adatabsztrakciós módszert a multidimenzionális modell. (OLAP eszközök esetén a multidimenzionális modell követelmény.) Meg kell jegyeznünk, hogy a multidimenzionális modell fogalomkészlete erősen intuitív, általában nem definiálják absztrakt módszerekkel.

Tényadatnak (v. mutatószámnak, keyfigure, Kennzahl) nevezzük azokat mérhető, numerikus adatokat, melyeket elemezni és ehhez tárolni szeretnénk. (A koncepcionális modellben inkább mutatószám, későbbi adatbázis realizációknál inkább tény, tényadat néven szerepel.) Lehetnek hagyományos, vagy a közgazdaságtanból átvett mérőszámok. Ilyenek pl. az árbevétel, súly, eladott darabszám, nyereség, raktárkészlet, stb. A tényadatok általában additívak (pl. árbevétel), de lehetnek részben additívak vagy nem additívak is (pl. haszonkulcs).
Dimenziónak (v. egyszerűen jellemzőnek) nevezzük azokat a jellemzőket, tulajdonságokat, melyek szerint a mérőszámokat csoportosítani, jellemezni tudjuk. A dimenziók egymástól független jellemzői egy-egy tényadatnak. Dimenziók lehetnek pl. idő, hely, termék, alapanyag, szállító neve, raktár, költségnem, költséghely, stb. A dimenziók elemei a modellünkben hierarchiákba rendezhetők. Ilyen hierarchikus szerkezet lehet pl. idő dimenzió esetén egy év - hónap - nap felbontás, vagy egy egyetemi szoba esetén egy épületegyüttes - épület - emelet - szoba felbontás.
A következőkben az adatainkat úgy kezeljük, mintha egy n-dimenziós kocka pontjai lennének, ahol a dimenziók az itteni dimenzió fogalomnak megfelelnek (így az ő számuk az n). Az így felvázolt szerkezetet nevezzük adatkockának. A kocka név itt általános, az n-dimenziós adathalmazt is kockának hívjuk, nem csak a háromdimenziós esetet. Az adatkockákat független közgazdasági tárgyterületenként (ld.3.1.2, adattárház definíciója) készítjük. A kocka felbontása (granularity) alatt azt a legkisebb adategységet értjük, mely egységekben az adatot még elérhetővé szeretnénk tenni, tehát mikor az adat jellemezéséhez minden dimenziót felhasználunk. Adatkockánként több tényadat is szerepelhet, ekkor azonban mindegyikük granularitása meg kell egyezzen.
A következő példa egy nagyon leegyszerűsített háromdimenziós változatát ábrázolja egy nemzetközi kereskedő cég eladási adataiból alkotott adatkockának. A mutatószámok (tényadatok) a kocka celláiban helyezkednek el, egyértelműen azonosíthatók egy idő-termék-hely hármassal. Jelenti ez azt is, hogy a kocka legkisebb felbontásként a következő adatot tartalmazza: egy adott napon egy adott fióküzletben mennyi fogyott egy adott termékből, és ebből mennyi árbevétel keletkezett. Az ábrán szintén szerepelnek dimenziókhoz hiearchiák is.

7.ábra: Eladási adatok háromdimenziós adatkockája

Nyilvánvaló, hogy az adatkockánkat, hacsak nem 2 (esetleg 3) dimenziós, nem tudjuk megfelelően megjeleníteni a végfelhasználó számára. Az elemző, a felhasználó az adatkockának mindig csak egy megfelelő két dimenziós nézetét látja, láthatja, egy táblázat formájában. Jelenti ez azt, hogy a többi dimenzió szerint az adatok vagy fel lesznek összegezve, vagy egy konkrét értékre le lesznek szűrve a megjelenítéshez.

8.ábra: Példa riportozó OLAP felüleletre

Az adatkockákon végzett elemzésekhez kockák közti műveleteket használhatunk. Most megnézzük a leginkább elterjedt műveleteket. Ezek a műveletek az adatkockához egy új adatkockát rendelnek, céljuk általában az, hogy az új adatkocka az adatok egy olyan nézetét biztosítsa, ami az elemzési szempontunknak megfelel, esetleg táblázatként meg is jeleníthető.

• Aggregáció (roll up)
  Egy adott dimenziót kihagyunk a felbontásból, azaz a dimenzió elemein végighaladva az adatokat felösszegezzük. Előfordulhat az is, hogy a dimenzió felbontását nem teljesen hagyjuk ki, hanem áttérünk egy kisebb elemszámú hierarchia alkalmazására az adott dimenzióra. (Pl. városok helyett országok szerint nézzük adatainkat)

• Lefúrás (drill down, roll down)
  Ennek ellentéte, mikor egyre részletezettebben nézzük az adatokat. Pl. felbontjuk az összesített eladási adatokat termékekre, vagy a havi összesített adatokat lebontjuk napi adatokra.

• Pivoting
  Az adatkocka elforgatását értjük alatta. A kocka felbontása marad, csak a dimenziókat cseréljük fel, ezáltal más nézetét kapva az adatoknak.

• Szelekció (selection, filtering)
  Ebben az esetben egy adott dimenzió egy adott elemét kiválasztjuk, és a hozzá tartozó adatokat nézzük, a többi adatot pedig figyelmen kívül hagyjuk. Ilyen pl., ha kíváncsiak vagyunk egy konkrét fióküzlet bevételeinek alakulására.

• Szeletelés (slicing and dicing)
  Slicing alatt a szelekcióhoz hasonlóan azt értjük, mikor adott dimenziót fix értékkel lekötünk, és így nézzük a kocka nézetét, szeletét. Dicing alatt a kocka egy részkockájának kivágását értjük.

Fontos, hogy ezen műveletek elvégzésére a felhasználók másodperces nagyságrendű válaszidőket várnak. Általában 5 másodperc körülienek határozzák meg a még elfogadható OLAP műveleti időket!

A hagyományos adatbázis leírási módszereink (Entity/Relationship, UML) a multidimenzionális rendszer esetében nem használhatók megfelelően, vagy nem nyújtanak hasznos segédeszközt. Kénytelenek vagyunk lemondani az általánosan használhatóságról, hogy használható multidimenzionális leíró rendszert kapjunk. Itt most két ilyen formális leíró módszert nézünk meg.

ME/R modell: Multidimensional Entity/ Relationship Modell
A klasszikus egyed/kapcsolat modell egy kibővítése. A kapcsolat egy speciális "tényadat-kapcsolat", ezen keresztül kapcsolódnak a dimenzió-szintek, melyek között a nyíl jelzi a specializációs kapcsolatot. A nyilak nem alkothatnak kört, és a kisebb részletezettség felé mutatnak.

9.ábra: ME/R Modell példa

Célunk az előzőekben részletezett elvi multidimenzionális adatmodell megvalósítása adatbázis belső sémák szintjén. Itt már különbséget kell tennünk a sémák közt megvalósítás módja szerint, vagyis, hogy milyen adatbázisban szeretnénk tárolni az adatokat. A csoportok ezek szerint:
MOLAP: Multidimensional OLAP, azaz olyan OLAP megoldások, melyek saját speciális adatbáziskezelővel közvetlenül valamely multidimenzionális célstruktúrában tárolják az adatokat. Nagy hagyományokkal rendelkező megközelítés, szinte a relációs adatbáziskezelővel egyidőben megjelent a multidimenzionális elemzési célú tárolás: a 70-es évek elején két MIT hallgató fejlesztett ki egy modellt és működő rendszert, amely jóval később az Oracle Express termékcsalád alapját is képezte. Az adattárház séma ebben a csoportban tehát ezt a speciális multidimenzionális sémát jelenti.
ROLAP: Relational OLAP, azaz olyan OLAP megoldások, ahol az adatok tárolását hagyományos relációs adatbáziskezelővel végezzük. Itt a multidimenzionális megjelenést speciális relációs adatbázis sémákkal biztosítjuk. Elterjedtségére főképp rugalmasságára és a relációs adatbáziskezelők viszonylagos olcsóságára és megbízhatóságára, valamint a relációs tárolási technika elterjedtségére vezethető vissza. Az említett relációs adattárház sémák leginkább a csillagséma, hópehely séma, melyekre még visszatérünk.
HOLAP: Hybrid OLAP, azaz olyan hibrid megoldások, ahol az adatbáziskezelő biztosítja a hagyományos relációs tárolás lehetősége mellett multidimenzionális tárolási metódusokat is biztosítanak. Itt az előző kettőre jellemző adatbázis sémák mindegyike előfordulhat. Egyre inkább tendencia, hogy a relációs adatbázisok támogatják a multidimenzionális adattárolást speciális indexekkel, SQL bővítményekkel stb.

10.ábra: ROLAP-MOLAP rugalmasság összehasonlítás konkrét alkalmazásokkal

7. MOLAP architektúrák

MOLAP esetén külön kezeljük a dimenziók adatait és a tényadatokat.

Dimenziók: véges, rendezett lista a dimenziók elemeiről. Fontos, hogy a dimenzióelemek listája jól rendezett legyen.

Adatkocka: Egy n dimenziós kocka esetén az adatok egy n-dimenziós térben helyezkednek el, annak egy zárt részhalmazában a dimenzióértékek végessége miatt. Mivel a dimenziók diszkrét értékűek is, a dimenzióértékek a térben cellákat jelölnek ki. Ezek a cellák tartalmazzák a mutatószámokat. A dimenzióértékek által lehatárolt térrészt, azaz a kockát speciális indexstruktúrával látjuk el, aképp, hogy a a kocka minden egyes cellája be legyen indexelve. (Az index általában adott attribútumú sorok gyors elérését szolgáló struktúra.) A kockát eltároljuk a háttértárunkon, felépítjük az indexet, ami általában elfér a memóriában is, és ezt használva az adatok elérése jelentősen gyorsabb, mint egy sima relációs adatbázisban. Előny továbbá, hogy a struktúra jól illeszkedik a koncepcionális modellhez, fordítás nélkül alkalmazhatóak rá az OLAP műveletek.

Dimenzió hierarchiák: A dimenziók hierarchikus felépítését úgy kezeljük, hogy a hierarchia csomópontjait elhelyezzük a dimenzióelemek között és összesített adatokat rendelünk hozzá.

11.ábra: Hierarchia MOLAP megoldása három dimenzió esetén

Aggregált adatok: Aggregált, felösszegzett adatok kezelése MOLAP architektúra esetén akkor sem jár elfogadhatatlan válaszidővel, ha külön nem foglalkozunk összegek tárolásával, mégpedig a gyors adatelérés miatt. Ezen túlmenően előre is definiálhatunk a kockákban aggregációs szinteket, hasonlóképp mint a hierarchiák esetében, ekkor az összegek beépülnek a kockába. Fontos megjegyezni a rendszerek azon hiányosságát, hogy nem lehet aggregált adatokat tárolni dimenziók nem teljes értékkészletével. Például nem megoldható, hogy aggregált adatokat tároljunk csak Gödöllő és Eger adataival. Igaz ugyanakkor az is, hogy a felhasználói lekérdezések ritkán ilyen jellegűek.
A dimenzió hierarchiák és az aggregált adatok esetén nyújtott megoldások tulajdonképp az adatok rendundás tárolásához vezetnek. A teljesítmény növelésére használt redundáns tárolás nem csak a MOLAP megoldásokra, hanem általánosan jellemző az adattárházakra, a tárhely-takarékosságról áthelyeződött a hangsúly a kiértékelés gyorsaságára.

Attribútumok: Ebben az esetben attribútum alatt a dimenzió jellemzőit értjük. Például, tekintve a "Vevő" dimenziót, ennek attribútumai lehetnek a vevő címe, számlaszáma, kategóriája, szöveges leírása, és így tovább.

Virtuális adatkocka: olyan kocka, amely levezetett, számolt adatokat tartalmaz, melyek konkrétan nem szerepelnek fizikailag tárolt kockákban. Ilyen lehet például egy a nyereségből épített kocka, vagy egy tény-terv összehasonlító százalékos eltérést mutató kocka.

A kocka indexeléséhez szokás olyan indexstruktúrát használni, ahol a kocka celláit valamilyen adott algoritmussal sorbarendezzük, majd az indexek sora ennek a sorbarendezésnek felel meg. Ennek legegyszerűbb módja, ha a kocka adott (x1, x2, .. xn) koordinátájú pontjához a kordinátákból alkotott x1 + (x2-1)*|{1.dimenzió elemszáma}|+...+(xn-1)*|{(n-1)..dimenzió elemszáma}| sorszámú indexet rendeljük.
Az indexeket és magát a fizikai tárolóhelyet a háttértárakon előre elkészítjük, így az adatok anélkül írhatóak, hogy az indexstruktúrát módosítani kellene. Ugyanakkor mivel a rendezés egyértelműen azonosítja az adott cellát, nem kell az adatokkal együtt a kulcsokat is eltárolni.

12.ábra: Háromdimenziós kocka celláinak egy rendezése

Amennyiben az adatmátrixunk ritka, tehát az adatok a kockán belül szétszórtan helyezkednek el, a kocka a hasznos adat mennyiségéhez képest nagy területet foglalhat el. Ennek oka, hogy az előre felépített indexstruktúra miatt a háttértáron előre helyet kell foglalni a kocka egészének. Sok dimenzió és nagy kiterjedésű dimenziók esetén ez akár oda is vezethet, hogy az adatbázis használhatatlanul naggyá válik. (A konkrét adatok egy becsléséhez ld. 6.ábra.) A ritka mátrix probléma kezelésére egyes multidimenzionális adatbáziskezelők tartalmaznak ún. ritka mátrix algoritmust, amely a kocka szerkezetéből megpróbálja a nem használt részeket kiszűrni, és a nekik fenntartott helyet felszabadítani, így elkerülve a mátrix kezelhetetlen naggyá válását.

A már említett ritka mátrix probléma mellett meg kell említenünk még, hogy a strukturális változtatások ebben a modellben rendkívül költségesek. Emellett ezek a rendszerek általában nehezen skálázhatók, nincs általánosan elfogadott szabványuk, minden gyártó saját utakon jár.

A MOLAP termékek széles skálán mozognak az asztali, néhány 10 Mb mennyiségű adat kezelésére alkalmas alkalmazásoktól kezdve a vállalati "high end" szoftverekig. Az első csoportba tartoznak pl. a Cognos PowerPlay-e, az Andyne PaBLO-ja és a Business Objects Mercury-ja. Az utóbbi kategóriában a Kenan Acumulata ES-e, az Oracle Express családja, a Planning Sciences Gentium-a és a Holistic System Holos-a olyan termékek, melyek nem csupán a multidimenzionális adattárolást, hanem rengeteg más kapcsolódó feladatot is megoldanak. Tisztán multidimenzionális adatbázis motorok az Arbor Essbase-e, a D&B/Pilot Ship Servere és a TM/1 a Sinper-től.

8. ROLAP architektúrák

ROLAP architektúra esetén tehát a koncepcionális modellünket a hagyományos relációs adatbázis környezetben szeretnénk megvalósítani. (Feltételezem, hogy alapvető relációs-adatbázis ismeretekkel rendelkezünk.)
Jelölésként a következőket szokás használni: egy-egy téglalap egy relációs táblát jelent, melynek neve a téglalap elsötétített tetején szerepel. A téglalap sorai megfelelnek a tábla oszlopainak (attribútumok). A téglalapok közti vonalak a táblák közti kulcs-kapcsolatokat jelentenek, tehát az egyik tábla valamely sorainak a másik tábla megfelelő attribútuma idegen kulcsa. (Jelenti ez azt, hogy egyrészt a hivatkozott táblában egy adott mező kulcsként van értelmezve, másrészt teljesíti a hivatkozási épség megszorítását is, tehát a hivatkozó tábla minden kulcsához tartozik érték a hivatkozott táblában. A jelölés hiányossága, hogy egyrészt a kapcsolat nem irányított, másrészt nem egyértelmű a kulcsok kijelölése, de erre nem is lesz igazán szükség.)

Nézzük meg a Kimball által [2.] javasolt négylépcsős relációs adattárház-tervezési metódust!

1. modellezendő üzleti folyamat kiválasztása
   pl.: raktárkészlet nyilvántartások

2. felbontás (granularity) meghatározása
   pl.: raktárkészlet termékenként, naponként, raktárhelyiségként, szállítóként, stb.

3. dimenziók meghatározása, kidolgozása
   pl.: termék: név, súly, szín, beszerzési ár, stb.

4. tényadatok meghatározása
   pl.: raktári mennyiség, súly, érték, minőségi mutatók, stb.

A lépésekkel előre haladva előfordulhat, hogy előző lépésre visszatérve már meghatározott jellemzőket újra kell gondolnunk, kiegészítenünk, módosítanunk kell.

Modellünkben a tényadatok, mutatószámok játsszák a központi szerepet. A koncepciónknak megfelelően készítünk egy táblát, amely tartalmazza az összes tényadatunkat, és azok jellemzőit. A ténytábla normalizálásaként a mutatószámok jellemzőit dimenziók szerint egy-egy dimenziótáblában gyűjtjük össze, melynek minden elemét egy kulcs azonosít. Célszerű generált kulcsot használni, melyek nem rendelkeznek önálló információtartalommal, viszont az adatbáziskezelő támogatja a kezelését.

13.ábra: Termék dimenzió dimenziótáblája (példa)

A dimenziótáblák attribútumai közé általában érdemes minél több jellemzőt felvenni. Igaz ugyanis, hogy az adataink elemezhetősége nagyban függ a dimenziótáblák elemeinek megfelelő csoportosíthatóságától, rendezhetőségétől. Ehhez szükséges, hogy az elemzést végző felhasználók minél több, lehetőleg szöveges jellemző alapján tudjanak tájékozódni a dimenzión belül. Példaként tekintsük az "dátum" dimenziót! Ennek talán nem is szentelnénk saját dimenziótáblát, hiszen az adatbáziskezelőnk valószínűleg ismer valamely dátum típust, azt gondolhatjuk ez elég is. Gondoljuk végig azonban azt az esetet, mikor az dátumnak egy külön dimenziótáblát szentelünk, és abba az elemezni kívánt időtartam minden napját felveszünk. Mellé kerülhetnek jellemzőként ünnepnapokat, leltározási időszakokat, évszakot, kormányváltás időszakát, vagy bármely más fontosnak vagy kevésbé fontosnak gondolt attribútum. Ekkor ezek szerint az attribútumok szerint az adataink elemezhetőek. A dimenziótábla mérete pl. 50 éves időintervallumra nézve is csak 18250 sor, ami valószínűleg a ténytáblánk méretéhez képest még mindig elhanyagolható (még ha a táblák denormalizáltak is), cserében viszont nagy elemzési rugalmasságot kapunk.
Általánosan is igaz, hogy a dimenziótáblák mérete a ténytábla méretéhez képest nagyságrend(ekk)el kisebb, ez adja tulajdonképp a csillagséma denormalizált (redundáns) dimenziótábláinak létjogosultságát.

14.ábra: Csillagséma: "Napi eladások" adatkocka megvalósítása

• egyszerű, intuitív adatmodell
• használata kevés join adatbázis műveletet igényel
• használata kevés tábla olvasását igényli
• könnyű megvalósíthatóság, a modell metaadatai (adatokat leíró adat) egyszerűek

A csillagséma hátrányai:

• aggregációk (összegek) képzése nehézkes
• nagy dimenziótáblák esetén a hierarchiakezelés nagyon lassíthatja a lekérdezéseket
• a dimenzióadatok tárolása redundáns

A hópehely séma nagyban hasonlít a csillag sémára, csak itt normalizáljuk a dimenziótáblákat (megszüntetjük vagy csökkentjük a redundanciát).

15.ábra: Példa hópehely sémára

Konszolidált csillagsémának hívjuk azt a speciális csillagsémát, mikor a központi ténytáblában aggregált adatokat is tárolunk.

A relációs multidimenzionális eszközök teljesítményében (válaszidőkben) általában elmaradnak a MOLAP eszközöktől. A teljesítmény javítására három standard módszert alkalmaznak Nem térünk ki most a relációs adatbáziskezelők teljesítményének javítására, amely tetemes elméleti és gyakorlati háttérrel büszkélkedhet. A következő módszerek már csak ezeket kiegészítő, speciálisan csak adattárházakra alkalmazható módszerek.

Denormalizáció alatt értjük azt az eljárást, mikor a ténytáblában redundánsan eltárolunk járulékos jellemzőket, olyanokat, melyek a dimenziótáblákban egyébként szerepelnek. Például, a kiskereskedős példánál az elemzéseknél gyakran használják a termék dimenziót, de abból csak a gyártó jellemzőt. Ekkor, ha a válaszidők nem megfelelőek, a ténytáblába mint oszlop bevesszük a "gyártó" jellemzőt, így megspórolva egy join műveletet a kiértékelésnél, elbukva viszont tárterületet a redundancia miatt.
Az adattárház rendszerekre általánosan jellemző az elemzési hatékonyság miatti redundáns adattárolás.

Aggregáció alatt értjük azt, mikor az adatok valamely szempont szerinti felösszegzett változatát is eltároljuk az adatbázisunkban. Ez jelentheti egy vagy több dimenzió elhagyását. A következő ábra szemlélteti egy négydimenziós adatkocka agregációs lehetőségeit. Nyilván az aggregációs szintek bevezetésével, használatával a válaszidők jelentősen javulhatnak egyes lekérdezéseknél, igaz viszont az is, hogy az összegeket minden új adatelem beszúrásánál frissíteni kell.

18.ábra: Aggregációs rács

Ezek közül a lehetőségek közül érdemes kiválasztani a leginkább használt nézeteket.
Szokás az adatkocka n dimenziót tartalmazó változatát n-cuboid-nak nevezni. A kocka materializációja alatt pedig azt értjük, hogy a lehetséges cuboid-ok közül melyeket tárolunk el fizikailag is.
Az aggregáció egy általánosabban értelmezése szerint gyakran tárolják az adatok olyan nézeteit is, ahol valamely dimenziókat elhagynak, valamely más dimenziókat viszont leszűkítenek egy adott értékintervallumra vagy értékre. (Ezt a fajta aggregációs tárolást egyébként a MOLAP adatbázisok általában nem támogatják, ezt szokták emlegetni mint hátrány. Újabban viszont támogatják relációs adatbázisok szintjén, például az Oracle 9i adatbáziskezelő a Materialized View objektum bevezetésével.)

A ténytábla túl nagyra hízása a teljesítmény rovására megy. Ezt elkerülendő szokás a táblát több ténytáblára vágni, melyek esetleg akár párhuzamosan is feldolgozhatók lehetnek.

9. HOLAP architektúrák

Egyre jellemzőbb trend, hogy a már meglévő relációs adatbázisok funkcionalitását kibővítik multidimenzionális tárolási lehetőségekkel. Ez lehetőséget ad olyan hibrid architektúrák felépítésére, melyeket alapvetően relációs módszerekkel építünk annak jól skálázható és robosztus tulajdonságai miatt, de kiegészítésként a gyakran használt nézetekre, adatokra építünk multidimenzionális kockákat is, a jóval gyorsabb lekérdezési sebesség miatt.
Az Oracle bár még néhány évig támogatja az Express termékcsaládját, hosszú távon ő is a relációs adatbáziskezelőjébe való beolvasztással tervez. Ugyancsak megjelent a Microsoft SQL Server-ében a multidimenzionális tárolást használó Analysis Services, és a DB2 relációs adatkezelőjébe a 8.1-es változattól ugyancsak beolvasztottak egy MOLAP szervert.
Az architektúra térnyerését jelzi például az eddig kizárólag relációs technikára és relációs adatbáziskezelőkre építkező SAP Business Information Warehouse adattárház terméke, ahol is a 3.0-ás változattól (2002), amennyiben az alatta lévő adatbáziskezelő MSSQL Server Analysis Services, már szintén képes a multidimenzionális tárolási technika alkalmazására.

10. Adattárház komponensek

Az adattárház-rendszer működtetéséhez, az információfeldolgozás automatizálásához és adminisztrációjához sok eszközre, komponensre van szükségünk. Ezek az eszközök a data warehousing folyamatának egy-egy kisebb-nagyobb részfolyamatára nyújtanak megoldást, kézenfekvő tehát őket a megoldott részfeladatok alapján csoportokba sorolni. Az ábrán szerepelnek az adattárház alapvető komponensei.

19.ábra: Adattárház komponensek

ETL Tools: Extraction, Transformation and Load, vagyis olyan eszközök, melyek az adatok kinyerését, transzformációját és adattárházba töltését támogatják. Ez a csoport jelenti az összekötő kapcsot a tranzakciós rendszerek és az adattárház között.
Az adatbetöltés folyamata a következő részfeladatokra bontható le:

• Adatkinyerés az operatív rendszerekből (extraction)

• Adattranszformáció (különböző adatformátumok, mértékegységek, nyelvek stb.)

• Adatminőség ellenőrzése, adattisztítás (cleaning)

• Adatbetöltés az adattárház struktúráiba (loading)

Az adattárház adatai az operatív adatokból származnak, az operatív adatok változásainak propagálódniuk kell az adattárház részletezett és aggregált adatain át a felhasználó által látható beszámolókig. Nem feltétlenül igaz viszont, hogy az operatív adatok változásait ezek azonnal követik. Fontos az adatfeltöltés periodicitásának és időpontjának gondos megválasztása. A túl gyakori adatfrissítés az operatív rendszerek fölöslegesen nagy terheléséhez vezethet, a túl ritka frissítésnek pedig az elemzett adatok naprakészsége láthatja kárát. Szétválaszthatjuk az adatainkat eszerint pl. óránkénti, naponkénti, hetenkénti és havonkénti adatfrissítést igénylő adatokra, és ezeknek megfelelően időzíthetjük az adattöltést az operatív rendszerek számára leginkább megfelelő időpontokra. Gyakran ezek az időpontok, időintervallumok éjszakai órák, hétvégék, ekkor legkisebb ugyanis az OLTP rendszerek terhelése. Fontos odafigyelni arra, hogy adott adattárház tárgyterületek adattöltése nagy adatmozgásokat igényelhet, az OLTP rendszerek hagyományos felhasználásával szemben több ezer, millió rekord egyidejű lekérdezésével jár, melyek semmiképp nem veszélyeztethetik a vállalat mindennapi működését.
Adattöltések megoldásai közt két alapvető csoportot különböztethetünk meg, attól függően, hogy hová csoportosítjuk az adatgyűjtést végző, szabályozó mechanizmusokat.

• "Push" adattöltés: Az operatív rendszerünket felkészítjük arra, hogy az adattárház számára adatokat gyűjtsön, adatokat továbbítson. Ebben az esetben lentről-felfelé az operatív rendszer kezdeményezi az adatok továbbítását az adattárházba.

• "Pull" adattöltés: Az adattárház a megfelelően beállított időintervallumban az operatív rendszerekhez intézett lekérdezésekkel frissíti az adatait.

Két újabb kategóriát jelenthet az adattöltések megkülönböztetése a változások követésének szemszögéből. Eszerint, ha az operatív rendszerben új vagy megváltozott adatokra vonatkozóan csak a változás valamilyen leírását továbbítjuk, delta-töltésről (a változásra utalva), ha az operatív rendszer adatait egy az egyben továbbítjuk, teljes-töltésről beszélhetünk.
Egy viszonylag részletes lista ETL szállítókról és termékekről: http://www.dwinfocenter.org/clean.html

Ide az adattárház adatain OLAP lekérdezéseket lehetővé tévő eszközök tartoznak. Az adattárház valamelyik már tárgyalt módszerrel tárolja az analitikai adatokat, az adatkockákat, ezek az eszközök pedig ezekhez az adatokhoz biztosítanak az OLAP elvárásoknak megfelelő lekérdező felületet. Ezek az adatszolgáltató megoldások túllépnek a hagyományos adatbázis lekérdezéseket kiszolgáló SQL szerverek funkcionalitásán, speciális OLAP lekérdezésekre, lekérdezés sorozatokat is támogatva.
Fontos kérdés, hogy az OLAP szerver milyen kapcsolódási felületet biztosít a kliens-alkalmazások felé. Eddig egységesen elfogadott szabvány OLAP-lekérdező interface-re még nem igazán született, a különböző szállítók különböző utakat járnak. Megoldást jelenthet talán az Open-OLAP szabvány, ami egyre szélesebb körben elfogadott és támogatott.

Ez a csoport az adattárház adataira épülő elemző, riportozó alkalmazásokat foglalja magába. Nagyon széles skálán mozoghatnak ezek az eszközök, kezdve a legegyszerűbb lekérdező-beszámolókészítő alkalmazásoktól a hagyományos statisztikai elemző-szoftvereken át az adatbányász eszközökig. Gyakran találkozhatunk valamely már ismert elemző eszköz vagy táblázatkezelő (SAP esetében pl. Excel) OLAP funkciókkal kibővített változatával. Ennek előnye a gyors tanulhatóság és a megszokott környezet, ezáltal a végfelhasználókkal való könnyebb elfogadtathatóság.

Metaadat: Ebben az esetben a "meta-" előtagot olyan értelemben használjuk, mint egy átfogó jelző olyan fogalom-és leíró módszerekre, amelyek egy eredeti fogalomrendszerrel foglalkoznak, abból származnak. Innen adódik a metaadat kifejezésre az "adatokat leíró adatok" meghatározás. A metaadat fogalma már a '60-as évektől kezdve jelen van az informatikában, a nem szekvenciális file-manager rendszerek adatleíró mezőitől kezdve (metaadatként felfogva az adatrekordok indexeléséhez felhasznált rekord-leíró mezőket) mind sokrétűbb módszerekként. A '70-es évektől relációs adatbáziskezelő rendszereknél is megjelent és kifejlődött többféle adatdefiníciós módszer, adatleíró megoldás, a tábladefiníciós megoldásoktól kezdve absztraktabb módszerekig, mint pl. az Entity/Relationship modell.

sok szállító --> sok tervezést és adminisztrációt segítő termék --> sok metaadat-kezelő megoldás

11. Az adattárház megoldás bevezetésének folyamata, az adattárház-project

12. Kurrens kutatási területek

A relációs adattárházak gyenge pontja a lekérdezések viszonylag nagy válaszideje főképp az elvégzendő tábla-összekapcsolások (join) miatt. Erre megoldást jelenthet megfelelően kialakított aggregátumok (technológiai elnevezésével élve materializált nézetek) tárolása az adatbázisban. Kérdéses viszont, hogy milyen algoritmussal érdemes kiválasztani az lehetséges aggregátumokból a megfelelőket, milyen hierarchikus szerkezetet érdemes belőlük kialakítani, és milyen módszerrel lehet az aggregátumokat saját magukat karbantartó tulajdonsággal felruházni.

A relációs tárolás hatékonyságát, a lekérdezések válaszidejét nagyban javíthatja megfelelő indexstruktúrák alkalmazása. Kutatás tárgyát képezi az adattárházak struktúráival hatékony módon működő indexelési módszerek kialakítása. Két már bevált és hasznos ilyen jellegű index-típus az úgynevezett bitmap index, valamint a join index. Az indexelés témaköre nagyban összefügg az előző pontban tárgyalt aggregátum-kezelés témakörrel: mindkét témakör olyan, adatbázisban járulékosan tárolt, redundáns adatok kezelésével, kialakításával foglalkozik, melynek célja a lekérdezések válaszideinek csökkentése.

Induktív adatbázis alatt értjük azokat az adatbázisokat, melyek nem csak adatokat, hanem az adatokat leíró következtetési sémákat is tartalmaznak. Az induktív adatbázisok koncepciója még nem teljesen kiforrott, annyit azonban leszögezhetünk, hogy induktív következtetési szabályokat, modelleket járulékosan tartalmazó adatbázisokról van szó. Képzeljünk el például egy olyan adatbázist, amely amellet, hogy tartalmazza például egy vállalat teljes vevőnyilvántartását, és lehetővé teszi a (deduktív következtetésekként felfogható) hagyományos adatbázis lekérdezések végrehajtását, olyan modelleket is tartalmaz, melyek az adathalmazból általánosított következtetéseket tartalmaznak, például jellemző megrendelési szokásokat, a vevők klaszterezését stb. Az induktív adatbázisok témaköre szoros kapcsolatban áll az adatbányászattal, ahol is hasonló rejtett összefüggések kinyerése a cél.

A relációs adattárházak csillag struktúrájának lekérdezését célzó query-k gyakran nem az optimális, leggyorsabban kiértékelhető formában érkeznek. Kérdés, hogy hogyan lehet a query-ket az optimális formára alakítani, és a lehető leggyorsabban kiszolgálni?

Az SQL lekérdező nyelv nem nyújt megfelelő támogatást OLAP, illetve adatbányász lekérdezések végrehajtásához. Kérdés, hogy milyen bővítés lenne célravezető ezek magasszintű támogatásához?

Az adattárházak adatmodelljei még korántsem mutatnak egységes, kiforrott képet. A tervezés, az implementáció és a használat során megfelelően használható, elfogadott modell még nincs jelen.

Adattárházat építeni PC-k klasztereiből, vagy általában sok független adatpiacból még nem kidolgozott, de ígéretes terület. A megfelelő módszerek, modellek még hiányoznak.

Az adattárház metaadat-szótára kulcsfontosságú a használhatósága és a hatékonysága szempontjából. Fontos ezért, hogy kialakításuk jól átgondoltan, esetleg megfelelő formalizmusok használatával történjen. Fontos még az általános használhatóság, a könnyen illeszthetőség feltétele is más rendszerekhez, valamint lehetőség szerint a minél teljesebb elfogadottság, a nagy piaci szereplők meggyőzése a metaadatkezelő szabvány használatáról, így az egységesítés.

A különböző portálok, vállalati webszerverek egyre nagyobb felhasználása megteremtette az igényt az általuk készített naplófile-ok megfelelő analízisére. Erre megfelelő megoldást nyújthat egy adattárház, azonban a rendkívül nagy adatmennnyiségek miatt a megvalósított struktúrák, megoldások gyakran kudarchoz vezetnek. Ezek kutatása is ígéretes terület.

13. Az adattárház piac és szereplői

Irodalom

[1] W.H.Inmon: Building the Data Warehouse - Second Edition

[2] Ralph Kimball, Margy Ross: The Data Warehouse Toolkit - Second Edition

[3] Naeem Hashmi: Businness Information Warehouse for SAP

[4] Andreas Totok: Modellierung von OLAP- und Data-Warehouse-Systemen

[5] Gary Dodge, Tim Gorman: Essential Oracle8i Data Warehousing

[6] Matthias Jarke, Maurizio Lenzerini, Yannis Vassiliou, Panod Vassiliadis: Fundamentals of Data Warehouses

[7] Sakhr Youness: Professional Data Warehousing with SQL Server 7.0 and OLAP Services

[8] Wolfgang Martin: Data Warehousing: Data Mining - OLAP

[9] Schutte, Rotthowe, Holten: Data Warehouse Management-handbuch

[10] Ramon Baraquin, Herb Edelstein: Planning and Designing the Data Warehouse

[11]

[12]

[13]

[14]