informacje o nowym zamówieniu danych - Komunikatytpd.cs.put.poznan.pl/accounts/pdf/SPBD/ZBD/01-Hurtownie_danych_m.pdf · Cele stosowania technologii baz danych: ... Własno ści

Hurtownie

danych

Hurtownie danych i przetwarzanie OLAP 2

Instytut Informatyki Politechniki Poznańskiej 2014/2015

Motywacja

Cele stosowania technologii baz danych:

• Automatyzacja rutynowych działań pracowników firmy dla zwiększenia ich produktywności i ograni-czeniu błędów

Typy aplikacji baz danych - aplikacje operacyjne

• Wprowadź informacje o nowym zamówieniu • Ustaw status zamówienia - zrealizowane • Czy zrealizowano zamówienie nr 12345 ?

W jaki sposób wspiera ć prac ę kierownictwa firm?

• Wspomaganie analityków i kadry zarządzającej w podejmowaniu racjonalnych decyzji poprzez udo-stępnianie informacji statystycznych o stanie firm

Drugi rodzaj aplikacji baz danych – aplikacje analityczne

• Czy sprzedaż w tym roku jest większa niż w po-przednim ?

• Jakie są zyski ze sprzedaży towarów w poszcze-gólnych asortymentach?

• Jaki jest wolumen sprzedaży w poszczególnych sklepach



Wymagania dotycz ące aplikacji analitycznych

• Wielowymiarowa analiza statystyczna • Analizy dotyczą całej działalności firm • Analizy dotyczą aktualnego stanu firmy • Możliwość dynamicznego generowania wszel-

kich możliwych statystyk • Wykonywanie analiz na żądanie

Zastosowania analizy danych

1. Finanse firm : prognozowanie, projekt budżetu, analiza kosztu i zysku

2. Polityka kadrowa : optymalizacja zatrudnienia, ustalanie harmonogramów

3. Dystrybucja : planowanie i optymalizacja

4. Handel : analizy rynku

5. Sprzeda ż detaliczna : lokalizacja sprzedaży, analizy demograficzne

6. Produkcja : prognozowanie i planowanie

7. Ochrona zdrowia : koszty, jakość usług

8. Doradztwo finansowe : analiza i zarządzanie ryzykiem



Interfejsy aplikacji analitycznych

Arkusze wielowymiarowe o funkcjonalności umożli-wiającej generowanie dowolnych analiz:

1. Wybór aspektów (wymiarów) analiz 2. Wybór poziomu szczegółowości analiz 3. Wybór funkcji statystycznych 4. Wybór zakresu analiz

1

2

3 2 4



Interfejs graficzny



Specyfika aplikacji analitycznych

Czy specyfika analitycznego przetwarzania da-nych wymaga nowych rozwiązań niedostępnych w technologii baz danych?

• Przetwarzanie wielowymiarowe

• Dane dotyczące wszelkich aspektów działalności firm są zazwyczaj rozproszone i heterogeniczne – źródła danych klasy HAD (Heterogeneous, Auton-omous, Distributed)

• Przetwarzanie analityczne danych jest konfliktowe z przetwarzaniem operacyjnym: blokady, logi

• Wymagany dostęp do danych historycznych; z ca-łego okresu działalności firmy

• Intensywne i złożone przetwarzanie danych w try-bie on-line; wyniki złożonych analiz powinny być wyświetlane natychmiast



Wymagania technologiczne na rozwi ązania systemowe

• Wielowymiarowy model danych • Łatwy i wydajny dostęp do sumarycznej informacji roz-

mieszczonej w wielu rozproszonych, heterogenicznych i autonomicznych bazach danych (integracja danych, transformacje między różnymi repre-zentacjami danych)

baza danych

Klient K lient

baza danych

baza danych

• Efektywna analiza danych w środowisku operacyjnym

(separacja środowisk operacyjnego i analitycznego)

Aplikacje operacyjne

Aplikacje analityczne

Baza Danych

• Efektywna analiza danych w trybie on-line

(nowe dyskowe struktury danych, przetwarzanie równo-ległe)



Rozwi ązanie: Hurtownie Danych

Hurtownia danych jest specjalizowana klasą bazy danych, przechowującą i przetwarzającą dane wejściowe dla pro-cesów wspomagania decyzji:

• integruje dane pobierane z rozproszonych i heteroge-nicznych operacyjnych źródeł danych

• utrzymuje dane zagregowane dla potrzeb analizy on-line

Klient Klient

Magazyn danych

OLAP

OLTP Klient Klient Klient Klient

operacyjna baza danych





Dlaczego oddzielna hurtownia danych

Względy wydajno ściowe • Do wspomagania typowych operacji OLAP potrzebne są

specjalne struktury danych i efektywne metody dostępu

• Przetwarzanie analityczne może ograniczać efektyw-ność aplikacji operacyjnych

• Niepotrzebny narzut systemowy związany z synchroni-zacją współbieżnych transakcji i odtwarzaniem stanu spójnego

• Zapewnienie wydajnego przetwarzania dużych zbiorów danych w trybie ad-hoc

Funkcjonalno ść • Wielowymiarowy model danych

• Utrzymywanie danych historycznych niepotrzebnych dla aplikacji operacyjnych

• Konsolidacja danych elementarnych pochodzących z wielu operacyjnych źródeł danych

• Zagwarantowanie jakości danych przechowywanych w źródłowych bazach danych w różnych formatach poję-ciowych, logicznych i fizycznych



Własno ści hurtowni danych

Organizacja tematyczna • zorganizowany wokół kilku podstawowych tematów:

klientów, produktów, sprzedaży

• koncentrujący się na danych przydatnych w procesie podejmowania decyzji

• ma uproszczony schemat dany w porównaniu z ope-racyjnymi bazami danych

Integracja danych • integruje wiele heterogenicznych źródeł danych: rela-

cyjne bazy danych, pliki tekstowe, zamknięte systemy spadkowe

• dane przed wstawieniem do hurtowni danych są czyszczone i integrowane

Temporalno ść • horyzont przechowywania danych jest znacznie dłuż-

szy niż w operacyjnych bazach danych

• elementem składowanych danych jest czas ważności pamiętanych faktów

Trwało ść • składowane dane są odseparowane od przetwarzania

operacyjnego

• na danych wykonywane są jedynie dwie operacje: wstawiania do hurtowni i odczytu podczas analizy da-nych



Przepływy danych w hurtowniach danych

ładowanie danych

nowe wersjedanych

przetwarzaniedanych

przetwarzaniedanych

agregatydanych

danewyjściowe

elementarne

dane historyczne

Metadane



Modele przetwarzania danych Można wyró żnić dwa podstawowe modele przetwarza-nia danych w bazach danych:

• OLTP (on-line transaction processing) – efektywne prze-twarzanie dużej liczby prostych transakcji modyfikują-cych i zapewnienie spójności danych

o realizowana w klasycznych bazach danych o dotyczy bieżących danych elementarnych o krótkie transakcje o statycznej strukturze o transakcje muszą posiadać własności ACID o typowe operacje to pojedyncze modyfikacje i zapy-

tania

• OLAP (on-line analytical processing) – efektywna wie-lowymiarowa analiza dużych wolumenów danych

o realizowana w hurtowniach danych o dotyczy wielowymiarowych danych historycznych o sesje użytkowników mają charakter ad hoc o typowe operacje to złożone zapytania przetwarzają-

ce duże wolumeny danych o ze względu na brak operacji modyfikacji nie wystę-

pują klasyczne problemy spójności danych



Charakterystyka systemów OLTP i OLAP

OLTP OLAP użytkownicy szeregowi pracownicy kadra zarządzająca,

analitycy

funkcje automatyzacja rutyno-wych działań

wspomaganie decyzji

dane elementarne, aktualne, płaskie, rozproszone

sumaryczne, histo-ryczne, wielowymia-rowe, zintegrowane

użycie powtarzalne ad hoc

dost ęp proste odczyty i zapisy, za pomocą indeksów, funkcji haszowych

złożone zapytania, za pomocą zmaterializo-wanych agregatów

jednostka pra-cy

krótkie i proste transak-cje

złożone zapytania

liczba przetw a-rzanych da-nych

kilka, kilkanaście, kilka-dziesiąt

miliony, miliardy

liczba u żyt-kowników

tysiące dziesiątki

rozmiar bazy danych

100 MB÷100GB 100GB÷100TB

miara wydajn o-ści

przepustowość czas odpowiedzi



Systemy OLAP a systemy wspomagania decyzji

DSS

Wspomaganie decyzji – jest technologią informa-tyczną mająca na celu przyśpieszenie i ułatwienie podejmowania decyzji przez decydentów i anality-ków • Jakie były nakłady na reklamę poszczególnych produk-

tów ?

• Czy występuje korelacja między nakładami na reklamę, a wielkością sprzedaży ?

