1 of 22

Adattárház rendszerek

Kovács László, ME

2 of 22

Adattárház

speciális adatbázis
egyedi tárolási-kezelési formátum
adatelemzés orientált
adatmegjelenítési elemek
felhasználó orientált műveletek
egyszerűbb adatstruktúra
adatelemzés orientált belső szerkezet
több-dimenziós adatmodell, adatkocka
MDX

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

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. Mindig 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 múltbeli eseményeknek. Egy beléptető rendszernél szükség lehet egy adott múltbeli időpontban benn tartózkodó személyek listájára.

A letárolt, archív adatok azonban nemcsak az egyszerű visszaolvasásra használhatók fel. 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 könyv kölcsönző esetében például annak ismerete, hogy mely típusú könyveket 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. �

3 of 22

Adattárház

- Inmon (1995)

OLAP alapú adattárolás
heterogén adatok integrálása
múltbeli adatok
MD modell
MD algebra
nagy adatmennyiség

4 of 22

DW architektúra

5 of 22

DW architektúra

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.

Kék keret: Komponensek: Külső világ és alkalmazások, ezek szolgáltatják a DW bemenetét, és adatforrását. Ezek OLTP rendszerek

Piros keret: Integrácios és transzformácios réteg (ETL)

Lila keret: Operational Data Source, az integrált, részletes és jelenlegi adat az adatforrásokbol. Nem nő idővel. Tranzakciosként szerepel.

EDW: Enterprise Data Warehouse: témakör-orientált, integrált, összegzett és jelenlegi adatok. Optimalizált lekérdezési célokra. Dimenzionális modellű tipikusan. Ő az adatpiacok forrása. Mivel hisztorikus adatok, ezért idővel nő a mérete.�Zöld keret: DSS (Decision Support Systems: Döntéstámogato rendszerek) Alkalmazások

Cross Media Storage: Ritkán igényelt hisztorikus adatokat tartalmaz. Nem annyira jo elérési idővel rendelkezik, általában megfizethetőbb, mint az EDW.

6 of 22

ETL architektúra

Csábító azt gondolni, hogy egy adattárház létrehozása egyszerűen több forrásból az adatokat kinyerése, és betöltése az adattárház adatbázisába. Ez távol áll az igazságtól, és összetett ETL-folyamatot igényel. Az ETL folyamat különböző érdekelt felektől, köztük fejlesztőktől, elemzőktől, tesztelőktől, felsővezetőktől aktív közreműködést igényel, és technikailag nagy kihívást jelent.

Annak érdekében, hogy megőrizze értékét a döntéshozók eszközeként, az adattárház rendszernek az üzleti változásokkal együtt kell változnia. Az ETL egy adattárház rendszer (napi, heti, havi) ismétlődő tevékenysége, amelynek agilisnek, automatizáltnak és jól dokumentáltnak kell lennie.

1. lépés) Kivonás

Az ETL architektúrának ebben a lépésében az adatok a forrásrendszerből az átmeneti (staging) területre kerülnek kinyerésre. Az átalakítások, ha vannak ilyenek, az átmeneti területen történnek, hogy a forrásrendszer teljesítménye ne csökkenjen. Ezenkívül, ha a sérült adatokat közvetlenül a forrásból az adattárház-adatbázisba másolják, a visszaállítás kihívást jelent. Az átmeneti terület lehetőséget ad a kivont adatok érvényesítésére, mielőtt azok az adattárházba kerülnének.

Az adattárháznak integrálnia kell a különböző rendszereket

A források lehetnek örökölt alkalmazások, például nagyszámítógépek, testreszabott alkalmazások, kapcsolattartó eszközök, például ATM, híváskapcsolók, szöveges fájlok, táblázatok, ERP, szállítóktól, partnerektől származó adatok, többek között.

Ezért az adatok fizikai kinyerése és betöltése előtt logikai adattérképre van szükség. Ez az adattérkép a források és a céladatok közötti kapcsolatot írja le.

Három adatkinyerési módszer:

Teljes kivonás
Részleges kivonás - frissítési értesítés nélkül.
Részleges kivonás – frissítési értesítéssel

Az alkalmazott módszertől függetlenül a kivonás nem befolyásolhatja a forrásrendszerek teljesítményét és válaszidejét. Ezek a forrásrendszerek élő termelési adatbázisok. Bármilyen lassítás vagy zárolás hatással lehet a vállalat eredményére.

Néhány érvényesítés a kivonás során történik:

Hangolja össze a rekordokat a forrásadatokkal
Győződjön meg arról, hogy nincs spam/nem kívánt adat betöltve
Adattípus ellenőrzés
Távolítson el minden típusú ismétlődő/töredezett adatot
Ellenőrizze, hogy minden kulcs a helyén van-e vagy sem

2. lépés) Átalakítás

