DW 4. előadás MD modell

Átírás

1 DW 4. előadás MD modell

2 Multidimenzionális adatmodell A normalizált relációs modell bonyolult a felhasználók számára TELEP(tkod, nev, kozpont, regio,...) TERMÉK(kod, megnevezes, egysegar,...) TERMELES(termek, telep, datum, db, kategoria,...) termelés alakulása a keleti régióra vonatkozóan az elmúlt három hónapra vonatkoztatva.. CREATE VIEW v1 AS SELECT termek, datum, sum(db) as odb FROM termeles WHERE datum BETWEEN sysdate() AND sysdate() 90 GROUP BY termek, datum; SELECT b.megnevezes, c.odb, b.egysegar*c.odb as ertek, c.datum FROM Telep a, termek b, v1 c WHERE a.tkod = c.telep AND c.termek = b.kod AND a.regio = Kelet ORDER BY megnevezes, datum ;

3 Multidimenzionális adatmodell ugyanez keresztreferencia táblázat formában.. grafikonon CREATE VIEW v2 AS SELECT b.megnevezes, c.odb, b.egysegar*c.odb as ertek, c.datum FROM Telep a, termek b, v1 c WHERE a.tkod = c.telep AND c.termek = b.kod AND a.regio = Kelet ORDER BY megnevezes, datum ; SELECT SUM(CASE megnevezes WHEN cipo THEN ertek ELSE 0) CIPO, SUM(CASE megnevezes WHEN kalap THEN ertek ELSE 0) KALAP, SUM(CASE megnevezes WHEN ing THEN ertek ELSE 0) ING, FROM v2 GROUP BY datum dátumok termékek

4 Induló SQL utasítás általában: SELECT mező1,, mezőn, sum(menny) as mennyiség FROM táblanév GROUP BY mező1,, mezőn;

5 Adattárházak adatmodelljei A relációs modell gyenge pontjai az adattárházaknál: - OLTP orientált, - szétdarabolt (normalizált) adatszerkezet, - SQL nyelv bonyolultsága, - lassú a kapcsolatok kezelése. A relációs modell előnyei az adattárházaknál: - bevált technológia, - szabványosság, megalapozottság, - létező motorok rendelkezésre állása. Adattárház rendszerek: ROLAP : relációs motorra épül MOLAP: MD modellre épül

6 MD adatmodell alapjai Célkitűzések, elvárások: - emberi szemlélethez közelebb álló legyen, - egyszerűbb parancs felület, - szemléletes, - OLAP orientált. Elvégzett módosítások: - normalizáltság megszüntetése, - egységbe fogja az adatokat, - vizuális analógiára épít, - adatelemzési műveletekre támaszkodik. A több egydimenziós relációt egy összefogó adatkockába hozza össze.

7 Multidimenzionális adatmodell A relációs táblák egydimenziós (egy kulcs) struktúrák. Lehetővé kell tenni, hogy több kulcs is rendelhető legyen az adatokhoz. termék telep dátum Adatkocka felépítése

8 Adatkocka és relációs tábla összevetése termék termelés telep termek telep dátum FK-kapcsolat Kétirányú átalakítás, ekvivalens struktúrák

9 Adatkocka alkotó elemek

10 Adatkocka alkotó elemek Tény (fact) Tag (member) Dimenzió (dimension) Változó (measure) Adatkocka (cube) termek Dimenzió érték Tulajdonság (attribute) Adatcella Dimenzió hierarchia telep Dátum Év Hónap Nap

11 Adatkocka alkotó elemek, fogalmak Változó, tag, tény: azon mennyiség aminek az értékét, alakulását vizsgáljuk (amit tárolunk az adatkockában); a működési paraméterek meghatározó mennyisége rendszerint numerikus, additív (aggregálható), de lehet semi-additív (pl. dátum mentén raktárkészlet, vagy tanulmányi átlag), vagy non-additív (pl. szín). Dimenzió: azon mennyiség, amitől függ a változó működési paraméter (a kulcsok, amiknek a függvényében érhetjük el az egyes tényadatokat) lehet összetett, szöveges, leíró. Tag: a változó komponense. Tulajdonság/attribútum: a dimenzió komponense (pl. termék dimenziónál a termék megnevezése, vagy egységára). Adatkocka: a változók és kapcsolt dimenzióik.

