Intelligens Adattárházak

DEBRECENI EGYETEM INFORMATIKAI KAR INFORMÁCIÓ TECHNOLÓGIA TANSZÉK

Intelligens Adattárházak Diplomamunka

Debrecen 2009.

Dr. Juhász István

Csepei Csaba

egyetemi adjunktus

programtervezımatematikus szak

Intelligens Adattárházak

1

TARTALOMJEGYZÉK

1

Tartalomjegyzék................................................................................................................... 2

2

Bevezetés ............................................................................................................................... 4

3

Adattárház koncepciók ........................................................................................................ 5

3.1 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.3 3.4 3.5 3.5.1 3.5.2 3.5.3 3.5.4 3.6 3.6.1 3.6.2

Mi az adattárház? ................................................................................................................... 5 Az adattárház jellemzıi .......................................................................................................... 5 Tárgyorientált.........................................................................................................................5 Integrált ..................................................................................................................................5 Nem illékony..........................................................................................................................6 Idıben változó........................................................................................................................6 Operatív adatbázisok és az adattárházak ................................................................................ 6 OLTP és OLAP rendszerek.................................................................................................... 8 Az adattárház komponensei ................................................................................................. 10 Operatív forrás rendszerek ...................................................................................................10 Átmeneti adattároló terület...................................................................................................11 Adat megjelenítési terület ....................................................................................................12 Adathozzáférési eszközök....................................................................................................13 Adatok az adattárházban ...................................................................................................... 13 Adatok típusai ......................................................................................................................13 Metaadatok...........................................................................................................................14

4

Adattárház tervezés............................................................................................................ 14

4.1 Adattárház architektúrák ...................................................................................................... 14 4.1.1 Alap architektúra..................................................................................................................15 4.1.2 Architektúra egy összesítési területtel..................................................................................15 4.1.3 Architektúra egy összesítési területtel és adatpiacokkal ......................................................16 4.2 Adattárházak logikai és fizikai tervezése ............................................................................. 17 4.2.1 Logikai terv ..........................................................................................................................17 4.2.2 Fizikai terv ...........................................................................................................................18 5

Többdimenziós adatmodellezés......................................................................................... 18

5.1 5.1.1 5.2 5.3 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.4

Adatkockák .......................................................................................................................... 18 Kocka mőveletek..................................................................................................................20 MOLAP architektúra............................................................................................................ 23 ROLAP architektúra............................................................................................................. 23 Dimenziótáblák ....................................................................................................................24 Ténytáblák............................................................................................................................25 Tények és dimenziók összekapcsolása.................................................................................27 ROLAP adatmodellek ..........................................................................................................28 Többdimenziós modelltervezési folyamat ...........................................................................29 HOLAP architektúra ............................................................................................................ 30

6

ETL folyamatok.................................................................................................................. 31

6.1 6.2 6.3

Adatok kinyerése a forrásrendszerekbıl .............................................................................. 31 Adatok transzformációja ...................................................................................................... 33 Adatok betöltése az adattárházba ......................................................................................... 34

7

Intelligens Adattárházak ................................................................................................... 34

7.1 Üzleti Intelligencia ............................................................................................................... 37 7.1.1 Az üzleti intelligencia kategóriái..........................................................................................39 7.2 Döntéstámogató rendszerek, döntés hozás........................................................................... 40

IntelligensAdattárházak

2/51


7.3 Tudásfeltárás - KDD ............................................................................................................ 41 7.4 Adatbányászat ...................................................................................................................... 42 7.4.1 Az adatbányászat célja .........................................................................................................43 7.4.2 Adatok elıfeldolgozása........................................................................................................44 7.4.3 Adatbányászati technikák.....................................................................................................46 8

Összegzés............................................................................................................................. 48

9

Köszönetnyilvánítás ........................................................................................................... 49

10

Ábrajegyzék ........................................................................................................................ 50

11

Irodalomjegyzék................................................................................................................. 51


3/51


2

BEVEZETÉS Az információs rendszerek és technológiák fejlıdésével, a papír eszközökkel dolgozó irattárakat felváltották a számítógépes informatikai rendszerek, valamint egyre inkább elterjedt a gazdasági, üzleti, közigazgatási és kutatási tranzakciók számítógéppel történı végrehajtása. Ez azt eredményezte, hogy napról-napra több adat győlik össze a vállalatok adatbázisaiban. Az adatok mennyisége hihetetlen mértékben növekszik. Ez a felhalmozódó adatmennyiség gyakran inkább akadályozója, mint elısegítıje a tisztánlátásnak, mindaddig, amíg ezt a hatalmas adattömeget nem alakítjuk számunkra hasznos információvá és tudássá. Az adatok sokáig hagyományos adatbázisokban, vagy rendszerezett könyvtári állományokban győltek. Ezeket az adatokat kezdetben operatív adatbázisra épülı vezetıi információs rendszerekben kezelték. Ezután körülbelül két évtizede kezdtek el megjelenni az adattárházak. Ennek egy klasszikus példája, hogy Európa egyik legnagyobb bankjába, a hollandiai ABN AMRO bankba az 1990-es évek elején vezettek be egy sikeres kezdeti adattárház implementációt, de ennek a fejlesztései már az 1980-as évek végén megindultak. Minden vállalat üzleti érdekében áll, hogy minél többet tudjon meg magáról a vállalatról, ügyfeleirıl, és azok szokásairól. Ezért nyilvánvaló, hogy a vállalat élete során felgyülemlı adathalmazok elemzése és a belılük levonható következtetések stratégiai eszközként szolgálhatnak. Sok vállalat sikerének fontos alappillére, hogy stratégiai módon használja ki az üzleti intelligencia lehetıségeit és az adattárházra épülı informatikai technológiákat. A vállalatok életében fontos, hogy a kritikus helyzetekben helyes döntéseket hozzanak. Az adattárházban egy vállalat különbözı területeirıl, a legnagyobb részletességig visszakereshetı adatok tárolódnak. Az adattárház legnagyobb elınye, hogy az összegyőjtött adattengerbıl a megfelelı módszerekkel segítséget nyújthatunk a vállalat számára legjobb döntések meghozatalához. Diplomamunkám elsı fejezeteinek célja, hogy bemutatassam az adattárházak alapvetı ismérveit, koncepciójukat, komponenseit, az OLTP és OLAP rendszereket. Ezek után rátérek az adattárházak architektúrájának, az adattárház adatok feldolgozásának, valamint az adattárház építésnél alkalmazott adatmodellek bemutatására. Végezetül pedig ismertetem az intelligens adattárházakat és a hozzájuk kapcsolódó technológiákat.


4/51


3

ADATTÁRHÁZ KONCEPCIÓK

3.1

Mi az adattárház?

Az adattárházak olyan adatbázisok, melyeket inkább lekérdezések és elemzések végrehajtására terveztek, mint a tranzakciók feldolgozására. Ez legfıképp tranzakciós adatokból nyert hisztorikus adatok feldolgozását foglalja magába, de ezek az adatok gyakran származhatnak más forrásból. Különválasztja az elemzési munkaütemet a tranzakciós munkaütemtıl, és lehetıvé teszi a szervezetek számára, hogy a több forrásból származó adatokat egyesítse. A relációs adatbázisokhoz képest az adattárházak környezete magába foglal kivonatolási, szállítási, feldolgozási és betöltési (ETL) megoldásokat, egy online elemzési feldolgozó motort (OLAP), kliens-elemzési eszközöket, valamint más alkalmazásokat, melyek kezelik az összegyőjtött adatok feldolgozását, és továbbítják azokat az üzleti felhasználók felé. Az adattárházak bemutatásánál

gyakran hivatkoznak a William Inmon

által

meghatározott adattárház jellemzıkre. Ezek alapján egy adattárház • • • • 3.2 3.2.1

tárgyorientált, integrált, nem illékony, idıben változó.

Az adattárház jellemzői Tárgyorientált

Az adattárházak célja, hogy segítsen az adatok elemzésében. Például, ha többet akarunk megtudni egy cég eladási adatairól, akkor építhetünk egy adattárházat, mely a begyőjtött adatokat az eladás szempontjából vizsgálja. Egy ilyen adattárházat használva, választ kaphatunk például olyan kérdésekre, hogy ki volt a legjobb fogyasztónk egy adott termékre vonatkozóan a legutóbbi évben. 3.2.2

Integrált

Az integráltság szorosan kapcsolatban van a tárgyorientáltsággal. Az adattárháznak a különbözı forrásokból származó adatokat egységes formába kell transzformálnia. Meg kell oldani az elnevezési konfliktusokat, valamint a mértékegységeket egységesíteni kell. Mikor ezt elértük, akkor mondhatjuk, hogy adataink integráltak. Az adattárházak a


5/51


szervezet üzleti és egyéb információit egységes formában tükrözik. Erre azért van szükség, mivel a különbözı idıben, különbözı célokra készített alkalmazásokhoz nagyon sokféle típusú információt tárolnak az operatív adatbázisok, és elıfordulhat, hogy az egyik alkalmazásban ugyanazt az egyedet másképpen nevezik, mint egy másik alkalmazásban. Az adattárházak egyik leglényegesebb tulajdonsága, hogy az információt egységesítve, konzisztens formában tárolják, azaz minden egyed csak egy névvel szerepelhet az adatbázisban. 3.2.3

Nem illékony

A nem illékonyság számunkra azt jelenti, hogy amelyik adat egyszer bekerült az adattárházba, azok a továbbiakban nem fognak változni. Ez logikus, hiszen az adattárház célja, hogy lehetıvé tegye számunkra, hogy az adatok elemzésével következtessünk múltbéli történésekre. Az adattárház adatait csak lekérdezésekhez használjuk, és soha sem módosítjuk, legfeljebb újabb idıpontokhoz tartozó rekordokkal bıvítjük. Az adattárházakat más operatív adatbázisokból töltjük fel adatokkal, és amennyiben a végfelhasználó módosítani szeretné az adatait, azt csak az operatív adatbázisokon keresztül teheti meg, mivel csak ezekben lehet frissíteni, megváltoztatni vagy törölni adatokat. A módosított adatok aztán újabb betöltéssel, új idıponthoz tartozó adatokként kerülnek be az adattárházba. 3.2.4

Időben változó

Annak érdekében, hogy trendeket fedezhessenek fel, az elemzıknek nagy mennyiségő adatra van szükségük. Ez teljesen ellentétes az online tranzakció feldolgozó rendszerekkel (OLTP), ahol a teljesítmény megköveteli azt az igényt, hogy a hisztorikus adatokat archiváljuk. Az adattárházak figyelembe veszik az adatok idıbeli változását. 3.3

Operatív adatbázisok és az adattárházak

A legtöbb szervezet nagy adatbázisokat mőködtet a napi ügyletek lebonyolítására, illetve felügyeletére. Ezeket a mindennapi üzemeltetéshez szükséges adatbázisokat operatív adatbázisoknak hívjuk. Az operatív adatbázisokat általában nem arra a célra tervezik, hogy hosszú történeti adatokat tároljanak vagy segítségükkel nagyon összetett lekérdezéseket gyorsan meg lehessen válaszolni, hanem arra, hogy a napi ügymenethez szükséges alkalmazásokat támogassák.


6/51


Az adattárház egy másik típusú adatbázist jelent. Az adattárházakat eleve stratégiai döntések támogatására tervezik, mindazonáltal az adattárházakat általában operatív adatbázisokból vagy azok részeibıl építik fel. Az adattárházak még a szokásos adatbázisoknál is sokkal több adatot tartalmaznak. A rekordok száma több milliárd is lehet. (Az ennél kisebb mérető, helyi adattárházakat adatpiacoknak hívjuk.) Az adattárház végülis egy adatbázis, melyet az adott szervezet operatív adatbázisától elkülönülten tartanak fenn. Az adattárház-rendszer lehetıvé teszi különbözı felhasználói rendszerek integrációját. Az információfeldolgozást is támogatja az elemzés céljára felhasználható, egyesített, történeti adatok biztosításával. Konkrétan megfogalmazva az adattárház egy olyan döntéstámogató és információ-feldolgozó egység, melyet külön üzemeltetnek a szervezet mőködéséhez kapcsolódó adatbázistól, és megbízható, feldolgozott, hisztorikus elemzések céljából összegyőjtött adatokat tartalmaz. Az egyik legjelentısebb különbség a két fajta rendszer között, hogy az adattárházak általában nincsenek harmadik normál formában. Az adattárházak és az operatív tranzakciós rendszerek eltérı követelményeket támasztanak. Íme, néhány különbség a tipikus adattárházak és operatív rendszerek között: • Munkateher (Workload) Az adattárházakat arra tervezték, hogy ad-hoc lekérdezéseket futtassanak le bennük. Lehetséges, hogy nem ismerjük elıre az adattárházunk munkaterhét, így az adattárházat optimalizálni kell, hogy a sokféle lekérdezési mőveleteket minél jobb teljesítménnyel végrehajthassák Az operatív rendszerek csak az elıre meghatározott mőveleteket támogatják. • Adatok módosítása Az

adattárházakat

rendszeresen

frissítik

ETL

folyamatok

segítségével,

