Adattárházak. Adattárház: alapfogalmak. Adattárház modellek: adatkockák és OLAP. Adattárház architektúrák. Adattárházak megvalósítása

Átírás

1 Adattárházak Adattárház: alapfogalmak Adattárház modellek: adatkockák és OLAP Adattárház architektúrák Adattárházak megvalósítása Adatok általánosítása és fogalmi leírások Az adattárháztól az adatbányászatig Adattárházak 1

2 Mi az adattárház? Sokféleképpen definiálják, nincs egyértelmő meghatározás. Olyan döntéstámogató adatbázis, amelyet a szervezet mőködéséhez szükséges adatbázisától elkülönítve üzemeltetnek Egyesített, történeti (idıtıl függı) adatok elemzését, információ feldolgozását támogató platform. Az adattárház olyan témaspecifikus, integrált, idıfüggı, fizikailag is tárolt adatgyőjtemény, amely a menedzsment döntéshozó folyamataihoz szükséges lehet. W. H. Inmon Adattár-háztartás (Data warehousing): Az adattárházak készítésének, felhasználásának folyamatai Adattárházak 2

3 Mit jelent a témaspecifikusság (Subject-Oriented)? Mit vizsgálunk: vásárlókat, termékeket, eladásokat? Nem a napi mőködéshez szükséges folyamatokkal, tranzakciós folyamatok foglalkozunk, hanem a modellezéssel, a döntéshozók számára hasznos adatelemzésekkel Egy speciális témakörhöz szükséges adathalmaz egyszerő, tömör reprezentálása. Kihagyjuk azokat az adatokat, amelyek nem kellenek a döntéshozáshoz. Adattárházak 3

4 Mit jelent az integráltság? Többféle, heterogén adatforrás adataiból készítjük el az adattárházat relációs adatbázisok, sima szöveges fájlok, tranzakciós rekordok Integrációs technikákat és adattisztítást kell alkalmaznunk. Biztosítani kell a különbözı helyrıl származó adatok esetén is az egységes elnevezéseket, egységes struktúrákat, egységes attribútum mértékeket. például a szállodai szobaár: Ft, 2700 Ft AFA, reggelivel Az adattárházba kerüléskor rögtön konvertáljuk az adatokat a megfelelı formátumra Adattárházak 4

5 Mit jelent az idıfüggés? Általában hosszabb idıtartamra (akár évekre visszamenıleg) vizsgáljuk az adatokat A mőködési adatbázisban: az adatok aktuális értéke szerepel Az adattárházban: az adatok múltja is szerepel Az adattárház kulcsai (azonosítói) mindig tartalmaznak idıpontot, explicit vagy implicit formában a mőködési adatbázisban nincs mindig idıpont megadva Adattárházak 5

6 Mi jellemzı a fizika tárolásra? A mőködési környezetbıl átvett adatokat fizikailag elkülönítve tároljuk A mőködési környezetben történı módosítások nem láthatók egybıl az adattárházban Nincs szükség tranzakció-kezelésre, naplózásra, konkurenciakezelésre Két alapvetı adatelérési mővelet kell csak: a kezdeti adatbetöltés és a lekérdezésekhez szükséges adatelérés Adattárházak 6

7 Adattárház vagy heterogén adatbázis-kezelés? A heterogén adatbázisok hagyományos integrálása: lekérdezésvezérelt Burkolókat és közvetítıket (wrappers/mediators) használunk a heterogén adatbázisok feletti rétegben A lekérdezést egy metaszótár segítségével a heterogén adatbázisok számára értelmezhetı alkérdésekké alakítjuk, a megfelelı adatbázisban végrehajtjuk az alkérdést, majd az eredményeket visszaadjuk, és ezekbıl összerakjuk az eredeti lekérdezésre a választ bonyolult információszőrı folyamat, ráadásul az erıforrásokért versenyezni is kell (mi van, ha nem érhetı el éppen az adatbázis?) Adattárház: frissítésvezérelt, nagy teljesítmény, gyorsaságot lehet elérni vele a heterogén adatforrások adatait elızetesen integráljuk és betöltjük egy adattárházba, majd ezt kérdezzük le, ezen végezzük el az elemzéseket. Adattárházak 7

8 Adattárház vagy mőködési adatbázis? OLTP (on-line transaction processing) on-line tranzakciós feldolgozás a hagyományos adatbázis-kezelés fı feladata a napi mőködést szolgálja ki: vásárlás, raktárnyilvántartás, bankolás, gyártás, bérszámfejtés, regisztrálás, könyvelés. OLAP (on-line analytical processing) on-line elemzı feldolgozás az adattárházak fı feladata adatok elemzése, döntéshozás Mik az eltérések az OLTP és az OLAP között: felhasználói kör, a rendszer célja: ügyfelek kiszolgálása, illetve piaci pozíciók megszerzése adattartalom: részletes, aktuális, illetve redukált, történeti adatok az adatbázis tervezése: az alkalmazásoknak megfelelı egyed-kapcsolat modell, illetve a témához tartozó adatok csillagsémában tárolva nézıpont: aktuális helyi adatok, illetve több helyrıl származó, integrált adatok idıbeli változása hozzáférések célja: módosítás, illetve bonyolult, csak olvasási lekérdezések Adattárházak 8

