Információ menedzsment eladások I. rész: Döntéstámogatás. Gajdos Sándor, TMIT sz

Információ menedzsment el adá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 (Maslow) Avagy: mi „m ködteti” az embereket

A vállalatok rengeteg energiát ölnek abba, hogy fokozzák alkalmazottaik lelkesedését. Ez igazán szép t lü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 id tö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

És mi „m ködteti” a vállalatokat?

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

Litmus teszt Gyakorlat

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 er forrá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észtvev i

heterogén csapatra van szükség • • • • • • • • • • • • • •

PM üzleti analitikus architect (f mé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-)min ségbiztosító, tesztel …

Követelmények összegy jtése • • • • •

Alapelvek El ké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 f bb 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)

Ügyfél Cím Hitel Utolsó módosítás

– Mike Jones – 123 Main Street – AA – 1992. jan. 12

Ügyfél Cím Hitel Utolsó módosítás

– Mike Jones – 14 Market Street – AA – 1994. ápr. 6

Adattárház (DW)

Április 6.: Mike Jones a Market Street 14-be költözött

Ügyfél Cím Hitel Mett l: Meddig:

Ügyfél Cím Hitel Mett l: Meddig:

– Mike Jones – 123 Main Street – AA – 1994. jan. 12 – 1994. ápr. 5.

– Mike Jones – 123 Main Street – AA – 1994. jan. 12. – jelen

Ügyfél Cím Hitel Mett l: Meddig:

– Mike Jones – 14 Market Street – AA – 1994. ápr. 6. – jelen

2

