Metody i technologie budowy hurtowni danych ze szczególnym
Transkrypt
Metody i technologie budowy hurtowni danych ze szczególnym
Zakład Zaawansowanych Technik Informacyjnych Z-6 Metody i technologie budowy hurtowni danych ze szczególnym uwzględnieniem zapewnienia długookresowej jakości produktu Praca nr 06.30.002.7 Warszawa 2007 – 12 – 7 Metody i technologie budowy hurtowni danych ze szczególnym uwzględnieniem zapewnienia długookresowej jakości produktu Praca nr 06.30.002.7 Słowa kluczowe (maksimum 5 słów): Hurtownie Danych, Jakość danych Kierownik pracy: mgr inż. Mariusz Pajer Wykonawcy pracy: dr inż. Janusz Granat mgr inż. Michał Majdan mgr inż. Robert Kuśmierek mgr inż. Cezary Chudzian mgr inż. Marcin Salwa mgr inż. Jarosław Sobieszek Kierownik Zakładu: dr inż. Janusz Granat © Copyright by Instytut Łączności, Warszawa 2007 4 Spis Treści 1. Wstęp ...............................................................................................................................4 2. Przegląd stosowanych technologii i metod.......................................................................4 2.1. Podstawy hurtowni danych .......................................................................................4 2.2. Typowe metody i technologie budowy hurtowni danych...........................................5 2.2.1. Warstwa konceptualno-funkcjonalna ................................................................6 2.2.2. Warstwa logiczna..............................................................................................9 2.2.3. Warstwa fizyczna............................................................................................14 2.2.4. Narzędzia użyteczne w budowie hurtowni danych .........................................17 2.3. Zastosowanie ASM do budowy hurtowni danych ...................................................17 3. Opracowana metodyka...................................................................................................18 4. Moduł Sterujący..............................................................................................................20 4.1. 4.1.1. Uruchomienie..................................................................................................23 4.1.2. Konfiguracja....................................................................................................24 4.1.3. Zatrzymanie aplikacji ......................................................................................25 4.1.4. Komunikacja systemu z użytkownikiem..........................................................26 4.1.5. Realizowana funkcjonalność ..........................................................................26 4.2. Działanie i budowa systemu ...................................................................................27 4.2.1. Działanie systemu...........................................................................................27 4.2.2. Struktura aplikacji ...........................................................................................29 4.3. 5. Funkcjonalność systemu ........................................................................................22 Dalsze plany rozwoju..............................................................................................31 Wnioski ...........................................................................................................................32 Bibliografia..............................................................................................................................33 3 1. Wstęp Hurtownie danych (HD) są złożonymi systemami informatycznymi, które przetwarzają i łączą dane pochodzące z różnych źródeł w zunifikowane struktury, aby nadać im jakość i formę niezbędną dla celów analitycznych. Taka definicja HD zwraca uwagę na wymiar jakości a zwłaszcza jakości danych, który współdecyduje o tym, czy zbudowana wysokim nakładem pracy HD będzie dostarczać danych godnych zaufania, czy też przedstawi ich fałszywy obraz. Z problem tym stykają się członkowie zespołu realizującego niniejszą pracę wdrażając i utrzymując HD. Dlatego w ramach niniejszej pracy opracowano nową metodykę. Uzupełnia ona dotychczas stosowane metodyki budowy HD o nowe metody, które zapewnią jakość danych od momentu ich ekstrakcji do HD aż do prezentacji użytkownikowi końcowemu. Metody te dotyczą aspektu przetwarzania i przepływu danych w HD, dla którego istotne jest wprowadzenie modularyzacji kolejnych kroków przetwarzania danych, powiązanie ich w łańcuchy oraz wprowadzenie zewnętrznej aplikacji, która uruchamia kolejne moduły oraz nadzoruje przetwarzanie, przepływy i jakość danych. Modularyzacja umożliwia optymalizację wydajności przetwarzania danych, stopniową kontrolę jakości danych w trakcie przetwarzania oraz w prowadzenie mechanizmów zwrotnych pozwalających na wykrycie i opanowanie anomalii przed uzyskaniem zafałszowanych wyników końcowych. Modularyzacja sprzyja wreszcie wprowadzaniu zmian w HD i utrzymaniu HD oraz ogranicza ich koszty. Moduły przetwarzające dane w HD układają się w łańcuchy, które tworzą wzorce przepływu i przetwarzania danych. Metodyka korzystająca ze wzorca wymaga użycia lub stworzenia systemu sterującego przetwarzaniem zgodnie ze zdefiniowanymi dla HD wzorcami. W ramach niniejszej pracy zaimplementowano w języku Java system nazwany Modułem Sterującym, który służy do wykonywania procesów ETL, zgodnie ze zdefiniowanym wzorcem. Moduł Sterującym oraz niniejszy raport są głównymi produktami pracy 06.30.002.7. 2. Przegląd stosowanych technologii i metod 2.1. Podstawy hurtowni danych Wdrożenie hurtowni danych następuje najczęściej wtedy, kiedy osoby decydujące o funkcjonowaniu (lub zarządzające wybranymi obszarami działalności) przedsiębiorstwa dochodzą do wniosku, że posiadane przez nich narzędzia analityczne nie pozwalają im na podjęcie decyzji w oparciu o wystarczającą liczbę danych, z użyciem wszystkich koniecznych źródeł danych lub w dostatecznie szerokim zestawieniu kategorii i kryteriów. Kryteria, względem których analizuje się obiekty ewidencjonowane w HD nazywa się miarami. Kategorie obiektów podlegających analizie nazywa się wymiarami. Szczególnym i naturalnym wymiarem analiz jest czas (agregacja lub porównywanie wartości miar w czasie). Zgodnie z koncepcją hurtowni danych, dane zapisane w HD nie ulegają modyfikacjom, dlatego cykliczne zapisywanie danych do HD tworzy w niej historyczny obraz danych, których czas zapisu można ewidencjonować się przy pomocy stempli czasowych. Wdrożenie HD bywa często elementem strategii uporządkowania i usystematyzowania analiz wybranego obszaru działalności przedsiębiorstwa. Typowymi przykładami zastosowania danych zgromadzonych w HD są analizy zysku wobec kosztów, przychodu wobec sprzedaży, preferencji i charakterystyki zachowań klientów. HD są repozytoriami danych (lub po prostu bazami danych), których działanie jest zoptymalizowane w kierunku raportowania danych i które przechowują dane w strukturach zdefiniowanych przez analizy (do których mają służyć), aby jak najkrócej i jak najbardziej płynnie następowało wybieranie danych z HD do prezentacji dla użytkownika końcowego. 4 Struktury danych składowanych w HD są w pełni zgodne ze strukturami będącymi przedmiotem analiz (na przykład kategorie biznesowe są wymiarami), tak aby nawet najbardziej złożone analizy można było prowadzić w czasie rzeczywistym, z tego powodu hurtownie danych określa się mianem systemów przeznaczonych do zadań typu OLAP (Online analytical processing) lub określa się wprost mianem systemów typu OLAP. Struktury hurtowni danych widoczne z perspektywy narzędzi analitycznych określa się mianem data marts [4]. Tym samym mianem określa się również tematyczne hurtownie danych. HD integruje i gromadzi w jednym miejscu dane pochodzące z wielu źródeł, którymi są najczęściej transakcyjne bazy danych służące do działań operacyjnych, na przykład bieżącego ewidencjonowania działań, zasobów, produktów, usług czy klientów przedsiębiorstwa. Transakcyjne bazy danych służące do działań operacyjnych są z reguły systemami typu OLTP (On-line transactional processing), ponieważ są zoptymalizowane do wykonywanie bieżących czynności ewidencyjnych przy użyciu tzw. transakcji, tak aby zawierać zawsze aktualne informacje o stanie ewidencjonowanych obiektów. Wypełnienie struktur HD następuje na drodze złożonego procesu, który określa się mianem ETL (Extraction – Transformation – Loading) – ekstrakcja, transformacja i ładowanie. Ekstrakcją danych nazywa się pobranie danych z pierwotnych Źródeł Danych (ŹD, czyli z operacyjnych systemów informacyjnych) dla potrzeb HD. Dane z ŹD od HD pobiera się najczęściej cyklicznie. Z uwagi na zazwyczaj dużą liczbę pobieranych danych czyni się to przyrostowo, a operacja pobrania wymaga najczęściej dużego obciążenia ŹD. Dane pobrane z ŹD ulegają najczęściej szeregu przekształceń, transformacji i integracji przed złożeniem do końcowych struktur danych w HD. Jest to spowodowane koniecznością ich oczyszczenia i unifikacji, a także ma na celu wykonanie niezbędnych obliczeń i porównań. Czynności przekształcania i wpasowywania danych w końcowe struktury HD nazywa się transformacją i ładowaniem. Jak wspomniano, HD są zoptymalizowane pod kątem raportowania i zawierają dane w strukturach przeznaczonych do bezpośredniej prezentacji, co powoduje, że struktury przechowywanych danych są nie znormalizowane a same dane są redundantne. Redundancja jest wymuszona na przykład koniecznością składowania wartości miar dla każdego z poziomów agregacji dowolnego z wymiarów. Przykładem może być składowanie danych dla potrzeb analizy sprzedaży, w której zachodzi konieczność prezentacji liczby lub wartości sprzedaży (miary) na poziomie każdego roku, półrocza, kwartału, miesiąc i dnia. Zagregowane wartości liczby lub wartości sprzedaży muszą być zapisane w HD, aby można je było zaprezentować bez konieczności wykonania obliczeń w trakcie prezentacji, co prowadzi do redundancji informacji i danych mówiących o wartości lub liczbie sprzedaży. Należy również zauważyć, że wartości obliczane dla przytoczonych powyżej agregacji są wyliczane i zapisywane do struktur HD w trakcie procesu ETL. 2.2. Typowe metody i technologie budowy hurtowni danych Budowa hurtowni danych jako źródła informacji dla analiz biznesowych, które powstają na drodze integracji i przekształceń danych pochodzących z wielu źródeł warunkuje złożoność tego procesu. Metodologie budowy HD muszą obejmować między innymi: − jak najszersze i jak najbardziej dokładne modelowanie tych obszarów działalności przedsiębiorstwa, które będą objęte analizami wykonywanym przy użyciu informacji składowanych w hurtowni danych; − wszystkie pojęcia, obiekty i działania, które będą ujęte w źródłach danych zasilających hurtownie oraz wszystkie pojęcia, obiekty i działania, które będą odwzorowywane w hurtowni a także ich wzajemne relacje; − zaprojektowanie struktury danych hurtowni odpowiadające potrzebom analiz; 5 − zrozumienie funkcjonowania systemów źródłowych i identyfikację struktur, które będą dostarczać danych do zasilania HD, a także ich przełożenia na struktury hurtowni danych; − wybór technologii implementacji HD, wykonania procesów ETL oraz dostarczenia analiz użytkownikowi końcowemu (interfejs użytkownika). Wykonanie powyższych prac wymaga współdziałania pomiędzy specjalistami w dziedzinie budowy hurtowni danych a osobami planującymi analizy, odbiorcami analiz i osobami posiadającymi wiedzę na potencjalnych i zidentyfikowanych źródeł danych. Czynności związane z budową HD można rozpatrywać w podziale na trzy podstawowe warstwy [3] : 1. pojęciową-funkcjonalną; 2. logiczną; 3. fizyczną. Rys. 1: Schemat budowy hurtowni danych Warstwa pojęciowofunkcjonalna Warstwa logiczna Warstwa fizyczna Projekt Funkcjonalny Projekt Techniczny Implementacja Model pojęciowofunkcjonalny Schemat funkcjonalny Aplikacja użytkownika Model logiczny Specyfikacja aplikacji użytkownika Hurtownia Danych Specyfikacja struktur Hurtowni Danych Schemat Hurtowni Danych Schemat Źródła Danych 1 Moduły ładowania danych Specyfikacja logiki ładowania danych Moduły transformacji danych Specyfikacja logiki transformacji danych Moduły ekstrakcji danych Specyfikacja logiki ekstrakcji danych Schemat Źródła Danych n Specyfikacja struktur Źródeł Danych mapowanie pojęciowo-logiczne mapowanie logiczno-fizyczne Źródło Danych 1 Źródło Danych n logiczny przepływ danych fizyczny przepływ danych 2.2.1. Warstwa konceptualno-funkcjonalna Pojęciowo-funkcjonalna warstwa budowy HD ma dostarczyć koncepcyjnej reprezentacji tej części działalności przedsiębiorstwa, która ma być analizowana przy pomocy danych zgromadzonych w HD. Identyfikuje się w niej konceptualne reprezentacje: − wymiarów i miar analiz, a przez to obiektów opisywanych w HD; 6 − obiektów opisywanych przez źródła danych; − relacji pomiędzy obiektami opisywanymi przez analizowanymi i opisywanymi poprzez zawartość HD. źródła danych a obiektami Opis obiektów zidentyfikowanych w warstwie pojęciowo-funkcjonalnej i ich relacji składa się na Model Pojęciowy-Funkcjonalny (MPF) hurtowni danych, który zostaje najczęściej udokumentowany w Projekcie Funkcjonalnym (PF) hurtowni danych. Model pojęciowo-funkcjonalny jest niezależny od sposobu implementacji HD i ma na celu pokazanie semantyki ŹD i HD wraz z ich wzajemnymi relacjami. Model ten nie powstaje w sposób jednorazowy, ale jest wynikiem przyrostowej pracy zespołu projektowego, który zaczyna od uzgodnienia słownika terminów z osobami korzystającymi ze ŹD i odbiorcami HD. Kolejnym krokiem jest ujednolicenie pojęć i obrazów działania tego obszaru działalności przedsiębiorstwa, który ma zostać poddany analizom. Dalej stworzona zostaje koncepcyjna reprezentacja danych występujących w ŹD i określa się ich przełożenie na informacje gromadzone do analizy w HD. Końcowym krokiem tego etapu prac nad modelem pojęciowofunkcjonalnym jest konsolidacja schematów ŹD i HD. Stworzenie modelu pojęciowo-funkcjonalnego w oparciu o spojrzenie poprzez pryzmat jednolitego i globalnego modelu danych korporacyjnych we wszystkich źródłach oraz hurtowni danych nazwano LAV (local-as-view). Jest to podejście rekomendowane uczestników europejskiego projektu DWQ 1 . W podejściu LAV, każda tabela w źródle danych oraz każda tabela w hurtowni danych jest zdefiniowana przy użyciu warunków spojrzenia poprzez globalny modelu danych korporacyjnych. Dzięki na reprezentację pojęciową zarówno hurtowni danych jak i źródeł danych nie rzutuje rzeczywista logika struktur źródeł danych. Mapowanie reprezentacji pojęciowej na rzeczywiste struktury dokonuje się na poziomie warstwy logicznej. Alternatywnie można użyć podejścia GAV (global-as-view), które bywa często stosowane w budowie hurtowni danych. W podejściu GAV modele pojęciowe każdego ze źródeł danych są zbudowane zgodnie z ich własnymi modelami biznesowymi. Następnym celem jest wyznaczenie schematu konsolidacji danych zapisanych w ŹD z informacjami gromadzonymi w HD. Drogą do tego jest identyfikacja obiektów reprezentowanych w ŹD oraz ich związków z obiektami reprezentowanymi w HD. Dzięki powyższym działaniom, model pojęciowo-funkcjonalny staje się podstawą konsolidacji schematów oraz danych ŹD i HD. Model pojęciowo-funkcjonalny jest również niezbędny do dalszego udoskonalania zbudowanej hurtowni danych, jak również do dopasowywania HD do zmian w ŹD. Uzgodnienie danych zgromadzonych w różnych ŹD i reprezentujących te same obiekty jest jednym z elementów prac w warstwie pojęciowo-funkcjonalnej. Prace te można zautomatyzować przy użyciu dostępnych narzędzi do automatycznego wnioskowania, które potrafią wyprowadzić i zweryfikować kilka typów właściwości danych w oparciu o koncepcyjne opisy poszukiwanych informacji i ich wzajemnych związków. Formalizacja informacji zawartych w modelu koncepcyjnym wprowadza rozróżnienie pomiędzy koncepcjami obiektów i wartości, co znajduje odbicie w zapisie modelu pojęciowofunkcjonalnego za pomocą dwóch komponentów: 1. modelu Encji i Relacji (ER, Entity – Relationship model) – formalizowany w postaci diagramu ERD (Entity – Relationship Diagram), który przedstawia graficznie właściwości koncepcyjne obiektów i relacji między obiektami; 1 ESPIRIT Basic Research Action Project RP 22469 „Foundations of Data Warehouse Quality (DWQ)”, http://www.dbnet.ece.ntua.gr/~dwq/. 7 2. zestawu asercji domen wartości, który modeluje właściwości wartości parametrów obiektów. Praca [3] pokazuje zalety i przedstawia przykłady ulepszenia formalizacji opisu modelu koncepcyjnego HD, poprzez dodanie do modelu ER formalizmu opartego na logice, który nazwano DLR [29]. Formalizm ten należy do rodziny Logiki Deskryptywnej (Description Logic). Autorzy publikacji argumentują, że DLR wzbogaca formalizm opisu modelu koncepcyjnego o kilka form wyrażeń, które nie mogą zostać zapisane przy pomocy standardowego modelu ER. Ponadto DLR dostarcza zaawansowanych możliwości wnioskowania automatycznego, które mogą zostać wykorzystane do weryfikacji różnych właściwości modelu pojęciowo-funkcjonalnego. DLR zostało wcześniej wprowadzone do obszaru Reprezentacji Wiedzy i tam zostało przebadane [32,33,34]. Przestawione zostało pełnowartościowe zastosowanie metody formalizacji schematu ER przy pomocy DLR w budowie procesów ETL i hurtowni danych w obszarze telekomunikacji [30,31]. Zarówno w przypadku budowy nowej hurtowni, jak i w przypadku rozbudowy już istniejącej hurtowni, konieczne jest zastosowanie kroków zmierzających do rozszerzenia schematów źródeł i schematu hurtowni. Następuję to w przypadkach: − dodania nowego źródła danych lub nowej części źródła danych; − dodania nowej analizy lub zmiany zawartości istniejącej analizy. Przypadek dodania nowego źródła jest nazywany źródło-centrycznym (source-centric) [3]. Wymaga on przeprowadzenia analizy nowego źródła lub jego dodawanej części, a następnie dodania go do modelu pojęciowo-funkcjonalnego. Wśród niezbędnych kroków wymienia się [3]: 1. konstrukcję nowego modelu źródła, 2. integracje nowego modelu źródła z modelem pojęciowo-funkcjonalnym, podczas której trzeba przeprowadzić: ♣ rozwiązywanie konfliktów – obejmujące identyfikację i rozwiązanie konfliktów semantycznych i strukturalnych pomiędzy schematem nowego źródła a istniejącym modelem pojęciowo-funkcjonalnym, między innymi poprzez doprowadzenie do ich kompatybilności przed integracją; ♣ zdefiniowanie asercji między-modelowych – dodanie nowego modelu źródła do istniejącego już modelu pojęciowo-funkcjonalnego, wnosi do rozszerzonego modelu koncepcyjnego asercje między-modelowe wiążące elementy schematu nowego źródła z elementami modelu pojęciowo-funkcjonalnego; 3. analizę jakości – polegającą na ewaluacji poprawionego modelu pojęciowofunkcjonalnego względem zdefiniowanych wcześniej wskaźników jakości modelu pojęciowo-funkcjonalnego, pomocne mogą być przy tym techniki wnioskowania związane z zastosowanym wcześniej formalizmem opisu modelu, w przypadku wykrycia niezgodności z zadanymi kryteriami, należy dopasować model do zadanych kryteriów. Scenariusz modyfikacji modelu pojęciowo-funkcjonalnego, w wyniku dodania nowej analizy lub modyfikacji zawartości już istniejącej analizy, jest określany jako zorientowany na zapytanie (query-centric). Wymaga on przeprowadzenia analizy nowej funkcjonalności i zmiany modelu pojęciowo-funkcjonalnego hurtowni w celu wprowadzenia semantyki związanej z nowym zapytaniem (analizą). Wśród kroków charakterystycznych dla tego scenariusza warto wymienić: 1. kontrolę konfliktów pomiędzy nowymi elementami semantyki modelu pojęciowofunkcjonalnego a dotychczasowymi elementami tego modelu i schematami źródeł danych; 8 2. zdefiniowanie asercji dla nowych elementów schematu pojęciowo-funkcjonalnego; 3. analizę schematów źródeł w celu określenia, czy w obecnej formie są one wystarczające do obsługi nowego zapytania; 4. w przypadku stwierdzenia konieczności wprowadzenia nowego źródła lub dodania nowej części już istniejącego źródła, należy przeprowadzić scenariusz źródłocentryczny dla każdego dodanego źródła lub każdej nowej części źródła danych; 5. kontrolę jakości i dodanie nowych kryteriów jakości uwzględniających zmianę modelu pojęciowo-funkcjonalnego. Model pojęciowo-funkcjonalny określa ponadto funkcjonalność analiz możliwych do przeprowadzenia z użyciem danych zgromadzonych w HD. Dąży się do tego, aby zidentyfikować wszystkie dostępne wymiary, wszystkie możliwe poziomy ich dekompozycji oraz schematy agregacji wartości na poszczególnych poziomach dekompozycji wymiarów. Dla przykładu, w projekcie funkcjonalnym można określić, że wartości wymiaru „czas” będą przedstawione w podziale na lata, które będą dzielone na półrocza, które będą dzielone na kwartały roku (pierwsze półrocze – I kwartał i II kwartał, drugie półrocze – III kwartał i IV kwartał), które będą dzielone na miesiące (1…12), które będą dzielone na tygodnie w ramach miesięcy (a nie roku !), które będą dzielone na dni. Warto tu zauważyć, że w przypadku podziału względem wymiaru czasu istotne znaczenia ma obsługa tego typu wymiaru i agregacji względem tego typu wymiaru przez mechanizmy narzędzi ETL i/lub HD. Może się bowiem okazać, że z uwagi na procedury przekształcania i prezentacji możliwe będzie na przykład tylko wprowadzenie następujących odrębnych dwóch typów podziałów: − na pierwszym poziomie lata, które będą dzielone na kwartały roku (I…IV kwartał), które będą dzielone na miesiące (1…12), które będą dzielone na dni; − na pierwszym poziomie lata, które będą dzielone na tygodnie roku, które będą dzielone na dni. Określenie pełnej funkcjonalności analiz zaplanowanych do przeprowadzenia przy użyciu informacji zmagazynowanych w hurtowni danych, pozwala na stworzenia jak najbardziej pełnego modelu pojęciowego hurtowni oraz ułatwia ocenę kompletności schematów źródeł. Określenie pełnej funkcjonalności analiz jest również niezbędne w celu wyboru technologii i narzędzi budowy hurtowni danych. 2.2.2. Warstwa logiczna Budowa hurtowni w warstwie logicznej składa się z trzech podstawowych części: 1. specyfikacji logicznego schematu struktur każdego ze źródeł; 2. wyspecyfikowaniu i zaprojektowaniu logicznego schematu struktur hurtowni danych na podstawie opracowanego modelu pojęciowo-funkcjonalnego; 3. zaprojektowaniu mechanizmów i modułów wykonujących zadania procesu ETL. Wynikiem przeprowadzenia wymienionych powyżej działań jest uzyskanie specyfikacji logiki służącej do integracji danych pochodzących ze struktur źródłowych i przekształcenia ich w zawartość struktur hurtowni danych. W przypadku potrzeby stworzenia narzędzi do przeglądania zawartości HD, należy zaprojektować również logikę działania aplikacji będącej interfejsem użytkownika, poprzez który będzie on prowadził analizy. Produkty wszystkich z wymienionych tu działań są elementami projektu technicznego hurtowni danych. Projekt techniczny powinien uwzględniać aspekty wydajnościowe procesu przetwarzania danych i wprowadzać zrównoleglenie zadań wykonywanych przez algorytmy ekstrakcji, czyszczenia, transformacji i ładowania danych do hurtowni. Konieczne jest również zagwarantowanie 9 możliwości prowadzenia analiz korzystających z informacji zapisanych w hurtowni danych w czasie rzeczywistym. Specyfikacja logicznej struktury źródeł danych jest tożsama opisowi struktur danych pobieranych ze źródeł. Specyfikacja logicznych struktur hurtowni danych jest tożsama zmaterializowanemu widokowi struktur wirtualnej hurtowni danych, która została wyspecyfikowana w modelu pojęciowo-funkcjonalnym. Ponieważ źródła danych mają najczęściej postać relacyjnych baz danych, dlatego ich struktury definiuje się zazwyczaj przy pomocy zestawu relacji używając relacyjnego modelu baz danych. Przypisanie do każdej relacji zapytania ponad modelem pojęciowo-funkcjonalnym, umożliwia formalne zdefiniowanie mapowania reprezentacji pojęciowo-funkcjonalnej na reprezentację logiczną. Dzięki temu logiczną zawartość źródła można opisać za pomocą warunków wirtualnej bazy danych zdefiniowanej za pomocą modelu pojęciowo-funkcjonalnego, co jest konieczne w przypadku zastosowania podejścia LAV do stworzenia modelu pojęciowo-funkcjonalnego. Logiczny schemat hurtowni danych również opisuję się przy pomocy zestawu relacji. Podobnie jak w przypadku schematu logicznego źródeł, tak i w przypadku schematu logicznego hurtowni danych, mapowanie na model pojęciowo-funkcjonalny jest dokonywane przy pomocy zapytań. Ponieważ model pojęciowo-funkcjonalny hurtowni danych definiuje źródła danych w oderwaniu od ich rzeczywistych modeli biznesowych (pojęciowych) oraz w oderwaniu od ich rzeczywistych struktur danych, dlatego konieczne jest uwzględnienie w procesie mapowania: 1. informacji o aktualnych strukturach logicznych źródeł danych; 2. specyfikacji translacji schematu danych systemu źródłowego zaprojektowany na podstawie modelu pojęciowo-funkcjonalnego. 2.2.2.1. na schemat Zapytania ponad MPF Określono formalizację zapisu mapowania modelu pojęciowo-funkcjonalnego na model logiczny, przy użyciu mechanizmu zapytań ponad modelem pojęciowo-koncepcyjnym [3]. Formalizacja ta opiera się na definicji, że zapytania oparte na MPF są uniami koniunktywnych zapytań. Każde z takich zapytań można zapisać jako: T (~ x ) ← q(~ x, ~ y ), (1) gdzie: T (~ x ) – nagłówek, definiuje schemat relacji o nazwie T oraz jej arność, ~ x – arność, w tym przypadku zapewne liczba kolumn, szerzej chodzi tu o liczbę x , użycie symbolu ~ x odnotowuje, że chodzi tu krotność zmiennych komponentów ~ x1 ,K, xn dla pewnego n , ten symbol oznacza również zbiór zmiennych x1 ,K, xn q(~ x, ~ y ) – ciało, opisuje zawartość relacji przy użyciu warunków modelu pojęciowo- funkcjonalnego, q – zapytanie, którego formę podaje . Ciało ma formę: conj1 (~ x, ~ y1 ) ∨ L ∨ conjm (~ x, ~ ym ) , gdzie: conji (~ x, ~ yi ) – koniunkcja atomów, 10 (2) ~ x, ~ yi – wszystkie zmienne występujące w koniunkcji. Każdy z atomów może reprezentować: − encje występujące w modelu pojęciowo-funkcjonalnym, przy użyciu formy: E (t ) , (3) gdzie: E – encje występujące w MPF, t – zmienna w ~ x, ~ y lub stała; i − relacje w modelu pojęciowo-funkcjonalnym, przy użyciu formy: R(~ t ), (4) gdzie: R – relacje występujące w MPF, ~ t – zmienna w ~ x, ~ yi lub stała; − atrybuty w modelu pojęciowo-funkcjonalnym, przy użyciu formy: A(t , t ′) , (5) gdzie: A – atrybuty występujące w MPF, t – zmienna w ~ x, ~ y lub stała; i t ′ – zmienna w ~ x, ~ yi lub stała. Dla każdej bazy danych spełniającej warunki modelu koncepcyjno-funkcjonalnego, podstawienie specyfikacji ciała zapytania (2) do równania definiującego zapytanie (1) daje zapytanie sformułowane jako: T (~ x ) ← conj1 (~ x, ~ y1 ) ∨ L ∨ conjm (~ x, ~ ym ) , (6) dla którego arność n oznacza n -krotny zbiór ( d1 ,K, d n ), w którym każde di jest takim obiektem tej bazy danych, że przy zastąpieniu każdego di przez xi wyrażenie: ∃~ y1 ⋅ conj1 (~ x, ~ y1 ) ∨ L ∨ ∃~ ym ⋅ conjm (~ x, ~ ym ) , (7) daje w wyniku prawdę. Zapytania zdefiniowane w powyższy sposób można wykorzystać w procesie wnioskowania pod warunkiem uwzględnienia poniższych reguł modelu pojęciowo-funkcjonalnego. − Reguła spójności zapytania. Zapytanie q zdefiniowane ponad MPF jest spójne, jeżeli istnieje choć jedna taka baza spełniająca warunki MPF, dla której zbiór krotek wybrany przy użyciu q nie jest zbiorem pustym. − Reguła zawieranie się zapytań. Biorąc dwa zapytania q1 i q2 (o tej samej arności n ) zdefiniowane ponad MPF można powiedzieć, że q1 zawiera się w q2 , jeżeli zbiór krotek wybranych przy użyciu q1 zawiera się w zbiorze krotek wybranych przy użyciu q2 , dla każdej bazy spełniającej warunki MPF. 11 − Reguła rozłączności zapytań. Biorąc dwa zapytania q1 i q2 (o tej samej arności n ) zdefiniowane ponad MPF można powiedzieć, że są one rozłączne, jeżeli przecięcie zbioru krotek wybranych przy użyciu q1 i zbioru krotek wybranych przy użyciu q2 jest zbiorem pustym, dla każdej bazy spełniającej warunki MPF. Siłę zapytań zdefiniowanych ponad modelem projektowo-funkcjonalnym jako narzędzi do budowy modelu logicznego źródeł i hurtowni danych, pokazują poniższe. 1. Tabele relacyjnych baz danych zawierają krotki wartości, które są jedynym typem obiektów występującym w logicznym modelu źródeł danych i hurtowni danych, dlatego każda zmienna w nagłówku zapytania reprezentuje wartość (a nie obiekt pojęciowy). 2. Każda zmienna występująca w ciele zapytania reprezentuje obiekt pojęciowy lub wartość, w zależności od atomu, w którym występuje. Ponieważ obiekty pojęciowe i wartości tworzą zbiory rozłączne (dla każdej bazy danych, która spełnia warunki MPF), żadne zapytanie nie może zawierać wartości, pod którą można jednocześnie podstawić obiekt pojęciowy i wartość. 3. Ponieważ każdy obiekt pojęciowy jest reprezentowany za pomocą krotki wartości na poziomie logicznym, dlatego niezbędny jest mechanizm wyrażający korespondencję pomiędzy krotką wartości a obiektem pojęciowym, który ta krotka reprezentuje. Mechanizm ten zapewnia uszczegółowienie zapytania. 2.2.2.2. Uszczegółowienie zapytań ponad MPF Precyzyjne pobieranie danych przy użyciu zapytania ponad MPF, wymaga dodania uszczegółowienia (adornment) do zapytania. Uszczegółowienie służy do zadeklarowania domen kolumn tabel oraz atrybutów tabeli, które są niezbędne do identyfikacji obiektów wyspecyfikowanych w modelu pojęciowo-funkcjonalnym. Zapytanie uszczegółowione (adorned query) zapisuje się przy pomocy następującego wyrażenia: T (~ x ) ← q (~ x, ~ y ) | α1 , K , α n , (8) gdzie: α1 ,K, α n – uszczegółowienie, α i – oznaczenie przypisów do poszczególnych zmiennych wyspecyfikowanych w ~x . Uszczegółowienie można opisać przy pomocy dwóch poniższych definicji. − x przypis uszczegóławiający ma formę: Dla każdego X ∈ ~ X :: V , (9) gdzie: V – domena wyrażenia. Formuła uszczegółowienia (9) definiuje w jaki sposób wartości przypisane do zmiennej X są reprezentowane w tabeli na poziomie logicznym. − z⊆~ x , który został użyty w celu identyfikacji Dla każdego zbioru wartości ~ ~ x, ~ y ) , przypis uszczegółowiający w T obiektu pojęciowego Y ∈ y wymienionego w q(~ przyjmuje formę: 12 Identify([~ z ], Y ) , (10) gdzie: [~z ] – grupuje zmienne ~ z w pojedynczy argument. Przypis uszczegółowiający (10) definiuje explicite, że zbiór wartości reprezentacją obiektu pojęciowego Y . ~ z jest Uszczegóławianie zapytań stosuje się zarówno wobec zapytań operujących na relacjach w tabelach źródłowych baz danych, jak i wobec zapytań operujących na relacjach w zmaterializowanym widoku hurtowni danych. W przypadku uszczegóławiania pytań związanych ze źródłami danych, uszczegółowienie wymaga zastosowania metod analitycznych odwrotnej inżynierii programowania (reverse engineering) wobec struktur źródła danych. W przypadku uszczegóławianiu zapytań wobec zmaterializowanych struktur hurtowni danych, uszczegóławianie jest dodatkowym produktem wraz ze specyfikacją i projektowaniem logicznych struktur hurtowni danych, zaś uszczegółowione zapytania stanowią specyfikację poleceń ładujących dane do hurtowni danych. 2.2.2.3. Uzgodnienia korespondencji Uzgodnieniami korespondencji (reconciliation correspondences) nazywa się asercje, które specyfikują korespondencje pomiędzy danymi występującymi w różnych logicznych schematach danych, zarówno w schematach źródeł danych, jak i w schemacie hurtowni danych [3,35]. Uzgodnienia korespondencji definiuje się przy użyciu terminologii relacji, podobnie jak ma to miejsce w przypadku relacji opisujących źródła danych i hurtownie danych na poziomie logicznym. Każde z potrzebnych uzgodnień korespondencji definiuje się w formie uszczegółowionego zapytania, które zostaje następnie zaimplementowane w postaci programu wykonywanego każdorazowo w trakcie procesów ETL. W fazie modelowania logicznego definiuje się przede wszystkim parametry wejściowe i wyjściowe programów odpowiadających parametrom uzgodnień korespondencji. W literaturze rozróżnia się trzy typy korespondencji: 1. konwersję; 2. dopasowanie; 3. mieszanie. Szczegółowy opis wymienionych typów korespondencji zawiera praca [35]. 2.2.2.4. Typowa realizacja prac w warstwie logicznej Specyfikację schematów logicznych źródeł danych i hurtowni danych można wykonać przy użyciu uszczegółowionych zapytań. Zaprojektowanie schematu logicznego hurtowni danych wymaga restrukturyzacji i denormalizacji struktur HD zgodnie z wymaganiami optymalizacji struktur HD w celu umożliwienia prowadzenia analiz czasie rzeczywistym. W trakcie tych operacji należy wybrać dane, które będą zmaterializowane w HD oraz sposób ich organizacji. Oszacowanie kosztów ekstrakcji, transformacji, ładowania i odświeżania danych, czy przestrzeni potrzebnej do składowania danych jest między innymi konieczne, aby można było podjąć poprawne decyzje projektowe. Istotne miejsce w modelowaniu logicznym zajmuje zaprojektowanie logiki ekstrakcji danych ze źródeł, ich transformacji i ładowania do materialnych struktur hurtowni danych. Korzysta się przy tym ze specyfikacji użytecznych struktur źródeł danych oraz zaprojektowanej materializacji struktury danych hurtowni. Na strukturach źródeł danych operują programy służące do ekstrakcji danych, które pobierają dane ze źródeł i opakowują je w struktury 13 użyteczne do dalszego przetwarzania, dlatego programy te określa się również mianem wrapers [3]. Do ich specyfikacji można wykorzystać formalizację uszczegółowionych zapytań wobec źródeł danych ponad modelem pojęciowo-funkcjonalnym. Formalizacja uszczegółowionych zapytań wobec hurtowni danych ponad modelem pojęciowo-funkcjonalnym jest natomiast użyteczna do specyfikacji procedur ładowania danych do struktur hurtowni. Integracja danych pochodzących ze źródeł w hurtowni wymaga zawarcia w procesach transformacji operacji oczyszczania i łączenia danych, które bywają nazywane mediatorami (mediators). Nazwą mediatorów określa się również łącznie całość procedur transformacji i ładowania danych [3]. W celu przeprowadzenia oczyszczenia i łączenia danych, budowniczowie hurtowni muszą wyspecyfikować – jak należy mapować i dopasowywać dane pochodzących ze źródeł do wymogów jakościowych informacji, która ma być składowana w hurtowni danych. W tym celu można użyć opisanej wcześniej metodyki uzgodnienia korespondencji, aby poprzez uszczegółowione zapytania wyspecyfikować logikę procedur oczyszczania i łączenia danych. Metodyka uzgodnienia korespondencji jest również użyteczna do automatycznej generacji procedur spełniających funkcje mediatorów lub do automatycznego wyszukiwania właściwości korespondencji pomiędzy danymi źródeł i informacjami gromadzonymi w hurtowni danych [35]. 2.2.3. Warstwa fizyczna Warstwa fizyczna obejmuje implementację struktur hurtowni danych i procesów ETL. W przypadku potrzeby implementacji interfejsu użytkownika, implementowane są również narzędzia do prowadzenia analiz zgodnie z technologią OLAP. Struktury hurtowni danych implementuje się przy użyciu rozwiązań opartych na relacyjnej baz danych [8, 10, 11,12,13,14,16,20,23] lub rozwiązań dedykowanych nie opartych na relacyjnej bazie danych [24,25], które pozwalają na stworzenie wielowymiarowych struktur danych. Podczas implementacji wielowymiarowe struktury danych przyjmują zazwyczaj formę przypominającą gwiazdę lub płatek śniegu. Wielowymiarowe struktury informacyjne hurtowni danych implementuje się w postaci wielowymiarowych struktur zwanych kostkami danych (data cube) lub przy użyciu tabel, które ponadto są używane do przechowywania agregacji lub danych uszczegóławiających informacje wielowymiarowe. Procesy ETL implementuje się przy użyciu: − języka SQL i jego rozszerzeń, które zostały stworzone przez producentów bazy danych bazy danych lub producentów hurtowni danych zbudowanych w oparciu o relacyjne bazy danych; − języków stworzonych przez producentów rozwiązań hurtowni danych [25]; − rozwiązań dedykowanych [7,9,15,18,19,21,22,24,25]. do projektowania i wykonywania procesów ETL Interfejs użytkownika jest realizowany za pomocą: − narzędzi wchodzących w skład rozwiązań określanych jako Inteligencja Biznesowa (BI – Business Intelligence) [14,15,17,19,20,23,24,25]; − narzędzi do analizy danych, które pozwalają na definiowanie własnych analiz [7,14,17,23,24,25,27]; 14 − samodzielnie zaimplementowanych aplikacji z użyciem technologii WWW, XML, CGI, ASP, .NET, języków Java, C, C++, C#. W sprzedaży jest obecnie dostępnych szereg narzędzi i rozwiązań, które mogą zostać użyte do implementacji hurtowni danych, procesów ETL lub realizacji interfejsu użytkownika według technologii OLAP. Poniżej wymieniono reprezentatywną część z dostępnych rozwiązań. − IBM WebSphere DataStage [7] – narzędzie do integracji danych, wchodzi w skład rozwiązania IBM Information Server, które w połączeniu z hurtownią danych pozwala na prowadzenie analiz według technologii OLAP. − IBM DB2 Warehouse [8] – hurtownia danych. − Informatica PowerCenter [9] – zunifikowana platforma służąca do dostępu, analizy i integracji danych, współpracująca w różnorodnymi biznesowymi systemami informacyjnymi, w tym z hurtowniami danych i bazami danych, umożliwia prowadzenie analiz według technologii OLAP. − Teradata Enterprise Data Warehouse [10] – dedykowana hurtownia danych, zapewniająca równoległe przetwarzanie i dostęp do olbrzymich ilości danych. Teradata działa zgodnie z architekturą obliczeń rozproszonych SN (shared nothing), która tworzy strukturę typu GRID, gdzie każdy z węzłów jest niezależny i samowystarczalny. Rozwiązanie to zawiera dedykowane elementy w zakresie sprzętu i oprogramowania. Podobnymi rozwiązaniami są Netezza, Greenplum i PANTA. − Netezza Performance Server [11] – dedykowana hurtownia danych, zapewniająca równoległe przetwarzanie i dostęp do olbrzymich ilości danych. Rozwiązanie to zawiera dedykowane elementy w zakresie sprzętu i oprogramowania, w tym: wbudowany systemem operacyjny Linux, adaptowaną wersję bazy danych PostgreSQL i dużą przestrzeń dyskową. Podobnymi rozwiązaniami są Teradata, Greenplum i PANTA. − Greenplum Database [12] – dedykowana hurtownia danych, zapewniająca równoległe przetwarzanie i dostęp do olbrzymich ilości danych. Greenplum działa zgodnie z architekturą obliczeń rozproszonych SN. Rozwiązanie to zawiera dedykowane elementy w zakresie sprzętu i oprogramowania, w tym: wbudowany systemem operacyjny Linux/ Solaria/ OSX, adaptowaną wersję bazy danych PostgreSQL i dużą przestrzeń dyskową. Podobnymi rozwiązaniami są Teradata, Netezza i PANTA. − PANTA Data Warehouse Appliance with Oracle [13] – dedykowana hurtownia danych, zapewniająca równoległe przetwarzanie i dostęp do olbrzymich ilości danych. Rozwiązanie to zawiera dedykowane elementy w zakresie sprzętu i oprogramowania, w tym: bazę danych Oracle i dużą przestrzeń dyskową. Podobnymi rozwiązaniami są Teradata, Netezza i Greenplum. − Sybase IQ Analytics Server [14] – rozwiązanie określane jako Server analityczny. Zawiera hurtownię danych, narzędzia do stworzenia własnych analiz oraz elementy BI. Sybase IQ jest oparte na specyficznej relacyjnej bazie danych, która przechowuje w tabelach dane zorganizowane w sekcje kolumn danych, a nie wiersze danych. Dzięki temu jest lepiej dopasowana do przeszukiwania danych zgodnie z ideą wymiarów i miar w hurtowni danych. − SAP NetWeaver Business[15] – rozwiązanie zawierające narzędzia BI, narzędzia umożliwiające prowadzenie analiz według technologii OLAP, hurtownię danych, narzędzia wykonujące procesy ETL. 15 − Oracle Data Warehousing [16] – rozwiązanie zawierające hurtownię danych i narzędzia ETL jako komponenty bazy danych Oracle. − Oracle Business Intelligence Foundation and Tools [17] – rozwiązanie zawierające zestaw narzędzi BI oraz zestaw narzędzi umożliwiających prowadzenie analiz według technologii OLAP. Po przejęciu przez Oracle platformy Hyperion, zawiera zestaw narzędzi BI platformy Hyperion. − Oracle Data Integrator [18] – narzędzie do projektowania i wykonywania procesów ETL w celu integracji danych pochodzących z wielu źródeł w jednej bazie lub hurtowni danych. − Cognos 8 Business Intelligence [19] – rozwiązanie zawierające zestaw narzędzi BI, zestaw narzędzi umożliwiających prowadzenie analiz według technologii OLAP, zestaw narzędzi do integracji danych poprzez zaprojektowanie i realizację procesów ETL. − BusinessObjects Warehouse [20] – rozwiązanie składające się z hurtowni danych i narzędzi analitycznych. BusinessObjects Warehouse stanowi część platformy BusinessObjects BI, która dostarcza narzędzi BI. − BusinessObjects Data Integrator [21] – narzędzie do zaprojektowania i realizacji procesów ETL. − Microsoft SQL Server Integration Services [22] – narzędzie do implementacji i wykonywania procesów ETL. Microsoft SQL Server Integration Services wraz z Microsoft SQL Server: Data Warehousing są elementami platformy BI Microsoft SQL Server, która dostarcza narzędzi analitycznych zgodnie z technologią OLAP. − Microsoft SQL Server Data Warehousing [23] – hurtownia danych oparta o relacyjną bazę danych. Microsoft SQL Server Data Warehousing wraz z Microsoft SQL Server Integration Services są elementami platformy BI Microsoft SQL Server, która dostarcza narzędzi analitycznych zgodnie z technologią OLAP. − Kalido [24] – rozwiązanie zawierające zestaw narzędzi BI, zestaw narzędzi umożliwiających prowadzenie analiz według technologii OLAP, zestaw narzędzi do integracji danych poprzez zaprojektowanie i realizację procesów ETL oraz hurtownię danych. − SAS System [25] – rozwiązanie zawierające zestaw narzędzi BI, zestaw narzędzi umożliwiających prowadzenie analiz według technologii OLAP, zestaw narzędzi do integracji danych poprzez zaprojektowanie i realizację procesów ETL oraz hurtownię danych. SAS System dysponuje własnym językiem programowania o nazwie SAS, który zalicza się do języków 4GL (fourth-generation programming language), choć z uwagi na pewne ograniczenia bywa też określany jako 3,5 GL. Język SAS służy miedzy innymi do zaprogramowania procesów ETL. Konkurentem języka SAS jest język R [26]. Język R jest językiem, którego interpretery i specyfikacja są dostępne bezpłatnie (w porównaniu z drogim środowiskiem uruchomieniowym SAS System). Język R jest implementacją typu kod otwarty (open source) języka S [28]. − Insightful [27] – rozwiązanie do prowadzenia analizy statystycznej i data mining. Insightful jest przeznaczone prowadzenia analiz w technologii OLAP z użyciem hurtowni danych. Insightful dysponuje własnym językiem S-PLUS, który jest komercyjną implementacją języka S [28]. 16 2.2.4. Narzędzia użyteczne w budowie hurtowni danych Wśród narządzi przydatnych do stworzenia modelu pojęciowo-funkcjonalnego, a następnie do prac nad logicznym modelem hurtowni danych warto wymienić wymienione poniżej typy narzędzi. − Narzędzia do budowania ontologii – ułatwią budowę i upowszechnienie ontologii, która stanie się słownikiem definiującym terminy opisujące wspólny obraz działalności korporacyjnej. Słownik ten powinien zawierać wszystkie pojęcia opisujące obiekty występujące w modelu pojęciowo-funkcjonalnym. Przykładem takiego narzędzia jest FaCT lub FaCT++ [37,38]. Ponadto FaCT i FaCT++ jest narzędziem zawierającym automatyczne wnioskowanie z użyciem DLR, co czyni go szczególnie przydatnym dla formalizacji modelu pojęciowo-funkcjonalnego i weryfikacji właściwości modelu pojęciowo-funkcjonalnego [3]. − Narzędzia do projektowania baz danych, aplikacji, systemów informacyjnych, narzędzia CASE – ułatwią budowę modeli pojęciowo-funkcjonalnych i umożliwią jego zapis. Przykładami takich narzędzi są: DBDesigner 4 [39], CA ERwin® Modeling Suite [40], PowerDesigner [41], ArgoUML [42], Oracle Developer [43]. − Narzędzia do prototypowania zapytań – ułatwią i umożliwią specyfikacje logiki zapytań i aplikacji procesu ETL. Przykładem takiego narzędzia posiadającego wsparcie dla uszczegółowionych zapytań jest DaRe [3]. 2.3. Zastosowanie ASM do budowy hurtowni danych Abstract State Machines (ASMs) zostało stworzone jako narzędzie do wysokopoziomowego projektowania systemów i ich analizy. Ideą ASM polega na dostarczeniu projektantom i analitykom zunifikowanego formalizmu z czysto matematyczną semantyką bez popadania w pułapkę ograniczenia metod formalnych. Zgodnie z podaną ideą, formalizm ASM ma być używany na wszystkich poziomach rozwoju systemu oraz być na tyle elastycznym, aby uchwycić wymagania na dosyć ogólnym poziomie i jednocześnie pozwolić na uzyskanie wykonalnej specyfikacji systemu. Dlatego formalizm ASM jest precyzyjny, zwięzły, abstrakcyjny i kompletny, dosyć prosty i łatwy do obsługi, a także używa wyłącznie podstawowej matematyki. Budowanie systemu z użyciem ASM rozpoczyna się od definicji podstawowego modelu (ground model) ASM (lub kilku powiązanych modeli), którego głównym zadaniem jest uchwycenie wymagań. Dalszy rozwój następuje na drodze rafinacji modelu (modeli) ASM przy użyciu dosyć generalnych pojęć oczyszczania poprzez cykle oczyszczania i walidacji. Podstawowy ASM można zdefiniować w następujący sposób: ( ASM M ) ( ) IMPORT M 1 r11 ,K r1n1 ,K, M k rk1 ,K, rknk , EXPORT q1 ,K, ql (11) SIGNATURE gdzie: M – etykieta opisywanej aktualnie ASM; M i – etykieta ASM zdefiniowanej gdzie indziej; rij – nazwy funkcji i reguł importowanych z ASM M i , które zostały zdefiniowane w ciele M i i są jedynie używane w M i ; 17 q1 ,K, ql – nazwy funkcji i reguł, które mogą zostać zaimportowane i używane przez inne ASM (inne niż M ); SIGNATURE – sygnatura ASM, która składa się ze skończonej listy funkcji f1 ,K, f m , dla każdej z funkcji f i podaje się arność tej funkcji, która jest oznaczana jako ari i jest liczbą całkowitą nie ujemną. W pracy [4] autorzy podali dalszą specyfikację ASM i zaproponowali użycie ASM jako metody budowy hurtowni danych z uwagi na jej wysoki poziom formalizacji. Zaproponowali oni użycie trzy warstwowego modelu hurtowni danych: 1. warstwa źródeł danych; 2. warstwa wewnętrznych struktur zdefiniowanych przy użyciu schematu gwiazdy lub płatka śniegu; 3. warstwa prezentacji danych do analizy (data marts). Dla każdej z wymienionych warstw skonstruowali oni podstawowy model danych, który poddali następnie rafinacji. Autorzy podali formalne reguły rafinacji oraz przedstawili praktyczne wskazówki użycia podanych reguł. Metoda zastosowania ASM do budowy hurtowni danych jest warta przytoczenia w tej pracy, ponieważ prawdopodobnie umożliwia weryfikację części kryteriów jakości na już na samym początku budowy hurtowni danych [4], a przez to warta jest uwzględnienia w rozważenia nad metodami i technologiami budowy danych ze szczególnym zapewnieniem długookresowej jakości produktu i dalszej obserwacji. 3. Opracowana metodyka Przedstawione powyżej metodyki budowy hurtowni danych prezentują szereg metod stosowanych do budowy hurtowni, które stosowane są w procesach projektowania, wdrażania i bywają użyteczne w procesie utrzymania hurtowni danych. Metodyka łącząca typowe metody budowy hurtowni danych, kładzie silny nacisk ma pojęciowe i logiczne struktury źródeł danych i hurtowni danych oraz ich wzajemne mapowanie. Użycie uszczegółowionych zapytań, zapewnienia dobrą jakość przekształcenia modelu pojęciowego w model logiczny, dobrą jakość identyfikacji obiektów znajdujących się w logicznych strukturach źródeł oraz dobrą jakość wypełniania struktur logicznych hurtowni. Użycie formalizacji dla uzgodnień korespondencji w trakcie projektowania logicznego, zapewnia dobrą jakość przekształceń danych pochodzących z logicznych struktur źródeł w informacje składowane w logicznych strukturach hurtowni danych. W powyższy sposób, metodyka łącząca typowe metody budowania prawdopodobnie może, dzięki odpowiedniej formalizacji zapytań, zapewnić dobrą jakość struktur danych hurtowni i dobrą jakość danych składowanych w hurtowni poprzez procesy ETL w trakcie budowy hurtowni. Podobne efekty pozwoli zapewne osiągnąć (zgodnie z przewidywaniami), metodologia oparta na użyciu ASM i metody zaproponowane jako rama dla projektowania scenariuszy ETL [5]. Ponieważ cykl funkcjonowania hurtowni danych zawiera regularne wykonywanie procesów ETL, w celu wypełniania jej informacjami utworzonymi na podstawie danych pochodzących ze źródeł, to: 1. hurtownia danych jest niezwykle czuła na zaburzenia jakości danych występujących w źródłach lub brak ich dostępności, 2. długookresowa jakość hurtowni danych jest tożsama z jakością informacji składowanych w HD w wyniku kolejnych wykonań procesów ETL. 18 Opisanej powyżej długookresowej jakości nie mogą zapewnić przedstawione wcześniej metodyki, ponieważ zapewniają one jakość produktu (jakim jest hurtownia danych), jedynie poprzez zapewnienie jakości procesu budowy tego produktu, a nie zapewniają jakości informacji uzyskanych w trakcie kolejnych uruchomień procesów ETL. W oparciu o powyższe obserwacje i dotychczasowe doświadczenia zespołu realizującego niniejszą pracę w zakresie projektowania, wdrażania i utrzymania hurtowni danych zdefiniowano metodykę budowy hurtowni danych, która zapewnia długookresową jakość hurtowni oraz procedury kontroli jakości danych. Metodyka ta obejmuje procesy projektowania, wdrażania i utrzymania hurtowni danych i składa się z poniższych elementów. 1. Dla procesów projektowania. a. Zdefiniowanie kryteriów kontroli poprawności jakościowej danych, które będą podstawiane w miejsce atrybutów obiektów w modelu pojęciowofunkcjonalnym. b. Zaprojektowanie mechanizmów obsługi anomalii w danych zgromadzonych w hurtowni na poziomie interfejsu użytkownika. c. Włącznie kryteriów kontroli poprawności jakościowej wartości zmiennych występujących w reprezentacji logicznej struktur źródeł i hurtowni danych, do uszczegółowienia zapytań mapujących model pojęciowo-funkcjonalny na model logiczny lub odpowiadających im formalizmów. d. Włączenie kryteriów kontroli poprawności jakościowej wartości danych do uzgodnień korespondencji lub odpowiadających im formalizmów, w celu wprowadzenia kontroli jakościowej na poziomie przekształceń danych pochodzących z logicznych struktur źródeł w informacje składowane w logicznych strukturach hurtowni danych. e. Włączenie kryteriów kontroli poprawności jakościowej do metody dekompozycji procesów ETL na mniejsze moduły, w celu zrównoleglenia wykonywania procesów ETL i zwiększenia wydajności procesów ETL oraz zapewnienia większej kontroli nad jakością produktów poszczególnych działań w procesach ETL. f. Zaprojektowanie systemu czuwającego nad jakością produktów w całości procesów ETL, tak aby było możliwe skontrolowanie produktów realizacji poszczególnych modułów uzyskanych ze dekomponowanych procesów ETL i podjęcie akcji zaradczych lub powiadomienie o utracie jakości w hurtowni danych. Postuluje się wbudowanie tej funkcjonalności w system administrujący wykonywaniem procesów ETL. g. Zapisanie informacji o kryteriach kontroli jakości produktów procesów ETL w postaci meta danych, które mogłyby zostać użyte przez osoby utrzymujące hurtownie danych, przez osoby korzystające z hurtowni danych, przez aplikacje służące do prowadzenia analiz (w celu oznaczenia jakości danych lub szerzej obsługi przypadków wystąpienia anomalii w informacjach zgromadzonych w hurtowni danych), przez systemem automatycznej kontroli i zapewnienia jakości hurtowni danych. 2. Dla procesów wdrożenia. a. Wdrożenie procesów ETL zgodnie ze zdefiniowanymi w projekcie kryteriami jakości produktów wykonania tych procesów. b. Wdrożenie systemu czuwającego nad jakością produktów w całości procesów ETL zgodnie ze specyfikacją określoną w projekcie. c. Wdrożenie aplikacji służących do prowadzenia analiz z uwzględnieniem jakości produktów procesów ETL. 19 3. Dla procesów utrzymania a. Użytkowanie systemu czuwającego nad jakością produktów w całości procesów ETL. b. Korzystanie z aplikacji analitycznych dostarczających informacji o jakości informacji składowanej w hurtowni lub obsługujących przypadki wystąpienia anomalii w hurtowni danych. c. Zapewnienie mechanizmu sprzężenia zwrotnego od osób korzystających z hurtowni danych do osób utrzymujących hurtownię danych, w celu zapewnienia przepływu informacji o anomaliach w danych. d. Zapewnienie mechanizmu przepływu informacji o anomaliach w danych, informacji o zmianach w strukturach danych lub informacji o jakościowych zmianach danych zawartych w źródłach danych od osób utrzymujących źródła danych do osób utrzymujących hurtownię danych. e. Modyfikacje lub uzupełnienia zdefiniowanych wcześniej kryteriów kontroli jakości zmiennych, danych i produktów procesów ETL (w zależności od kontekstu), w przypadku stwierdzenia nie prawidłowości w jakości informacji składowanych w hurtowni danych, w przypadku zmian w strukturach źródeł danych lub strukturach hurtowni danych, w przypadku jakościowych zmian danych źródeł lub jakościowych zmian informacji w hurtowni danych. Obsługa anomalii w informacjach zgromadzonych w hurtowni danych lub prezentacja informacji o takich anomaliach w narzędziach, którymi posługuje się użytkownik hurtowni danych, może być potrzebna na przykład w celu: − ostrzeżenia użytkownika przed wadliwymi agregacjami (gdy na przykład brakuje części lub uszkodzona jest część danych); − prezentacji danych, które co prawda nie są całkiem wadliwe, ale na przykład nie mogły być użyte do dalszych porównań lub agregacji. 4. Moduł Sterujący Moduł Sterujący (MS) jest systemem przetwarzania danych w HD, którego implementacja jest niezbędna do przeprowadzenia budowy i utrzymania hurtowni danych zgodnie z zaproponowaną metodologią zapewnienia długookresowej jakości produktu. Z uwagi na podział aplikacji Moduł Sterujący na części zwane dalej modułami, cała aplikację będzie się w dalszej części nazywać aplikacją, systemem, lub managerem. Procesy przetwarzania danych typu ETL (extract, transform, load) są nierozerwalnie związane z zasilaniem hurtowni danych. Procesy tego typu to zazwyczaj skomplikowane procedury informatyczne, wykonywane z reguły automatycznie wówczas, gdy konieczne jest uaktualnienie danych w hurtowni. Procesy ETL składają się z atomowych podprocesów, przetwarzających dane cząstkowe. Wyniki pracy poszczególnych podprocesów stanowią dla innych podprocesów dane do przetwarzania i w tym sensie można mówić o złożoności procesu ETL. Proces ETL w opisywanej postaci można przedstawić jako graf, składający się z poszczególnych etapów/podprocesów, przy czym łuki grafu reprezentują zależności między podprocesami, natomiast same podprocesy są węzłami grafu. Strukturę taką nazywamy w niniejszej pracy wzorcem przetwarzania, lub też łańcuchem przetwarzania. Podprocesy, będące składowymi wzorca przetwarzania nazywamy po prostu zadaniami przetwarzania. Przykładową strukturę przedstawiono na Rys. 2. Wykonanie procesu przetwarzania o strukturze tak złożonej jak opisana powyżej niesie za sobą szereg problemów do rozwiązania: 20 − Problemy związane z jakością przetwarzanych danych takie jak niekompletność danych, niepoprawność danych, czy niezrozumiałość danych. − Problemy wydajnościowe związane z obciążeniem środowiska, w którym dokonuje się przetwarzania i oczekiwaniem przez użytkownika, że proces zakończy się w skończonym czasie − Problemy związane z zapewnieniem odporności procesu ETL na awarie środowiska przetwarzania (braki zasobów, awarie sprzętowe, zatrzymywanie i wznawianie procesu). Rys. 2 Przykładowy wzorzec przetwarzania Dlatego też niezbędny jest system zarządzający realizacją procesu ETL przez nadzór nad wykonaniem wzorca przetwarzania. System taki winien zapewnić stały nadzór nad całościowym procesem ETL poprzez: − Możliwość wyboru strategii uruchamiania poszczególnych podprocesów zapewniającej na przykład jak najszybsze wykonanie poszczególnych podprocesów przetwarzania ( w miarę możliwości zrównoleglenie ich działania) lub na przykład optymalne wykorzystanie dostępnych zasobów − Udostępnienie informacji o stanie poszczególnych podprocesów przetwarzania i postępie całościowym przetwarzania − Uwzględnienie zmiany w dostępności poszczególnych procesów przetwarzania. zasobów i wadliwe wykonanie się Biorąc pod uwagę powyższe wymagania w budowie systemu dają się wyodrębnić 3 moduły: − Moduł odpowiedzialny za budowę według określonej strategii harmonogramu wykonywania procesów. System musi uwzględnić zarówno zależności między 21 procesami, jak i zapotrzebowanie procesów na pamięć, procesory czy miejsce na dyskach fizycznych maszyny, na której wykonane zostanie przetwarzanie. Harmonogram musi być dynamicznie korygowany w trakcie pracy systemu, aby uwzględnić niepoprawne zakończenie przetwarzania się poszczególnych procesów, brak zasobów do wykonania procesów itp. − Moduł odpowiedzialny za uruchamianie procesów przetwarzania według harmonogramu i związana z tym gospodarka dostępnymi zasobami (rezerwacja i zwalnianie pamięci/procesorów/miejsca na dysku) − Moduł odpowiedzialny za monitorowanie pracy poszczególnych procesów (w szczególności wykrywanie błędów w ich działaniu) i powiadamianie o tym modułu odpowiedzialnego za opiekę nad harmonogramem wykonywania procesów Ideę współpracy między modułami przedstawiono na Rys. 3. Rys. 3 Organizacja pracy w systemie Niniejszy rozdział omawia zaimplementowane w ramach pracy narzędzie, spełniające opisane powyżej warunki. Podrozdział pierwszy omawia funkcjonalność systemu z punktu widzenia użytkownika. Podrozdział drugi zawiera szczegółowy opis działania i budowy systemu. W ostatnim podrozdziale przedstawiono propozycję rozbudowy narzędzia. 4.1. Funkcjonalność systemu System, w obecnej postaci przy wykonywaniu wzorca przetwarzania współpracuje ściśle z bazą danych. W strukturze bazy przechowywane są wszystkie informacje na temat wzorców przetwarzania i zadań będących ich składowymi. Również informacje związane z pracą systemu takie jak status wykonywanego wzorca, czy wykonywanego zadania zapisywane są do bazy. System przetwarza dane zgodnie ze wskazanym wzorcem dla danych z zadanego okresu, przy czym kwantem w tym okresie przetwarzania jest dzień. Aby rozróżnić proces przetwarzania danych dla poszczególnych zadań w danym okresie w systemie wprowadzono 22 pojęcie instancji zadania. Termin ten oznacza zadanie przetwarzania dla danych z danego dnia. Analogicznie można mówić o instancji wzorca agregującej instancje zadań należące do tego wzorca, dla danego dnia w okresie przetwarzania. Informacje związane z pracą systemu, takie jak status wykonywanej instancji wzorca, czy status wykonywanej instancji zadania również zapisywane są do bazy. W Przykł. 1 omówiono zagadnienia związane z uruchamianiem systemu, jego konfiguracją i sposobami zatrzymywania i komunikacją systemu z użytkownikiem. 4.1.1. Uruchomienie System startuje jako aplikacja konsolowa. Użytkownik przy uruchomieniu podaje szereg parametrów, m.in. określających uruchamiany wzorzec i okres przetwarzania. Poniżej przedstawiono szczegółowy opis składni wywołania programu. Przykł. 1: Opis składni wywołania programu NAME MsRun - runs Mangment Service for Data Warehouse Processing VERSION 2.0 RC3 build 2007112801 SYNOPSIS [SYSTEM STYLE] ms_run_java.sh -h ms_run_java.sh [options] & [JAVA STYLE] java –jar MsRun.jar -h java –jar MsRun.jar [options] & SUMMARY MsRun is Mangment Service for Data Warehouse Processing. It is designed to be run in Java Runetime Environment as a standalone deamon process (still experimental). The deamon can be stopped in soft or hard shutdown mode. User should send USR1 signal (kill -s USR1 MsRun_PID) to the deamon to start the soft shutdown or USR2 signal (kill s USR2 MsRun_PID) to start the hard shutdown. The MsRun PID can be found in file "/tmp/MsRun_ms.pid". The MsRun PID can be found in file "/tmp/MsRun_ms.pid". OPTIONS -f or --from - begin date of processing period -t or --to - end date of processing period -o or --horizon - begin date of processing period, end date is today 23 -d or --days - number of days -p or --pattern - id (name) of processing pattern -e or --exit - exit application when all scheduled task instances has been finished DATE FORMAT YYYYMMDD, i.e. 20071231 4.1.2. Konfiguracja Szczegółowa konfiguracja aplikacji przechowywana jest w pliku „usrCfg/msrun.properties”. Zmieniając wartości parametrów zawartych w pliku użytkownik ma możliwość dopasowania aplikacji do swoich potrzeb środowiska, w którym będzie ona uruchamiana. Wśród parametrów znajdują się zarówno te określające miejsce przechowywania istotnych dla aplikacji danych czy parametry dostępu do bazy danych jak i związane bezpośrednio z pracą systemu (np. po ilu próbach system ma zrezygnować z uruchamiania instancji zadania – zakładając, że wszystkie uruchomienia zakończyły się fiaskiem). Parametry poprzedzane są komentarzami wyjaśniającymi ich znaczenie. Istnieje możliwość zmiany formatu pliku konfiguracyjnego z formatu Properties na XML. W Przykł. 2 przedstawiono fragment zawartości przykładowego pliku konfiguracyjnego: Przykł. 2: Fragment pliku konfiguracyjnego aplikacji # application Name appName = MsRun appVersion = 2.0 RC3 appYear = 2007 appMonth = 11 appDay = 28 appBuildMinor = 01 appScriptName = ms_run_java.sh appRunningName = ${appScriptName} # path to file keeping MsRun PID. msRunPidFile = /tmp/${appName}_ms.pid # the fist part of message to put into file keeping MsRun PID when no PID found msRunNoPidMessageFirstPart = # No PID found. Look at process list to find # the second part of message to put into file keeping MsRun PID when no PID found msRunNoPidMessageSecondPart = PID. # path to file keeping Log4J properties. 24 log4JPropertiesFile = log4J.properties # path to file keeping sql patterns. sqlPropertiesFile =sql/SQLqueries.properties TIMESTAMP_FORMAT= yyyy/MM/dd HH:mm:ss # URL used for connection to MetaData Database. sqlDBUrl = jdbc:oracle:thin:@palenica:1521:kruk #user name used for connection to MetaData Database. sqlDBUser= segmm #password used for connection to MetaData Database. sqlDBPasswd= segmmz6 #enable caching for connection to MetaData Database. sqlCachingEnabled = true #cashe name used for connection to MetaData Database. sqlCacheName = SegmmCache #MinLimit property used for connerction to MetaData Database. sqlMinLimit = 1 #MaxLimit property used for connerction to MetaData Database. sqlMaxLimit = 4 #InitialLimit property used for connerction to MetaData Database. sqlInitialLimit = 1 #ConnectionWaitTimeout property used for connection to MetaData Database. sqlConnectionWaitTimeout = 5 Użytkownik ma możliwość dokonywania dynamicznych zmian w konfiguracji systemu, bez wyłączania aplikacji. Po naniesieniu zmian w pliku konfiguracyjnym wystarczy do procesu systemowego, reprezentującego aplikacje wysłać sygnał HUP. 4.1.3. Zatrzymanie aplikacji Aplikacja może zostać zatrzymana „miękko” lub „twardo”. W trybie miękkim system czeka z zakończeniem pracy na zakończenie wykonywania aktualnie uruchomionych instancji zadań i nie uruchamia już w tym czasie kolejnych instancji, które zgodnie z harmonogramem powinny być uruchomione w następnej kolejności. W trybie twardym system zakańcza wszystkie działające w danej chwili instancje i sam zakańcza pracę. Zatrzymanie w trybie miękkim wywoływane jest przez wysłanie do procesu systemowego, reprezentującego aplikację sygnału USR1. Zatrzymanie w trybie twardym wywołuje sygnał USR2. 25 4.1.4. Komunikacja systemu z użytkownikiem Wszystkie informacje o pracy systemu są na bieżąco zapisywane w logach w podkatalogu „logs”. Informacje zapisywane są do 3 plików. W pliku ms_run2_INFO_log4j.log system przechowuje informacje związane ze swoją normalną pracą oraz komunikaty o ewentualnych błędach powstałych w jej czasie. W pliku ms_run2_ERRORS_log4j.log zapisywane są wyłącznie informacje o wynikłych błędach. Plik ms_run2_ALL_log4j.log przeznaczony jest raczej dla administratorów i programistów zajmujących się utrzymaniem aplikacji. Duplikowane są tam wszystkie informacje zapisywane w plikach ms_run2_INFO_log4j.log i ms_run2_ERRORS_log4j.log uzupełnione o komunikaty pozwalające na bardziej szczegółowe śledzenie działania aplikacji. Przedstawiony interfejs aplikacji pozwala na komunikację z nią w skrajnie ubogim środowisku. Sytuacja taka zdarza się na serwerach produkcyjnych, gdzie np. ze względu na bezpieczeństwo jedynym sposobem dostępu jest szyfrowany terminal znakowy ssh. Kolejną zaletą jest możliwość demonizacji aplikacji, to jest jej pracy w tle. 4.1.5. Realizowana funkcjonalność Dalsza część podrozdziału omawia ogólnie funkcjonalność programu. Najistotniejszą z realizowanych przez system funkcjonalności jest harmonogramowanie instancji zadań do wykonania. Dzięki modułowej konstrukcji aplikacji strategie budowy harmonogramu są łatwe do implementacji i wymiennego użycia. W obecnie zaimplementowanej strategii instancje zdań porządkowane są w harmonogramie ze względu na datę w okresie przetwarzania. Instancje zadań mające przetworzyć dane z pierwszego dnia w okresie przetwarzania zostaną wykonane jako pierwsze. Dodatkowo w budowie harmonogramu uwzględnia się dostępność i poprawność danych wejściowych dla poszczególnych instancji zadań. Harmonogram jest cyklicznie przebudowywany w trakcie trwania aplikacji. Pozwala to uwzględnić w nim pojawienie się oczekiwanych danych i zasobów. Ponadto w zależności od konfiguracji instancje zakończone błędem mogą zostać ponownie uwzględnione w harmonogramie. W opisywanej strategii wprowadzony jest mechanizm kary, na mocy którego instancja wykonana z błędem przed ponownym uwzględnieniem w harmonogramie zostaje pominięta w x cyklach jego przebudowy. Kolejną, kluczową dla działania systemu funkcjonalnością jest uruchamianie wg harmonogramu instancji zadań. System przy uruchamianiu instancji zadań alokuje dla nich niezbędne zasoby (np. pamięć, czas procesora, miejsce na dysku). Alokacja ma miejsce tylko wewnątrz aplikacji, na podstawie zapisanych w bazie informacji o dostępnych zasobach i zapotrzebowaniu na zasoby, generowanym przez poszczególne zadania. Mechanizm ten pozwala na optymalne obciążenie środowiska, w którym dokonywane jest przetwarzanie. Następną z realizowanych funkcjonalności jest monitorowanie przetwarzanych instancji zadań. W trakcie pracy instancji monitorowane są generowane przez nią logi, zużycie przez nią procesora i zajętość pamięci w środowisku przetwarzania, jak również czas działania. Po jej zakończeniu sprawdzana jest również dostępność i jakość danych mających być rezultatem pracy instancji. W ramach monitorowania system nadaje instancji status określający jej stan w danej chwili. Informacja ta jest zapisywana zarówno w logach jak i w bazie danych. Wśród statusów instancji zadań rozróżniamy: − UNDEFINED – instancja jeszcze nie została uruchomiona; − NOEXC – próba uruchomienia instancji się nie powiodła; − RUNNING – instancja pracuje; 26 − WARNING – pojawił się błąd w trakcie pracy instancji, ale nie jest on krytyczny; − DONE – instancja została zakończona; − ERROR – pojawił się błąd krytyczny w pracy instancji/ instancja zakończyła się błędami; − RETRY – instancja przeznaczona jest do ponownego uruchomienia; − EXCLUDED – instancja została wykluczona z harmonogramu po x uruchomieniach zakończonych porażką. Wraz ze zmianami statusów instancji zadań zmienia się status instancji wzorca przetwarzania. Ostatnią z opisanych funkcjonalności jest zapis do logów informacji związanych z pracą systemu. Funkcjonalność ta została już opisana w tym podrozdziale, w części „Komunikacja systemu z użytkownikiem”. 4.2. Działanie i budowa systemu 4.2.1. Działanie systemu System otrzymuje przy uruchomieniu identyfikator wzorca przetwarzania i informacje o okresie przetwarzania. Na podstawie tych informacji i danych z bazy danych tworzone są obiektowe reprezentacje wzorca przetwarzania, wchodzących w jego skład zadań i instancji tych zadań dla podanego okresu przetwarzania. Instancje zadań harmonogramowane są do uruchomienia według jednej z zaimplementowanych strategii. Rozpoczyna pracę manager harmonogramu, uruchamiający zgodnie z powstałym harmonogramem kolejne instancje zadań. Przed uruchomieniem instancji zadania następuje sprawdzenie dostępności wymaganych przez instancje zasobów. Po potwierdzeniu dostępności zasobów następuje ich alokacja i uruchomienie instancji zadania. Po uruchomieniu wszystkich wskazanych przez harmonogram w danej chwili zadań, lub braku wystarczających zasobów manager zapada w drzemkę. Budzi się z niej bądź po upływie określonego w konfiguracji czasu bądź po zakończeniu którejś z uruchomionych instancji zadań. Po wybudzeniu manager odpytuje harmonogram o instancje do uruchomienia. Harmonogram jest w tym momencie przebudowywany, aby uwzględnić nowe warunki (np. pojawienie się wymaganych przez poszczególne instancje danych wejściowych). Manager po otrzymaniu od harmonogramu instancji podejmuje próbę ich uruchomienia i cykl się powtarza. 27 Rys. 4 Diagram działania systemu Instancje zadań uruchamiane są równolegle. Uruchomienie każdej instancji odpowiada uruchomieniu w systemie kolejnej instancji właściwej aplikacji przetwarzającej dane. Dla przykładu testowego, wykorzystywanego przy tworzeniu opisywanego systemu był to SAS. Dla każdej instancji zadania tworzone są monitory śledzące zawartość logów generowanych przez instancje. Śledzone jest również zużycie przez nią zasobów systemowych. Po zakończeniu instancji następuje powiadomienie o tym fakcie managera harmonogramu i zwolnienie zajętych zasobów systemowych. Weryfikowana jest również jakość i dostępność 28 stworzonych przez instancje danych. System może w każdej chwili zakończyć działanie po otrzymaniu sygnału „miękkiego” lub „twardego zatrzymania” bezpośrednio od użytkownika lub sytemu będącego środowiskiem uruchomieniowym. Użytkownik może również chwilowo zatrzymać pracę aplikacji żądaniem przeładowania konfiguracji. System obsłuży wtedy to polecenie i wznowi pracę z nowymi ustawieniami. Dane o stanie instancji a po zakończeniu jej działania o rezultatach są zapisywane na bieżąco do logów i do bazy danych. Rys. 4 zawiera diagram obrazujący działanie systemu. 4.2.2. Struktura aplikacji Na poziomie funkcjonalności system składa się z trzech modułów. 1. Moduł harmonogramujący przede wszystkim odpowiedzialny jest za budowę i dynamiczną aktualizację harmonogramu uruchamiania instancji zdań. Wiąże się z tym odpowiedzialność za konstrukcję obiektów reprezentujących wzorzec, zadania i instancje zdań. 2. Moduł uruchamiający uruchamia wg harmonogramu instancje zdań. 3. Moduł monitorujący śledzi stan uruchomionej instancji i efekt jej pracy. Należy przy tym zaznaczyć, że moduł monitorujący a częściowo i moduł uruchamiający jest zwielokrotniony na poziomie każdej instancji, to jest dla każdej instancji zadania istnieje osobny byt monitorujący jej pracę. Na poziomie struktury fizycznej aplikacji funkcjonalność opisanych powyżej modułów realizowana jest przez klasy zgromadzone w dwóch kluczowych pakietach (task i schedule) obsługiwanych przez klasy zgromadzone w szeregu mniejszych pakietów(db, tools, config i exceptions). Strukturę fizyczną aplikacji przedstawiono na Rys. 5. Pakiet schedule realizuje funkcjonalność modułu harmonogramującego i modułu uruchomieniowego. Pakiet task odpowiedzialny jest za realizacje modułu monitoringu. Znajdują się w nim również klasy związane z obiektową reprezentacją zadań i ich instancji. Pakiet db odpowiedzialny jest za komunikację systemu z bazą danych. Dostęp do plików konfiguracyjnych z dowolnego miejsca aplikacji realizowany jest poprzez pakiet config. Pakiet tools zawiera klasy użytkowe, wykorzystywane przez wszystkie 3 moduły. Między innymi w pakiecie tym znajdują się klasy pozwalające na zapis do logów. Aplikacja korzysta z kilku plików, przechowujących dane niezbędne do jej poprawnego działania. W pliku „SQLqueries.properties”, przechowywanym w podkatalogu SQL znajdują się sparametryzowane kwerendy SQL. Wykorzystuje je pakiet db, zapewniając komunikacje z bazą danych. W pliku „log4j.xml” zdefiniowany jest mechanizm zapisu do logów aplikacji. Przy zapisie komunikatu do logów definiowany jest jego priorytet. Dostępne są 4 priorytety: − DEBUG − INFO − WARNING − ERROR 29 Rys. 5: Struktura fizyczna aplikacji W zależności od priorytetu komunikaty trafiają do różnych logów w podkatalogu logs, wszystkie zaś duplikowane są w pliku ms_run2_ALL_log4j.log. W pliku log4j.xml można zdefiniować na poziomie zarówno pakietów, jak i konkretnych klas priorytet, poniżej którego komunikaty nie będą zapisywane do logów. Opisywane plik daje wiele innych możliwości, 30 których opis można znaleźć w dostępnej pod adresem http://logging.apache.org/log4j/ dokumentacji. W pliku config.xml zdefiniowany jest miejsce przechowywania i format właściwego pliku konfiguracyjnego aplikacji. Aplikacja współpracuje z plikami konfiguracyjnymi w formacie xml i properties. W chwili obecnej właściwym plikiem konfiguracyjnym aplikacji jest plik „msrun.properties”. 4.3. Dalsze plany rozwoju Prezentowana aplikacja w obecnej postaci spełnia opisane we wstępie rozdziału wymagania, stawiane managerowi procesów ETL(Extract,Transform,Load). Jest to prototyp a nie w pełni konkurencyjna, komercyjna aplikacja. Dalszy rozwój aplikacji może nastąpić wg dwóch ścieżek: akademickiej i komercyjnej. Niezależnie od wybranej ścieżki rozwoju w dalszych pracach nad aplikacją powinno uwzględnić się implementacje opisanej poniżej funkcjonalności: − System powinien opcjonalnie poprzednio działający system. − System powinien obsługiwać osierocone instancje zadań. Łączy się to z poprzednio wymienioną funkcjonalnością. Osierocone instancje pojawiają się w przypadku nagłego przerwania procesu przetwarzania. Może to być wywołane np. zabiciem procesu systemowego reprezentującego aplikację lub awarią środowiska, w którym aplikacja została uruchomiona. System powinien rozpoznać stan porzuconej instancji i wprowadzić/uzupełnić informacje o niej do systemu i bazy danych, usunąć tymczasowo tworzone przez instancje pliki, ewentualnie podjąć próbę ponownego uruchomienia instancji zadania. − Użytkownik powinien mieć możliwość wymuszenia ponownego uwzględnienia w harmonogramie usuniętej z niego instancji zadania. − System powinien umieć przetwarzać naraz kilka wzorców przetwarzania, przy czym użytkownik powinien mieć możliwość dodania nowych wzorców przetwarzania w nowych okresach. Podobnie przydatna byłaby możliwość dodania do harmonogramu pojedynczego zadania dla podanego przez użytkownika okresu przetwarzania. kontynuować przetwarzanie rozpoczęte przez Rozwój akademickiej postaci aplikacji sprowadza się do rozwijania biblioteki zawierającej strategie budowy harmonogramu przetwarzania instancji zadań. W ostatniej wersji aplikacji moduł strategii harmonogramowania został wydzielony z całości aplikacji. Dzięki temu zabiegowi implementacja nowej strategii staje się znacznie prostsza. Możliwe jest również testowanie działania aplikacji z różnymi algorytmami harmonogramowania bez konieczności rekompilacji kodu przy zmianie strategii. Wszystko to znacznie ułatwia pracę nad nowymi, innowacyjnymi, bardziej wydajnymi czasowo, wykorzystującymi optymalnie zasoby algorytmami harmonogramowania. Sama implementacja algorytmu jest tu już czynnością wtórną. Rozwój skomercjalizowanej wersji aplikacji a więc dążącej do jej jak największej konkurencyjności powinien uwzględnić poniższe propozycje rozwoju: − Przejście w części dostępu do bazy danych na technologie DAO, z wykorzystaniem Hibernate. Pozwoli to przy dalszym rozwoju aplikacji na znaczne ograniczenie czasu poświęconego na obsłużenie zdarzeń związanych z dostępem do bazy danych − Uniezależnienie pracy aplikacji od rodzaju repozytorium, w którym przechowywane dane o wzorcach przetwarzania i jego składowych (zamiast bazy danych na przykład schematy XML). Umożliwi to wykorzystanie aplikacji bez konieczności instalacji 31 dodatkowego oprogramowania (baza danych/ zakładanie nowej, złożonej struktury w bazie danych). − Stworzenie interfejsu zapewniającego komunikacje z aplikacją na bieżąco (przede wszystkim na potrzeby raportowania aktualnego stanu aplikacji, aktualnego stanu przetwarzania), na przykład w oparciu o mechanizm gniazdek dla części dotyczącej komunikacji i schematy XML dla części dotyczącej budowy raportów. − Budowa interfejsu webowego we frameworku RubyOnRails, z funkcjonalnością obejmującą zdalną administrację i wizualną kontrolę nad stanem bieżącym aplikacji. Proponowany framework zapewnia bardzo szybką konstrukcję interfejsu. − Powiadamianie użytkownika przebywającego w innej lokacji o bieżących zdarzeniach w systemie z wykorzystaniem aplikacji typu jabber lub serwera sms. 5. Wnioski Przeprowadzony przegląd obecnie stosowanych metod i technologii budowania hurtowni danych pozwoliła na identyfikację ich zalet i wad. Modelowanie pojęciowo-funkcjonalne z użyciem formalizmu DLR, metody formalizacji przy użyciu uszczegółowionych zapytań, mechanizm korespondencji, metodyka użycia ASM oraz zastosowanie ramy projektowania scenariuszy ETL do budowy hurtowni danych wydają się zapewniać odpowiednią jakość budowy hurtowni danych, ale są nie wystarczające do zapewnienia długookresowej jakości produktu. W przeciwieństwie do wymienionych wcześniej metodyk, nowa metodyka budowy hurtowni danych (przedstawiona w niniejszej pracy) powinna pozwolić zapewnić długookresową jakość hurtowni danych. W celu udowodnienia tej tezy przystąpiono do implementacji narzędzia nazwanego Moduł Sterujący, które zostało zaprojektowane zgodnie z nową metodyką i które pozwoli na praktyczne wdrożenie i sprawdzenie poprawności nowej metodyki. Konieczna jest dalsza praca, aby dookreślić formalizm dla nowej metodyki i dokończyć implementację Modułu Sterującego. Przydatnym byłoby również zbudowanie hurtowni, która byłaby zaprojektowana, wdrożona i użytkowana zgodne z nową metodyką, aby w pełni zweryfikować poprawność przedstawionej metodyki. 32 Bibliografia [1] Kimball R., Reeves L., Ross M., Thornthwaite W.: The Data warehouse Lifecycle Toolkit. Expert Methods for Designing, Developing, and Deploying Data Warehouses. Wiley. 1998 [2] Todman Chris: Projektowanie hurtowni danych. Zarządzanie kontaktami z klientami (CRM). WNT, 2003 [3] Calvanese D., Dragone L., Nardi D., Rosati R., Trisolini S.: Enterprise modeling and Data Warehousing in Telecom Italia, Information Systems, 2006, Volume 31, No. 1 [4] Zhao J., Ma H.: M ASM-based design of data warehouses and on-line analytical processing systems. The Journal of Systems and Software, 2006, Volume 79 [5] Simitsis V., Georgantas A., Terrovitis P., Skiadopoulos M.: A generic and customizable framework for the design of ETL scenarios. Information Systems, November, 2005, Volume 30, Issue 7 [6] Vassiliadis P., Bouzeghoub M., Quix C.: Towards Quality-Oriented Data Warehouse Usage and Evolution. Information Systems, 2000, Volume 25, No. 2 [7] IBM: IBM WebSphere DataStage, http://www-306.ibm.com/software/data/integration/datastage/ [8] IBM: DB2 Warehouse, http://www-306.ibm.com/software/data/db2/warehouse/ [9] Informatica: Informatica PowerCenter, http://www.informatica.com/products/powercenter/default.htm [10] Teradata: Enterprise Data Warehouse, http://www.teradata.com/enterprise-data-warehouse [11] Natezza: Data warehouse appliance product information from Netezza, http://www.netezza.com/products/data-warehouse-appliance-products.cfm [12] Greenplum: Greenplum - World's Best Database for BI - Products Overview, http://www.greenplum.com/index.php?page=products [13] PANTA: PANTA Systems - Oracle based Data Warehouse Appliances, http://www.pantasys.com/products/overview.html [14] Sybase: Sybase IQ Analytics Server - Data Warehousing & Mining Tool - Sybase Inc, http://www.sybase.com/products/datawarehousing/sybaseiq [15] SAP: SAP - Components & Tools of SAP NetWeaver: SAP NetWeaver Business Intelligence, http://www.sap.com/platform/netweaver/components/bi/index.epx [16] Oracle: Oracle Data Warehousing | Oracle Business Intelligence Solutions, http://www.oracle.com/solutions/business_intelligence/dw_home.html [17] Oracle: Oracle Business Intelligence Foundation and Tools | Oracle Business Intelligence, http://www.oracle.com/appserver/business-intelligence/index.html [18] Oracle: Oracle Data Integrator | Oracle Fusion Middleware, http://www.oracle.com/products/middleware/oracle-data-integrator.html [19] Cognos: Data Integration with Cognos 8 Business Intelligence, http://www.cognos.com/products/cognos8businessintelligence/data-integration.html [20] Bussiness Objects: Performance Management Applications: BusinessObjects Warehouse, http://www.businessobjects.com/products/analyticapps/warehouse/default.asp [21] Bussiness Objects: Data Integration Tools: BusinessObjects Data Integrator, http://www.businessobjects.com/products/dataintegration/dataintegrator/default.asp 33 [22] Microsoft: Microsoft SQL Server: Integration Services, http://www.microsoft.com/sql/technologies/integration/default.mspx [23] Microsoft: Microsoft SQL Server: Data Warehousing, http://www.microsoft.com/sql/solutions/dw/default.mspx [24] Kalido: Kalido - Enterprise Data Management Solutions, http://www.kalido.com/solutions/enterpriseData.asp [25] Sas: SAS | Enterprise Data Integration Server, http://www.sas.com/technologies/dw/entetlserver/index.html [26] The R-Project: The R Project for Statistical Computing, http://www.r-project.org/ [27] Insightful: Statistical analysis software and data mining software | Insightful, http://www.insightful.com/products/splus/default.asp [28] Wikipedia: S (programming language), http://en.wikipedia.org/wiki/S_programming_language [29] Calvanese D., De Giacomo G., Lanzerini M., Nardi D., Rosati R.: Description logic framework for information integration. W: Proceedings of the Sixth International Conference on Principles of Knowledge Representation and Reasoning (KR’98), 1998, str. 2-13 [30] Trisolini S.M., Lanzerini M., Nardi D.: Data integration and warehousing in Telecom Italia. W: Proceedings of the ACM SIGMOD International Conference on Management of Data, 1999, str. 538-539 [31] Calvanese D., De Giacomo G., Lanzerini M., Nardi D., Rosati R.: Use of reconciliation tool at Telecom Italia. Technical Report DWQ-UNIROMA-007, DWQ Consortium, October 1999 [32] Baader F., Calvanese D., McGuinness D., Nardi D., Patel-Schneider P.F. (Eds.): The Description Logic Handbook: Theory, Implementation and Applications. Cambrige University Press, Cambrige, 2003 [33] Donini F.M., Lanzerini M., Nardi D., Schaerf A.: Reasoning in Description logics. W: Principles of Knowledge Representation, Studies in Logic, Language and Information. Red: Brewka G., CSLI Publications, 1996, s. 193-238 [34] Borgida A.: Description logics in data management. IEEE Trans. Knowledge Data Eng., Vol. 7, No. 5, 1995, s. 671-682 [35] Calvanese D., De Giacomo G., Lanzerini M., Nardi D., Rosati R.: Data integration in data warehousing. International Journal of Cooperative Information Systems, Volume 10, Number 3, 2001, str. 237-271 [36] Inmon W.: Building the Data Warehouse. Wiley & Sons, New York, 1996 [37] Horrocks I.: Using an expressive description logic: FaCT or fiction ?. W: Proceedings of the Sixth International Conference on Principles of Knowledge Representation and Reasoning (KR’98), 1998, str. 636-647 [38] University of Manchester, OWL : FaCT++, http://owl.man.ac.uk/factplusplus/ [39] fabFORCE.net: DBDesigner 4, http://www.fabforce.net/dbdesigner4/ [40] CA: CA ERwin® Modeling Suite, http://www.ca.com/us/products/product.aspx?id=297 [41] Sybase: PowerDesigner, http://www.sybase.com/products/modelingmetadata/powerdesigner [42] Tigris.org: ArgoUML, http://argouml.tigris.org/ [43] Oracle: Oracle Developer, http://www.oracle.com/technology/products/jdev/index.html 34