9 Az OLTP és az OLAP közti különbségek OLTP OLAP a felhasználók ügyfelek, adminisztrátorok, programozók a funkcionalitás célja napi mőködés kiszolgálása döntéshozás az adatbázis tervezése alkalmazásorientált témaorientált az adatok aktuálisak, részletesek, relációsak, vagy szöveges állományok, elkülönítettek adatelemzı tudásmunkások történeti, összesített, többdimenziós, egységesített, integrált a felhasználás módja folyamatos, ismétlıdı idınkénti, ad-hoc a hozzáférés módja olvas/írás, indexek az elsıdleges kulcsokra lekérdezések, sokféle, speciális index használata a tipikus munkaegység rövid, egyszerő tranzakció összetett lekérdezés a munkaegységbe bevont rekordok száma pár tucat milliós nagyságrend a felhasználók száma több ezer száznál kevesebb az adatbázis mérete 100 megabájt pár gigabájt 100 gigabájt több terabájt a teljesítmény mérése tranzakciószám/másodperc lekérdezés száma/másodperc, átlagos válaszidı Adattárházak 9

10 Miért különítjük el az adattárházat? Nagy teljesítmény akarunk elérni mindkét rendszerben Az adatbázis-kezelı rendszerek az OLTP-t támogatják: különbözı adatelérési módszerekkel, indexelésekkel, konkurenciakezeléssel, helyreállítási mechanizmusokkal Az adattárház az OLAP-ot támogatja: összetett OLAP lekérdezéseket, többdimenziós nézeteket, összesítéseket Más a cél, másfélék az adatok, mint OLTP esetén: hiányzó adatok: A döntésekhez nagyon régi adatok is kellhetnek, ami a napi mőködéshez nem kellene (már archiválva van) összesítések: heterogén forrásokból származó adatokat kell összesíteni, aggregálni adatminıség változatos: a különbözı rendszerek eltérıen reprezentálják, kódolják az adatokat, így ezeket össze kell egyeztetni Megjegyzés: Léteznek adattárház nélküli OLAP rendszerek, amelyek közvetlenül az relációs adatbázisból dolgoznak. Adattárházak 10

11 Adattárházak Adattárház: alapfogalmak Adattárház modellek: adatkockák és OLAP Adattárház architektúrák Adattárházak megvalósítása Adatok általánosítása és fogalmi leírások Az adattárháztól az adatbányászatig Adattárházak 11

12 A táblázatoktól az adatkockákig Az adattárház többdimenziós adatmodellt valósít meg, tipikusan adatkockákat használ. Egy adatkocka, mint például az eladások, esetén az adatokat több dimenzióban nézhetjük, modellezhetjük Dimenziótáblákat használunk: cikk(cikk_név, márka, típus), vagy idı(nap, hét, hónap, negyedév, év) A ténytábla tartalmazza az értékeket, mértékeket (például eladott_mennyiség_dollárban) és kulcsokat a megfelelı dimenziótáblákhoz, amely alapján a dimenzió részleteit tudjuk a tényekhez hozzákapcsolni Az n-dimenziós (n-d) alapkockát alapkuboidnak (alaptéglának) hívjuk. Ez a legrészletezettebb nézete a tényeknek. A legfelsı szintő 0-D kuboid a teljes összesítést tartalmazza, (függetlenül helytıl, idıtıl, egyéb dimenzióktól). Ez az apex kuboid. A kuboidok hálóját hívjuk adatkockának. Adattárházak 12

13 Az adatkocka: a kuboidok hálója összes (all) 0-D (apex) kuboid idı cikk hely szállító 1-D kuboidok idı,cikk idı,hely cikk,hely hely,szállító idı,szállító cikk,szállító 2-D kuboidok idı,cikk,hely idı,hely,szállító idı,cikk,szállító cikk,hely,szállító idı, cikk, hely, szállító 3-D kuboidok 4-D (alap) kuboid Adattárházak 13

14 Az adattárház fogalmi modelljei Adattárházak modelljei: dimenziók és mértékek Csillagséma: Középen áll a ténytábla, ami dimenziótáblákkal van összekapcsolva. Hópehelyséma: A csillagséma finomítása, a dimenziótáblákat dekomponáljuk normálformájú kisebb dimenziótáblákra. Csillagkép vagy galaxisséma: Több ténytábla közös dimenziótáblákat használ. Adattárházak 14

15 Csillagséma time time_key day day_of_the_week month quarter year branch branch_key branch_name branch_type Mértékek Sales ténytábla time_key item_key branch_key location_key units_sold dollars_sold avg_sales item item_key item_name brand type supplier_type location location_key street city state_or_province country Adattárházak 15

16 Hópehelyséma time time_key day day_of_the_week month quarter year Sales ténytábla time_key item_key item item_key item_name brand type supplier_key supplier supplier_key supplier_type branch branch_key branch_name branch_type Mértékek branch_key location_key units_sold dollars_sold avg_sales location location_key street city_key city city_key city state_or_province country Adattárházak 16