12 Adatkocka alkotó elemek, fogalmak Ténytábla: idegen kulcs attribútumok gyűjteménye; elsődleges kulcsa idegen kulcsokból áll össze, plusz az időbeliség; reprezentálja az üzleti dimenziót (főleg numerikus adatok). CREATE TABLE TÉNYTÁBLA(AB REF(PROD), TRDATE D, BC REF(LOC), SUM N(6), COUNT N(6), PK(AB, TRDATE, BC))

13 Adatkocka reprezentációk CUBE MOLAP Relation-network ROLAP

14 MD séma modell Csillag (star) modell Dátum - év - hó - nap Vásárlás - érték - tömeg Vevő - név - kód Bolt - név - cím - régió Cella - érték - darab - tömeg dátum bolt vevő Középen vastag keretben a ténycella szerepel, a dimenziók hozzá kapcsolódnak, a dimenzió és a tény megadásnál az attribútumok is szerepelnek.

15 Minta csillag modell nehéz a különböző aggregációs szintek, ismétlődő dimenziók kezelése

16 MD séma modell reklamáció hónap termék napi forgalom forgalom dátum bolt napi forgalom Galaxis (fact constellation) modell

17 Minta a galaxis modellre Nehéz a kapcsolódó dimenziók kezelése

18 Csillag modell A forgalmat bolt és régió bontásban is szeretnénk látni a: két külön dimenzió (érték függőség, ritka kocka) régió forgalom bolt b: egy dimenzió (eltérő szint, nem egyenrangú, korlátozott) forgalom bolt - régió külön dimenzió kellene, úgy hogy a kapcsolat megmaradjon

19 Dimenzió hierarchia Ország A Ország B ország régió AA régió AB régió megye AB1 megye AB2 megye Járás AB11 Járás AB12 járás Település AB12A Település AB122B település előfordulás bázisszint séma

20 Összetett dimenzió hierarchia Egy kulcsot több felbontási szinten is lehet értelmezni.

21 MD séma modell hónap termék forgalom dátum kategória bolt munkahét Hópehely (snowflake) modell Bevezeti a dimenzió hierarchiát

22 Hópehely (snowflake) modell

23 Hópehely (snowflake) modell

24 Minta a hópehely modellre osztott dimenziók kezelése

25 MD séma modell gyártó reklamáció termék forgalom dátum(nap) régió bolt hónap negyedév Hópehely-háló modell

26 Befoglalt adatkocka Egy adatkocka (cube) adatait a dimenzióhierarchia mentén haladva és a dimenziók bevonásával eltérő részletezettségi szinten szemlélhetjük. Ezek a cuboid-ok (4d-s rácsozása). csúcspont alap

27 Country Tervezési irányelvek Konzisztens dimenziók Teljességet adó dimenziók Degenerált dimenziók Többértékű dimenziók Date 1Qtr 2Qtr 3Qtr 4Qtr TV PC VCR sum sum U.S.A Canada Mexico sum Aggregációs függvények lehetnek: - disztributív (min(), max(), sum()), - algebrai (avg(), stddev()), - holistic, teljeskörű (median(), rank()).

28 Összeférő (conformed) dimenziók: olyan dimenziókat kell alkalmazni, amelyek minden adatkockában ugyanolyan jelentéssel és szerkezettel rendelkeznek. A tartalmi és formai illeszkedés vizsgálatát és kialakítását minden dimenzió esetében el kell végezni. A dimenzió mellett a többi adatmodell elemre is értelmezhető az illeszkedés, a konformitás fogalma. Így a változók esetében is beszélhetünk összeférő változókról, amikor is az azonos változó elnevezés mögött azonos jelentés és azonos szerkezet húzódik meg az adattárház modell minden adatkockája esetén. Az összeférő változók és dimenziók alkalmazása nemcsak logikai lezártságot jelent, hanem egyben szükséges előfeltétele is a különböző data mart vagy adatbázis forrásokból származó adatelemek integrálásának.

29 Szempontok a tervezés során a dimenzió és változó struktúrájának kialakításakor : leíró elnevezés: az elnevezésnek sugallnia kell a tartalmat, általános jelentésű legyen: a struktúrának minden lehetséges alkalmazási feladat és körülmény között alkalmazhatónak kell lennie, tiszta, helyes ellenőrzött értékű legyen, jól tagolt: mivel az alkalmazások, a feldolgozások szempontjából az az előnyös, ha az igényelt adatelemek már készen rendelkezésre állnak, s nincs szükség bonyolult elemzési, kiemelési funkciókra, (ehhez azonban a tárolt információt elemi információkra és elemi adatelemekre célszerű feldarabolni), hatékonyan kezelhető, indexelhető: a belső karbantartás hatékonysága szempontjából célszerű, ha az azonosító szerepet betöltő elemek kis méretűek és egyértelmű rendezés értelmezhető rajtuk.

