AKADEMIA GÓRNICZO-HUTNICZA

Transkrypt

1 AKADEMIA GÓRNICZO-HUTNICZA Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki KATEDRA INFORMATYKI Hurtownia danych na przykładzie systemu billingowego. Kierunek, rok studiów: Informatyka, IV rok Przedmiot: Bazy danych Wersja z dnia Grupa (projekt): Prowadzący zajęcia: Rok akad: 2003/2004 mgr inż. Bartłomiej Śnieżyński Zespół autorski: Marek Wiącek Paweł Zawada Paweł Trendota mwiacek@student.uci.agh.edu.pl pzawada@student.uci.agh.edu.pl paweltre@student.uci.agh.edu.pl Kraków, styczeń 2004

2 Niniejsze opracowanie powstało w trakcie i jako rezultat zajęć dydaktycznych z przedmiotu wymienionego na stronie tytułowej, prowadzonych w Akademii Górniczo-Hutniczej w Krakowie (AGH) przez osobę (osoby) wymienioną (wymienione) po słowach "Prowadzący zajęcia" i nie może być wykorzystywane w jakikolwiek sposób i do jakichkolwiek celów, w całości lub części, w szczególności publikowane w jakikolwiek sposób i w jakiejkolwiek formie, bez uzyskania uprzedniej, pisemnej zgody tej osoby (tych osób) lub odpowiednich władz AGH. (AGH) w Krakowie Spis treści 1. Wprowadzenie 3 2. Opis systemu 4 3. Warehouse 6 Wymiary 6 Cube y 6 Mapowania 8 Optymalizacja 9 4. Platforma i narzędzia 10 Oracle Warehouse Builder 10 Oracle Discoverer Procedura instalacyjna 13 2

3 1. Wprowadzenie Hurtownia danych, inaczej nazywana magazynem danych lub data warehouse jest to wydzielona baza danych, której zadanie polega na gromadzeniu danych potrzebnych do zarządzania przedsięwzięciem. Baza to znajduje się w odosobnieniu od baz operacyjnych i powinna być zoptymalizowana pod kątem przetwarzania analitycznego. Fakt, że baza ta znajduje się w odosobnieniu nie oznacza jednak, że hurtownia nie korzysta z danych operacyjnych. Te właśnie dane są punktem wyjścia przetwarzania analitycznego. Okresowo są one zbierane i przetwarzane w celu dalszej analizy. Hurtownia danych różni się od zwykłych baz również pod kątem organizacji danych. Zwykłe bazy mogą być i często są rozproszone (na przykład informacje zbierane z różnych regionów sprzedaży znajdują się lokalnie w centrach sprzedaży) podczas gdy hurtownia z natury jest scentralizowana, łączy ona informację z wielu źródeł, zbiera dane uporządkowane tematycznie. Hurtownie oprócz danych elementarnych przekopiowanych z baz operacyjnych, zawierają one agregaty, czyli obliczone wartości pewnych danych np. średnie lub sumy. 3

4 2. Opis systemu Zakładamy, że realizowana hurtownia danych ma służyć analizie systemu bilingowego. System ten, gdyby został zrealizowany w wersji operacyjnej, miałby przede wszystkim możliwość rejestrowania prowadzonych rozmów i przesyłanych wiadomości, wraz ze wszystkimi danymi organizacyjnymi, takimi jak szczegółowe dane dotyczące użytkownika, jego wykształcenia, zarobków, miejsca zamieszkania itp. Jednak w naszym przypadku wersja operacyjna jest potrzebna jedynie jako źródło danych do analizy. Poniżej znajduje się graficzna ilustracja modelu danych wykorzystanego w bazie operacyjnej. 4