A forrásszerverről kinyert adatok nyersek, és nem használhatók eredeti formájukban. Ezért meg kell tisztítani, megfeleltetni és átalakítani. Valójában ez a kulcsfontosságú lépés, ahol az ETL-folyamat értéket ad és megváltoztatja az adatokat úgy, hogy értelmes jelentéseket lehessen készíteni.

Ez az egyik fontos ETL-fogalom, ahol függvénykészletet alkalmaz a kivont adatokon. Az átalakítást nem igénylő adatokat úgy nevezik, hogy közvetlen mozgás vagy átmenő adat.

Az átalakítási lépésben testreszabott műveleteket hajthat végre az adatokon. Például, ha a felhasználó olyan árbevétel-összeget szeretne, amely nem szerepel az adatbázisban. Vagy ha egy táblázatban a keresztnév és a vezetéknév különböző oszlopokban van. Lehetőség van a betöltés előtt összefűzni őket.

Az adatok integritásával kapcsolatos problémák a következők:

Ugyanannak a személynek különböző írásmódja, mint például Jon, John stb.

Számos módja van a cégnév jelölésének, például a Google, Google Inc.

Különböző nevek használata, például Cleaveland, Cleveland.

Előfordulhat, hogy ugyanazon ügyfél számára különböző alkalmazások különböző számlaszámokat generálnak.

Egyes adatoknál a szükséges fájlok üresek maradnak

A POS-ban kézi bevitelként begyűjtött érvénytelen termék hibákhoz vezethet.

Az ellenőrzések ebben a szakaszban történnek

Szűrés – Csak bizonyos oszlopokat válasszon betöltésre

Szabályok és keresőtáblák használata az adatok szabványosításához

Karakterkészlet átalakítás és kódolás kezelése

Mértékegységek átváltása, például a dátum és idő átváltása, a pénznemek átváltása, a számszerű átváltás stb.

Adatküszöb érvényesítési ellenőrzés. Például az életkor nem lehet több két számjegynél.

Adatfolyam érvényesítése az átmeneti területről a köztes táblákhoz.

A kötelező mezőket nem szabad üresen hagyni.

Tisztítás (például a NULL leképezése 0-ra vagy a Nem férfi „M” és a nő „F”-re stb.)

Egy oszlop felosztása többszörösekre, és több oszlop összevonása egyetlen oszlopba.

Sorok és oszlopok transzponálása,

Bármilyen összetett adatellenőrzés használata (pl. ha egy sor első két oszlopa üres, akkor a sor automatikusan elutasítja a feldolgozást)

3. lépés) Betöltés

Egy tipikus adattárházban hatalmas mennyiségű adatot kell betölteni viszonylag rövid idő alatt (éjszakák). Ezért a betöltési folyamatot a teljesítmény szempontjából optimalizálni kell.

Betöltési hiba esetén a helyreállítási mechanizmusokat úgy kell konfigurálni, hogy az adatintegritás elvesztése nélkül induljanak újra a meghibásodás helyétől. A Data Warehouse adminisztrátorainak figyelniük kell, folytatniuk és meg kell szakítaniuk a betöltéseket a szerver aktuális teljesítményének megfelelően.

A betöltés típusai:

Kezdeti betöltés – az összes Data Warehouse tábla feltöltése

Növekményes terhelés – a folyamatos változtatások rendszeres alkalmazása szükség szerint.

Teljes frissítés – egy vagy több tábla tartalmának törlése és újratöltés friss adatokkal.

Betöltés ellenőrzése:

Győződjön meg arról, hogy a kulcsmező adatai se nem hiányoznak, se nem null.

Tesztelje a modellezési nézeteket a céltáblázatok alapján.

Ellenőrizze a kombinált értékeket és a számított mértékeket.

Adatellenőrzések a dimenziótáblában és az előzménytáblázatban.

Ellenőrizze a BI-jelentéseket a betöltött tény- és dimenziótáblázaton.�

7 of 22

Adattisztítás

Inkonzisztencia okai:

hiányzó adatelem
hiányzó adatérték
hibás adat érték
hibás számítások
duplikáció
eltérő formátum
eltérő kódolás
integritási hiba
név konfliktus
strukturális konfliktus

8 of 22

MD adatkocka modell

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 fontos stratégia kérdéseket kell hoznia, arról, hogy például mely régiókat, terméketet fejlesszen vagy 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 kíváncsiak. Egy döntéshez például nem pusztán azt kell ismerni, hogy mennyi volt a vállalat múltévi forgalma, hanem olyan finomabb ismeretekre van szükség, hogy hogyan 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 modellel szemben, ahol a különböző mennyiségek adatai szeparált táblákban 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 megadott 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éken keresztül kapcsolódik a kocka belsejé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 mennyiségeket.

Az MOLAP (Multidimenzios OLAP) 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.

