Információ menedzsment hallgatói szemmel 0.8. verzió* DSS - Decision Support System... 2 Bevezető... 2 DSS... 2 OLTP vs OLAP... 3 Denormalizált Adatstruktúra... 4 OLAP... 7 Módszerek az adattárház adatainak hasznosítására... 8 Metaadat kezelés... 9 Történet... 11 1960-as évek... 11 1970-es évek... 11 1980-as évek... 11 1990-es évek... 11 2000 után... 11 Adattárházak... 12 Definició... 12 Architektúrák... 12 Fejlődése... 13 üzemeltetési arhitektúra... 14 Relációs lekérdezések optimalizálása... 15 Heurisztikus, szabály alapú optimalizálás... 15 Költség alapú optimalizálás... 16 Lekérdezés optimalizálás csillagsémákon... 19 Adattárház módszertanok... 22 Üzleti életciklus... 22 Lakmusz teszt... 22 Pénzügyi megfontolások... 22 A projekt résztvevői... 23 Követelmények összegyűjtése... 23 Dimenziós modellezés... 24 Összegzések tervezése... 26 *hiányzó részek: Reklámkampány analízis Állomásoztató terület tervezése Közel valósidejű dw
DSS - Decision Support System Bevezető DSS Az eddig megismert adatbázisok szerepe világ egy hű leképzése (jegynyilvántartás, könyvtár, raktárkezelés), adminisztrálása volt. Az aktuális állapotot tükrözte egy rendszerben, A lekérdezési műveletek mellett gyakori UPDATE műveletek jellemezték. Az új szemlélet szerint a rendszer korábbi állapotaiból, összegyűjtött adataiból a jövőbeli trendekre szeretnénk következtetni. Célja a változásokat jellemezni. Többségében lekérdező műveletek használatával. Az így kialakuló alkalmazásokat szokás döntés támogató rendszereknek (DSS - Decision Support System) is nevezni. a lekérdezések optimalizálása szükséges. Szemben az eddig látott alkalmazásokkal, melyek az operatív tevékenységben résztvevő dolgozók számára készült adatokkal dolgoztak, a DSS rendszerek vállalat vezetői számára készültek. A vállalat működését befolyásoló stratégiai kérdések megoldására alkalmazzák. Kezdetben a rossz hatásfokú jelentéskezelő rendszerek - management information systems - MIS / EIS jellemezték az születő iparágat. Később adattárházakon alapuló döntéstámogatás váltotta őket. A DSS rendszerek legfontosabb jellemzői: az egyszerű adatolvasás/írás helyett az adatok analitikus, statisztikus elemzése dominál. Adatelemző komponensekkel egészülnek ki a normál adatkezelő utasítások. célja az adatok mögött húzódó trendek felderítése, meghatározni az eseméynek válozási irányát és jellegét nem tartalmaznak adatmódosítási elemeket a megfelelő minőségű, megbízható előrejelzésekhez nagy adatmennyiséget igényelnek. nagyobb szerepet kap az időbleiség (egy adatelem mely időponbeli aktuális állapotnak felel meg). Felhasználóbarát, emberközeli kezelő felület lekérdezések terén rugalmasság: a problémákat sok oldalról, többféle megközelítésben meg leeht vizsgálni.
Az újfajta igények az adatkezeléstől gyorsabbb nagytömegű adatkezelést igényelnek. Analaitikus műveleteket támogató, hosszabb és nagyobb adatmennyiségeket érintő tranzakciók kezelése. OLTP vs OLAP A hagyományos adatkezlést online tranzakció orientált rendszernek (On Line Transaction Processing - OLTP) nevezik a másik módszert online analitikus elemzés orientált adatkezelésnek (On Line Analitical Processing - OLAP). Az OLTP rendszerekben a működés során több konkurensen futó rövid életű transzakció található meg. Az OLAP rendsezreknél viszont lényegesen kevesebb a párhuzamosan futó lekérdzés, de azok jóval hosszbb időt igényelnek, hiszen mögöttük hatalmas adatmennyiésg áll. Az adatok jellegében is különbséget találunk: az OLTP rendszereknél az aktuális állapotról tárolnak információt homogén modell szerint, hiszen javarészt egyetlen adatforrásra építenek. Az OLAP ezzel szemben nem a konzisztens állapotleírással foglalkozik, hanem minél több információt kíván kisajtolni a rendszerből, ennek érdekében szélesebb információ forrást von be az értékelésbe. Külön energiát szükséges fordítani a heterogén adatok összedolgozására. összehasonlítás OSS - OLTP DSS - OLAP funkció adatfeldolgozás döntéstámogatás szállítandó üzleti műveletek, funkcionlitás információ felhasználás struktúrált, ismétlődő műveletek válaszidő mp órák, napok érintett rekordszám kevés ad-hoc a műveletek fajtája, jellege, intenzitása igen sok lekérdezési profil kevés tábla sok tábla követelmény struktúra szervezés stabil: egy jól ismert folyamathoz ismeretlen: feltáró folyamathoz sok tábla kevés oszlop, normalizált folyamat orientált (tranzakció alapú) kevés tábla sok leíró oszlop, redundáns témaorientált adatok jellege dinamikus statikus frissítés folyamatosan bulk loading, periodikus felhasználók száma nagyszámú, egyidejű hozzáférés jellege rekordokhoz, gyorsan kevesebb, kisebb konkurencia sok rekodoz, összegzésekhez gépfelhasználás stabil nagyon dinamikus rendelkezésre állás kritikus 100% nem kritikus
Denormalizált Adatstruktúra Motivációk vállalati erősforrásgazdálkodási rendszer egyszerűsített ER diagrammja A tapasztalatok szerint a lekérdezésoptimalizálók rossz hatékonysággal műkönek a bonyolult adatstruktúrákon. AZ OLAP igényeket csak körülményesen nehezen lehet vele megvalósítani, a klasszikus elsődleges kulcs-idegen kulcs szerkezettel a több változót érintő aggregációs értékeket vizsgáló kapcsolatok feltárása igen hosszadalmas. Az ipari méretű rendszerekben az egyedtípusok száma több ezer lehet. A végfelhasználó nem képes hatékonyan használni (különösen a vezetők, a managerek). A lekérdezés optimalizáló alkalmazások (cost-based) gyakran tévednek, általános struktúrák esetén katasztrófális hatékonysággal dolgoznak. A struktúra karbantartása (update) igencsak nehézkes, a tranzakció kezelésre van optimalizálva, nem pedig a szükséges lekérdezések támogatására. Dimenziós modellezés A jóval magasabb szintű funkcionális elemek leírására született meg a dimenziós modellezés (DM). Ennek támogatására egy grafikus, funkciójában az ER modellhez hasonló formátumú séma leíró nyelvek jöttek létre, köztük a csillag modell, mely az elkészített leírás alakjáról kapta a nevét.
Elemei a tények, melyek a csillag közepét alkotják: numerikus, additív, folyamatos értékkészletű attributumokkal rendelkezik. Kevés attributum, sok sor. a dimenziók mentén a tényértékek változását kísérjük figyelemmel. Gyakran szöveges, leíró attribútumokkal rendelkezik, sok attribútum és kevesebb rekord. A ténytábla értékei egy többváltozós függvény függvényértékeinek feleltethetők meg. E mellett a dimenziók értékei a független változók értékeivel párosíthatók. Praktikus jelöléssel lássuk az értékesítési folyamathoz tartozó DM-t: A tény kiolvasása a dimenziók együttállása mellett. Alkalmas-e ez a klasszikus struktúra által nyújtott szolgáltatások megvalósítására? általánosan nem egy konkrét kérdéskategóriára lehet hatékonyabb a dimenziós adatmodell de nem is baj a DSS-ben, ha nem támogat minden lekérdezést
Konform dimenziók A ténytáblák a vállalati működés kritikus folyamatait fedik le, melyek ezáltal jól elemezhetőkké válnak. A vállalat vezetése szempontjából átfogó kép kell az összes folyamatról. A dimenziós modellben a ténytáblák csak dimenziókat, a dimenziók csak tényeket kapcsolnak össze. Ha azonban multidimenziós adatmodell képzünk az azonos dimenziók együtt (nemcsak logikailagi, hanem a megvalósítás szempontjából is) közösen kezelehetjük. Az adathalmazok összevonásával jönnek létre az ún. konform dimenziók: a különböző tényekhez tartozó azonos jelentésű dimenziók azonosakra vannak kialakítva (közösek). Ezen keresztül azonban a tényadatok között is kapcsolatot lehet teremteni. adattárház busz CSONK Célja a dimenzióstruktúrák összekapcsolása a konform dimenziók rendszerén keresztül, mégpedig úgy, hogy nincs fizikai kapcsolat kialakítva! Az a konstrukció, ami a konform dimenziók rendszerén keresztül összekapcsolja a különböző dimenziós struktúrákat. rendezett formában (busz) ábrázolás
Implementációs lehetőségek: relációs: tény-tábla o táblák o kulcs o a ténytáblában a tényadatokon kívül annyi idegen kulcs lesz, ahány dimenziója van multidimenziós tömbök + 5. ábra o dimenziók a tengelyeken o cella hordozza a tényadatok értékt o egy tényadat Pédlák: ROLAP (relációs alapokon), MOLAP (multidimenziós alapokon), HOLAP (hibrid). OLAP Aggregátum Előre kiszámított, majd eltárolt lekérdezés, amley a tényadatokat összegi a dimenziókban rejlő hierarchiáknak megfelelően. Az aggregált lekérdezések rengeteg adatot érintenének a sok diszkművelet nagyon lassú működéshez vezetne. A lekérdezések előtt az előreszámítással és ezek tárolásával felgyorsíthatjuk ezt a folyamatot. Kérdés hogy milyen felbontással van szükségünk rájuk (értékesítés termékcsoportokra, hetente, megyénként). Ennek beállítása a betöltéskor szükségeses. Új lekérdezésekkor ezekhez fordulunk, pl. az össes értékesítés egy héten, az aggregátumok közötti összegzés. Def: bizonyos lekérdezések tárolt eredményei, melyek segítségével a lekérdezési teljesítményt futásidőben, virtuálisan meg tudjuk növelni. Az aggregátumot jellegzetesen az egyes dimenziókban található hierarchiák mentén szokták definiálni: egy dimenzióban több hierarchia is lehet. E mellett alkalmazható még az is, hogy az aggregátumokat több dimenzió mentén is elkészítjük. Azonban egy tényhez akár 10 dimenzió is tartozhat, dimenziónként átlagosan 4 hierarchiaszint: igencsak számításigényes... További megfontolások szükségesek a kiszámítandó aggregátumok meghatározására. drill down : ha egyre résztelezettebb felbontást akarunk, a hiearchiában lefele megyünk. Például tudjuk az igazgatósági értékesítési számot, és az érdekel, hogy ezt hogy hozza össze az igazgatóság 3 osztálya. rolling up : aggregáltabb felbontást akarunk, a hiearchiában felfele megyünk. Például az igazgatóság adatai után a vállalati szintre vagyok kíváncsiak. drill through : a konform dimenziókon keresztül egy dimenzióstruktúrában megfogalmazott adathoz hozzá akarunk kapcsolni egy másik dimenzióstruktúrában lévő tényt. Például az értékesítést követően mikor realizálódott a termék után a pénz: egyik tény az értékesítés, a másik a megtérülés.
slice and dice : "forgasd és szeleteld" a dimenziók kiválasztása, elhelyezése (mit, minek a függvényében). Majd bizonyos dimenziók fixálása - szeletelés. Például az adott időpillanatban vagy adott termék kapcsán vizsgálódunk. Módszerek az adattárház adatainak hasznosítására Riport ("canned" report): Rendszeresen elkészített azonos témájú, néhány (50) számérték frissítésével emailben vagy más módon (fileszerver, telefon) eljutatott jelentés. Dinamikussá tehető néhány változó lekérezés esetén kap értéket (pl. idő dimenzió: év-hónap) OLAP analízisek : ROLAP (relációs alapokon), MOLAP (multidimenziós alapokon), HOLAP (hibrid). ad-hoc lekérdezések : nem jellemző a sok elemi adat kezelhetetlensége könnyen padlóra küldheti a rendszert. Adatbányászat Aggregátumnavigáció, metaadat kezelés. Adatbányászat adattiszítás (data cleaning) értékhibák feltárása, csak megbízható információ beengedése, statikus szabályok mellett gyanúsnak tartott értékek esetén figyelmeztetés. Heterogén környezetből gyűjti az adatokat, akár az adatok formátumcseréje árán is. integrálás : adatforrások kiválasztása elérése beolvasása mintavételezés: frissítési folyamat az az aktuális állapot betöltése az eddig meglévőkhöz. transzformálás adatbányászati elemzés dokumentálás Adattárház adatkinyerés tisztítás integrálás transzformáció betöltés aggregálás lekérdezés Megkülönböztetjük a leíró (alapjellemzős meghatározása és a következetető (összefüggések feltárása) adatbányászatot.
Módszerei: csoportos leírás (jellemzők megadása) asszociációs szabálykeresés szabálygenerálás előrejelzés szegmentáció idősorelemzés Eszközök: statisztika fuzzy neurális hálózatok döntési fák ad-hoc módszerek Metaadat kezelés Definíció : Egy másik adatot leíró, meghatározó adat, amely összefoglalja az adat használatára vonatkozó összes tényt. Az adattárház használhatóságát alapvetően meghatározza mind az üzemeltetés mind a lekérdezés szempontjából. Hiszen a sokféle heterogén forrásrendszer adatainak, hasonló, a frissítésekkor változó adatoknak igen gazdag adatstruktúráját kell tudnunk kezelni. A jól struktúrált adatok szerkezete az adatok teljes terjedelméhez képest elhanyagolható. A Közepesen (semi-) strukúrált adatok belső szerkezetét fel lehet ismerni, de a nagysága összemérhető a teljes kezelt adattal. pl.: XML. A nem strukútrált adatok nem jellemezhetők, akármilyen szemanitikával is próbálkozunk. Csoportosítás Funkció szerint: technikai (mezők típusa, hossza, sorrendje, csoportjai, kényszerei) szemantikai, más néven üzleti információs metaadatok (az adat mértékegysége) adminisztrációs az adattárházban zajló folyamatok járulékos adatai (indulási időpont, forrás, végrehajtott transzformációk, végrehajtott lekérdezések, lekérdezések eredménye, lekérdezések jogosultsága) navigációs az elérhető adatok struktúrákba szervezése, majd a végfelhasználó számára ajánlások (elkészült aktivizálható riportok felsorolása, alapstruktúrák, aggregátumok)
Befolyásoltság szerint: aktív : A folyamatok befolyásolási (triggelerési) lehetősége, tipikusan a jól felépített adattárházak tartoznak ebbe a csoportba passzív : Az események leírására szolgálnak, értelem szerűen nem befolyásolják a folyamatokat. Illetékességi hely szerint: back-room front-room Kapcsolódó folyamatok Gyakorlatilag megegyezik a korábbi adatok kezelése során felsoroltakkal. adatkinyerés adminisztráció (aktualizálás, konszolidálás, mentés...) végfelhasználói hozzáférés Lehetőség szerint a centralizált metaadattár és a lekérdező felület javasolt. Szabványosítási folyamat MDC: MDIS EIA: CDIF MS: XML ORACLE: 1999-ig saját, majd 2001-től XML, végül a Object Managment Group által készített Common Warehouse Metamodell (CWM) használja.
Történet 1960-as évek mainframe-ek leporellóra nyomtatták százszámra az oldalakat lassú a további adatfeldolgozás katasztrofális 1970-es évek terminál alapú rendszerek (inputok kijelzőn) 1980-as évek PC alapú rendszerek intelligens terminálok grafikus módon megjelenített adatok rendszerek: EIS (Executes Information System) (ez nem biztos, hogy így van)?! abszolút inkonziszens adatok (ellentmondásosak) kevés historikus adat (a gyenge tárak miatt) bonyolult adatbázissémák. nehéz lekérdezhetőség 1990-es évek megjelennek azok a rendszerek, amelyeket adattárházaknak nevezünk erőfeszítés az adatok egységesítésére, konzisztencia megőrzésére szemantikailag, fizikailag integrálják egyetlen igazság kiolvashatósága bármilyen lekérdezéssel. kliens server modell első megvalósítása trend analízis - > klasszikus predektív analízis internet technológia bevonultatása. döntés támogatási eszközök kiszélesítése, informatikai alapokra helyezése vékony kliensek (vállalati intranet) információ hozzáférés 2000 után internet technológiák benyomulása széleskörű hozzáférés biztosítása Közel valós idejű (real time) döntéstámogatás adat feltöltés egy időben az adatok lekérdezésével. (nem éjszaka van feltöltés).
Adattárházak Definició Adattárház olyan információs rendszer, melyet jellegzetes szervezeti és stratégiai döntés támogatásra használnak. Négy fő tulajdonsága van: subject-oriented : egy helyen jelennek meg az üzleti logikai fogalmak, nem rendszerekben elosztva. Korábban function-oriented-ek voltak integrated : konzisztens kód és adatformátumok time-variant : Az adatok idősorosan vannak tárolva, bármi áron kiszolgálva a múltbéli adatok elemezhetőségét. non-volatile : nincs lehetőség adatmódosításra, csak beolvasási és lekérdezési műveletek adottak. Minden betöltött adatot megőrzünk, még a vélhetően hibás adatok javítására sincs mód. Az UPDATE műveletek kizárását a nagy költségek indokolják. Az adott rekordot érvénytelenné tehető, és helyére betölthetünk egy újat/frissebbet (jelölve az adatok hatályosságát). Architektúrák koncepcionális elvi adat (konzisztencia) milyen módszerekkel front-end (végvelhasználó hogyan használja), back-end (letöltöget) eszközarchitektúra fizikailag milyen eszközök üzemeltetési milyen funkciókat biztonsági biztonság megteremtése Az koncepcionális architektúra tervezés elemei: forrásrendszerek nincs plusz terhelhetőség, max járatban így szedi ki belőle az adatot kinyerés-integrálás úgy kell az adatot kinyerni, hogy a legkisebb terheléssel és módosítással tegyük állomásoztató terület ( Staging Area - SA) A back-end nagy része. Itt zajlik az átadott adatok összekapcsolása, transzformációja, módosítása; legtöbb hozzáadott értelmet ez állítja elő. elemi adattár szakterületi adattár lekérdezésorientált adatstruktúrák tervezése és megvalósítása metaadattár üzemi adattár (operational data store - ODS) o integrált és témaorientált adatok, o nem historikus: csak a jelen helyzet olvasható ki o o aggregált adatok helyett elemieket tárol Célja: megkönnyítse az adatok integrálását, lehetővé tegye a jelen idejű adatok lekérdezését, adatmódosítás végrehajtása több rendszer érintésével (több helyen egyszerre változik az adat) MOM (Message Oriented Middleware) direkt mód megjelenítés támogatás
Fejlődése Összehasonlítási alapok: megvalósítás költsége megvalósíthatóság rugalmasság funkcionalitás adatkonzisztencia illeszkedés a vállalati hierarchiához. Állomások: Nem tervezett döntéstámogatás: Egyszerű (a felmerült igények mentén alakítjuk a felületet) viszont hosszú távon igen drága,hiszan a fizikailag elkülönült front-end-ek káoszt okozhatnak. Rugalmatlan (a forrásrendszerben bekövetkezett változást problémás több helyen lekezelni), inkonzisztens. Szakterületi adattár szemantikai integrálása : egységes vállalati adatomdell lekérdezhetősége és a logikai kapcsolatok felépítése. Jóval több erőfeszítést igényel, illetve új szerepkör: adatgondnok. Csökkenti a forrásrendszerek terhelését. A bemeneti adatok konzisztenciája nem biztosított, ugyanis nincs fizikai adatintegrálás. virtuálisan integrált szakterületi adattárak: funkcionalitás többletet ad a Middleware használata. függő szakterületi adattár: (hub and spoke architektúra) Mind a szemantikai mind a fizikai integritás garantált. Részletes adattárház áll rendelkezésre a beérkező adatok feldolgozása után. Az adatok összekapcsolása megvalósítja, hogyk a különbözőképpen megadott leérdezések azonos eredményt szolgáltatnak. Jól skálázható, kategórikus tiltások. o részletes adattárház - nagykereskedő o stakterületi adattár - kiskereskedő
üzemeltetési arhitektúra adatminőség problematikája o soha ne higyjünk annak, ha a megrendelő azt mondja, hogy jó minőségű az adatforrás o mit tegyünk a rossz adatokkal? * a rekord mögött valami valós cselekmény van * ha nem töltöm be, akkor biztos, hogy csalok * mitől rossz? * valami adat hibás, hiányos, értelmetlen * nem ahhoz a klienshez lehet kapcsolni ütemezés o betöltés, transzformáció... o elegáns megoldás éjszaka betöltés nappali lekérdezés o mi van, ha naponta többször kell adatot átvenni? hogy segít ebben a koncepcionális architektúra? közös diszk-alrendszer külön node végzi a betöltést külön node végzi a kérések kiszolgálását ha alacsonyszinten (tranzakciókezelést és constraintellenőrzést kihagyjuk), akkor sokkal gyorsabb lehet a betöltés bulk loading o kérdés az automatizáltság foka első lépésben a full automatizmus irreális cél legyen benne a potenciál, pl workflowmanagement az üzemeltetés során alakulnak ki a feltételek, amikre a későbbiek során érdemes automatizmust építeni o hogyan menedzseljük az összeg táblákat? o hogyan monitorozzuk a használatot? ki, mit, mikor kérdezett le a dw-ből? mennyire terhelt a rendszert? o o o hardware, operációs rendszer üzemeltetése fejlesztői - teszt - üzemi környezet szeparálva (teszt és üzemi adatokhoz nem szabad, hogy hozzáférjen a fejlesztő: ugyanis a teszt adatoknak valóságosnak kell lenni) fizikailag vagy logikailag szeparálva
Relációs lekérdezések optimalizálása Heurisztikus, szabály alapú optimalizálás Módszer : Reláció algebrai alakból felrajzolt fa optimalizálása. Lekérdezési fa elkészítése során célunk a lehető leggyorsabb alak kiválasztaása: induljunk ki a kanonikus alakból (Descartes, szűrés, projekció). lesüllyesztjük a szelekciókat átrendezzük a leveleket (először a kisebbeket descartes szorozzuk) join operandusok projekció lesüllyesztése Műveletek Fel merül a kérdés, hogy két fa mikor ekvivalens? lásd slideok Használjuk ki a halmazműveletek(únió, metszet) kommutativitását és a join Descartes-szorzat és a halmazműveletek asszociatívitását. Összefoglalva a szabályokat: kopnjunktív szelekciós feltételeket szelekciós feltételek sorozatává bontjuk. szelekciós műveleteket felcseréljük a többi művelettel átrendezzük a leveleket a Descartes szozatokat és a fölüttök lévő szelekciós kapcsolási feltételt egy join műveletté vonjuk össze. projekciós műveletekket leseréljük a többi művelettel.
Költség alapú optimalizálás A relációkról a renelkezésre álló információk alapján kiszámolunk több végrehajtási tervre egy költséget, és az optimálisat kiválasztjuk. Katalógusadatok Ehhez katalógusadatokat tárolunk az egyes relációkról: n_r az r rel-ben található rekordok száma (number) b_r az r rel-et tartalmazó blokkok száma (block) s_r egy rekord mérete (size) f_r mennyi rekord fér egfy blokkba (blocking factor) pl.: ha a rel rekordjai fizikailag együtt vannak tárolva, akkor b_r = [n_r/f_r] (felső egész) V(A, r) hány különböző értéke fordul elő az r rel-ben az A attr-nak SC(A, r) selection cardinality, azon rekordok átlagos száma, amelyek egy kiválasztási feltételt kielégítenek. Pl.: ha A kulcs: SC(A, r)=1 illetve általánosan: SC(A, r) = n_k / V(A, r) f_i fa struktúrájú index esetén (pl B*), pointer kimenetek átlagos száma (elágazis tényező) HT_i az index szintjeinek a száma, Pl.: HT_i = [log f_i (V(A,r))] (alsó egész), illetve hash esetén HT_i = 1 LB_i a levélszintű indexblokkok száma (lowest level index block). Hátrányok a relációk elemszámánal nyilvántartása nem triviális lekérdezni hosszú idő (~100milliós rekordszámnál pl) folyamatos frissités is nagy overhead ezért pl az ORACLE-nél külön, explicit módon kell frissíteni a katalógust (ANALYZE) itt még azt is meg lehet adni, hogy hány %-a alapján analizálja a db-t Költségszámítás Felmerül a kérdés: hogyan határozzuk meg egy reláció költségét: igényelt és felhasznált erőforrások alapján? válaszidő alapján? (az összes rekord vagy az első válasz rekord válaszideje alapján?) kommunikációra fordított idő alapján? (elosztott rendszereknél fontos) A definicó szerint legyen egy reláció költsége a háttértár blokkolvasások és írásak száma a válasz kiíratásának ktg-e nélkül (uis a diszkolvasás ms nagyságrendű, a blokk feldolgozása pedig ennek pl 100-a). Ez az érv kezdi érvényét veszteni, amikor ~100GB-os memóriák is vannak, és lehet az egész db-t memóriában tárolni.
Operációk műveletek költsége SELECT attribútum = alapján A1 - lineáris keresés ktg: E_A1=b_r A2 - bináris keresés o feltételi, hogy a blokkok folyamatosan az A attribútum szerint rendezettek legyenek a diszkeken, illetve, hogy a szelekció feltétele az A attribútumon legyen. o ktg E_A2 = [log2(b_r)] + [SC(A,r)/f_r] -1, ahol az első tag: binárisan megkerünk 1 blokkot, a második tag: több rekord is egyezhet, ezek ennyi rekordban vannak, illetve a harmadik tag: az első blokk megtalálását kétszer számolnánk egyébként. A3 - elsődleges indexszel, kulcsot vizsgálva o ktg: E_A3 = HT_i + 1, ahol az első tag: indexfa végigjárása illetve a második tag: adatblokk beolvasása. A4 - elsődleges indexszel, de ez nem kulcs o ktg E_A4 = HT_i + [SC(A, r)/f_r], ahol első tag: indexfa végigjárása második tag: adatblokkok beolvasása A5 - másodlagos index használatával o ktg: E_A5 = HT_i + SC(A, r), ahol az első tag: indexfa végigjárása illetve a második tag: adatblokkok beolvasása (ui a blokkok nem sorban vannak egymás utáni blokkoban) E_A5 = HT_i + 1 (ha A kulcs). SELECT összehasonlítás alapú szelekció: A<v ha v-t nem ismerjük: n_r/2-t kapunk vissza ha v-t ismerjük, egyenletes eloszlás esetén n_ált = n_r((v-min(a,r))/(max(a,r)-min(a,r))) A6 - elsődleges index használatával o ha a v-t nem ismerjük E_A6 = HT_i + b_r/2 o ha v-t ismerjük E_A6 = HT_i + [c/f_r], ahol c a találati halmaz várható nagysága A7 - másodlagos index E_A7 = HT_i + LB_i/2 + n_r/2, ahol az első tag: végigmegyünk az indexfán, a második tag: az indexfa leveleit olvassuk illetve a harmadik tag: az adatblokkok olvasás. Ez igencsak nem gazdaságos, ugyanis, ha bután, kimerítően keresek, akkor b_r-nyit kell csak olvasni SELECT komplex szelekció Mind a konkunkció és diszjunkció esetén nem bonyolultabb, mint egy szimpla szelekció becslése.
JOIN nested loop join o worst case ktg: n_r*b_s + b_r (ha legalább az egyik belefér a memóriába, akkor a ktg b_r+b_s) block nested loop join o 4 ciklus egymásban (2: 1-1 blokkok mindig felolvasok mind2 relációból + 2: blokkon belül illesztek o worst-case ktg: b_r*b_s+b_r (sok memory: b_r+b_s) indexed nested-loop join o az egyik rel-hez van indexünk o az első alg-ot nézzük, a belső ciklusban az indexelt reláció legyen o ktg: b_r+n_r*c, ahol a c a szelekció ktg-e s-en sorted merge-join o a rel-kat a join feltételben meghatározott attr-ok mentén rendezzük, majd fésüljük hash-join o az egyik rel-t hash-táblán keresztül érjök el, miközben a másik rel-t egy adott rekordjához illeszkedő rekordok keressük egyéb o pl bitmap indexszel, bitmap join Egyéb operációk CSONK Egy kifejezés kiértékelésnek módjai Materializáció: def Egyszerűen implementálható viszont sok háttértár műveletet igényel. Pipelineing: Szimultán kiértékelés, a részegységek az előttük álló elemből kapott eredményekből a sorban következő számára állítanak elő részeredményeket. Nincs szükség a teljes reláció előre kiszámolására. Ezáltal az ideiglenes tárolási igényeket minimalizálja, kicsi memóriaigény. viszont leszűkíti az alkalmazható algoritmusok körét. A kiértékelési terv kiválasztása A terv során válaszolnunk kell a következő kérdésekre: milyen műveleteket kívánunk elvégezni milyen sorrendben milyen algoritmus használatával milyen workflow szerint. Ha minden ekvivalens kifejezést (költség alapú optimalizáció) megvizsgálnanák és minden formát kiértékelnénk (azzal a céllal, hogy a végén az optimálisat válasszuk ki), túl nagy terlhelést jelentene a rendszer számára. Ezért Heurisztikus költség alapú optimalizálást érdemes használni. Mindezt automatikusan vagy manuálisan? Az automata szélesebb ismerettel rendelkezik a
letárolt adatelemekről, gyorsabb a numerikus kiértékeliési mechanizmusa, szisztematikusan értékel, algoritmusa több szakember együttes tudását hordozza, dinamikusan minden műávelet előtt az aktuális feltételeket figyelembe véve értékel. Ezzel szemben az ember szélesebb általánso ismerettel rendelkezik, a probléma szemantikai tartalmát megérti, nagyobb szabadsággal rendelkezik a felhasználható módszerek, eszközök tekintetében illetve jobban fel van készítve a váratlan helyzetek kezelésére. Lekérdezés optimalizálás csillagsémákon Az Oracle 7-es verziójától érhető el, különbözik a korábbi filozófiától, nagyságrendekkel hatékonyabb: lényegében egy illesztés a ténytábla és a dimenziós táblák között. A dimenziós táblák join-jának kiküszöbölése, lehetőség az automatikus felismerésre. Két ismert séma (hópihe,csillag közül a csillagsémákon vizsgáltuk részletesen a lekérdezésoptimalizálást. Hópihe séma A hópihe sémáról megemlítettük, hogy gyenge browsing teljesítménnyel rendelkezik ha növeljük a relációk számát. Itt a dimenziós táblák nem önmagukban állnak, hanem több tábla írja le a különböző hierarchia-szinteket. A gyakorlati tapasztalat azt mutatja, hogy az adattárház hozzáférések 80-90%-a dimenziók megfelelő kezelésével, a hatalmas lekérdezés előkészítésével foglalkozik.
Csillag séma A csillag séma kialakításának feltétlei (Oracle): egyattribútumos bitmap index definiálása a tény valamennyi idegen kulcsára inicializáló paraméter beállítása (STAR_TRANSFORMATION_ENABLED should be set to TRUE) költségalapú optimalizálás használata Bitmap (bittérkép) lehetőleg alacsony kardinalitású attribútumot válassznk (azaz kevés különböző érték forduljon elő) Pl.: Az alkalmazott nemének (férfi-nő) tárolására: definiálunk egy kétoszlopos indexet, az értékeknek megfelelően (annyi oszlop, ahány érték). A táblázat sorai a sorszámnak megfelelően be van indexelve külső kulccsal a relációhoz. mivel alacsonykitöltésű a táblázat, ezért tömöríteni szokták: a töredékére összenyomható bizonyos szelekciók kiértékelését nagyon meg tudja könnyíteni (a bitmap indexek jóval kisebbek, könnyebb vele bánni) bővebben lásd wikipédia.
Csillag transzformáció Az Oracle query optimalizáló modulja végzi el az SQL utasítás átírását, ahol ez hasznos lehet. A művelet két lépésből áll, elsőnek a szükséges sorokat választja ki a tény táblából, ez a bitmap indexelés használata miatt igen hatékény. A második lépésben az így kapott eredményhalmazt JOIN -oljuk a dimenziós táblákkal. Lássunk egy csillag queryt: SELECT ch.channel_class, c.cust_city, t.calendar_quarter_desc, SUM(s.amount_sold) sales_amount FROM sales s, times t, customers c, channels ch WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id AND s.channel_id = ch.channel_id AND c.cust_state_province = 'CA' AND ch.channel_desc in ('Internet','Catalog') AND t.calendar_quarter_desc IN ('1999-Q1','1999-Q2') GROUP BY ch.channel_class, c.cust_city, t.calendar_quarter_desc; Az első transzformációs lépés után a három bitmap (time_id, cust_id, channel_id) index felismerése után AND operátorral kötjük össze: SELECT... FROM sales WHERE time_id IN (SELECT time_id FROM times WHERE calendar_quarter_desc IN('1999-Q1','1999-Q2')) AND cust_id IN (SELECT cust_id FROM customers WHERE cust_state_province='ca') AND channel_id IN (SELECT channel_id FROM channels WHERE channel_desc IN('Internet','Catalog')); Az így kapott eredményhalmazon végül a dimenziók mentén JOIN művelet következik. Ennek hatékonyságát növeli, hogy a bitmapnak köszönhetően effektíve egyetlen JOIN művelet elegendő a dimenziónkénti JOIN -ok helyett. Megállapíthatjuk, hogy a csillagtranszformáció elég jól működik, ha a WHERE predikátum kellően szelektív a tényrekordra, viszont ha sok tényrekord értintett az eredmény előállításában, akkor "full table scan" jobb lehet...
Adattárház módszertanok Üzleti életciklus Az egyes módszerek közös pontja, hogy iteratívan képzeli el a DW kialakítását, fázisokat definiálnak. Hadden-Kelly: Preparing - Planning - Building - Operating HP Open Warehouse Oracle Warehouse Methodology Ralph Kimball SAS Lakmusz teszt Nagy adattárház gyakorlattal rendelkező szakértők állították össze, választ ad arra a kérdésre, hogy adott helyzetben, adott cégnek van-e szüksége DW használatára. Lolopop.Readiness.Test.pdf Do You Have A Strong Business Management Sponsor? Is There A Compelling Business Motivation? Is There A Strong Information Systems (IT)/Business Partnership? What Is Your Current Analytic Culture? What Is The Feasibility For Undertaking A Data Warehouse Project? A kérdéscsoprtok súlya: 60-15-5-5-15, 1-5-ös skála szerint kell osztályozni. A DW bevezetése célszerű, ha négynél nagyobb, három és négy között: nem rossze eredmény, de érdemes odafigyelni a 3-nál kisebbes tételekre. Kettő és három közti érték esetén határeset, érdemes a céget fejleszteni olyan irányba, hogy jobb választ lehessen adni ezekre a kérdésekre. Kérdéses, hogy ez megéri-e. Kettőnél kisebb átlag elérése esetén egyáltalán nem ajánlott DW bevezetése a vizsgált környzetbe. A teszt iránymutatásnak jó, a DW bevezethetőségét nem feltétlenül ez alapján érdemes eldönteni. Pénzügyi megfontolások A ROI (Return of Investment) határoz meg mindent. Költségek közt számolni kell a SW/HW vásárlásokkal, belső fejlesztésekkel, külső erőforrásokat veszünk igénybe, támogatással (support) és a növekedéssel (üzleti folyamatok optimalizálása, átalakítása). Ezek mennyiség és eloszlása igen jó becsülhető. Haszonként ezért cserébe bevételnövekedést (gyorsabb piacrajutás, forgalomnövekedés a jobb termék pozicionálás eredményeképp) és költségcsökkenést érhetünk el.
A projekt résztvevői Heterogén csapat kialakítása a feladat: PROJEKT MANAGER főmérnök - architect (a technika összeálljon egy egésszé) üzleti analitikus (a folyamatokat átlássa) biztonság tervező (kritikus, üzleti titkok kezelése) adatgondnok (naprakész infó az adatok jelentéséről, elérhetőségéről... -> humánkiegészítésű metaadattár) adatmodellező betöltés tervező front-end tervező (végfelhasználók kiszolgálása) adatminőségbiztosító ("rubish in - rubish out") stb. Követelmények összegyűjtése alapelvek Indirekt kérdezzünk rá a dolgokra, segíteni kell aa stratégiai kezdeményezések felismerését. Meg kell határozni sikerességi mutatókat. Azokat a legfontosabb üzleti folyamatokat kell kiválasztani, melyeknek javítása jelentős kihatással jár (például a legtöbb pénzt mozgató folyamatok). interjúk lebonyolítása Az interjúkészítőnek beszélgető partnernek kell lenni: legyen tapaszalt és a tárgyterülettel kellően tisztában. Ugyanakkor az üzlethez kell érteni, nem a technológiához. Ismerje hogy milyen módszerrel állhat neki, milyen kérdéseket érdemes feltennie, milyen sorrendben. Az ötletelésnek nincs helye (drága a partner ideje...). Kiket kérdezzünk meg? A legfelsőbb vezetőket (stratégiai kérdésekben), üzleti kulcsszereplőket (a folyamatokról), a középvezetőket (ők a földön járnak...), az IT részleget (a környezet előkészítettsége rajtuk áll), illetve végül, akiket muszáj megkérdezni politikai okokból (megéri, különben kerékkötője lesz a projektnek). szokásos kérdések egy interjún az adott vezető szervezetének mi a helye a cégben, a vezetőnek mi a felelőssége? az adott vezető szervezetének mi az üzleti célja? hogyan és milyen gyakran szokták mérni az eredményességet személyre, szervezetre vonatkozóan? milyen problémáik vannak? a tapasztalataik szerint mi akadályozza legfőképpen a céljaik elérésében? milyen rutinszerű analíziseket használnak ténylegesen? szoktak-e kérni adhoc elemzéseket? milyen akadályai vannak, hogy a megfelelő információkhoz hozzájussanak? milyen régi infókhoz szoktak hozzányúlni, minek van értelme, mennyire karakterisztikus a jövőre? milyen üzleti lehetőségekhez fogna, ha megfelelő infók állnának a rendelkezésre?
Sikerkritériumok meghatározása Az adattárház folyamatosan fejlesztendő rendszer ("egy adattárház addig él, amíg változtatnak rajta"), ugyanis a környezet is folyamatosan változik. A folyamatos változás miatt a kezdeti elképzelés változhat. Bizonyos analízistípusokat le tud-e szállítani, célszerű ellenőrizni, hogy adott idő alatt lefut-e az analízis? Mennyi megfelelően transzformált adat áll a rendelkezésre? Ténylegesen hányan használják a rendszert? konszolidálás, priorizálás, konszenzus kialakítása Az igényeket érdemes csoportosítani és prioritásokat felállítani. Mit, mi mentén akarunk elemezni. A prioritás meghatározásának szempontjai. érintett pénzvolumen milyen adatok, milyen rendszerekből szükségesek (a rendszerek legyenek jól dokumentáltak illetve a dokumentáció legyen konzisztens a valósággal). mennyire komplex, mekkora adatmennyiség Dimenziós modellezés előnyök lekérdezés könnyen optimalizálható a modell bővítése egyszerű, nem kell átstruktúrálni az adatbázist, ha új adatot veszünk fel laikusok által is könnyen lekérdezhető a lekérdezést nem kell megváltoztatni, ha az adattárház bővül négylépéses dimenziós modellezés 1. üzleti folyamat azonosítása o szolgáltatás használata o hitelek igénylése, felvétele o bevéltelek alakulása o kinnlévőségek o rendelések o személyzeti ügyek o számlázás o javítások és reklamációk 2. tényadat granularitásának megválasztása - milyen részletes adatok tárolását támogatjuk o túl részletes (sok adat, nagy diszk-, CPU-igény) o nem elég részletes (elemzéseket akadályozhat meg) o le kell írni a tényrekord pontos jelentését 3. dimenziók azonosítása - mi alapján akarunk rendezni, lekérdezni, csoportosítani a tényadatokat? o sok és részletes dimenzió => változatosabb analízisek, sok erőforrásigény o az igényeket szembesíteni kell az üzleti lehetőségekkel 4. tények azonosítása - általában numerikusak és folyotonos értékkészletűek pl.: eladott áru darabszáma, eladási ár forintban, átlagos kisker ár
dimenziós tervezési elvek Ismerjük meg és értsük pontosan a kezelt adatokat. ténytáblák A ténytáblában legyenek rövid rekordok (lehető legkisebb granularitás), kódokkal teli, rendelkezzen azonosítókkal. additív tényadatok: általában összegezhető adatokat kell választani nem additív tényadatok: egyáltalán nem összegezhetőek, egyetlen dimenzió mentén sem szemi-additív tényadatok: minden dimenzió szerint összegezhető, kivéve az időt. (általánosabban: egyes dimenziók szerint összegezhető, mások szerint nem). Ténynélküli ténytáblák valójában klasszikus több-több kapcsolatok, pl. óralátogatási szokás ( időpont, tárgy, terem, diák, tanár ) vagy egy termék-kampány lefedettségi táblái ( eladás, termék, bolt, idő, kampányjellemzők ) Nem ad választ arra, hogy mit nem adtak el abból, amiről a kampány szólt. Legyen egy másik ténytábla rekordja, mely a kampányban való résztvételt jelenti. Az esemény-tények egyetlen időponthoz köthetőek, az állapot tény viszont két időponthoz (kezdet+vég). Itt azonban új tényrekord beszúrása egy másik lezárásával jár, ez egyrészt alacsonyabb hatékonyságú másrészt valószínűsíthető az információveszteség. Ugyanakkor egymásba átalakíthatók. dimenziós táblák A dimenziós táblákban foglalnak helyet a leíró attribútumok (a rekordok hossza kevéss kritikus, akár igen nagyszámú is lehet). Konform dimenziókat használjunk. A felesleges dimenziók teljesítményveszteséget eredményznek. A dimenziós adatok nem feltétlenül nyerhetők ki valamely forrásrendszerből. Általában az idő, termék, hely, ügyfél a leggyakoribb dimenzió. Minden dimenzió rendelkezzen egy surrogate kulccsal, mely anonym, kiegészítő, jelentés nélküli, mesterséges. A surrogate kulcs használatával elég jó méretcsökkentést tudunk elérni a ténytáblákban. A forrásrendszeri kulcs változásaitól függetlenek lesz a rendszerünk, sőt az entitások időbeli változásait is le tudjuk így írni. Hátránya ugyanakkor, hogy a tény és dimenziós rekordok újrakulcsolával jelentős betöltési overheadet kapunk.
Role-playing dimenziók többféle jelentést is hordozhatnak a tényadathoz kapcsolódóan, például egyetlen fizikai idődimenzió több kulccsal kapcsolódhat a tényrekordhoz Degenerált dimenziók olyan leíró (rövid dimenziós jellegű) adatok, melyeket a ténytáblában helyezünk el különösebben kapcsolódó dimenzió nélkül. Például egy dokumentunk egyedi sorszáma, számlaszám. Velük a forrásrendszerben könnyen lehet azonosítani valamit, így egyedi megfontolásból kerülnek be. Junk dimenziók nem mindig szervezhetők dimenziókba egy vagy néhány jelentés nélküli dimenziót alkotó elemeket nevezzük így, melyeket a ténytáblában nem célszerű elhelyezni: flagek, szöveges leírók. idővel változó dimenziók SCD (slowly changeing dimensions) kezelésére három módszert használhatunk: o felülírás : egyszerűen megvalósítható, de adatvesztéssel jár. o o old mező létrehozása : szintén gyorsan implementálható, de korlátozott history. új dimenziós rekord beillesztése : teljes history építhető fel vele, nehézkesebb keresési műveletek. Összegzések tervezése Összegzésnek nevezzük azokat az előre kiszámított speciális lekérdezéseket, mleyekben a ténytábla tényadatait összegezzük bizonyos feltételek mentén. Azaz a dimenziókban lévő hierarchiákat összenyomjuk és a tényadatokat ennek megfelelően összegezzük. Ezáltal elérhetjük a meglévő teljesítményi korlátok betartását. Garantálnunk kell akár 1000-es nagyságrendű egyidejűleg futó összegzést is. Ehhez azonban minda fizikai adatszervezést, mind az összegzéseket terveznünk kell, illetve a lekérdezést a végletegik optimalizálnunk. Az összegzéseket új ténytáblákban ildomos tárolni, ehhez azonban új dimenziós táblák is kellenek (+ a hozzájuk tartozó surrogate kulcsok). Az új ténytáblák és dimenziós táblák (granularitás csökkentésével) szerkezetének kialakításakor a már meglévőkből is képezhetjük. Pédldául termékek helyett márkákra aggregálunk. Ezáltal egy új márka kulcs jön létre. Az összegzések méretezésekor célszerű legalább 10:1 arányú rekorszámcsökkenést eszközölni. Ennek mérőszámai a dimenzió kompresziója és az együttes előfordulási gyakoriság (density). Az előző példánál maradva ha egy márkához átlagosan 50 termék tartozik, akkor a márkán definiált összegzés 50x komresszióval bír termék, bolt, nap előfordulási gyakoriság: egy adott boltban, azon a meghatározott napon a termékek 10%át adták el átlagosan márka, bolt, nap előfordulási gyakoriság: egy adott boltban, azon a meghatározott napon a márkák 50%át adták el átlagosan Az összegzések közti navigációt egy külön rétegnek kell kiszolgálnia, mely meghatározza, hogy melyik a legalkalmasabb összegzés a felhasználói lekérdzeés kiszolgálására, ezáltal növelve a rendszer teljesítőképességét és kényelmes használhatóságát. Igyekezni kell kerülni a túl sok összegzés definiálását, hiszen nem mindegyik összegzés fogja jelentősen csökkenteni a lekérdezett sorok számát. Ennek kiszámítása futás-idejű feladat.