30 A dimenziók tervezése során az irányelvek betartása mellett is előfordulhatnak olyan esetek, amikor a szokásostól eltérő struktúrákat kell létrehozni. Degenerált dimenzió: olyan dimenziót jelent, amelynek nincs attribútuma, egy tulajdonság nélküli dimenzió (pl. rendelési szám); fizikai szinten a degenerált dimenziók csak a ténytáblában fordulnak elő. A dimenzió a tény változó egyed egy jellemzőjét tartalmazza, kijelölve minden tény cellához egy dimenzió előfordulást. A dimenziók egyértelműen kijelölik az egyes ténycellák pozícióját az adatkockán belül. Előfordulhat, hogy minden tény cellához nem csak egyetlen egy dimenzió előfordulás köthető (pl. orvosi vizsgálatnál több gyógyszer). Többértékű dimenzió: a dimenzióknak több előfordulása is társítható az egyes ténycellákhoz. Hibás, mert egyértékű lehet a kapcsoló mező. Gyógyszer - kód - gyártó - név - Orvosi vizsgálat - összeg - időtartam - Beteg - név - irsz. - település - Orvos - név - kód - Dátum - év - hó - nap

31 Megoldás: egy külön kapcsoló tábla (híd (bridge) tábla) bevezetése, fel kell venni egy külön táblát, amelynek célja a kapcsolódó cella előfordulás és dimenzió előfordulás párosok nyilvántartása. Minden egyes ténycellának lesz egy egyedi csoportkulcsa, s a híd tábla cellái az összetartozó dimenzió kulcsot és csoportkulcsot tartalmazzák. Gyógyszer gykód vkód gykód vizsgálat vkód A híd táblát nem csak a többértékű dimenziók esetében szokás használni, hanem a hálós dimenziók esetében is, hiszen itt sem közvetlenül mutat a rendszer a tény cellából a hozzá tartozó dimenzió előfordulás hierarchia miden tagjára (pl. cikkek szerzői). Szerző - név - cím - fokozat - hivatkozás Terület - név - kód Szakcikk - hivatkozási pont - oldalszám Dátum - év - hó - nap Folyóirat - név - kód - kiadó -

32 Nem ismert előre, hogy milyen mélységű is lesz a dimenzió háló, ezért nem lehet fixen beépíteni a cella struktúrába az összes dimenzió előfordulásra mutató pointert. A tetszőleges méretű dimenzió háló kezelésére a híd kocka alkalmazása a megoldás, mivel segítségével rugalmasan leírhatók a változó méretű kapcsolat rendszerek is. Az egyes híd tábla cella előfordulások az egyes dimenzió előfordulások kapcsolatát adják meg, minden egyes leszármazotti viszonyhoz egy híd táblabeli cella előfordulás fog létrejönni. A híd cella előfordulás két kapcsoló mezőt tartalmaz, az egyik mutat az ős dimenzió előfordulásra, a másik pedig annak egy leszármazottjára. Technikai okokból célszerű olyan híd cellát is létrehozni, melyben mindkét kapcsoló ugyanazon dimenzió előfordulásra mutat. Ekkor az induló ténytábla cella egy ilyen híd cella előfordulásra fog mutatni, mely mindkét kapcsoló mezőjével az érintett dimenzió előfordulást fogja tartalmazni. A rendszer tartalmazni fog még több olyan híd cella előfordulást is, melyek ezen induló dimenzió előfordulást a belőle származó dimenzió előfordulásokkal kötik össze. skód1 skód2 Szerző skód név ckód skód Cikk ckód

33 Egy dimenzió típus többszörözötten is kapcsolódhat egy ténytáblához. Például egy szervizelési folyamathoz többféle szerepkörben is hozzárendelhetjük az idő dimenziót (bejelentési, kiszállási, kezdési, befejezési időpont). Ezen elemek mindegyikét lehet egy-egy önálló dimenzióként szerepeltetni az adatmodellben, hiszen mindegyik más-más jelentéssel bír. A szokásos megvalósítás szerint ekkor mindegyik dimenzió mögött egy önálló dimenzió előfordulás táblázat állna. A szervizes példában az időpontok megadása több helyen is ismétlődne. Fizikailag egy megadott időpont leírása több helyen is előfordulna redundanciát okozva. A rendszer jobb helykihasználása végett azonban hasznosabb, ha magát az idő adatokat csak egyszer tároljuk le, és a különböző dimenziók esetében közösen kerülnek felhasználásra az egyes dimenzió előfordulások. Szerepkörökkel ellátott dimenzió: egy fizikai dimenzió több különböző logikai szerepkörben is megjelenik az adatkocka modellben.