• Czy należy zwiększyć nakłady na reklamę produktu ‘X’ ?

Systemy OLAP są częścią systemów wspomagania decyzji



Architektura systemów OLAP

Źródła informacji

Ekstrakcja, transformacja,

ładowanie i odświeżanie

danych

Hurtownia

danych

Przetworzone dane

wielowymiarowe

Narzędzia do analizy

danych

Procesy

ETL



Architektura hurtowni danych Wyróżnia się trzy podstawowe typy architektury hurtowni danych:

• scentralizowana hurtownia danych • rozproszona hurtownia danych – zbiór tematycznych

hurtowni danych (ang. data marts) • wirtualna hurtownia danych – hurtownia danych za-

wiera perspektywy zbudowane na operacyjnych źró-dłach danych

Architektura scentralizowana

Źródła danych Hurtownia

danych klienci



Architektura rozproszona Dane hurtowni danych są rozpraszane ze względu na: • równoważenie obciążenia podczas zasilania hurtowni • zwiększenie skalowalności systemu • zwiększenie dostępności danych

Architektura sfederowana • Centralna hurtownia danych jest wirtualna; • Dane są składowane w tematycznych hurtowniach da-

nych

Źródła danych

Logiczna hurtownia

danych klienci

Tematyczne hurtownie danych:

(data marts)

dystrybucja

finanse

sprzeda ż



Architektura wielowarstwowa

• Centralna hurtownia danych fizycznie przechowuje wspólne dane;

• Tematyczne hurtownie danych przechowują wybrane silniej zagregowane dane i kopie danych z poprzedniej warstwy systemu

Źródła danych

Fizyczna hurtownia

danych klienci

Tematyczne hurtownie danych:

(data marts)

dystrybucja

finanse

sprzeda ż

I warstwa II warstwa



Wielowymiarowe struktury danych

Podstawowe struktury danych

• Fakty – są elementarną strukturą danych, prze-chowującą informacje o wartościach miar w kon-tekście określonych wymiarów.

• Miary – zazwyczaj są to atrybuty numeryczne np. wartość sprzedaży, cena towaru, ocena z egzami-nu, saldo konta bankowego, kwota przelewu ban-kowego. Miary będą przetwarzane podczas analiz przez funkcje statystyczne.

• Wymiary – są strukturami danych, przechowują-cymi identyfikatory oraz atrybuty opisowe po-szczególnych wymiarów. Atrybuty opisowe są atrybutami dowolnego typu, opisującymi dany wy-miar np. nazwa towaru, nazwa producenta towaru, opis towaru, itd. Wymiary mogą być powiązane w struktury hierarchiczne.

• Kostka danych – wielowymiarowa struktura da-nych indeksowana przez wymiary, w której skła-dowane są elementarne lub przetworzone przez funkcje statystyczne wartości miar.



Przykłady wielowymiarowych struktur danych

Analizowane fakty:

<id_towaru, id_kasy, data, cena, liczba>

<nr_indeksu, nazwa_przedmiotu, semestr, data, ocena>

<id_właściciela_konta, typ_konta, typ_saldo, saldo>

<nr_konta, typ_operacji, data, kwota>

Wymiary:

<id_towaru, nazwa, cena_jednostkowa, producent>

<nr_indeksu, imię, nazwisko, data_urodzenia>

<typ_konta, pełna_nazwa_konta, oferowane_od>

Identyfikatory wymiarów Miary

Identyfikator wymiaru Atrybuty opisowe

Identyfikator wyższego poziomu

wymiaru



Wielowymiarowe struktury danych

Zbiór faktów określonego typu indeksowanych przez wymiary tworzy strukturę kostki danych.

Przykładowa kostka danych: struktura danych MOLAP

Niemcy

Polska

Czechy

Węgry

K r a j

Data

CD VCR

DVD

1998 1999 2000 2001

Produkt

1001

259 123 998

501 358 289

212

9999 4871 1983

56

543 309

TV

wartości miar – liczba sprzedanych towarów

wartości wymiarów – rok sprzedaży



Hierarchiczna struktura wymiarów

Wymiary kostki mogą mieć strukturę hierarchiczna. Z jednym wymiarem może być związanych kilka hie-rarchii.

rok

wymiar czasu

kwartał

miesi ąc

tydzie ń

dzie ń

sezon

województwo

wymiar lokalizacji

miasto

sklep

sie ć sklepów

kraj



Operacje na danych wielowymiarowych Operacja zwijania (roll-up) – zwijanie kostki przez agregowa-nie danych wzdłuż hierarchii wymiarów; w szczególnym wy-padku zanikanie całych wymiarów.

Operacja rozwijania (drill down ) – rozwijanie kostki przez rozbijanie agregatów na składowe wzdłuż hierarchii wymiarów.

miejsce zamieszkania :

wykształcenie :

okres

Gniezno

Leszno

Poznań

2000 2001 2002

średnie podstawowe

wyższe

450 523 612

165 120

291 259

124

211

Gniezno

Leszno

Poznań

styczeń 2000

luty

46 52

14

grudzień 2002

32

11

12 22

12

21

marzec

47

11

17

kwiecień

38

9

15

…

Drill -down okres [lata → miesiące]

Roll -up okres [miesiące → lata]

wyższe średnie

podstawowe okres:

Analiza bezrobocia



Operacje na danych wielowymiarowych

Operacja ci ęcia i przykrawania (slice & dice) – usuwa-nie warstw kostki wielowymiarowej, przez projekcję wybra-nych wartości atrybutów wymiarów (dla operacji cięcia do pojedynczych wartości wymiarów)

miejsce zamiesz-

kania

wykształcenie

okres

Gniezno

Leszno

Poznań

2000 2001 2002

średnie podsta-wowe

wyższe

450 523 612

165 120

291 259

124

211

Slice [wykształcenie = średnie]

2000 2001 2002

325 466 490

139 87

230 211

98

198



Operacje na danych wielowymiarowych

Operacja obrotu (pivot) – reorientacja struktury wielowy-miarowej, często połączona z agregacją redukującą liczbę wymiarów.

Gniezno

Leszno

Poznań

2000 2001 2002

450 523 612

165 120

291 259

124

211

Pivot

Gniezno

Leszno

Poznań

podst.

śred-nie

wyższe

612 490 112

67 139

95 230

165

291

Suma osób niezależnie do

wykształcenia

Suma osób niezależnie do

okresu



Model zapyta ń star-net

Różne schematy zapytań wykonywane na kostce danych można zobrazować za pomocą modelu zapytań star-net.

Dostawa

Zamówienia

Zamówienia

Kontrakty

Zamawiający

Produkt

Branża Kategoria

Produkt

Sprzedawca

Sklep

Sieć

Sprzedawca

Promocja

Miasto

Województwo

Kraj

Lokalizacja

dzień kwartał Rok

Czas

Typ

Rodzaj

rollup

drill down

pivot



Serwery OLAP ROLAP – Relacyjne systemy OLAP - dodanie nowej funk-cjonalności do systemów relacyjnych

• Reprezentacja kostki danych za pomocą relacyjnych struktur danych: tabele faktów i tabele wymiarów

• Rozszerzenie relacyjnych baz danych o operacje wielowymiarowe, które są odwzorowywane na stan-dardowe operacje relacyjne

MOLAP - Wielowymiarowe systemy OLAP

• Naturalna wielowymiarowa reprezentacja kostki da-nych

• Dedykowane systemy baz danych implementujące bezpośrednio operacje na wielowymiarowych struk-turach danych

HOLAP - Hybrydowe systemy OLAP

• Udostępniają zarówno struktury relacyjne i wielowy-miarowe



Model ROLAP

Trzy podstawowe topologie • Płatka śniegu (bezpośrednia prezentacja hierarchii wymiarów)

tabele hierarchii wymiaru

tabela faktów

• Gwiazdy (spłaszczenie wymiarów)

• Konstelacji faktów (wspólne ramiona gwiazd) np. tabele faktów: zamówienia zło żone , zamówie-nia zapłacone i zamówienia zrealizowane współdzielą wymiar klient

tabela faktów

tabele wymiarów



Wielowymiarowy model ROLAP

Schemat płatka śniegu (tabele wymiarów są znormalizowane)

sprzeda żidKlienta

idProd

idMag

wielkość

wartość

bran że

branżaopis

kategorie

kategoria

branża

opis produkty

kraje

nazwaopis

Klienci

idKlienta

nazwa

kraj

Magazyny

idMag

pojemność

lokalizacja

idProd

kategoria

marka

nazwa



Wielowymiarowy model ROLAP

Schemat gwiazdy (tabele wymiarów są zdenormalizowane)

sprzeda żidKlienta

idProd

idMag

wielkość

wartość

Magazyny

idMag

pojemność

lokalizacja

produkty

idProd

nazwa

marka

kategoria

