On-Line Analytic Processing Analitikus adatfeldolgozás Warehousing Data Cubes Data Mining Adattárház Adatkocka Adatbányászat

Overview Traditional database systems are tuned to many, small, simple queries. Some new applications use fewer, more time-consuming, complex queries. New architectures have been developed to handle complex “analytic” queries efficiently. A hagyományos adatbázisokat sok, apró, egyszerű lekérdezésre hangolták A jelenlegi alkalmazások kevesebb, de idő ignyesebb, bonyolultabb lekérdezéseket használnak Ezért modernebb adatarchitektúrákat fejlesztettek ki azért, hogy a bonyolultabb „analitikus”, elemző jellegű lekérdezéseket kezelni tudják

The Data Warehouse Adattárház The most common form of data integration. Copy sources into a single DB (warehouse) and try to keep it up-to-date. Usual method: periodic reconstruction of the warehouse, perhaps overnight. Frequently essential for analytic queries. Jelenleg ez az egyik legelterjedtebb formája az adatintegrációnak. Egyetlen egy közös adatbázisba másolják (adattárház) az adatokat és napra készen tartják. Módszere: periodikus aktualizálás, gyakran éjszaka. Gyakran az analitikus lekérdezések végett hozzák létre.

OLTP Most database operations involve On-Line Transaction Processing (OLTP). Short, simple, frequent queries and/or modifications, each involving a small number of tuples. Examples: Answering queries from a Web interface, sales at cash registers, selling airline tickets. Adatbázisok tipikusan on-line tranzakció feldolgozást végeznek (OLTP). Rövid, egyszerű, gyakran feltett kérdések, mindegyik viszonylag kevés sort ad vissza válaszként. 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

OLAP Növekvő jelentőségű az OLAP jellegű lekérdezések. Of increasing importance are On-Line Analytic Processing (OLAP) queries. Few, but complex queries --- may run for hours. Queries do not depend on having an absolutely up-to-date database. Sometimes called Data Mining. Növekvő jelentőségű az OLAP jellegű lekérdezések. Kisebb számú, de összetett , amelyek órákig is futhatnak. A lekérdezések nem igénylik az abszolút időben pontos adatbázist. Korábban ezt nevezték adatbányászatnak.

OLAP Examples Példák 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. 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. Wal-Mart-ot az érdekli, hogy melyik régióban melyik termék értékesítése növekszik

Common Architecture Tipikus architektúra megoldások Databases at store branches handle OLTP. Local store databases copied to a central warehouse overnight. Analysts use the warehouse for OLAP. Az áruházláncok egyes áruházai OLTP szinten dolgoznak. A helyi adatbázisokat éjszakánként feltöltik a központi adattárházba. Az adatelemzők az adattárházat OLAP elemzésekre használják fel.

Star Schemas Csillag séma A star schema is a common organization for data at a warehouse. It consists of: Fact table : a very large accumulation of facts such as sales. Often “insert-only.” Dimension tables : smaller, generally static information about the entities involved in the facts. Csillag séma az adattárházak megszokott adatszerkezete. A következőkből áll: 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.

Example: Star Schema Példa csillag sémára 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. The fact table is a relation: Sales(bar, beer, drinker, day, time, price) 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. A ténytábla egy olyan reláció lesz: Sales(bar, beer, drinker, day, time, price)

Example, Continued Példa folytatás The dimension tables include information about the bar, beer, and drinker “dimensions”: Bars(bar, addr, license) Beers(beer, manf) Drinkers(drinker,addr, phone) A dimenzió táblák a kocsma, a sör és a sörbarát (alkesz) adatait tartalmazzák

Dimensions and Dependent Attributes Dimenziók és a függő attribútumok Two classes of fact-table attributes: Dimension attributes : the key of a dimension table. Dependent attributes : a value determined by the dimension attributes of the tuple. A ténytáblák attribútumainak két osztálya: Dimenzió attribútumok: A dimenzió tábla kulcsa. A függő attribútum: A sorban a dimenzió attribútumok által meghatározott értékek

Example: Dependent Attribute Példa függő attribútumok price is the dependent attribute of our example Sales relation. It is determined by the combination of dimension attributes: bar, beer, drinker, and the time (combination of day and time attributes). Az ár függő attribútum az Értékesítés relációban 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)

