Információ menedzsment eladások I. rész: Döntéstámogatás Gajdos Sándor, TMIT 2008. sz
Inmon adattárház definíciója
Üzleti intelligencia (BI) Új definíció (EPICOR, 2005): The art of science of knowing what the heck is going on with your business as it is happening, having the facts to understand it and support it, and having the ability to quickly do something about it.
A szükségletek hierarchiája Avagy: mi mködteti az embereket (Maslow) És mi mködteti a vállalatokat? A vállalatok rengeteg energiát ölnek abba, hogy fokozzák alkalmazottaik lelkesedését. Ez igazán szép tlük, de nézzünk szembe a tényekkel - dolgozni nem jó. Ha az emberek annyira szeretnének dolgozni, ingyen is csinálnák. Azért kell megfizetni az emberek munkáját, mert a munka messze nem tartozik az elképzelhet legkellemesebb idtöltések közé. Az ésszer vállalat tudja, hogy az alkalmazottak akkor lelkesednek a legjobban a munkájukért, ha segítünk nekik, hogy minél hamarabb abbahagyhassák azt. Scott Adams: Dilbert elv. SHL Hungary Kft. 2001
A DW üzleti életciklus Hadden-Kelly HP Open Warehouse Oracle Warehouse Methodology Ralph Kimball SAS Általános jellemz a fázisok definiálása és az iteratív szemlélet
Hadden-Kelly
Ralph Kimball módszertana
DW projekt definiálása érdekeltség vagy ellenérdekeltség? felkészültség értékelése
Gyakorlat Litmus teszt
Pénzügyi megfontolások A ROI (Return Of Investment) az Isten Amibe kerül: HW, SW, bels fejlesztési költségek, küls erforrások költsége, support, növekedés költségei. Mennyisége és eloszlása jól becsülhet Ami haszonként várható: bevételnövekedés: pl. gyorsabb piacrajutás vagy forgalomnövekedés a termékek jobb pozícionálása miatt,... költségcsökkenés: költséghatékonyabb marketing kampányok,...
DW projekt résztvevi heterogén csapatra van szükség PM üzleti analitikus architect (fmérnök) adatmodellez betöltés tervez front-end tervez biztonsági tervez data steward (adatgondnok) DBA Oktatók Betöltés programozó Front-end fejleszt üzemeltet (adat-)minségbiztosító, tesztel
Követelmények összegyjtése Alapelvek Elkészületek az interjúkhoz Interjúk lebonyolítása Sikerkritériumok meghatározása Konszolidálás, priorizálás, konszenzus kialakítása
DW architektúrák Rendszertervezési döntés, amely általában nem könnyen változtatható meg Fontosabb szempontok, amiket figyelembe kell venni. Mire jók a különböz architektúrák? Kommunikáció Tervezés Tanulás Hatékonyságnövelés és újrahasznosítás
Architektúrák Koncepcionális architektúra Adat(konzisztencia) architektúra Front-end architektúra és back-end architektúra Eszközarchitektúra (HW, SW) Üzemeltetési architektúra Biztonsági architektúra...
Koncepcionális architektúra fbb elemei forrásrendszerek adatkinyerés-integrálás állomásoztató terület (staging area, SA) elemi adattár (detailed storage, DS) szakterületi adattár (data mart) metaadattár üzemi adattár (operational data store, ODS) megjelenítés támogatás
ODS vs. DW Operatív adattár (ODS) Április 6.: Mike Jones a Market Street 14-be költözött Adattárház (DW) Ügyfél Mike Jones Cím 123 Main Street Hitel AA Utolsó módosítás 1992. jan. 12 Ügyfél Mike Jones Cím 123 Main Street Hitel AA Mettl: 1994. jan. 12. Meddig: jelen Ügyfél Mike Jones Cím 14 Market Street Hitel AA Utolsó módosítás 1994. ápr. 6 Ügyfél Mike Jones Cím 123 Main Street Hitel AA Mettl: 1994. jan. 12 Meddig: 1994. ápr. 5. Ügyfél Mike Jones Cím 14 Market Street Hitel AA Mettl: 1994. ápr. 6. Meddig: jelen
2 (! & ' ( " ) (! * + #,- * + # $ %.!,/! 3! # 0 1 + % %
!! " Szemantikai integrálási folyamat * /! 5 6 6 ( # 6 - * + #,* + # 0 1 + ( ( %.!,/!!! - & 7#.89 : ; - $ * + 4! % %
#! = $! " * /!! M I D D L E W A R E 5 6 6 ( # 6 - * + #,* + # 0 1 + ( ( %.!,/!! - & 7#.89 : ; $ 3! % % # < 8
300 250 200 150 100 50 300 250 200 150 100 50 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 Függ szakterületi adattár (hub-and-spoke architektúra)! 8! & 5 6 6 (. /!! # 6 - * + #,* + # 0 1 + ( ( %.!,/!! - & 7#.89 : ; 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 3 7* ;! % ( 6 - # <
Adathozzáférési (front-end) architektúra Üzemeltetési architektúra
Relációs lekérdezések optimalizálása
Tartalom Heurisztikus, szabály alapú optimalizálás Költség alapú optimalizálás Katalógus költségbecslés Operációk, mveletek áttekintése Kifejezés-kiértékelés Az optimális végrehajtási terv kiválasztása Lekérdezés optimalizálás csillagsémákon
Áttekintés
I. Heurisztikus, szabály alapú optimalizálás Relációs algebrai fás optimalizálás Lekérdezési fa EMPLOYEE (EMPLOYEE_ID, LAST_NAME, FIRST_NAME, BIRTH_DATE, ) PROJECT (PROJECT_ID, PNAME, ) WORKS_ON (PROJECT_ID, EMPLOYEE_ID) select last_name from employee, works_on, project where employee.birth_date > 1957.12.31 and works_on.project_id = project.project_id and works_on.employee_id = employee.employee_id and project.pname = Aquarius
Egy lehetséges rel. algebrai megfelel: σ EMPLOYEE 12 31 LAST _ NAME BIRTH _ DATE > '1957.. ' EMPLOYEE _ ID= EMPLOYEE _ EMPLOYEE _ ID (( ( )) ( WORKS _ ON) σ ( ( PROJECT ))) PROJECT _ ID= PROJECT _ PROJECT _ ID PNAME = ' Aquarius ' π LAST _ NAME (3) PROJECT _ ID= PROJECT_ PROJECT _ ID (2) EMPLOYEE _ ID= EMPLOYEE _ EMPLOYEE _ ID σ PNAME =' Aquarius' σ (1) BIRTH _ DATE > '1957. 12. 31' WORKS_ON PROJECT EMPLOYEE
Cél: a leggyorsabb alak kiválasztása Kiindulás: kanonikus alakból (Descartes, szrés, projekció) π LAST _ NAME σ PNAME = ' Aquarius' AND PROJECT _ ID= PROJECT _ PROJECT _ ID AND EMPLOYEE _ ID= EMPLOYEE _ EMPLOYEE _ ID AND BIRTH _ DATE > '1957. 12. 31' X X PROJECT EMPLOYEE WORKS_ON
Második lépés: szelekciók süllyesztése π LAST _ NAME σ PROJECT _ ID= PROJECT _ PROJECT _ ID X σ EMPLOYEE _ ID= EMPLOYEE _ EMPLOYEE _ ID σ PNAME =' Aquarius' X PROJECT σ BIRTH _ DATE > '1957. 12. 31' WORKS_ON EMPLOYEE
Harmadik lépés: levelek átrendezése π LAST _ NAME σ EMPLOYEE _ ID= EMPLOYEE _ EMPLOYEE _ ID X σ PROJECT _ ID= PROJECT _ PROJECT _ ID σ BIRTH _ DATE > '1957. 12. 31' X EMPLOYEE σ PNAME =' Aquarius' WORKS_ON PROJECT
Negyedik lépés: join π LAST _ NAME EMPLOYEE _ ID= EMPLOYEE _ EMPLOYEE _ ID PROJECT _ ID= PROJECT _ PROJECT _ ID σ BIRTH _ DATE > '1957. 12. 31' σ PNAME =' Aquarius' WORKS_ON EMPLOYEE PROJECT
Ötödik lépés: projekció süllyesztése π LAST_ NAME EMPLOYEE _ ID = EMPLOYEE _ EMPLOYEE _ ID π EMPLOYEE_ EMPLOYEE_ ID π EMPLOYEE_ EMPLOYEE_ ID, LAST_ NAME PROJECT _ ID = PROJECT _ PROJECT _ ID σ BIRTH _ DATE > '1957. 12. 31' π PROJECT _ ID PROJECT _ ID, EMPLOYEE _ ID π EMPLOYEE σ PNAME=' Aquarius' WORKS_ON PROJECT
Mikor ekvivalens két fa? Relációs algebrai transzformációk I. σ c1andc2 ANDANDcn ( R) σ c1 ( σ c2 ( ( σ cn( R)) )) σ c1 ( σ c2( R)) σ c2 ( σ c1 ( R)) π List1 ( π List 2 ( ( π Listn( R)) )) = π List1( R) π A1, A2, An ( σ c ( R)) σ c ( π A1, A2,, An ( R))
Mikor ekvivalens két fa? Relációs algebrai transzformációk II. R c S S R σ (R S) ( ( R)) c σ c c S π L (R c S) ( π A1,, An ( R)) c ( π B1,, Bm ( S)) π (R L S) c π ( π ( )) L ( A1,, An, An+ 1,, An+ k R π B1,, Bm, Bm+ 1, Bm p ( S))) c (, + A halmazmveletek (unió, metszet) kommutativitása A join, Descartes-szorzat, unio és metszet asszociatív: ( Rθ S) θ T Rθ ( Sθ T )
Mikor ekvivalens két fa? Relációs algebrai transzformációk III. σ π c L ( Rθ S) ( σ ( R)) θ ( σ ( S)) c ( Rθ S) ( π ( R)) θ ( π ( S)) L c L Egyéb szabályok: c NOT ( c1 AND c2) ( NOT c1) OR ( NOT c2) c NOT ( c1 OR c2) ( NOT c1) AND ( NOT c2)
Összefoglaló szabályok: konjunktív szelekciós feltételeket szelekciós feltételek sorozatává bontjuk. szelekciós mveleteket felcseréljük a többi mvelettel átrendezzük a lekérdezési fa leveleit. A Descartes szorzatokat és a fölöttük lév szelekciós kapcsolási feltételt egy join mveletté vonjuk össze. a projekciós mveleteket felcseréljük a többi mvelettel
II. KöltsK ltség g alapú optimalizálás 1. Elemzés (szintaktikus), fordítás 2. Költség optimalizálás 3. Kiértékelés
Példa 1. Lekérdezés: select balance from account where balance < 2500 Algebrai forma: π ( σ 2500 ( account balance balance < σ balance < π balance 2500 ( ( account )) ))
Példa 1: A lekérdez rdezés s végrehajtv grehajtási terv π balance σ balance < 2500 account
II. KöltsK ltség g alapú optimalizálás Katalógusadatok alapján történ költségbecslés A katalógusban tárolt egyes relációkra vonatkozó információk Katalógus információk az indexekrl A lekérdezés költsége Oracle megoldás az adatok frissítésére
A katalógusban tárolt t egyes reláci ciókra vonatkozó informáci ciók: n r : az r relációban lev rekordok száma (number) b r : az r relációban lev rekordokat tartalmazó blokkok (blocks) száma s r : egy rekord nagysága (size) byte-okban f r : mennyi rekord fér egy blokkba (blocking factor)
- V (A, r): hány különböz értéke (values) fordul el az A attribútumnak az r relációban (kardinalitás): V (A, r) = π A (r) ; A kulcs, akkor V (A, r) = n r. - SC(A, r) : (Selection Cardinality) azon rekordok átlagos száma, amelyek egy kiválasztási feltételt kielégítenek. Az A kulcs, akkor SC(A, r) = 1. Általános esetben : SC(A, r) = n r / V (A, r). Ha a relációk rekordjai fizikailag együtt vannak tárolva, akkor: b r = n f r r
Katalógus informáci ciók k az indexekrl f i : pointer kimenetek átlagos száma a fa struktúrájú indexeknél, pl. a B* fáknál HT i : az index szintjeinek száma (Height of Tree) HT HT i i = [ log V ( A, r) ] = 1 f i (Hash) (B* fa) LB i : a levélszint indexblokkok száma (Lowest level index Block)
Költség g meghatároz rozása Meghatározása: -igényelt és felhasznált erforrások alapján? -válaszid alapján? -kommunikációra fordított id alapján? Definíció: -háttértár blokkolvasások és írások száma a válasz kiírásának költsége nélkül +További egyszersítések
Select Operáci ciók, mveletek m költsk ltsége szelekciós algoritmusok (alap, indexelt, összehasonlításos) komplex szelekció Join típusai join nagyságbecslés join algoritmusok komplex join Egyéb ismétldés kiszrése unió,metszet,különbség
Alap szelekciós s algoritmusok (=) A1: Lineáris keresés Költsége: E A1 = b r A2: Bináris keresés Feltétele: blokkok folyamatosan a diszken A attribútum szerint rendezettek szelekció feltétele az egyenlség az A attribútumon Költsége: E A SC ( A, r ) 2 = log 2 r f r [ b ] + 1
Indexelt szelekciós s algoritmusok A3: Elsdleges index használatával, egyenlségi feltételt a kulcson vizsgálva E A3 = HT i + 1 A4: Elsdleges index használatával, egyenlségi feltétel nem kulcson (a nemkulcs attribútumon van az elsdleges index) E A4 = HT + A5: Másodlagos index használatával. E A5 = HT i + SC(A, r) i EA5 = HT i + 1 (ha A kulcs) SC ( A, r ) f r
Összehasonlítás s alapú szelekció - σ A v (r) Az eredményrekordok számának becslése: Ha v-t nem ismerjük: n r /2 Ha v-t ismerjük, egyenletes eloszlás esetén: n átlagos = n r v min( A, r) ( ) max( A, r) min( A, r)
Összehasonlítás s alapú szelekció - σ A v (r) A6: Elsdleges index használatával. Ha v-t nem ismerjük: E A6 =HT i +b r /2 Ha v-t ismerjük: E A 6 = HT i + A7: Másodlagos index használatával c f r LBi E A7 = HTi + + 2 nr 2 c jelöli azon rekordok számát, ahol A v
Komplex szelekció Konjukció: σ θ1 θ2.. θn (r) θ i kondíciónak eleget tev join nagysága: s i független feltételeket feltételezve Eredmény rekordok száma: Diszjunkció: σ θ1 θ2.. θn (r) Eredmény rekordok száma: Negáció: σ θ (r) Eredmény rekordok száma: size(r)-size(σ θ (r)) n r s * s 1 2 * *...* s n n r s 1 s 2 s n r * 1 1 * 1 *..* 1 nr nr n n n r
Komplex szelekció A8: Konjuktív szelekció indexek használatával. Legjobb feltétel mentén A9: Diszjunktív szelekció indexek mentén, minden feltétel-attribútumra van index lineáris keresés, ha nincs mindegyikre index A10: Szelekciók összekapcsolása diszjunkcióval pointereket készítünk az indexek alapján, majd unió a pointerekre Tanulság: A komplex szelekció kiértékelése semmivel sem bonyolultabb, mint egy szimpla szelekció.
Definíció: Típusai: Természetes join Join operáci ció Küls join (outer join) Bal oldali: T 1 (+)* T 2 Jobb oldali küls összekapcsolás: T 1 *(+) T 2. Teljes küls összekapcsolás: T 1 (+)*(+) T 2 T = σ feltétel (T 1 x T 2 ) ) Theta-join: R R ( R 2 ) θ σ 1 2 = θ 1 R T = π A U B (σ R1.X=R2.X (T 1 x T 2 ) )
Nested-loop join (egymásba ágyazott ciklikus illesztés) s) Adott két reláció r és s: FOR minden t r r rekordra DO BEGIN FOR minden t s s rekordra DO BEGIN teszteljük (t r, t s ) párt, hogy kielégíti-e a θ-join feltételt IF igen, THEN adjuk a t r. t s rekordot az eredményhez END END - worst case költség : n r *b s +b r -ha legalább az egyik befér a memóriába, akkor a költség: b r +b s
Block nested-loop join (blokkalapú egymásba ágyazott ciklikus illesztés) s) FOR minden b r r blokkra DO BEGIN FOR minden b s s blokkra DO BEGIN FOR minden t r b r rekordra DO BEGIN FOR minden t s b s rekordra DO BEGIN teszteljük le a (t r,t s ) párt END END END END - worst-case költsége: b r * b s + b r -sok memóriával: b r + b s
Indexed nested-loop join (indexalapú egymásba ágyazott ciklikus illesztés) s) - Az egyik relációhoz van indexünk (s) - Tegyük az els algoritmus bels ciklusába az indexelt relációt => A keresés index alapján kisebb költséggel is elvégezhet -Költsége: b r + n r *c, ahol c a szelekció költsége s-en.
További join implementáci ciók sorted merge-join a relációkat a join feltételben meghatározott attribútumok mentén rendezzük, majd összefésüljük hash-join az egyik relációt hash-táblán keresztül érjük el, miközben a másik reláció egy adott rekordjához illeszked rekordokat keressük egyéb pl. bitmap indexekkel (bitmap join)
Egyéb b operáci ciók Ismétldés kiszrése (rendezés, majd törlés) Projekció (projekció, majd ismétldés kiszrés) Unió (Mindkét relációt rendezzük, majd összefésülésnél kiszrjük a duplikációkat) Metszet (mindkét relációt rendezzük, fésülésnél csak a másodpéldányokat hagyjuk meg) Különbség (mindkét relációt rendezzük, fésülésnél csak els relációbeli rekordokat hagyunk) Aggregáció pl. márkanév G sum(egyenleg) (számla) számítása pl. rendezéssel márkanévre. Összegzés on-the-fly
Kifejezés s kiért rtékelés s módjaim Materializáció összetett kifejezésnek egyszerre egy mveletét értékeljük ki valamilyen rögzített sorrend szerint Pipelining egyszerre több elemi mvelet szimultán kiértékelése folyik egy operáció eredményét azonnal megkapja a sorban következ operáció operandusként
Materializáci ció Kanonikus alak: π customer _ name ( σ 2500 ( account) balance< customer) Mveleti fa: π customer_name σ balance < 2500 customer account Ered költség: a végrehajtott mveletek költsége + részeredmények tárolásának költsége Elnye: egyszer implementálhatóság Hátrány: sok háttértár-mvelet
Pipelining szimultán kiértékelés a részegységek az elttük álló elemtl kapott eredményekbl a sorban következ számára állítanak el részeredményeket nem számítja ki elre az egész relációt Elnye: -kiküszöböli az ideiglenes tárolás szükségességét -kicsi memóriaigény Hátránya: -szkíti a felhasználható algoritmusok körét
A kiért rtékelési terv kiválaszt lasztásasa milyen mveletek milyen sorrendben milyen algoritmus szerint milyen workflow-ban Egy konkrét kiértékelési terv
Költségalapú optimalizáci ció Mohó és egyben rossz stratégia: Minden ekvivalens kifejezés felsorolása Minden forma kiértékelése Az optimális kiválasztása Pl.: Tekintsük az alábbi kifejezést: r1 r2 r3, => 12 ekvivalens Általános esetben: n join-ra (2*(n-1))!/(n-1)! ekvivalens lehetség. Túl nagy terhelés a rendszer számára A megoldás: HEURISZTIKUS KÖLTSÉG ALAPÚ OPTIMALIZÁLÁS
Automatikus vs. manuális optimalizálás Az optimalizáló modul elnyei: Szélesebb ismeret a letárolt adatérétekekrl Gyorsabb numerikus kiértékelési mechanizmus Szisztematikus értékelés Algoritmusa több szakember együttes tudását hordozza Dinamikusan, minden mvelet eltt, az aktuális feltételeket figyelembe véve értékeldik ki. Az emberi optimalizálás elnyei: Szélesebb általános ismeret, a probléma szemantikai tartalmának megértése Nagyobb szabadság a felhasználható módszerek, eszközök tekintetében. Váratlan helyzetekre jobban felkészült.
III. Lekérdez rdezés optimalizálás csillagsémákon Lényegében egy illesztés a ténytábla és a dimenziós táblák között Dimenziós táblákat sohasem join-olunk A lehetség automatikus felismerése Hópihe séma: gyenge browsing teljesítmény, relációk növekv száma
Csillagséma optimális lekérdezése (feltételei, Oracle) Egyattribútumos bitmap index definiálása a tény valamennyi idegen kulcsára inicializáló paraméter beállítása (engedélyezés) költségalapú optimalizáló használata
Csillagtranszformáció Transzparens a felhasználónak Elve: 1. Dimenziós ID-k meghatározása 2. pontosan a szükséges tényrekordok kiolvasása bitmap segítségével 3. tényrekordok illesztése a dim. rekordokhoz.
Csillagtranszformáció példa SELECT ch.channel_class, c.cust_city, t.calendar_quarter_des 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 ( 2006-Q1', 2006-Q2') SELECT ch.channel_class, c.cust_city, t.calendar_quarter_desc FROM sales WHERE time_id IN (SELECT time_id FROM times WHERE calendar_quarter_desc IN( 2006-Q1', 2006-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'));
Mködése a dimenziók általában kevés rekordot tartalmaznak dimenziók lekérdezése a dimenziós ID-kra time_id bitmap azonosítja a 2006. els negyedévi tényrekordokat time_id bitmap azonosítja a 2006. második negyedévi tényrekordokat hasonló bitmap-ek azonosítják a megfelel customer-hez és channel-hez tartozó tényrekordokat a bitmap-eket kombináljuk logikai mveletekkel tényrekordok elvétele a diszkrl dimenziós rekordok join-ja a tényrekordokhoz (módja reguláris optimalizálás során dl el)
Mikor jó? Ha a where predikátuma kellen szelektív a tényrekordokra Ha sok tényrekord érintett az eredmény elállításában, akkor full table scan jobb lehet...
Dimenziós modellezés Dimenziós modellezés elnyei: lekérdezése könnyen optimalizálható a modell bvítése egyszer, nem kell átstrukturálni az adatbázist, ha új adatot veszünk fel laikusok által is könnyen lekérdezhet a lekérdezést nem feltétlenül kell megváltoztatni, ha az adattárház bvül
Négylépéses dimenziós modellezés 1. Üzleti folyamat azonosítása 2. Tényadat granularitásának megválasztása 3. Dimenziók azonosítása 4. Tények azonosítása
1. Üzleti folyamat izolálása Példák: szolgáltatás használata, hitelek igénylése és felvétele, bevételek alakulása, kinnlevségek, rendelések személyzeti ügyek számlázás javítások és reklamációk, stb.
2. Tényadat granularitásának megválasztása milyen részletes adatok tárolását támogatjuk túl részletes: sok adat, nagy diszkigény, nagy CPU igény nem elég részletes: elemzéseket akadályozhat meg LE KELL ÍRNI A TÉNYREKORD PONTOS JELENTÉSÉT
3. Dimenziók azonosítása Mi alapján akarjuk rendezni, lekérdezni, csoportosítani a tényadatokat? Sok és részletes dimenzió változatosabb analízisek Dimenziók azonosítása szigorúan az adatok használata (ld. üzleti igények) alapján Dimenzió lesz minden, ami... Inkább szöveges attribútumok, de lehet numerikus is
4. Tények azonosítása A használandó mennyiségek konkrét meghatározása (pl. eladási ár Ft-ban, darabszám, átlagos kisker. ár, ) Általában folytonos értékkészletek és numerikusak.
Dimenziós tervezési elvek A pontosan ismerni és érteni az adatokat Dimenziós táblák: leíró attribútumuk, akár 50 is, a rekordok hossza kevéssé kritikus. Ténytáblák: a rekordok legyenek rövidek Konform dimenziókban gondolkodunk Minden dimenziónak legyen surrogate (anonym, kiegészít, jelentés nélküli, mesterséges) kulcsa.
Elnyei: Surrogate kulcs méretcsökkentés a ténytáblában forrásrendszeri kulcs változásaitól függetlenek leszünk az entitások idbeli változásait is le tudjuk így írni Hátránya: újra kell kulcsolni a tény és dimenziós rekordokat (jelents betöltési többletteher)
Dimenziós tábla tervezés A felesleges dimenziók teljesítményveszteséget eredményeznek. A dimenziós adatok nem feltétlenül nyerhetk ki valamely forrásrendszerbl. Az id, termék, hely, ügyfél a leggyakoribb dimenziók
Id dimenzió IDOSZAKOK_DIMENZIO IDOSZAK_ID <pk> NUMBER(4) NAPTARI_DATUM DATE NAP_MEGNEVEZESE CHAR(10) NAP_MEGNEVEZESE_ANGOL CHAR(9) NAP_ROVID_BETUJELE CHAR(3) NAP_ROVID_BETUJELE_ANGOL CHAR(3) HET_HANYADIK_NAPJA NUMBER(1) HONAP_HANYADIK_NAPJA NUMBER(2) EV_HANYADIK_NAPJA NUMBER(3) PENZUGYI_NEGYEDEV_NAPJA NUMBER(3) HONAP_HANYADIK_HETE NUMBER(2) EV_HANYADIK_HETE NUMBER(2) HONAP_ROVIDITESE CHAR(5) HONAP_ROVIDITESE_ANGOL CHAR(3) EV_HANYADIK_HONAPJA NUMBER(2) NAPTARI_NEGYEDEV NUMBER(1) NEGYEDEV_HONAPJA NUMBER(1) NEGYEDEV_HETE NUMBER(2) NEGYEDEV_NAPJA NUMBER(3) PENZUGYI_NEGYEDEV NUMBER(1) PENZUGYI_NEGYEDEV_HONAPJA NUMBER(1) PENZUGYI_NEGYEDEV_HETE NUMBER(3) HANYADIK_FELEV NUMBER(1) HONAP_MEGNEVEZESE CHAR(10) HONAP_MEGNEVEZESE_ANGOL CHAR(9) EVSZAM NUMBER(4) ROVID_EVSZAM NUMBER(2) PENZUGYI_EVSZAM NUMBER(4) PENZUGYI_ROVID_EVSZAM NUMBER(2) IDOSZAK_MEGNEVEZESE CHAR(40) IDOSZAK_MEGNEVEZESE_ANGOL CHAR(40) IDOSZAK_ROVID_NEVE CHAR(3) IDOSZAK_ROVID_NEVE_ANGOL CHAR(3) NAPOK_SZAMA_FIX_IDOPONTTOL NUMBER(4) KARACSONY_JELZO CHAR(1) HUSVET_JELZO CHAR(1) ALAPERTELMEZETT_IDOSZAK CHAR(1) NAPTIPUS NUMBER(1) NAPTIPUS_MEGNEVEZES CHAR(9)
Ténytábla tervezés Tényadatok a lehet legkisebb granularitásban (vö.: hiányzó "vásárlói kosár" analízis). Additív tényadatok Hacsak lehetséges, összegezhetnek kell választani. Nem additív tényadatok Egyáltalán nem összegezhetk, egyetlen dimenzió mentén sem. Szemi-additív tényadatok minden dimenzió szerint összegezhet, kivéve az idt. (általánosabban: bizonyos dimenziók szerint összegezhetk, mások szerint nem)
Tényadatok additivitásáról Áruház Nap Napi egyenleg Napi átlag Budapest Hétf 200 Budapest Kedd 100 Budapest Szerda 50 Budapest Csütörtök 20 Budapest Péntek 300 Budapest Szombat 200 Budapest Vasárnap 200 152.86 Gyr Hétf 500 Gyr Kedd 600 Gyr Szerda 200 Gyr Csütörtök 100 Gyr Péntek 100 Gyr Szombat 500 Gyr Vasárnap 500 357.14 Összesen 3570 Egyszer átlag (összesen/tételek száma) 255 Helyes átlag (összesen/periódusok száma) 510 510
Ténynélküli ténytáblák pl. diákok óralátogatási szokásai (id, tárgy, terem, diák, tanár függvényében) (kampány) lefedettségi táblák Pl. az eladás ténye termék, bolt, id, kampányjellemzk függvényében. Nem ad választ arra, hogy mit NEM adtak el abból, amirl a kampány szólt! Megoldás: egy másik ténytábla rekordja jelentse a kampányban való részvételt tényrekord jelentése: van olyan... Valójában klasszikus több-több kapcsolatok
Állapot- és esemény-tények Esemény-tény: egyetlen idpont Állapot-tény: két idpont Új tényrekord beszúrása egy másik lezárásával jár alacsonyabb hatékonyság valószínbb információvesztés (ld. késbb) Általában egymásba átalakíthatók Kik, mikor, hol, mit, stb. vásároltak Kik azok a vásárlók, akiknek van Melyek azok a termékek, amelyeket eladtak A lekérdezések hatékonysága ersen különböz!
Role-playing dimenziók pl. id, cím,... többféle jelentést is hordozhat a tényadathoz kapcsolódóan egyetlen fizikai dimenzió, amely több idegen kulccsal kapcsolódik a tényrekordhoz
Degenerált dimenziók Számla, tételekkel. A tételek lesznek a tényadatok. Mi legyen a számlaszámmal? Vannak olyan leíró (rövid, dimenziós jelleg) adatok, amelyeket a ténytáblában helyezünk el kapcsolódó dimenzió nélkül. Pl.: dokumentum egyedi azonosító száma A forrásrendszerben lehet könnyen azonosítani velük valamit Egyedi megfontolás. Normálisak, várhatók, hasznosak
Junk dimenziók Flag-ek és szöveges leírók nem mindig szervezhetk értelmes dimenziókba Ténytáblában nem célszer elhelyezni Egy vagy néhány jelentés nélküli dimenziót alkothatnak.
Ha a dimenzió is változik idvel ( slowly changing dimensions, SCD) Pl. az ügyfél elköltözik, címe megváltozik 1. régi rekord felülírása 2. old mez képzése a dim. táblában 3. új rekord a dim. táblában a surrogate kulcs új értékével
1. felülírás Pl.: az ügyfelek címei változhatnak, ha elköltözik. Ügyfél ID Ügyfél neve Ügyfél címe 123 Gipsz Jakab Budapest, Tó u. 15. 1. felülírás Ügyfél ID Ügyfél neve Ügyfél címe 123 Gipsz Jakab Debrecen, F u. 3. Egyszer, de nincs history.
2. old mez létrehozása Ügyfél ID Ügyfél neve Ügyfél címe 123 Gipsz Jakab Budapest, Tó u. 15. 2. A jelenlegi és az elz állapot jellemzésével Ügyfél ID Ügyfél neve Ügyfél elz címe Ügyfél jelenlegi címe 123 Gipsz Jakab Budapest, Tó u. 15. Debrecen, F u. 3. egyszer, de korlátozottak a lehetségei.
3. Új dim. rekord készítése Ügyfél ID Ügyfél neve Ügyfél címe 123 Gipsz Jakab Budapest, Tó u. 15. 3. új dimenziós rekord minden változáshoz Ügyfél ID Ügyfél neve Ügyfél címe Tól Ig 123 Gipsz Jakab Budapest, Tó u. 15. 1989. júl. 15. 2005. szept. 6. 123 Gipsz Jakab Debrecen, F u. 3. 2005. szept. 7.??????? particionálja a history-t, nehézkesebb a lekérdezés
Reklámkampány analízis 1. Mi a korreláció bizonyos oksági tényezk (engedmények, kiállítás módja, kuponok) és a pezsgsvödrök eladása között (darabban és Forintban) szupermarketenként, termékenként és 4 hetes eladási periódusonként? 2. Változik-e a pezsgsvödrök árérzékenysége üzletenként? Szükség van továbbá az alábbi standard riportokra: Piaci részesedés termékkategóriákként, szupermarketenként és idszakonként A legjobban fogyó márkák szupermarketenként és idszakonként Az adatforrások: a szupermarketek eladási adatai 4 hetes összesítésekben termékkódokként és szupermarketenként az így kapott file tartalmaz információt az alkalmazott kedvezményekrl, a kiállítás módjáról, a kuponokról, az eladott darabszámról, az eladási árról, az átlagos kiskereskedelmi árról és a kereskedelmi hierarchiáról. Attribútumlista: Kedvezmények, átlagos kiskereskedelmi ár, márka, kategória, kuponok, szín, kiállítás módja, eladási ár, íz, üzlet, csomagolás, költség, év, évszak, termékkód, darabszám, hét, cím (üzlet), dátum
FIZIKAI TERVEZÉS 1. ld. fizikai adatbázis tervezésrl eddig tanultak 2. összegzések tervezése 3. lekérdezés optimalizálás kérdései
Összegzések tervezése DEF.: elre kiszámított speciális lekérdezés, amikor a ténytábla tényadatait összegezzük bizonyos feltételek mentén. Másképpen: a dimenziókban lév hierarchiák "összenyomása" és a tényadatok ennek megfelel összeadása. (Ezért fontos a tényadatok additivitása.) Legfontosabb eszköz a teljesítmény kézbentartására Akár 1000 összegzés is létezhet egyidejleg!
Összegzések tárolása Új tényrekordokra van szükség, amelyhez új dimenziós táblák kellenek és új mesterséges kulcs. Az új rekordok kétféleképpen tárolhatók: új ténytáblában új szintjelz mezk segítségével (kevésbé jellemz)
Összegzés új ténytáblában Az összegzett tényrekordokat új táblában helyezzük el (Praktikusan a meglév ténytáblából is képezhetjük a szerkezetét). Hasonlóképpen az új dimenziós táblákat is képezhetjük a meglév dimenziósakból, a granularitás csökkentésével Példa: eredeti tény: termékek megrendelése, dimenzió: termék aggregátum tény: márkák megrendelése, dimenzió: márka A tényrekordokat összegeztük márkák szerint, új kulcsot definiáltunk a márka dimenzióhoz.
Összegzések méretezése 1. Elv: legalább 10:1 mérték rekordszámcsökkenés A választás szempontjai a (dimenzió) kompressziója és az együttes elfordulási gyakoriság (density). A kompresszió: ha egy márkához átlagosan (!) 50 termék tartozik, akkor a márkára definiált összegzés 50-szeres kompressziójú. Termék-bolt-nap elfordulási gyakorisága: ha egy boltban egy nap eladják a termékek 10%-át (átlagosan) Márka-bolt-nap elfordulási gyakorisága: ugyanakkor egy boltban egy nap eladják a márkáknak az 50%-át (átlagosan)
Összegzések méretezése 2. A várható rekordok száma az összegzés ténytáblájában = <sorok száma a dimenziókban> szorozva <elfordulási gyakoriság> Az együttes elfordulási gyakoriságok elre általában nem ismertek Megoldás: becslések, ill. tapasztalati méretezés (ha elég jó, akkor meghagyjuk )
Összegzések méretezése 3. way Termék dim. Üzlet dim. Idszak dim. Termék Üzlet Idszak Gyakoriság 0 SKU üzlet nap 10000 1000 90 0.1 90,000,000 1 márka üzlet nap 2000 1000 90 0.5 90,000,000 1 1 SKU kerület nap 10000 100 90 0.5 45,000,000 2 1 SKU üzlet hónap 10000 1000 3 0.5 15,000,000 6 2 márka kerület nap 2000 100 90 0.8 14,400,000 6 2 márka üzlet hónap 2000 1000 3 0.8 4,800,000 19 2 SKU kerület hónap 10000 100 3 0.8 2,400,000 38 3 márka kerület hónap 2000 100 3 1 600,000 150 Rekordszám (millio) Összegzés kompresszió Dimenzió kompressziók: Termék-márka 5:1 Üzlet-kerület 10:1 Nap-hónap 30:1
Összegzés navigáció Új réteg. Nyilvántartja a létez összegzéseket és meghatározza, hogy melyik a legalkalmasabb a felhasználói lekérdezés kiszolgálására. Teljesítképesség és kényelmes használat Nagy a veszélye a túl sok összegzés definiálásának Nem mindegyik összegzés csökkenti jelentsen a sorok számát, ezeket futási idben kell kiszámolni. Számos adatbáziskezelnek része (pl. Oracle 8itl)
ÁLLOMÁSOZTATÓ TERÜLET TERVEZÉSE (Az ETL egyes fontosabb kérdései)
Back-room: data acquisition & staging Data acquisition (adat kinyerés) I. forrásrendszer minimális terhelése adat nem veszhet el és/vagy sérülhet teljes vs. inkrementális kezdeti ill. rendszeres flat file vs. adatbázis kapcsolat vs. hordozható táblatér metaadat gyjtés/vezérlés gyakoriság (ODS esetén sajátos megfontolások) tipikus források (pl. SAP) esetén dobozos interfész
Data acquisition (adat kinyerés) II. DW fejlesztési erfeszítések 60%-a adatelemek kiválasztása változások érzékelése (tranzakciós napló) full extract, ha: változás nem jól követhet szinkronizációhoz kis táblák esetén
Data acquisition (adat kinyerés) III. Adatkinyerés módja Adott idnként egyedi tábla másolatok (Full snapshot) Adott idnként egyedi tábla változásadatok Elnyök Egyszer Nem kell a forrásrendszert módosítani Forrásrendszer terhelése átidzíthet Forrásrendszer terhelése átidzíthet Információvesztés valószínsége kisebb Hátrányok Erforrásigényes mindkét oldalon Információvesztés lehetséges Nagy késleltetés A forrásrendszer módosításával járhat Nem mindig megvalósítható Nagy késleltetés Változásadatok eseményvezérelt kinyerése egyes táblákból Változásadatok kinyerése teljes tranzakció kontextusra, eseményvezérelten Kitüntetett adatokra kis késleltetés Információvesztés valószínsége még kisebb Információvesztés nincs Késleltetés nincs Viszonylag költséges Folyamatos többletterhelés a forrásnak Nem mindig megvalósítható Forrásrendszer módosításával jár együtt Költséges Bonyolult technológia Folyamatosan nagyobb többletterhelés a forrásnak Nem mindig megvalósítható Forrásrendszer módosításával jár együtt
Staging (állomásoztatás) I. Itt keletkezik a legtöbb hozzáadott érték Tervezése idigényes dimenziós és ténytáblák elállítása (bulk load!) flat file vs. relációs vs. egyedi struktúrák C, Cobol, utility-k, ill. adatbázis mveletek (sok overhead) archiválás adatmodell: teljesítmény és könny fejlesztés
Staging (állomásoztatás) II. metaadat vezérelt elv: a folyamatok a metaadattárból vezéreltek, mintsem beágyazottak az ETL programokba aktív-passzív metaadat (utasítás ill. dokumentál) változások a metaadattáron keresztül megvalósíthatók
Staging (állomásoztatás) III. adattípus konverziók adatforrások integrálása surrogátum kulcsok generálása referenciális integritás kezelése cleansing: (duplikátumok, hibás-hiányzó adatok) pontos specifikálás NULL: sok rendszerben nincs kódja
Adatminség javítása Minségi standard-ok definiálása (pontosság, teljesség, ellentmondás-mentesség, egységesség, frissesség) Javítás spec. karakterek ellentmondásos/változó használata (F N M F m f y n ) mez használat dokumentálatlan célra mez használat többféle célra adat fejldés - jelentésváltozás hiányzó - hibás - dupla értékek Javításuk a forrásrendszerben kívánatos, de nem mindig lehetséges A nevek és címek javítása külön tudomány
Staging (állomásoztatás) IV. Job vezérlés ütemezés: id és/vagy eseményvezérelt monitorozás naplózás (adatbázisba, segít optimalizálni is) kivételkezelés (visszautasított rekordok kezeléséhez hely, id, paraméterek kellenek) hibakezelés (crash recovery, stop, restart, állítható commit set jól jöhet) értesítés eseményrl (mail, SMS)
Staging (állomásoztatás) V. Mentések még UPS, mirroring, redundáns HW esetén is kell biztonsági mentés nagy teljesítmény egyszer adminisztráció nagyfokú automatizmus szoros kapcsolat a rendelkezésreállással
Staging (állomásoztatás) VI. Betöltés lépésenként Céltáblánként és célattribútumonként transzformációk leírása,végrehajtása Kivételkezelés megvalósítása Dimenzió betöltése (kis statikus, kis változó, nagyméret) Ténytáblák töltése Összegzések készítése Automatizmusok kialakítása
Prezentációs szerver Ahol az adatokat a végfelhasználók elérik Eleinte nem vált el a részletes adattártól Minél magasabb rendelkezésreállás
Közel valósidej adattárházak
Eddig: kötegelt (batch) feldolgozás Oka: a tipikus igényeket kielégíti és rel. olcsó Következmény: jelents késleltetés az eredményekben Cél: a késleltetés csökkentése
Valósidejség értelmezése I. felhasználói szempont: a lekérdezés eredménye álljon gyorsan el mszaki szempont: az adatok legyenek minél frissebbek Az igazi kihívás a kett együttes teljesítése. Eredmény: stratégiai, taktikai és operatív döntések támogatása
Valósidejség értelmezése II. Szigorú valós idej mködés akár folyamatirányításra Puha valós idej mködés döntéstámogatásra (near-time, soft realtime, right-time, on-time) Tipikusan mp-es, ill. nagyobb késleltetések Romlik a hatásfok, ha csökken a késleltetés
Hol lehet rá szükség? Általában: Ahol sok adat alapján gyors és automatizált döntésekre van szükség Ahol gyors döntéseket kell hozni példányokra vonatkozóan Ahol a jelenlegi mködést a historikus viselkedéssel kell összehasonlítani Tipikus területek: korai riasztások ( early warning ) KPI számítása kritikus folyamatok állandó követése vételi ajánlat készítés kártyás vásárlásnál CRM - gyors ügyfélinformáció hitelkártyacsalások felderítése
RTDW definíció Egy vállalatot átfogó (folytonos és többpontos) adatfolyam histórikus és analitikus része (Haisten, 1999.) Real Time is anything that is too fast for your current ETL (Kimball, 2005.)
Valósidejség a gyakorlatban (kompromisszumok) Nyers er helyett paradigmaváltás snapshot-ok helyett változásadatok frissítés gyakoriságának korlátozása statikus és dinamikus adatok szétválasztása lassan változó adatok kezelése továbbra is kötegelten
Komponensek Adatstruktúrák (tartalom) Megjelenítés Interfészek, adatmozgatás ETL helyett CTF (Capture, Transform, Flow)
CTF Adatkinyerés (Capture) folyamatosság ( kötegelt) teljes kontextus megragadása eseményvezérelt Transzformációk (Transform) konverziók, mezk szétválasztása, kódok feloldása összegzés, multidimenziós átalakítás Adattovábbítás (Flow)
Adatok kinyerése Full snapshot-ok: csak batch esetén Megváltozott adatok kinyerése Közvetlen támogatás nincs partícionálás idbélyegek triggerek Közvetlen támogatás a forrásrendszerben pl. CDC (Change Data Capture)
Oracle CDC (Change Data Capture) módosított adatok (U, I, D) azonnal elérhetk egy külön táblában publisher-subscriber(s) minden elfizetnek saját nézete van a megváltozott adatokra Az elfizet kezeli a nézet hosszát és törli belle az adatokat
Adatok mozgatása egyre szorosabb együttmködés az ETL és EAI eszközök között: Acta Works: Java JMS Informatica PowerCenterRT: IBM WebSphere MQ, TIBCO Rendezvous DataStage XE: IBM WebSphere MQ IBM Warehouse Manager: IBM WebSphere MQ
A valósidej adattár Hogyan töltsünk lekérdezés közben? Valós idej partíció kritikus mérszámok gyors korrekciójára IMDB Statikus partíciók hagyományos adattárház szakterületi adattárak ettl függenek valós idej partíció ürítése holtidben
Összegzések Ismert, hogy csökkenti a válaszidket helyet takarít meg elfedi a részletes adatokat szerepe átértékeldik trendek követése idérzékeny tevékenységeknél inkrementális összegzés
Egy lehetséges felépítés EAI Transzformációs motor Dinamikus partíció Statikus partíciók MDB L e k é r d e z é s e k Metaadatok MDB
Analógiák Tranzakciós rendszer: (digitális) fénykép a jelen állapotról Hagyományos adattárház: (digitális) fényképek sorozata - film Valósidej adattárház: (digitális) film, ahol csak a megváltozott képtartalmat rajzoljuk újra
Rövid történet 1998: els publikációk 1999: els fejlesztések 2001: els CTF eszközök megjelenése 2002: Oracle 9iR2 CDC 2003: HP Magyarország kísérleti RTDW v1.0 2004: Els Oracle alapú ipari implementáció (Euronext) 2006: Els Mo.-i ipari alkalmazás a MAVIRnál (BME-TMIT és HP)
Amikrl nem volt szó front-end kialakítása (ld. Inf. rendszerek fejlesztése ) teljesítmény méretezés teljesítmény mérés (www.tpc.org) hardver...
Jó tanulást! gajdos@db.bme.hu 06-209-365-073