Informatika | Adatbázisok » Daragó László - OLAP adatbázis-kezelés

Adatbáziskezelés Daragó László A menedzsment információs rendszer (MIS). 2 Az elektronikus adatfeldolgozás formái. 3 A menedzselési szint és az EDP kapcsolata. 5 Relációs adatbázis . 6 Adatbázis. 6 Meta adat (fogalomtár). 6 Adatmodell . 7 Funkcionális függőség. 7 Kulcsok. 8 Normál formák, normalizáció . 8 Első normál forma (1NF) . 8 Második normál forma (2NF) . 9 Harmadik normál forma (3NF) . 9 Boyce Codd normál forma (BCNF) . 10 Osztott adatbázisok . 11 Osztott adatbázis . 11 Osztott rendszer. 12 Az adatok elhelyezése . 12 OLTP. 13 OLAP . 13 ROLAP, MOLAP. 14 Architektúra és End-to-End folyamat . 15 Szerver oldali eszközök és segédprogramok. 17 Adat tisztítás. 18 Feltöltés . 18 Frissítés. 19 Fogalmi (conceptual) modell és kliens oldali eszközök. 20 Kliens oldali eszközök . 21 Managed query environment. 23 Adatbázis tervezési módszertan . 23 Adattárház szerverek . 28 Index struktúrák és használatuk . 28 Materialized view-k és

használatuk . 29 Szerver architektúrák a lekérdezés feldolgozáshoz. 30 Metaadat és adattárház management. 32 Irodalomjegyzék. 34 Ábrajegyzék . 35 1/35 A menedzsment információs rendszer (MIS) Az elektronikus adatfeldolgozás (EDP: Elektrical/Electronical Data Processing) a modern vállalatirányítás nélkülözhetetlen része. A folyamatvezérlés, az eljárások szabályozása, a működés felügyelete, a marketing, a stratégiai menedzsment olyan nagy mennyiségű adat elérését feltételezi, amely csak jól megtervezett információs rendszer alkalmazásával kivitelezhető. 1. Ábra Management Information System A MIS az EDP-t alkalmazó szervezetek olyan integrált, vagy interface-elt end-user információs rendszere, amely támogatja a működést, a menedzsmentet és a döntéshozatalt. Jellemzői: - hardver és szoftver összetevők - emberi eljárások - felhasználói végpontok, kiszolgálópontok - jól definiált adatbázis A

piramis elemei: 2/35 - MISS: Management Information Support System, a szervezet működéséhez igazodó tranzakciós rendszer, amely a valóságban történő eseményekkel inputoutput kapcsolatban áll. - OS/controlling: Operation supervising/controlling: a működés felügyeletét ellátó interaktív alrendszer, valamint a vezető információs alrendszert kiszolgáló adatszolgáltató modul - TP: taktikai tervezés, feladata az erőforrások felkutatása, piackutatás, a döntéshozatali panelek kialakítása, a controlling tevékenység szabályozása - EIS (VIR): Executive Information System (Vezetői Információs Rendszer), a stratégiai tervezés döntéstámogató alrendszere Egyéb elnevezések: - EDP: MISS és OS/controlling - DSS (Decision Support System): OS/controlling, TP és EIS Az egyes tevékenységek (menedzselési szintek) eltérő jellegű adatelérési igénnyel bírnak, ezért az információs rendszernek is igazodnia kell azokhoz. Az

elektronikus adatfeldolgozás formái Az EDP alkalmazási formája a hardver és szoftver elemek mellett az adatbázis optimális felépítését is meghatározza. Az elektronikus adatfeldolgozás formáit három csoportba lehet osztályozni. 1. Adat input/output 2. Ábra EDP: I/O 3/35 A feldolgozás célja azonnali, vagy későbbi időpontban az output előállítása az inputtól függően. A bevitt adat a tárban lévő más adatokkal együtt, a feldolgozás algoritmusa szerint határozza meg az outputot. A cél az output megfelelő válaszidő belüli előállítása, reprodukálhatósága. 2. Lekérdezés futtatás 3. Ábra EPD: lekérdezés A feldolgozás célja a tárban lévő adatoknak a megadott paraméterek szerinti csoportosítása, meghatározott formában történő megjelenítése. A megjelenítéskor használhatóak a csoportosítást, szűrést, átlagolást, összegzést végző függvények. A gyakorlati alkalmazások általában bonyolult lekérdezési

függvényeket használnak, ezért kaszkádolt lekérdezéseket használnak, ahol az első lekérdezés eredménye a második adatforrása, és így tovább: 4. Ábra EDP: kaszkádolt lekérdezés A lekérdezéseket lehet spontán módon adatmegjelenítésre, vagy későbbi felhasználás céljából adatszűrésre alkalmazni. 4/35 Fajtái: - választó lekérdezés: az adatbázis adott nézetének megjelenítése módosító lekérdezés: az adatbázisnak a lekérdezés paraméterei által meghatározott módosítása - törlő lekérdezés: az adatbázis meghatározott rekorjainak törlése - táblakészítő lekérdezés: az adatbázis bővítése a meglévő adatok újracsoportosításával. 3. Jelentés generálás 5. Ábra EDP: jelentés A feldolgozás célja a tárolt adatoknak előre meghatározott, formázott alakban történő megjelenítése. A jelentések futtatására a ciklikusság jellemző Általában nem az adatbevitellel egyidőben vagy

közvetlenül utána, hanem meghatározott rendszerességgel futtatják. Lényege az egyedi, de állandó megjelenítése a kívánt adatoknak. A menedzselési szint és az EDP kapcsolata Az előzőek szerint a szervezet a MIS felosztása szerint négyféle menedzselési szintet különböztet meg. Általában a szervezet minden alkalmazottja mind a négy szinten végez aktivitást, beosztásuk és konkrét feladatunk határozza meg, hogy melyik szint milyen mértékben jellemző rá. Egy áruházi pénztáros, kórházi nővér vagy banki ügyintéző többnyire a tranzakciós szinten fejti ki aktivitását, de a beszámoló, jelentéskészítés is hozzátartozik feladatköréhez, míg a felső vezetésre a stratégiai elemzések végzése, a beszámolók értékelése jellemző, ugyanakkor nem kizárt, hogy az adatbevitel munkája részét képezi. Az, hogy jellemző tevékenység pl. a felső vezetésnél a stratégiai tervezés és elemzés azt eredményezi, hogy a MIS-piramisban

az EIS(VIR) az általánosan (de nem kizárólagosan) alkalmazott 5/35 modul. A gyakori tévedés, amely a MIS-t a vezetői információs rendszerekkel azonosítja valószínűleg ennek köszönhető. A menedzselési szintek jellemző adatfeldolgozási folyamatai: Menedzselési szint Jellemző input iránya Jellemző iránya output Jellemző adatfeldolgozási forma MISS Valóság Valóság, controlling, I/O TP controlling MISS EIS Jelentés TP MISS EIS, controlling Lekérdezés, jelentés EIS Controlling,TP Valóság Jelentés Relációs adatbázis Mivel az adatbázis a szervezet mindenkori állapotát írja le fontos, hogy a egyértelmű és az output előállítása szempontjából optimális legyen. A MISS feladata, vagyis az I/O rendszerek kiszolgálás megfelelő adatbázis-motor, DBMS rendszerek által valósul meg. A relációs adatbázis a relációs adatmodell fizikai megvalósítása, amelyben az egyes adatok kapcsolataik szerint vannak tárolva.

Adatbázis - rendezett gyűjtemény: úgy van rendezve, hogy könnyű legyen a tárolás, módosítás, illetve lekérdezés - összefüggő adatok: olyan adatok, mely lefedik egy felhasználó csoport érdeklődési területét Meta adat (fogalomtár) az adott adat tulajdonságait írja le. Jellemzői: - adatdefiníció - adatstruktúra - szabályok, és korlátozások - az adatraktárban találhatók (repository) A meta-adat az adat leírója. Jelentést párosít az adathoz, meghatározza az adat struktúráját, valamint azt, hogy milyen szabályoknak illetve korlátozásoknak kell megfelelnie az 6/35 adatoknak. Az adatok leírói, a meta- adatok az adatraktárban (repository) találhatók Fontos, hogy az adatbázis mellett létezzen egy ilyen raktár. Adatmodell Az adatbázis elméleti megalapozása és tervezése az adatmodellen keresztül valósul meg. A relációs adatbázis-tervezés bevált eszköze az ERD (Entity-Relationship Diagram), amellyel lényegében a