( & ' (

!

"

)(

* + # ,- * + !

% .! ,/ !

# $

3

#

!

% %

01 +

! !

"

* /! 5 #

Szemantikai integrálási folyamat

6 6( 6

- * + # ,* + # 01 +

( (

% .! ,/ ! ! !

& 7# .8 9

$

* +4

!

% %

:

;

=

#

$

!

"

M I D D L E W A R E

* /!

!

!

$

3

%

!

%

#

<

8

5 #

6 6( 6

- * + # ,* + # 01 + % .! ,/ ! ! & 7# .8 9

( (

:

;

Függ szakterületi adattár (hub-and-spoke architektúra) !

! &

8 5 6 6( #

6

- * + # ,* + # 01 + ( (

. !

% .! ,/ ! ! -

/ !

& 7# .8 9

:

;

300

250

300

200

250

150

200

100

150

50

100

0

50 1

2

3

4

5

6

7

8

0 1

!

7*

3

; -

% ( 6

#

<

2

3

4

5

6

7

8

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, m veletek á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)) ∏ (σ ( PROJECT))) LAST _ NAME

BIRTH_ DATE>' 1957.12.31'

PROJECT _ ID= PROJECT _ PROJECT _ ID

EMPLOYEE _ ID=EMPLOYEE _ EMPLOYEE _ID

(WORKS_ ON)

PNAME='Aquarius'

π

LAST _ NAME

(3) PROJECT _ ID = PROJECT _ PROJECT _ ID

(2) EMPLOYEE _ ID = EMPLOYEE _ EMPLOYEE _ ID

σ

EMPLOYEE

PNAME = 'Aquarius '

PROJECT

(1) BIRTH _ DATE > ' 1957.12.31'

σ

WORKS_ON

Cél: a leggyorsabb alak kiválasztása Kiindulás: kanonikus alakból (Descartes, sz ré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

EMPLOYEE

PROJECT

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

X

σ

BIRTH _ DATE > ' 1957.12 .31'

EMPLOYEE

σ

PNAME ='Aquarius '

PROJECT

WORKS_ON

Harmadik lépés: levelek átrendezése π

σ

LAST _ NAME

EMPLOYEE _ ID = EMPLOYEE _ EMPLOYEE _ ID

X

σ

PROJECT _ ID = PROJECT _ PROJECT _ ID

X

σ

PNAME = 'Aquarius '

PROJECT

σ

BIRTH _ DATE > ' 1957.12 .31'

EMPLOYEE

WORKS_ON

Negyedik lépés: join

π

LAST _ NAME

EMPLOYEE _ ID = EMPLOYEE _ EMPLOYEE _ ID

PROJECT _ ID = PROJECT _ PROJECT _ ID

σ

PNAME ='Aquarius '

PROJECT

WORKS_ON

σ

BIRTH _ DATE > ' 1957.12 .31'

EMPLOYEE

Ötödik lépés: projekció süllyesztése π

LAST_ NAME

EMPLOYEE _ ID = EMPLOYEE _ EMPLOYEE _ ID

π

π

EMPLOYEE_ EMPLOYEE_ ID

σ

PROJECT _ ID = PROJECT _ PROJECT _ ID

π σ

PROJECT _ ID

PNAME= 'Aquarius'

PROJECT

π

PROJECT _ ID ,

EMPLOYEE_ EMPLOYEE_ ID, LAST_ NAME

EMPLOYEE _ ID

WORKS_ON

1957 .12 . 31 ' BIRTH _ DATE > '

EMPLOYEE

Mikor ekvivalens két fa? Relációs algebrai transzformációk I.

σ c1 AND c 2 AND

AND cn

( R) ≡ σ

σ c1 (σ c 2 ( R )) ≡ σ

c2

π

Listn

List1

(π

π A1, A 2,

List 2

An

( (π

c1

(σ c 2 ( ( σ cn ( R )) ) )

(σ c1 ( R )) ( R )) ) ) = π

(σ c ( R )) ≡ σ c ( π A1, A 2,

( R)

List 1

, An

( R ))

Mikor ekvivalens két fa? Relációs algebrai transzformációk II. R

c

σ c (R

π L (R π L (R

S ≡S

c

R

S ) ≡ (σ c ( R)) c c

S ) ≡ ( π A1,

S , An

S ) ≡ π L ( (π A1,

( R ))

, An , An +1,

c , An + k

( π B1, ( R ))

, Bm c

( S ))

(π B1,

, Bm , Bm +1,

, Bm + p

( S )) )

A halmazm veletek (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 ( R θ S ) ≡ (σ c ( R)) θ ( σ c ( S ))

π L ( R θ S ) ≡ ( π L ( R)) θ (π L ( S )) Egyéb szabályok:

c ≡ NOT ( c1 AND c 2 ) ≡ ( NOT c1) OR ( NOT c 2)

c ≡ NOT ( c1 OR c 2 ) ≡ ( NOT c1) AND ( NOT c 2)

Összefoglaló szabályok: • konjunktí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 lekérdezési fa leveleit. • A Descartes szorzatokat és a fölöttük lév szelekciós kapcsolási feltételt egy join m veletté vonjuk össze. • a projekciós m veleteket felcseréljük a többi m velettel

II. Költsé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:

π balance (σ balance < 2500 ( account )) σ balance

< 2500

(π balance ( account ))

Példa 1: A lekérdezés végrehajtási terv πbalance σbalance < 2500 account

II. Költsé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 indexekr l – A lekérdezés költsége

• Oracle megoldás az adatok frissítésére

A katalógusban tárolt egyes relációkra vonatkozó információk: – nr : az r relációban lev rekordok száma (number) – br : az r relációban lev rekordokat tartalmazó blokkok (blocks) száma – sr : egy rekord nagysága (size) byte-okban – fr: 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) = nr . - 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) = nr / V (A, r).

Ha a relációk rekordjai fizikailag együtt vannak tárolva, akkor: br =

nr fr

Katalógus információk az indexekr l · fi : pointer kimenetek átlagos száma a fa struktúrájú indexeknél, pl. a B* fáknál · HTi : az index szintjeinek száma (Height of Tree)

[

HT i = log f i V ( A , r ) HT i = 1

]

(B* fa)

(Hash)

· LB i : a levélszint indexblokkok száma (Lowest level index Block)

Költség meghatározása Meghatározása: -igényelt és felhasznált er forrá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 egyszer sítések

Operációk, m veletek költsége • Select – szelekciós algoritmusok (alap, indexelt, összehasonlításos) – komplex szelekció

• Join – – – –

típusai join nagyságbecslés join algoritmusok komplex join

• Egyéb – ismétl dés kisz rése – unió,metszet,különbség

Alap szelekciós algoritmusok (=) • A1: Lineáris keresés – Költsége: EA1 = br

• A2: Bináris keresés – Feltétele: • blokkok folyamatosan a diszken • A attribútum szerint rendezettek • szelekció feltétele az egyenl ség az A attribútumon – Költsége: SC ( A , r ) E A 2 = [log 2 b r ] + −1 fr

Indexelt szelekciós algoritmusok • A3: Els dleges index használatával, egyenl ségi feltételt a kulcson vizsgálva – EA3 = HTi + 1 • A4: Els dleges index használatával, egyenl ségi feltétel nem kulcson (a nemkulcs attribútumon van az els dleges index) SC ( A , r ) E A 4 = HT i + fr • A5: Másodlagos index használatával. – EA5 = HTi + SC(A, r) – EA5 = HTi + 1 (ha A kulcs)

Összehasonlítás alapú szelekció - σA≤v(r) Az eredményrekordok számának becslése: Ha v-t nem ismerjük: nr/2 Ha v-t ismerjük, egyenletes eloszlás esetén:

v − min(A, r ) nátlagos = nr ( ) max(A, r ) − min(A, r )

Összehasonlítás alapú szelekció - σA≤v(r) • A6: Els dleges index használatával. – Ha v-t nem ismerjük: EA6=HTi+br/2 – Ha v-t ismerjük: E A 6 = HT i +

c fr

c jelöli azon rekordok számát, ahol A≤v

• A7: Másodlagos index használatával E A7

LBi nr = HTi + + 2 2

Komplex szelekció • Konjukció: σθ1∧θ2.. ∧θn (r)

– θi kondíciónak eleget tev join nagysága: si – független feltételeket feltételezve s1 * s2 * ... * sn – Eredmény rekordok száma: nr * n

• Diszjunkció: σθ1∨θ2.. ∨θn(r)

nr

sn s1 s2 – Eredmény rekordok száma: nr * 1− 1− * 1− *..* 1− nr nr nr

• Negáció: σ¬θ(r)

– Eredmény rekordok száma: size(r)-size(σθ(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ó.

Join operáció • Definíció: R1 • Típusai:

θ

R2 = σθ (R1 × R2)

– Természetes join T = πA U B(σR1.X=R2.X(T1 x T2) )

– Küls join (outer join) • Bal oldali: T1 (+)* T2 • Jobb oldali küls összekapcsolás: T1 *(+) T2. • Teljes küls összekapcsolás: T1 (+)*(+) T2

– Theta-join:

T = σ feltétel (T1 x T2) )

Nested-loop join (egymásba ágyazott ciklikus illesztés) Adott két reláció r és s: FOR minden tr ∈ r rekordra DO BEGIN FOR minden ts ∈ s rekordra DO BEGIN teszteljük (tr, ts ) párt, hogy kielégíti-e a θ-join feltételt IF igen, THEN adjuk a tr. ts rekordot az eredményhez END END -”worst case” költség : nr*bs+br -ha legalább az egyik befér a memóriába, akkor a költség: br+bs

Block nested-loop join (blokkalapú egymásba ágyazott ciklikus illesztés) FOR minden br ∈ r blokkra DO BEGIN FOR minden bs ∈ s blokkra DO BEGIN FOR minden tr∈ br rekordra DO BEGIN FOR minden ts ∈ bs rekordra DO BEGIN teszteljük le a (tr,ts) párt END END END END -“worst-case” költsége: br * bs + br -sok memóriával: br + bs

Indexed nested-loop join (indexalapú egymásba ágyazott ciklikus illeszté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: br + nr *c, ahol c a szelekció költsége s-en.

További join implementá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 operációk • Ismétl dés kisz rése (rendezés, majd törlés) • Projekció (projekció, majd ismétl dés kisz rés) • Unió (Mindkét relációt rendezzük, majd összefésülésnél kisz rjü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évGsum(egyenleg)(számla) számítása pl. rendezéssel márkanévre. Összegzés on-the-fly

Kifejezés kiértékelés módjai • Materializáció – összetett kifejezésnek egyszerre egy m veletét értékeljük ki valamilyen rögzített sorrend szerint

• Pipelining – egyszerre több elemi m velet 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ó Kanonikus alak:

π customer _ name (σ balance <2500 (account )

M veleti fa:

customer )

πcustomer_name

σbalance < 2500 customer account

Ered költség: a végrehajtott m veletek költsége + részeredmények tárolásának költsége El nye: egyszer implementálhatóság Hátrány: sok háttértár-m velet

Pipelining • szimultán kiértékelés • a részegységek az el ttük álló elemt l kapott eredményekb l a sorban következ számára állítanak el részeredményeket • nem számítja ki el re az egész relációt El nye: -kiküszöböli az ideiglenes tárolás szükségességét -kicsi memóriaigény Hátránya: -sz kíti a felhasználható algoritmusok körét

A kiértékelési terv kiválasztása •milyen m veletek •milyen sorrendben •milyen algoritmus szerint •milyen workflow-ban

Egy konkrét kiértékelési terv

Költségalapú optimalizá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 lehet sé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 el nyei: • Szélesebb ismeret a letárolt adatérétekekr l • Gyorsabb numerikus kiértékelési mechanizmus • Szisztematikus értékelés • 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 dik ki. Az emberi optimalizálás el nyei: • 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é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 lehet sé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'));

M kö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 m veletekkel • tényrekordok el vétele a diszkr l • dimenziós rekordok join-ja a tényrekordokhoz (módja reguláris optimalizálás során d l el)

Mikor jó? • Ha a where predikátuma kell en 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 el nyei: • lekérdezése könnyen optimalizálható • a modell b ví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 b vü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, • kinnlev sé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észlet ek é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.

Surrogate kulcs El nyei: • méretcsökkentés a ténytáblában • forrásrendszeri kulcs változásaitól függetlenek leszünk • az entitások id beli változásait is le tudjuk így írni Hátránya: • újra kell kulcsolni a tény és dimenziós rekordokat (jelent s 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 nyerhet k ki valamely forrásrendszerb l. • Az id , termék, hely, ügyfél a leggyakoribb dimenziók

Id dimenzió IDOSZAKOK_DIMENZIO IDOSZAK_ID 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, választani.

összegezhet nek

kell

• Nem additív tényadatok – Egyáltalán nem összegezhet k, dimenzió mentén sem.

• Szemi-additív tényadatok

egyetlen

– minden dimenzió szerint összegezhet , kivéve az id t. (általánosabban: bizonyos dimenziók szerint összegezhet k, 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 Gy r Hétf 500 Gy r Kedd 600 Gy r Szerda 200 Gy r Csütörtök 100 Gy r Péntek 100 Gy r Szombat 500 Gy r 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ányjellemz k függvényében. Nem ad választ arra, hogy mit NEM adtak el abból, amir l 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 id pont • Állapot-tény: két id pont – Új tényrekord beszúrása egy másik lezárásával jár alacsonyabb hatékonyság – valószín bb információvesztés (ld. kés bb)

• Á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 er sen 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 szervezhet k é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 id vel… (“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 123 Gipsz Jakab Egyszer , de nincs history.

Ügyfél címe Debrecen, F u. 3.

2. “old” mez létrehozása 123 2. 123

Ügyfél ID

Ügyfél neve Gipsz Jakab

Ügyfél címe Budapest, Tó u. 15.

A jelenlegi és az el z állapot jellemzésével Ügyfél ID Ügyfél neve Ügyfél el z címe Gipsz Jakab

egyszer , de korlátozottak a lehet ségei.

Budapest, Tó u. 15.

Ügyfél jelenlegi címe Debrecen, F u. 3.

3. Új dim. rekord készítése Ügyfél ID 123

Ügyfél neve Gipsz Jakab

Ügyfél címe Budapest, Tó u. 15.

3. új dimenziós rekord minden változáshoz Ügyfél ID Ügyfél neve Ügyfél címe 123 Gipsz Jakab Budapest, Tó u. 15. 123 Gipsz Jakab Debrecen, F u. 3. particionálja a history-t, nehézkesebb a lekérdezés

Tól 1989. júl. 15. 2005. szept. 7.

Ig 2005. szept. 6. ???????

Reklámkampány analízis

1. Mi a korreláció bizonyos oksági tényez k (engedmények, kiállítás módja, kuponok) és a pezsg svö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 pezsg svö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 id szakonként • A legjobban fogyó márkák szupermarketenként és id szakonké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ényekr l, 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ésr l eddig tanultak 2. összegzések tervezése 3. lekérdezés optimalizálás kérdései

Összegzések tervezése • DEF.: el re 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 egyidej leg!

Ö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 mez k 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 el fordulá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 el fordulási gyakorisága: ha egy boltban egy nap eladják a termékek 10%-át (átlagosan) • Márka-bolt-nap el fordulá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 <el fordulási gyakoriság> • Az együttes el fordulási gyakoriságok el re á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 0 1 1 1 2 2 2 3

Termék dim. SKU márka SKU SKU márka márka SKU márka

Üzlet dim. üzlet üzlet kerület üzlet kerület üzlet kerület kerület

Dimenzió kompressziók: Termék-márka Üzlet-kerület Nap-hónap

Id szak dim. nap nap nap hónap nap hónap hónap hónap

5:1 10:1 30:1

Termék Üzlet Id szak 10000 1000 90 2000 1000 90 10000 100 90 10000 1000 3 2000 100 90 2000 1000 3 10000 100 3 2000 100 3

Gyakoriság 0.1 0.5 0.5 0.5 0.8 0.8 0.8 1

Rekord- Összegszám zés komp(millio) resszió 90,000,000 90,000,000 1 45,000,000 2 15,000,000 6 14,400,000 6 4,800,000 19 2,400,000 38 600,000 150

Ö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ít ké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 jelent sen a sorok számát, ezeket futási id ben kell kiszámolni. • Számos adatbáziskezel nek része (pl. Oracle 8it l)

Á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 gy jté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 er feszí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

El nyök

Hátrányok

Adott id nként egyedi tábla másolatok (Full snapshot)

Egyszer Nem kell a forrásrendszert módosítani Forrásrendszer terhelése átid zíthet

Er forrásigényes mindkét oldalon Információvesztés lehetséges Nagy késleltetés

Adott id nként egyedi tábla változásadatok

Forrásrendszer terhelése átid zíthet Információvesztés valószín sége kisebb

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

Kitüntetett adatokra kis késleltetés Információvesztés valószín sége még kisebb

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

Változásadatok kinyerése teljes tranzakció kontextusra, eseményvezérelten

Információvesztés nincs Késleltetés nincs

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 id igé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 m veletek (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

Adatmin ség javítása • Min sé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 fejl dé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ényr l (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: jelent s késleltetés az eredményekben • Cél: a késleltetés csökkentése

Valósidej ség értelmezése I. • felhasználói szempont: a lekérdezés eredménye álljon gyorsan el • m szaki 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ósidej ség értelmezése II. • Szigorú valós idej m ködés – akár folyamatirányításra • Puha valós idej m kö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 m kö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ósidej sé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, mez k 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 • id bé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érhet k egy külön táblában • publisher-subscriber(s) • minden el fizet nek saját nézete van a megváltozott adatokra • Az el fizet kezeli a nézet hosszát és törli bel le az adatokat

Adatok mozgatása • egyre szorosabb együttm kö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ér számok gyors korrekciójára • IMDB

– Statikus partíciók • hagyományos adattárház • szakterületi adattárak ett l függenek • valós idej partíció ürítése holtid ben

Összegzések • Ismert, hogy – csökkenti a válaszid ket – helyet takarít meg – elfedi a részletes adatokat

• szerepe átértékel dik • trendek követése id érzékeny tevékenységeknél • inkrementális összegzés

Egy lehetséges felépítés Dinamikus partíció

Transzformációs motor

EAI Statikus partíciók

MDB

MDB Metaadatok

L e k é r d e z é s e k

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)

Amikr l 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! [email protected] 06-209-365-073