17 Galaxisséma ( 2 ténytáblával) time time_key day day_of_the_week month quarter year Sales ténytábla time_key item_key branch_key item item_key item_name brand type supplier_type Shipping ténytábla time_key item_key shipper_key from_location branch branch_key branch_name branch_type Mértékek location_key units_sold dollars_sold avg_sales location location_key street city province_or_state country to_location dollars_cost units_shipped shipper shipper_key shipper_name location_key shipper_type Adattárházak 17

18 Adatbányász (adattárház) nyelvek Szabvány nincs, de több kísérlet történt a funkciók SQL-szerő leírására. DMQL egy adatbányász lekérdezı nyelv relációs adatbázisokra (Han definiálta 1996-ban) GMQL (Geo Mining Query Language) - térbeli adatok adatbányászó nyelve, DMQL-re épül (Koperski definiálta 1999-ben) SDMOQL (Spatial Data Mining Object Query Language) itérbeli adatok objektum alapú lekérdezı nyelve, OQL-re épül (Malerba definiálta 2002-ben) Adattárházak 18

19 Adatkocka definiálása (BNF) DMQLben Kocka (ténytábla) definiálása define cube <kockanév> [<dimenzió_lista>]: <mérték_lista> Dimenziótáblák definiálása define dimension <dimenziónév> as (<attribútum_vagy_aldimenzió_lista>) Közös dimenziótáblák definiálása ha már egy kockában definiáltuk a dimenziót define dimension <dimenziónév> as <dimenziónév_a_másik_kockában> in cube <a_másik_kocka_neve> Adattárházak 19

20 Csillagséma definiálása DMQL-ben define cube sales_star [time, item, branch, location]: dollars_sold = sum(sales_in_dollars), avg_sales = avg(sales_in_dollars), units_sold = count(*) define dimension time as (time_key, day, day_of_week, month, quarter, year) define dimension item as (item_key, item_name, brand, type, supplier_type) define dimension branch as (branch_key, branch_name, branch_type) define dimension location as (location_key, street, city, province_or_state, country) Adattárházak 20

21 Hópehelyséma definiálása DMQL-ben define cube sales_snowflake [time, item, branch, location]: dollars_sold = sum(sales_in_dollars), avg_sales = avg(sales_in_dollars), units_sold = count(*) define dimension time as (time_key, day, day_of_week, month, quarter, year) define dimension item as (item_key, item_name, brand, type, supplier(supplier_key, supplier_type)) define dimension branch as (branch_key, branch_name, branch_type) define dimension location as (location_key, street, city(city_key, province_or_state, country)) Adattárházak 21

22 Galaxisséma definiálása DMQL-ben define cube sales [time, item, branch, location]: dollars_sold = sum(sales_in_dollars), avg_sales = avg(sales_in_dollars), units_sold = count(*) define dimension time as (time_key, day, day_of_week, month, quarter, year) define dimension item as (item_key, item_name, brand, type, supplier_type) define dimension branch as (branch_key, branch_name, branch_type) define dimension location as (location_key, street, city, province_or_state, country) define cube shipping [time, item, shipper, from_location, to_location]: dollar_cost = sum(cost_in_dollars), unit_shipped = count(*) define dimension time as time in cube sales define dimension item as item in cube sales define dimension shipper as (shipper_key, shipper_name, location as location in cube sales, shipper_type) define dimension from_location as location in cube sales define dimension to_location as location in cube sales Adattárházak 22

23 Adatkockák az Oracle-ben Adattárházak 23

24 Dimenzió készítése Oracle-ben Adattárházak 24

25 Szintek és hierarchiák készítése Oracle-ben Adattárházak 25

26 Attribútumok készítése Oracle-ben Adattárházak 26

27 Kocka készítése Oracle-ben Adattárházak 27

28 A kocka mértékeinek megadása Oracle-ben Adattárházak 28

29 Az adatkockákban háromféle mérték szerepelhet Disztributív: partíciókra kiszámolva és az eredményekre alkalmazva ugyanazt kapjuk, mintha a teljes adathalmazra alkalmaztuk volna: f( {f(p1),,f(pn)} ) = f(p1 Pn) ilyen például a count(), sum(), min(), max() Algebrai: ha egy N változós algebrai függvénybe disztributív függvényeket helyettesítünk ilyen például avg() = sum()/count(), n n n s = standard_deviation() ( xi x) = [ xi ( xi ) n 1i= 1 n 1 i= 1 n i= 1 Holisztikus (teljes): nem korlátos számú argumentumú függvény min_n() : n-ik legkisebb, például median(), mode(), rank() 2 ] Adattárházak 29

30 Egy fogalmi hierarchia a HELY dimenzióban összes - bármi (all) bármi (all) régió Europe... North_America ország Germany... Spain Canada... Mexico város Frankfurt... Vancouver... Toronto iroda L. Chan... M. Wind Adattárházak 30