opis kategorii branża

opis branży

Klienci

idKlienta

nazwa

kraj opis kraju



Techniki optymalizacji

• denormalizacja (model gwiazdy) – tworzenie nadmiaro-wych danych dla ograniczenia liczby złączeń

• podział – podział tabeli faktów na mniejsze dla redukcji czasu przeglądania tablicy

• wstępna agregacja – wcześniejsza agregacja danych dla potencjalnych zapytań

produkty

idProd

kategoria

sprzeda ż

idKlienta

idProd

idMag

wielkość

kategorie

kategoria

branża

bran że

branża

wartość

opis

opis

marka

bran że - 10 krotek kategorie - 100 krotek produkty - 1000 krotek sprzeda ż - 1000000 krotek

Zapytanie o branżę, kategorię, produkt i sprzedaż wymaga przeanalizowania 1000000*1000*100*10 = 1012 połączeń.



Schemat gwiazdy

wielkość

sprzeda ż

idKlienta

idProd

idMag

wartość

produkty

idProd

kategoria

branża

opis branży

marka

opis kategorii

produkty - 1000 krotek sprzeda ż - 1000000 krotek

Zapytanie o branżę, kategorię, produkt i sprzedaż wymaga przeanalizowania 1000000*1000 = 109 połączeń.



Struktury danych MOLAP Dane są przechowywane w tablicach wielowymiarowych (ang. data cube). Tablice wielowymiarowe mogą zawierać zarówno elementarne miary, jak i dane zagregowane - da-ta cube jako zbiór cuboid-ów.

Tablice wielowymiarowe zawierają wiele wartości pustych. Wiele przecięć wymiarów nie zawiera żadnych faktów. (Klienci nie kupują wszystkich towarów, ze wszystkich hur-towni, we wszystkich jednostkach czasu.)

Data Produkt

Kraj

sum

sum

TV HD

VCR TV 3D

2009 2010 2011 2012

USA

Kanada

Meksyk

sum(sum)

sum(sum(sum))

null null

null



Poziomy agregacji

Dla tablicy N - wymiarowej można wyróżnić N+1 poziomów agregacji danych (poziomy od 0 do N). Poziom zerowy zawiera pojedynczą komórkę – agregat wyznaczony dla wszystkich danych. Poziom pierwszy reprezentuje tabele jednowymiarowe – jedna tabela na jeden wymiar. Poziom drugi reprezentuje tabele dwuwymiarowe. Poziom N re-prezentuje pojedynczą podstawową tablicę N wymiarową. Sumaryczna liczba wszystkich tabel wynosi 2N.

produkt data kraj

produkt, data produkt,kraj

data, kraj

produkt, data, kraj

0 - wymiarów

1 - wymiar

2 - wymiary

3 - wymiary

all



Implementacja operacji wielowymiarowych w ROLAP

Operacja roll-up wzdłuż hierarchii typu towaru I poziom select idKlienta, idMag, idTow, sum(warto ść) from sprzeda ż group by idKlienta, idMag, idTow II poziom select idKlienta, idMag, kategoria, sum(warto ść) from sprzeda ż, produkt where sprzeda ż.idTow=produkty.idTow group by idKlienta, idMag, kategoria

III poziom select idKlienta, idMag, bran ża, sum(warto ść) from sprzeda ż, produkt where sprzeda ż.idTow=produkty.idTow group by idKlienta, idMag, bran ża

IV poziom select idKlienta, idMag, sum(warto ść) from sprzeda ż group by idKlienta, idMag

Operacja drill-down w odwrotnej kolejności



Operacja slice select idKlienta, idMag, bran ża, sum(warto ść) from sprzeda ż, produkt where sprzeda ż.id_tow=produkty.id_tow and bran ża=’spo żywcza’ group by idKlienta, idMag, bran ża

Operacja dice select idKlienta, idMag, bran ża, sum(warto ść) from sprzeda ż, produkt where sprzeda ż.id_tow=produkty.id_tow and bran ża in (’spo żywcza’,’AGD’) and idMag between 10 and 20 group by idKlienta, idMag, bran ża



Operacja pivot Stan wyj ściowy: select idKlienta, idMag, sum(warto ść) from sprzeda ż group by idKlienta, idMag

Stan docelowy: select idTow, idMag, sum(warto ść) from sprzeda ż group by idTow, idMag



Uzyskanie wielowymiarowej tabeli o wszystkich poziomach agregacji

Suma zapyta ń dla wszystkich kombinacji wymiarów

select Klient, Magazyn, Towar, sum(warto ść) from sprzeda ż, klienci, towary, magazyny where sprzeda ż.idKlienta=klienci.idKlienta and sprzeda ż.idMag=magazyny.idMag and sprzeda ż.idTow=towary.idTow group by Klient, Magazyn, Towar

union all select 'All', Magazyn, Towar, sum(warto ść) from sprzeda ż, towary, magazyny where sprzeda ż.idMag=magazyny.idMag and sprzeda ż.idTow=towary.idTow group by Magazyn, Towar

union all ... select 'All', 'All', 'All', sum(warto ść) from sprzeda ż



Rozszerzenia j ęzyka DDL - ORACLE

CREATE TABLE produkty ( prod_id NUMBER(9) PRIMARY KEY, prod_nazwa VARCHAR(40), prod_opis VARCHAR(100), ... prod_kat VARCHAR(20), ... prod_bran ża VARCHAR(20) ... )

CREATE DIMENSION wymiar_produkt LEVEL produkt IS (produkty.prod_id) LEVEL kategoria IS (produkty.prod_kat) LEVEL bran ża IS (produkty.prod_bran ża) HIERARCHY prod_rollup ( produkt CHILD OF kategoria CHILD OF bran ża) ATTRIBUTE produkt DETERMINES (produkty.prod_nazwa, produkty.prod_opis, prod_klasa, prod_jednostka_miary, prod_rozmiar_paczki, prod_status, prod_lista_cen, prod_cena_min) ATTRIBUTE kategoria DETERMINES (prod_kategoria, prod_kategoria_opis) ATTRIBUTE category DETERMINES (prod_bran ża, prod_bran ża_opis);



Nowe operatory wielowymiarowe w języku SQL

Operator cube umożliwia wyznaczenie pełnej zawartości tabeli wielowymiarowej dla wszystkich poziomów agregacji wykonując w jednym zapytaniu operację wyznaczania war-tości wybranych funkcji statystycznych dla wszystkich kombinacji wymiarów podanych jako argumenty operatora. select idKlienta, idMag, idTow, sum(warto ść) from sprzeda ż group by cube(idKlienta, idMag, idTow)

idKlienta idMag idTow Sum(warto ść) 1 1 1 100 zł 1 1 2 270 zł 1 1 370 zł 1 2 1 150 zł 1 2 2 150 zł 1 2 300 zł 1 1 250 zł 1 2 420 zł 1 670 zł ... 1 25 900 zł 1 5 780 zł

... 250 100 zł



Rozszerzenia j ęzyka SQL Operator rollup realizuje operację zwijania hierarchiczne-go wymiaru dla wszystkich podanych poziomów tego wy-miaru równocześnie. select bran ża, kategoria, idTow, sum(warto ść) from sprzeda ż inner join produkt on sprzeda ż.idTow=produkty.idTow group by rollup(bran ża, kategoria, idTow)

bran ża kategoria idTow Sum(warto ść) spożywcza napoje 1 10 200 zł spożywcza napoje 2 15 700 zł spożywcza napoje 3 8 370 zł

… spożywcza napoje 258 900 zł

… spożywcza 1 10 200 zł

... spożywcza 12 145 300 zł

... 45 630 000 zł



Rozszerzenia j ęzyka SQL Operator grouping set wykonując operację wyznaczania wartości funkcji statystycznych na różnych poziomach agregacji dla podanych kombinacji wymiarów podanych jako argumenty operatora. select bran ża, kategoria, idTow, sum(warto ść) from sprzeda ż inner join produkt on sprzeda ż.idTow=produkty.idTow group by groupig set((bran ża, kategoria), (kategoria, idTow), ())

bran ża kategoria idTow Sum(warto ść) spożywcza napoje 102 200 zł spożywcza pieczywo 80 370 zł

… napoje 1 8 900 zł napoje 2 12 008 zł

… 45 630 000 zł

spożywcza 1 10 200 zł spożywcza napoje 1 8 900 zł spożywcza 1 890 200 zł

napoje 102 200 zł 1 8 900 zł



SQL nowe funkcje analityczne

Funkcje Rank i DensRank służą do wyznaczania ran-kingów

select nazwisko, placa, rank() over (order by placa desc) AS rank , dense_rank() over (order by placa desc) AS drank from pracownicy

Nazwisko Płaca RANK DRANK

Tarzan Buła Nowek Dziubutkiewicz

12 000 zł 11 780 zł 11 780 zł 10 990 zł