34 Mindegyik szerepkör esetén: a kapcsoló hivatkozások egy közös dimenzió előfordulás halmazba mutatnak, a dimenzió előfordulásai csak egyszer, redundancia nélkül kerülnek letárolásra. Ezáltal jelentős helytakarékosság érhető el és sokkal hatékonyabb lesz az egyes szerepkörökön keresztüli összekapcsolások megvalósítása. Nem kell különböző táblák rekordjait illeszteni, mert egy táblában helyet foglal az összes előfordulás. Értékelő oktató - okód - név - fokozat Vizsga - jegy - sorszám Felügyelő oktató - okód - név - fokozat Vizsga - jegy - sorszám felügyelő értékelő Oktató -okód -név -fokozat..

35 Relációs modell konverziója multidimenzionális modellre - tényadatok feltárása, - kapcsolatok feltárása, - ténytáblák, tagok meghatározása, - dimenziók kijelölése, - idő dimenzió behozatala, - egyéb dimenzió bővítés, - attribútumok meghatározása, - dimenzió hierarchia meghatározása, közben ügyelni a következőkre: - dimenzió konzisztencia, - dimenzió teljesség, - osztott dimenziók, - időbeliség (változik-e).

36 Konverziós mintapélda CREATE TABLE VAROS(NEV C(20), MEGYE C(20)) CREATE TABLE FUV(FKOD N(3), NEV C(20),CÍM C(50), PK(FKOD)) CREATE TABLE DOLG(KOD N(3), NEV C(20), BEOSZT REF(BEO), FIZ N(5), PK(KOD)) plusz CREATE TABLE BEO CREATE TABLE VEVO(KOD N(4), NEV C(20), VAROS REF(VAROS), UCIM C(20), PK(KOD)) CREATE TABLE TEL(CIM C(30), VEZ REF(DOLG), NEV C(20), HELY REF (VAROS), FUVAROZO REF(FUV), PK(NEV)) CREATE TABLE TERM(KOD N(4), NEV C(20), KATEG C(20), PK(KOD)) CREATE TABLE TERTEKESIT(ARU REF(TERM), DATUM D, TELEP REF(TEL), OSSZ N(6), SELEJT N(6), PK(ARU, DATUM, TELEP)) CREATE TABLE RENDELES(RKOD N(6), IDO D, DARAB N(5), ARU REF(TERM), VEVO REF(VEVO), PK(RKOD)) PK(ARU, IDO, VEVO)

37 Konverziós mintapélda TEL VAROS DOLG TERTEKESIT RENDELES FUV TERM VEVO TELEPHELY VAROS FUVAROZO ERTEKESITES RENDELES TERMEK VEVO

38 Konverziós mintapélda ERTEKESITES RENDELES TELEPHELY FUVAROZO DATUM VAROS MEGYE HO EV VEVO TERMEK KATEGORIA

39 Konverziós mintapélda (csak ERTEKESITES) FUVAROZO nev, cim TELEPHELY cim nev ERTEKESITES OSSZDB SELEJTDB TERMEK cim nev KATEGORIA nev DATUM nap VAROS megn MEGYE megn EV ev HO ho

40 MD séma rekordszinten név típus dimenzió tábla név típus tény tábla név típus dimenzió tábla név típus dimenzió tábla

41 Fizikai megvalósítás (2D-t nézve) TELEPHELY cim nev OSSZDB SELEJTDB Audi Opel Fiat Lada TERMEK cim nev KATEGORIA nev Baja Miskolc Dorog Logikai struktúra

42 Fizikai megvalósítás K G P A F L O Audi Opel Fiat Lada Baja Miskolc 7,2 6,1 7,0 3,2 9,1 7,4 Dorog 7,2 4,2 ritkán kitöltött kocka

43 Tervezési irányelvek- minőségbiztosítás Data Warehouse Back-End Quality Issues Metadata Repository Reporting / OLAP tools Sources DSA DW Quality Issues Data Marts Administrator Administrator Designer End User EDBT Summer School - Cargese