leendő táblák és a közöttük létező kapcsolatok határozhatók meg a felhasználó világa (entitások/egyedtípusok és kapcsolataik) alapján. Az adatmodell olyan matematikai formalizmus, mely a valóság adatorientált leírására alkalmas. Az adatmodellnek a valóság teljes értékű megadásához az alábbi három komponenset kell tartalmaznia: - strukturális rész, mely a valóságban megtalálható adattípusok és kapcsolataik leírására szolgál - műveleti rész, mely felhasználásával különböző lekérdezési vagy módosítási tevékenységeket végezhetünk - integritási rész, mely az adatbázisban megvalósuló adattípusokra és kapcsolatokra, valamint az elvégezhető műveletekre ad megszorítást Funkcionális függőség A funkcionális függőség tulajdonképpen egy korlátozás két attribútum között. Attribútum B funkcionálisan függ attribútum A-tól, ha A értékéből egyértelműen következik B értéke. Például a

főszakirány neve egyértelműen meghatározza, hogy melyik tanszéké az adott főszakirány, és hogy ki a felelős az adott tanszéken a szakirányért. Másképpen fogalmazva, ha ismert a főszak neve, akkor egyértelmű, hogy melyik tanszék, és azon belül ki a felelős az adott szakirányért. A jelölés egy nyilat használ A nyíl bal oldalán lévő attribútumot determinánsnak nevezik, mert ez határozza meg a nyíl jobb oldalán lévő attribútumokat. (pl: Főszak név -> Tanszék, Felelős) Funkcionális függőségek tulajdonságai: Armstrong három axiómája a funkcionális függőségről: Legyen R reláció attribútumai A1,A2.An, jelölje X, Y, Z ezen attribútum halmaz egy részhalmazát Reflexivitás: Ha X tetszőleges részhalmaza Y-nak, akkor Y->X. Szokás ezt triviális függőségnek nevezni. Tranzivitás: Ha X->Y és Y->Z, akkor X->Z. 7/35 Bővíthetőség: Ha X->Y, akkor XZ->YZ. Ezen tulajdonságokból következnek az alábbi

szabályok: Egyesítési szabály: Ha X->Y és X->Z, akkor X->YZ. Pszeudó tranzivitás: Ha X->Y és WY->Z, akkor XW->Z. Dekompozíciós szabály: Ha X->Y és Z tetszőleges részhalmaza Y-nak, akkor X->Z. Kulcsok A relációkban az adatok integritása kulcsokkal biztosítható. A kulcsjelölt az attribútumok olyan kombinációja, amely egyedi. Ezek közül egy választható elsődleges kulcsnak, a többi pedig kulcsjelölt. Ha kulcs több attribútumból áll, akkor összetett kulcsról beszélünk, ha csak egy attribútumból áll, akkor egyszerű kulcs. A külső vagy idegen kulcs egy olyan attribútum(ok), amely kulcs egy másik relációban. Például, ha definiálunk egy főszakirány relációt, akkor a Főszak név attribútum lehet az elsődleges kulcs a Főszakirány relációban, míg a Főszak név a Diák relációban hivatkozik erre a Főszak névre. Ez azt jelent, hogyha például szeretnénk megtudni, hogy egy adott tanszékhez kik tartoznak,

akkor a Főszakirány táblából kinézzük, hogy milyen szakirányok tartoznak az adott tanszékhez, és a főszakirány alapján kinézzük a diákokat a Diák relációból. A kulcsjelöltekre vonatkozó definíció pontosabban fogalmazható meg a funkcionális függőségek segítségével: Minden nem kulcs attribútum funkcionálisan függ a kulcstól. Ez annak felel meg, hogy a kulcs egyedi. Ha bármely attribútumot, vagy attribútumokat elhagyjuk, akkor már az első feltétel nem teljesül. Ez a minimalitási kritérium Amennyiben egy attribútum halmaz csak az első kritériumot teljesíti úgy akkor azt a reláció szuperkulcsának nevezzük. Normál formák, normalizáció A normalizáció tulajdonképpen egy ellenőrző módszer, amivel ellenőrizhetjük, hogy az adott relációban megtalálhatók az előbb említett anomáliák. Ez egy formális módszer, tehát nem kíván intuíciót, legfeljebb a funkcionális függőségek felírásakor. A következőkben a

relációk normál formáiról lesz szó, amelyek kiküszöbölik a különböző anomáliákat. Részletesen lesz szó az első, második, harmadik, és Boyce-Codd normál formákról. Az ennél magasabb normál formákkal nem foglalkozunk, de megjegyezzük, hogy létezik 4. és 5 normál forma is Első normál forma (1NF) Az első normál forma csak annyit szab meg feltételként, hogy ne legyenek ismétlődő csoportok a relációban. Ez a korlátozás tulajdonképpen megfelel a reláció azon 8/35 tulajdonságának, hogy egy oszlop és egy sor találkozásában csak egyetlen érték szerepelhet. Ha például az előző „rossz” relációnkat másképpen reprezentáljuk (felső táblázat), akkor ez ismétlődő csoportot tartalmaz. Ezt úgy küszöbölhetjük ki, hogy átalakítjuk egy olyan táblázattá, ahol az ismétlődő csoportok külön sorba kerülnek. Az 1NF tulajdonképpen csak egy alaki meghatározás, ez még semmilyen anomáliát nem küszöböl ki. Második

normál forma (2NF) A második normál forma egy erősebb korlátozás. Ahhoz, hogy egy reláció 2NF legyen először is 1NF-nek kell lennie. A második feltétel az, hogy ne legyen részleges kulcsfüggőség, más szóval, minden nem kulcs attribútum az egész elsődleges kulcstól függjön, ne pedig annak egy részletétől. Példaként most vegyünk egy foci bajnokságot leíró relációt. A relációban tároljuk a csapat nevét, a csapat székhelyét, és a hozzátartozó játékosok igazolás számát valamint nevét. Ez a reláció 1NF-ban van, de azok az anomáliák érvényesek, amelyekről eddig szó volt. Gondoljunk például arra, hogy egy új csapatot nem tudunk felvenni, amíg nincs hozzátartozó játékos, de ugyanúgy megtalálhatók a módosítási, és törlési anomáliák. A normalizációhoz nézzük először a funkcionális függőségeket Mint látható részleges függőségeink vannak. A Ját név a Ját ig-tól függ, ami csak egy része a kulcsnak

Ugyanakkor az is igaz, hogy a Város attribútum csak a Csapatnévtől függ, nem pedig a teljes kulcstól. Ez az oka annak, hogy anomáliák vannak A problémát úgy oldhatjuk meg, ha a relációt kisebb relációkra bontjuk: Csapat, Játékos, Játék. Minden problémás függőségre készítünk egy relációt. Az eredeti relációban megőrizzük azokat az attribútumokat, amelyek nem kerültek be az új relációba, plusz az új relációk elsődleges kulcsi idegen kulcsként bekerülnek az eredeti relációba. Harmadik normál forma (3NF) Ahhoz, hogy egy reláció 3NF legyen először is 2NF-nek kell lennie. Ugyanakkor nem lehetnek tranzitív függőségek. A tranzitív függőség egy olyan függőség láncolat, amelyben az elsődleges kulcs meghatároz valamilyen attribútumot, és az az attribútum meghatároz egy harmadik attribútumot. Ez a lánc akármilyen hosszú lehet A szokásos Tanulmány relációnk egy ilyen reláció, és már láttuk, hogy milyen formában

jelentkeznek a különböző anomáliák. A funkcionális függőségekből látszik, hogy a Tanszék és Felelős attribútumok tranzitíve függenek (a Szak attribútumon keresztül) a Törzs attribútumtól. A felosztási szabály hasonló a 2NF-nál alkalmazott módszerhez. A tranzitív függőséget egy új relációba helyezzük, és az eredeti relációban meghagyjuk az összes többi attribútumot, plusz ehhez hozzávesszük az új 9/35 reláció elsődleges kulcsát. Könnyen ellenőrizhető, hogy az új relációkban már nem jelentkeznek az anomáliák. Boyce Codd normál forma (BCNF) A Boyce-Codd normál forma egy erősebb normál forma, ami közvetlenül ellenőrizhető a funkcionális függőségekből, tehát nem kell ellenőriznünk, hogy az adott reláció 3NF-e. Ha BCNF, akkor biztosan 3NF is. Az egyetlen feltétel a BCNF formára az, hogy a determinánsoknak kulcsjelölteknek kell lenniük. Példaként vegyünk egy Interjú nevű relációt Ebben a relációban