31 Adattárházak, hierarchiák megjelenítése Hierarchiák specifikálása: séma szintő hierarchia nap < {hónap < negyedév; hét} < év értékhalmaz szintő hierarchia {1..10} < olcsó Adattárházak 31

32 Többdimenziós adatok Az eladott mennyiséget a termék, hónap és régió függvényében adjuk meg Dimenziók: Termék, Hely, Idı Hierarchikus összesítı utak Ipar Régió Év Termék Kategória Ország Negyedév Termék Város Hónap Hét Iroda Nap Hónap Adattárházak 32

33 Az összesítéseket tartalmazó adatkocka Σ TV PC MP3 Dátum 1.n.é. 2. n.é. 3. n.é. 4. n.é. Σ Éves TV eladás az USA-ban U.S.A Kanada Mexico Ország Σ Adattárházak 33

34 A kockának megfelelı kuboidok all termék dátum ország 0-D (apex) kuboid 1-D kuboidok termék,dátum termék,ország dátum, ország 2-D kuboidok termék, dátum, ország 3-D (alap) kuboid Adattárházak 34

35 Adatkocka böngészése Az adatkocka használatánál szükséges a megjelenítés OLAP mőveletek kezelése interaktív kezelés Mi jellemzı a legnagyobb összesített eladásra? Legnagyobb kocka: Észak- Amerika, szabadtéri, olcsó termék: legfeljebb az ára Adattárházak 35

36 Tipikus OLAP mőveletek Felgörgetés - Roll up (drill-up): összesítjük (pl. összegezzük) az adatokat a hierarchián feljebb lépve vagy a dimenziót elhagyva Lefúrás - Drill down (roll down): kirészletezünk adatokat (a felgörgetés fordítottja) alacsonyabb szintő összesítést veszünk, részletezzük az adatokat, vagy bevezetünk egy új dimenziót Szeletelés és kockázás - Slice and dice: vetítés és kiválasztás Forgatás (pivotálás) - Pivot (rotate): elforgatjuk a kockát, vagy a vizualizációját, a 3D-t alkotó 2D-s síkszeletek sorozatát átrendezzük Egyéb mőveletek Keresztülfúrás - drill across: egynél több ténytáblában fúrunk le Átfúrás -drill through: a lefúrást SQL utasításokkal a kockában a legrészletezettebb adatokig, azaz az alap relációs táblákig folytatjuk Adattárházak 36

37 Példa az OLAP mőveletekre: felgörgetés (Roll-up) A városokat összesítjük az országokban Adattárházak 37

38 Példa az OLAP mőveletekre: lefúrás (Drill-down) Kibontjuk a negyedéveket hónapokra Adattárházak 38

39 Példa az OLAP mőveletekre: kockázás (Dice) Egy részkockát képzünk két városra, két negyedévre és két termékre Adattárházak 39

40 Példa az OLAP mőveletekre: szeletelés (Slice) Az elsı negyedév szerinti kétdimenziós szeletet vesszük Adattárházak 40

41 Példa az OLAP mőveletekre: forgatás (Pivot) A hely és termék tengelyeket felcseréljük Adattárházak 41

42 A dimenziók fogalmi hierarchiáinak reprezentálása csillagháló (Star-Net) modellben Szállítás Rendelések szerzıdések Vásárló légi Idı év negyedév kamion nap rendelések cikk márka termékcsoport Termék ország város értékesítı karácsonyi kerület Hely régió Minden kör egy lábnyom (footprint) téli osztály Akciók Szervezet Adattárházak 42

43 Adattárházak Adattárház: alapfogalmak Adattárház modellek: adatkockák és OLAP Adattárház architektúrák Adattárházak megvalósítása Adatok általánosítása és fogalmi leírások Az adattárháztól az adatbányászatig Adattárházak 43

44 Adattárház tervezése Négyféle szempont az adattárház tervezéséhez Fentrıl le az adattárházhoz szükséges lényeges információ kiválasztása (mire van és mire lehet majd szükség) Adatforrás mit tárolunk a mőködési rendszereinkben Adattárház milyen tény és dimenziótáblákat tárolunk az adattárházban Üzlet a végfelhasználó milyen célra használhatja majd az adatokat Adattárházak 44

45 Az adattárház tervezési folyamata Fentrıl le, vagy lentrıl fel, vagy kombinálva Fentrıl le (Top-down): Gondosan, fokozatosan részletezve mindent megtervezünk (idıigényes) Lentrıl fel (Bottom-up): Próbálgatunk, prototípusokat adunk (gyors) Szoftvertervezési szempontból Vízesés modell (Waterfall): strukturált, szisztematikus elemzés, mielıtt a következı lépést megtesszük Spirális modell (Spiral): gyorsan, egyre több funkcionalitást teszünk a készülı rendszerbe Az adattárház tervezési folyamatának tipikus lépései Határozzuk meg az üzleti folyamatokat, amelyekben modellezzünk például a rendeléseket, számlákat Határozzuk meg az üzleti folyamatok atomi adatszintjét Határozzuk meg a tényrekordokhoz tartozó dimenziókat Határozzuk meg a rekordokban szereplı mértékeket Adattárházak 45