Approaches to Building Warehouses Adattárház készítési módozatok ROLAP = “relational OLAP”: Tune a relational DBMS to support star schemas. MOLAP = “multidimensional OLAP”: Use a specialized DBMS with a model such as the “data cube.” ROLAP = relációs OLAP. Relációs adatbáziskezelő rendszer olyan hangolása, amely a csillag sémát támogatja. MOLAP = többdimenziós OLAP: specializált adatbáziskezelő használata, amely pl. az adatkocka adatszerkezetet támogatja.

ROLAP Techniques ROLAP technikák Bitmap indexes : For each key value of a dimension table (e.g., each beer for relation Beers) create a bit-vector telling which tuples of the fact table have that value. Materialized views : Store the answers to several useful queries (views) in the warehouse itself. 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.

Typical OLAP Queries Tipikus OLAP lekérdezések Often, OLAP queries begin with a “star join”: the natural join of the fact table with all or most of the dimension tables. 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;

Typical OLAP Queries --- 2 Tipikus OLAP lekérdezések The typical OLAP query will: 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. Tipikus OLAP lekérdezések: Egy csillag séma összekapcsolással kezdődik. Leválogatják a fontos sorokat, a dimenzió táblák adatai alapján Egy vagy több dimenzió alapján csoportosítjuk. Az eredmény egyes attribútumait összegezzük

Example: OLAP Query For each bar in Palo Alto, find the total sale of each beer manufactured by Anheuser-Busch. Filter: addr = “Palo Alto” and manf = “Anheuser-Busch”. Grouping: by bar and beer. Aggregation: Sum of price. 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 Szűrő: addr = “Palo Alto” and manf = “Anheuser-Busch”. Csoportosítás: kocsma és sör. Összesítés: az ár (price) összege

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;

Using Materialized Views Materializált nézetek használata A direct execution of this query from Sales and the dimension tables could take too long. If we create a materialized view that contains enough information, we may be able to answer our query much faster. 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. Ha egy materializált nézetet hozunk létre, amely elegendő információt tartalmaz sokkal gyorsabban lehetne megválaszolni

Example: Materialized View Példa: Materializált nézetek használata Which views could help with our query? Key issues: 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. Mely nézetek segítenék a lekérdezést: Kulcs kérdések: Ö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.

Example --- Continued folytatás Here is a materialized view that could help: Itt a materializált nézet: A funkcionális függések miatt nincs igazi 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.

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’;

MOLAP and Data Cubes MOLAP és adatkockák Keys of dimension tables are the dimensions of a hypercube. Example: for the Sales data, the four dimensions are bars, beers, drinkers, and time. Dependent attributes (e.g., price) appear at the points of the cube. A dimenzió táblák kulcsai a hiper-kocka dimenziói: Példa: Sales (értékesítés) adataira, négy dimenzió: bars, beers, drinkers, és time. A függő attribútumok (pl. price, ár) a kocka „belső” pontjaiban jelennek meg

Marginals Kocka oldalai, szélei The data cube also includes aggregation (typically SUM) along the margins of the cube. The marginals include aggregations over one dimension, two dimensions,… Az adatkocka tartalmazhat (tipikusan SUM) a kocka oldalai szerint A kocka szélei tartalmazhatnak összesítést egy dimenzióban, két dimenzióban, stb.

Example: Marginals Példa Our 4-dimensional Sales cube includes the sum of price over each bar, each beer, each drinker, and each time unit (perhaps days). It would also have the sum of price over all bar-beer pairs, all bar-drinker-day triples,… A példánk 4 –dimenziós adatkockája tartalmazza az árak (price) összegét, minden kocsmára, sörre, alkeszre és idő egységre (pl. napra) De tartalmazhatná az értékesítési adatokat, az árak (price) összegét minden kocsma-sör párosra, minden kocsma-alkesz-nap hármasra, stb.

Structure of the Cube Az adatkocka szerkezete Think of each dimension as having an additional value *. A point with one or more *’s in its coordinates aggregates over the dimensions with the *’s. 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) Képzeljük azt, hogy mindegyik dimenzió tartalmaz egy további értéket (*) [A szokásos vélelmezett „tetszőleges” érték értelmezéssel]. 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. Pl. Sales(“Joe’s Bar”, *, “Bud”, *, sales)

Drill-Down Lefúrás Drill-down = “de-aggregate” = break an aggregate into its constituents. Example: having determined that Joe’s Bar sells very few Anheuser-Busch beers, break down his sales by particular A.-B. beer. Lefúrás= „finomabb összegzés” = az összegzéseket finomabb alkotórészeire bontjuk. Példa: Ha kiderült, hogy Joe kocsmája nagyon kevés Anheuser-Busch sört adott el. Bontsuk fel az értékesítési adatokat az egyes Anheuser-Busch sörfajták szerint.

