On-Line Analytic Processing Analitikus adatfeldolgozás Warehousing Data Cubes Data Mining Adattárház Adatkocka Adatbányászat 1
Overview u Traditional database systems are tuned to many, small, simple queries. u Some new applications use fewer, more timeconsuming, complex queries. u New architectures have been developed to handle complex “analytic” queries efficiently. u A hagyományos adatbázisokat sok, apró, egyszerű lekérdezésre hangolták u A jelenlegi alkalmazások kevesebb, de idő igényesebb, bonyolultabb lekérdezéseket használnak u Ezért modernebb adatarchitektúrákat fejlesztettek ki azért, hogy a bonyolultabb „analitikus”, elemző jellegű lekérdezéseket kezelni tudják 2
The Data Warehouse Adattárház u The most common form of data integration. w Copy sources into a single DB (warehouse) and try to keep it up-to -date. w Usual method: periodic reconstruction of the warehouse, perhaps overnight. w Frequently essential for analytic queries. u Jelenleg ez az egyik legelterjedtebb formája az adatintegrációnak. w Egyetlen egy közös adatbázisba másolják (adattárház) az adatokat és napra készen tartják. w Módszere: periodikus aktualizálás, gyakran éjszaka. w Gyakran az analitikus lekérdezések végett hozzák létre. 3
OLTP u Most database operations involve On-Line Transaction Processing (OLTP). w Short, simple, frequent queries and/or modifications, each involving a small number of tuples. w Examples: Answering queries from a Web interface, sales at cash registers, selling airline tickets. u Adatbázisok tipikusan online tranzakció feldolgozást végeznek (OLTP). w Rövid, egyszerű, gyakran feltett kérdések, mindegyik viszonylag kevés sort ad vissza válaszként. w Pl. : Web felületen keresztüli lekérdezések és válaszok, pénztárgépnél vásárlás, rep. jegy értékesítés 4
OLAP u Of increasing importance are On-Line Analytic Processing (OLAP) queries. w Few, but complex queries --- may run for hours. w Queries do not depend on having an absolutely up-to-date database. u Sometimes called Data Mining. u Növekvő jelentőségű az OLAP jellegű lekérdezések. w Kisebb számú, de összetett , amelyek órákig is futhatnak. w A lekérdezések nem igénylik az abszolút időben pontos adatbázist. u Korábban ezt nevezték adatbányászatnak. 5
OLAP Examples Példák 1. 2. Amazon analyzes purchases by its customers to come up with an individual screen with products of likely interest to the customer. Analysts at Wal-Mart look for items with increasing sales in some region. 1. Amazon elemzi vásárlói viselkedését azért, hogy olyan képernyő tartalmat jelenítsen meg, amely valószínűleg érdekli a vásárlót. 2. Wal-Mart-ot az érdekli, hogy melyik régióban melyik termék értékesítése növekszik 6
Common Architecture Tipikus architektúra megoldások u. Az áruházláncok u. Databases at store egyes áruházai OLTP branches handle szinten dolgoznak. OLTP. A helyi adatbázisokat u. Local store databases uéjszakánként feltöltik copied to a central a központi warehouse overnight. adattárházba. u. Analysts use the u. Az adatelemzők az warehouse for OLAP. adattárházat OLAP elemzésekre használják fel. 7
Star Schemas Csillag séma u A star schema is a common organization for data at a warehouse. It consists of: 1. Fact table : a very large accumulation of facts such as sales. 2. w Often “insert-only. ” Dimension tables : smaller, generally static information about the entities involved in the facts. u Csillag séma az adattárházak megszokott adatszerkezete. A következőkből áll: 1. • 2. Tény tábla: olyan adatok kumulált tömege mint pl. az értékesítési adatok. Általában csak „beillesztés” -re állított tábla. Dimenzió táblák: kisebb, általában statikus információkat tartalmaznak azokról az entitásokról, amelyekről tényeket tárolunk. 8
Example: Star Schema Példa csillag sémára u Suppose we want to record in a warehouse information about every beer sale: the bar, the brand of beer, the drinker who bought the beer, the day, the time, and the price charged. u The fact table is a relation: Sales(bar, beer, drinker, day, time, price) u Tegyük fel, hogy az adattárházban fel akarunk jegyezni minden sör értékesítési adatot: a kocsmát, a sörfajtáját, a sörbarátot, a napot, időpontot és fizetett árat. u A ténytábla egy olyan reláció lesz: Sales(bar, beer, drinker, day, time, price) 9
Example, Continued Példa folytatás u. The dimension tables include information about the bar, beer, and drinker “dimensions”: u. Bars(bar, addr, license) Beers(beer, manf) Drinkers(drinker, addr , phone) u. A dimenzió táblák a kocsma, a sör és a sörbarát (alkesz) adatait tartalmazzák 10
Dimensions and Dependent Attributes Dimenziók és a függő attribútumok u Two classes of facttable attributes: 1. Dimension attributes : the key of a dimension table. 2. Dependent attributes : a value determined by the dimension attributes of the tuple. u A ténytáblák attribútumainak két osztálya: 1. Dimenzió attribútumok: A dimenzió tábla kulcsa. 2. A függő attribútum: A sorban a dimenzió attribútumok által meghatározott értékek 11
Example: Dependent Attribute Példa függő attribútumok uprice is the dependent attribute of our example Sales relation. u. It is determined by the combination of dimension attributes: bar, beer, drinker, and the time (combination of day and time attributes). u Az ár függő attribútum az Értékesítés relációban u Amelyet a dimenzió attribútumok kombinációja határoz meg: a kocsma, a sör és a sörbarát valamint az időpont ( a nap és az idő attribútumok kombinációja) 12
Approaches to Building Warehouses Adattárház készítési módozatok 1. ROLAP = “relational OLAP”: Tune a relational DBMS to support star schemas. 2. MOLAP = “multidimensional OLAP”: Use a specialized DBMS with a model such as the “data cube. ” 1. ROLAP = relációs OLAP. Relációs adatbáziskezelő rendszer olyan hangolása, amely a csillag sémát támogatja. 2. MOLAP = többdimenziós OLAP: specializált adatbáziskezelő használata, amely pl. az adatkocka adatszerkezetet támogatja. 13
ROLAP Techniques ROLAP technikák 1. 2. Bitmap indexes : For each key value of a dimension table (e. g. , each beer for relation Beers) create a bitvector telling which tuples of the fact table have that value. Materialized views : Store the answers to several useful queries (views) in the warehouse itself. 1. 2. Bitmap indexek: a dimenzió táblák mindegyik kulcsértékére (pl. minden sörfajtára a Sör relációban) egy bit vektor létrehozása, amely megmondja, hogy mely sorok tartalmazzák ezt az értéket. Materializált nézetek: az olyan nézeteket, amelyek több lekérdezés megválaszolásához hasznosak magában az adattárházban eltárolják. 14
Typical OLAP Queries Tipikus OLAP lekérdezések u Often, OLAP queries begin with a “star join”: the natural join of the fact table with all or most of the dimension tables. u Az OLAP lekérdezések gyakran egy csillag összekapcsolással kezdődnek: a ténytábla és a dimenzió táblák természetes összekapcsolásával. SELECT * FROM Sales, Bars, Beers, Drinkers WHERE Sales. bar = Bars. bar AND Sales. beer = Beers. beer AND Sales. drinker = Drinkers. drinker; 15
Typical OLAP Queries --- 2 Tipikus OLAP lekérdezések u The typical OLAP query will: 1. 2. 3. 4. Start with a star join. Select for interesting tuples, based on dimension data. Group by one or more dimensions. Aggregate certain attributes of the result. u Tipikus OLAP lekérdezések: 1. Egy csillag séma összekapcsolással kezdődik. 2. Leválogatják a fontos sorokat, a dimenzió táblák adatai alapján 3. Egy vagy több dimenzió alapján csoportosítjuk. 4. Az eredmény egyes attribútumait összegezzük 16
Example: OLAP Query u For each bar in Palo Alto, find the total sale of each beer manufactured by Anheuser-Busch. 1. Filter: addr = “Palo Alto” and manf = “Anheuser-Busch”. 2. Grouping: by bar and beer. 3. Aggregation: Sum of price. u Palo Alto mindegyik kocsmájára keressük meg az Anheuser-Busch által gyártott mindegyik sörre az összes eladás értékét 1. Szűrő: addr = “Palo Alto” and manf = “Anheuser-Busch”. 2. Csoportosítás: kocsma és sör. 3. Összesítés: az ár (price) összege 17
Example: In SQL Példa: SQL-ben SELECT bar, beer, SUM(price) FROM Sales NATURAL JOIN Bars NATURAL JOIN Beers WHERE addr = ’Palo Alto’ AND manf = ’Anheuser-Busch’ GROUP BY bar, beer; 18
Using Materialized Views Materializált nézetek használata u A direct execution of this query from Sales and the dimension tables could take too long. u If we create a materialized view that contains enough information, we may be able to answer our query much faster. u Az előbbi példa lekérdezés közvetlen végrehajtása a Sales és a dimenzió táblák segítségével túl hosszú ideig tartana. u Ha egy materializált nézetet hozunk létre, amely elegendő információt tartalmaz sokkal gyorsabban lehetne megválaszolni 19
Example: Materialized View Példa: Materializált nézetek használata u u Which views could help with our query? Key issues: 1. 2. 3. 4. It must join Sales, Bars, and Beers, at least. It must group by at least bar and beer. It must not select out Palo-Alto bars or Anheuser-Busch beers. It must not project out addr or manf. u Mely nézetek segítenék a lekérdezést: u Kulcs kérdések: 1. 2. 3. 4. Össze kell kapcsolni minimum a Sales, Bars, és Beers táblákat. Csoportosítani kell legalább bar, és beer attr. szerint. sem a Palo-Alto-i kocsmákat (bar) sem Anheuser-Busch söreit (beer) Nem szabad kihagyni. Nem szabd lehagyni az eredményből, vetítéssel, sem az addr (cím) sem manf (gyártó) attribútumokat. 20
Example --- Continued folytatás Itt Here is a materialized view that a materializált nézet: A funkcionális függések miatt nincs igazi could help: csoportosítás CREATE VIEW BABMS(bar, addr, beer, manf, sales) AS SELECT bar, addr, beer, manf, SUM(price) sales FROM Sales NATURAL JOIN Bars NATURAL JOIN Beers GROUP BY bar, addr, beer, manf; Since bar -> addr and beer -> manf, there is no real grouping. We need addr and manf in the SELECT. 21
Example --- Concluded Lezárás Here’s our query using the materialized view BABMS: BABMS materializált nézet lekérdezése: SELECT bar, beer, sales FROM BABMS WHERE addr = ’Palo Alto’ AND manf = ’Anheuser-Busch’; 22
MOLAP and Data Cubes MOLAP és adatkockák u Keys of dimension tables are the dimensions of a hypercube. u A dimenzió táblák kulcsai a hiper-kocka dimenziói: u Dependent attributes (e. g. , price) appear at the points of the cube. u A függő attribútumok (pl. price, ár) a kocka „belső” pontjaiban jelennek meg w Example: for the Sales data, the four dimensions are bars, beers, drinkers, and time. w Példa: Sales (értékesítés) adataira, négy dimenzió: bars, beers, drinkers, és time. 23
Marginals Kocka oldalai, szélei u. Az adatkocka u. The data cube also tartalmazhat includes aggregation (tipikusan SUM) a (typically SUM) along kocka oldalai the margins of the szerint cube. u. The marginals include u A kocka szélei tartalmazhatnak aggregations over összesítést egy one dimension, two dimenzióban, két dimensions, … dimenzióban, stb. 24
Example: Marginals Példa u A példánk 4 –dimenziós u Our 4 -dimensional adatkockája tartalmazza Sales cube includes the az árak (price) összegét, sum of price over each minden kocsmára, sörre, bar, each beer, each alkeszre és idő egységre drinker, and each time (pl. napra) unit (perhaps days). u De tartalmazhatná az u It would also have the értékesítési adatokat, az árak (price) összegét sum of price over all minden kocsma-sör bar-beer pairs, all barpárosra, minden kocsmadrinker-day triples, … alkesz-nap hármasra, stb. 25
Structure of the Cube Az adatkocka szerkezete u Think of each dimension as having an additional value *. u A point with one or more *’s in its coordinates aggregates over the dimensions with the *’s. u Example: Sales(“Joe’s Bar”, *, “Bud”, *, sales) holds the sum over all drinkers and all time of the Bud consumed at Joe’s. Sale(bar, addr, beer, manf, sales) u Képzeljük azt, hogy mindegyik dimenzió tartalmaz egy további értéket (*) [A szokásos vélelmezett „tetszőleges” érték értelmezéssel]. u Egy olyan pont, amelynek koordinátái között egy vagy több „*” szerepel azt jelenti, hogy azok fölött a dimenziók fölött, amelyeknek az értéke ebben a sorban (adatkocka pontban) „*” összegzést hajt végre. u Pl. Sales(“Joe’s Bar”, *, “Bud”, *, sales) 26
27
Drill-Down Lefúrás u. Drill-down = “deaggregate” = break an aggregate into its constituents. u. Example: having determined that Joe’s Bar sells very few Anheuser-Busch beers, break down his sales by particular A. -B. beer. u Lefúrás= „finomabb összegzés” = az összegzéseket finomabb alkotórészeire bontjuk. u Példa: Ha kiderült, hogy Joe kocsmája nagyon kevés Anheuser-Busch sört adott el. u Bontsuk fel az értékesítési adatokat az egyes Anheuser-Busch sörfajták szerint. 28
Roll-Up Felgörgetés (felösszegzés) u Roll-up = aggregate along one or more dimensions. u Example: given a table of how much Bud each drinker consumes at each bar, roll it up into a table giving total amount of Bud consumed for each drinker. u Felgörgetés = összegzés egy vagy több dimenzió mentén u Példa: legyen egy olyan táblánk, amelyben minden alkeszről azt tároljuk, hogy mennyi Bud sört fogyasztott el az egyes kocsmákban, görgessük fel ezt egy olyan táblába, amelyik megadja minden alkeszre azt, hogy mennyi Bud sört fogyasztott el 29
Materialized Data-Cube Views Materializált adatkocka nézetek u. Data cubes invite materialized views that are aggregations in one or more dimensions. u. Dimensions may not be completely aggregated --- an option is to group by an attribute of the dimension table. u Adatkockák létrehozására olyan materializált nézeteket lehet használni, amelyek egy vagy több dimenzióban összegzéseket tartalmaznak. u Az egyes dimenziókat nem kell teljes mértékben összegezni – az egyik lehetőség, hogy a dimenzió tábla bizonyos attribútumai szerint összegzünk. 30
Example Példa u A materialized view for our Sales data cube might: 1. 2. 3. 4. Aggregate by drinker completely. Not aggregate at all by beer. Aggregate by time according to the week. Aggregate according to the city of the bar. u Az értékesítés materializált nézete (Sales), adatkocka a következő lehet: u Alkeszek alapján teljes összegzés. u A sör fajták alapján nincs összegzés u Idő tekintetében hetek szerinti összegzés u A kocsmák városa szerinti összegzés. 31
Data Mining Adatbányászat u Data mining is a popular term for queries that summarize big data sets in useful ways. u Examples: u Az adatbányászat az olyan adatfeldolgozásokat jelenti, amelyek nagy adathalmazokat összegeznek valamilyen szempontból hasznos módon. u Példák: 1. Clustering all 1. Az összes Web lap Web pages by topic. klaszterezése témák 2. Finding szerint. characteristics of 2. A bankkártyák csalásra fraudulent credittörténő használatának card use. jellemzőinek feltárása 32
Market-Basket Data Bevásárló kosár u An important form of mining from relational data involves market baskets = sets of “items” that are purchased together as a customer leaves a store. u Summary of basket data is frequent itemsets = sets of items that often appear together in baskets. u A relációs adatforrásokból az egyik tipikus adatbányászati feladat a bevásárló kosár = olyan bevásárlási tételek listája, amiket egy fogyasztó megvásárolt. u A bevásárlási adatok egyik összegzése a gyakran előforduló tételhalmazok = olyant áru tételek, amelyek gyakran fordulnak elő együtt. 33
Example: Market Baskets Példa u If people often buy u. Ha valaki gyakran hamburger and vásárol hamburgert ketchup together, the és ketchup-ot együtt store can: 1. 2. Put hamburger and ketchup near each other and put potato chips between. Run a sale on hamburger and raise the price of ketchup. és szalma krumplit vesz még hozzá. u Akkor csináljunk egy árleszállítást a hamburgerre, viszont emeljük meg a ketchup árát. 34
Finding Frequent Pairs Gyakori párosítások feltárása u The simplest case is when we only want to find “frequent pairs” of items. u Assume data is in a relation Baskets(basket, item). u The support threshold s is the minimum number of baskets in which a pair appears before we are interested. u Az egyszerű eset, amikor csak a gyakori párosításokat akarjuk megtalálni. u Tegyük fel, hogy az adatok a Baskets(basket, item) relációban vannak. u Az s támogató küszöbérték az olyan bevásárló kosarak minimális száma, amelyben egyrészt a minket érdeklő termék párosítások jelennek meg, és másrészt ha ezt a küszöb értéket túllépi a bevásárló kosarak száma, akkor érdekesek lesznek számunkra. 35
Keressük azokat a bevásárló kosár párosokat, amelyek ugyanarra a kosárra vonatkoznak, de az árutételek különböznek SELECT b 1. item, b 2. item Az első tételnek meg FROM Baskets b 1, Baskets b 2 kell előznie a másikat azért, WHERE b 1. basket = b 2. basket hogy ne számoljuk kétszer ugyanazt AND b 1. item < b 2. item a párt. Frequent Pairs in SQL GROUP BY b 1. item, b 2. item HAVING COUNT(*) >= s; Throw away pairs of items that do not appear at least s times. Dobjuk el azokat a termékeket, amelyek nem jelennek meg legalább s-szer Hozzunk létre egy csoportot minden olyan pár termékre, amelyik legalább az egyik kosárban megjelenik Create a group for each pair of items 36 that appears in at least one basket.
A-Priori Trick --- 1 Trükk u Straightforward implementation involves a join of a huge Baskets relation with itself. u The a-priori algorithm speeds the query by recognizing that a pair of items {i, j } cannot have support s unless both {i } and {j } do. u Az egyszerű megvalósítást a Baskets reláció önmagával történő összekapcsolásával lehetne megoldani u Az a-priori algoritmus felgyorsítja a lekérdezést, a következőképpen, egy {i, j } csak akkor éri el a támogató küszöbértéket, s –t, ha mind {i } mind {j } vagyis mindketten elérik. 37
A-Priori only u Használjunk 2 materializált Trick --- egy u Use a materialized view to hold information about frequent items. nézetet a gyakori termékek nyilvántartására. INSERT INTO Baskets 1(basket, item) SELECT * FROM Baskets WHERE item IN ( Items that SELECT ITEM FROM Baskets appear in at least s baskets. GROUP BY item Termékek, amelyek legalább s kosárban HAVING COUNT(*) >= s megjelennek ); 38
A-Priori Algorithm A-Priori Algoritmus 1. 2. u u w Materialize the view Baskets 1. Run the obvious query, but on Baskets 1 instead of Baskets 1 is cheap, since it doesn’t involve a join. Baskets 1 probably has many fewer tuples than Baskets. Running time shrinks with the square of the number of tuples involved in the join. 1. Készítsünk egy Baskets 1 materializált nézetet. 2. A nyilvánvaló lekérdezést futtassuk a Baskets 1 -en, Baskets helyett. • • Baskets 1 lekérdezése olcsó, mivel nincs benne összekapcsolás Baskets 1 –nek kevesebb sora van (val. szeg) mint Baskets-nek • A futási idő az összekapcsolásban érintett sorok számának négyzetével arányosan csökken. 39
Example: A-Priori Példa u Suppose: 1. 2. 3. u u A supermarket sells 10, 000 items. The average basket has 10 items. The support threshold is 1% of the baskets. At most 1/10 of the items can be frequent. Probably, the minority of items in one basket are frequent -> factor 4 speedup. u Tegyük fel: 1. 2. 3. Egy szupermarket 10, 000 terméket árúsít. Az átlagos kosár tartalma 10 tétel. A támogatási küszöbérték kosarak számának 1%-a u Ezért legfeljebb a tételek 1/10 tekinthető gyakorinak. u Valószínűleg, egy kosárban a tételek kisebb része tekinthető gyakorinak –> 4 szere gyorsuláshoz vezet ez a feltételezés. 40
Скачать презентацию On-Line Analytic Processing Analitikus adatfeldolgozás Warehousing Data Cubes
28f058f7213d12e6bcd3b67ae3fc2302.ppt