Prototypowy system magazynu danych dla przetwarzania analitycznego w trybie on-line

Spis treści

I Wstęp              3

I.1. Cel i zakres pracy              4

I.2. Podział zadań              6

II Przetwarzanie analityczne w trybie on-line (OLAP)              8

II.1. Wprowadzenie              8

II.2. Cechy OLAP              9

II.3. Podział systemów OLAP              12

III Magazyny danych (data warehouse)              19

III.1. Wprowadzenie              19

III.2. Definicja hurtowni danych              20

III.3. Funkcje hurtowni danych              20

III.4. Architektura hurtowni danych              22

IV Metody i narzędzia              23

IV.1. Język SQL i relacyjne bazy danych              23

IV.1.1. Geneza języka. Jego funkcja w SZBD              24

IV.1.2. Sposoby użycia SQL’a              24

IV.1.3. Zasady SQL’a i relacyjnych baz danych              25

IV.1.4. Łączenie tablic              25

IV.1.5. Podstawy języka SQL              26

IV.2. Metody dostępu do baz danych z poziomu języków programowania wysokiego poziomu              28

IV.2.1. Open Database Connectivity (ODBC)              28

IV.2.2. Java Database Connectiviy (JDBC)              28

IV.2.3. Oracle Call Interface (OCI)              30

IV.3. Komunikacja sieciowa              33

IV.3.1. Protokół TCP/IP              33

IV.3.2. Wykorzystanie protokołów sieciowych w językach C/C++              37

IV.3.3. Wykorzystanie protokołów sieciowych w języku Java              38

IV.4. Narzędzia do budowy parserów              38

IV.4.1. Analiza leksykalna – Lex              39

IV.4.2. Analiza składniowa – Yacc              44

V Projekt systemu magazynu danych – architektura              50

V.1. Założenia projektowanego systemu              50

V.2. Architektura systemu              51

V.3. Wymagania dla źródłowych baz danych              52

V.4. Funkcje poszczególnych modułów systemu              55

VI Implementacja systemu              57

VI.1. Struktura magazynu              57

VI.1.1. Słownik (metadata store)              58

VI.1.2. Część magazynowa              65

VI.2. Program konfiguracji słownika systemu              68

VI.3. Moduł komunikacji z użytkownikiem (query processor)              68

VI.3.1. Założenia projektowe              68

VI.3.2. Zadanie query processora              69

VI.3.3. Wymagany format zapytania              71

VI.3.4. Uwagi implementacyjne              73

VI.3.5. Moduły składowe query processora              73

VI.3.6. Etapy działania programu              77

VI.3.7. Wykorzystane narzędzia              82

VI.3.8. Przenośność kodu              83

VI.3.9. Wykorzystanie modułu we własnych aplikacjach. Składowe publiczne klasy CWarehouseConnection              83

VI.4. Moduł integratora              85

VI.4.1. Zadanie integratora              85

VI.4.2. Założenia implementacyjne              85

VI.4.3. Faza inicjalizacji magazynu danych              85

VI.4.4. Faza pielęgnacji magazynu danych              86

VI.4.5. Implementacja modułu integratora              86

VI.4.6. Rozbudowa modułu integratora              92

VI.5. Moduł monitora              93

VI.5.1. Zadanie monitora              93

VI.5.2. Założenia implementacyjne              93

VI.5.3. Implementacja              95

VI.6. Moduł osłony (wrapper)              97

VI.6.1. Funkcje modułu osłony              97

VI.6.2. Założenia implementacyjne              97

VI.6.3. Zasada działania wrappera              98

VI.6.4. Komunikacja z modułem integratora              99

VI.6.5. Zaimplementowane funkcje              99

VI.6.6. Uwagi końcowe              100

VII Instrukcja użytkownika              101

VII.1. Program konfiguracyjny słownika magazynu              101

VII.2. Query processor              110

VII.3. Uruchomienie modułu wrappera              111

VII.4. Uruchomienie modułu monitora              112

VIII Przykładowa sesja z systemem              113

IX Zakończenie              117

X Literatura              120

I Wstęp

Działalność każdej firmy wiąże się z tworzeniem i zapamiętywaniem dużej ilości danych różnego rodzaju – o klientach, rynkach, sprzedaży. W przypadku dużych firm ilość tych danych jest ogromna i stale rośnie. Oczywiście dane te nie są gromadzone bez powodu – ich staranna analiza dostarcza wielu informacji i często ułatwia podejmowanie strategicznych dla firmy decyzji. W praktyce okazuje się jednak, że im większa liczba danych, tym trudniejszy dostęp do nich. Jesteśmy wprawdzie w stanie je magazynować, jednak ich ilość uniemożliwia efektywne odszukiwanie i przeglądanie  niezbędnych informacji. Eksperci szacują, że w dużych firmach decydenci mają dostęp do bardzo niewielkiej części zgromadzonej informacji, a przecież właśnie ona stanowi podstawę, przy podejmowaniu ważnych decyzji. Zjawisko to określa się czasem „uwięzieniem danych”.