tároljuk azt, hogy egy vállalatnál az interjúra érkező jelöltek kivel és mikor találkoznak. Minden jelöltet egy alkalmazott hallgat meg Egy adott alkalmazott egy adott napon egyetlen egy szobában tartja az interjúit. Először is nézzük, hogy „jó”-e ez a reláció. Az egyetlen anomália az, hogy például az alkalmazott szobához rendelése redundánsan van tárolva, hiszen egy napon több interjú-alanya is lehet. Nézzük ezek után, hogy a reláció vajon 3NF-e. A reláció elsődleges kulcsa a Jelölt, és a Nap kombinációja, mivel feltételezzük, hogy a egy jelölt egy napon csak egy interjúra jön. A funkcionális függőségek a következők. Sem részleges függőség, sem pedig tranzitív függőség nem áll fenn, ezért a reláció 3NF, de mint láttuk még mindig hordoz magában redundanciát. Most nézzük, hogy BCNF-e. Az első függőség rendben van, mert a Jelölt, Nap kombináció kulcsjelölt. A második függőség nincs rendben, mert a Nap,

Alkalmazott ID kombináció az nem kulcsjelölt. A harmadik függőség megint rendben van, mert a Nap, Alkalmazott ID, Időpont kombináció kulcsjelölt. A felbontás hasonló az előző módszerekhez Összefüggést a BCNF és a 3NF között Ha minden kulcsjelölt egyszerű, akkor BCNF és 3NF ekvivalensek. Ha vannak összetett kulcsjelöltek, de nincs köztük átfedés, akkor is ekvivalens a két dolog. Probléma csak akkor adódik, ha több összetett kulcsjelöltünk van, és átfedés van közöttük, bár ebből sem következik feltétlenül, hogy a 3NF reláció nem BCNF. Lehetséges, hogy a 3NF reláció nem BCNF, tehát meg ezt meg kell vizsgálni. Egy-egy normálforma tekintetében az előírás dogmaszerű felfogása, szigorú betartása helyett azokat a szempontokat célszerű végiggondolni, amelyek miatt a normálforma betartása érdekes lehet: redundancia, illetve (törlési, módosítási, beszúrási) anomáliák elkerülése. Ezek 10/35 a szempontok a

tervezés különböző fázisaiban különböző súllyal versengenek más szempontokkal: - a tervezés analizáló, korai fázisaiban azzal a szemponttal, hogy minél természetesebben, egyszerűbb leképezéssel modellezzük a világot; - a tervezés későbbi, megvalósítást előkészítő fázisaiban mindinkább hatékonysági szempontok válnak lényegessé. Osztott adatbázisok Az adatbázis fizikai megvalósítása szerint megkülönböztetnek integrált és osztott (interfaceelt) adatbázisokat. Integrált adatbázis esetén egyetlen adatbázismotor tartalmazza az információs rendszer adatbázisát, míg osztott adatbázis esetén az fizikailag különálló adatbázis motorokban helyezkedik el. A konkrét szervezet feladatrendszere dönti el, hogy melyik az optimális megoldás. Osztott adatbázis Az osztott adatbázis olyan logikailag egységes adatbázis, melyet fizikailag különböző, egymással összekapcsolt számítógépeken valósítanak meg. Ezek a

számítógépek lehetnek hardver és szoftver szempontjából azonos típusúak, ekkor a rendszer homogén, míg az összes többi esetben inhomogén. Az osztott adatbázisok előnyei: - a kevesebb kommunikáció miatt alacsonyabb üzemeltetési költség - az adatok a felhasználó közelében maradnak - az adatbázis-kezelő rendszer modulárisan építhető fel - az egyes csomópontok "menet közben" cserélhetők a rendszer leállítása nélkül - egy csomópont meghibásodása csak a kizárólagosan ott tárolt adatokat teszi elérhetetlenné Hátrányai: - a rendszer igen bonyolulttá válhat - inhomogén rendszereknél transzlációs problémák adódhatnak - problémát okozhat a személyzet beosztása, az ún. szuboptimalizálás, mely azt jelenti, hogy az egyes szakemberek megpróbálják az adott csomópontot a rendszer centrumává tenni - több jó szakember beszervezése is nehezebb, mint egy centrálisan működtetett adatbázisnál egy jó

szakemberé 11/35 - egyik csomópont sem zárhat be a többiek előtt, a működésére a többi csomópont miatt továbbra is szükség lehet A legtöbb problémát a rendszer konzisztenciája (egyértelműsége) jelenti. Az osztott adatbázisok megjelenésével fel kellett adni az adatbázis redundancia mentességének elvét. Gyakorlatilag bizonyos, hogy lesznek olyan adatok, melyeket több csomópont is a magáénak érez, s azokat saját gépén kívánja tárolni (pl.: az adott adatokat ezek a csomópontok közel azonos mértékben használják). Redundáns tárolással kímélhető a rendszer és költség megtakarítás érhető el. Megengedhetetlen azonban, hogy egy adat két példánya különböző értékű legyen (ebben az esetben egy kérdésre adott válasz az adatelérés útjától függene). Annak biztosítása, hogy a módosítások még rövid időre se okozzanak inkonzisztenciát, komoly erőfeszítést igényel. Osztott rendszer Az osztott rendszer olyan

adatbázis-kezelő rendszer, ahol köztes ún. Front-End számítógép vagy processzor szűri az igényeket. Az adatbázisok kezelésére az ún Back-End számítógépet vagy processzort alkalmazzák. A rendszer használata akkor kifizetődő, ha a nagyszámítógép kihasználtsága eléggé nagy. Terminálok B E Host F E 6. Ábra FE-BE rendszer Az adatok elhelyezése Az adatbázisok hatékonysága nagy mértékben múlik azon, hogy az adatok elosztása mennyire illeszkedik a feldolgozáshoz. Az adatok elosztása lehet statikus, amikor az adatbázis-felügyelő jelöli ki a másolatok számát és helyét (a statikus persze itt kvázi statikus, 12/35 mert a döntéseket időről időre felül kell vizsgálni). Dinamikus eloszlásnál a rendszer dönti el, hogy mikor célszerű egy-egy másolat készítése vagy éppen megszüntetése. OLTP Az On-line Transaction Processing, vagy magyarul tranzakciós rendszerek előszeretettel alkalmazzák a relációs adatbázisokat. A

normálformáknak megfelelő adatbázis az I/O rendszerek gyors és kényelmes használatát biztosítja, bár meglehetősen erőforrás igényes a legegyszerűbb művelet is. Mivel a relációk létrehozása és kezelése, a kulcsok generálása az adatbevitelnél real-time módon hajtódik végre, a háttérben történik az adatbázis karbantartása. Az egyes tranzakciók ilyen módon a felhasználó és az adatbázis kezelő interaktív kapcsolatát jelentik. Az OLTP alkalmazások jellemzően az irodai adatfeldolgozási feladatokat automatizálják, mint például rendelés bejegyzés, banki tranzakciók, amik egy szervezet egyszerű hétköznapi tevékenységei. Ezek az ismétlődő és struktúrált feladatok rövid, atomi, izolált tranzakciókat tartalmaznak. A tranzakciók napra kész és részletes adatokat igényelnek, valamint nem sok (néhányszor tíz) rekordot olvasnak és módosítanak, amelyeket általában az elsődleges kulcsukkal érnek el. Az operatív adatbázisok

mérete néhány száz megabyte-tól a gigabyte-okig terjedhet. Kritikus az adatbázis konzisztenciája és visszaállíthatósága és a teljesítménymérés kulcsa a tranzakció teljesítőképesség maximalizálása. Következésképpen az adatbázist arra tervezték, hogy az ismert alkalmazások műveleti szemantikáját kifejezze, és részben, hogy minimalizálja a konkurens konfliktusokat. OLAP A normálformák jelentőségének a korábbinál árnyaltabb megítélését az objektumorientált elvek mellett a relációs modell új, adatelemzést támogató alkalmazásai is elősegítik. Az OLAP (Online Analytical Processing) adatbázisok ugyanis egy-egy ténytábla köré csoportosított dimenzió- és összesítő (aggregátum) táblákra épülnek, vagyis redundáns csillag-, hópehelymodellt alkalmaznak az OLTP (Online Transaction Processing) normalizáltabb adatbázismodellje helyett. Az OLAP az Excel Pivot-tábláihoz hasonlóan lehetővé teszi a felhasználók