(éjszakánként vagy hetente) az ömlesztett adatmódosítások technikájával. A végfelhasználók nem érik el a legfrissebb adatokat, csak azokat, amik már bekerültek az adattárházba. Az operatív rendszerekben a végfelhasználók rutinszerően adják ki adatmódosító utasításokat az adatbázisnak. Az operatív adatbázis mindig naprakész, és az egyes üzleti tranzakciók aktuális állapotát tükrözi. • Séma design


7/51


Az adattárházak gyakran használnak denormalizált vagy részlegesen denormalizált sémákat (mint például a csillag-séma), hogy optimalizálják a lekérdezések teljesítményét. Az operatív rendszerek gyakran használnak teljesen normalizált sémát, hogy gyorsítsák az update/insert/delete utasításokat, és hogy garantálják az adatbázis konzisztenciát. • Jellemzı mőveletek Az átlagos adattárház mőveletek több ezer, vagy akár több millió sort érintenek. Egy operatív rendszerben a mőveletek csak néhány rekordot érintenek. • Hisztorikus adatok Az adattárházak rendszerint több hónapos, több éves adatokat tárolnak. Ennek célja, hogy támogassa az adatok történeti elemzését. operatív rendszerben az adatokat általában pár hétig vagy hónapig tárolják. Az operatív rendszerekben csak akkor tárolnak történeti adatokat, ha azok teljes mértékben megfelelnek az aktuális tranzakciónak. 3.4

OLTP és OLAP rendszerek

Az on-line operatív adatbázisrendszerek fı feladata, hogy végrehajtsák az online tranzakciókat és feldolgozzák a lekérdezéseket. Az ilyen rendszereket OLTP (Online Transaction Processing, online tranzakció feldolgozó) rendszereknek hívjuk. Ezek lefedik egy szervezet legtöbb naponta használt mőveletét. Ezzel szemben az adattárházak a felhasználókat, a szakértıket az adatelemzés és döntéshozás feladatában segítik. Ezek a rendszerek eltérı felhasználói igényeknek megfelelıen sokféle formában képesek rendszerezni és bemutatni az adatokat. Ezekez a rendszereket OLAP (online analitikus feldolgozó) rendszereknek nevezzük. Az OLTP és OLAP rendszerek fı megkülönböztetı jellemzıi a következıképpen foglalhatóak össze: • Felhasználó- és rendszerorientált: Az OLTP rendszer ügyfélorientált, és az ügyintézık, kliensek, illetve információtechnológiai szakemberek használják a tranzakciók és a lekérdezések feldolgozási céljára. Az OLAP rendszerek piacorientált, és szakértık, elemzık, vezetık használják adatelemzés céljából. • Adattartalom: Az OLTP rendszer naprakész adatokat kezel, amelyek jellemzıen túl részletesek ahhoz, hogy a döntéshozásban könnyen használhatóak legyenek. Az


8/51


OLAP rendszer nagymennyiségő történeti adatot kezel, lehetıséget nyújt az összefoglalásra és az összesítésre, és az információkat különbözı finomsági szinteken tárolja és kezeli. Ezek a jellemzık megkönnyítik, hogy az adatokat körültekintı döntéshozatal során használják. • Adatbázis-szerkezet: Az OLTP rendszer általában Egyed-Kapcsolat(ER – Entity Realationship) adatmodellt és alkalmazásorientált adatbázis-szerkezetet használ. Egy OLAP rendszer jellemzıen csillag vagy a hópehely adatmodellt és témaorientált adatbázis-szerkezetet alkalmaz. • Nézőpont: Az OLTP rendszer fıleg a vállalaton vagy részlegen belüli aktuális adatokra koncentrál, történeti adatokra, vagy más szervezetek adataira való utalás nélkül. Ezzel szemben az OLAP rendszer gyakran átível az adatbázisséma több verzióján is. Olyan információkkal dolgoznak, amelyek több különbözı forrásból származnak, egyesítve az információkat. Az OLAP adatokat hatalmas mennyiségük miatt gyakran több adathordozón tárolják. • Hozzáférési minták: Az OLTP rendszerekhez való hozzáférés fıleg rövid, egyszerő tranzakciók jelentik. Egy ilyen rendszer konkurenciavezérlı és helyreállító mechanizmusokat igényel. Az OLAP rendszerekhez való hozzáféréseket azonban zömében csak olvasó (read-only) mőveletek jelentik (mivel a legtöbb adattárház inkább történeti, mint naprakész információkat tárol), bár ezek között sok összetett lekérdezés is elıfordulhat.

További jellemzık amik az OLTP és OLAP rendszereket egymástól megkülönböztetik, az adatbázis mérete, a mőveletek gyakorisága, valamint hogy mi alapján mérjük a teljesítményt.

TULAJDONSÁG

OLTP

OLAP

Jellegzetesség

Operatív feldolgozás

Információ feldolgozás

Orientáció

Tranzakció

Elemzés

Funkció

Napi mőveletek

Hosszú távú információs igények, döntéstámogatás


9/51


Adatbázisséma

ER alapú, alkalmazásorientált

Csillag/hópehely, témaorientált

Adatok

Aktuális, a legfrissebbek

Történeti, folyamatos pontosítás

Elérés

Olvasás/írás

Fıleg olvasás

Fókusz

Adatok begyőjtése

Információ kiadása

Elért rekordok

Tízes nagyságrend

Milliós nagyságrend

Felhasználók száma

Ezres nagyságrend

Százas nagyságrend

Adatbázis mérete

GB-os nagyságrendő

100GB – TB-ig

Teljesítmény

Tranzakciós teljesítmény

Lekérdezés

mértéke

3.5

végrehajtásának

hatékony-sága, válaszidı

Az adattárház komponensei

Ebben a fejezetben megvizsgáljuk az adattárház komponenseit, melyekbıl felépíthetjük az adattárház környezetet. Hasznos lehet, hogyha jól megértjük az egyes részeket mielıtt elkezdünk azokból adattárházat építeni. Minden összetevı egy-egy jól meghatározott funkciót szolgál. Az egyik legnagyobb fenyegetés, amivel szembe találkozhatunk az adattárház építésénél, az, hogy összekeverjük az egyes komponensek szabályait és funkcióit.[3] Ahogyan az 1. ábra is mutatja, négy különbözı komponenst fogunk megvizsgálni: operatív forrás rendszerek, átmeneti adattároló terület, adat megjelenítési terület és adathozzáférési eszközök. 3.5.1

Operatív forrás rendszerek

Ezek a rendszerek az üzleti tranzakciók által létrehozott és módosított rekordokat tartalmazó operatív rendszerek. A forrás rendszereknek az adattárházon kívül kell lenniük, mert elıfordulhat, hogy elveszítjük az adattartalmak és az adatformázások feletti ellenırzésünket. A forrás rendszerek fı prioritása a feldolgozási teljesítmény és az elérhetıség biztosítása. Az operatív rendszereknek nem az a célja hogy hosszú távú történeti adatokat tároljanak. Ha az operatív rendszerek mellet van egy jó adattárház, akkor a forrásrendszereket felmenthetjük a sok történeti adat tárolásának felelıssége alól. A forrás rendszerek gyakran megosztanak általános adatokat –, mint például


10/51


termékadatok, fogyasztók adatai, földrajzi adatok – a szervezeten belül más operatív rendszerekkel. Nagyszerő lenne, ha ezeket a forrás rendszereket konzisztens nézettel újra lehetne tervezni. Példaképp, egyféle alkalmazás integráció (EAI - Enterprise Application Integration) bevezetése az adattárház tervezését sokkal könnyebbé tehetné.

3.1. ábra - Adattárház komponensek

3.5.2

Átmeneti adattároló terület

Az adattárház átmeneti adattároló területének (data staging area) feladata az adatok ideiglenes tárolása, valamint az ETL (Extract Transform and Load) folyamatok végrehajtása. A nyers adatok áttranszformálódnak, az adattárházba bevihetı, a felhasználói lekérdezéseknek és felhasználásnak megfelelı adatokká. Természetesen ez az átmeneti terület csak a megfelelı szakemberek számára érhetı el, az adatok biztonsága érdekében. Az adattárház végfelhasználói már csak az adattárháznak megfelelı, adattárházba bekerült adatokhoz férhetnek hozzá. Az adatok kinyerése (extraction) az elsı lépése az adatok adattárház környezetbe való átültetésének folyamatában. Ez a lépés pontosabban azt jelenti, hogy olvassuk és értelmezzük a forrásadatokat, majd azokat az adatokat, melyek szükségesek az adattárháznak, átmásoljuk az átmeneti tároló területre, hogy további adattranszformáló mőveleteket végezhessünk el rajtuk. Miután az adat átkerült az átmeneti területre, számos transzformációt végeznek el rajta. Ezek közé tartozik például az adattisztítás (tartományütközések feloldása, hiányzó elemek pótlása, egységes formára hozás), különbözı forrásokból származó adatok


11/51


egyesítése, duplikációk megszüntetése valamint kulcsok meghatározása. Ezek a transzformációk mind elıfutárai az adatok megjelenítései területre való betöltéséhez. Az adatokon végzett transzformációk után az ETL folyamat utolsó lépése az adatok betöltése az adattárház környezetbe. A betöltési folyamat során az átmeneti területrıl a megfelelı adatok áttöltıdnek az adatpiacokba. A betöltés után a frissen érkezett adatokat indexelni kell a jó lekérdezési teljesítmény eléréséhez. 3.5.3

Adat megjelenítési terület

Az adatmegjelenítési terület (data presentation area) az, ahol az adatok szervezetten és elérhetıen tárolódnak, hogy a felhasználók, jelentés írók és analitikus alkalmazások közvetlen lekérdezéseket hajthassanak végre rajtuk. Igazából már ezt nevezhetjük adattárháznak, hiszen az itt lévı adatokon már semmilyen transzformáció nem megy végbe. Itt található minden olyan adat, amit a továbbiakban az üzleti közösség láthat és elérhet az egyes adatelérési eszközökön keresztül. Ez a megjelenítési terület valójában integrált adatpiacok sorozatát foglalja magába. Az adatpiacokkal lényegében az adatmegjelenítési területet részekre osztjuk, particionáljuk, hogy így a cég, szervezet különbözı igényekkel rendelkezı, elkülönülı részeit megfelelıen kiszolgáljuk. Az adatmegjelenítési területen az adatokat dimenziós modellben tároljuk. A dimenziós modellezés egy régi technika új elnevezése, melynek alapjai egyszerőek és könnyen megérthetık. Az 1970-es években IT-szervezetek, tanácsadók, végfelhasználók és forgalmazók úgy vélték, hogy szükséges egy olyan dimenziós struktúra kitalálása, mely illeszkedik az egyszerőség iránti alap emberi szükségletre. A dimenziós modellezés eléggé különbözik a harmadik normál formában történı ER modellezéstıl (EntityRelationship modeling), melyet arra terveztek, hogy felderítsék és eltávolítsák az adatredundanciákat. Ebben az adatokat több különálló entitásokra osztják, melyek egyegy táblát alkotnak a relációs adatbázisban. A normalizált modellezés jól alkalmazható az operatív feldolgozó rendszerek teljesítményénél, hiszen egy módosító vagy beszúró utasítás csak egy helyen érinti az adatbázist. A normalizált modellek viszont túl összetettek lennének egy adattárházban végrehajtott lekérdezésnek, és szemben állna az adattárházak azon céljával, hogy az adatokon történı lekérdezéseket a lehetı leghatékonyabban végezhessük el. Tehát az adattárházunkban a dimenziós modellezést kell megvalósítanunk. Ha a megjelenítési terület relációs adatbázison alapszik, akkor a táblákat a csillagséma alapján


12/51


érdemes létrehozni. Ha viszont többdimenziós adatmodellt valló adatbázissal dolgozunk, vagy a megjelenítési terület az OLAP (on-line analytical processing) technikán alapszik, akkor adatainkat adatkockákban kell tárolnunk. A dimenziós modellezés mind relációsmind többdimenziós adatbázisok esetén is alkalmazható. Mindkét esetben közös logikai tervet alkalmazhatunk a dimenziók felismerésével; habár a fizikai implementációk eltérnek. 3.5.4

Adathozzáférési eszközök

Az adattárház környezet utolsó komponense az adathozzáférési eszközök (data access tools). Ebben a terminológiában az eszközök kifejezés azon különbözı lehetıségeket foglalja magába, melyek segítségével az üzleti felhasználók elemzési döntéseket tudnak hozni. Úgy is fogalmazhatnánk, hogy az adathozzáférési eszközök lehetıvé teszik az adatok lekérdezését az adattárházból. Az adathozzáférési eszközök olyan egyszerőek lehetnek, mint egy eseti (ad-hoc) lekérdezés, vagy akár olyan bonyolultak is lehetnek, mint egy kifinomult adatbányászati alkalmazás. Leggyakrabban az üzleti felhasználók valamilyen paramétervezérelt elemzési alkalmazáson keresztül érik el az adattárház adatait. 3.6

Adatok az adattárházban

Az adatok különbözı variációkban tárolódnak a számítógépeken. Az adatoknak csak néhány típusa teljesen megfelelı arra, hogy adattárházban tárolhassuk ıket. A fejezet célja, hogy felfedjük az adatok típusai közötti különbségeket, és hogy feltárjuk azokat a típusokat, melyek megfelelıek az adattárházakban való tárolásra. 3.6.1

Adatok típusai