1 2 2 4

1 2 2 3

select * from (select nazwisko, placa, rank() over (order by placa desc) AS rank from pracownicy) where rank<=2

Nazwisko Płaca RANK

Tarzan Buła Nowek

12 000 zł 11 780 zł 11 780 zł

1 2 2



SQL nowe funkcje analityczne Rankingi mogą być wykonywane równolegle w dynamicznie definiowanych oknach oraz dotyczyć danych zagregowanych

select * from (select etat, nazwisko, placa_pod, rank() over (partition by etat order by placa_pod desc) as rank from pracownicy) where rank=1

Nazwisko Etat Płaca Rank

Tarzan Kowalski Celiński Żelichowski

Prezes Kierownik Referent

Portier

12 000 zł 5 600 zł 1 350 zł

960 zł

1 1 1 1

select * from (select id_zesp, etat, sum(placa_pod), rank() over (partition by id_zesp order by sum(placa_pod) desc) as rank from pracownicy group by id_zesp, etat) where rank<=2 order by id_zesp, rank

Id_Zesp Etat Sum(płaca) Rank

10 10 20 20

Prezes Sekretarka Ochroniarz

Portier

35 000 zł 4 600 zł

20 350 zł 5 860 zł

1 2 1 2



SQL nowe funkcje analityczne Rankingi mogą dotyczyć wartości hipotetycznych dla wspar-cia analiz typu „what if”

select rank(2500) within group (order by placa_pod desc) AS hipotetyczny_ranking from pracownicy

hipotetyczny_rank ing

57 Podział danych na N grup w zależności od rankingu

select nazwisko, płaca, ntile(10) over (order by placa desc) AS grupa_płacowa

from pracownicy

Nazwisko Płaca grupa_płacowa

Tarzan Buła Nowek Dziubutkiewicz … Kowalski Celiński

12 000 zł 11 780 zł 11 780 zł 10 990 zł

… 980 zł 960 zł

1 1 1 1

… 10 10



Implementacja hurtowni danych

Ekstrakcja danych – monitorowanie zmian w źró-dłach danych, pobieranie danych ze źródeł danych

Integracja danych – czyszczenie, transformacja, ła-dowanie i integracja danych w hurtowni danych

Przetwarzanie danych – przetwarzanie analityczne danych, tworzenie i utrzymywanie danych zagrego-wanych, struktury fizyczne danych

Zarządzanie hurtowni ą danych – definiowanie i utrzymywanie meta-danych



Architektura systemu utrzymywania hurtowni danych

źródła danych

źródło danych

źródło danych

Monitor/ Ekstrakcja

Monitor/ Ekstrakcja

Monitor/ Ekstrakcja

Transformacja i integracja

Aplikacja OLAP

Aplikacja OLAP

Ładowanie

Hurtownia danych

ETL



Ekstrakcja danych ze źródeł danych

Ekstrakcja danych z zewnętrznych źródeł danych jest za-zwyczaj implementowana za pomocą bram (ang. gateway) i standardowych interfejsów, takich jak: ODBC, JDBC, Oracle Open Connect, Sybase Enterprise Connect, Infor-mix Enterprise Gateway, itp.

Stosuje się dwa modele ekstrakcji danych:

• kumulatywny – źródła danych są w całości ładowane do hurtowni danych

• przyrostowy – do hurtowni danych ładowane są tylko zmiany stanu danych

Proces przyrostowej ekstrakcji danych obejmuje dwie fazy:

• monitorowanie zmian w stanie źródeł danych

• propagacja zmian do hurtowni danych

Implementacja powyższych faz jest silnie zależna od funk-cjonalności źródeł danych.



Klasyfikacja źródeł danych

Źródła niewspółpracuj ące

Źródło Magazyn danych

Cykliczna detekcja zmian

propagacja

• Pliki danych - nie oferujące żadnych mechanizmów systemowych ułatwiających monitorowanie zmian. Moż-liwe zastosowanie migawek stanu pliku danych. Wykry-cie zmian odbywa się przez porównanie aktualnego sta-nu z zapamiętanym poprzednim stanem (migawką). Me-toda ta nie gwarantuje odtworzenia całej historii zamian w hurtowni danych (np. pary operacji wstaw daną i usuń tę samą daną wykonanych w ramach jednego cyklu).

• Źródła odpytywane oferują interfejs programowy do obsługi zapytań. Wykrycie zmian odbywa się przez po-równanie aktualnego stanu z zapamiętanym poprzednim stanem. Metoda ta nie gwarantuje odtworzenia całej hi-storii zamian w hurtowni danych.

• Źródła z logiem są wyposażone w plik logu, który za-wiera historię operacji wykonywanych na źródle. Pod-stawowym problemem są różne formaty logów.



Źródła współpracuj ące

Źródło Magazyn danych propagacja

detekcja zmian

• Źródła replikowane są wyposażone w mechanizmy synchronicznego lub asynchronicznego utrzymywania replik danych. Wszystkie modyfikacje źródła są przeka-zywane do repliki zarządzanej przez hurtownię danych w kolejności ich wykonania na źródle danych.

• Źródła aktywne są wyposażone w mechanizm aktyw-nych reguł (procedur wyzwalanych, triggers). Ze wzglę-du na kontekst wykonywania akcji aktywnych reguł roz-różnia się źródła:

� Informuj ące – umożliwiające bezpośrednie przeka-zanie modyfikacji stanu do hurtowni danych.

� Z aktywno ścią wewn ętrzn ą, – dla których zasię-giem działania jest jedynie źródło. Aktywne reguły źródła mogą utrzymywać utworzone dodatkowo w źródle relacje różnic, odczytywane i czyszczone cy-klicznie przez hurtownię danych.



Transformacja i integracja danych

Proces transformacji i integracji danych polega na:

• rozwiązania problemu anomalii będących konsekwencją asynchroniczności procesu magazynowania danych z działaniem aplikacji operacyjnych

• dostosowaniu ładowanych danych do schematu hurtow-ni danych za pomocą technik czyszczenia danych (np. według zdefiniowanych reguł transformacji)

• powiązania ładowanych z zawartością hurtowni danych przez weryfikację więzów integralności, sortowanie, przeliczanie agregatów



Spójno ść procesu magazynowania danych

Przykład:

Źródło zawiera dwie relacje: Pracownicy i Wypłaty

Osoby Wypłaty IdPrac Nazwisko IdPrac Kwota 100 Morzy 100 1500

Hurtownia danych zawiera zmaterializowaną perspektywę zdefiniowaną na źródłach danych, będącą połączeniem tych dwóch relacji źródłowych:

select * from Osoby o inner join wypłaty w on o.idprac = w.idprac

IdPrac Nazwisko Wypłata 100 Morzy 1500



Proces przyrostowego utrzymania hurtowni danych

Źródło Magazyn danych

zgłoszenie

zapytanie

odpowiedź

1. Źródło zgłasza do hurtowni danych modyfikację

U=Insert(Wypłaty, <100, 2000>)

2. Hurtowania wysyła zapytanie Q=Join(<100, 2000>, Oso-by)

3. Źródło wykonuje zapytanie Q i zwraca do hurtowni jego wynik <100, Morzy, 2000>

4. Hurtowania danych odbiera wynik i dodaje go do zmate-rializowanej perspektywy

IdPrac Nazwisko Wypłata 100 Morzy 1500 100 Morzy 2000



Anomalie procesu utrzymania hurtowni danych

Asynchronizm aplikacji operacyjnych i procesu utrzymy-wania hurtowni danych są przyczyną występowania ano-malii: wstawiania, modyfikacji i usuwania

1. Źródło zgłasza do hurtowni danych modyfikację U1=Insert(Osoby, <110, Tarzan>)

2. Hurtownia wysyła zapytanie Q1=Join(<110, Tarzan>, Wy-płaty)

3. Źródło zgłasza do hurtowni danych modyfikację U2=Insert(Wypłaty, <110, 5000>)

4. Hurtownia wysyła zapytanie Q2=Join(<110, 5000>, Osoby) 5. Źródło wykonuje zapytanie Q1 i zwraca do hurtowni jego

wynik <110, Tarzan, 5000> 6. Hurtownia danych odbiera wynik i dodaje go do zmateriali-

zowanej perspektywy 7. Źródło wykonuje zapytanie Q2 i zwraca do hurtowni jego

wynik <110, Tarzan, 5000> 8. Hurtownia danych odbiera wynik i dodaje go do zmateriali-

zowanej perspektywy

IdPrac Nazwisko Wypłata 100 Morzy 1500 100 Morzy 2000 110 Tarzan 5000 110 Tarzan 5000



Przykład anomalii usuwania

Stan początkowy źródła: Osoby Wypłaty IdPrac Nazwisko IdPrac Kwota 100 Morzy 100 1500