5 Obejmuje on następujące tabele: Accounts każde konto odpowiada jednemu numerowi telefonicznemu Calls zbiór wszystkich rozmów zarejestrowanych przez system CityPopulationGrades tabela pomocnicza służąca zaszeregowaniu miast pod względem liczności populacji Messages zbiór wszystkich wiadomości zarejestrowanych przez system Provinces zawiera mniejsze okręgi, które wchodzą w skład regionów Regions zawiera zbiór większych regionów, na które podzielony jest obszar objęty działaniem systemu SalaryGrades tabela pomocnicza służąca zaszeregowaniu zarobków użytkowników TarificationPlans zbiór planów taryfowych dla kont Users zbiór wszystkich użytkowników zarejestrowanych w systemie W celu wypełnienia powyższych tabel został napisany generator w języku Java. Połączenie z bazą danych uzyskuje się za pomocą mechanizmu JDBC. Tabele pomocnicze, takie jak Provinces, Regions czy SalaryGrades mają statycznie zdefiniowany zbiór danych przeznaczonych do wpisania do bazy danych, natomiast tabele, których zawartość ma odpowiadać danym generowanym przez rzeczywisty system jest wypełniana danymi losowymi. Przykłady takich tabel to Users, Messages, Calls. 5

6 3. Warehouse Wymiary WH_EDUCATION - wykształcenie WH_TARIFICATION_PLAN - plan taryfowy WH_CITY_POP_GRADE - wielkość miasta WH_SALARY_GRADE - wysokość zarobków WH_TIME - czas (hierarchia: rok, kwartał, miesiąc) WH_GENDER - płeć WH_REGION - region (hierarchia: region Polski, województwo) Poniżej przedstawione są dwa wymiary hierarchiczne: czasowy i terytorialny, pozostałe posiadają jeden poziom hierarchii. Cube y WH_INCOME - przychody z połączeń i wiadomości w regionach, taryfach i czasie. Miary przychody z połączeń i przychody z wiadomości. W większości systemów tego typu kostki mają największe znaczenie. Pozwalają łatwo znaleźć elementy generujące największe i najmniejsze przychody w przestrzeni i czasie. 6

7 WH_USERS - użytkownicy wg wymiarów: region, płeć, wykształcenie, wielkość miasta, wielkość zarobków. Miara liczba użytkowników Ta kostka daje ogólny pogląd o użytkownikach systemu. Ze względu na dużą liczbę wymiarów są tu szerokie możliwości analizy, wyszukiwania zależności pomiędzy grupą społeczną a liczbą użytkowników. WH_NEW_USERS - nowi użytkownicy na przestrzeni czasu w różnych regionach. Miara liczba użytkowników 7

8 Ta kostka pozwoli zanalizować, które regiony są najbardziej rozwojowe pod względem możliwości pozyskiwania nowych użytkowników. Dodatkowo uwidoczniona zostanie zmienność przyrostu użytkowników na przestrzeni czasu. Taka wiedza może się przydać na przykład, aby stwierdzić które miesiące są najlepsze dla promocji mających na celu zwerbowanie użytkowników. Mapowania Mapowania wyznaczają sposób budowy hurtowni na podstawie bazy operacyjnej. Możliwe mapowania to na przykład mapowanie tabeli do wymiaru lub zapytania do kostki (w naszym przypadku są to mapowania perspektyw zmaterializowanych do kostek). Mapowania wymiarów: WH_CITY_POP_GRADE_MAP WH_EDUCATION_MAP WH_GENDER_MAP WH_REGION_MAP WH_SALARY_GRADE_MAP WH_TARIFICATION_PLAN_MAP Mapowania kostek: WH_USERS_MAP WH_NEW_USERS_MAP WH_INCOME_MAP 8

9 Optymalizacja W przypadku hurtowni danych optymalizacja ma bardzo duże znaczenie. Nie chodzi tu o samą wygodę użytkowania, lecz o niebezpieczeństwo, że czas obliczania bardziej złożonych zapytań analitycznych może sięgać nawet dni, a więc przekraczać granice akceptowalnego czasu. Aby temu zapobiec, stosuje się techniki optymalizacyjne. Jedną z takich podstawowych technik jest zastosowanie perspektyw zmaterializowanych (materialized views). Umożliwiają one składowanie wyników zapytań w postaci tabel bazy danych. Często zdarza się na przykład, że zapytanie do bazy zawiera czasochłonne wyliczenia wartości zagregowanych. W przypadku użycia perspektywy zmaterializowanej wartości te zostaną fizycznie zapisane w bazie i zostaną użyte przy ponownym odwołaniu się do nich. Jednak wykorzystując mechanizm perspektyw zmaterializowanych należy się wykazać pewną ostrożnością, gdyż może wystąpić problem aktualności danych w nich zawartych. Dostępna jest funkcjonalność odświeżania danych w perspektywach asynchroniczna lub synchroniczna czyli wyzwalana przez przyczynę zewnętrzną lub podczas zmiany danych źródłowych. 9

