Metody i technologie budowy hurtowni danych ze szczególnym uwzględnieniem zapewnienia długookresowej jakości produktu

Transkrypt

1 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 Warszawa

2 Metody i technologie budowy hurtowni danych ze szczególnym uwzględnieniem zapewnienia długookresowej jakości produktu Praca nr 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

3 Spis Treści 1. Wstęp Przegląd stosowanych technologii i metod Podstawy hurtowni danych Typowe metody i technologie budowy hurtowni danych Warstwa konceptualno-funkcjonalna Warstwa logiczna Warstwa fizyczna Narzędzia użyteczne w budowie hurtowni danych Zastosowanie ASM do budowy hurtowni danych Opracowana metodyka Moduł Sterujący Funkcjonalność systemu Uruchomienie Konfiguracja Zatrzymanie aplikacji Komunikacja systemu z użytkownikiem Realizowana funkcjonalność Działanie i budowa systemu Działanie systemu Struktura aplikacji Dalsze plany rozwoju Wnioski...32 Bibliografia

4 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 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

5 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 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

6 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 Projekt Funkcjonalny Model pojęciowofunkcjonalny Schemat funkcjonalny Schemat Hurtowni Danych Schemat Źródła Danych 1 Warstwa logiczna Projekt Techniczny Model logiczny Specyfikacja aplikacji użytkownika Specyfikacja struktur Hurtowni Danych Specyfikacja logiki ładowania danych Specyfikacja logiki transformacji danych Specyfikacja logiki ekstrakcji danych Warstwa fizyczna Implementacja Aplikacja użytkownika Hurtownia Danych Moduły ładowania danych Moduły transformacji danych Moduły ekstrakcji danych Schemat Źródła Danych n Specyfikacja struktur Źródeł Danych Źródło Danych 1 Źródło Danych n mapowanie pojęciowo-logiczne mapowanie logiczno-fizyczne logiczny przepływ danych fizyczny przepływ danych 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

7 obiektów opisywanych przez źródła danych; relacji pomiędzy obiektami opisywanymi przez źródła danych a obiektami analizowanymi i opisywanymi poprzez zawartość HD. 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 Foundations of Data Warehouse Quality (DWQ), 7

8 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

9 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 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

10 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 na schemat zaprojektowany na podstawie modelu pojęciowo-funkcjonalnego 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ę komponentów ~ x, użycie symbolu ~ x odnotowuje, że chodzi tu krotność zmiennych x, K, x dla pewnego n 1 n, ten symbol oznacza również zbiór zmiennych x, K 1, xn q ( ~ x, ~ y) ciało, opisuje zawartość relacji przy użyciu warunków modelu pojęciowofunkcjonalnego, q zapytanie, którego formę podaje. Ciało ma formę: gdzie: conj ~ x, ~ y ) koniunkcja atomów, i( i conj ~, ~ L ~, ~ ), (2) ( x y1 ) conjm( x ym 1 10

11 ~ x, ~ wszystkie zmienne występujące w koniunkcji. y i Każdy z atomów może reprezentować: encje występujące w modelu pojęciowo-funkcjonalnym, przy użyciu formy: gdzie: E encje występujące w MPF, t zmienna w ~ x, ~ y lub stała; i E () t, (3) relacje w modelu pojęciowo-funkcjonalnym, przy użyciu formy: gdzie: R relacje występujące w MPF, ~ t zmienna w ~ x, ~ y i lub stała; R () ~ t, (4) atrybuty w modelu pojęciowo-funkcjonalnym, przy użyciu formy: gdzie: A atrybuty występujące w MPF, t zmienna w ~ x, ~ y lub stała; t zmienna w ~ x, ~ yi lub stała. i ( t t ) A,, (5) 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 conj ~ x, ~ y L conj ~ x, ~, (6) ( ) ( ) ( ) 1 1 m y m dla którego arność n oznacza n -krotny zbiór ( d, K 1,dn ), w którym każde di jest takim obiektem tej bazy danych, że przy zastąpieniu każdego d przez x wyrażenie: daje w wyniku prawdę. ~ y conj ~, ~ L ~ ~, ~ ), (7) ( x y1 ) ym conjm( x ym 1 1 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 zawiera się w q, jeżeli zbiór krotek wybranych przy użyciu q 2, dla każdej bazy spełniającej warunki MPF. q 1 i i q1 2 zawiera się w zbiorze krotek wybranych przy użyciu 11

12 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 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 α,, α, (8) gdzie: α, K 1,α uszczegółowienie, n ( ) ( ) K 1 n α i oznaczenie przypisów do poszczególnych zmiennych wyspecyfikowanych w ~ x. Uszczegółowienie można opisać przy pomocy dwóch poniższych definicji. Dla każdego X ~ x przypis uszczegóławiający ma formę: gdzie: V domena wyrażenia. X :: V, (9) Formuła uszczegółowienia (9) definiuje w jaki sposób wartości przypisane do zmiennej X są reprezentowane w tabeli na poziomie logicznym. Dla każdego zbioru wartości ~ z ~ x, który został użyty w celu identyfikacji w T obiektu pojęciowego Y ~ y wymienionego w q ( ~ x, ~ y), przypis uszczegółowiający przyjmuje formę: 12

13 ([] z Y ) gdzie: [] z~ grupuje zmienne ~ z w pojedynczy argument. Identify ~,, (10) Przypis uszczegółowiający (10) definiuje explicite, że zbiór wartości reprezentacją obiektu pojęciowego Y. 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. z~ jest 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] 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

14 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] 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 do projektowania i wykonywania procesów ETL [7,9,15,18,19,21,22,24,25]. 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

15 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

16 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

17 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] 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 M1 11 1n1 k EXPORT q1, K, ql SIGNATURE gdzie: M etykieta opisywanej aktualnie ASM; M i etykieta ASM zdefiniowanej gdzie indziej; r ij nazwy funkcji i reguł importowanych z ASM M i i są jedynie używane w ; ( r, Kr ), K, M ( r, K, r ) M i k1 knk, (11), które zostały zdefiniowane w ciele M i 17

18 q 1, K,q l 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 f,,, dla każdej z funkcji f podaje się arność tej funkcji, która jest oznaczana jako ar i jest liczbą całkowitą nie ujemną. i 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. i 1 K f m 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

19 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

20 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