i hurtowni danych: IdPrac Nazwisko Wypłata 100 Morzy 1500

1. Źródło zgłasza do hurtowni danych modyfikację

U1=Delete(Wypłaty, <100, 1500>) 2. Hurtownia wysyła zapytanie Q1=Join(<100, 1500>, Osoby) 3. Źródło zgłasza do hurtowni danych modyfikację U2= Delete (Oso-

by, <100, Morzy>) 4. Hurtownia wysyła zapytanie Q2=Join(<100, Morzy>, Wypłaty) 5. Źródło wykonuje zapytanie Q1 i zwraca do hurtowni jego wynik ∅ 6. Hurtownia danych odbiera wynik i odejmuje go od zmaterializowa-

nej perspektywy 7. Źródło wykonuje zapytanie Q2 i zwraca do hurtowni jego wynik ∅ 8. Hurtownia danych odbiera wynik i odejmuje go od zmaterializowa-

nej perspektywy

Stan końcowy źródła: Osoby Wypłaty IdPrac Nazwisko IdPrac Kwota

i hurtowni danych: IdPrac Nazwisko Wypłata 100 Morzy 1500



Synchronizacja procesu magazynowania danych

W celu usunięcia anomalii podczas wysyłania zapy-tań do źródeł danych należy uwzględniać wysłane i nieobsłużone zapytania.

• Hurtownia danych odbiera zgłoszenie modyfika-cji zawierające zbiór zmodyfikowanych krotek ∆S

• Hurtownia danych wysyła do źródła zapytanie Q1 = R join ∆S

• Hurtownia danych odbiera zgłoszenie modyfika-cji zawierające zbiór zmodyfikowanych krotek ∆R

• Hurtownia danych wysyła do źródła skompen-sowane zapytanie Q2 = (S join ∆R) Θ (∆S join ∆R) (Θ ∈ {+ union, - minus})

Dla poprawnego działania kompensacji zapytań hur-townia danych musi utrzymywać aktualne informacje o zbiorach zadanych i niezrealizowanych zapyta-niach UQS (ang. Unanswered Query Set). Zapytania odwołujące się do relacji, dla których istnieją odpo-wiadające im pozycje w zbiorze UQS muszą być kompensowane.



Przykład kompensacji

1. Źródło zgłasza do hurtowni danych modyfikację U1=Insert(Osoby, <110, Tarzan>)

2. Hurtownia wysyła zapytanie Q1=Join(<110, Tarzan>, Wy-płaty)

3. Źródło zgłasza do hurtowni danych modyfikację U2=Insert(Wypłaty, <110, 5000>)

4. Hurtownia wysyła skompensowane zapytanie Q2=Join(<110, 5000>, Osoby) - (<110, 5000>, <110, Ta-rzan>)

5. Źródło wykonuje zapytanie Q1 i zwraca do hurtowni jego wynik <110, Tarzan, 5000>

6. Hurtownia danych odbiera wynik i dodaje go do zmateriali-zowanej perspektywy

7. Źródło wykonuje zapytanie Q2 i zwraca do hurtowni jego wynik ∅

8. Hurtownia danych odbiera wynik i dodaje go do zmateriali-zowanej perspektywy

Końcowy stan hurtowni danych jest zgodny ze źródłem:

IdPrac Nazwisko Wypłata 100 Morzy 1500 100 Morzy 2000 110 Tarzan 5000



Modele spójno ści Hurtowni Danych

Dany stan źródeł danych S, stan hurtowni danych V i zapy-tanie Q wyznaczające stan hurtowni danych. Hurtownia danych jest spójny ze względu na stan źródeł danych, je-żeli V = Q(S).

Ze względu na dziedzinę zastosowania hurtowni danych właściwa będzie jeden z poziomów spójności hurtowni da-nych ze zbiorem źródeł danych:

Zbieżność (ang. convergence) – spójność hurtowni da-nych jest gwarantowana jedynie dla całych zbiorów mody-fikacji źródeł danych. W trakcie realizacji zbioru modyfikacji stan hurtowni danych może być niespójny.

Słaba spójno ść – każdemu stanowi hurtowni danych V odpowiada stan źródeł danych S taki, że V = Q(S). Nie wszystkie stany źródeł są reprezentowane w historii hur-towni danych.

Silna spójno ść – rozszerzenie słabej spójność o zagwa-rantowanie, że kolejność występowania stanów V w historii hurtowni danych jest zgodna z kolejnością występowania odpowiednich stanów S w historii źródeł danych.

Kompletno ść – istnieje pełne i zachowujące porządek odwzorowanie między stanami źródeł i stanami hurtowni danych.



Czyszczenie danych Hurtownie danych są bezustannie zasilane dużymi wolu-menami danych pochodzących z różnych heterogenicz-nych źródeł. Stąd duże prawdopodobieństwo, że część tych danych jest brudna, czyli niepoprawna lub niespójna.

Czyszczenie danych ma na celu zapewnienie odpowied-niej jakości danych ładowanych do hurtowni danych. Ze względu na potencjalnie bardzo duży zbiór klas błędów i niespójności danych problem ich czyszczenia jest trudny do automatyzacji.

• Klasyfikacja klas błędów i niespójności

• Techniki czyszczenia danych



Klasyfikacja problemów jako ści danych

1. Problemy pojedynczych źródeł danych

1.1. Poziom schematu - brak więzów integralności, błę-dy w projekcie schematu 1.1.1. Brak unikalności atrybutów 1.1.2. Brak zależności referencyjnych 1.1.3. Atrybuty typu NULL 1.1.4. Nieznormalizowane struktury danych

1.2. Poziom instancji danych – błędy wprowadzania da-nych 1.2.1. Błędne wartości 1.2.2. Brak wartości 1.2.3. Duplikaty 1.2.4. Sprzeczne dane

2. Problemy wynikające z wielości źródeł danych

2.1. Poziom schematu – heterogeniczność modeli da-nych 2.1.1. Konflikty nazw 2.1.2. Konflikty strukturalne

2.2. Poziom instancji danych – nakładanie się, sprzecz-ności, niespójności 2.2.1. Różne reprezentacje danych 2.2.2. Sprzeczność danych 2.2.3. Niespójność danych wywiedzionych i agrega-

tów



Przykłady brudnych danych

Niepoprawne wartości pojedynczych atrybutów:

data_urodzenia=’31-13-1980’ - spoza zakresu dziedziny miasto=’Ponzna ń’ – przetypowanie cena=???? - brak wartości zawód=’prog.DB’ – skróty pracownik=’Jan Kowalski, student’ - wartości złożone miasto=’Polska’ – zamienione pola Niepoprawne zależności między atrybutami: wiek=22, rok_urodz=1937 miasto=’Pozna ń’, kod=’00-245’

Niepoprawne zależności między rekordami:

• naruszenie unikalności atrybutu: prac1=(id=1001, nazwisko=’Nowak’) prac2=(id=1001, nazwisko=’Tarzan’)

• przestawienie słów: student1=’M.Morzy’ student2=’Morzy.T’

• duplikaty danych prac1=(nazwisko=’J.Tarzan’, ...) prac2=(nazwisko=’Jan Tarzan’, ...)



• sprzeczne dane prac=(nazwisko=’Nowak’, data_ur=’1-02-1970’) prac=(nazwisko=’Nowak’, data_ur=’1-12-1970’)

• błędy referencyjne prac=( nazwisko=’Nowak’, zespół=13) – nie ma zespołu 13 prac=( nazwisko=’Nowak’, zespół=13) – Nowak nie pra-cuje w zespole 13

• różne reprezentacje danych

źródło I

Nr_klienta Nazwisko Miasto Ulica Płeć 100 Jurek Nowak Poznań Browarna 5 M 110 J. Tarzan Kalisz Piwna 13 K

źródło II

id Imi ę Nazwisko Płe ć Adres Fax 100 Jerzy Nowak 0 P-ń, ul.Browarna 5 6513013 110 Janina Tarzan 1 Kalisz, Piwna13 7823456



Techniki czyszczenia danych

• Funkcje konwersji i normalizacji danych przekształ-cające i standaryzujące różne formaty danych.

Do konwersji formatów danych stosuje się uniwersalne programy do konwersji różnych struktur i typów danych (np. Oracle SQL*Loader) lub programy dedykowane dla obsługi poszczególnych źródeł (wrapper).

Przez normalizację danych rozumie się przekształcanie danych, którego celem jest umożliwienie porównywania danych tego samego typu. Na przykład: zamiana wiel-kości liter w tekście, ustalenie formatu daty, wydzielanie rdzeni wyrazów, itp.

• Wyspecjalizowane funkcje czyszcz ące związane z określoną dziedziną zastosowania.