Az adatokat megfogalmazhatnánk úgy, hogy az üzleti információk virtualizált reprezentációi. Az adatoknak három szintjét különböztethetjük meg, ha meg akarjuk határozni az adattárházak terjedelmét: • Jelentés (Meaning) A számítógépes adatokat régóta alkalmazzák üzleti tevékenységek lefolytatására és kezelésére. Az ilyen adatokat üzleti adatoknak (business data) nevezzük, melyek az üzleti tevékenységek állapotát ábrázolják, és értékük azon jelentésen alapszik, amit reprezentálnak.


13/51


Az adatok egy másik típusnak a fontossága gyorsan növekszik. Az ilyen adatoknak megvan a saját lényegi jelentésük, és értékük inkább az adat tartalmán alapszik, mint azon, hogy mit reprezentál. Ezeket az adatokat „termék, mint adat” (data as product) néven fogalmazhatnák meg, hiszen ezeket elıállítják, árulják, eladják ugyanúgy, mint egy fizikai értelemben vett terméket. Erre példaként szolgálhat a digitális formában tárolt filmek vagy könyvek. Végül pedig vannak a metaadatok, melyek az adatok jelentését írják le. Az ilyen adatok csak azért vannak, hogy üzleti adatokat vagy termékeket határozzanak meg, írjanak le. • Struktúra (Structure) Az adatok lehetnek jól-strukturáltak, amikor a mezık és rekordok közötti jólmeghatározott kapcsolat van; vagy lehetnek nem-strukturáltak, mely esetén a belsı struktúra nagyon változó lehet. Valamint az adatok szerkezete lehet a két szélsıséges (teljesen strukturált – nem strukturált) eset között. • Terjedelem (Scope) Az adatok lehetnek személyes adatok, melyeket csak a tulajdonosa változtathat meg. Valamint lehetnek nyilvánosak. A nyilvános adatok több ember között meg vannak osztva. Ekkor az adatok változásának kezelése fokozott figyelmet igényel. 3.6.2

Metaadatok

A metaadatok az adattárház környezet olyan információt hordozó adatai, melyek maguk nem

elemzendı

adatok.

A metaadatokat

az

adattárház

egy enciklopédiához

hasonlíthatnánk. A metaadatok különbözı formában jelennek meg, hogy támogathassák az adattárház technikai-, adminisztratív- és üzleti felhasználó csoportjainak eltérı igényeit. A metaadatok fontos szerepet játszanak az adattárházaknál. Két csoportra oszthatjuk ıket: üzleti- és technikai metaadatok. Az üzleti metaadatok azt írják le, hogy mi van az adattárházban. Ezzel ellentétben a technikai metaadatok magukat az adatelemeket írják le. Az ilyen típusú metaadatokat adatmodellezésre használják.

4

ADATTÁRHÁZ TERVEZÉS

4.1

Adattárház architektúrák

Az adattárházak és architektúrájuk az adott szervezet helyzetétıl függ. Általában három féle architektúrát különböztetünk meg: IntelligensAdattárházak

14/51


• Alap architektúra • Architektúra egy összesítési területtel • Architektúra egy összesítési területtel és adatpiacokkal 4.1.1

Alap architektúra

Az alábbi ábra mutatja az egyszerő adattárház architektúrát. A végfelhasználók az adattárházon keresztül közvetlenül hozzáférhetnek a különbözı forrásokból eredı adatokhoz. Adatforrások

Adattárház

Felhasználók

Elemzés Operatív rendszer

Metaadatok

Jelentések Operatív rendszer Összegzı adatok

Nyers adatok

Adattárház

Flat file-ok Adatbányászat

4.1. ábra - Alap architektúra

Az ábrán szereplı meta-adatok és nyers adatok egy hagyományos OLTP rendszerben vannak jelen, mint ahogyan egy további típusú adatok, az összegzı adatok is. Ez utóbbi adatok nagyon fontosak az adattárházban, hiszen hosszú mőveleteket elıre kiértékelnek. Ezeket az összegzıket Oracle-ben materializált nézetnek hívjuk. 4.1.2

Architektúra egy összesítési területtel

Az elızı ábra esetében meg kell tisztítani és fel kell dolgozni az adatokat mielıtt bekerülnek az adattárházba. Ezt megoldhatnánk egy program futtatásával, bár általában e helyett inkább egy összesítési terület-et alkalmaznak. Az összesítési terület egyszerősíti az összefoglalók és az általános adattárház kezelés felépítését. A következı ábra mutatja ezt a típusú architektúrát.


15/51


4.2. ábra - Architektúra egy összesítési területtel

4.1.3

Architektúra egy összesítési területtel és adatpiacokkal

Bár az ez elızı ábrán szereplı architektúra elég gyakori, mégsem lesz számunkra megfelelı, ha az adattárházunk architektúráját, az adott szervezeten belüli különbözı csoportoknak megfelelıen akarjuk kialakítani. Ezt még kiegészíthetjük adatpiacokkal, melyek olyan rendszerek, amelyeket egy-egy üzleti vonalhoz terveztek.

4.3. ábra - Architektúra egy összesítési területtel és adatpiacokkal


16/51


4.2

Adattárházak logikai és fizikai tervezése

Tegyük fel, hogy egy szervezet úgy dönt, hogy adattárházat épít. Ekkor a szervezetnek meg kell határoznia az üzleti követelményeket, meg kell állapodniuk az alkalmazás terjedelmében, valamint létre kell hozni egy alaptervet. A követelményeket olyan formában kell meghatározni, hogy azok a rendszerben realizálhatóak legyenek. Ehhez létre kell hozni az adattárház logikai- és fizikai tervét, melyekben a következıknek kell szerepelniük: • konkrét adattartalom • adatcsoportok közötti kapcsolatok • az adattárház által támogatott rendszerkörnyezet • az adat-transzformáció megkövetelése • az adatok frissítésének gyakorisága A logikai terv sokkal elméletibb és absztraktabb, mint a fizikai terv. A logikai tervezés folyamán az objektumok közötti logikai kapcsolatokat térképezzük fel. A fizikai tervezés során meghatározzuk a számunkra leghatásosabb tárolási, valamint helyreállítási módokat annak megfelelıen, hogy hogyan kezeljük objektumainkat a szállítás, biztonsági másolat létrehozása (backup) és a helyreállítás (recovery) szemszögeibıl. A tervezés folyamán figyelembe kell venni a végfelhasználók igényeit, akik leggyakrabban elemzésekre és aggregát adatok megtekintésére használják az adattárházat. Egy jól létrehozott terv lehetıvé teszi a fejlesztések és változtatások bevezetését. 4.2.1

Logikai terv

A logikai terv elméleti és absztrakt. Ekkor még nem kell törıdnünk a fizikai implementációs kérdésekkel, hanem legfıképp azoknak az információtípusoknak a meghatározásával, melyekre szükségünk lesz. Egy technika, mellyel modellezhetjük egy szervezet logikai információ követelményeit, az egyed-kapcsolat modellezés (entityrelationship modeling). A logikai tervezés folyamán az adatokat olyan logikai kapcsolatok sorozatába szervezzük, melyeket entitásoknak és attribútumoknak nevezünk. Egy relációs adatbázisban az entitások táblákként jelennek meg. Az attribútum az entitás egy összetevıje, mely lehetıvé teszi, hogy egyedi entitásokat definiáljunk. Egy relációs adatbázisban az attribútumok a táblák oszlopaiként jelennek meg.


17/51


Hogy biztosítsuk adataink konzisztenciáját, egyedi azonosítókat kell alkalmaznunk. A fizikai tervben ezek az egyedi azonosítók elsıdleges kulcsokként jelennek meg. Habár az egyed-kapcsolat modellezést leginkább a magasan normalizált OLTP alkalmazások esetében alkalmazzák, ez a technika hasznos a dimenzió modellezés (dimensional modeling) esetében is, melyet adattárházaknál használnak. A dimenzió modellezésben ahelyett, hogy atomi információegységek és a közöttük lévı kapcsolatok feltárásával foglalkoznánk, feltárjuk azokat az információkat, melyek egy központi ténytáblához és az ehhez tartozó dimenzió táblákhoz tartoznak. 4.2.2

Fizikai terv

A fizikai adatbázis tervezés a fizikai adatbázis struktúra felépítésére fekteti a hangsúlyt, beleértve az adatbázis környezet beállítását valamint a megfelelı biztonságnyújtást. Habár egy relációs adatbázis fizikai adatmodellje nagyon hasonlít a dimenzió modellhez, a dimenzió modell további lehetıségeket biztosít a címzés terén, mint például teljesítményfokozó stratégiák az indexeléstıl kezdve a partícionálásig és aggregációig.

5

TÖBBDIMENZIÓS ADATMODELLEZÉS Az OLAP technológia elsıdleges célja a rendkívül gyors lekérdezések végrehajtása, és hogy a válaszidı a lehetı legkevesebb legyen. Az OLAP rendszerekben fontos az állandó lekérdezési teljesítmény megırzése. Azaz a dimenziók számának és az adatbázis méretének növelésével a felhasználó ne tapasztaljon jelentıs teljesítménycsökkenést.

5.1

Adatkockák

Az adattárházak és az OLAP eszközök többdimenziós adatmodellt vesznek alapul, amely az adatot adatkockáknak tekinti. Az adatkocka lehetıvé teszi, hogy az adatot több dimenzióban modellezzük, és több dimenzióban tekintsünk rá. Habár a kockára általában, mint háromdimenziós geometriai struktúrára szokás tekinteni, az adattárházak esetében az adatkocka n-dimenziós lehet, így nem szorítják az adatokat három dimenzióba. Az adatkockát dimenziók és tények definiálják. A tények azokat az értékeket határozzák meg, amelyeket az elemzés szempontjából az adatkockák adatcelláiban tárolunk. Ezeket a tényeket témaorientáltan tároljuk az adatkockákban, melyek általában valamilyen központi téma köré szervezıdnek.


18/51


A dimenziók azokat a nézıpontokat reprezentálják, melyek szerint adatainkat elemezni szeretnénk. A dimenziókat feloszthatjuk dimenzióelemekre. Például a cím dimenziót fel tudjuk bontani Hajdúszoboszló, Debrecen, Szombathely, és Sárvár dimenzióelemekre. Továbbá létre tudunk hozni hierarchiákat, melyek a dimenzióelemek közötti kapcsolatokat írják le. Ez azt jelenti, hogy a dimenziókhoz különbözı dimenzióelem halmazokat tudunk rendelni, mely halmazok egymással hierarchikus viszonyban vannak. Tehát egy dimenzióelemet egy másik dimenzióelem halmazzal tovább tudunk bontani, és ez által különbözı részletességő lekérdezéseket hajthatunk végre. Így például a cím dimenziót a város alapján történı dimenzióelemeken kívül tekinthetjük a megyék alapján is

(Hajdú-Bihar

megye,

Vas

megye).

A

dimenzióelemek

rendelkezhetnek

tulajdonságokkal, amik olyan plusz információkat hordozó adatok, melyek nem minısülnek csoportosítási szempontnak az elemzéseket tekintve. Ilyen tulajdonság lehet például egy termék csomagolása vagy színe. A lekérdezések során lehetıségünk van arra, hogy bizonyos dimenzióelemek közül csak azokat válasszuk ki, melyek megfelelnek egy adott tulajdonságnak. Hogy jobban megértsük ezt a többdimenziós szemléletmódot, vegyünk egy példát. Tegyük fel, hogy egy áruházlánc értékesítési adatait szeretnénk elemezni. Kezdetben vegyünk egy kétdimenziós adatkockát, melyben negyedéves bontásban szeretnénk látni az árucikkek értékesítési adatait. Ekkor ezt az adatkockát úgy képzelhetnénk el, mint egy táblázatot, melyben a dimenziók (idı és árucikk) lehetséges értékei címkézik a sorokat és oszlopokat, valamint a köztes cellákban a tények szerepelnek. A tények mutatják az értékesítési adatokat, amit például megadhatunk euróban, vagy valamilyen más pénznemben, esetleg egyéb mértékegységben. Ha az értékesítéseket például aszerint is elemezni szeretnénk, hogy hol adtuk el az adott árucikkeket, akkor azt egy új dimenzió (cím) bevezetésével érhetnénk el. Ekkor már háromdimenziós az adatkockánk, melyet az 5.1-es ábra szerint képzelhetünk el.


19/51

Cí m

(v ár os )


5.1. ábra – Adatkocka

Az adatkockák mind relációs-, mind többdimenziós adatbázisokban is tárolhatóak. Így három különbözı tárolási architektúrát különböztethetünk meg: ROLAP, MOLAP, és HOLAP. A tárolási stratégiát annak megfelelıen kell megválasztanunk, hogy a lekérdezések sebességének maximalizálása, vagy a tárhely minimalizálása –e a célunk. 5.1.1

Kocka műveletek

A többdimenziós modellben az adatok értelem szerően több dimenzió mentén szervezıdnek, és minden dimenzió több absztrakciós szintet foglal magába, a fogalmi hierarchiáknak megfelelıen. Ez a szervezés biztosítja a felhasználóknak, hogy különbözı távlatokból tekintsen az adatokra. Számos OLAP adatkocka-mővelet létezik a különbözı nézetek

megvalósítására,

amely

interaktív

lekérdezésekre

és

elemzésre

nyújt

lehetıséget.[5] 5.1.1.1

Felgörgetés (Roll-up)