10 4. Platforma i narzędzia Do realizacji projektu wykorzystaliśmy bazę danych Oracle 9i. Ta platforma bazodanowa posiada zestaw narzędzi zgrupowanych pod nazwą Oracle Warehouse Builder czyli OWB znacznie ułatwiających tworzenie hurtowni danych i przesuwanie danych z bazy operacyjnej do analitycznej. Korzystaliśmy z OWB w wersji 9.2. Oracle Warehouse Builder Oracle Warehouse Builder służy do projektowania hurtowni danych. Umożliwia definiowanie źródeł danych, projektowania struktur hurtowni a także tworzenie procedur transformacji danych. Procedury transformacji danych tworzy się za pomocą interfejsu graficznego używając operatorów mapowania, przy pomocy których można zdefiniować większość przekształceń. Oracle Warehouse Builder umożliwia zarządzanie zmianami w strukturach wejściowych i docelowych. Różnice występujące pomiędzy aktualnym projektem, a definicją zewnętrznych tabel są wykrywane przez narzędzie i możliwe do automatycznego wprowadzenia do repozytorium. Oracle Discoverer Oracle Discoverer jest rozwiązaniem umożliwiającym definiowanie i wykonywanie analiz przekrojowych na bazie zdefiniowanych struktur. W jego skład wchodzą dwie aplikacje: Oracle Discoverer Administrator i Oracle Discoverer Desktop. Oracle Discoverer Administrator służy do definiowania struktur, które są wykorzystywane do właściwej analizy. 10

11 Oracle Discoverer Desktop jest przeznaczony dla użytkownika końcowego, służy do przeprowadzania analiz danych. Użytkownik może wybrać interesujące go dane, zanalizować je oraz zobaczyć wyniki w postaci tabelarycznej lub graficznej. Można także prowadzić interaktywną analizę danych, polegającą na drążeniu w górę, w dół oraz do powiązanych elementów, sortowanie danych itp. Narzędzie to jest stosunkowo proste w obsłudze, ale jednocześnie rozbudowane i oferujące sporą funkcjonalność. Poniżej przykładowy widok analizy dane o przychodach z połączeń we wszystkich regionach przedstawione na wykresie kołowym. 11

12 12

13 5. Procedura instalacyjna Poniżej zamieszczamy kompletny opis instalacji i uruchomienia hurtowni. Wszystkie potrzebne dane oprócz narzędzi są dostarczone wraz z końcową wersją projektu. 1. Zainstalować serwer Oracle9i. 2. Utworzyc uzytkownika dla bazy OLTP: CREATE USER wh IDENTIFIED BY whpassword; GRANT CONNECT, RESOURCE TO wh; 3. Wykonać skrypt create-db.sql na schemacie wh. 4. Uruchomić generator napisany w Javie. 5. Zainstalować OWB (musi być zarówno po stronie serwera, jak i klienta, chyba że uruchamia się wszystko na jednej maszynie). 6. Uruchomić OWB Repository Assistant i stworzyć repozytorium w schemacie owb. 7. Uruchomic Runtime Assistant i stworzyć Runtime w schemacie owbr oraz użytkownika dostępowego owbra. 8. Stworzyć dla runtime nowy Target Schema w schemacie owbts. 9. Uruchomić skrypt grant.sql jako SYSDBA. 10. Uruchomić OWB Client, zaimportować metadane. 11. W OWB Client zmodyfikować lokacje, aby odwoływały się do właściwej bazy danych. 12. Wykonać deploy na obiektach w takiej kolejnosci: - Funkcje, - Widoki z Warehouse'a - Wymiary, - Cube'y - Procedury - Mapowania dla wymiarów - Mapowania dla cube'ów 13. Wykonać WH_POPULATE_TIME w schemacie owbra. 14. Wykonać mapowania: - Uruchomić mapowania (Deployment manager -> menu kontekstowe -> Execute) dla wymiarów. - Uruchomić mapowania dla cube'ow. 13

14 14