számára az információ gyors elérést és elemzését. Az OLAP kiszolgáló az adatokat multidimenziónális kockákban (CUBE) tárolja, melynek jellemzői a dimenziók és a mértékek. Az (OLAP) adattárházakat a döntés támogatásra irányozzák. A történeti, összesített, véglegesített adatok sokkal fontosabbak, mint a részletes, egyedi rekordok. Mivel az adattárházak véglegesített adatokat tartalmaznak, akár több operatív adatbázisból, nagy 13/35 időtartományból is, ezért nagyságrendekkel nagyobbak szoktak lenni, mint az operatív adatbázisok; a vállalati adattárházakat néhány száz gigabyte-tól terabyte-os méretűre tervezik. A terhelések lekérdezés (query) központúak, főként alkalmi, komplex lekérdezésekkel, amelyek rekordok millióit érhetik el és nagyon sok join-t, scan-t és aggregációt hajtanak végre. A lekérdezés teljesítőképessége és a válaszidők fontosabbak, mint a tranzakció teljesítőképessége. A komplex

analízisek és a megjelenítés megkönnyítésére a tárházban lévő adatokat multidimenzionálisan modellezik. Például egy üzleti adattárházban az eladás dátuma, körzete, az eladó és a termék lehet néhány lényeges dimenzió. Ezek a dimenziók gyakran hierarchikusak; az eladás dátuma nap-hónap-negyedév-év hierarchiába, a termék pedig termék-kategória-iparág hierarchiába szervezhető. A tipikus OLAP műveletek tartalmazzák a rollup-ot (a csoportosítás szintjét növeli) és a drill-down-t (csökkenti a csoportosítás szintjét vagy növeli a részletezettséget) egy vagy több dimenzió hierarchia mentén, valamint a slice and dice–t (szelekció és projekció) és a pivot-ot (átalakítja az adatok multidimenzionális képét). Mivel az operatív adatbázisokat az ismert OLTP terhelések támogatására hangolták, egy komplex OLAP lekérdezés futtatása elfogadhatatlan teljesítményt eredményezne. Ráadásul a döntés

támogatás olyan adatokat igényelne, amelyek az operatív adatbázisokból hiányozhatnak, például a trendek megállapítása vagy az előrejelzés készítés történeti adatokat igényel, ellenben az operatív adatbázisok csak az aktuális adatokat tárolják. A döntés támogatás általában több heterogén forrásból származó adat összegyűjtését igényli: ezek külső forrásokat is tartalmazhatnak, mint például a tőzsde ellátásánál, ráadásul számos operatív adatbázist. A különböző források változó minőségű adatokat tartalmazhatnak, vagy ellentmondó megjelenítéseket, kódokat, formátumokat használhatnak amelyeket össze kell hangolni. Végül, a multidimenzionális adatmodellek támogatása és a tipikus OLAP műveletek speciális adatszervezést, elérési és implementálási módszereket igényelnek, amelyeket a kereskedelmi, OLTP-re tervezett, DBMS-ek általában nem nyújtanak. Mindezek miatt az adattárházakat és az

operatív adatbázisokat külön-külön valósítják meg. ROLAP, MOLAP Az adattárházakat standard vagy kibővitett relációs DBMS-eken is megvalósíthatjuk, ezeket Relációs (Relational) OLAP (ROLAP) szervernek nevezzük. Ezek a szerverek feltételezik, hogy az adatokat relációs adatbázisokban tároljuk, és támogatják az SQL kiterjesztéseit és a speciális elérési és implementációs módszereket a multidimenzionális adatmodell és műveletek hatékony megvalósításához. Ezzel szemben a multidimenzionális OLAP 14/35 (MOLAP) szerverek speciális adatstruktúrákban (pl. tömbök) közvetlenül tárolják a multidimenzionális adatokat és ezeken a speciális adatstruktúrákon valósítják meg az OLAP műveleteket. Felépíteni és karbantartani egy adattárházat több, mint egy OLAP szerver kiválasztása és a séma és néhány komplex lekérdezés definiálása. Több alternatíva architektúra létezik. Több szervezet akar egy integrált vállalati

adattárházat implementálni, ami összegyűjti az összes témában az információkat (pl. vevők, termékek, eladások, vagyon, személyzet) átfogva az egész szervezetet. Azonban egy vállalati adattárház felépítése hosszú és komplex folyamat, ami kiterjedt üzleti modellezést igényel és sok évbe telhet mire sikerül. Sok szervezet megelégszik e helyett az data mart-okkal (szó szerint: adat piacok, azaz az adattárház részei), amik az osztályhoz tartozó a kiválasztott témákra összpontosító alhalmazok (pl. egy marketing data mart tartalmazhatja a vevőt, a terméket és az eladási információt) Ezek az data mart-ok lehetővé teszik a gyorsabb válaszadást (roll out), mivel nem igényelnek az egész vállalatra kiterjedő konszenzust, de hosszú távon komplex integrációs problémákhoz vezethetnek, ha nem alakítottak ki komplett üzleti modellt. Architektúra és End-to-End folyamat Az 7. ábra egy tipikus adattárház architektúrát mutat 15/35

7. Ábra Adattárház architektúra Eszközöket tartalmaz az adatok kinyerésére az összetett operatív adatbázisokból és külső forrásokból; ezeknek az adatoknak a megtisztítására, transzformálására, integrálására; az adatok adattárházba való betöltésére; és az adattárház periodikus frissítésére, amellyel a forrásokban történt módosításokat tükrözzük le, illetve kitakarítjuk az adatokat az adattárházból esetleg egy lassabb irattári tárolásra. A fő adattárházon kívül, még számos, 16/35 osztályhoz tartozó data mart is lehet. Az adattárházban és a data mart-okban lévő adatokat egy vagy több adattárház szerver tárolja és kezeli, amelyek multidimenzionális adatnézetet szolgáltatnak a különböző kliens oldali eszközök: lekérdező eszközök, jelentés írók, analizáló eszközök és adatbányászó eszközök, számára. Végezetül van még egy adatszótár (repository) a metaadatok tárolására és

kezelésére valamint az adattárház rendszert adminisztráló és ellenőrző (monitoring) eszközök. Az adattárházat feloszthatjuk a terhelés elosztás, a skálázhatóság (scalability) és a nagyobb elérhetőség érdekében. Az ilyen osztott architektúrában a metaadatok adatszótáráról általában az adat raktár minden részletével együtt másolat készül, és az egész adattárházat központilag adminisztrálják. Egy alternatív architektúra lehet az adattárházak vagy data martok szövetsége (federation), ahol mindegyiknek saját adatszótára és decentralizált adminisztrációja van. Akkor célszerű megvalósítani, ha egyetlen logikailag integrált vállalati adattárház felépítése túl költséges lenne. Adattárházat tervezni és kivitelezni (rolling out) komplex folyamat, a következő tevékenységeket tartalmazza: - Definiálni az architektúrát, megtervezni a kapacitást, és kiválasztani a tároló szervereket, az adatbázist és az OLAP

szervereket, valamint az eszközöket. - Integrálni a szervereket, a tárolókat és a kliens eszközöket. - Megtervezni az adattárház sémát és nézeteket. - Definiálni a fizikai adattárház szerveződést, az adat elhelyezést, a részekre bontást és az elérési módszereket. A forrásokhoz kapcsolódni átjárók (gateway), ODBC meghajtók vagy egyéb wrapper-ek segítségével. - Az adatok kivonására, tisztítására, átalakítására, betöltésére és frissítésére script-eket tervezni és implementálni. - A séma és a nézetek definícióját, a script-eket és egyéb metaadatokat az adatszótárba telepíteni. - A végfelhasználói (end-user) alkalmazások megtervezése és implementálása. - Kivitelezni (roll out) az adattárházat és az alkalmazásokat. Szerver oldali eszközök és segédprogramok Az adattárház rendszerek különböző adat kivonó és tisztító eszközöket, valamint betöltő és frissítő segédprogramokat