46 Adattárház megvalósítása többrétegő architektúrában Más források Mőködési adatbázis Metaadat Kiszed Tisztít Transzformál Betölt Frissít Monitor & Integrátor Adattárház OLAP Szerver szolgáltat Elemzés Lekérdezés Jelentések Adatbányászat Adatpiacok Adatforrások Tárolt adatok OLAP motor Kliens eszközök Adattárházak 46

47 Az adattárház három típusa Vállalati adattárház (Enterprise warehouse) a teljes szervezet összes fontos információját tartalmazza, amely bármilyen témájú elemzéshez valaha is kellhet Adatpiac (Data Mart) egy adott témához (például marketing) szükséges adatok győjteménye külön is megépíthetjük, de lehet része a vállalati adattárháznak is Virtuális adattárház (Virtual warehouse) A mőködési adatbázisra építünk nézeteket Egyes összesítı nézeteket materializálunk Adattárházak 47

48 Adattárház építése 3. Osztott adatpiacok építése 4. Többrétegő adattárház architektúra 2. Adatpiac építése 2. Adatpiac építése 2. Vállalati adattárház építése A modell finomítása A modell finomítása A modell finomítása 1. Magas szintő szervezeti adatmodell definiálása Adattárházak 48

49 Adattárház-építı segédeszközök Adatgyőjtéshez több, heterogén, akár külsı adatforrásból összegyőjti, kiválasztja a szükséges adatokat Adattisztításhoz adathibákat kijelzi, ha lehet ki is javítja Adattranszformációhoz az örökölt adatbázisokból az adatokat az adattárház formátumára transzformálja Betöltéshez rendez, összesít, egyesít, nézeteket készít, ellenırzi az integritási feltételeket, indexeket készít, particionál Frissítéshez idıközönként az új adatokat, változásokat betölti az adattárházba Adattárházak 49

50 A leíró adatok kezelése (Metadata Repository) A metaadatok az adattárház objektumainak definícióit tárolják. Adattárház struktúráinak leírása sémák, nézetek, dimenziók, hierarchiák, számolt adatok definíciói, adatpiacok elérési helye és tartalma Mőködési metaadatok adatvonal (a migrált adatok története és a transzformációk sorozata), adatállapot (aktív, archivált, törölt), monitorozási információk (használati statisztikák, hibajelentések, ellenırzések) Az összesítésekhez, aggregációkhoz szükséges algoritmusok Azok a leképezések (mappings), amelyek a mőködési adatbázisból áttöltik az adatokat az adattárházba Rendszer szintő adatleírások a jobb teljesítményhez indexek definíciói, frissítési periódusok Üzleti adatok üzleti fogalmak, definíciók, díjkalkulációk Adattárházak 50

51 OLAP szerver architektúrák Relációs OLAP (ROLAP) alsó rétegben egy relációs vagy objektumrelációs adatbázis-kezelı tárolja, kezeli az adattárház adatait, erre épül rá az OLAP köztes réteg az adatbázis-kezelı lehetıséget biztosít az optimalizálásra, aggregációra és egyéb kiegészítı eszköz, szolgáltatás használatára jól skálázható Multidimenziós OLAP (MOLAP) ritka tömbök kezelésére kifejlesztett többdimenziós tárkezelı az összesített, aggregált adatok speciális indexelési lehetısége Hibrid OLAP (HOLAP) (pédául Microsoft SQLServer) az alsó szint relációs, felsı szint tömbkezelı Speciális SQL szerver (például Redbricks) SQL lekérdezı utasítások csillagsémákra, hópehelysémákra Adattárházak 51

52 Adattárházak felhasználása Felhasználási területek Alapinformáció szolgáltatása lekérdezések, alapvetı statisztikai elemzések, jelentések, (táblák, kereszttáblák, diagramok, grafikonok) Elemzések többdimenziós elemzések OLAP mőveletek (szeletelés, kockázás, lefúrás, forgatás) használata Adatbányászat rejtett minták feltárása asszociációs szabályok keresése, analitikus modell készítése, osztályozás és elırejelzés, az eredmények vizuális megjelenítése Adattárházak 52

53 Adattárházak Adattárház: alapfogalmak Adattárház modellek: adatkockák és OLAP Adattárház architektúrák Adattárházak megvalósítása Adatok általánosítása és fogalmi leírások Az adattárháztól az adatbányászatig Adattárházak 53

54 Adatkockák hatékony elıállítása Az adatkocka kuboidok hálója A háló legalján az alapkuboid áll. A háló tetején az egy cellából álló apex kuboid áll. Hány darab n-dimenziós kuboid van, ha L i (+1 az ANY miatt) szint van egy dimenzióban? T = n ( L i + 1) i = 1 Az adatkockát érdemes materializálni teljes materializálás: összes kuboidot (2 n vagy még több, ha szintek is vannak) részleges materializálás: néhány kuboidot nincs materializás Melyik kuboidot materializáljuk? gyakran van rá szükség, mennyi hely van a kuboidok tárolására, sok összesítést tudunk belıle képezni Adattárházak 54

