Adattárházak Adattárház: alapfogalmak

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

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

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

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

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

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

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

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

Az OLTP és az OLAP közti különbségek
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

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

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

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

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

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

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

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

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

Adatkocka definiálása (BNF) DMQL-ben
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

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

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

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

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

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

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

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

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

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

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(), min_N() : n-ik legkisebb, standard_deviation() Holisztikus (teljes): nem korlátos számú argumentumú függvény például median(), mode(), rank() Adattárházak

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

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

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 Régió Ipar Régió Év Kategória Ország Negyedév Termék Város Hónap Hét Iroda Nap Termék Hónap Adattárházak

Az összesítéseket tartalmazó adatkocka
Éves TV eladás az USA-ban Dátum Termék Ország Termékre, dátumra, országra ÖSSZESEN  TV MP3 PC 1.n.é. 2. n.é. 3. n.é. 4. n.é. U.S.A Kanada Mexico Adattárházak

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

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

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

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

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

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

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

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

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 termékcsoport kamion negyedév márka Idő Termék év nap cikk értékesítő város ország karácsonyi kerület régió téli osztály Minden kör egy lábnyom (footprint) Hely Akciók Szervezet Adattárházak

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

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

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

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

Adattárház építése 1. Magas szintű szervezeti adatmodell definiálása
4. Többrétegű adattárház architektúra 3. Osztott adatpiacok építése 2. Vállalati adattárház építése 2. Adatpiac é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

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

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

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

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

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? 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

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) FROM SALES CUBE BY item, city, year Mindez az alábbi Group-By –ok képzését jelenti (date, product, customer), (date,product),(date, customer), (product, customer), (date), (product), (customer) () (item) (city) () (year) (city, item) (city, year) (item, year) (city, item, year) Adattárházak

A jéghegy kocka Motiváció
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

A jéghegy kocka Az R adatbázis A jéghegy kuboidjai
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

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 Adattárházak

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

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

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

Data Generalization and Summarization-based Characterization
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 1 2 3 4 Conceptual levels 5 Adattárházak

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

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

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

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 where status in {“Msc”, “MBA”, “PhD” } Adattárházak

Class Characterization: An Example
Initial Relation Prime Generalized Relation Adattárházak

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., Adattárházak

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

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 range: [0, 1] quantitative discriminant rule form Adattárházak

Example: Quantitative Discriminant Rule
Count distribution between graduate and undergraduate students for a generalized tuple Quantitative discriminant rule where 90/( ) = 30% Adattárházak

Class Description Quantitative characteristic rule necessary
Quantitative discriminant rule sufficient Quantitative description rule necessary and sufficient Adattárházak

Example: Quantitative Description Rule
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 Adattárházak

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

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

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

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 Database API Filtering&Integration Filtering Layer1 Data Repository Data cleaning Data Warehouse Databases Data integration Adattárházak

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

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

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

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: , 1987. J. Widom. Research problems in data warehousing. CIKM’95. Adattárházak

Adattárházak Adattárház: alapfogalmak

Hasonló előadás

Az előadások a következő témára: "Adattárházak Adattárház: alapfogalmak"— Előadás másolata:

Hasonló előadás

Projectumról

Visszajelzés

Bejelentkezés

A társadalmi hálózaton keresztül belépni:

Adattárházak Adattárház: alapfogalmak

Hasonló előadás

Az előadások a következő témára: "Adattárházak Adattárház: alapfogalmak"— Előadás másolata:

Hasonló előadás

Projectumról

Visszajelzés