használnak az adattárház feltölésére. A külső forrásból történő kinyerés általában átjárókon és standa rd interface-eken (mint például Information Builders 17/35 EDA-SQL, ODBC, Oracle Open Connect, Sybase Enterprise Connect, Informix Enterprise Gateway) keresztül valósul meg. Adat tisztítás Mivel az adattárházakat döntéshozásra használják, fontos, hogy a bennük lévő adatok helyesek legyenek. Azonban mivel a nagy mennyiségű adat többszörös forrásból jön össze, nagyon valószínű, hogy az adatokban hibák és anomáliák vannak. Ezért azok az eszközök, amelyekkel az adat rendellenességek észrevehetők és kijavíthatók, jó eredményt hozhatnak. Néhány példa, ahol az adat tisztítás nélkülözhetetlenné válik: ellentmondó mező hosszak, leírások és érték hozzárendelések, hiányzó bejegyzés és az integritási feltételek megsértése. Nem meglepően, az adat beviteli űrlapokban (forms) lévő opcionális mezők az

inkonzisztes adatok jelentős forrásai. Az adat tisztító eszközöknek három, egymással kapcsolatban álló, de némiképp különböző, osztálya van. A data migration (adat vándorlási) eszközök egyszerű transzformációs szabályok megadását engedik, pl."helyettesítse be a gender [nem] karakterlánc helyére a sexet [nem]" A Warehouse Manager Prism-től példa egy ilyen típusú népszerű eszközre A data scrubbing (adat súroló vagy tisztító, az adat tisztítás, data cleaning, része) eszközök domainspecikikus ismereteket (pl. postai címzések) használnak az adatok megtisztításához Gyakran hasznosítják a nyelvtani elemző és fuzzy illesztő technikák at, hogy megtisztíthassák a különböző forrásokból származó adatokat. Néhány eszköz lehetővé teszi, hogy megadjuk a források "relatív tisztaságát". Ebbe a kategóriába tartozó eszközök például az Integrity és a Trillum. A data auditing (adat auditáló)

eszközök lehetővé teszik a scan-elt adatok közötti kapcsolatok és szabályok felderítését (vagy jelzik a megállapított szabályok megsértését). Így ezeket az eszközöket a data mining (adat bányászó) eszközök változatainak tekinthetjük. Például egy ilyen eszköz (a statisztikai analízis alapján) gyanús mintát fedezhet fel, hogy egy bizonyos autóügynökre sohasem panaszkodnak. Feltöltés Miután kinyertük, megtisztítottuk és átalakítottuk az adatokat, be kell töltenünk azokat az adattárházba. További előfeldolgozások (preprocessing) lehetnek még mindig szükségesek: az integritási feltételek ellenőrzése; rendezés; összegzés, csoportosítás és egyéb számítások, hogy felépítsük az adattárházban tárolt leszármaztatott táblákat; az indexek és egyéb elérési útvonalak építése és több különféle cél tároló területekre osztása. Erre a célra tipikusan batch betöltő segédprogramokat használnak. Az

adattárház feltöltésén kívül a betöltő segédprogramnak meg kell engednie, hogy a rendszer adminisztrátor felügyelhesse az 18/35 állapotot, törölhesse, felfüggeszthesse és újrakezdhesse a betöltést és a hiba után az adatintegritás elvesztése nélkül újraindíthassa azt. Az adattárházak töltő segédprogramjainak sokkal nagyobb mennyiségű adattal kell foglalkozniuk, mint az operatív adatbázisoknak. Csak egy kis idő ablak van (általában éjszaka) amikor az adattárház a frissítés érdekében offline lehet. A szekvenciális betöltések nagyon hosszú időt vehetnek igénybe, pl. egy terabyte-nyi adat betöltése heteket és hónapokat vehet igénybe. Ezért tipikusan a pipeline-ozott és partícionált párhuzamosságot használj ák Egy teljes betöltésnek az az előnye, hogy olyan hosszú batch tranzakciónak tekinthetjük, ami egy új adatbázist épít fel. Amíg az folyamatban van, az aktuális adatbázis még kiszolgálhatja a

lekérdezéseket, amikor a betöltési tranzakció sikeresen befejeződött (commit-tal), az aktuális adatbázist felcseréljük az újjal. Periódikus checkpoint-ok használatával biztosíthatjuk, hogy ha hiba történik a töltés során, a folyamat legutolsó checkpoint-tól indulhat újra. Azonban még párhuzamosságot használva is túl hosszú lehet a teljes betöltés. A kereskedelmi segédprogramok zöme (pl. RedBrick Table Management Utility) inkrementális töltést használ a frissítés alatt, hogy csökkentse az adat raktárba töltendő adatok mennyiségét. Csak a módosított rekordokat szúrják be. Azonban ilyenkor a töltési folyamat nehezebben kezelhető Az inkrementális töltés ellentmondásba kerülhet a folyamatban lévő lekérdezésekkel, így azt rövidebb tranzakciók sorozataként kezelik (amelyek periódikusan commit-álódnak, pl. minden 1000 rekord után, vagy minden néhány másodpercben), de most ezt a tranzakció sorozatot koordinálni kell,

hogy biztosítsuk a származtatott adatok és az indexek konzisztenciáját a bázis adatokkal. Frissítés Egy adattárház frissítése abban áll, hogy továbbítja a forrás adatokon végzett módosításokat, hogy megfelelően módosítsa az adattárházban tárolt bázis adatokat és leszármazott adatokat. A frissítés kiadásának két irányzatát lehet tekinteni: mikor és hogyan. Általában az adattárházakat periódikusan frissítik (pl. naponta vagy hetente) Csak ha néhány OLAP lekérdezés aktuális adatokat igényel (pl. percre pontos tőzsdei jegyzések) van szükség minden módosítás továbbítására. A frissítési politikát az adattárház adminisztrátor állítja be Ez függ a felhasználók szükségleteitől és forgalmától és különböző forrásokra különböző lehet. A frissítési technikák a forrás karakterisztikáktól és az adatbázis szerverek képességétől is függenek. Teljes forrás file-t vagy adatbázist kivonni általában túl

költséges, de lehetséges, hogy ez az egyetlen lehetőség a forrásból adatot kinyerni. A kortárs adatbázis rendszerek zöme replikáció szervereket szolgáltat, amelyek az inkrementális technikákat támogatják, a 19/35 módosítások elsődleges adatbázisból az egy vagy több másolat felé terjesztésére. Ilyen replikáció szervereket használhatunk egy adattárház inkrementális frissítéséhez, amikor a források megváltoznak. Két replikációs technika van: adat szállítás (shipping) és tranzakció szállítás. Az adat szállításnál (amit pl az Oracle Replication Server-ben, Praxis OmniReplicator-ban használnak), egy az adattárházban lévő táblázatot úgy tekinthetünk, mint a forrás adatbázisban lévő táblázat távoli snapshot-ját. Az after row triggert a snapshot log tábla frissítésére használják, akárhányszor megváltozik a forrás tábla, és van egy automatikus frissítő ütemezés (vagy kézi frissítő eljárás) set

up-oknak, hogy továbbítsa a módosított adatokat a távoli snapshot-ra. A tranzakció szállításban (amit pl. a Sybase Replication Server-ben és a Microsoft SQL Server-ben használnak) szabályos tranzakció log-ot használnak a triggerek és a speciális snapshot log tábla helyett. A forrás oldalon a tranzakció log-ot vizsgálják, hogy észrevegyék a módosításokat a másolt táblákon, és azokat a log rekordokat elküldik a replikációs szervernek, amely összepakolja a megfelelő tranzakciókat a másolatok módosítására. A tranzakció szállítás előnye, hogy nem igényel triggereket, amelyek növelhetik az operatív forrás adatbázisok terhelését. Azonban különböző forgalmazók DBMS-ein keresztül ez nem mindig használható könnyen, mert nincs szabványos API a tranzakció napló (log) elérésére. Az adattárházak frissítésére ilyen másolati szervereket használnak. Azonban a frissítési ciklust helyesen kell kiválasztani, hogy az adat

