https://vik.wiki/index.php?action=history&feed=atom&title=Adatt%C3%A1rh%C3%A1z_m%C3%B3dszertanokAdattárház módszertanok - Laptörténet2026-05-16T18:01:12ZAz oldal laptörténete a wikibenMediaWiki 1.43.8https://vik.wiki/index.php?title=Adatt%C3%A1rh%C3%A1z_m%C3%B3dszertanok&diff=139184&oldid=prevUnknown user: Új oldal, tartalma: „{{GlobalTemplate|Infoszak|InfoMenDWModszert}} __TOC__ ==Üzleti életciklus== Az egyes módszerek közös pontja, hogy iteratívan képzeli el a DW kialakítását,…”2012-10-21T20:34:53Z<p>Új oldal, tartalma: „{{GlobalTemplate|Infoszak|InfoMenDWModszert}} __TOC__ ==Üzleti életciklus== Az egyes módszerek közös pontja, hogy iteratívan képzeli el a DW kialakítását,…”</p>
<p><b>Új lap</b></p><div>{{GlobalTemplate|Infoszak|InfoMenDWModszert}}<br />
<br />
<br />
__TOC__<br />
<br />
==Üzleti életciklus==<br />
<br />
Az egyes módszerek közös pontja, hogy iteratívan képzeli el a DW kialakítását, fázisokat definiálnak. <br />
<br />
* [http://www.hadden-kelly.com/methodology.html Hadden-Kelly]: Preparing - Planning - Building - Operating <br />
* HP Open Warehouse<br />
* Oracle Warehouse Methodology<br />
* [http://www.kimballgroup.com/ Ralph Kimball]<br />
* [http://www.sas.com/ SAS]<br />
<br />
==Data Warehouse readiness Litmus test==<br />
<br />
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. {{InLineFileLink|Infoszak|InfoMenDWModszert|Lolopop.Readiness.Test.pdf|Lolopop.Readiness.Test.pdf}}<br />
<br />
* Do You Have A Strong Business Management Sponsor?<br />
* Is There A Compelling Business Motivation?<br />
* Is There A Strong Information Systems (IT)/Business Partnership?<br />
* What Is Your Current Analytic Culture?<br />
* What Is The Feasibility For Undertaking A Data Warehouse Project?<br />
<br />
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 rossz eredmény, de érdemes odafigyelni a 3-nál kisebb 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örnyezetbe.<br />
<br />
A teszt iránymutatásnak jó, a DW bevezethetőségét nem feltétlenül ez alapján érdemes eldönteni.<br />
<br />
==Pénzügyi megfontolások==<br />
<br />
<br />
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 piacra jutás, forgalomnövekedés a jobb termék pozicionálás eredményeképp) és költségcsökkenést érhetünk el. <br />
<br />
==A projekt résztvevői==<br />
<br />
Heterogén csapat kialakítása a feladat:<br />
* projektmanager<br />
* főmérnök - architect (a technika összeálljon egy egésszé)<br />
* üzleti analitikus (a folyamatokat átlássa)<br />
* biztonság tervező (kritikus, üzleti titkok kezelése)<br />
* adatgondnok (naprakész infó az adatok jelentéséről, elérhetőségéről... -> humán kiegészítésű metaadattár)<br />
* (Adatgondnok == [http://en.wikipedia.org/wiki/Data_steward data steward]?)<br />
* adatmodellező (adatmodellezés a szemantikus modellektől kezdve az adatbázis adatmodellig, normalizálási, integritási és hatékonysági elemek meghatározása)<br />
* betöltés tervező (ismerik adatforrások logikai és fizikai felépítését, betöltés során felmerülő konvertálási, adattisztítási feladatok megoldása)<br />
* front-end tervező (végfelhasználók kiszolgálása)<br />
* adatminőség biztosító ("rubish in - rubish out")<br />
* oktatók (belső fejlesztő gárda szakmai képzése, a felhasználók oktatása)<br />
* stb.<br />
<br />
==Követelmények összegyűjtése==<br />
<br />
===alapelvek===<br />
<br />
Indirekt kérdezzünk rá a dolgokra, segíteni kell a 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).<br />
<br />
===interjúk lebonyolítása===<br />
<br />
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).<br />
<br />
===szokásos kérdések egy interjún===<br />
<br />
* az adott vezető szervezetének mi a helye a cégben, a vezetőnek mi a felelőssége?<br />
* az adott vezető szervezetének mi az üzleti célja?<br />
* hogyan és milyen gyakran szokták mérni az eredményességet személyre, szervezetre vonatkozóan?<br />
* milyen problémáik vannak?<br />
* a tapasztalataik szerint mi akadályozza legfőképpen a céljaik elérésében?<br />
* milyen rutinszerű analíziseket használnak ténylegesen?<br />
* szoktak-e kérni ad-hoc elemzéseket?<br />
* milyen akadályai vannak, hogy a megfelelő információkhoz hozzájussanak?<br />
* milyen régi infókhoz szoktak hozzányúlni, minek van értelme, mennyire karakterisztikus a jövőre?<br />
* milyen üzleti lehetőségekhez fogna, ha megfelelő infók állnának a rendelkezésre?<br />
<br />
===Sikerkritériumok meghatározása===<br />
<br />
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?<br />
<br />
* teljesítési, megvalósítási mérték: x db különböző lekérdezést lehet beadni a rendszernek<br />
* használati mérték: x ember használja<br />
* szolgálati szint, rendelkezésre állás: napi x órában elérhető<br />
* adatminőség: x% adathiba bizonyos adatmennyiségen<br />
<br />
===konszolidálás, priorizálás, konszenzus kialakítása===<br />
<br />
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<br />
* érintett pénzvolumen<br />
* 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).<br />
* mennyire komplex, mekkora adatmennyiség<br />
<br />
===DW architektúra===<br />
nem feltétlenül formalizált<br />
<br />
Feladatok:<br />
* front-end manager (Mc Donald's-ban a pultos, eladó): kapcsolattartás a végfelhasználókkal<br />
* back-end: a termékek előállítása, átmeneti tárolóba töltése<br />
<br />
==Dimenziós modellezés==<br />
<br />
===előnyök===<br />
<br />
* lekérdezés könnyen optimalizálható<br />
* a modell bővítése egyszerű, nem kell átstrukturálni az adatbázist, ha új adatot veszünk fel<br />
* laikusok által is könnyen lekérdezhető<br />
* a lekérdezést nem kell megváltoztatni, ha az adattárház bővül<br />
<br />
===négylépéses dimenziós modellezés===<br />
<br />
* 1. '''üzleti folyamat azonosítása'''<br />
<br />Példák: <br />
** szolgáltatás használata<br />
** hitelek igénylése, felvétele<br />
** bevéltelek alakulása<br />
** kinnlévőségek<br />
** rendelések<br />
** személyzeti ügyek<br />
** számlázás<br />
** javítások és reklamációk<br />
* 2. '''tényadat granularitásának megválasztása''' - milyen részletes adatok tárolását támogatjuk<br />
** túl részletes (sok adat, nagy diszk-, CPU-igény)<br />
** nem elég részletes (elemzéseket akadályozhat meg)<br />
** le kell írni a tényrekord pontos jelentését<br />
* 3. '''dimenziók azonosítása''' - mi alapján akarunk rendezni, lekérdezni, csoportosítani a tényadatokat?<br />
** sok és részletes dimenzió => változatosabb analízisek, sok erőforrásigény<br />
** az igényeket szembesíteni kell az üzleti lehetőségekkel<br />
* 4. '''tények azonosítása''' - általában numerikusak és folytonos értékkészletűek pl.: eladott áru darabszáma, eladási ár forintban, átlagos kisker ár<br />
<br />
===dimenziós tervezési elvek===<br />
<br />
Ismerjük meg és értsük pontosan a kezelt adatokat.<br />
<br />
====ténytáblák====<br />
<br />
A '''ténytáblában''' legyenek rövid rekordok (lehető legkisebb granularitás), kódokkal teli, rendelkezzen azonosítókkal. <br />
* ''additív'' tényadatok: általában összegezhető adatokat kell választani<br />
* ''nem additív'' tényadatok: egyáltalán nem összegezhetőek, egyetlen dimenzió mentén sem<br />
* ''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).<br />
<br />
'''Ténynélküli ténytáblák''' <br />
Előfordulhat, hogy a ténytáblának csak egy tény-oszlopa lenne, amiben csak egy 1-es van, pl. egy sor a ténytáblában azt jelenti, hogy a diák látogatott egy órát, de ehhez nem tartozik mennyiség, hiszen csak egyszer lehet egy órát meglátogatni, a külső kulcs mutatja, h melyik órát. Ilyenkor felesleges felvenni ezt a tény-oszlopot.<br><br />
Ezek valójában klasszikus több-több kapcsolatok, pl.: <br />
* óralátogatási szokás ( ==időpont, tárgy, terem, diák, tanár== ) vagy <br />
* egy termék-kampány lefedettségi táblái ( ==eladás, termék, bolt, idő, kampányjellemzők== )<br><br />
Ez utóbbi viszont nem ad választ arra, hogy mit nem adtak el abból, amiről a kampány szólt. Hogy ezt az információt kinyerhessük, szükségünk van egy másik ténytáblára, melynek rekordjai a kampányban való részvételt jelentik.<br />
<br />
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. <br />
<br />
Pl. tárolhatjuk egy szerződésről<br />
* a megkötésének és felbontásának idejét külön sorokban (esemény): betöltésre optimalizált, lassabb lekérdezni<br />
* a szerződés fennállását egy sorban (állapot): lekérdezésre optimalizált, lassabb betölteni<br />
<br />
====dimenziós táblák====<br />
<br />
A '''dimenziós táblákban''' foglalnak helyet a leíró attribútumok (a rekordok hossza kevésbé kritikus, akár igen sok mezője is lehet). Ha lehet, konform dimenziókat használjunk, azaz több ténytáblához alkalmazzuk ugyanazt a dimenziós táblát, ha ezt a típusok lehetővé teszik. (Pl több tánytáblához egy idő dimenziós táblát.) <br />
A felesleges dimenziók teljesítményveszteséget eredményeznek. A dimenziós adatok nem feltétlenül nyerhetők ki valamely forrásrendszerből. Az ==idő, termék, hely és ügyfél== a leggyakoribb dimenziók.<br />
<br />
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.<br />
<br />
* '''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 (Számlázás ideje, fizetés ideje, szállítás ideje)<br />
* '''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 dokumentumunk 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.<br />
* '''Junk dimenziók''' - egyes elemek 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: flag-ek, szöveges leírók.<br />
* '''idővel változó dimenziók''' SCD (slowly changeing dimensions) kezelésére három módszert használhatunk:<br />
** ''felülírás'' : egyszerűen megvalósítható, de adatvesztéssel jár.<br />
** ''old mező létrehozása'' : szintén gyorsan implementálható, de korlátozott history. <br />
** ''új dimenziós rekord beillesztése'' : teljes history építhető fel vele, nehézkesebb keresési műveletek.<br />
<br />
==Összegzések tervezése==<br />
Összegzésnek nevezzük azokat az előre kiszámított speciális lekérdezéseket, melyekben 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. Egyszerre akár 1000 összegzés is létezhet. Ehhez azonban mind a fizikai adatszervezést, mind az összegzéseket terveznünk kell, illetve a lekérdezést a végletekig optimalizálnunk.<br />
<br />
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.<br />
<br />
Az összegzések méretezésekor célszerű legalább 10:1 arányú rekordszámcsökkenést eszközölni. Ennek mérőszámai a dimenzió '''kompressziója''' és az '''együttes előfordulási gyakoriság''' (density). Az előző példánál maradva<br />
* ha egy márkához átlagosan 50 termék tartozik, akkor a márkán definiált összegzés 50x kompresszióval bír<br />
* ==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<br />
* ==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<br />
<br />
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érdezé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.<br />
<br />
-- [[AdamO|adamo]] - 2007.11.26.<br />
<br />
-- [[MatyasZsoltLevente|habib]] - 2008.01.08. - javítgatta, (belekavart :))<br />
<br />
<br />
<br />
[[Category:Infoszak]]</div>Unknown user