Magazyn danych (hurtownia danych, ang. data warehouse) jest próbą rozwiązania tego problemu – wydobycia z ogromnych baz danych niezbędnej wiedzy. Hurtownie przechowują informację, analizowaną później z wykorzystaniem technik OLAP (przetwarzanie analityczne na bieżąco – On-Line Analitycal Processing), a przechowywana informacja ma zwykle charakter wielowymiarowy. Hurtownie danych są więc praktycznym wykorzystaniem trzech nowoczesnych trendów rozwojowych obejmujących:

· przetwarzanie analityczne na bieżąco (OLAP – on-line anaytical processing),

· wielowymiarowe bazy danych,

· odkrywanie wiedzy.

I.1. Cel i zakres pracy

Celem pracy jest zaprojektowanie i implementacja systemu hurtowni danych o określonych wymaganiach. Najważniejsze przedstawiono poniżej:

· W odróżnieniu od istniejących i działających na rynku systemów OLAP, chcielibyśmy, aby nasz system utrzymywał przez cały czas pracy aktualne dane – czyli dbał o ich spójność z danymi zawartymi w źródłowych bazach danych. Cecha ta staje się pożądana ponieważ od aktualnej informacji zgromadzonej w hurtowni zależą strategiczne decyzje dotyczące rozwoju firmy.

· Wymóg aktualności danych w magazynie stawia kolejne wymaganie – efektywność procesu aktualizacji danych w magazynie. Pożądane jest zminimalizowanie czasu między zmianą danych w źródłowych bazach danych, a aktualizacją danych w magazynie. Dlatego przyjęliśmy, że dane w magazynie powinny być składowane przyrostowo (inkrementalnie) – oznacza to aktualizowanie magazynu jedynie o nowe informacje, uwzględniając jego poprzednią zawartość.

· Praktyka pokazuje, że gotowe oprogramowanie wymaga pielęgnacji, a praca nad projektem kończy się dopiero w momencie zaprzestania jego używania. Dlatego podstawową cechą umożliwiającą użytkowanie systemu i dostosowywanie do zmieniających się warunków jego pracy jest łatwość jego rozbudowy. Chodzi przede wszystkim o możliwość obsługi nowych standardów baz danych oraz możliwość wykorzystania informacji magazynowych w tworzonych na potrzeby firmy aplikacjach.

Architektura systemu

Na poniższym rysunku przedstawiono schemat systemu umożliwiającego spełnienie podanych wymagań:

Otoczenie systemu stanowią źródłowe bazy danych (na rysunku źródła) i z nich czerpane są informacje, które magazynujemy. Miejscem ich magazynowania jest magazyn danych (ang. data warehouse). Jak widać na rysunku, całość systemu składa się z czterech modułów. Moduł integratora jest odpowiedzialny, za składowanie danych w magazynie. Nie odwołuje się on jednak bezpośrednio do źródłowych baz danych, lecz za pośrednictwem modułów pomocniczych. Monitor zajmuje się „śledzeniem” zmian w źródłowej bazie danych i informowaniem o tym integratora. Na tej podstawie integrator wykonuje aktualizację magazynu. Używa w tym celu modułu wrappera, jako pośrednika w odwołaniach do baz danych. Integrator nie musi więc znać szczegółów implementacyjnych związanych z źródłowymi bazami danych. Wszystkie informacje złożone w magazynie są dostępne dla użytkownika za pomocą modułu query processora. Stanowi on interfejs, między magazynem a użytkownikiem – transformuje zapytania użytkownika, wykonuje je i dostarcza gotowe wyniki.

Z przyjętych wcześniej założeń wynika przydział dla każdej źródłowej bazy danych osobnej pary monitor / wrapper. Jedynie te moduły komunikują się bezpośrednio z bazami źródłowymi, więc jedynie one muszą znać odpowiednie protokoły komunikacji i sposoby wymiany danych. Umożliwia to uniezależnienie systemu od systemów zastosowanych w źródłowych bazach danych. Jeżeli chcemy rozbudować nasz system o obsługę nie znanego standardu bazy danych, musimy dopisać te dwa moduły.

Zakres pracy obejmuje zaprojektowanie i implementację czterech modułów systemu:

· moduł monitora,

· moduł wrappera,

· moduł integratora,

· moduł query processora.

Zakładamy opracowanie jednej pary monitor / wrapper dla systemu zarządzania bazą danych firmy Oracle. Zakładamy również, że magazyn danych opierać się będzie również na systemie firmy Oracle. Częścią pracy jest opracowanie ujednoliconych protokołów komunikacji między poszczególnymi modułami a także postaci naszego magazynu – jego słownika i części magazynowej.

I.2. Podział zadań

Projektując nasz system, podzieliliśmy się zadaniami w następujący sposób:

· moduł wrappera – Daniel Krawiec,

· moduł monitora – Paweł Orzechowski,

· moduł integratora – Krzysztof Ostrowski,

· moduł query processora – Arkadiusz Kaźmierowski.

Zadania opracowania specyfikacji odpowiednich protokołów komunikacyjnych i postaci magazynu przypadają twórcom modułów z nich korzystających, tak więc:...