55 Adatkocka mőveletek A kocka definiálása DMQL-ben define cube sales[item, city, year]: sum(sales_in_dollars) compute cube sales Kifejezhetı SQL-ben a cube by (Gray 1996) mővelettel () SELECT item, city, year, SUM (amount) (city) (item) (year) FROM SALES CUBE BY item, city, year Mindez az alábbi Group-By ok képzését jelenti (date, product, customer), (city, item) (city, year)(item, year) (city, item, year) (date,product),(date, customer), (product, customer), (date), (product), (customer) () Adattárházak 55

56 A jéghegy kocka Csak azokat a kuboidokat számoljuk ki, amelyekhez tartozó aggregátorérték elég nagy, például elég sok adatot tartalmaz Motiváció HAVING COUNT(*) >= minsup Általában csak kevés kuboid érdekes egy ritka kockában Azok lesznek az érdekesek, amelyben az aggregáció elér egy küszöbindexet Nem kell exponenciális sok kockát kiszámolni Adattárházak 56

57 A jéghegy kocka SELECT Part, StoreLocation, Customer, SUM(Price) FROM R CUBE BY Part, StoreLocation, Customer HAVING COUNT(*) >=2 Az R adatbázis A jéghegy kuboidjai PRICE Adattárházak 57

58 Az OLAP adatok indexelése: Bitmap index Olyan oszlopra jó, amelyben kevés különbözı értéke szerepel (az oszlop képmérete kicsi) Minden értéknek egy bitvektor felel meg, mivel a bitmőveletek gyorsak A bitvektornak annyi eleme van, ahány sora van a táblának A bitvektor j-ik komponense 1, ha a j-ik rekordban ez az értéke szerepel az indexelt oszlopban, egyébként 0. Jól használható AND, OR, COUNT, GROUP BY számítására Az alap tábla Index a Region oszlopra Index a Type oszlopra Cust Region Type C1 Asia Retail C2 Europe Dealer C3 Asia Dealer C4 America Retail C5 Europe Dealer RecID Asia Europe Am erica RecID Retail Dealer Adattárházak 58

59 Az OLAP adatok indexelése: összekapcsolási index (Join Index) A join index: JI(R-id, S-id) formájú, ahol R (R-id, ) >< S (S-id, ) A join index párok formájában materializálja az összekapcsolható sorokat, ezzel gyorssá teszi az összekapcsolási mőveletet Az adattárház csillagsémájában a dimenziótáblák rekordjait kell a ténytábla rekordjaihoz kapcsolni, így erre nagyon jól használható. Például a Sales ténytáblához kapcsoljuk a location és az item dimenziókat A city join index azokat a párokat tartalmazza, hogy egy adott városban milyen azonosítóval rendelkezı eladások történtek Lehetne hármasokat is tárolni (a három tábla összekapcsolható rekordazonosítóit) Adattárházak 59

60 Az OLAP lekérdezések hatékony végrehajtása Határozzuk meg, milyen mőveleteket kellene elvégezni a rendelkezésre álló kuboidokon A lefúrás, felgörgetés, stb. mőveleteket írjuk át SQL-be, például a kockázás mővelet kiválasztással és vetítéssel fejezhetı ki. Határozzuk meg, mely materializált kuboidokból számolható ki az OLAP mővelet. Például adott a következı kocka és a hierarchiák a szokásosak. define cube sales_star [time, item, branch, location]:dollars_sold = sum(sales_in_dollars), avg_sales = avg(sales_in_dollars), units_sold = count(*) define dimension time as (time_key, day, day_of_week, month, quarter, year) define dimension item as (item_key, item_name, brand, type, supplier_type) define dimension branch as (branch_key, branch_name, branch_type) define dimension location as (location_key, street, city, province_or_state, country) Egy olyan lekérdezés kell kiszámolni, amely a {brand, province_or_state} értékekre vonatkozik a year = 2004 feltétellel. A következı 4 materializált nézet közül melyiket használhatjuk? 1) {year, item_name, city}2) {year, brand, country}3) {year, brand, province_or_state} 4) {item_name, province_or_state}, ahol year = 2004 A 2. nem jó, mert a country adatokban elveszítjük a finomabb province_or_state értékeket. A többi jó. Az 1. választása a sok city érték miatt kevésbé hatékony. Ha sok item tartozik ugyanahhoz a brand értékhez, akkor 4. se elég hatékony. A 3. a legjobb. (Indexek esetén más lehet a helyzet!) Adattárházak 60

61 Adattárházak Adattárház: alapfogalmak Adattárház modellek: adatkockák és OLAP Adattárház architektúrák Adattárházak megvalósítása Adatok általánosítása és fogalmi leírások Az adattárháztól az adatbányászatig Adattárházak 61

62 What is Concept Description? Descriptive vs. predictive data mining Descriptive mining: describes concepts or task-relevant data sets in concise, summarative, informative, discriminative forms Predictive mining: Based on data and analysis, constructs models for the database, and predicts the trend and properties of unknown data Concept description: Characterization: provides a concise and succinct summarization of the given collection of data Comparison: provides descriptions comparing two or more collections of data Adattárházak 62

