Hurtownie danych oparte o Oracle9i/10g – przegląd funkcjonalności
advertisement
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
