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
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
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
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: 10000 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
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
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
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
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
Az OLTP és az OLAP közti különbségek OLTP
OLAP
a felhasználók
ügyfelek, adminisztrátorok, programozók
adatelemzı tudásmunkások
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
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
Miért különítjük el az adattárházat?
Nagy teljesítmény akarunk elérni mindkét rendszerben
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:
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
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
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
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
Az adatkocka: a kuboidok hálója összes (all) idı
cikk
idı,hely idı,cikk
0-D (apex) kuboid
hely
szállító
cikk,hely idı,szállító
1-D kuboidok hely,szállító
2-D kuboidok cikk,szállító
idı,hely,szállító
3-D kuboidok idı,cikk,hely
idı,cikk,szállító
cikk,hely,szállító
4-D (alap) kuboid idı, cikk, hely, szállító Adattárházak
13
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
Csillagséma time
item
time_key day day_of_the_week month quarter year
Sales ténytábla time_key item_key
item_key item_name brand type supplier_type
branch_key location
branch
location_key
branch_key branch_name branch_type
units_sold dollars_sold avg_sales
location_key street city state_or_province country
Mértékek Adattárházak
15
Hópehelyséma time time_key day day_of_the_week month quarter year
item Sales ténytábla time_key item_key
item_key item_name brand type supplier_key
supplier supplier_key supplier_type
branch_key location
branch
location_key
branch_key branch_name branch_type
units_sold dollars_sold avg_sales
Mértékek Adattárházak
location_key street city_key
city city_key city state_or_province country 16
Galaxisséma ( 2 ténytáblával) time time_key day day_of_the_week month quarter year
item Sales ténytábla time_key
item_key item_name brand type supplier_type
item_key
location_key
branch_key branch_name branch_type
units_sold dollars_sold avg_sales
Mértékek
Adattárházak
time_key item_key shipper_key from_location
branch_key branch
Shipping ténytábla
location
to_location
location_key street city province_or_state country
dollars_cost units_shipped shipper shipper_key shipper_name location_key shipper_type
17
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
Adatkocka definiálása (BNF) DMQLben
Kocka (ténytábla) definiálása define cube
[]: <mérték_lista> Dimenziótáblák definiálása define dimension as () Közös dimenziótáblák definiálása ha már egy kockában definiáltuk a dimenziót define dimension as in cube Adattárházak
19
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
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
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
Adatkockák az Oracle-ben
Adattárházak
23
Dimenzió készítése Oracle-ben
Adattárházak
24
Szintek és hierarchiák készítése Oracle-ben
Adattárházak
25
Attribútumok készítése Oracle-ben
Adattárházak
26
Kocka készítése Oracle-ben
Adattárházak
27
A kocka mértékeinek megadása Oracle-ben
Adattárházak
28
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)
Algebrai: ha egy N változós algebrai függvénybe disztributív függvényeket helyettesítünk
ilyen például a count(), sum(), min(), max()
ilyen például avg() = sum()/count(),
min_N() : n-ik legkisebb,
például median(), mode(), rank()
1 n 1 n 2 1 n 2 2 s = (xi − x) = [∑ xi − (∑ xi ) ] ∑ standard_deviation() n −1 i=1 n −1 i=1 n i=1 Holisztikus (teljes): nem korlátos számú argumentumú függvény 2
Adattárházak
29
Egy fogalmi hierarchia a HELY dimenzióban bármi (all)
összes - bármi (all) Europe
régió
ország
város iroda
Germany
Frankfurt
...
...
...
Spain
North_America
Canada
Vancouver ... L. Chan Adattárházak
...
...
Mexico
Toronto
M. Wind 30
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
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
Kategória Ország Negyedév
Termék
Termék
Város Iroda
Hónap Hét Nap
Hónap Adattárházak
32
Az összesítéseket tartalmazó adatkocka Dátum
2. n.é. 3. n.é.
4. n.é.
Σ
U.S.A
Σ
Kanada Mexico
Ország
TV PC MP3
1.n.é.
Éves TV eladás az USA-ban
Σ
Adattárházak
33
A kockának megfelelı kuboidok
all 0-D (apex) kuboid termék
termék,dátum
dátum
ország
termék,ország
1-D kuboidok dátum, ország
2-D kuboidok 3-D (alap) kuboid termék, dátum, ország
Adattárházak
34
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: ÉszakAmerika, szabadtéri, olcsó termék: legfeljebb 20000 az ára Adattárházak
35
Tipikus OLAP mőveletek
Felgörgetés - Roll up (drill-up): összesítjük (pl. összegezzük) az adatokat
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):
a hierarchián feljebb lépve vagy a dimenziót elhagyva
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
Példa az OLAP mőveletekre: felgörgetés (Roll-up)
A városokat összesítjük az országokban
Adattárházak
37
Példa az OLAP mőveletekre: lefúrás (Drill-down)
Kibontjuk a negyedéveket hónapokra
Adattárházak
38
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
Példa az OLAP mőveletekre: szeletelés (Slice) Az elsı negyedév szerinti kétdimenziós szeletet vesszük
Adattárházak
40
Példa az OLAP mőveletekre: forgatás (Pivot)
A hely és termék tengelyeket felcseréljük
Adattárházak
41
A dimenziók fogalmi hierarchiáinak reprezentálása csillagháló (Star-Net) modellben Rendelések
Szállítás
Vásárló szerzıdések légi rendelések negyedév
kamion
termékcsoport márka
Idı
Termék év
nap
ország
város
cikk értékesítı karácsonyi kerület
régió Hely
téli
Minden kör egy lábnyom (footprint)
Akciók Adattárházak
osztály Szervezet 42
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
Adattárház tervezése
Négyféle szempont az adattárház tervezéséhez
Fentrıl le
Adatforrás
mit tárolunk a mőködési rendszereinkben
Adattárház
az adattárházhoz szükséges lényeges információ kiválasztása (mire van és mire lehet majd szükség)
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
Az adattárház tervezési folyamata
Fentrıl le, vagy lentrıl fel, vagy kombinálva
Lentrıl fel (Bottom-up): Próbálgatunk, prototípusokat adunk (gyors)
Szoftvertervezési szempontból
Fentrıl le (Top-down): Gondosan, fokozatosan részletezve mindent megtervezünk (idıigényes)
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
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 Adattárházak
OLAP motor Kliens eszközök 46
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
Adattárház építése 4. Többrétegő adattárház architektúra
3. Osztott adatpiacok építése
2. Adatpiac építése
2. Vállalati adattárház építése
2. Adatpiac é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
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
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
Mőködési metaadatok
sémák, nézetek, dimenziók, hierarchiák, számolt adatok definíciói, adatpiacok elérési helye és tartalma 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
OLAP szerver architektúrák
Relációs OLAP (ROLAP)
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)
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 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
Adattárházak felhasználása
Felhasználási területek
Alapinformáció szolgáltatása
Elemzések
lekérdezések, alapvetı statisztikai elemzések, jelentések, (táblák, kereszttáblák, diagramok, grafikonok) 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
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
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 Li (+1 az ANY miatt) szint van egy dimenzióban? n
T = ∏ ( L i + 1) i=1
Az adatkockát érdemes materializálni
teljes materializálás: összes kuboidot (2n 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
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 (city, item) (city, year)(item, year)
CUBE BY item, city, year Mindez az alábbi Group-By –ok képzését jelenti
(city, item, year)
(date, product, customer), (date,product),(date, customer), (product, customer), (date), (product), (customer) () Adattárházak
55
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 HAVING COUNT(*) >= minsup
Motiváció Á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
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 23 34 45 56 67 78 89 90 Adattárházak
57
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
Cust C1 C2 C3 C4 C5
Region Asia Europe Asia America Europe
Index a Region oszlopra
Index a Type oszlopra
Type RecID Asia Europe Am erica RecID Retail Dealer 1 1 0 1 1 0 0 Retail 2 0 1 0 1 0 Dealer 2 3 0 1 1 0 0 Dealer 3 4 1 0 4 0 0 1 Retail 5 0 1 0 1 0 Dealer 5 Adattárházak
58
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
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
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
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
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. 1 2 3 4
Conceptual levels 5
Approaches:
Data cube approach(OLAP approach)
Attribute-oriented induction approach Adattárházak
63
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
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
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
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
Class Characterization: An Example Name
Gender
Jim Initial Woodman Relation Scott
M
Major
Vancouver,BC, 8-12-76 Canada CS Montreal, Que, 28-7-75 Canada Physics Seattle, WA, USA 25-8-70 … … …
M F …
Removed
Retained
Sci,Eng, Bus
Gender Major M F …
Birth_date
CS
Lachance Laura Lee …
Prime Generalized Relation
Birth-Place
Science Science …
Country
Age range
Residence
Phone #
GPA
3511 Main St., Richmond 345 1st Ave., Richmond
687-4598
3.67
253-9106
3.70
125 Austin Ave., Burnaby …
420-5232 …
3.83 …
City
Removed
Excl, VG,..
Birth_region
Age_range
Residence
GPA
Canada Foreign …
20-25 25-30 …
Richmond Burnaby …
Very-good Excellent …
Count 16 22 …
Birth_Region Canada
Foreign
Total
Gender M
16
14
30
F
10
22
32
Total
26
36
62
Adattárházak
68
Presentation of Generalized Results
Generalized relation:
Cross tabulation:
Relations where some or all attributes are generalized, with counts or other aggregation values accumulated. 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
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
Quantitative Discriminant Rules
Cj = target class qa = a generalized tuple covers some tuples of class but can also cover some tuples of contrasting class d-weight count(q a ∈ C j ) range: [0, 1] d − weight = m
∑ count(q
a
∈ Ci )
i =1
quantitative discriminant rule form ∀ X, target_cla ss(X) ⇐ condition( X) [d : d_weight] Adattárházak
71
Example: Quantitative Discriminant Rule Status
Birth_country
Age_range
Gpa
Count
Graduate
Canada
25-30
Good
90
Undergraduate
Canada
25-30
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/(90 + 210) = 30%
Adattárházak
72
Class Description
Quantitative characteristic rule ∀ X, target_class(X) ⇒ condition(X) [t : t_weight]
necessary Quantitative discriminant rule
∀ X, target_cla ss(X) ⇐ condition( X) [d : d_weight]
sufficient Quantitative description rule
∀ X, target_cla ss(X) ⇔ condition 1(X) [t : w1, d : w ′1] ∨ ... ∨ condition n(X) [t : wn, d : w ′n]
necessary and sufficient Adattárházak
73
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%
240
75%
30%
320
100%
32%
N_Am
120
17.65%
60%
560
82.35%
70%
680
100%
68%
Both_ regions
200
20%
100%
800
80%
100%
1000
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
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
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
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
An OLAM System Architecture Mining query
Mining result
Layer4 User Interface
User GUI API
OLAM Engine
OLAP Engine
Layer3 OLAP/OLAM
Data Cube API Layer2
MDDB
MDDB Meta Data
Filtering&Integration
Database API
Filtering
Layer1 Data cleaning
Databases
Data Data integration Warehouse Adattárházak
Data Repository
78
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
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
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 1993. 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, 1997. A. Gupta and I. S. Mumick. Materialized Views: Techniques, Implementations, and Applications. MIT Press, 1999. J. Han. Towards on-line analytical mining in large databases. ACM SIGMOD Record, 27:97-107, 1998. V. Harinarayan, A. Rajaraman, and J. D. Ullman. Implementing data cubes efficiently. SIGMOD’96 Adattárházak
81
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 http://www.microsoft.com/data/oledb/olap, 1998 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 http://www.olapcouncil.org/research/apily.htm, 1998 E. Thomsen. OLAP Solutions: Building Multidimensional Information Systems. John Wiley, 1997
P. Valduriez. Join indices. ACM Trans. Database Systems, 12:218-246, 1987.
J. Widom. Research problems in data warehousing. CIKM’95. Adattárházak
82