63 Data Generalization and Summarizationbased Characterization Data generalization A process which abstracts a large set of task-relevant data in a database from a low conceptual levels to higher ones. Approaches: Data cube approach(olap approach) Attribute-oriented induction approach Conceptual levels Adattárházak 63

64 Attribute-Oriented Induction Proposed in 1989 (KDD 89 workshop) Not confined to categorical data nor particular measures How it is done? Collect the task-relevant data (initial relation) using a relational database query Perform generalization by attribute removal or attribute generalization Apply aggregation by merging identical, generalized tuples and accumulating their respective counts Interactive presentation with users Adattárházak 64

65 Basic Principles of Attribute-Oriented Induction Data focusing: task-relevant data, including dimensions, and the result is the initial relation Attribute-removal: remove attribute A if there is a large set of distinct values for A but (1) there is no generalization operator on A, or (2) A s higher level concepts are expressed in terms of other attributes Attribute-generalization: If there is a large set of distinct values for A, and there exists a set of generalization operators on A, then select an operator and generalize A Attribute-threshold control: typical 2-8, specified/default Generalized relation threshold control: control the final relation/rule size Adattárházak 65

66 Attribute-Oriented Induction: Basic Algorithm InitialRel: Query processing of task-relevant data, deriving the initial relation. PreGen: Based on the analysis of the number of distinct values in each attribute, determine generalization plan for each attribute: removal? or how high to generalize? PrimeGen: Based on the PreGen plan, perform generalization to the right level to derive a prime generalized relation, accumulating the counts. Presentation: User interaction: (1) adjust levels by drilling, (2) pivoting, (3) mapping into rules, cross tabs, visualization presentations. Adattárházak 66

67 Example DMQL: Describe general characteristics of graduate students in the Big-University database use Big_University_DB mine characteristics as Science_Students in relevance to name, gender, major, birth_place, birth_date, residence, phone#, gpa from student where status in graduate Corresponding SQL statement: Select name, gender, major, birth_place, birth_date, residence, phone#, gpa from student where status in { Msc, MBA, PhD } Adattárházak 67

68 Class Characterization: An Example Initial Relation Name Gender Major Birth-Place Birth_date Residence Phone # GPA Jim Woodman Scott Lachance Laura Lee Prime Generalized Relation M CS Vancouver,BC, Canada M CS Montreal, Que, Canada F Physics Removed Retained Sci,Eng, Bus Seattle, WA, USA Main St., Richmond st Ave., Richmond Austin Ave., Burnaby Country Age range City Removed Excl, VG,.. Gender Major Birth_region Age_range Residence GPA Count M Science Canada Richmond Very-good 16 F Science Foreign Burnaby Excellent 22 Gender Birth_Region Canada Foreign Total M F Total Adattárházak 68

69 Presentation of Generalized Results Generalized relation: Relations where some or all attributes are generalized, with counts or other aggregation values accumulated. Cross tabulation: Mapping results into cross tabulation form (similar to contingency tables). Visualization techniques: Pie charts, bar charts, curves, cubes, and other visual forms. Quantitative characteristic rules: Mapping generalized result into characteristic rules with quantitative information associated with it, e.g., grad ( x) male( x) birth _ region( x) = " Canada"[ t:53%] birth _ region( x) = " foreign"[ t:47%]. Adattárházak 69

70 Mining Class Comparisons Comparison: Comparing two or more classes Method: Partition the set of relevant data into the target class and the contrasting class(es) Generalize both classes to the same high level concepts Compare tuples with the same high level descriptions Present for every tuple its description and two measures support - distribution within single class comparison - distribution between classes Highlight the tuples with strong discriminant features Relevance Analysis: Find attributes (features) which best distinguish different classes Adattárházak 70

71 Quantitative Discriminant Rules Cj = target class q a = a generalized tuple covers some tuples of class but can also cover some tuples of contrasting class d-weight range: [0, 1] d weight = i= 1 quantitative discriminant rule form m count(q a count(q C a j ) C i ) X, target_class(x) condition(x) [d : d_weight] Adattárházak 71

72 Example: Quantitative Discriminant Rule Status Birth_country Age_range Gpa Count Graduate Canada Good 90 Undergraduate Canada Good 210 Count distribution between graduate and undergraduate students for a generalized tuple Quantitative discriminant rule X, graduate_ student( X) birth_ country( X) = " Canada" age_ range( X) = "25 30" gpa( X) = " good" [ d :30%] where 90/( ) = 30% Adattárházak 72

73 Class Description Quantitative characteristic rule X, target_class(x) necessary condition(x) [t : t_weight] Quantitative discriminant rule X, target_class(x) sufficient Quantitative description rule X, target_cla ss(x) condition(x) [d: d_weight] condition 1(X) [t : w 1,d : w 1]... conditionn(x) [t : w n,d : w n] necessary and sufficient Adattárházak 73