Funkcje te operują na słownikach danych związanych z daną dziedzina zastosowań: słowniki nazw miast, nazw towarów, skrótów, synonimów, itp., lub bazują na algo-rytmach generowania określonego typu wartości: nume-ry PESEL, REGON, NIP, itp. Ze wglądu na wąski zakres zastosowania są bardzo skuteczne.




• Czyszczenie niezale żne od dziedziny stosuje się przy łączeniu danych pochodzących z różnych źródeł.

Technika ta stosuje algorytmy dopasowania pól pocho-dzących z różnych źródeł danych. Algorytmy te dzielą porównywane teksty na łańcuchy atomowe. Podstawo-wy algorytm wylicza stopień dopasowania pól A i B jako:

Match(A,B) = k/(|A|+|B|)/2 ,

gdzie: k – jest liczbą pasujących do siebie łańcuchów atomowych. Dwa łańcuchy atomowe pasują do siebie, jeżeli są sobie równe lub jeden z nich jest przedrostkiem drugiego.

Dla pól: A) ‘Tadeusz Morzy’ i B) ‘Morzy T.’

|A|=2, |B|=2 i k=2, skąd: Match (A,B)=1




• Czyszczenie oparte na regułach dopasowuje wartości pochodzące z różnych źródeł za pomocą zdefiniowane-go zbioru reguł określających warunki dopasowania.

Metoda scalania z czyszczeniem (merge/purge) – jest to metoda umożliwiająca usuwanie duplikatów danych i scalania danych

1. Generowanie kluczy dla zbioru rekordów na pod-stawie wskazanych atrybutów rekordów.

2. Sortowanie zbioru danych na podstawie utworzo-nych kluczy (dla zwiększenia wydajności sortowa-nie może być poprzedzone usunięciem duplikatów, grupowaniem danych według wartości klucza)

3. Dopasowywanie rekordów w oknie o stałej wielko-ści na podstawie wartości funkcji podobieństwa re-kordów zdefiniowanych w postaci reguł.

w=8 w=8

bieżące okno

rekordów

kolejne okno



Przykład reguły zdefiniowanej przez użytkownika:

Dane rekordy r1 i r2

if r1.nazwisko = r2.nazwisko and r1.imi ę podobne do r2.imi ę and r1.adres = r2.adres and r1.wiek=r2.wiek

then r1 jest równe r2

Reguły mogą być znajdowane automatycznie za pomo-cą eksploracji danych. Zawartość każdego źródła jest analizowana leksykalnie pod kątem statystyk występo-wania pewnych słów i związków między nimi.

Wszystkie wymienione techniki mogą być używa-ne zarówno podczas ładowania jak i odświeżania hurtowni danych.



Perspektywy zmaterializowane

Zmaterializowana perspektywa V jest relacją zdefiniowaną przez zapytanie Q na zbiorze relacji R, która składuje swój własny stan:

V=Q( R) CREATE MATERIALIZED VIEW V AS SELECT X, SUM(Y) FROM R GROUP BY X

Stanem perspektywy V jest zbiór krotek będących wyni-kiem zapytania:

select * from V

Modyfikacje stanów relacji ze zbioru R powodują niespój-ność stanu perspektywy V. W celu przywrócenia spójności perspektywa V musi być odświeżana.

Ze względu na moment uruchomienia wyróżniamy:

� odświeżanie natychmiastowe , to jest synchroniczne do zmian w relacjach ze zbioru R;

� odświeżanie opó źnione , to jest asynchroniczne do zmian w relacjach ze zbioru R.

Ze względu na sposób realizacji wyróżniamy:

� odświeżanie pełne wyznaczające stan perspektywy V poprzez jej pełne przeliczenie;

� odświeżanie przyrostowe wyznaczające stan per-spektywy V poprzez jej częściowe przeliczenie.



Perspektywy utrzymywalne

Perspektywa V jest utrzymywalna , jeżeli dla dwóch do-wolnych stanów bazy danych S i S’, dla których różnica w stanie relacji R wynosi ∆R=S(R)−S’(R), istnieje wyrażenie ∆Q takie, że: S’(V)= ∆Q(S(V), ∆R, R) i ∆Q wyznacza nowy stan perspektywy V przez jej cz ęściowe przeliczenie .

Perspektywa V jest częściowo utrzymywalna, je żeli ∆Q istnieje jedynie dla niektórych typów operacji modyfikacji relacji R.

Przykład Perspektywy utrzymywalne:

V = select count(*) from R

V = select sum(R.x) from R

Perspektywy częściowo utrzymywalne: V = select min(R.x) from R

V = select max(R.x) from R

są utrzymywalne ze względu na operacje insert , a nie utrzymywalne ze względu na operacje delete.

Perspektywa V jest nieutrzymywalna jeżeli jedynym spo-sobem jej odświeżenia jest wykonanie definiującego ją za-pytania Q.

V = select median(*) from R



Perspektywy samoobsługowe

Perspektywa V jest samoobsługowa, jeżeli jest utrzymy-walna lub częściowo utrzymywalna i:

S’(V)= ∆Q(S(V), ∆R),

to znaczy, że ∆Q wykorzystuje do odświeżania jedynie po-przedni stan V oraz modyfikacje relacji źródłowych R.

Przykładem perspektywy samoobsługowej jest: V = select count(*) from R

Perspektywa V jest słabo-samoobsługowa, jeżeli , jeżeli jest utrzymywalna lub częściowo utrzymywalna i:

S’(V)= ∆Q(S(V), ∆R, S⊂R),

to znaczy, że ∆Q wykorzystuje do odświeżania poprzedni stan Q, różnice w relacjach źródłowych R oraz pewien podzbiór S krotek relacji R.

Przykładem perspektywy słabo-samoobsługowej jest: V = select median(cena) from R group by rok

Wstawienie nowej danej o sprzedaży w roku 2011 wyma-ga przeliczenia danych o sprzedaży jedynie z roku 2011.



Tabele agregatów

Kostka OLAP może obejmować wszystkie zmateria-lizowane tabele agregatów dla wszystkich poziomów agregacji. Dla N wymiarów daje to 2N tabel agrega-tów.

(miasto, produkt, data)

(miasto, produkt, ∗) (miasto, ∗, data) (∗, produkt, data)

(miasto, ∗, ∗) (∗, produkt, ∗) (∗,∗, data)

(∗,∗,∗)

Przykład

Przy założeniu, że N=10, a każdy z wymiarów tworzy dwu-poziomową hierarchię, liczba tabel agregatów jest równa 220= 1 048 576.



Query rewriting Dla zapewnienia logicznej (fizycznej?) niezależności danych aplikacje analityczne odwołują się jedynie do danych bazo-wych, tj. tabel faktów i wymiarów. W wypadku istnienia zma-terializowanych perspektyw użytecznych dla uzyskania wy-niku zapytania, optymalizator zapytań zmodyfikuje zapytanie odwołując się do zmaterializowanych danych sumarycznych.

Przykład Dana perspektywa zmaterializowana:

Sprzeda żKlientMagazynBran ża

select idKlienta, idMag, bran ża, sum(warto ść) AS suma

from sprzeda ż, produkt where sprzeda ż.idTow=produkty.idTow group by idKlienta, idMag, bran ża

Zapytanie użytkownika: select idKlienta, idMag, sum(warto ść) from sprzeda ż, produkt where sprzeda ż.idTow=produkty.idTow group by idKlienta, idMag

zostanie zmodyfikowane przez optymalizator zapytań do postaci: select idKlienta, idMag, sum(suma) from Sprzeda żKlientMagazynBran ża group by idKlienta, idMag

Sumy wartości sprzedaży nie będą wyliczane na podstawie danych elementarnych, ale na podstawie danych zagregowanych.



Wykorzystanie danych o ni ższym stopniu agregacji

Czy dostępna perspektywa zmaterializowana o definicji:

CREATE MATERIALIZED VIEW Sum_towar AS SELECT bran ża, kategoria, idTow, SUM(warto ść) FROM TabelaFaktów GROUP BY bran ża, kategoria, idTow

i zbiorze danych:

branża kategoria idTow Sum(warto ść) spożywcza napoje 1 10 200 zł spożywcza napoje 2 15 700 zł spożywcza napoje 3 8 370 zł

…

może być wykorzystana w realizacji zapytań o wyższym poziomie agregacji, np.:

SELECT bran ża, kategoria, SUM(warto ść) FROM TabelaFaktów GROUP BY bran ża, kategoria

lub: SELECT bran ża, SUM(warto ść) FROM TabelaFaktów GROUP BY bran ża

lub: SELECT SUM(warto ść) FROM TabelaFaktów



Klasyfikacja funkcji statystycznych ze wzgl ędu na mo żliwo ść hierarchicznej agregacji

Xij jest dwuwymiarowym zbiorem zawierającym m podzbiorów, z których każdy zawiera nj liczb (wymia-rami są np. branża – m i towary - nj):

{ Xij | i=1, …, nj; j=1, …, m}.