mennyiség az inkrementális töltő segédprogramot el ne árassza. Azon túl, hogy az adattárházban lévő bázis adatokhoz továbbítjuk a változásokat, a származtatott adatokat szintén megfelelően módosítani kell. Az adattárházakban a származtatott adatok legjelentősebb osztályai az összegző táblák, az egyedi-tábla indexek és a join indexek. Fogalmi (conceptual) modell és kliens oldali eszközök Egy népszerű fogalmi modell, ami az kliens oldali eszközöket, az adatbázis tervezést és az OLAP-hoz szükséges lekérdező eszközöket befolyásolja, az adattárházban lévő adatok multidimenzionális nézete. A multidimenzionális adatmodellben létezik a numerikus mértékeknek, amelyek az analízis tárgyai, egy halmaza. Ilyen mértékekre példák az eladások, a költségvetés, a bevétel, a leltár, az ROI (return of investment, befektetés megtérülése). Minden egyes numerikus mérték egy dimenzióhalmaztól függ, ez adja meg a mértékhez a

kontextust. Például a dimenziók, amik az eladási mennyiséghez kapcsolódnak, lehetnek a város, a termék neve és az eladás dátuma. Feltesszük, hogy a dimenziók együtt egyértelműen meghatározzák a mértéket. Így a multidimenzionális adat egy mértéknek látszik, mint egy 20/35 érték a dimenziók multidimenzionális terében. Minden egyes dimenziót a tulajdonságok egy halmaza ír le. Például a termék dimenzió négy tulajdonságot tartalmazhat: a termék kategóriáját és ipar(ág)át, a bevezetésének évét és az átlagos határhasznot. Például a Surge szóda az ital kategóriához és az élelmiszeriparhoz tartozik,1996-ban vezették be és 80%-os átlagos határhaszna lehet. Egy dimenzió tulajdonságai hierachikus összefüggéseken keresztül kapcsolódhatnak egymáshoz. A fenti példában a termék neve és annak kategória illetve ipar tulajdonsága között ilyen hierarchikus viszony áll fenn. Az OLAP fogalmi modelljének másik

megkülönböztető jegye a mértékek egy vagy több dimenzióval, mint a kulcs műveletek egyikével, való csoportosítására helyezett hangsúlya. Például a teljes eladások kiszámítása és rangsorolás a minden megyére (vagy minden évben). Más elterjedt műveletek az azonos dimenziók szerint csoportosított mértékek (pl. eladások és költségvetés) összehasonlítását tartalmazzák. Az idő egy olyan dimenzió, ami különösen jelentős a döntés hozásban (pl. trend elemzés) Gyakori kívánalom, hogy legyen beépített naptár és az idő dimenzió egyéb megjelenése. Kliens oldali eszközök A multidimenzionális adatmodell az üzleti adat szemléletből nőtt ki, amit az üzleti elemzéseknél széleskörűen használt PC-s táblázatkezelő (spreadsheet) programok tettek népszerűvé. A táblázatkezelők még mindig a legellenállhatatlanabb előtér alkalmazások az OLAP-ban. Egy OLAP lekérdező környezetnél a kihívást durván úgy foglalhatnánk

össze, mint a táblázatkezelő műveletek hatékony megvalósítását a nagy multi-gigabyte-os adatbázisokon. Valóban, pl az Arbor Corporation Essbase terméke, vagy az SMS (illetve újabban Siemens) Novius terméke is Microsoft Excel-t használ kliens oldali multidimenzionális eszközéhez. A multidimenzionális táblázatkezelő alkalmazások által támogatott leggyakoribb műveletek: - pivoting: 21/35 8. Ábra Multidimenzionális adat Tekintsük a 8. ábra multidimenzionális sémáját, amit egy rovatos táblázatban jelenítettünk meg ahol minden egyes sor megfelel egy eladásnak. Legyen egy oszlop minden dimenziónak és egy extra oszlop az eladás mennyiségét reprezentálja. A pivotálást legegyszerűbben úgy tekinthetjük, hogy kiválasztunk két dimenziót amiket egy mérték, pl. az eladás a fenti példában, csoportosítására használunk. A csoportosított értékeket gyakran egy rácsban (grid) jelenítjük meg, ahol minden érték az adott

mérték csoportosított értékének megfelelő (x, y) koordinátában van, mikor is az első dimenzió értéke x, a második dimenzióé pedig y. Így a példánkban, ha a város és az év a választott dimenziók, akkor x-tengely reprezentálhatja a városok értékeit, és az y-tengely pedig az éveket. Az (x, y) pont pedig az x város y évi 22/35 aggregált eladásait jelenti. Így az eredeti táblázatbeli érték a pivotált táblázatban sor és oszlop fej (header) lett. - rollup és a drill-down: A rollup annak felel meg, hogy veszünk egy aktuális objektumot és további group-by műveletet végzünk az egyik dimenzión. Így lehetséges “felgöngyölíteni” az eladási adatokat, amelyek már csoportosítva lehetnek a városok és termékek szerint. A drill-down operáció a rollup ellentéte A slice and dice megfelel az adat dimenzionáltság csökkentésének, azaz veszi az adatok egy projekcióját a dimenziók egy részhalmazán más dimenziók

kiválasztott értékeiért. Például elvégezhetjük a műveletet az eladási adatokon egy jellegzetes termékre, hogy létrehozzunk egy táblát, ami az eladás dátumát és városát tartalmazza, mint dimenziót. Az egyéb elterjedt operátorok tartalmazzák a ranking-ot (rendezés), szelekciókat és számított jellemzőket definiálnak. Managed query environment Ámbár a multidimenzionális táblázatkezelők nagy érdeklődésre tartottak számot mióta felhatalmazták a felhasználót, hogy elemezzék az üzleti adatokat, nem helyettesítik a managed query environment-el segített hagyományos analízist. Ezek a környezetek tárolt eljárásokat és előredefiniált komplex lekérdezéseket használnak azért, hogy az analizáló eszközök csomagját szolgáltassák. Az ilyen eszközök gyakran lehetővé teszik a felhasználónak a lekérdezést a domain specifikus üzleti adatok tagjaiban. Ezek az eszközök gyakran alap adat elérési eszközöket használnak és az

elérési mintákat a szerver oldali adatbázis szerverektől függően optimalizálják. Ráadásul vannak lekérdező környezetek (pl: Microsoft Access), amik az alkalmi SQL lekérdezések felépítésében segítenek a “kijelöl és kattint” technikával. Végül, változatos adatbányászó eszközök léteznek, amiket gyakran az adattárházak kliens oldali eszközeiként használnak. Adatbázis tervezési módszertan Amikor relációs ROLAP szervert használunk, a multidimenzionális modellt és a műveleteit kapcsolatokra és SQL lekérdezésekre kell leképeznünk. Ebben a fejezetben leírjuk az olyan relációs adatbázis sémák tervezését, amik tükrözik az multidimenzionális adatnézetet. Az egyed kapcsolat diagramokat (ER diagram) és a normalizációs technikákat széleskörűen használják az OLTP környezetekben adatbázis tervezésre. Azonban az ER diagramos tervezés nem alkalmas döntés támogató rendszerekhez, ahol a lekérdezések és az adat

betöltések (beleértve az inkrementális töltést) hatékonysága fontos. Az adattárházak zöme a multidimenzionális adatmodell megjelenítésére a csillag sémát használja. Az adatbázis egy ténytáblát és minden dimenzióhoz egy-egy táblát tartalmaz A 23/35 ténytáblában minden mező egy pointert tartalmaz (kapcsolókulcs – gyakran használnak a hatékonyság érdekében generált kulcsot) minden egyes dimenzióhoz ami a multidimenzionális koordinátáit adja és ezekhez a koordinátákhoz tárolja a numerikus mértékeket. Mindegyik dimenziótábla oszlopokat tartalmaz, amelyek a dimenzió jellemzőinek felelnek meg. A 9 ábra a csillag sémára mutat egy példát. 24/35 25/35 9. Ábra Csillag séma A csillag séma nem támogatja határozottan a jellemzők hierarchiáját. A hópehely séma a csillag séma finomítását nyújtja, ahol a dimenzionális hierarchia világosan megjelenik a dimenziótáblák normalizációja által, amint a 10.

ábra mutatja Ez előnyhöz vezet a dimenziótáblák megtartásában. 26/35 10. Ábra Hópehely séma Azonban a dimenziótáblák csillag sémabeli nem normalizált struktúrája előnyös lehet a dimenziók nézegetésénél. 27/35 Adattárház szerverek Az adattárházak nagy mennyiségű adatot tartalmazhatnak. Hogy hatékonyan válaszolhasson a lekérdezésekre nagyon hatékony elérési módszereket és lekérdezés feldolgozó technikákat igényelnek. Számos kérdés merül fel: először is, az adattárházak redundáns struktúrákat használnak, mint például az indexek és a materialized view-k. Azt kiválasztani, hogy melyik indexeket építsük fel és melyik nézeteket valósítsuk meg, fontos fizikai tervezési probléma. A következő kihívás a létező indexek és megvalósított nézetek hatékony használata a lekérdezések megválaszolásához. A komplex lekérdezések optimalizálása egy másik fontos probléma. Míg az adat-szelektív