A felgörgetés mővelet az összesítést egy adott dimenzió fogalmi hierarchiáján való felfelé haladással vagy dimenziócsökkentéssel hajtja végre. Például a cím dimenzióhoz hozzá tartozhat az (utca, város, megye, ország) hierarchia. Ezen a hierarchián az utcától az ország felé haladva összesítést végezhetünk.


20/51


Amikor a felgörgetést dimenziócsökkenéssel hajtjuk végre, akkor egy vagy több dimenziót távolítunk el az adatkockából. Ha például az értékesítési adatokat csak cím és árucikk dimenziók szerint szeretnénk vizsgálni, akkor felgörgetéssel eltávolíthatjuk az idı dimenziót.[5] s)

Hajdúszoboszló Debrecen Szombathely Sárvár Idı(negyedév)

Q1

Cí

me m(

Q3

e)

Hajdú-Bihar Vas Q1

A cím felgörgetése (városról megyére)

Q2

gy

Idı(negyedév)

Cí

ro vá m(

Q2 Q3 Q4

Q4 biztonság telefon Szórakoztató számítógép elektronika

biztonság telefon Szórakoztató számítógép elektronika

Árucikk(típus)

Árucikk(típus)

5.2. ábra - A cím dimenzió felgörgetése (városról megyére)

5.1.1.2

Lefúrás (Drill-down)

A lefúrás a felgörgetés ellenkezıje: a kevésbé részletes adatoktól a még részletesebb adatokig halad. A lefúrást vagy egy adott dimenzió fogalmi hierarchiáján való lefelé haladással, vagy új dimenziók bevezetésével hajtjuk végre. Például az idı dimenzión a negyedév szintjérıl a részletesebb hónap szintre léphetünk. Az eredményül kapott adatkocka az összes eladást negyedévek helyett hónapokra bontja le. Mivel a lefúrás több részletet ad hozzá az adatokhoz, ez úgy is elérhetı, ha új dimenziókat veszünk fel az adatkockába. Az adatkockánkon úgy is végrehathatunk lefúrást, ha például bevezetünk egy új vásárló_típus dimenziót.[5]


21/51

Idı(negyedév)

Idı(negyedév)


5.3. ábra - Lefúrás az idı dimenzión (negyedévrıl hónapra)

5.1.1.3

Szeletelés és kockázás (Slice and Dice)

A szeletelés mővelet egy kiválasztást hajt végre az adott kocka egyik dimenzióján, és ennek eredménye egy alkocka lesz. A kockázás mővelet kettı vagy több dimenzión hajt végre kiválasztást, amelynek az eredménye szintén egy alkocka.[5]

5.4. ábra - Szeletelés és kockázás

5.1.1.4

Forgatás (Pivoting)

A forgatás (vagy pivotálás) képi mővelet, amely elforgatja az adattengelyeket, hogy az adatokat másmilyen ábrázolásban lássuk.[5]


22/51


5.2

MOLAP architektúra

MOLAP (Multidimensional OLAP) architektúra esetén adatainkat többdimenziós adatbázisban tároljuk. Az adatok ilyenkor speciális dimenziós struktúrában tárolódnak, mely arra irányul, hogy a lekérdezéseket minél gyorsabban végre tudjuk hajtani. A MOLAP architektúrában egy olyan adatkocka szerkezeteket kezelünk, melyet úgy képzelhetünk el, mint egy többdimenziós tömböt. Ez a szerkezeti megoldás sokszor gyorsabb, mint más megközelítések, mert lehetıség van arra, hogy közvetlen indexeléssel érjük el az adatkocka struktúrában lévı adatokat. Egy MOLAP architektúrában a dimenziók hierarchiába rendezését úgy lehet megoldani, hogy a dimenzióelemek közé felvesszük a hierarchia fentebbi csomópontjait és összesített adatokat rendelünk hozzájuk. A speciális indexelésnek köszönhetıen az összetett kalkulációk esetén is gyorsan megkaphatjuk egy lekérdezés eredményét. Viszont, ha hatalmas adatmennyiséggel dolgozunk, és rengeteg dimenziót használunk, akkor a MOLAP megoldások nem mindig a leghatékonyabbak. A dimenziók számának nagymértékő növekedésével sok olyan cella értéke üres lehet, melyek több specifikus attribútum-kombinációhoz tartozó értéket reprezentálnának. Ez néha elfogadhatatlan szintig megnövelheti a tárhely igényeket, és a teljesítményt is visszaveti. 5.3

ROLAP architektúra

ROLAP (Relational OLAP) architektúra esetén adatainkat relációs adatbázisban tároljuk. A ROLAP kockát nem egy többdimenziós tömb valósítja meg –, mint MOLAP esetén–, hanem elıre meghatározott sémák alapján összekapcsolódó relációs táblák (dimenzió- és ténytáblák) együttese alkotja. Ezen sémák közül a leggyakrabban a csillagsémát alkalmazzák. A ROLAP architektúrában az adatok feldolgozásához és lekérdezéséhez hagyományos relációs adatbázis technikákat használhatunk (mint például indexelések és összekapcsolások). A ROLAP hatékony lehet nagy adatmennyiségek esetén, hiszen a tábláknak csak azokat az adatkocka cellákat kell tartalmazniuk, melyek ténylegesen tartalmaznak adatot. Így a tárkapacitás kihasználtsága optimálisabb, mint a MOLAP esetén. A továbbiakban áttekintjük a ténytáblák és dimenziótáblák fogalmát, valamint összekapcsolásukat.


23/51


5.3.1

Dimenziótáblák

Általában véve egy dimenzió egy olyan nézıpont vagy elem, amellyel kapcsolatban a szervezet feljegyzéseket kíván készíteni. Például egy áruházláncot üzemeltetı cég létrehozhat egy értékesítés adattárházat, hogy áruházainak eladásait nyilvántartsa az idı, árucikk, üzlet, cím és egyéb dimenziók szerint. Ezekkel a dimenziókkal például lehetıvé válik olyan dolgok nyomon követése, mint például az árucikkek iránti havi kereslet alakulása. A dimenziótáblák a dimenziókról tartalmaznak információkat, további leírásokat. Egy jól megtervezett többdimenziós modellben a dimenziótábláknak sok oszlopa és attribútuma van. Ezek az attribútumok leírják a dimenziótábla sorait. Nem ritka, hogy egy dimenziótáblának 50 vagy 100 attribútuma is van. A dimenzió attribútumok a lekérdezési megszorítások, csoportosítások és riport címkék elsıdleges forrásaként szolgálnak. Például, ha egy felhasználó le szeretné kérdezni a heti eladásokat márkák szerint, akkor a „hét”-nek és „márka”-nak létezniük kell, mint dimenzió attribútum. Fontos hogy ezeket jól meghatározzuk, mert a dimenzió attribútumok minısége és mélysége nagy kihatással van arra, hogy mennyire hatékony lekérdezéseket tudunk végrehajtani az adattárházunkban. Azok a legjobb attribútumok, melyek szövegesek és diszkrétek. Például egy termékdimenzió attribútumként tartalmazhatna egy rövidebb és egy hosszabb leírást, márka nevet, kategória nevet, csomagolási típust, méretet és még számos egyéb termékjellemzıt (5.5. ábra). Habár a méret általában egy számértéket képvisel, mégis szolgálhat dimenzió attribútumként, hiszen inkább szöveges leírásként viselkedik, mint numerikus értékként. Néha az adatbázis tervezésekor nem teljesen világos, hogy egy numerikus adatmezı tényként, vagy dimenzió attribútumként fog –e szerepelni. Ilyenkor jó, ha döntésünknél figyelembe vesszük, hogy a mezı értéke olyan mértékként szolgál, ami sok értéket felvehet és számításoknál is használjuk, vagy pedig inkább egy diszkréten meghatározott leíró jellemzı.


24/51


Termék Dimenziótábla Termék_azonosító (TK) Termék_leírás Gyáriszám Márka_megnevezés Kategória Csomag_típus Csomag_méret Súly Tárolási_típus …. 5.5. ábra - Példa dimenziótábla

A dimenzió táblák gyakran hierarchikus kapcsolatokat reprezentálnak. Fenti példánkat folytatva a termék dimenzió tábla minden sorában le lesz tárolva a termék kategóriája és márkája is, így a hierarchikus leíró információkat redundánsan tároljuk. Megtehetnénk azt is, hogy például a márkaleírás helyett márkakódot használva összekapcsolnánk a dimenziótáblánkat egy új táblával, mely a márkára adatokat tartalmazná – ebben az estben a hópehelyséma adatmodell szerint szerveznénk a dimenziótáblákat. Igaz így tárhelyet nyernénk, viszont ekkor a táblakapcsolatok bonyolódásával a lekérdezések sebessége is lassulhat. A dimenziótáblák a legtöbb esetben denormalizáltak –, hogy a lekérdezések egyszerőbbek legyenek –, de ezzel általában kevesebb, mint tíz százalékot vesztünk a szükséges tárhelybıl. Tehát érdemes dimenziótábla területet feláldozni az egyszerőség és a teljesítmény kedvéért. 5.3.2

Ténytáblák

A többdimenziós adatmodell jellemzıen egy központi téma köré (pl. értékesítés) szervezıdik. Ezt egy ténytábla reprezentálja. A tények számértékek, valamilyen mértékegységben megadva. Úgy kell rájuk gondolni, mint azokra a mennyiségekre, vagy mértékekre, amelyek szerint elemezni akarjuk a dimenziók közötti összefüggéseket. A ténytáblázat tartalmazza a tények vagy mértékek nevét és egy-egy kulcsot minden kapcsolódó

dimenziótáblához.

A

dimenziók

fogják

meghatározni

a

ténytábla

szemcsézettségét. A legjobban használható tények numerikusak és összeadhatók (additive), mint például az euró, mint eladási érték. Az összeadhatóság elég fontos, mivel az adattárház alkalmazások szinte sohasem egyetlen egy ténytábla sort adnak vissza. Sokkal inkább több százat, ezret vagy akár milliót. A termékes példánknál maradva, az 5.6-os ábrát


25/51


megfigyelve mindegy, hogy a felhasználó az értékeket milyen felosztásban szeretné látni, a mennyiséget és értéket egy érvényes összegben visszaadhatjuk. A ténytáblában lehetnek olyan adatok melyek csak esetenként összeadhatók (semiadditive vagy partly-additive), és olyanok is, melyek egyáltalán nem összeadhatók (nonadditive). Az esetenként összeadható tényeket csak bizonyos dimenziók esetén tudjuk összegezni. A nem összeadható tényeket pedig egyszerően nem tudjuk összeadni. Ebben az esetben megkövetelhetjük, hogy a darabszámukat vagy átlagukat adjuk vissza.

5.6. ábra - Példa ténytábla

Elméletileg lehetıség van arra is, hogy egy tényérték szöveges legyen, bár ilyen elég ritkán fordul elı. A legtöbb esetben, ha egy érték szöveges, akkor az valaminek a leírása, és értékeit egy diszkrét listából veszi fel. A tervezıknek figyelmet kell szánniuk arra, hogy az ilyen értékeket dimenziótáblákba rakjuk. Redundáns szöveges információkat nem célszerő ténytáblában tárolni. Ha pedig a szöveges érték a ténytábla minden sorára nézve egyedi, akkor pedig ez az érték inkább a dimenziótáblába tartozik. Az igazi szöveges tény nagyon ritka egy adattárházban, mivel egy megjósolhatatlan tartalmú szöveges tényt –, mint például egy szabadon megadott megjegyzést – szinte lehetetlen megfelelıen elemezni. A példánkhoz visszatérve, tegyük fel, hogy szeretnék az eladásokat elemezni. Ha nincs olyan eladási tevékenység, mely egy adott napon, adott tároló helyen lévı adott termékre vonatkozik, akkor azt a sort kihagyjuk a táblából. Fontos, hogy a ténytáblát ne töltsük fel zéró értékeket reprezentáló tényekkel. Az egyik legfontosabb lépés a többdimenziós tervezésnél a ténytábla szemcsézettségének meghatározása. Ez pontosan azt jelenti, hogy meg kell állapítanunk, hogy a ténytábla rekordjai mit fognak reprezentálni. A ténytáblákat szemcsézettségük szerint három csoportba sorolhatjuk: tranzakciós szemcsézettség, periódikus pillanatnyi szemcsézettség és felhalmozó pillanatnyi szemcsézettség.


26/51


A tranzakciós szemcsézettség (transaction grain) a legkisebb szemcsézettség, és ezt alkalmazzák leggyakrabban. Egy fogyasztóhoz vagy termékhez akkor van sor a ténytáblában, ha ehhez valaha egy tranzakciós esemény végbement. Tehát ilyenkor egy fogyasztóhoz vagy termékhez több sor is tartozhat a ténytáblában, ha több mint egy tranzakció futott le hozzá kapcsolódódóan. A tranzakciós ténytáblák mérete hatalmasra nıhet, akár több milliárd rekordot is tartalmazhat. A periódikus pillanatnyi szemcsézettség (periodic snapshot grain) egy elıre meghatározott idıtartamhoz kapcsolódik. A tényértékek összegzik a tevékenységeket az adott idıintervallumban. Ez a szemcsézettség garantálja, hogy minden riportolandó entitás (pl. bankszámla) megjelenik minden periódusnál még akkor is, ha nem ment végbe hozzá kapcsolódóan semmilyen tevékenység. Az ilyen szemcsézettségő ténytáblák szintén elég nagyok lehetnek. A felhalmozó pillanatnyi szemcsézettség (accumulating snapshot grain) egy elıre meghatározott folyamathoz kapcsolódik, melynek meghatározott kezdete és vége van. A ténytábla sorai idırıl idıre változnak, felülíródnak. Egy ilyen ténytábla esetén például nyomon követhetünk egy termékszállítmányt egészen addig, amíg azok ki nem kerülnek a raktárból. Ez a szemcsézettség eléggé eltér az elızıektıl. A ténytábla is sokkal kevesebb sort tartalmaz a felülírási stratégia miatt. A ténytáblába soraiban kettı vagy több külsı kulcsos hivatkozás is szerepelhet. Ezek a külsı kulcsok valamely dimenziótábla elsıdleges kulcsához kapcsolódnak. Ha a ténytáblában minden kulcs helyesen illeszkedik a megfelelı dimenziótáblához, akkor azt mondjuk, hogy a táblák eleget tesznek a hivatkozási integritásnak (referential integrity). A ténytáblát mindig a hozzá kapcsolódó dimenziótáblákon keresztül érjük el. A ténytáblának magának van egy elsıdleges kulcsa, melyet külsı kulcsok egy részhalmaza alkot. Ezt a kulcsot gyakran összetett vagy konkatenált kulcsnak nevezik (composite key). Minden dimenzió modellben lévı ténytáblának van összetett kulcsa, és fordítva is igaz, hogy minden olyan tábla, mely rendelkezik összetett kulccsal, az ténytábla. A dimenzió modellben a ténytáblák leírják a dimenziók közötti N:M-es kapcsolatot. 5.3.3

Tények és dimenziók összekapcsolása

Miután megértettük, hogy mik is azok a tény- és dimenziótáblák, rakjuk ıket össze egy többdimenziós modellben. Ahogy azt az 5.7-es ábrán is láthatjuk, a ténytáblánk több


27/51


numerikus

értéket

tartalmaz,

melyekhez

több,

leíró

attribútumokkal

feltöltött

dimenziótáblát kapcsoltunk. Az összekapcsolt táblák jellegzetes csillagszerő szerkezetet mutatnak, melyet csillagsémának nevezünk.

5.7 ábra - Tény- és dimenziótáblák a többdimenziós modellben

Amit az ábrán elsınek észrevehetünk az, hogy az eredményül kapott dimenziós séma eléggé egyszerő és szimmetrikus. Ezáltal mindent könnyebben átláthatunk. Az egyszerő dimenziós modellnek teljesítménybeli elınyei is vannak. Az adatbázis optimalizálók a kevesebb kapcsolatokkal rendelkezı, egyszerő sémákat sokkal hatékonyabban fel tudják dolgozni. Ezen felül dimenziós modellünkön bármikor változtathatunk. Például beilleszthetünk egy teljesen új dimenziót, ha a ténytábla minden sorához hozzá tudunk rendelni egy értéket az új dimenzióból. Valamint a dimenziók attribútumait is módosíthatjuk. Ha már rendelkezünk egy normalizált ER diagrammal, azt is átültethetjük dimenziós modellbe. Ilyenkor elsı lépésként az ER diagramot szét kell választanunk elkülönülı üzleti folyamatok szerint, majd ezeket külön-külön kell lemodelleznünk. Második lépésként ki kell válogatnunk az ER diagram alapján azokat az N:M kapcsolatokat, melyek numerikusak és additívak, valamint nem szolgálnak kulcsként, és ezeket át kell ültetnünk a ténytáblába. Végsı lépésként denormalizálnunk kell a fennmaradó táblákat, és létrehozni a dimenziókat a ténytáblához kapcsolódó kulcsokkal. 5.3.4

Az

ROLAP adatmodellek

adattárházak

legnépszerőbb

adatmodellje

a

többdimenziós

adatmodell.

A

többdimenziós modellezés leggyakoribb sémái a csillagséma, a hópehelyséma vagy a galaxisséma (más néven csillagképséma).


28/51


5.3.4.1

Csillagséma adatmodell

A leggyakoribb modellezı minta a csillagséma, amelyben az adattárház tartalmaz egy nagymérető központi táblázatot, a ténytáblázatot, amely nagymennyiségő adatot tárol redundancia nélkül, és kisebb kísérı táblázatokat (dimenziótáblázatokat), egyet minden dimenzióhoz. A reláció típusa a ténytábla és a dimenziótáblák között 1-N kapcsolat, ezért a dimenziótáblák jelentısen kisebb méretőek a ténytáblánál. Úgy lehet elképzelni, mintha a dimenziótáblák alkotnák a csillag csúcsait, a ténytábla pedig a közepét. Innen ered a csillagséma elnevezés. 5.3.4.2

Hópehelyséma adatmodell

A hópehelyséma a csillagséma változata azzal a különbséggel, hogy néhány, közvetlenül a ténytáblához csatlakozó dimenziós tábla további altáblákra van osztva, ezzel lehetıvé téve a dimenziós táblák normalizálását (mert amúgy a dimenziós táblák második normálformában vannak), és így a szükséges tárhely csökkentését. További elınye, hogy a tárolás hatékonysága javul a redundancia csökkentése miatt. Hátránya azonban, hogy a táblák számának növekedésével az adatlekérdezések bonyolultsága nıhet, és a megtakarított tárhely is elenyészı a ténytábla méretéhez képest. Ezért nem vált olyan elterjedtté, mint a csillagséma modell. 5.3.4.3

Galaxisséma adatmodell

A csillagsémának ebben a változatában még egy ténytábla található. Ezek a ténytáblák a dimenziós táblákat is megoszthatják egymás között. Erre kifinomult alkalmazásokban lehet szükség, azaz, hogy több ténytábla megosszon egymás között egy-egy dimenziótáblát. 5.3.5

Többdimenziós modelltervezési folyamat

A többdimenziós tervezési folyamatot négy részre oszthatjuk. Ezeket nézzük meg a következıkben. 1. Elsıként meg kell határoznunk azokat az üzleti folyamatokat, melyeket modellezni szeretnénk. Ezek alatt a folyamatok alatt a szervezet által gyakorolt természetes üzleti tevékenységeket értjük. Fontos, hogy az üzleti folyamatok nem feltétlenül esnek egybe a szervezet egyes elkülönülı üzleti részlegeivel vagy funkcióival. Például létrehozhatunk egy olyan dimenziós modellt, mely a megrendeléseket kezeli; ahelyett, hogy külön modellt építenénk a szervezet


29/51


eladási és marketing részlegének, melyek mindegyike a megrendelési adatokat szeretné elérni. Ha ugyanazon üzleti folyamatokra vonatkozóan eltérı dimenziós modelleket hozunk létre, akkor szinte elkerülhetetlen lesz, hogy ezek értelmezésükben és terminológiájukban ne különbözzenek. Ez az adatok inkonzisztenciájához vezethet. A legjobb módszer arra, hogy az adatok konzisztenciáját biztosítsuk az, hogy az adatokat csak egyszer publikáljuk a modellben. Ez részben azért is jó, mert ezzel csökkenthetjük az ETL folyamatok fejlesztési erıforrás-szükségleteit. 2. Második lépésként meg kell határoznunk az üzleti folyamatok szemcsézettségét. Ez számunkra azt fogja jelenteni, hogy pontosan meg kell mondanunk, hogy mit fog reprezentálni a ténytábla egy sora. A szemcsézettség meg fogja határozni a ténytábla értékeihez rendelt részletesség szintjét. Az adattárház-tervezı csapatok gyakran átugorják ezt a látszólag felesleges lépést, pedig ez nagyon lényeges momentuma a tervezési folyamatnak. A szemcsézettség helytelen meghatározása adattárház implementációnkat frekventálttá teheti, azaz elıidézhet, hogy gyakran kell változtatnunk rajta. 3. A harmadik lépésben kiválasztjuk a dimenziókat, melyeket a ténytáblánál alkalmazunk. Ha a szemcsézettséget sikerült jól meghatároznunk, akkor a dimenziókat is könnyedén azonosíthatjuk. A dimenziók megválaszolják azt a kérdést, hogy „Mik írják le azokat az adatokat, melyeket egy üzleti folyamat eredményez?”. 4. Negyedik lépésként meg kell határoznunk azon numerikus értékeket, melyek a ténytáblába kerülnek. Minden ténynek meg kell felelnie a 2. pontban definiált szemcsézettségnek. Amennyiben olyan tényeink is vannak, melyek más szemcsézettséghez tartoznak, azokat egy különálló ténytáblába kell raknunk. A tények azt a kérdést válaszolják meg, hogy „Mit mérünk?”. Éppen ezért a tények tipikusan numerikus értékek (mint például megrendelt mennyiség, vagy euróban megadott költség). 5.4

HOLAP architektúra

A HOLAP (Hybrid OLAP) az elızı két architektúra elınyeit ötvözi. Ezt úgy éri el, hogy az összegzett adatokat MOLAP-, az elemi adatokat pedig ROLAP architektúra szerint tárolja.


30/51


Ezen felül lehetıségünk van arra is, hogy egy adatkockán belül különbözı tárolási módokat válasszunk. Például az 5 évtıl régebbi, kevésbé használt adatokat tárolhatjuk a tárkapacitás szempontjából kedvezıbb ROLAP architektúrájú partíción, míg az ettıl korábbi adatokat tárolhatjuk a lekérdezési teljesítményre optimalizált MOLAP partíción.

MOLAP

ROLAP

Adatok tárolása többdimenziós

Adatok tárolása relációs oldalon

adatbázisban

HOLAP Összegzett

adatok

többdimenziós,

tárolása

elemi

adatok

tárolása relációs oldalon Leggyorsabb lekérdezés

Legkisebb tárkapacitás

ROLAP és MOLAP elınyének ötvözése

A

MOLAP

adatkockák

szerkezete

nagyon

hasonlít

a

relációs

csillagséma

adatmodellekhez. Mivel relációs oldalon nagyon könnyő felépíteni egy csillagsémát, ezért sokszor alkalmazzák azt a megoldást, hogy csillagsémából ültetik át az adatokat egy MOLAP adatkockába. Ez egyszerőbb megoldás, mint a forrásrendszerekbıl közvetlenül tölteni az adatkockákat. Feltehetnénk azt a kérdést, hogy akkor miért építünk ugyanarra az adatkörre egy relációs és egy többdimenziós adatbázist is. Erre az lehet a válasz, a MOLAP architektúra elemzések szempontjából sok elınnyel rendelkezik relációs társával szemben, hiszen lényegesen jobb lekérdezési teljesítményt nyújt, valamint fejlettebb elemzést segítı funkciókkal rendelkezik.

6

ETL FOLYAMATOK Az ETL (Extraction, Transform and Load) folyamatok az adatok forrásrendszerekbıl történı kinyerését, transzformációját valamint az adattárházba való betöltését foglalják magukba. Ezen felül biztosítják az adatok megfelelı minıségben történı adattárházba jutását. Az ETL rendszerek a háttérben, az adattárház végfelhasználói elıl elrejtve mőködnek. Egy adattárház ETL rendszerének megépítése gyakran az adattárház implementációs és karbantartási erıforrásainak hetven százalékát is felemészthetik. Ebbıl is látszik, hogy mennyire fontos ennek az alrendszernek a pontos, jó megtervezése.

6.1

Adatok kinyerése a forrásrendszerekből

Adatok nélkül egy adattárháznak semmi hasznát sem vehetnénk, ezért azt fel kell töltenünk adatokkal. Ezeket az adatokat különbözı adatforrásokból nyerjük ki, mely


31/51


tevékenység az ETL folyamatok elsı lépését képzi. Az adatok három fı adatforrásból kerülhetnek az adattárházba. A külső adatforrások (external data source) a vállalathoz közvetlenül nem kötıdı adatokat jelenítenek meg (pl. gazdasági információk). A független adatpiac (independent data mart) egy olyan adattár, mely egy lokális, jól körülhatárolt témájú, meghatározott felhasználói csoport részére konkrét feladatot lát el. Az adatpiacon tárolt adatok a központi adattárházba tölthetıek annak érdekében, hogy a vállalat különbözı részlegei is hozzáférhessenek az adatokhoz. Az adatok harmadik fı forrását az tranzakciós (OLTP), hagyományos relációs és más adatbázisok jelentik. Az adatok elıször egy átmeneti területre kerülnek (data staging area), ahol azokon végrehajtódnak a megfelelı transzformációk. Idınként, ezen az átmeneti területen megıriznek olyan adatokat, melyek segítségével olyan funkcionalitásokat nyújthatnak, melyek hisztorikus adatokat igényelnek, míg máskor az adatok minden egyes sikeresen lezárult folyamat végeztével törlıdnek.[4] Az egyes cégek, szervezetek egyszerre több különálló vagy összekapcsolódó számítógépes rendszert is használhatnak, mint például eszközkezelési, termékvezérlési, vagy általános könyvviteli rendszereket. Ami viszont számunkra fontos, hogy ezek a rendszerek gyakran logikailag és fizikailag is inkompatibilisek. Ezért, mielıtt egy ETL rendszert építenénk, létre kell hoznunk egy logikai adattérképet (logical data map), mely a táblák kezdeti forrás-adatmezıi és a végsı cél-adatmezık közötti kapcsolatokat dokumentálja. A logikai adattérkép tartalmazza az adattárház forrásrendszereinek adat definícióit, a cél adattárház adatmodelljét, valamint azt a pontos adatkezelést, mely szükséges ahhoz, hogy az adatokat az eredeti formájukból a megfelelı, végsı formára hozhassuk. A logikai adattérképet általában táblában vagy valamilyen táblázatkezelı formátumban jelenik meg, és a következı összetevıket tartalmazza[4]: •

Cél tábla neve: a tábla fizikai neve, ahogy az megjelenik az adattárházban.

•

Cél oszlop neve: az oszlop neve az adattárház táblában.

•

Tábla típus: azt jelzi, hogy a tábla ténytábla, dimenzió vagy aldimenziótábla –e.

•

SCD (slowly changing dimension) típus: Ez a típusjelölı a lassú dimenzió változást jelzi. Leggyakrabban a Type-1, Type-2 és Type-3 SCD típusokat alkalmazzák. Ez a típusjelölı érték oszloponként különbözı lehet.

•

Forrás adatbázis: annak az adatbázisnak a neve, ahonnan a forrás adat származik. Ez lehet egy adatbázis elérési név, vagy akár egy fájl neve.


32/51


•

Forrás tábla neve: annak a táblának a neve, amelyikbıl a forrás adat származik. Sok esetben itt több táblanevet is meg kell adnunk. Ekkor egyszerően fel kell sorolni azoknak a tábláknak a nevét, melyek szükségesek ahhoz, hogy feltöltsük a megfelelı adatokat a céltáblába.

•

Forrás oszlop neve: a forrás oszlop vagy oszlopok nevei. Azon oszlopok nevei, melyek szükségesek, hogy a céloszlop értékeit meghatározzuk.

•

Transzformáció:

a

forrásadaton

végzendı

pontos

módosítások,

melyek

meghatározzák a cél elvárt formáját. Ezt a komponenst általában SQL-el vagy pszeudó kóddal írják le.

Az elıállított logikai adattérkép azt a célt szolgálja, hogy leírjuk vele, mit is várunk el pontosan az egyes ETL folyamatoktól. Az adattárházban lévı adatoknak követniük kell az operatív adatokban bekövetkezett változásokat. Az adatfrissítés gyakoriságának meghatározása alapos körültekintést igénylı feladat, mivel a túl gyakori adatfrissítés könnyen a tranzakciós rendszerek túlterheltségéhez vezet, míg a túl ritka adatfrissítés esetén az elemzett adatok válnak elavulttá. Így az adatok csoportosíthatók óránként, naponta, hetente vagy havonta, illetve az egyes események bekövetkezése után frissítendı adatokra, s ez alapján idızíthetı az adattöltés a tranzakciós rendszerek számára megfelelı idıpontra (kis terheltségő idıszakok, éjszakai órák, hétvégék). Ez rendkívül fontos lehet, hiszen az adattárházba való adatáttöltés hatalmas mennyiségő adat mozgásával járhat. Az adattárházat inkrementálisan töltjük fel adatokkal, azaz a forrásrendszerekbıl csak azokat az adatokat kell kivonnunk, melyek még nem kerültek be az adattárházba. 6.2

Adatok transzformációja

Az adatok transzformációjához definiálnunk kell, hogy milyen minıségben szeretnénk adatainkat látni az adattárházban. Fontos, hogy az adatminıséget úgy határozzuk meg, hogy adataink legyenek akkurátusak, azaz teljesüljenek rájuk a következı jellemzık: •

Korrektség: az adatokat leíró értékek megfelelnek a valóságnak. (Például, ha egy személy az Ady Endre utcában lakik, akkor a levelezési címében az utca megjelölésekén az Ady Endre utcának kell szerepelnie.)

•

Egyértelműség: az adatokat leíró értékeket csak egy jelentésnek megfelelıen elehet venni. (Például, mivel nagyon sok városban található Ady Endre utca,


33/51


ezért hogy egyértelmő legyen, az utcanevet minısíthetjük annak a városnak a nevével, amelyikben lévı adott utcára hivatkozunk – Debrecen, Ady Endre utca.) •

Konzisztensség: az adatokat leíró értékek esetén egyetlen, azonos konvenciót alkalmazunk a jelentésük átadására. (Például Magyarországra hivatkozhatunk Mo. rövidítéssel, vagy akár a teljes nevével. A konzisztencia azt jelenti ebben az esetben,

hogy

mindenhol

ugyanazzal

a

konvencióval

hivatkozunk

Magyarországra.) •

Teljesség: a teljességnek két szempontja van. Az elsı, hogy biztosítanunk kell, hogy az adatok különbözı értékei minden példányhoz definiálva vannak. A második szempont szerint pedig biztosítanunk kell, hogy adatok összevont rekordjai esetén ne vesszenek el egyes rekordok.

Adatgyőjtés után a különbözı adattisztító és adatfeldolgozó eljárásokkal juthatunk tisztított és feldolgozott adatokhoz. Az adattisztításon hiányzó értékek pótlását (pl. egy odaillı átlagos értékkel), a normalizálást (pl. euró-forint váltás), illetve konzisztens reprezentációt értünk. Adatfeldolgozó eljárás pedig például a kódfeloldás (pl. vonalkód „megfejtése”).

Finomításon

a

részadathalmazok

generálását,

számított

mezık

létrehozását, információk összegzését értjük. 6.3

Adatok betöltése az adattárházba

Az adatokon végzett transzformációk mind azért történtek, hogy az adatokat a továbbiakban minél könnyebben be tudjuk tölteni az adattárházba. Általánosságban az adattárházba került adat már nem fog változni. Ez alól egy nyilvánvaló kivétel lehet, ha kiderül, hogy hibás adatok kerültek az adattárházba.

7

INTELLIGENS ADATTÁRHÁZAK Az elsı generációs adattárházak támogatják az adattisztítást, transzformációt és az adatbetöltést. Gyakran ezek az adatok a szervezet legegyszerőbb, legkisebb szintő ismeretet hordozó adatai. Ahhoz, hogy ezeket az ismereteket elérhetıvé tegyék, metaadatokat

definiálnak.

A

metaadatok

leírják

az

adatok

attribútumait,

transzformációkat, aggregációs szinteket, valamint munkafolyamat információkat.


34/51


A következı generációs adattárházakat intelligens adattárházakként (IDW – Intelligent Data Warehouse) hozzák létre. Az IDW-k olyan adattárházak, melyek egy tudástárház által aktív adatforrásként vannak kezelve. A tudástárházak (Knowledge Warehouse) szakértıi rendszermodelleket használó szoftver motor által létrehozott és vezérelt objektumokat alkalmaznak. Ezek az objektumok szabályokat, metódusokat és eljárásokat biztosítanak újrafelhasználható módon. A tudástárházak kezelik az üzleti objektumokat, szabályokat és eljárásokat, hogy ez által formálják az ületi tudást. Az üzleti tudás pedig kialakítja az alapokat és az infrastruktúrát az intelligens adattárház üzleti folyamatainak kezeléséhez. Napjainkban rengeteg olyan szervezet van, melyek rámutatnak, vagy szóba hozzák az intelligens adattárházak szükségességét. Ezek a szervezetek különbözı módokat javasolnak az elsı generációs adattárházakban való üzleti intelligencia alkalmazásának. Sokan közülük azt a szemléletet vallják, hogy az adatbányászat szolgáltat „intelligenciát” az adattárházaknál. Néhányan pedig úgy vélik, hogy a tartalom-menedzselés szolgáltatja ugyanezt, mások szerint pedig a portálok. Az intelligens adattárházak megkövetelik az adatbányászat használatát az ismertek hasznosításához. Az adatbányászat kiterjeszti az intelligenciát, hogy felfedjék az adattárház adatok és üzleti folyamatok közötti kapcsolatokat. Habár magában az adatbányászat nem követeli meg az adattárházak használatát, viszont az üzleti folyamatokat támogató adatbányászati stratégiák nélkül egy intelligens adattárház nem lehet teljes. Számos szoftvercsomag létezik, melyek támogatják a tudás-menedzsmentet. Ezek leginkább a tudás-tartalom menedzsmentre (knowledge content mangement) fektetik a hangsúlyt.

A

tudás-tartalom

menedzsment

modern

lehetıségeket

nyújt

a

dokumentumkezelésre és a csoportok közötti interakciókra. Ezeknek a szoftvereknek a fı erıssége az email-kommunikáció és a munkacsoport együttmőködés erısítése, valamint segítséget nyújtanak a dokumentumok keresésében és tárolásában. Ezek a szoftverek azzal támogatják az IDW-t, hogy információkat szolgáltatnak a vállalatról. Habár tudást hordoznak magukban az adattárház metaadatai, és a tartalom menedzsment is, ezek nincsenek kapcsolatban egymással. Az adat és a tudás közötti kapcsolat kiépítését az adatportálok (Data Protals) oldják meg. Az adatportálok kapcsolatot létesítenek az adatforrások és a tartalom információk között. Így már majdnem azt mondhatnánk, hogy a portálok utat biztosítanak az adattárházaknak az üzleti intelligencia integrálása felé, de


35/51


mi van az információk újrafelhasználhatóságával? Gyakran a tartalomban lévı tudás nem újrafelhasználható és rövid élettartamuk van, mely során idınként frissíteni kell ıket. Az adatportálok az IDW egy fontos részét képezik, de ez még mindig csak egyetlen komponense az IDW architektúrának. Az intelligens adattárház architektúra magába foglal egy tudástárházat (Knowledge Warehouse), mely támogatja az újrafelhasználható ismeret rugalmas módszerekkel és folyamatokkal való összekapcsolását. A tudástárház és az adattárház szerkezetének olyannak kell lennie, hogy képes legyen követni a cég változásait, mely által az információk és a vállalat céljai összhangba kerülnek egymással.

Tudástárház

Adattárház

Tudásbázis Metaadatok Tudásbázis ODS

Folyamatok

Adat csoportok Nézetek

Objektumok Szabályok Csomagok Többdimenziós

Adatbányászat

7.1. ábra - IDW architektúra 1

Ahhoz, hogy egy elsı generációs adattárházat intelligens adattárház szintre emeljünk, négy tervezési lépést kell végrehajtanunk. Elsıként szükségünk van egy olyan szoftverre, mely kezeli az adattárház metaadatait. A legtöbb ilyen szoftver támogatja az OMG (Object Management Group) által kifejlesztett Common Warehouse Metamodel-t. A CWM egy olyan keretrendszer, mellyel leírhatjuk az adaterıforrásokat, adatelemzési- és tárházkezelési információkat. A CWM több metamodelt, üzleti intelligenciát, ismeret-kezelést (knowledge management) és portál technológiát definiál. Következıként, a tárháznak az üzleti hálózaton keresztül kell kommunikálnia, hogy az adatokat közel valós idıben tudja kezelni. Harmadik követelményként lennie kell egy tudástárháznak, melynek tudásbázis könyvtárakat kell tartalmaznia. Ezekben a tudásbázisokban konkrét üzleti szabályokkal, módszerekkel és konkrét feladatokra vonatkozó eljárásokkal rendelkezı objektumok IntelligensAdattárházak

36/51


vannak. A tudásbázisok más tudásbázisokkal együtt dolgoznak, hogy ezzel is növeljék az újrafelhasználhatóság. Végül pedig az IDW-nek tartalmaznia kell egy szoftveres motort, mely egy szakértıi rendszert implementál, hogy az adattárház adatait feldolgozza, konkrét üzleti célok eléréséhez. Ehhez a tudástárház objektumait használja fel. Az IDW elsıdleges célja, hogy összekapcsolja a tudástárház- és az adattárház folyamatokat az operatív rendszerekkel, ezzel biztosítva minıséget, funkcionalitásokat és információ megosztást. Az IDW tudástárháza vezérli a végfelhasználók front-end rendszerek felıl érkezı kéréseit, szakértı rendszer rutinokat hív meg, valamint vezérli az információ megosztást. A végfelhasználók hozzá férhetnek az üzleti szabályokhoz, eljárásokhoz és a munkafolyamatokhoz.

7.2. ábra - IDW architektúra 2

Mint láthattuk, az intelligens adattárházakhoz szorosan kapcsolódnak az üzleti intelligencia, döntéstámogatás és adatelemzés fogalmak. A továbbiakban ezeket nézzük meg kicsit részletesebben. 7.1

Üzleti Intelligencia

Az üzleti intelligenciát (Business Intelligence - BI) úgy definiálhatjuk, hogy a helyes hozzáférés a helyes adatokhoz és információkhoz, melyek szükségesek ahhoz, hogy meghozzuk a helyes üzleti döntéseket a helyes idıben. Egy másik megfogalmazás szerint pedig, üzleti intelligencia alatt értünk minden olyan tevékenységet, eszközt, vagy folyamatot, melyet arra használunk fel, hogy megszerezzük a leghasznosabb


37/51


információkat a helyes döntéshozatalhoz. Ez az üzleti intelligenciának egy elég széleskörő megfogalmazása, mely nem korlátozódik kizárólag az adattárházakra. A BI számos alkalmazás, valamint adatbegyőjtési-, tárolási-, elemzési és adathozzáférési technikák széles kategóriáját foglalja magába. Ezen alkalmazások és technikák célja, hogy segítséget nyújtsanak felhasználóinak a jobb üzleti- és stratégia döntések meghozatalához, valamint hogy szélesebb körő rálátást biztosítson a vállalat üzleti folyamataira. A BI által szolgáltatott információk minden felhasználó és vállalat számára fontos lehet. A BI alapjai nem új keletőek, hiszen már számos törekvés volt az üzleti döntéstámogatás elısegítésére. •

DSS: Decision Support Systems – döntéstámogató rendszerek. A DSS rendszerek nagy népszerőségre tettek szert, mivel számítógépes erıforrások és hisztorikus

adatok

segítségével

elısegítik

olyan

összetett

problémák

megoldását, mint például termelési ütemezés és más szokványos tervezési döntések. •

EIS: A DSS sikerére felszínre került egy újabb döntés-menedzselı eszköz, melyet Executive Information Systems (EIS – Vezetıi Információs Rendszerek) technológiának neveznek.

•

MIS, MDS, AIS, és mások: számos BI-t megelızı törekvések születtek. Ezek közül a legfontosabbak a Management Information Systems, Management Decision Systems, Analysis Information Systems, és még sok más hasonló rendszer, melyek mindegyike kicsit új stílust hozott a cégek döntéshozó folyamatába.

Ezek a technológiák hozzájárultak a mai üzleti intelligencia fogalom kialakulásához, természetesen némelyik jobban, mások pedig kevésbé. A tranzakciós alkalmazások általában a tranzakciós táblákban lévı, aktuális adatokat jellemzı riportokon keresztül nyújtanak üzleti intelligenciát az üzleti felhasználók számára. Ezek a kiválasztott riportok kulcs követelmények alapján jönnek létre. Sok cég a riportok és elemzések egyre bonyolultabbá válásával, olyan üzleti intelligencia megoldásokat alkalmaznak, melyek összetett adattárház stratégián alapulnak. Az adattárház megépítése elıtt viszont tisztázni kell, hogy milyen típusú üzleti intelligenciára van szükségünk. A továbbiakban nézzük meg az üzleti intelligencia egy lehetséges kategorizálását.


38/51


7.1.1

Az üzleti intelligencia kategóriái

Az üzleti intelligenciánál négy kategóriát különböztethetünk meg: • alap lekérdezések és riportolások (Basic querying and reporting) • üzleti elemzés (Business Analysis – BA) • adatbányászat (Data mining) • Dashboards 7.1.1.1

Lekérdezések és riportolások

Az alap lekérdezések és riportolások nagyrészt az elemzési célból felhasználható adatok hagyományos alkalmazását foglalja magába. Az elemzendı adatokat általános riportokkal vagy ad-hoc lekérdezésekkel érjük el, majd az eredményt egy meghatározott formában jelenítjük meg a végfelhasználó számára a képernyın vagy nyomtatott formában. Ez alapján a következı lépésekre bonthatjuk fel ezt a folyamatot:

7.1.1.2

1.

az elemzendı adatok iránti igény meghatározása,

2.

adatok kinyerése a megfelelı forrásokból,

3.

amennyiben szükséges, az adatok összegzése, újraszervezése,

4.

az adatok formázása,

5.

és végül megjelenítés.

Üzleti elemzés

Az üzleti elemzés (Business Analysis) a felhasználó interakciós modellbe egy elemzési folyamatot és a változtathatóság lehetıségét vezeti be. Alapjában véve az elızı kategórián felül a következıket biztosítja: 6. Az adatokra különbözı szemszögökbıl tekinthetünk. Pontosabban meghatározhatjuk, hogy mit szeretnénk látni. 7. Nekünk tetszıen módosíthatjuk meg a megjelenítést. 7.1.1.3

Adatbányászat

Az adatbányászat (Data mining) már jobban elkülönül az üzleti intelligencia elızı két formájától, mivel az üzleti felhasználók nem rendelkeznek az adatbányászat statisztikai alapjainak elvárt tudásával. Az adatbányászati eszközök olyan elemzési technikákat nyújtanak, melyek megkövetelik az alapvetı adatbányászati algoritmusok ismeretét. Ezek az eszközök hatalmas adatmennyiségeket elemeznek, melyekben mintákat és más aspektusokat igyekeznek felfedezni, mellyel lehetıvé válik, hogy a jövıbe mutató


39/51


következtetéseket vonhassunk le. Fontos, hogy az adatbányászat egy olyan technika, mely a lehetıségeket mutatja meg számunkra, és nem egy olyan szolgáltatás, ami megmondja a jövıt. A lekérdezések és riportolásoknál, valamint az üzleti elemzésnél az üzleti intelligenciát az biztosította számunkra, hogy pontosan feltett kérdésekre kaptuk meg a válaszainkat. Itt a kulcsszó a kérdés volt. Ezeknél a kategóriáknál, ha nincs kérdés, akkor nincs is mit megválaszolni. Az adatbányászat viszont tovább mutat ennél, hiszen feltárás-orientált természetébıl adódóan akkor is kapunk válaszokat, ha még nem is tudjuk pontosan mi a kérdés. Ez kicsit furának tőnhet, de az adatbányász rendszerek tipikusan olyan válaszokat nyújtanak számunkra, melyeket komplex modellek felépítésével határoz meg. Ezeket a modelleket adatelemzésre használják, mely adatokban trendeket, tendenciákat igyekeznek felfedezni. Az adatbányászatról részletesebben a 7.4. fejezetben írok. 7.1.1.4

Dashboards

Az üzleti intelligencia szótárában megjelenı „dashboard” kifejezést nehezen tudnánk igazán visszaadni magyar szavakkal. A szó eredeti jelentése mőszerfal, amirıl legtöbbünknek egy gépjármő része juthat eszünkbe. Ezt nevezhetnénk találó elnevezésnek is, hiszen a „dashboard” az autók mőszerfalához hasonlóan a legfontosabb információkat jeleníti meg számunkra. Ez az eszköz végülis egy megjelenítésre alkalmas grafikus megoldás. A „dashboard” gyakran egy portál oldal formájában jelenik meg, mely adatok és grafikus diagramok segítségével jeleníti meg a fı teljesítmény jelzıket, és fontos információkat. Ez az eszköz különbözı forrásokból képes információkat megjeleníteni, valamint gyors, könnyen érthetı, magas szintő nézetet nyújt az üzleti mőveletek prezentálására.[7] 7.2

Döntéstámogató rendszerek, döntés hozás

A döntéstámogató rendszerek (Decision Support Systems – DSS) a számítógép alapú információs rendszerek (Computer-based Information Systems – CBIS) részét képzik. Ez az elnevezés (CBIS) különbözı információs rendszereket foglal magába, mint például iroda-gépesítési rendszereket, tranzakciós feldolgozó rendszereket, menedzsment információs rendszereket és menedzsment-támogató rendszereket. A menedzsment támogató rendszerek (Management Support Systems) közé tartoznak a szakértıi rendszerek, végrehajtó információs rendszerek, valamint a döntéstámogató rendszerek is ide sorolhatóak. A döntéstámogatás a döntéshozás folyamatának egy részét képezi. A IntelligensAdattárházak

40/51


döntést úgy definiálhatnánk, hogy egy választás több lehetséges alternatíva közül. A döntéshozás folyamatának célja, ennek a választásnak a meghatározása. A döntéshozás és a döntéstámogatás nem összekeverendı fogalmak. Egy döntéstámogató rendszer önállóan nem hoz döntést, csak támogatja a döntéshozás folyamatát. A döntési folyamat négy lépésbıl áll: •

feladat meghatározása és adatgyűjtés: belsı és külsı rendszerekbıl történı

adatgyőjtés.

A

probléma

azonosítása

és

felbontása

részproblémákra. •

tervezés: modellépítés, választási feltételek, szabályok meghatározása, alternatívák keresése.

•

választás: megoldás kiválasztása, választás igazolása.

•

megvalósítás:

döntés

sikerének

és

sikertelenségének

elbírálása,

visszacsatolás. 7.3

Tudásfeltárás - KDD

A tudásfeltárás (Knowledge Discovery in Databases – KDD) több összekapcsolódó lépésbıl áll, melynek csak egy része az adatbányászat. A KDD egy feltörekvı terület, mely több eszközt és technikát nyújt a döntéstámogatás és az adatanalízis számára, melyek megkönnyítik a hasznos tudás kinyerését nagy mennyiségő adatokból. A KDD folyamat egy iteratív, többlépéses, az emberi interakciókhoz közel álló folyamat. A 7.3. ábra jelöli a KDD folyamat lépéseit.

7.3. ábra - KDD folyamat


41/51


Körvonalazzuk a KDD folyamat alaplépéseit. Elsıként azonosítanunk kell a folyamat célját, mely visszatükrözi a felhasználó nézıpontját. Másodikként létre kell hoznunk egy cél adathalmazt: ki kell választanunk azokat az adatokat, amelyeken végre akarjuk hajtani a tudásfeltárást. A harmadik lépés az adattisztítás és elıfeldolgozást. Ezek alapmőveletek, melyek eltávolítják az adatokból a zajokat, összegyőjtik a szükséges információkat a modell számára, kiválasztják a hiányzó adatmezıket pótló stratégiát, és még más egyéb elıkészítı mőveleteket hajtanak végre. A negyedik lépés az adatredukció és projekció. A feladat céljától függıen kell az adatokat reprezentálni. Ide dimenzió redukció mőveletek és transzformáló módszerek tartoznak. Ötödikként a KDD folyamat céljait rá kell illeszteni egy jól megválasztott adatbányászati algoritmusra, mint például összegezés, osztályozás, regresszió, klaszterezés vagy más egyéb. A hatodik lépésben feltáró elemzéseket és a feltevések kiválasztását kell elvégezni. Ki kell választani azokat az adatbányászati algoritmusokat és módszereket, melyeket az adatminták feltárására használunk fel. Itt döntenünk kell, hogy melyik modellt és milyen paramétereket, valamint milyen adatbányászati algoritmust használunk, figyelembe véve a KDD folyamat kritériumait. A hetedik lépés az adatbányászat: az érdekes minták megkeresése. A nyolcadik lépés a megtalált minták interpretálása, valamint estenként iterálás az elızı hét lépés valamelyikéhez való visszatéréssel. Az utolsó, kilencedik lépés pedig a feltárt tudás felhasználása: a tudás követlen felhasználása, a feltárt tudás továbbítása egy másik rendszerhez további tevékenységek elvégzésére, vagy egyszerően csak dokumentálás és riportolás. 7.4

Adatbányászat

Az adatbányászat (Data Mining) a 90-es években kezdett elterjedni. Az adatbányászat, mint önálló szakterület úgy jöhetett létre, hogy könnyen használható, hatékony elemzési eszközöket tudott biztosítani szakértık számára. Az adatbányászat lényege, hogy nagy mennyiségő nyers adatokból elızetesen nem ismert, hasznos, külsı szemlélı számára nem-triviális információkat, összefüggéseket nyerjünk ki. Az adatbányászat folyamata a szükséges adatok összegyőjtésébıl, adatbányászati módszer alkalmazásából, a kinyert információk reprezentálásából és a megszerzett tudás felhasználásából áll. Az adatok mennyiségének növekedése legfıképp annak köszönhetı, hogy az utóbbi évtizedekben az emberi tevékenységek, az informatikának köszönhetıen egyre inkább automatizálttá válnak. Ez a megnövekedett automatizáltság és elektronikus módon


42/51


történı dokumentáltság folyamán növekedik egyre nagyobbá az adathalmaz. Az adatok győlnek mindenhol és mindenrıl, és hogy felhasználásuk egyszerőbbé váljon, ki kell tudnunk szőrni a hatalmas adathalmazból a fontos információkat. Az elıbbiekben többször is használtuk az adat, az információ és a tudás szavakat. Habár hasonlóan hangzanak, jelentésük mégis eltér egymástól. Az adatok önmagukban is hordoznak valamiféle információt, viszont az is nagyon gyakori eset, hogy több adat együtt, csoportosan szolgál számunkra valamilyen információval. A harmadik szó, a tudás alatt pedig a feldolgozott információt érthetjük, mely támogatást szolgáltathat a döntéshozatalra.[5] 7.4.1

Az adatbányászat célja

Az adatbányászat egy olyan döntéstámogatást szolgáló folyamat, mely érvényes, hasznos és elızıleg nem ismert, tömör információt tár fel nagy adathalmazból. Az adat alapú tudásfelmérésnek tulajdonképpen kétféle célja lehet: megerısítés és felfedés. Megerısítés alatt azt értjük, amikor a tudásfeltárás célja az adatelemzı egy adott feltevésének megerısítése. Ezzel szemben a felfedés (tudásfeltárás) során a rendszer generál hasznos információkat az adatokból. A tudásfeltárás alapján az adatbányászati feladatokat további két csoportra oszthatjuk: predikciós és leíró jellegő feladatokra. •

predikciós feladatok: A predikciós feladatoknál egyes jelenségek jövıbeni viselkedését, illetve nem ismert tulajdonságait kell megjósolni.

•

leíró jellegű feladatok: A leíró jellegő feladatoknál a jelenséget, illetve annak alakulását, és a jelenséggel kapcsolatosan feltárt összefüggéseket kell a lehetı legjobban értelmezhetı módon megtalálni.

Az adatbányászat legalapvetıbb problémája az, hogy hogyan lehet egy áttekinthetetlen adathalmazban megbúvó hasznos információkat feltárni, és ezeket eredeti adatok megjelenési formájánál kompaktabb, absztraktabb, informatívabb, és könnyebben kezelhetı módon reprezentálni. A tudás, melyet az adatbányászat elıállít, valamilyen modell vagy a rendelkezésre álló adatok általánosításaként áll rendelkezésre. Annak ellenére, hogy ma már rengeteg adatbányászati algoritmus létezik, ezen algoritmusok közös vonása, hogy indukció-alapú tanuláson alapulnak. Ennek a tanulásnak négy szintjét tudjuk megkülönböztetni:


43/51


•

Tények: A tény egy adott igazság egyszerő megállapítása. (pl. ma esett az esı)

•

Koncepció: A koncepció objektumok, szimbólumok vagy események csoportja, melyek azonos jelleggel bírnak. (pl. októberben gyakran esik az esı)

•

Eljárások: Az eljárás lépésrıl lépésre történı, valamely cél eléréséért végzett akciósorozat. (pl. ha indulás elıtt kinézünk az ablakon és esik az esı, akkor viszünk esernyıt)

•

Alapigazságok (principák): Az alapigazságok feltárása jelenti a tanulás legmagasabb szintjét. Principák általános igazságok, melyek más igazságok alapjai.

Az indukció-alapú tanulás egy koncepcióalkotási folyamat, mely során adatok alapján valamely koncepció, adat, általános érvényő ismeret keletkezik. E koncepciók általában adatbányászati

algoritmusok

kimenetei,

melyek

általában

döntési

fákban,

szabálybázisokban, hálózatokban vagy matematikai egyenletekben formalizálódnak. A tanulásnak ezt a formáját felügyelt tanulásnak nevezzük, ugyanis a tanulás során rendelkezésre áll az az információ, hogy az adott esetek milyen osztályokba tartoznak. A felügyelet nélküli tanulás az adatok elızetes osztályába való tartozásának ismeretét nélkülözve mőködik. Általában egy adott problémakörhöz tartozó objektumok egyes csoportjai bizonyos szempontok szerint hasonlóak egymáshoz, így az adatbázisban szereplı objektumokat azok egymáshoz való hasonlósága alapján csoportokba lehet sorolni.[5] 7.4.2

Adatok előfeldolgozása

Az adatbányászati módszerekkel elemezni kívánt adatok hiányosak, zajosak vagy inkonzisztensek lehetnek. •

Hiányos adat: ez akkor fordul elı, mikor bizonyos attribútumok részlegesen vagy teljesen hiányoznak. Ez csökkenti az adatok minıségét. Több módszer is kialakult a hiányzó adatok kezelésére. - Figyelmen kívül hagyhatjuk a hiányzó adatot, ha az elemzés szempontjából nem olyan fontos. Általánosságban, ha egy attribútum értékének 20%-a hiányzik, akkor nem veszik figyelembe.


44/51


- Megadhatjuk manuálisan a hiányzó adatot. Erre akkor van szükség, ha fontos információról van szó. - Használhatunk globális konstanst is. Ez lehet egy megadott fix érték vagy NULL érték. Esetleg használhatunk átlagértéket. Ez numerikus értékek esetén alkalmazható jól. •

Zajos adat: A zaj az adatokra rakódott, véletlenszerő hiba. A hiba lehet kis mértékő, de folyamatos, vagy ritka esetekben lehet kiugró értéket generáló. Erre is létezik többféle technika. - A Kosarazás technika lényege, hogy azonos számú kiválasztott értéket ugyanazzal a értékkel felülírjuk. A kiválasztáshoz tegyük fel, hogy egy kosárba legfeljebb n adat fér. Sorba rendezzük az adatokat, és az egymás mellett lévı n db értéket egy-egy külön kosárba pakoljuk. A simítást úgy végezzük, hogy vesszük az adott kosárban lévı értékek átlagát vagy mediánját, vagy az alsó vagy felsı határértéket, és ezzel felülírjuk a kosárban lévı értékeket. Minél szélesebb kosarat veszünk, annál erısebb lesz a simítás. - A klaszterezés technika lényege, hogy a hasonló értékeket csoportokba, klaszterekbe

soroljuk,

és

azokat

az

értékeket,

amik

nem

kerültek

klaszterbe(szélsıségesek), azokat nem vesszük figyelembe. - A regresszió technika esetén az adatok értékeire egy görbét illesztünk, amit a további feldolgozásban használunk. Lineáris vagy többváltozós regressziót szoktak használni. •

Inkonzisztens adatok: Inkonzisztens adatok alatt azokat az eseteket kell érteni, amikor bizonyos adatok teljesen összeférhetetlenek, az általuk reprezentált értékek nem felelnek meg egymásnak. Nincs meg az elvárt kapcsolat és egymásrautaltság az adatok között. Ezzel kapcsolatban oda kell figyelnünk az adatok közötti kapcsolatok sértetlenségére.

Az adatok elıfeldolgozást igényelnek, melyeket adattisztító rutinok futtatásával segíthetünk elı. Ezek a rutinok a zajos adatokon simítást végeznek, és azonosítják vagy eltávolítják a szélsıséges értékeket, valamint megszüntetik az inkonzisztenciát.[5]


45/51


7.4.3

Adatbányászati technikák

Az adatbányászat fogalmainak elıbbi körvonalazásaival közelebb kerülünk ahhoz a kérdéshez, hogy egy adott probléma megoldására milyen adatbányászati technika alkalmazása

célszerő.

A

következıekben,

körvonalazva

az

adatbányászati

algoritmusokban alkalmazott alapvetı technikákat, mőveleteket nézünk meg. Elıször tekintsük a felügyelt tanulás adatbányászati technikáit:[5] •

Osztályozás: Az osztályozás egy olyan összefüggés „tanulását” takarja, mely alkalmas arra, hogy ismert változók alapján egyes eseteket (objektumokat, azaz adatbázisbeli rekordokat) osztályokba sorolja. Az osztályozási feladat ennek megfelelıen két részfeladatra osztható: modell generálás és előrejelzés. Általában a modell generálás egy adott adathalmaz osztályozását jelenti adott számú diszjunkt részhalmazba. Az osztályozásra alkalmas modell bemeneti ismérvekbıl (tanító példákból) számol kiemeti attribútumokat (teszt példákat). A felügyelt tanulási stratégia egy adott tanulási halmaz – mely ismert osztályokba tartozó példányokból áll – segítségével építi fel az osztályozási modellt. Egy függvénykapcsolatot határoz meg a modell bemeneti és kimeneti attribútumai között. A generált modell elemzésével általában lehetıség nyílik annak a megállapítására, hogy a rendelkezésre álló ismérvek miként határozzák meg azt, hogy az adott elem melyik részhalmazba tartozik.

•

Regresszió:

A

regresszió

egy

következtetésre

alkalmas

függvény

meghatározását jelenti, de ebben az esetben a függvény célja az ismert ismérvekbıl más numerikus értékekre történı következtetés, azaz nem valamilyen kategorikus változó (pl. osztálycímke) becslése. Regressziós feladat például egy gazdasági vagy a termelési adatok által definiált idısor jövıbeni értékének meghatározása. Regressziós feladatok természetesen nem mindig kell, hogy kapcsolódjanak idıben történı változások elemzéséhez, gyakorta statikus összefüggések feltárása a cél.

A nem felügyelt tanuláshoz tartozó technikák: •

Csoportosítás(szegmentálás, klaszterezés): Olyan, nem felügyelt tanulási technika, mely segítségével egy adathalmaz objektumait úgy oszthatjuk fel csoportokra, hogy a csoportokon belül egymáshoz hasonló objektumok vannak, míg


a

csoportok

számottevıen

különböznek

egymástól.

Az

adatok 46/51


csoportosítását gyakran azok leíró jellegő elemzésére szokták alkalmazni, ugyanis e technika alkalmazása során a cél az adatokat jellemzı tipikus esetek olyan halmazának feltárása, melyek az adatbázisban lévı eseteket jól jellemzik. E feltárt csoportok gyakorta egymást kizáróak, de egyes esetekben akár egymással átfedık, netán hierarchikusak is lehetnek. A csoportosítási feladat algoritmikus eszközökkel történhet, így az adatbányásznak már csak annyi a feladata, hogy megpróbálja a csoportosítás eredményét kiértékelni, feltárni azt, hogy milyen jelentéssel és mekkora jelentıséggel bírnak a kialakult csoportok. •

Asszociáció: Az asszociációs szabályok feltárásának lényege az, hogy az adatbázisban lévı objektumok között összefüggéseket találjon. Amennyiben létezik ilyen kapcsolat, akkor az adatbányászat segítségével feltárható, és annak erıssége jellemezhetı. E feladatra tipikus alkalmazási példa a fogyasztói-kosár elemzés, mely olyan információt próbál feltárni, hogy ha a vásárló X és Y terméket vásárol, akkor valószínőleg Z terméket is.


47/51


8

ÖSSZEGZÉS A diplomamunkám megírása során igyekeztem átfogó, általános érvényőséggel ismertetni az adattárházak világát, az adattárházakra épülı, adatmenedzselést segítı rendszereket, az adattárházak architektúráját, adatmodellezési koncepciókat, valamint az adattárházaknál alkalmazott intelligens megoldásokat bemutatni. Dolgozatomból remélhetıleg tisztán látszik, hogy az üzleti intelligencia és az adattárház technológiák bevezetése mennyire fontos szerepet játszhat egy vállalat életében. Ez a technológia még most kezd igazán elterjedtté válni, és látható, hogy a jövıben valószínőleg még rengeteget fog fejlıdni. Ma már a legtöbb nagyvállalat egyértelmően látja, hogy szükség van az adattárházak és elemzési módszerek használatára. Az ETL folyamatok egyre jobb megoldásai mellett a lekérdezések gyorsaságát elısegítı minél intelligensebb megoldásokra is figyelmet fordítanak az adattárház-fejlesztı cégek (ilyen lekérdezés-optimalizáló megoldás például az Oracle szoftvere, az Exadata Storage Server, mely egy intelligens adatbázis protokollt biztosít a lekérdezések gyorsításához). A technológia fejlıdésével a vállalatok az adattárházak adattároló kapacitásának növekedése mellett is egyre kényelmesebben elemezhetik adataikat és egyre több hasznos információhoz juthatnak hozzá. Ezen felül az adattárház technológiák alkalmazása és intelligens megoldások integrálása nem csak a megkönnyítik a projektvezetık és vállaltirányítók döntéshozatalát, de felpezsdítik a konkurens cégekkel folytatott piaci versenyt is.


48/51


9

KÖSZÖNETNYILVÁNÍTÁS Köszönetet mondok témavezetı tanáromnak, Dr. Juhász Istvánnak a diplomamunkámhoz nyújtott segítségért.


49/51


10 ÁBRAJEGYZÉK 3.1. ábra - Adattárház komponensek ................................................................................... 11 4.1. ábra - Alap architektúra ................................................................................................ 15 4.2. ábra - Architektúra egy összesítési területtel................................................................ 16 4.3. ábra - Architektúra egy összesítési területtel és adatpiacokkal .................................... 16 5.1. ábra – Adatkocka .......................................................................................................... 20 5.2. ábra - A cím dimenzió felgörgetése (városról megyére) .............................................. 21 5.3. ábra - Lefúrás az idı dimenzión (negyedévrıl hónapra).............................................. 22 5.4. ábra - Szeletelés és kockázás ........................................................................................ 22 5.5. ábra - Példa dimenziótábla ........................................................................................... 25 5.6. ábra - Példa ténytábla ................................................................................................... 26 5.7 ábra - Tény- és dimenziótáblák a többdimenziós modellben ........................................ 28 7.1. ábra - IDW architektúra 1............................................................................................. 36 7.2. ábra - IDW architektúra 2............................................................................................. 37 7.3. ábra - KDD folyamat .................................................................................................... 41


50/51


11 IRODALOMJEGYZÉK [1] Barry Devlin: Data Warehouse from Architecture to Implementation. Addison Wesley Longman, 1997. [2] Ralph Kimball: The Data Warehouse lifecycle toolkit, 2nd edition. Wiley Computer Puplishing, 2008. [3] Ralph Kimball, Margy Ross: The Data Warehouse Toolkit, 2nd edition. Wiley Computer Publishing, 2002. [4] Ralph Kimball, Joe Caserta: The Data Warehouse ETL Toolkit. Wiley Computer Publishing, 2004 [5] Jiawei Han, Micheline Kamber: Adatbányászat – koncepciók és technikák. Panem kiadó, 2004. [6] Hsiao-Fan Wang: Intelligent Data Analysis. Information Science Reference Publishing, 2008. [7] R. Stackowiak, J. Rayman, R. Greenwald: Oracle Data Warehousing and Business Intelligence Solutions. Wiley Computer Publishing, 2007. [8] http://download.oracle.com/docs/cd/B10501_01/server.920/a96520/toc.htm [9] http://www.cs.sfu.ca/CC/459/han/papers/chaudhuri97.pdf [10] http://www2.sas.com/proceedings/sugi27/p170-27.pdf


51/51

Intelligens Adattárházak

Recommend Documents