Czy do wyznaczania agregatów wyższego poziomu można wykorzystać agregaty niższego poziomu? Zależy to od własności danego agregatu – funkcji statystycznej.

Agregacja w wymiarze branża

Agregacja w wymiarze produkt

Dane elementarne sprzedaż



Klasyfikacja funkcji statystycznych ze wzgl ędu na mo żliwo ść hierarchicznej agregacji

Funkcja F() jest funkcj ą rozdzieln ą (ang. distributive), je-żeli istnieje funkcja statystyczna G(), ta sama, bądź inna niż F(), taka, że:

F({Xij}) = G({F({Xij | i=1, …, nj}) | j=1, …, m})

Przykładami funkcji rozdzielnych są funkcje: SUM(), CO-UNT(), MIN() i MAX(). Na przykład:

• SUM(Xij) = SUM(SUM(Xi) j) – suma jest sum ą sum Funkcja F() jest funkcj ą algebraiczn ą, jeżeli istnieje M-krotkowa operacja algebraiczna G() i rozdzielne funkcje Hi() takie, że:

F({Xij}) = G({H1({Xij | i=1, …, nj}) | j=1, …, m}, …

HM({Xij | i=1, …, nj}) | j=1, …, m})

Przykładami funkcji algebraicznych są funkcje: AVG(), STDEV(), MAXN() i MINN(). Na przykład:

• AVG(X ij) = SUM(SUM(Xi) j)/SUM(COUNT(Xi) j) – średnia jest ilorazem sumy sum przez sum ę liczebno ści

Funkcja F() jest funkcj ą holistyczn ą, jeżeli nie istnieją funkcje i operacje, które zastosowane do m podzbiorów Xij, umożliwiałyby wyznaczenie wartości funkcji F dla całego zbioru Xij.

Przykładami funkcji holistycznych są funkcje: MEDIAN(), RANK(), MostFrequent().

• Nie mo żna wyznaczy ć mediany zbioru na podstawie median podzbiorów



Metody dost ępu dla efektywnego przetwarzania

danych wielowymiarowych

Specyfika hurtowni danych:

• selekcja na wielu wymiarach

• wiele operacji złączenia

• mała selektywność atrybutów

• wyznaczanie wartości statystycznych

Typowe zapytanie: select k.nazwa, idMag, p.bran ża, sum(warto ść) from sprzeda ż s, produkty p, klienci k where s.id_tow = p.id_tow and s.idKlienta = k.id and bran ża in (’spo żywcza’,’AGD’) and idMag between 10 and 20 and k.lokalizacja = 'Pozna ń' group by idKlienta, idMag, bran ża



Struktury fizyczne stosowane w hurtowniach danych

Klasyczne indeksy typu B+-drzewa – są mało wydaj-ne dla równoczesnego indeksowania wielu atrybu-tów o małej selektywności

• Indeksy bitmapowe

• Indeksy projekcji

• Indeksy bitmapowy projekcji (ang. Bit-Sliced)

• Indeksy poł ączeniowe

• Indeksy wielowymiarowe



Indeksy bitmapowe W indeksach bitmapowych dla każdej różnej wartości atry-butu indeksowanego jest tworzona mapa bitowa. Po-szczególne pozycje mapy odpowiadają rekordom indek-sowanego pliku. Ustawiona jedynka w określonej pozycji mapy bitowej wskazuje rekord o danej wartości atrybutu.

Mapy bitowe pozwalają na przyśpieszenie operacji slice&dice realizowanej dla kilku wymiarów. Mapy bitowe należy zakładać na atrybutach wymiarów tabeli faktów. Zbiór krotek relacji wynikowej jest wyznaczany w wyniku operacji wykonywanych na mapach bitowych.

Mapy bitowe Tabela faktów idTow idKlienta

idTow idKlienta wartość 1 2 5 12 1 2 3 1 1 980 zł 1 0 0 0 1 0 0 2 1 540 zł 0 1 0 0 1 0 0 5 1 4250 zł 0 0 1 0 1 0 0 1 2 630 zł 1 0 0 0 0 1 0

12 2 3200 zł 0 0 0 1 0 1 0 5 3 1500 zł 0 0 1 0 0 0 1 2 3 740 zł 0 1 0 0 0 0 1

… … …

Indeksy bitmapowe zajmują mniej miejsca niż analogiczne listy wskaźników na bloki z danymi i umożliwiają dzięki te-mu wydajniejszą realizację: złożonych warunków selekcji i wyznaczania wartości funkcji statystycznych.



Indeksy bitmapowe Koszt wykonania zapytania =

koszt operacji nawigacji w indeksie + koszt ustalenia wska źników na bloki z danymi + koszt odczytu bloków z danymi

Zastosowanie bitmap pozwala zredukować drugi ze składni-ków kosztu. Liczba rekordów w pliku tabeli faktów: r =100 000 000 Rozmiar bloków dyskowych: B=4kB Liczba różnych wartości dla atrybutów wymiarów: count D=10 Rozmiar wskaźników na bloki z danymi: p=8 bajtów Średnia liczba bloków ze wskaźnikami dla pojedynczej wartości

atrybutu: bw= (r / count D ) / (B/p) = 19 532 Rozmiar pojedynczej mapy bitowej: bMB=100 000 000[bitów] = 3000 [bloki]

przy kompresji 0,1: bMB komp = 300

Dane zapytanie na tabeli faktów: select * from sprzeda ż where idTow=102 and idKlienta=215 and …

Liczba prostych warunków selekcji połączonych operatorem and : sp =10

1. Koszt metody bez zastosowania bitmap: K = sp ∗ bw = 10 ∗ 19 532 = 195 320

2. Koszt metody z zastosowaniem bitmap: K = sp ∗ bMB = 10 ∗ 300 = 3000



Połączeniowe indeksy bit-mapowe Połączeniowe mapy bitowe są tworzone dla ścieżek połą-czeń prowadzących do atrybutów wymiarów tabeli faktów. Ich zastosowanie pozwala uniknąć wykonywania czaso-chłonnej operacji połączenia.

Tabela faktów Mapy bitowe Sprzedaż branża

idTow idKlienta wartość spożywcza odzieżowa AGD 1 1 980 zł 1 0 0 2 1 540 zł 1 0 0 5 1 4250 zł 0 0 1 1 2 630 zł 1 0 0

12 2 3200 zł 1 0 0 5 3 1500 zł 0 0 1 2 3 740 zł 1 0 0

… … …

Połączeniowy indeks bitmapowy bran ża zostanie założo-ny na tabeli faktów. Dzięki temu zapytanie:

select bran ża, sum(warto ść) from sprzeda ż, produkt where sprzeda ż.idTow=produkty.idTow group bran ża

nie będzie wymagało dostępu do tabeli wymiaru produkt .



Indeksy projekcji

Indeks projekcji dla danego atrybutu relacji jest listą warto-ści tego atrybut dla wszystkich krotek relacji uporządko-waną w kolejności krotek w oryginalnej relacji.

Indeks projekcji na atrybucie A relacji R jest równy: πall A(R)

Dla atrybutów o stałej długości określenie lokalizacji war-tości atrybutu dla krotki o pozycji n jest równe:

strona = n/bfr pi ; offset =n%bfr pi

Dany zbiór numerów krotek spełniających warunek zapy-tania. Szukane są jedynie wartości pojedynczego atrybutu.

Korzyść wyszukiwania wartości atrybutu za pomocą indek-su projekcji dla krotki o znanej lokalizacji jest konsekwen-cją faktu:

bfr pi >> bfr

Rozmiar(atrybut) = 4B Rozmiar(krotka) = 200B

B=4kB

bfrpi = 1000 bfr = 20

Gęstość wyniku zapytania = 1/50

Liczba danych na stronie:

1000/50=20 20/50=0,4

Liczba czytanych stron indeksu/stron pliku z danymi:

= b/(0,4*b*50) = 1/20



Bitmapowy indeks projekcji

Bitmapowy indeks projekcji założony na numerycznym atrybucie A jest zbiorem bitmap zawierających wartości dla poszczególnych bitów wartości atrybutu A. Jeżeli wartości atrybutu A są reprezentowane przez sekwencje N bitów to n-ta wartość i -tej mapy bitowej MBi gdzie i = 0, 1, …, N-1 , jest równa wartości i -tego bitu wartości atrybutu A prze-chowywanej w n-tej krotce relacji. To znaczy:

• MBi (n)=0, jeżeli i -ty bit wartości atrybutu A krotki o pozycji n jest równa 0,

• MBi (n)=1, jeżeli i -ty bit wartości atrybutu A krotki o pozycji n jest równa 1.

n atrybut A

0 0 1 0 0 1 0 0 0

1 1 1 0 0 0 1 0 1

2 0 0 1 1 1 1 1 0

3 1 0 1 0 1 0 1 0