lekérdezésekhez a hatékony index scan lehet célravezető, az adat-intenzív lekérdezések a szekvenciális scan használatát igénylik. Így a scan hatékonyság fejlesztése fontos dolog. Végül, szükséges, hogy kihasználjuk a párhuzamosságot a válaszidők csökkentése érdekében. Index struktúrák és használatuk Számos hasznos lekérdezés feldolgozó technika van, amik az indexeket kihasználják. Például az összetett feltételek szelektivitása az indexek metszetével hasznosítható. Másik hasznos index művelet az indexek uniója. Ezen index műveletek használatával jelentősen csökkenthetők, vagy számos esetben ki is zárhatók a bázistáblákhoz való hozzáférések. Az adattárház szerverek bitmap indexeket használhatnak, amelyek támogatják a hatékony index műveleteket (pl.: unió, metszet) Tekintsünk egy leaf page-et (levél az index fában) egy a d domain értéknek megfelelő index struktúrán. Egy ilyen leaf page hagyományosan a d

értéket tartalmazó rekordok rekord azonosítójinak (record id: RID) listáját tartalmazza. Azonban a fenti RID listának egy alternatív megjelenítését használják a bitmap indexek, egy bitvektort ami minden egyes rekordhoz egy bitet tartalmaz, amelyeket akkor állítunk be, ha az ahhoz a rekordhoz tartozó domain értéke d. Egy értelemben a bitmap index nem egy új index struktúra, hanem egyszerűen az RID lista egy alternatív megjelenítése. A bitmap index népszerűsége annak a ténynek köszönhető, hogy az RID lista bitvektoros reprezentációja fel tudja gyorsítani az index metszetet, uniót, join-t és aggregációt1 1. Például, ha van az alábbi formájú lekérdezésünk: column1 = d & column2 = d, akkor a megfelelő rekordokat úgy azonosíthatjuk, hogy vesszük a két bit vektor ÉS műveletét. Amíg az ilyen ábrázolás hasznos lehet az alacsony számosságú (cardinality) domainekhez (pl.: nem), azok szintén hatékonyak lehetnek a nagyobb

számosságú domainekhez a bitmap-ek kompressziójának segítségével (pl.: run length encoding, RLE 28/35 tömörítő algoritmus). A bitmap indexeket eredetileg a 204-es Modellben használták, de ma már számos termék támogatja őket (pl.: Sybase IQ) Érdekes kérdés annak eldöntése, hogy melyik jellemzőt indexeljük. Általában ez egy olyan kérdés amit valójában a fizikai adatbázis tervezési folyamatnak kell megválaszolnia. Az egyszerű táblákon lévő indexeken kívül a csillag séma speciális természete a döntés támogatáshoz különösen vonzó join indexeket is létrehoz. Amíg a hagyományos indexek letérképezik az oszlopban lévő értéket egy az adott értékkel rendelkező sorok listájába, egy join index fenntartja a kapcsolatot egy kapcsolókulcs és a hozzá illő elsődleges kulcs között. A csillag séma összefüggésében, egy join index össze tudja kapcsolni egy dimenziótábla egy, vagy több jellemzőjének az értékét a

ténytáblából hozzá illő sorokkal. Például tekintsük a 9 ábra sémáját Lehet egy join index a városokra, ami fenntartja minden városra a ténytáblában lévő mezők RID listáját, ami megfelel az eladásoknak abban a városban. Így egy join index lényegében előreszámít egy binary join-t A multikulcsos join indexek n-szeres előszámított join-okat ábrázolhatnak. Például az eladások adatbázis felett készíthetünk egy multidimenzionális join indexet tőle (városnév, terméknév) a ténytábla felé. Így a (Seattle, kabát) index bejegyzés azoknak az eladás táblában lévő mezőknek az RID-jére mutat, amelyek rendelkeznek a fenti kombinációval. Egy ilyen multidimenzionális join indexet használva mentesülhetünk néha attól, hogy a városnév és terméknév különálló indexeinek a metszetét vegyük. Join indexeket használhatunk bitmap ábrázolással az RID listákhoz a join feldolgozás hatékonysága érdekében. Végül, a döntés

támogató adatbázisok jelentős mennyiségű leíró szöveget tartalmaznak, így hasznos, ha indexek támogatják a szövegkeresést. Materialized view-k és használatuk Sok adattárház feletti lekérdezés összegzett adatokat igényel, és ezért aggregációkat használ. Ezért, az indexeken kívül, a megvalósult összegző adatok segíthetnek az egyszerű lekérdezések gyorsításában. Például egy beruházási környezetben a lekérdezések nagy többsége a Legaktuálisabb negyedév és a folyó költségvetési év teljesítményén alapulhat. Ha vannak összegzett adataink ezeken a paramétereken, akkor jelentősen gyorsítják a lekérdezési folyamatot. A megvalósított nézetek kihasználásában lévő kihívások nem különböznek az index használatban lévőktől: (a) azonosítani a nézeteket a megvalósításhoz, (b) kihasználni a megvalósított nézeteket a lekérdezés megválaszolásában és (c) hatékonyan módosítani a megvalósított nézeteket a

betöltés és a frissítés alatt. Az ezekhez a problémákhoz jelenleg alkalmazott ipari megoldások a megvalósított nézeteket viszonylag egyszerű struktúrájúnak tekintik. Az ilyen nézetek a ténytáblának a 29/35 dimenziótáblák (azokon a dimenziókon vett néhány szelekció után lehetséges) részhalmazával alkotott join-jait tartalmazzák, egy vagy több, a dimenziótáblából vett attribÚtumok halmazával csoportosított, mérték aggregációjával. Ezeknek a nézeteknek a struktúrája kicsit komplexebb amikor az alapul szolgáló séma a hópehely. A korlátozott forma ellenére, még mindig sok választási lehetőségünk van a nézetek megvalósítására. A megvalósításhoz a nézetek kiválasztásánál figyelembe kell venni a terhelés karakterisztikáját, az inkrementális (növekményes) update költségeit és a tárolási követelmények felső határát. Szerver architektúrák a lekérdezés feldolgozáshoz A hagyományos relációs

szerverek nem voltak felszerelve az indexek és egyéb kellékek intelligens használatára az adatok multidimenzionális nézetének a támogatására. Azonban most már minden relációs DBMS gyártó gyorsan rámozdult ezeknek a további követelményeknek a támogatására. A hagyományos relációs szervereken kívül három másik szerver kategória van, amiket kimondottan a döntés támogatáshoz fejlesztettek ki. - Specializált SQL szerverek: A Redbrick az ilyen osztályú szerverek példája. Itt a cél az, hogy a csak olvasható környezetben, a csillag és hópehely séma feletti SQL lekérdezésekhez fejlett lekérdező nyelvet és lekérdezés feldolgozás támogatást nyújtsanak. - ROLAP szerverek: Ezek olyan közepes szerverek, amelyek a relációs háttér szerver (ahol az adattárházban tároljuk az adatokat) és a kliens oldali eszközök között vannak. A Microstrategy például egy ilyen szerver. - HOLAP szerverek: Kiterjesztik a hagyományos relációs

szervereket egy specializált middleware-rel, hogy hatékonyan támogassák a multidimenzionális OLAP lekérdezéseket, és általában optimalizálják különleges szerver oldali relációs szerverekre. Azonosítják a megvalósítandó nézeteket, átírják az adott felhasználói lekérdezéseket a megfelelő megvalósított nézetek kifejezésévé és generálják a több utasításos (multi-statement) SQL-t a háttér szervernek. További szolgáltatásokat is nyújtanak, mint a lekérdezések ütemezése és a források hozzárendelése (pl.: meggátolja a lekérdezések elszabadulását [runaway]) Trend volt a ROLAP szerverek domain specifikus ROLAP eszközökhöz hangolása. A ROLAP szerverek fő ereje, hogy kihasználják a skálázhat óságot és a relációs rendszerek tranzakciós tulajdonságait. Azonban a hibás belső illesztések a OLAP-stílusú lekérdezés és az SQL között (pl.: oszlop aggregáció, szekvenciális feldolgozás hiánya) az OLAP szervernél