Cella,: A kockában a vizsgált adatmennyiséget tartalmazzó tárolási egység. Például 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, ahol egy cella egy vásárlást reprezentál, a cella dimenziói lehetnek például az eladott mennyiség és az eladási ár.

Attributumok: A dimenziók jellemzői, leírói adatai jelenti. A dimenziók ugyanis nem pusztán egyetlen egy elemi adattal leírható mennyiségek lehetnek, hanem tetszőlegesen összetett struktúrák is. Ekkor egy attributum a dimenzióhoz tartozó mennyiség egyes mezőjét azonosítja. Igy egy termék dimenzió esetén a terméket leíró adatok, mint 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 hierarchikus kapcsolatrendszert írja 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, ezen 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 foglalnak más értékeket. A mai hónap példá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, hogy az értékek hogyan tartalmazzák egymást. A felvázolt hierarchia más mennyiségek, dimenziók esetében is elképzelhető. A hagyományos rendszerekben minden érték önálló, 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).�

9 of 22

MD adatkocka

10 of 22

MD logikai modell : Star/Csillag séma

11 of 22

MD logikai modell : Snowflake/Hópehely séma

a dimenziókhoz szintek (felbontási szintek) rendelhetőek
szintek hierarchiája
bázis szint
PCR kapcsolat

12 of 22

MD adatmodell

elemi értékű cellák
változók, PKI értékek
dimenzió szintek
measure dimenzió
measure értékei változókat jelölnek
a cellák lehetnek üresek
member: a dimenzió egy értéke

13 of 22

14 of 22

MD műveletei

adatlekérdezés orientált
elemi műveletek
legkisebb kocka: egy skalár érték
MD algebra:

selection (slice and dice)
drill down
roll up
fold
...

15 of 22

MD művelet: selection

slice and dice: részkocka képzése

csak a feltételnek megfelelő cellák maradnak meg

variable:
attribute

ර _f(v)(Cube)

ර _f(d.a)(Cube)

^රprofit > 100 ^(Sales)

A MOLAP lekérdező felületének jellemzője, hogy a lekérdezések rendszerint csak egy vagy két dimenzió 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 felhasználok. A kocka különböző szeletei a különböző felhasználói igényeknek 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 régiót vezető menedzser számára adnak értékelendő információt. A kocka szeletekre bontásának műveletét az MOLAP angol terminológiájában 'slice and dice' műveletnek nevezik.

A teljes adatkocka tartalmát szelektálhatjuk, szűrhetjük egy vagy több általunk megadott szűkítési feltétel alapján. A szűkítési művelet eredménye egy újabb adatkocka, amely a kiinduló adatkocka értékeinek egy részhalmazát tartalmazza.

Fajtái:

Változó szelekció: az eredmény a teljes adatkocka; a feltételnek nem megfelelő cellák NULL értékűek

Attribútum szelekció: csak a feltételt kielégítő dimenzió értékeket tartalmazó cellák kerülnek az eredménybe

Változó projekció: csak a kijelölt változók értékei

Attribútum projekció: csak a kijelölt dim. Attribútumok

16 of 22

MD művelet: drill down and roll up

drill down: részlezetőbb szintre váltás (snowflake modell)

Részletek kijelzése

roll up: aggregáltabb szintre lépés (snowflake model)

Aggregáció jelzése

к_d(Cube)

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. Ílyenkor egy adott értékszinten megadott felbontásról felfele, egy összesítettebb értékszintre lépünk a dimenzióhoz tartozó értékhierarchiában.

17 of 22

MD művelet: fold

fold: dimenziók megszüntetése

jelentés: group by
csökkentett dimenziószám
a cellák összesített értékeket mutatnak

ф_{d, aggr}(Cube)

Egy másik speciális művelet a kocka átdimenzionálása, a „fold”. 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 forgalmá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.

Aggregációs függvények: count, sum, avg, min, max

18 of 22

MD műveletek

Input kocka : Sales(customers:person, products:item,time:month)

E1:

eladási adatok 2017-re:

^රmeasure = sales_amount and time = 2017

(к_time:year(Sales))

E2:

eladott darabszámok magyar vevőkre nézve 2017.ben:

^රmeasure = sales_amount and customer = “Hungary” and time = 2017

^(кtime:year, customer: country ^(Sales))

E3: össz eladási adatok havi bontásban ф_time:sum(Sales)

E4: össz eladási adatok évi bontásban ^фtime:sum^(кtime:year ^(Sales))

19 of 22

MDX nyelv

MDX nyelv modellje:

adatkocka
dimenziók
dimenzió hierarchia
szintek (level)
member: dimenzió érték
Measure
Tuple: értékek n-ese különböző dimenziókból véve
Set: azonos szerkezetű tuple-ek együttese
Default member
Property

20 of 22