…

MB0 MB1 MB2 MB3 MB4 MB5 MB6 MB7



Zastosowanie bitmapowych indeksów projekcji

Realizacja zapytania: select sum(warto ść) from sprzeda ż

za pomocą algorytmu: Suma(sprzeda ż)

sum = 0; for i=0 to N-1 // N jest liczbą map bitowych projekcji

sum += 2 i ∗ Count(MB i ); end Suma;

Realizacja zapytania: select sum(warto ść) from sprzeda ż where idKlienta=115

za pomocą algorytmu: Suma(sprzeda ż) sum = 0;

for i=0 to N-1 // N jest liczbą map bitowych projekcji // Bf jest mapą bitową krotek dla atrybut idKlienta=115

sum += 2 i ∗ Count(MB i and B f (115)); end Suma;



Analiza porównawcza Dane zapytanie:

select sum(warto ść) from sprzeda ż where idKlienta=115

Parametry fizycznych struktur danych:

r=100 000 000 - liczba rekordów w pliku sprzeda ż bfr=20 - współczynnik wypełnienia bloków pliku bfrproj=1000 - współczynnik wypełnienia bloków indeksu b=5 000 000 - liczba bloków pliku z danymi bproj=100 000 - liczba bloków pliku z danymi N=20 - liczba bitów wartości atrybutu warto ść σ=1/50 - selektywność zapytania

Metoda 1 – gęsty indeks B+-drzewo z listą wskaźników za-łożony na atrybucie idKlienta :

I/O ≈ liczba odczytów bloków pliku z danymi1

I/O ≈ 5 000 000 ∗(1-e-2 000 000/5 000 000) ≈ 1 648 400

Metoda 2 – indeks projekcji na atrybucie warto ść:

I/O ≈ liczba odczytów bloków indeksu

I/O ≈ bproj ≈ 100 000

Metoda 3 – bitmapowy indeks projekcji na atrybucie warto ść:

I/O ≈ liczba odczytów map bitowych

I/O ≈ r/8/4096 ∗ (N+1) ≈ 3052 ∗ 21 ≈ 64 092

1 Pominięto odczyt bloków indeksu B+-drzewo



Indeksy połączeniowe

Indeks połączeniowy dla relacji R i S jest zbiorem takich par wskaźników krotek tych relacji r i i s j , dla których spełniony jest warunek połączeniowy R. A=S. B.

Indeks

połączeniowy

dla warunku: Produkty.id=Sprzeda ż.prod_id

r1 s1

r1 s3

r1 s5

r1 s6

r2 s2

r2 s4

Produkty id nazwa cenar1→ 1 tv 2500r2→ 2 dvd 1200

Sprzeda ż id prod_id data ilo śćs1→ 1 1 1 12s2→ 2 2 1 11s3→ 3 1 1 50s4→ 4 2 1 8s5→ 5 1 2 44s6→ 6 1 2 4



R-drzewa R-drzewa są dynamicznymi strukturami danych służącymi do wyszukiwania obiektów wielowymiarowych (niepunk-towych!!! ) w przestrzeni wielowymiarowej. W R-drzewach obiekty wielowymiarowe są aproksymowane za pomocą minimalnych regionów pokrywających (MBR – minimum bounding rectangle).

Realizowane funkcje: • Zapytania punktowe: Znajdź identyfikatory obiektów

przestrzennych, których MBR zawiera punkt P • Zapytania regionowe : Znajdź identyfikatory obiektów

przestrzennych, których MBR ma część wspólną z re-gionem R

• Najbli ższy s ąsiad : ZnajdźNN identyfikatory obiektów przestrzennych, których MBR są najmniej oddalone od punktu P

Struktura w ęzłów R-drzewa • struktura węzłów pośrednich:

((MBR1, p1), (MBR2, p2), ... , (MBRn, pn)),

gdzie: n ∈ (m, M), M jest maksymalnym, a m jest mini-malnym wypełnieniem węzłów i m = M/2; z wyjątkiem korzenia, dla którego m = 2;

• struktura liści:

((MBR1, oid1), (MBR2, oid2), ... , (MBRn, pn)),

gdzie oid jest wskaźnikiem na indeksowany obiekt.



Charakterystyka R-drzewa 1. Wszystkie liście znajdują się na tym samym poziomie

drzewa – jest to drzewo zrównoważone.

2. Regiony znajdujące się w liściach są najmniejszymi z regionów obejmujących przestrzennie indeksowane obiekty.

3. Regiony znajdujące się w węzłach wewnętrznych są najmniejszymi z regionów obejmujących przestrzennie wszystkie regiony węzłów potomnych.

4. Regiony znajdujące się w tym samym węźle R-drzewa mogą się pokrywać.

Rx Ry

RzRA

... RA ...

Rx Ry Rz

5. Suma wszystkich regionów znajdujących się w danym

węźle nie musi tworzyć regionu i w konsekwencji nie musi być równa zawierającemu je regionowi w węźle ro-dzicielskim.

Dwie ostatnie własności są konsekwencją faktu, że podział przepełnionych węzłów nie polega na podziale regionu, lecz na pogrupowaniu regionów składowych i wyznaczeniu dla nich MBR.



Przykład

kształtobiektu 1

AKX

Y

Z

B

obiekt 2

obiekt 3 M

L

punkt P

...

A B ...

K L M

X Y Z

obiekt_1 obiekt_2 obiekt_3

...



Wyszukiwanie danych za pomoc ą R-drzew

Procedura Search (T, Rs) (gdzie T jest korzeniem drzewa, a Rs jest regionem zapy-tania)

(S1) Jeżeli T nie jest liściem, sprawdź dla każdej pary (Ri, Pi), czy region Ri pokrywa się częściowo z regionem Rs. Jeżeli tak, to dla takiego regionu wywołaj rekurencyjnie funkcję Search (Pi, Rs). Jeżeli region Rs nie ma części wspólnej z żadnym z regionów zakończ poszukiwanie wzdłuż danej ścieżki.

(S2) Jeżeli T jest liściem, sprawdź dla każdej pary (Ri, oidi), czy region Ri pokrywa się częściowo z regionem Rs. Je-żeli tak, to umieść oidi w zbiorze wynikowy procedury.

Operacja wyszukiwania danych w R-drzewach charaktery-zuje się stosunkowo niską efektywnością, ponieważ w przypadku, gdy poszukiwany region znajdują się w obsza-rze należącym do kilku regionów tego samego poziomu szukanie może przebiegać wzdłuż wielu równoległych ścieżek.

Przykład : znajdź obiekt zawierający punkt P.

...

A B ...

K L M...



Cubetree Modelowanie tabeli faktów i wszystkich poziomów tabel agregatów jako danych w przestrzeni wielowymiarowej, na której jest założony spakowany indeks typu R-drzewo.

Z

Y

X

(x1,y1,z1,m)

(x1,0,z1,ΣYm)

(0,0,0,Σm)

(x1, y1,0,ΣZm)

(0, y1, y1,ΣXm)

(x1,0,0,ΣYZm)

(0,0,z1,ΣXYm)

(0,y1,0,ΣXZm)



Koszty utrzymania Cubetrees



Efektywno ść zapyta ń



Przetwarzanie równoległe

Skracanie czasu odpowiedzi w wyniku zrównole-glania algorytmów realizujących operacje na sta-nie bazy danych. Miarą skrócenia czasu odpowiedzi jest współ-czynnik speedup:

�� = ��

��

Plany zapytań dla RDBMS mogą być w naturalny sposób zrównoleglone.

SUM(A’)

SUM(SUM)

SUM(A”)

partycja A' partycja A"



Partycjonowanie tabel

W relacyjnych bazach danych krotki relacji są party-cjonowane horyzontalnie na wielu dyskach w taki spo-sób, że każda krotka jest ulokowana na dokładnie jed-nym dysku.

Znanych jest kilka technik partycjonowania bazujących na różnych sposobach redystrybucji danych między różne partycje:

• partycjonowanie sekwencyjne Round Robin , • partycjonowanie ze względu na przedziały war-

tości danych ,

• partycjonowanie z funkcj ą haszuj ącą, • partycjonowanie wyliczeniowe ze względu na

wyszczególnione wartości.

CREATE TABLE Sprzedaż ( id_sklepu NUMBER(6), id_towaru NUMBER(6),

cena NUMBER(6,2))

PARTITION BY HASH(id_sklepu)

(PARTITION p1 TABLESPACE ts1,

PARTITION p2 TABLESPACE ts2,

PARTITION p3 TABLESPACE ts1,

PARTITION p4 TABLESPACE ts3);

Documents

informacje o nowym zamówieniu danych - Komunikatytpd.cs.put.poznan.pl/accounts/pdf/SPBD/ZBD/01-Hurtownie_danych_m.pdf · Cele stosowania technologii baz danych: ... Własno ści