szűk keresztmetszeteket okozhat a teljesítményben. 30/35 - MOLAP szerverek: Ezek a szerverek közvetlenül támogatják az adatok multidimenzionális szemléletét a multidimenzionális tároló eszközön keresztül. Ez lehetővé teszi, hogy multidimenzionális kliens oldali lekérdezéseket implementáljanak a tároló rétegen direkt leképezésen keresztül. Az Essbase (Arbor) például egy ilyen típusú szerver Egy ilyen megközelítés előnye a kitűnő indexelési tulajdonságok, de gyenge tárolási kihasználtságot nyújt, főleg, ha az adathalmaz ritkás. Sok MOLAP szerver alkalmaz egy kétszintű tárolási ábrázolást, hogy a ritkás adathalmazokhoz illesszék és széleskörűen használják a tömörítést. A kétszintű tárolási ábrázolásban egy vagy két dimenzionális résztömb halmazát, ami valószínűleg sűrű, azonosítják a tervező eszközök használatával vagy felhasználói bemenettel, és tömb formában ábrázolják. Azután a

hagyományos indexelési strutúrát használják ezeknek a kisebb tömböknek az indexelésére. Sok technika, amit a statisztikai adatbázisokhoz agyaltak ki a MOLAP szerverekhez is helytállónak tűnik. - SQL kiterjesztések: Számos SQL kiterjesztést, amik megkönnyítik az OLAP lekérdezések kifejezését és feldolgozását, szántak vagy implementáltak a kiterjesztett relációs szerverekbe. A kiterjesztett aggregáció függvénycsalád tartalmazza a rank (sorba állít) és a percentile (százalék) (pl.: minden termék a felső tíz százalékban, vagy az első tíz termék a teljes eladás szerint) valamint különböző a pénzügyi analízisben használt függvény támogatását (mean [átlag], mode [modus, leggyakoribb érték], median [középső]). - Jelentés készítési lehetőségek: Az üzleti analízisben készített jelentések gyakran igényelnek idő ablakban kiértékelt tulajdonságokat pl.: mozgó átlag Ráadásul fontos, hogy töréspontokat és

részösszegeket is tudjon szolgáltatni. A Redbrick SQL kiterjesztései rendelkeznek ezekkel a primitívekkel. - Többszörös group-by: Az kliens oldali eszközök, mint a multidimenzionális táblázatkezelők, különböző attributumok halmazokain csoportosítást igényelnek. Ezt szimulálhatjuk SQL utasítások halmazával, ami ugyanannak az adathalmaznak a többszöri scan-jét igényli, de ez lehet, hogy nem hatékony. Manapság két új operátort, cube és rollup, szántak az SQL kiegészítésére, erre a problémára nézve. Így a jellemzők listájának rollup-ja (termék, év, város) egy adathalmazon egy válaszhalmazt eredményez a group-by következő alkalmazásaival: (a) group by (termék, év, város), (b) group by (termék, év) és (c) group by termék. Másfelől, ha adott a k oszlopok egy halmaza, a cube operátor egy group-by-t szolgáltat az oszlopok minden egyes 2k kombinációjára. Ilyen összetett group-by operációkat hatékonyan futtathatunk

felismerve közöttük a közösségeket. A Microsoft SQL Server támogatja a cube és a rollup műveleteket. 31/35 Metaadat és adattárház management Mivel egy adattárház egy vállalkozás üzleti modelljét tükrözi, az adattárház architektúra alapvető eleme a metaadat management. Sok különböző fajta metaadatot kell menedzselni Az adminisztratív metaadatok minden, az adattárház beállításához és használatához szükséges információt tartalmaznak: a kliens és szerver oldali eszközök valamint a forrás adatbázisok leírását; az adattárház séma, a leszármaztatott adatok, a dimenziók és hierarchiák, az előredefiniált lekérdezések és jelentések definícióit; az data mart-ok elhelyezkedését és tartalmát; a fizikai szerveződést mint például az adat partíciókat; adat kivonási, tisztítási és transzformálási szabályokat; adat frissítési és megtisztítási politikát; és felhasználói profile-t, felhasználói jogosultság

és hozzáférés ellenőrzési politikákat. Az üzleti metaadatok az üzleti fogalmakat és definíciókat valamint az adatok birtoklását és a töltési politikákat tartalmazzák. A műveleti etaadatok az adattárház működése során összegyűjtött információkat tartalmazzák: a mozgatott és transzformált adatok eredete; az adattárházban lévő adatok érvényessége (currency) (aktív, archivált, megtisztított); és monitoring információk, mint például a használat statisztikái, hiba jelentések, audit trail (tevékenységnapló). Gyakran használnak egy metaadat adatszótárt az összes, az adattárházhoz kapcsolt metaadat tárolására és managelésére. Az adatszótár megengedi a metaadatok megosztását az eszközök és folyamatok között, egy adattárház tervezéséhez, beállításához, használatához, működéséhez és adminisztrálásához. A kereskedelmi példák a Platinium Repository-t és a Prism Directory Manager-t tartalmazzák.

Egy adattárház rendszer készítése és manage-elése nehéz dolog. A sémák, nézetek, script-ek, szabályok, lekérdezések és jelentések tervezésére és szerkesztésére fejlesztő eszközöket használnak. Tervező és analizáló eszközöket használnak a kapacitás tervek készítésre és a mi-történik-ha (what-if) forgatókönyvekhez, mint például a frissítési arány vagy a sémaváltozás hatásának a megértése. A management eszközök (pl: HP Intelligent Warehouse Advisor, IBM Data Hub, Prism Warehouse Manager) az adattárházak monitorozására használják, valamint statisztikai jelentésekre és stratégiai menedzsmentnek szóló javaslatok tételére: A partíciók és az összegző táblák használata, lekérdezés futási idők, a drill down-ok vagy rollup-ok típusa és gyakorisága, melyik felhasználók vagy csoportok melyik adatokat kérik, csúcsok és átlagos terhelések az időben, kivételek jelentése, elszabadult lekérdezések

detektálása és egyéb a szolgáltatást minősítő mértékek. A rendszer és hálózat management eszközö ket (pl.: HP OpenView, IBM NetView, Tivoli) arra használják, hogy mérjék a forgalmat a kliensek és a szerverek között, az adattárház és az operatív adatbázisok között és így tovább. Végül, csak mostanában tekintették az workflow management eszközöket a 32/35 kivonás-tisztítás-transzformáció-betöltés-frissítés folyamat menedzselésére. A folyamat lépései meghívhatják az adatszótárban tárolt megfelelő script-eket és periodikusan indíthatóak, igény szerint vagy egy meghatározott esemény történésekor. A workflow eszköz a folyamat sikeres végrehajtását biztosítja, állandóan rögzíti minden egyes lépés sikeres vagy hibás voltát és hiba helyreállítást nyújt részleges roll back-kel, retry-vel (újra probálkozás) vagy roll forward -dal. 33/35 Irodalomjegyzék - - Kovács Ferenc, Monostori Krisztián:

Bevezetés a relációs adatbázis-kezelésbe, BME, Egyetemi jegyzet Daragó László: Az SDM adatmodell alkalmazása adatbázis tervezéshez, DE-EFK, Főiskolai jegyzet Surajit Chaudhuri, Umeshwar Dayal: Az adattárház (data warehousing) és az OLAP technológia áttekintéseAz adattárház (data warehousing) és az OLAP technológia áttekintése, http://www.olapcouncilorg Csernoch János: Adatbázisok, KKMF, Jegyzet Widom J,: Research Problems in Data Warehousing. Proc 4tf Intl CIKM Conf, 1995 Kimball R.: The Data Warehouse Toolkit John Wiley, 1996 34/35 Ábrajegyzék 1. Ábra Management Information System 2 2. Ábra EDP: I/O 3 3. Ábra EPD: lekérdezés 4 4. Ábra EDP: kaszkádolt lekérdezés 4 5. Ábra EDP: jelentés 5 6. Ábra FE-BE rendszer 12 7. Ábra Adattárház architektúra 16 8. Ábra Multidimenzionális adat 22 9. Ábra Csillag séma 26 10. Ábra Hópehely séma 27 35/35