44 DW Materialized Views! DS.PS_NEW DS.PS_NEW 1.PKEY, DS.PS_OLD 1.PKEY SUPPKEY=1 DS.PS 1.PKEY, LOOKUP_PS.SKEY, SUPPKEY COST DATE 1 DS.PS_OLD 1 DIFF 1 DS.PS 1 Add_SPK 1 SK 1 Log rejected $2 rejected Log A2EDate rejected Log U DS.PS_NEW 2 DS.PS_NEW 2.PKEY, DS.PS_OLD 2.PKEY SUPPKEY=2 DS.PS 2.PKEY, LOOKUP_PS.SKEY, SUPPKEY COST DATE=SYSDATE QTY>0 DIFF 2 DS.PS 2 Add_SPK2 SK 2 NotNULL AddDate CheckQTY DS.PS_OLD rejected rejected 2 Log Log DSA PKEY, DAY MIN(COST) S 1 _PARTSU PP FTP 1 DW.PARTSU PP Aggregate 1 V1 DW.PARTSUPP.DATE, DAY PKEY, MONTH AVG(COST) S 2 _PARTSU PP FTP 2 TIME Aggregate 2 V2 Sources DW A DW több mint aggregált adattáblák rendszere EDBT Summer School - Cargese

45 Időbeli változás követése A struktúra jelentős változáson mehet át - dimenzió változása, - dimenzió hierarchia változása, - tényváltozó változása. átíródik Változó dimenziók Változások konzisztens követése? teljes verzió (history) tulajdonság verzió

46 Időbeli változás követése Érték változása Dolgozó név = KA fizetés = 5 új fizetés = 8 Dolgozó név = KA fizetés = 8 Dolgozó név = KA fizetés = 5 új fizetés = 8 Dolgozó név = KA fizetés = 5 Dolgozó név = KA fizetés = 8 Dolgozó név = KA fizetés = 5 új fizetés = 8 Dolgozó név = KA fizetés1 = 5 fizetés2 = 8

47 Időbeli változás követése Érték változása Kiegészítő mechanizmusok a méretek keretek között tartásához: a kis számú gyakran változó tulajdonság szeparálása a többi, ritkán változó tulajdonságtól, az érték változások gyakoriságának csökkentése egy intervallum-érték tárolásra történő áttéréssel. fizetés kategóriák -11 : A -18 : B -26 : C Dolgozó név = KA fizetés = A Hatékonyság: tervezés során, DW-rendszer motor mechanizmusai. új fizetés = 8 új fizetés = 12 Dolgozó név = KA fizetés = A Dolgozó név = KA fizetés = A Dolgozó név = KA fizetés = B

48 Location dimension: Időbeli változás követése Dimenzió hierarchia változása Issues Second Case Study D C1 D1 C1 D2 D D D2-50 Query: «Total number of births per year and district?» D D1 D2 1. Exact view 2. First Structure 3. Second Structure Evo??? Nov DOLAP 2002 McLean USA D 2001 Evo D1 D * 60 ** Evo * D1 ~ 40 % of the births of D1 ** D2 ~ 60 % of the births of D1

49 Kocka megalkotása A problémakör több fogalmat fog egybe, ezek rendezhetők - hybercube sémába, vagy - multicube sémába. - Hypercube (4d cube; kocka, amelyiknek 3-nál több dimenziója van; adatok logikailag egyszerű kockák; DW egy központi kocka): egyszerűség, ritka kitöltésű, nagy eltérés a fizikai szinttől. - Multicube (adatok kisebb kockák halmazába szeletelve; DW min. 2 kocka): - block mode több változó egységben, - series mode egy kocka csak egy változó.

50 Hypercube/hiperkocka Multidimenzionális struktúra Raktár Idő Termék Metrika A Jan. ABC Költség Termék Telephely B Febr. BAC CBA Bevétel Kiadás Dátum Mennyiség Raktár DAB Eladás C Márc. DBC Nyereség Beszállító Vevő EFG Selejt ABC/Eladás ABC/Költség BAC/Eladás BAC/Költség CBA/Eladás CBA/Költség Jan Febr Márc Oldal: raktár dim., sor: idő dim., oszlop: termék dim. és metrika kombinálva

51 Projekt feladat Minta MD modell kidolgozása PE-re Katica csavargyár modulok: 1. raktár 2. gyártás 3. rendelés/vevői és saját 4. számlázás 5. munkaügy 6. szerviz 7. bérügy