Roll-Up Felgörgetés (felösszegzés) Roll-up = aggregate along one or more dimensions. 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. Felgörgetés = összegzés egy vagy több dimenzió mentén 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

Materialized Data-Cube Views Materializált adatkocka nézetek Data cubes invite materialized views that are aggregations in one or more dimensions. Dimensions may not be completely aggregated --- an option is to group by an attribute of the dimension table. Adatkockák létrehozására olyan materializált nézeteket lehet használni, amelyek egy vagy több dimenzióban összegzéseket tartalmaznak. 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.

Example Példa A materialized view for our Sales data cube might: 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. Az értékesítés materializált nézete (Sales), adatkocka a következő lehet: Alkeszek alapján teljes összegzés. A sör fajták alapján nincs összegzés Idő tekintetében hetek szerinti összegzés A kocsmák városa szerinti összegzés.

Data Mining Adatbányászat Data mining is a popular term for queries that summarize big data sets in useful ways. Examples: Clustering all Web pages by topic. Finding characteristics of fraudulent credit-card use. Az adatbányászat az olyan adatfeldolgozásokat jelenti, amelyek nagy adathalmazokat összegeznek valamilyen szempontból hasznos módon. Példák: Az összes Web lap klaszterezése témák szerint. A bankkártyák csalásra történő használatának jellemzőinek feltárása

Market-Basket Data Bevásárló kosár An important form of mining from relational data involves market baskets = sets of “items” that are purchased together as a customer leaves a store. Summary of basket data is frequent itemsets = sets of items that often appear together in baskets. 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. 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.

Example: Market Baskets Példa If people often buy hamburger and ketchup together, the store can: Put hamburger and ketchup near each other and put potato chips between. Run a sale on hamburger and raise the price of ketchup. Ha valaki gyakran vásárol hamburgert és ketchup-ot együtt és szalma krumplit vesz még hozzá. Akkor csináljunk egy árleszállítást a hamburgerre, viszont emeljük meg a ketchup árát.

Finding Frequent Pairs Gyakori párosítások feltárása The simplest case is when we only want to find “frequent pairs” of items. Assume data is in a relation Baskets(basket, item). The support threshold s is the minimum number of baskets in which a pair appears before we are interested. Az egyszerű eset, amikor csak a gyakori párosításokat akarjuk megtalálni. Tegyük fel, hogy az adatok a Baskets(basket, item) relációban vannak. 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.

Frequent Pairs in SQL SELECT b1.item, b2.item 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 Az első tételnek meg kell előznie a másikat azért, hogy ne számoljuk kétszer ugyanazt a párt. SELECT b1.item, b2.item FROM Baskets b1, Baskets b2 WHERE b1.basket = b2.basket AND b1.item < b2.item GROUP BY b1.item, b2.item HAVING COUNT(*) >= s; 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 that appears in at least one basket. 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

A-Priori Trick --- 1 Trükk Straightforward implementation involves a join of a huge Baskets relation with itself. 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. Az egyszerű megvalósítást a Baskets reláció önmagával történő összekapcsolásával lehetne megoldani 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.

A-Priori Trick --- 2 INSERT INTO Baskets1(basket, item) Use a materialized view to hold only information about frequent items. Használjunk egy materializált nézetet a gyakori termékek nyilvántartására. INSERT INTO Baskets1(basket, item) SELECT * FROM Baskets WHERE item IN ( SELECT ITEM FROM Baskets GROUP BY item HAVING COUNT(*) >= s ); Items that appear in at least s baskets. Termékek, amelyek legalább s kosárban megjelennek

A-Priori Algorithm A-Priori Algoritmus Materialize the view Baskets1. Run the obvious query, but on Baskets1 instead of Baskets. Baskets1 is cheap, since it doesn’t involve a join. Baskets1 probably has many fewer tuples than Baskets. Running time shrinks with the square of the number of tuples involved in the join. Készítsünk egy Baskets1 materializált nézetet. A nyilvánvló lekérdezést futtassuk a Baskets1-en, Baskets helyett. Baskets1 lekérdezése olcsó, mivel nincs benne összekapcsolás Baskets1 –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.

Example: A-Priori Példa Suppose: 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. Tegyük fel: 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 T Ezért legalább a tételek 1/10 tekinthető gyakorinak. 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.