Hurtownie danych oparte o Oracle9i/10g – przegląd

X Konferencja PLOUG
Kościelisko
Październik 2004
Hurtownie danych oparte o Oracle9i/10g –
przegląd funkcjonalności
Robert Wrembel
Politechnika Poznańska, Instytut Informatyki
ul. Piotrowo 3A, 60-965 Poznań
[email protected]
Streszczenie
Hurtownie (magazyny) danych stają się obecnie niezbędnym komponentem systemów informatycznych w dużych firmach i instytucjach. Zawartość hurtowni danych poddana złożonej analizie i eksploracji danych staje się bezcennym
źródłem wiedzy wykorzystywanej w procesach decyzyjnych. Wiodące firmy wytwarzające oprogramowanie, m.in.
Oracle dostarczają zaawansowanych narzędzi do budowy hurtowni danych, ich optymalizacji, zarządzania nimi, oraz do
budowy aplikacji analitycznych. Celem niniejszego artykułu jest skrótowe omówienie oprogramowania Oracle wykorzystywanego w hurtowniach danych. Poruszone zostaną: (1) funkcjonalność serwera bazy danych Oracle9i/10g, (2)
narzędzia integracji danych, (3) narzędzia do budowania aplikacji.
192
Robert Wrembel
Hurtownie danych oparte o Oracle9i/10g – przegląd funkcjonalności
193
1. Wprowadzenie
Hurtownie danych, zwane również magazynami danych (ang. data warehouses) stają się obecnie niezbędnym komponentem systemów informatycznych w dużych firmach i instytucjach.
Z technologicznego punktu widzenia hurtownia danych jest ogromną bazą danych, do której wczytuje się dane z tzw. produkcyjnych źródeł danych. Na hurtowni danych pracują tzw. aplikacje analityczne (ang. On-line Analytical Processing - OLAP), czy eksploracji danych (ang. data mining).
Aplikacje takie są zorientowane na przetwarzanie danych historycznych i zagregowanych. Większość operacji realizowanych przez tego typu aplikacje obejmuje złożone zapytania wykorzystujące łączenie, filtrowanie, agregowanie, wymagające dostępu do milionów rekordów tabel bazy danych. Przykładami takich zapytań mogą być: Jaki jest trend sprzedaży towarów z branży AGD w
ostatnich kilku tygodniach? Jaki jest rozkład sprzedaży lodówek w województwie wielkopolskim?
Tak więc, przetwarzanie w aplikacjach analitycznych charakteryzuje się operacjami odczytu dużych wolumenów danych, przetwarzanych następnie przez złożone funkcje analityczne.
Zawartość hurtowni danych poddana złożonej analizie i eksploracji danych staje się bezcennym
źródłem wiedzy wykorzystywanej w procesach decyzyjnych. Dzięki szybkiej analizie bazującej na
pełnej i aktualnej informacji o stanie firmy, kadra zarządzająca może podejmować właściwe decyzje o strategicznym znaczeniu dla rozwoju danego przedsiębiorstwa.
Wiodące firmy wytwarzające oprogramowanie, m.in. Oracle dostarczają zaawansowanych narzędzi do budowy hurtowni danych, ich optymalizacji, zarządzania nimi, oraz do budowy aplikacji
analitycznych.
Budując hurtownię danych należy sprostać wielu problemom techniczno/technologicznym. Do
najważniejszych z nich należą: (1) zaprojektowanie właściwego schematu/struktury magazynu, (2)
sposób zasilania hurtowni danymi, (3) zbudowanie funkcjonalnych aplikacji analitycznych, (4)
zapewnienie efektywnego dostępu do dużych wolumenów danych. Niniejszy artykuł stanowi krótki przegląd funkcjonalności oprogramowania Oracle w zakresie wspomnianych problemów.
2. Architektura systemu magazynu danych
Dane zasilające magazyn danych są często przechowywane w heterogenicznych systemach informatycznych, czyli posiadających różne struktury, funkcjonalność i wykorzystujących różne
modele danych (np. hierarchiczne, relacyjne, obiektowe, semistrukturalne), w dokumentach tekstowych, czy arkuszach kalkulacyjnych. Często nawet w ramach tej samej instytucji wykorzystuje
się różne systemy informatyczne. Heterogeniczność źródeł danych utrudnia spójny dostęp do informacji. Dodatkowym problemem jest geograficzne rozproszenie źródeł. Koniecznym jest więc
dostarczenie oprogramowania, które zapewni spójny i zintegrowany dostęp do takich źródeł. Dane
do magazynu wczytuje się w złożonym procesie, zwanym ETL (Extraction-Translation-Loading).
Proces ten składa się z trzech następujących faz: odczytu danych ze źródeł (Extraction), transformacji ich do wspólnego modelu wykorzystywanego w magazynie wraz z usunięciem wszelkich
niespójności (Translation), wczytanie danych do magazynu (Loading). Architektura techniczna
systemu magazynu danych wspiera ten proces.
Na rysunku 1 przedstawiono w pełni funkcjonalną architekturę takiego systemu. Obiekty oznaczone jako ZD1, ZD2, ZDn reprezentują źródła danych. Z każdym z takich źródeł jest związana
warstwa oprogramowania – konwertera i monitora. Zadaniem pierwszego z nich jest transformowanie danych z formatu wykorzystywanego w źródle, do formatu wykorzystywanego w hurtowni
danych. Zadaniem modułu monitora jest wykrywanie zmian w danych źródłowych i ich przekazywanie do warstwy oprogramowania integratora. Moduł integratora jest odpowiedzialny za integrowanie danych w jeden spójny zbiór przed ich wczytaniem do hurtowni. Hurtownia danych zawiera zarówno dane elementarne, bieżące i historyczne, jak i dane przetworzone – zagregowane.
194
Robert Wrembel
Rys. 1. Podstawowa architektura systemu hurtowni danych
Centralna hurtownia danych zawiera dane dla wszystkich grup decydentów. Ze względu na
ilość przechowywanych w niej danych, wygodnie jest budować w oparciu o nią, małe tematyczne
hurtownie (ang. data marts), zawierające dane opisujące wąskie dziedziny funkcjonowania firmy.
Taka tematyczna hurtownia zawiera dane zwykle na wyższym poziomie agregacji niż w hurtowni
centralnej. Przykładowo, hurtownia danych nt. ruchu telefonicznego i opłat klientów operatora
sieci komórkowej może posłużyć do zbudowania dwóch data marts opisujących odpowiednio natężenie ruchu telefonicznego w ciągu doby i ranking klientów ze względu na wysokość płaconych
rachunków.
3. Modele danych – reprezentacja danych w hurtowni
Dane w magazynie można reprezentować i przechowywać w oparciu o model relacyjny, zwany
również ROLAP (ang. Relational OLAP) i wielowymiarowy, zwanym również MOLAP lub MDOLAP (ang. Multidimensional OLAP). Często w tej samej bazie danych reprezentuje się informacje
częściowo w modelu ROLAP, a częściowo w MOLAP. Taki sposób reprezentacji nazywa się hybrydowym – HOLAP (ang. Hybrid OLAP). Baza danych Oracle9i/10g umożliwia reprezentowanie
i przechowywanie danych we wszystkich wspomnianych wyżej modelach.
3.1. ROLAP
Magazyn danych w technologii ROLAP jest implementowany w postaci tabel, których schemat
posiada najczęściej strukturę gwiazdy (ang. star schema) lub płatka śniegu (ang. snowflake schema) lub konstelacji faktów (ang. fact constellation) lub strukturę gwiazda–płatek śniegu (ang. starflake schema). W przypadku implementacji relacyjnej zalecane jest zdefiniowanie dodatkowych
logicznych obiektów bazy danych opisujących ww. schematy. Obiektami tymi są wymiar (ang.
dimension), hierarchia wymiaru (ang. dimension hierarchy) i zależności funkcyjne (ang. functional
dependencies).
3.1.1. Schemat gwiazdy, płatka śniegu i konstelacji faktów
Przykładowy schemat gwiazdy przedstawia rysunek 2. Centralna tabela Sprzedaż zawiera informacje o sprzedaży pewnych produktów, w pewnych sklepach, w określonym czasie. Tabele
Sklepy, Produkty i Czas są nazywane tabelami wymiarów (ang. dimension tables), natomiast tabela
centralna jest nazywana tabelą faktów (ang. fact table). Atrybuty tabeli faktów przechowujące informacje o sprzedaży są nazywane miarami (ang. measures), np. wartość, l_sztuk. Tabela faktów –
Hurtownie danych oparte o Oracle9i/10g – przegląd funkcjonalności
195
Sprzedaż zawiera również atrybuty produkt_id, sklep_id, data, których wartości wskazują na odpowiednie wymiary. W takim schemacie tabele wymiarów są zdenormalizowane, por. tabele Sklepy, Produkty, Czas.
Rys. 2. Schemat gwiazdy
Jeśli wymiary są znormalizowane, wówczas schemat magazynu danych ma postać płatka śniegu (ang. snowflake schema). Przykładowy schemat o takiej strukturze został przedstawiony na
rysunku 3. W tym przypadku, wymiary Lokalizacja, Produkty i Czas mają postać hierarchii. Przykładowo, wymiarze Lokalizacja każdy sklep (tabela Sklepy) znajduje się w mieście (tabela Miasta), które z kolei znajduje się w województwie (tabela Województwa).
Rys. 3. Schemat płatka śniegu
Schemat gwiazdy lub płatka śniegu, w którym ten sam wymiar jest powiązany z wieloma tabelami faktów nazywa się schematem konstelacji faktów (ang. fact constellation schema). Natomiast
196
Robert Wrembel
schemat, w którym część wymiarów ma postać znormalizowaną (tzn. posiadają strukturę hierarchiczną), a część ma postać zdenormalizowaną nazywa się schematem gwiazdy–płatka śniegu. W
praktyce, ze względów efektywnościowych najczęściej stosuje się schematy gwiazdy lub gwiazdy–płatka śniegu.
3.1.2. Modelowanie wymiarów – logiczne obiekty bazy danych
Implementując hurtownię w oparciu o jeden z powyższych schematów, jest zalecane zdefiniowanie dodatkowych logicznych obiektów bazy danych opisujących ww. schematy. Obiektami
tymi są wymiar (ang. dimension), hierarchia wymiaru (ang. dimension hierarchy) i zależności
funkcyjne (ang. functional dependencies).
Jako przykład ilustrujący tworzenie ww. obiektów rozważmy tabelę wymiaru Produkty, której
schemat przedstawiono poniżej.
Name
---------PRODUKT_ID
NAZWA
CENA_DET
CENA_HURT
PODGRUPA
PODGR_INF
GRUPA
GRUPA_INF
Null?
-------NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
Type
-----------NUMBER(6)
VARCHAR2(30)
NUMBER(6,2)
NUMBER(6,2)
VARCHAR2(30)
VARCHAR2(50)
NOT NULL VARCHAR2(30)
VARCHAR2(50)
Rys. 4. Przykładowa hierarchia wymiaru Produkty
Poniższe polecenie create dimension definiuje dla tabeli Produkty hierarchię wymiaru
i zależności funkcyjne. Hierarchię tę przedstawiono na rysunku 4, natomiast zależności funkcyjne
są następujące: id_prod {nazwa, cena_det, cena_hurt}, podgrupa {podgr_inf}, grupa {grupa_inf}.
create dimension dim_produkty
level produkt is produkty.id_prod
level podgrupa is produkty.podgrupa
level grupa is produkty.grupa
hierarchy hier_produkty
(produkt child of
podgrupa child of
grupa)
attribute produkt determines
(nazwa, cena_det, cena_hurt)
attribute podgrupa determines
(podgr_inf)
attribute grupa determines
(grupa_inf);
Omawiane obiekty są wykorzystywane przez kosztowy optymalizator zapytań w procesie przepisywania zapytań.
3.2. MDOLAP
Hurtownia danych zaprojektowana w technologii MOLAP do przechowywania danych wykorzystuje wielowymiarowe tablice (ang. multidimensional arrays, datacubes). Tablice te zawierają
wstępnie przetworzone (m.in. zagregowane) dane pochodzące z wielu źródeł. Przykładowa trójwymiarowa tablica została przedstawiona na rysunku 5. Zawiera ona trzy wymiary: Lokalizacja,
Czas i Produkty oraz zagregowane informacje (poszczególne kostki) o sprzedaży wybranych produktów w poszczególnych latach, w wybranych miastach.
Hurtownie danych oparte o Oracle9i/10g – przegląd funkcjonalności
197
Rys. 5. Przykładowa trójwymiarowa tablica opisująca miarę sprzedaż w trzech wymiarach:
Lokalizacji, Czasu i Produktu
W systemie Oracle9i/10g dane wielowymiarowe są przechowywane w tzw. przestrzeni analitycznej (ang. analytic workspace). Definiowanie tej przestrzeni i zarządzanie nią realizuje się albo
z wykorzystaniem oprogramowania Analytic Workspace Manager, albo Warehouse Builder,
albo z poziomu SQL wykorzystując do tego celu pakiety systemowe. Zbiór pakietów rodziny
CWM2 umożliwia zarządzanie informacjami słownikowymi (metadanymi) opisującymi przestrzeń
analityczną. DBMS_AWM zawiera procedury tworzenia przestrzeni analitycznej, natomiast
DBMS_AW zawiera procedury umożliwiające operowanie na danych wielowymiarowych, m.in.
wczytywanie danych z tabel i analizę danych. DBMS_AW_UTITLITIES udostępnia procedury
zarządzania miarami w przestrzeni analitycznej. OLAP_TABLE umożliwia prezentowanie danych
wielowymiarowych w postaci tabelarycznej (relacyjnej).
Poniżej przedstawiono wybrane przykładowe polecenia obsługi danych w przestrzeni analitycznej. Polecenia te zostały wykonane z wykorzystaniem pakietu systemowego DBMS_AW. Polecenie 1. tworzy nową pustą przestrzeń analityczną o nazwie test_ws. Polecenie 2. definiuje wymiary sklepy, produkty i czas. Polecenie 3. definiuje zmienną l_sztuk reprezentującą miarę. Wymiarami dla niej są sklepy, produkty i czas. Polecenie 4. wpisuje wartości do wymiaru sklepy.
1. exec DBMS_AW.EXECUTE('AW CREATE test_ws;')
2. exec DBMS_AW.EXECUTE('DEFINE sklepy DIMENSION TEXT W 15; DEFINE produkty DIMENSION TEXT W 20; DEFINE czas DIMENSION TEXT W 15;')
3. exec DBMS_AW.EXECUTE('DEFINE l_sztuk VARIABLE DECIMAL <sklepy produkty czas>;')
4. exec DBMS_AW.EXECUTE('MAINTAIN sklepy ADD ''SKLEP1'' ''SKLEP2'' ''SKLEP3''
''SKLEP4'' ''SKLEP5'' ''SKLEP6'';')
Kolejne trzy polecenia służą do prezentowania wartości zmiennej l_sztuk. Polecenie 5. zawęża
wartości w wymiarze czas do miesiąca styczeń. Natomiast polecenie 6 zawęża wartości w wymiarze sklepy do trzech sklepów. Polecenie 7. prezentuje dane wielowymiarowe reprezentowane
zmienną l_sztuk.
5. exec DBMS_AW.EXECUTE('LIMIT czas TO ''styczeń'';')
6. exec DBMS_AW.EXECUTE('LIMIT sklepy TO ''SKLEP1'' to ''SKLEP3'';')
7. exec DBMS_AW.EXECUTE('REPORT l_sztuk;')
CZAS: styczeń
PRODUKTY
---------------Eternity for men
Polo
Adidas sport
STR8
Rioja
------------L_SZTUK-------------------------SKLEPY------------SKLEP1
SKLEP2
SKLEP3
---------- ---------- ---------1,00
2,00
NA
NA
NA
2,00
2,00
1,00
NA
NA
NA
NA
5,00
6,00
2,00
198
Bordeaux
Żubrówka
Dębowa
Robert Wrembel
4,00
1,00
NA
NA
NA
NA
NA
NA
NA
4. Zasilanie danymi
Głównym problemem w dostępie do źródeł zewnętrznych z hurtowni jest heterogeniczność
tych źródeł. Nawet jeśli źródła są bazami danych, to bardzo często są to bazy danych pochodzące
od różnych producentów, a co za tym idzie, posiadające różną funkcjonalność, reprezentację danych i dialekt języka SQL. Z tego względu, dostęp z jednej bazy danych do innej musi być realizowany za pomocą dedykowanego oprogramowania dla tych baz. Oprogramowanie to nosi nazwę
gateway'a. Jego zadaniem jest m.in. transformowanie dialektów SQL i reprezentacji (typów) danych przesyłanych między bazami danych.
Z instalacją Oracle9i/10g jest dostarczane oprogramowanie Transparent Gateways, które
umożliwia dostęp i wymianę danych z większością głównych komercyjnych systemów relacyjnych, tj. wytwarzanych przez IBM, Sybase, Microsoft, NCR. Ponadto, z wykorzystaniem sterowników ODBC/JDBC można realizować dostęp do wspomnianych wyżej i wielu innych baz danych.
Natomiast definiowanie całego procesu ETL jest wspomagane oprogramowaniem Warehouse
Builder.
Dane do hurtowni wczytuje się często również z plików tekstowych. W tym zakresie rozwiązania Oracle9i/10g obejmują m.in.: pakiet systemowy UTL_FILE, oprogramowanie SQL*Loader,
tabele zewnętrzne i funkcje tablicowe. Pakiet UTL_FILE zawiera procedury i funkcje odczytu i
zapisu plików. SQL*Loader umożliwia wczytywanie informacji z plików tekstowych o różnym
formacie. Możliwe jest także weryfikowanie, transformowanie i filtrowanie danych przed ich
wczytaniem do bazy. Rozszerzeniem tej funkcjonalności jest możliwość definiowania w bazie
danych tzw. tabel zewnętrznych (ang. external tables), których źródłem danych są pliki tekstowe
systemu operacyjnego. Do tabel takich odwołuje się za pomocą standardowych poleceń SQL select, a dane są dynamicznie pobierane z plików skojarzonych z tabelą zewnętrzną. W Oracle10g za pomocą tabel zewnętrznych można dodatkowo kopiować dane z bazy danych do plików
zewnętrznych. Mechanizm tzw. funkcji tablicowych (ang. table functions) udostępnia dane, które
najpierw są przetwarzane, a następnie przekazywane przez funkcje napisane w języku PL/SQL.
Funkcje te są składowane w bazie danych. Źródłami danych dla tych funkcji mogą być dowolne
obiekty bazy danych (np. zwykłe tabele lub tabele zewnętrzne) lub pliki tekstowe. Dane mogą być
przetwarzane w bardzo złożony sposób, a algorytmy ich przetwarzania implementuje się w języku
proceduralnym. Funkcje tablicowe w zapytaniach wykorzystuje się w sposób identyczny jak tabele.
Kolejny problem stanowi aktualność danych przechowywanych w hurtowni. Ponieważ zawartość źródeł danych jest bezustannie modyfikowana, więc zawartość hurtowni po pewnym czasie
staje się nieaktualna. Wobec tego, w trakcie jej eksploatacji musi ona być odświeżania. Podczas
procesu odświeżania dąży się do tego, aby do hurtowni trafiały jedynie te dane ze źródeł, które
uległy zmianie od czasu poprzedniego odświeżania. Jest to tzw. odświeżanie przyrostowe (ang.
incremental refershing).
Baza danych Oracle9i/10g posiada dwa mechanizmy umożliwiające propagowanie zmian
z bazy produkcyjnej do hurtowni. Pierwszy z nich to wyzwalacze (ang. triggers), czyli procedury
wyzwalane na skutek operacji modyfikowania danych źródłowych. Procedury te mogą informować moduł monitora lub propagować dane do hurtowni. Projektant hurtowni musi w tym przypadku sam zaimplementować właściwie działające wyzwalacze. Drugi mechanizm wykorzystuje tzw.
migawki (ang. snapshots) zwane również perspektywami zmaterializowanymi (ang. materialized
views).
Perspektywa zmaterializowana jest kopią tabeli lub jej fragmentu pochodzącego z innej bazy
danych. W definicji takiej perspektywy określa się najczęściej: częstotliwość jej odświeżania, sposób odświeżania (przyrostowe, pełne), zbiór danych ze źródła który ma być dostępny w perspek-
Hurtownie danych oparte o Oracle9i/10g – przegląd funkcjonalności
199
tywie. System zarządzania hurtownią danych sam kontroluje proces odświeżania perspektywy.
Odświeżanie przyrostowe perspektyw zmaterializowanych jest możliwe dopiero po utworzeniu w
bazie produkcyjnej tzw. dziennika perspektywy zmaterializowanej (ang. materialized view log) dla
każdej tabeli, z której perspektywa pobiera dane. Zadaniem dziennika jest rejestrowanie zmian
zachodzących w danych źródłowych. Proces odświeżający perspektywy korzysta z informacji
zapisanych właśnie w dziennikach. Odświeżanie przyrostowe z wykorzystaniem perspektyw zmaterializowanych i ich dzienników jest jednak możliwe jedynie w przypadku, gdy zarówno bazy
źródłowe, jak i sama hurtownia są oparte o Oracle9i/10g (lub wersje wcześniejsze). Perspektywy
zmaterializowane tworzy się albo z wykorzystaniem oprogramowania Enterprise Manager albo z
poziomu SQL.
Przykładowo, poniższe polecenie create materialized view tworzy perspektywę
zmaterializowaną, która jest odświeżana przyrostowo (klauzula refresh fast) i automatycznie co 1 minutę (klauzula start with sysdate+(1/(24*60))) . Źródłem danych dla tej
perspektywy są dane z tabeli Sprzedaż w zdalnej bazie danych (klauzula select).
create materialized view mv_sprzedaz
build immediate
refresh fast
start with sysdate+(1/(24*60))
next sysdate+(1/(24*60*6))
as
select * from sprzedaz@lab92
where data like '%2003';
Odświeżanie przyrostowe powyższej perspektyw będzie możliwe dopiero wtedy, gdy w źródłowej bazie danych dla tabeli Sprzedaż zostanie zdefiniowany tzw. dziennik perspektywy zmaterializowanej (ang. materialized view log) rejestrujący wszystkie zmiany zawartości Tabeli sprzedaż, jak przedstawiono poniżej.
create materialized view log on sprzedaz;
5. Analiza danych
5.1. Funkcjonalność OLAP
Dane przechowywane w hurtowni podlegają zaawansowanym analizom. Dla potrzeb takich
analiz i złożonego przetwarzania danych, Oracle9i/10g udostępnia szereg klauzul i funkcji ułatwiających konstruowanie zapytań OLAP. W zakresie wyznaczania agregatów rozszerzono język
SQL o klauzule group by cube, group by rollup, group by grouping sets umożliwiające wyliczanie
dodatkowych wartości zagregowanych.
Jako przykład rozważmy zapytanie obliczające sumy sprzedanych produktów w poszczególnych sklepach, oparte o schemat z rysunku 2. W przykładowym poniższym wyniku, pogrubiono te
dodatkowe podsumowania, które zostały wyliczone z wykorzystaniem klauzuli cube.
select pr.prod_nazwa produkt, sk.nazwa,
sum(l_sztuk) sprzedano
from sprzedaz sp, sklepy sk, produkty pr
where sp.sklep_id=sk.sklep_id
and
sp.produkt_id=pr.produkt_id
group by cube (pr.prod_nazwa, sk.nazwa);
PRODUKT
NAZWA
SPRZEDANO
--------- ------- ---------18
SKLEP1
5
SKLEP2
6
SKLEP3
7
Rioja
12
Rioja
SKLEP1
3
Rioja
SKLEP2
4
Rioja
SKLEP3
5
Bordeaux
6
Bordeaux SKLEP1
2
200
Robert Wrembel
Bordeaux
Bordeaux
SKLEP2
SKLEP3
2
2
W wersji Oracle10g do polecenia select dodano klauzulę model, która umożliwia zagnieżdżenie w zapytaniu kodu napisanego w specjalnie do tego celu dedykowanym języku proceduralnym. Możliwe jest m.in. wykorzystanie pętli i zmiennych. Cel stosowania tej klauzuli jest
dwojaki. Po pierwsze wyliczanie wartości hipotetycznych w celach predykcyjnych, np. predykcja
sprzedaży w roku następnym na podstawie lat poprzednich. Po drugie symulowanie w bazie danych arkuszy kalkulacyjnych. Elementarną funkcjonalność klauzuli model zilustrowano poniższymi przykładami. Więcej informacji na jej temat Czytelnik znajdzie w [O10DWG].
Przyjmijmy, że w bazie danych zdefiniowano perspektywę view_sprzedaż opartą o tabele Sklepy, Produkty, Czas i Sprzedaż (por. rysunek 2). Perspektywa ta udostępnia sumy kwot sprzedaży w
poszczególnych sklepach, poszczególnych produktów, w poszczególnych miesiącach. Poniższe
zapytanie do tej perspektywy wykorzystuje klauzulę model w następujący sposób. Dane relacyjne są transformowane do 2-wymiarowej kostki, której wymiarami są nazwa produktu i nazwa
miesiąca (atrybuty prod_nazwa i nazwa_miesiąca w klauzuli dimension by). Miarę stanowi
atrybut kwota (klauzula measures(kwota)). Klauzula partition by (miasto) umożliwia podzielenie kostki na "podkostki" – po jednej dla każdego miasta. Do wartości miary w każdej "podkostce" jest stosowana reguła specyfikowana w klauzuli rule. W poniższym przykładzie
kwota sprzedaży kosmetyku o nazwie Polo w kwietniu jest hipotetycznie wyliczana jako kwota
sprzedaży tego kosmetyku w marcu powiększona o 20%. W ogólności, w klauzuli model można
definiować wiele reguł.
select miasto, prod_nazwa, nazwa_miesiaca, kwota
from view_sprzedaz
where miasto = 'Kraków'
model return all rows
partition by (miasto)
dimension by (prod_nazwa, nazwa_miesiaca)
measures (kwota)
rules( kwota['Polo', 'kwiecień'] = kwota['Polo', 'marzec'] * 1.2)
order by prod_nazwa, nazwa_miesiaca;
Przykładowy wynik omawianego zapytania przedstawiono poniżej. Rekord, który został wyliczony klauzulą model przedstawiono jako pogrubiony i pochylony. Pozostałe rekordy pochodzą z
bazy danych.
MIASTO
---------Kraków
Kraków
Kraków
Kraków
Kraków
Kraków
PROD_NAZWA
------------Adidas sport
Bordeaux
Polo
Polo
Polo
Żubrówka
NAZWA_MIESIACA
KWOTA
--------------- ---------marzec
60
styczeń
450
kwiecień
264
marzec
220
styczeń
660
styczeń
54
Kolejny przykład prezentuje możliwość: definiowania zmiennych i sposób odwoływania się do
takich zmiennych oraz możliwość wykorzystania pętli w jednym poleceniu select. Idea poniższego zapytania jest następująca. Klauzula reference definiuje zmienną typu zbiór rekordów
(analogia do zmiennej typu REF CURSOR) będący wynikiem podzapytania umieszczonego w tej
klauzuli. Podzapytanie udostępnia przeliczniki walut. Dla tego zbioru przeliczników określono
wymiar, który stanowi atrybut waluta (dimension by (waluta)) i miarę, którą jest wartość
przelicznika (measures (wspolczynnik)). Wymiary i miara głównej kostki zostały ustalo-
Hurtownie danych oparte o Oracle9i/10g – przegląd funkcjonalności
201
ne w sposób identyczny, jak w omawianym wcześniej zapytaniu. Reguła przelicza kwoty sprzedaży na zadaną walutę. Wybór waluty jest dokonywany poprzez odwołanie się do zmiennej ze wskazaniem wartości wymiaru waluta (konw_ref. wspolczynnik ['EUR']).
select miasto, prod_nazwa, nazwa_miesiaca, kwota
from view_sprzedaz
where miasto = 'Kraków'
model
reference konw_ref on ( select waluta, pln from przelicznik)
dimension by (waluta) measures (wspolczynnik)
main konwersja
partition by (miasto)
dimension by (prod_nazwa, nazwa_miesiaca)
measures (kwota)
rules(UPSERT kwota[
FOR prod_nazwa IN (select distinct prod_nazwa from produkty),
FOR nazwa_miesiaca IN (select distinct nazwa_miesiaca from czas)] =
kwota[CV(prod_nazwa), CV(nazwa_miesiaca)]/konw_ref.wspolczynnik['EUR'])
order by miasto, prod_nazwa, nazwa_miesiaca;
Należy zwrócić uwagę, że poszczególne wartości wymiarów są dynamicznie pobierane w pętli
FOR z wyników podzapytań.
Wszystkie omawiane rozszerzenia polecenia select mają na celu umożliwienie implementowania bardzo złożonych analiz w jednym zapytaniu, którego wykonanie będzie mogło zostać
zoptymalizowane przez moduł optymalizatora kosztowego.
Zaawansowane analizy wymagają również stosowania specjalizowanych funkcji analitycznych
obliczających m.in.: rankingi, agregaty kumulacyjne, regresje. W tym zakresie, Oracle9i/10g
oferuje kilkadziesiąt takich funkcji.
5.2. Eksploracja danych
Eksploracja danych (ang. data mining) jest techniką analizy danych w celu odkrywania niejawnych, a interesujących ze względów np. biznesowych powiązań między danymi. Eksploracja danych ma zastosowanie w wielu dziedzinach działalności i przedsiębiorczości, m.in. handlu, marketingu, medycynie, bankowości, ubezpieczeniach. Przykładowo, dzięki eksploracji danych o sprzedaży produktów w supermarketach można wydobyć informację jakie zbiory produktów są najczęściej kupowane razem. Wykorzystuje się do tego tzw. technikę znajdowania reguł asocjacyjnych
(ang. association rules). Informacja o zbiorze produktów często kupowanych w czasie jednej wizyty w supermarkecie może być przydatna w projektowaniu fizycznego rozmieszczenia towarów na
półkach. Inny przykład może dotyczyć znajdowania grupy klientów, którzy z największym prawdopodobieństwem zakupią dany towar, np. w celu skierowania do nich kampanii reklamowej. Do
tego celu wykorzystuje się tzw. technikę klasyfikacji i predykcji (ang. classification and prediction). Inne techniki eksploracji danych obejmują: analizę skupień (ang. clustering), odkrywanie
osobliwości (ang. outlier detection), odkrywanie wzorców sekwencji (ang. sequential pattern mining).
Baza danych Oracle10g udostępnia narzędzia programistyczne umożliwiające znajdowanie
reguł asocjacyjnych, analizę skupień, klasyfikację i predykcję. Są one dostępne za pomocą interfejsu Java API lub pakietu systemowego DBMS_DATA_MINING, składowanych w bazie danych.
6. Efektywność systemu
Aby systemy relacyjnych baz danych mogły efektywnie przetwarzać zapytania typu OLAP
i zarządzać danymi rzędu terabajtów muszą posiadać nowe własności zwiększające ich efektywność. Nowymi cechami systemów relacyjnych w zastosowaniach hurtowni danych są m.in.: specy-
202
Robert Wrembel
ficzne techniki indeksowania, optymalizacja zapytań gwiaździstych, zastosowanie perspektyw
zmaterializowanych w procesie przepisywania zapytań, partycjonowanie danych i indeksów, kompresja danych, przetwarzanie równoległe.
6.1. Indeksowanie
Podstawowymi strukturami danych wykorzystywanymi do optymalizacji zapytań są indeksy.
Dla bardzo złożonych zapytań typu OLAP, operujących na ogromnej liczbie danych, standardowe
indeksy w postaci B–drzew okazują się nieefektywne ponieważ po pierwsze, nie zapewniają wystarczająco szybkiego dostępu do danych, po drugie, ich rozmiary są zbyt duże, przez co wzrastają
koszty ich przetwarzania, przechowywania i utrzymywania. Dla zastosowań OLAP, Oracle9i/10g
udostępnia indeksy bitmapowe i bitmapowe połączeniowe.
6.1.1. Indeks bitmapowy
Ideą indeksów bitmapowych jest wykorzystanie pojedynczych bitów do zapamiętania informacji o tym, że dana wartość atrybutu występuje w określonym rekordzie tabeli. Dla każdej unikalnej
wartości atrybutu jest przechowywana tablica bitów, zwana mapą bitową. Każdy bit mapy odpowiada jednemu rekordowy w tabeli R – bit pierwszy odpowiada pierwszemu rekordowi w tabeli R,
bit drugi – drugiemu rekordowi itp. Dla mapy A=’w’ bit n przyjmuje wartość jeden, jeśli atrybut A
rekordu o numerze n przyjmuje wartość ‘w’. W przeciwnym przypadku bit n przyjmuje wartość
zero. Liczba bitów mapy bitowej odpowiada liczbie rekordów tabeli R. Indeks bitmapowy jest
zbiorem map bitowych dla wszystkich unikalnych wartości danego atrybutu. Indeks tego typu (w
zależności od implementacji) może również posiadać strukturę B–drzewa, w którego liściach zamiast adresów rekordów są przechowywane mapy bitowe. Przykład indeksu bitmapowego dla
atrybutu kolor tabeli Sprzedaż przedstawiono w tabeli 2.
Sprzedaż
ROWID
x00A1
x00A2
...
x00B6
x00B7
x00B8
x00B9
kolor
sklep
produkt
...
kolor
SKLEP1
SKLEP2
...
SKLEP1
SKLEP4
SKLEP4
SKLEP3
Omo
Omo
...
Omo
Persil
Persil
Dosia
...
...
...
...
...
...
...
tak
nie
...
nie
tak
nie
tak
Tabela 1. Przykładowa tabela Sprzedaż
ROWID
x00A1
x00A2
...
x00B6
x00B7
x00B8
x00B9
tak
1
0
...
0
1
0
1
nie
0
1
...
1
0
1
0
Tabela 2. Indeks bitmapowy dla atrybutu
kolor
Polecenie tworzące taki indeks ma postać przedstawioną poniżej.
create bitmap index kolor_bitmap_indx on sprzedaz(kolor);
Indeksy bitmapowe są bardziej efektywne od indeksów w postaci B–drzewa tylko dla określonej klasy zapytań kierowanych do bazy danych. Są to zapytania wykorzystujące dużą liczbę predykatów warunkowych z operatorami równości oraz zapytania wykorzystujące funkcję COUNT.
Większa efektywność tych indeksów wynika z:
• dużej szybkości przetwarzania map bitowych za pomocą operatorów AND, OR i NOT.
• małego rozmiaru indeksów – indeksy takie zdefiniowane na atrybutach o wąskiej dziedzinie
są znacznie mniejsze od indeksów w postaci B–drzewa.
• możliwości wykonywania operacji logicznych i funkcji COUNT bezpośrednio na indeksach
bitmapowych (znajdujących się w pamięci operacyjnej), a nie na samych rekordach..
W przypadku stosowania operatora LIKE, indeksy bitmapowe są jednak bezużyteczne.
Hurtownie danych oparte o Oracle9i/10g – przegląd funkcjonalności
203
6.1.2 Bitmapowy indeks połączeniowy
Bitmapowy indeks połączeniowy (ang. join bitmap index) przyspiesza operacje łączenia tabel
powiązanych poprzez klucz podstawowy i obcy, jest więc strukturą zawierającą zmaterializowane
połączenie tabel. Jako przykład rozważmy tego typu indeks zdefiniowany na atrybucie Produkty.kategoria połączenia tabeli Sprzedaż i Produkty. Indeks ten będzie zawierał tyle map bitowych
ile jest różnych kategorii produktów (w tabeli Produkty). Pojedyncza mapa tego indeksu, np. dla
grupy kosmetyki będzie wskazywała na te rekordy w tabeli Sprzedaż, które opisują sprzedaż kosmetyków. Polecenie tworzące omawiany indeks przedstawiono poniżej, natomiast poglądowy
rysunek jego struktury przedstawiono na rysunku 6.
create bitmap index sprz_join_bitmap_indx
on sprzedaz(produkty.kategoria)
from sprzedaz, produkty
where sprzedaz.produkt_id=produkty.produkt_id;
Rys.6. Struktura przykładowego bitmapowego indeksu połączeniowego
6.2. Optymalizacja zapytań gwiaździstych
W magazynach danych typowe zapytania łączą centralną tabelę faktów z tabelami wymiarów.
Są to tzw. zapytania gwiaździste (ang. star queries). Jako przykład, rozważmy zapytanie do tabel
z rysunku 2, wyznaczające sumy sprzedaży produktów kategorii kosmetyki w województwach
wielkopolskim i mazowieckim. W celu skrócenia czasu odpowiedzi systemu na to zapytanie, należy zdefiniować dwa bitmapowe indeksy połączeniowe. Jeden na atrybucie województwo, a drugi
na atrybucie kategoria (omówiony w punkcie 6.1.2). Indeks na atrybucie województwo będzie
zawierał tyle map bitowych ile jest różnych województw w tabeli Sklepy. Pojedyncza mapa tego
indeksu, np. dla Wielkopolski będzie opisywała te sprzedaże (rekordy w tabeli Sprzedaż), które
zrealizowano w Wielkopolsce.
Kosztowy optymalizator zapytań bazy danych Oracle9i/10g zastąpi oryginalne zapytanie
użytkownika zapytaniem alternatywnym, które wykorzysta bitmapowe indeksy połączeniowe,
w następujący sposób. W kroku pierwszym moduł wykonawczy SQL odczyta następujące mapy
bitowe:
• opisującą sprzedaż produktów kategorii kosmetyki; niech mapa ta nazywa się MBkosmetyki;
• opisującą sprzedaż w województwie wielkopolskim; niech mapa ta nazywa się MBWielkopolska;
• opisującą sprzedaż w województwie mazowieckim; niech mapa ta nazywa się MBMazowsze;
204
Robert Wrembel
W korku drugim, zostanie wyznaczona wynikowa mapa bitowa (niech będzie oznaczona jako
MBwynik) w następujący sposób: MBkosmetyki and (MBWielkopolska or MBMazowsze). Będzie ona wskazywała na sprzedaże kosmetyków zarówno w jednym, jak i drugim województwie.
W kroku trzecim, z wykorzystaniem mapy MBwynik zostaną odczytane odpowiednie rekordy tabeli
Sprzedaż.
Optymalizacja zapytań gwiaździstych umożliwia kilku/kilkunastokrotne skrócenie czasu odpowiedzi systemu.
6.3. Perspektywy zmaterializowane i przepisywanie zapytań
Oprócz replikowania/odświeżania danych, inną bardzo ważną i często stosowaną dziedziną zastosowań perspektyw zmaterializowanych jest optymalizacja zapytań analitycznych. Dla tych zastosowań perspektywy zmaterializowane służą do przechowywania wyliczonych danych (najczęściej zagregowanych), których wyznaczenie jest czasochłonne. Materializowanie danych ma sens
jeżeli w systemie często pojawiają się zapytania identyczne lub podobne do tego, którego wynik
zmaterializowano. Jeżeli w systemie pojawi się zapytanie, które może zostać wykonane z wykorzystaniem zmaterializowanych perspektyw, zamiast korzystania ze źródłowych tabel i wyznaczania wyników od początku, wówczas kosztowy optymalizator zapytań skonstruuje odpowiednie
zapytanie do tych perspektyw. Jest to tzw. przepisanie zapytania (ang. query rewriting). Proces ten
jest całkowicie niewidoczny dla użytkownika.
Przykładowo, rozważmy poniższą perspektywę zmaterializowaną mv_sprzedaż.
create materialized view mv_sprzedaz
build immediate
refresh force
next sysdate + (1/24)
enable query rewrite
as
select sk.miasto, pr.prod_nazwa, cz.nazwa_miesiaca,
sum(sp.l_sztuk) sprzedano, sum(sp.wartosc) wartosc
from sprzedaz sp, sklepy sk, produkty pr, czas cz
where sp.sklep_id=sk.sklep_id
and sp.produkt_id=pr.produkt_id
and sp.data=cz.data
group by sk.miasto, pr.prod_nazwa, cz.nazwa_miesiaca;
Po poprawnym skonfigurowaniu instancji bazy danych, nadaniu użytkownikowi odpowiednich
uprawnień (por. [Wre00, O10DWG]), zebraniu statystyk dla tabel bazowych perspektywy, zostanie ona wykorzystana do przepisywania zapytań. Przykładowo, wyniki poniższego zapytania zostaną wyznaczone w oparciu o perspektywę mv_sprzedaż, jak pokazuje plan wykonania tego zapytania.
select sk.miasto, pr.prod_nazwa, sum(sp.wartosc) wartosc
from sprzedaz sp, sklepy sk, produkty pr, czas cz
where sp.sklep_id=sk.sklep_id
and sp.produkt_id=pr.produkt_id
and sp.data=cz.data
and sk.miasto='Poznań'
having sum(sp.wartosc)>190
group by sk.miasto, pr.prod_nazwa, cz.nazwa_miesiaca;
Execution Plan
---------------------------------------------------------0
SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=37)
1
0
TABLE ACCESS (FULL) OF 'MV_SPRZEDAZ' (Cost=2 Card=1 Bytes=37)
Hurtownie danych oparte o Oracle9i/10g – przegląd funkcjonalności
205
Praktycznie, w każdej hurtowni danych oprócz tabel zawierających dane elementarne znajdują
się perspektywy zmaterializowane, przechowujące dane zbiorcze/zagregowane na różnych poziomach. Projektując hurtownię danych, należy zapewnić, aby zbiór tych perspektyw był optymalny,
tzn. każda z nich była jak najczęściej wykorzystywana w procesie przepisywania zapytań. Wyznaczenie takiego zbioru perspektyw jest trudne. W tym zakresie baza danych Oracle10g oferuje
narzędzie o nazwie Access Advisor dostępne w postaci pakietu DBMS_ADVISOR. Wykorzystanie jego jest możliwe bezpośrednio z poziomu środowiska SQL*Plus lub z poziomu oprogramowania graficznego Enterprise Manager. Access Advisor umożliwia m.in. określenie: (1) właściwego zbioru zmaterializowanych perspektyw przyspieszających wykonywanie wskazanego
zbioru zapytań, (2) właściwego zbioru indeksów typu B–drzewo i bitmapowych przyspieszających
wykonanie zapytań ze wskazanego zbioru.
6.4. Partycjonowanie
W hurtowni danych największe rozmiary osiągają tabele faktów. Przeszukiwanie dużych tabel
jest czasochłonne, nawet z wykorzystaniem indeksów. Często decydenci są zainteresowani analizą
tylko podzbioru rekordów tabeli, np. ilości sprzedanych produktów z grupy kosmetyki w Wielkopolsce. Dla takiego zapytania, podział dużej tabeli Sprzedaż na mniejsze, np. ze względu na województwa, w których dokonano sprzedaży znacznie skróciłoby czas dostępu do wybranego podzbioru danych.
Fizyczny podział tabeli (lub indeksu) na części jest nazywany partycjonowaniem (ang. partitioning). Każda z części nazywa się partycją (ang. partition). Często jest ona fizycznie umieszczana
na osobnym dysku, znajdującym się w tym samym lub wielu węzłach (komputerach) sieci. Rozmieszczanie danych w poszczególnych partycjach jest realizowane na podstawie wartości wskazanego atrybutu tabeli (indeksu), tzw. atrybutu partycjonującego. Fizycznie podzielona tabela (lub
indeks) stanowi logiczną całość z punktu widzenia użytkownika. Podział dużej tabeli lub indeksu
na mniejsze fragmenty zapewnia, że:
• bardzo kosztowne operacje wejścia/wyjścia, tj. dostępu do dysków mogą być wykonywane równolegle;
• jest równoważone obciążenie dysków;
• polecenia SQL adresujące różne partycje mogą być wykonywane równolegle;
• polecenia SQL mogą adresować konkretną partycję eliminując w ten sposób konieczność przeszukiwania całej tabeli lub indeksu;
• wzrasta bezpieczeństwo danych w przypadku awarii sprzętu ponieważ awaria np. jednego dysku uniemożliwia dostęp tylko do partycji na tym dysku, natomiast partycje
znajdujące się na nieuszkodzonych dyskach są nadal dostępne;
• wzrasta szybkość odtwarzania danych po awarii ponieważ odtwarzaniu podlegają tylko
uszkodzone partycje, a nie cała tabela.
Głównym celem partycjonowania indeksu jest zwiększenie stopnia współbieżności transakcji i
minimalizacja rywalizacji transakcji, poprzez rozproszenie operacji wejścia/wyjścia wykonywanych na indeksie.
Baza danych Oracle9i/10g wspiera trzy następujące techniki partycjonowania rekordów tabeli:
partycjonowanie zakresowe, listowe i haszowe. W partycjonowaniu zakresowym (ang. range partitioning) dla każdej partycji określa się zakres wartości atrybutu partycjonującego. Do danej partycji trafiają więc rekordy ze ściśle określonego dla tej partycji zakresu określonego wartością atrybutu partycjonującego. W partycjonowaniu listowym (ang. list partitioning) dla każdej partycji
określa się zbiór wartości atrybutu partycjonującego. Natomiast w partycjonowaniu haszowym
(ang. hash partitioning) partycja, w której jest umieszczany rekord jest wyznaczana na podstawie
dobieranej przez system funkcji haszowej.
Jako przykład partycjonowania zakresowego bazującego na wartości rozważmy poniższe polecenie create table tworzące tabelę Klienci z podziałem na trzy partycje. Kryterium podziału
206
Robert Wrembel
jest w tym przypadku wartość atrybutu kod_miasta. Klienci z miast o kodach rozpoczynających
się od liter 'A' do 'C' (mniejsze od 'D') zostaną umieszczeni w partycji o nazwie p_klienci_C, klienci z miast o nazwach rozpoczynających się od liter 'D' do 'F' (mniejsze od 'G') zostaną umieszczeni
w partycji o nazwie p_klienci_F, natomiast wszyscy klienci z miast z zakresu 'G' do 'M' zostaną
umieszczeni w partycji p_klienci_M.
create table klienci
(klient_id number(10),
imie varchar2(25),
nazwisko varchar2(25),
kod_miasta varchar2(6))
partition by range(kod_miasta)
(partition p_klienci_C values less than ('D'),
partition p_klienci_F values less than ('G'),
partition p_klienci_M values less than ('N'));
W kolejnym przykładzie klienci_part_hash jest dzielona na pięć partycji umieszczonych
w jawnie wyspecyfikowanych przestrzeniach tabel dane1, dane2 i dane3. Ponieważ liczba partycji
jest większa niż liczba przestrzeni tabel, więc partycje są umieszczane w kolejnych przestrzeniach
tabel za pomocą algorytmu round-robin. Nazwy partycji są nadawane przez system.
create table klienci_part_hash
(klient_id number(10),
imie varchar2(25),
nazwisko varchar2(25),
kod_miasta varchar2(6))
partition by hash(kod_miasta)
partitions 5
store in (dane1, dane2, dane3);
Oracle9i/10g umożliwia tworzenie indeksów partycjonowanych zarówno dla tabel partycjonowanych, jak i niepartycjonowanych. Tabela partycjonowana może natomiast posiadać zarówno
indeks partycjonowany, jak i niepartycjonowany. Jeżeli sposób partycjonowania indeksu jest identyczny ze sposobem partycjonowania indeksowanej tabeli, to indeks taki nazywamy lokalnym
(ang. local). Identyczność partycjonowania oznacza zgodność atrybutów partycjonujących i zakresów partycji. Natomiast jeżeli sposób partycjonowania indeksu jest inny niż sposób partycjonowania tabeli indeksowanej (różne atrybuty partycjonujące tabeli i indeksu, różne zakresy partycji
tabeli i indeksu), to indeks taki nazywamy globalnym (ang. global). Ogólna struktura indeksu lokalnego i globalnego została zilustrowana rysunkiem 7.
Rys. 7. Ogólna struktura indeksu lokalnego i globalnego
Poniższe przykładowe polecenie tworzy indeks lokalny na atrybucie partycjonującym
kod_miasta, tabeli klienci partycjonowanej zakresowo (omówionej wcześniej). Zastosowanie sło-
Hurtownie danych oparte o Oracle9i/10g – przegląd funkcjonalności
207
wa kluczowego local wskazuje, że ma być tworzony indeks lokalny. W rezultacie, zostaną
utworzone trzy odrębne indeksy - po jednym dla każdej z trzech partycji tabeli klienci. Zakresy
wartości indeksu dla danej partycji będą identyczne z zakresem tej partycji tabeli.
create index klienci2_local_indx
on klienci2(kod_miasta)
local
(partition p_klienci_C_indx tablespace dane1_indx,
partition p_klienci_F_indx tablespace dane2_indx,
partition p_klienci_M_indx tablespace dane3_indx);
6.5. Kompresja
W celu zmniejszenia rozmiarów danych przechowywanych w magazynie stosuje się ich kompresję. W Oracle kompresji mogą podlegać następujące obiekty: tabele, perspektywy zmaterializowane, indeksy, tabele partycjonowane lub pojedyncze partycje. Technika kompresji danych
w blokach została zilustrowana rysunkiem 8. W bloku nieskompresowanym powtarzające się wartości atrybutów są przechowywane wielokrotnie. Natomiast w bloku skompresowanym, powtarzające się wartości są umieszczane na początku bloku, w przeznaczonym do tego celu obszarze, natomiast w rekordach są umieszczane wskaźniki do odpowiedniego obszaru wspólnego.
Rys. 8. Przykład kompresji bloków danych
Kompresję danych w blokach wymusza się na poziomie tabeli (polecenia create table,
create table as select) lub całej przestrzeni tabel. Przykładowo, poniższe polecenia
tworzą odpowiednio tabelę skompresowaną i przestrzeń tabel, zapewniającą kompresję tabel
w niej umieszczanych.
create table sprzedaz
(data date not null, produkt_id number(6) not null,
sklep_id number(6) not null, l_sztuk number(5) not null,
wartosc number(9,2) not null,
constraint sprz_pk primary key (data, produkt_id, sklep_id))
compress;
create tablespace dane 1
datafile 'C:\ORA91\ORADATA\DES4072\DANE1.DBF' size 10M autoextend on next 2M
default compress
storage(initial 128K next 128K pctincrease 0 minextents 1);
Oprócz kompresji danych w blokach stosuje się kompresję indeksów B–drzewo i bitmapowych. Kompresja indeksu B–drzewo dotyczy jego liści. W liściu nieskopmpresowanym są przechowywane m.in. pary: wartość indeksowana W – adres rekordu posiadającego wartość W. Jeżeli
indeks założono na atrybucie, którego wartość nie jest unikalna, wówczas wartość indeksowana W,
208
Robert Wrembel
pojawia się w liściach wielokrotnie – tyle razy ile jest rekordów z tą wartością. W przypadku liści
skompresowanych jest budowana lista zawierająca: wartość indeksowaną W i adresy wszystkich
rekordów posiadających wartość W. W ten sposób wartość indeksowana pojawia się w liściu jeden
raz.
Indeksy bitmapowe ulegają kompresji wtedy, gdy liczba zer w mapach bitowych staje się zbyt
duża w porównaniu do liczby jedynek. Jak pokazują eksperymenty (por. [Wre97]), kompresja taka
znacznie zmniejsza rozmiar indeksu bitmapowego. Kompresja map bitowych jest wykonywana
automatycznie przez Oracle i jest niewidoczna dla użytkownika. Kompresję indeksów wymusza
się za pomocą słowa kluczowego compress.
Warto wspomnieć, że kompresji podlegają dane wczytywane do tabeli wyłącznie za pomocą:
(1) polecenia create table as select, (2) równoległego insert ścieżką bezpośrednią
(polecenie insert /* +append*/), (3) programu SQL*Loader z wykorzystaniem ścieżki
bezpośredniej [O10Con]. Dodatkowo, przy przenoszeniu danych do przestrzeni tabel z kompresją
bądź do skompresowanej partycji (polecenie alter table move), dane te są kompresowane.
6.6. Przetwarzanie równoległe
Przetwarzanie równoległe (ang. parallel processing) polega na rozbiciu złożonych operacji na
mniejsze, które następnie są wykonywane równolegle, np. na wielu procesorach lub komputerach.
W efekcie, czas wykonania całej operacji jest krótszy. W przypadku hurtowni danych, najczęściej
równolegle przetwarza się zapytania, buduje tablice i indeksy.
Przykładowo, poniższe polecenie odczytuje zawartość tabeli Sprzedaż z wykorzystaniem 5
równoczesnych procesów.
select /*+ PARALLEL(sp, 5) */ sklep_id, sum(ilosc)
from sprzedaz sp
group by sklep_id;
Kolejne polecenie tworzy tabelę sklepy_kopia z wykorzystaniem 3 równocześnie działających
procesów.
create table sklepy_kopia parallel 3 as select * from sklepy;
Przetwarzanie równoległe można również stosować w czasie wczytywania danych z plików
zewnętrznych za pomocą SQL*Loader, tabel zewnętrznych, datapump export/import oraz w czasie archiwizowania i odtwarzania bazy danych po awarii.
7. Podsumowanie
W zakresie magazynów danych firma Oracle Corp. dostarcza oprogramowania niezbędnego
w każdym etapie projektowania i wykorzystywania takich systemów. Główne aspekty technologiczne obejmują: (1) projektowanie magazynu danych, (2) jego zasilanie danymi, (3) wykorzystanie jego zawartości w przetwarzaniu analitycznym, (4) efektywność dostępu do danych. Poniższa
tabela koreluje ww. aspekty technologiczne z narzędziami programistycznymi/mechanizmami
udostępnianymi przez Oracle.
Funkcjonalność
Cechy
Narzędzia programistyczne/mechanizmy
ROLAP
MOLAP
SQL, Designer, Enterprise Manager
SQL, Enterprise Manager, Analytic Worskpace Manager,
pakiety: DBMS_AWM, DBMS_AW, OLAP_TABLE,
DBMS_AW_UTITLITIES, rodzina CWM2
Projektowanie
Zasilanie (ETL)
Hurtownie danych oparte o Oracle9i/10g – przegląd funkcjonalności
209
dostęp do źródeł
bazodanowych
nie- SQL*Loader, pakiet UTL_FILE, tabele zewnętrzne,
funkcje tablicowe
dostęp do źródeł bazodano- Oracle Transparent Gateways do: IBM, Sybase, Microsowych innych producentów
ft, NCR, sterowniki ODBC/JDBC, wielotabelowy insert,
polecenie merge, insert ścieżką bezpośrednią
dostęp do innych baz da- perspektywy zmaterializowane, eksport/import, datanych Oracle
pump eksport/import, wielotabelowy insert, polecenie
merge, insert ścieżką bezpośrednią
Analiza danych
Funkcje analityczne SQL
Funkcje eksploracyjne
Aplikacje graficzne
kilkadziesiąt specjalizowanych funkcji SQL, rozszerzenie polecenia select o klauzule: group by cube, group by
rollup, group by grouping sets, case, with i model
interfejs PL/SQL - pakiet DBMS_DATA_MINING i
Java
Discoverer, pakiet Business Intelligence Beans, JDeveloper, Reports9i/10g, Sales Analyzer, Financial Analyzer
Efektywność systemu
Indeksowanie
Optymalizacja zapytań
indeksy bitmapowe i bitmapowe połączeniowe
kosztowy optymalizator zapytań - optymalizowanie zapytań gwiaździstych
Perspektywy zmaterializo- kosztowy optymalizator zapytań - przepisywanie zapytań
wane
Partycjonowanie
SQL, Enterprise Manager - partycjonowanie tabel i indeksów
Kompresja
SQL, Enterprise Manager - kompresja tabel, przestrzeni
tabel i indeksów
Przetwarzanie równoległe
SQL, Enterprise Manager
Bibliografia
[HHL03]
[O10Con]
[O10DWG]
[O10OLAP]
[olap]
[Tom]
[Wre97]
[Wre00]
Hobbs L., Hillson S., Lawande S.: Oracle 9iR2 Data Warehousing. Digital Press, 2003,
ISBN 1-55558-287-7
Oracle Database. Concepts. 10g Release 1
Oracle Database. Data Warehousing Guide. 10g Release 1
Oracle OLAP. Application Developer's Guide. 10g Release 1
http://www.oracle.com/olap/
http://asktom.oracle.com/
Wrembel R.: Nowe struktury indeksów dla magazynów danych. Materiały III Konferencji
Użytkowników i Developerów Oracle – PLOUG’97, Zakopane, 1997
Wrembel R.: Perspektywy (views) w systemach baz danych: aktualny stan technologii. Materiały VI Konferencji Użytkowników i Developerów Oracle – PLOUG'2000, Zakopane, 2000