74 Example: Quantitative Description Rule Location/item TV Computer Both_items Count t-wt d-wt Count t-wt d-wt Count t-wt d-wt Europe 80 25% 40% % 30% % 32% N_Am % 60% % 70% % 68% Both_ regions % 100% % 100% % 100% Crosstab showing associated t-weight, d-weight values and total number (in thousands) of TVs and computers sold at AllElectronics in 1998 Quantitative description rule for target class Europe X,Europe(X) (item(x) = "TV")[t : 25%,d : 40%] (item(x) = "computer")[t : 75%,d :30%] Adattárházak 74

75 Concept Description vs. Cube-Based OLAP Similarity: Data generalization Presentation of data summarization at multiple levels of abstraction Interactive drilling, pivoting, slicing and dicing Differences: OLAP has systematic preprocessing, query independent, and can drill down to rather low level AOI has automated desired level allocation, and may perform dimension relevance analysis/ranking when there are many relevant dimensions Adattárházak 75

76 Chapter 3: Data Warehousing, Data Generalization, and On-line Analytical Processing Data warehouse: Basic concept Data warehouse modeling: Data cube and OLAP Data warehouse architecture Data warehouse implementation Data generalization and concept description From data warehousing to data mining Adattárházak 76

77 From On-Line Analytical Processing (OLAP) to On Line Analytical Mining (OLAM) Why online analytical mining? High quality of data in data warehouses DW contains integrated, consistent, cleaned data Available information processing structure surrounding data warehouses ODBC, OLEDB, Web accessing, service facilities, reporting and OLAP tools OLAP-based exploratory data analysis Mining with drilling, dicing, pivoting, etc. On-line selection of data mining functions Integration and swapping of multiple mining functions, algorithms, and tasks Adattárházak 77

78 Mining query An OLAM System Architecture OLAM Engine User GUI API Data Cube API Mining result OLAP Engine Layer4 User Interface Layer3 OLAP/OLAM MDDB Meta Data Layer2 MDDB Filtering&Integration Databases Database API Data cleaning Data integration Filtering Data Warehouse Layer1 Data Repository Adattárházak 78

79 Chapter 3: Data Warehousing, Data Generalization, and On-line Analytical Processing Data warehouse: Basic concept Data warehouse modeling: Data cube and OLAP Data warehouse architecture Data warehouse implementation Data generalization and concept description From data warehousing to data mining Summary Adattárházak 79

80 Summary: Data Generalization, Data Warehousing, and On-line Analytical Processing Data generalization: Attribute-oriented induction Data warehousing: A multi-dimensional model of a data warehouse Star schema, snowflake schema, fact constellations A data cube consists of dimensions & measures OLAP operations: drilling, rolling, slicing, dicing and pivoting Data warehouse architecture OLAP servers: ROLAP, MOLAP, HOLAP Efficient computation of data cubes Partial vs. full vs. no materialization Indexing OALP data: Bitmap index and join index OLAP query processing From OLAP to OLAM (on-line analytical mining) Adattárházak 80

81 References (I) S. Agarwal, R. Agrawal, P. M. Deshpande, A. Gupta, J. F. Naughton, R. Ramakrishnan, and S. Sarawagi. On the computation of multidimensional aggregates. VLDB 96 D. Agrawal, A. E. Abbadi, A. Singh, and T. Yurek. Efficient view maintenance in data warehouses. SIGMOD 97 R. Agrawal, A. Gupta, and S. Sarawagi. Modeling multidimensional databases. ICDE 97 S. Chaudhuri and U. Dayal. An overview of data warehousing and OLAP technology. ACM SIGMOD Record, 26:65-74, 1997 E. F. Codd, S. B. Codd, and C. T. Salley. Beyond decision support. Computer World, 27, July J. Gray, et al. Data cube: A relational aggregation operator generalizing group-by, cross-tab and sub-totals. Data Mining and Knowledge Discovery, 1:29-54, A. Gupta and I. S. Mumick. Materialized Views: Techniques, Implementations, and Applications. MIT Press, J. Han. Towards on-line analytical mining in large databases. ACM SIGMOD Record, 27:97-107, V. Harinarayan, A. Rajaraman, and J. D. Ullman. Implementing data cubes efficiently. SIGMOD 96 Adattárházak 81

82 References (II) C. Imhoff, N. Galemmo, and J. G. Geiger. Mastering Data Warehouse Design: Relational and Dimensional Techniques. John Wiley, 2003 W. H. Inmon. Building the Data Warehouse. John Wiley, 1996 R. Kimball and M. Ross. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. 2ed. John Wiley, 2002 P. O'Neil and D. Quass. Improved query performance with variant indexes. SIGMOD'97 Microsoft. OLEDB for OLAP programmer's reference version 1.0. In A. Shoshani. OLAP and statistical databases: Similarities and differences. PODS 00. S. Sarawagi and M. Stonebraker. Efficient organization of large multidimensional arrays. ICDE'94 OLAP council. MDAPI specification version 2.0. In E. Thomsen. OLAP Solutions: Building Multidimensional Information Systems. John Wiley, 1997 P. Valduriez. Join indices. ACM Trans. Database Systems, 12: , J. Widom. Research problems in data warehousing. CIKM 95. Adattárházak 82