Hurtownie danych

Doświadczenia w budowie prostej hurtowni danych przy użyciu pakietu Systems Engineer firmy LBMS

Doświadczenia w budowie prostej hurtowni danych przy użyciu pakietu Systems Engineer firmy LBMS

Projekt miał na celu stworzenie zbioru danych pozwalającego na przeprowadzanie analizy pracy różnych działów przedsiębiorstwa. Analiza miała polegać m.in. na: porównywaniu osiągniętych wyników lub poniesionych kosztów z wielkościami planowanymi lub też wynikającymi z norm technologicznych.

Podstawowe wymagania użytkownika sprowadzały się do określenia tego, co i jak chce analizować, w jakich okresach, i na ilu poziomach szczegółowości. Poza tym podał on listę systemów informatycznych w przedsiębiorstwie - źródeł danych, z których należało importować informacje.

Wybór narzędzia do realizacji projektu był zupełnie naturalny - w naszej firmie wdrożono pakiet Systems Engineer firmy LBMS.

Analiza kosztów i wyników wykonywana jest w określony i dobrze znany (użytkownikowi) sposób, co sprawia, że łatwo jest przewidzieć, jakich danych i w jakiej postaci on oczekuje. Dotyczy to również agregacji - czyli tego, co należy podsumować, by uniknąć ciągłych przeliczeń podczas prezentacji. Na pewno nie wszystkie zastosowania hurtowni danych mają podobne cechy i dlatego polecana w literaturze struktura hurtowni typu "star-join" wydaje się odpowiednia.

W opisywanym systemie końcowym wynikiem przetwarzania jest zawartość grupy tablic, w których przechowywane są dane w postaci gotowej do prezentacji. Dostęp do danych zapewnia kilka procedur wbudowanych, których stopień skomplikowania nie przekracza poziomu "select'a" z jednej, góra trzech tablic. Czasem wyniki kilku takich poleceń są łączone wierszami przez użycie polecenia "union". W czasie prezentacji nie są wykonywane na serwerze żadne przeliczenia. Na przykład w tym celu, w jednym wierszu tablicy przechowywane są często zarówno wartości szczegółowe, jak i zagregowane (np. koszt narastający od początku roku).

System pozwala na "drill down"/"drill up" zarówno na dwóch poziomach struktury organizacyjnej, jak i po rodzajach kosztów (trzy poziomy) oraz w czasie (rok, miesiąc). Istniejące procedury SQL-owe obsługują jedynie prezentację typowych zestawów danych.

Korzystając jednak z powszechnie stosowanych narzędzi desktopowych (np. tablica przestawna w arkuszu MS Excel), można przeprowadzać opisywane na początku tego paragrafu analizy. Bierze się to stąd, że procedury symulują istnienie tablic o określonej strukturze, a wymieniony "drill", to w nomenklaturze SQL-owej nic innego, jak grupowanie ("drill down" to dodanie grupy w klauzuli GROUP BY, a "drill up" - jej odjęcie) i zamiana atrybutów na ich sumy lub odwrotnie. Tablica przestawna świetnie sobie z tym radzi.

Dlaczego Systems Engineer?

Znacznie trudniej byłoby odpowiedzieć na inne, odwrotne pytanie - a dlaczego nie ? Wybrany pakiet wspomagał bowiem pracę na każdym etapie tego projektu:

- pozwalał na rejestrację i analizę wymagań użytkownika. Poszczególne wymagania i problemy można było kojarzyć z

rozwiązaniami, obrazując w ten sposób drogę tworzenia projektu;

- umożliwił zastosowanie podstawowych technik projektowych, niezależnych od zastosowania, tj. modelowania danych i procesów;

- generował skrypt w języku tworzący bazę na wybranym serwerze dla określonego fizycznego modelu danych. Ponieważ logiczny model danych jest niezależny od serwera, więc uzyskujemy dużą elastyczność, co pozwala - z pewnymi ograniczeniami - na zmianę bazy, nawet w zaawansowanym stadium projektu (ograniczenia dotyczą m.in. naszej umiejętności tworzenia procedur SQL-owych, trzymając się standardu SQL-a, oraz utrzymywania logicznego i fizycznego modelu danych, zgodnych ze zmieniającymi się założeniami. Jeżeli przejście między modelami wiąże się z pewnym nakładem pracy, to istnieje tendencja do pielęgnowania tylko modelu

fizycznego - może trochę wbrew zaleceniom metodyki.);

- dostarczył "inteligentnego" edytora procedur wbudowanych w języku SQL, który zapewniał spójność tworzonego kodu z zawartością repozytorium. Edytor pozwala na rozróżnienie między nazwami atrybutów i encji występującymi w repozytorium (z natury rzeczy bardziej opisowymi) a nazwami docelowymi pojawiającymi się w generowanym kodzie, które podlegają wszystkim ograniczeniom na identyfikatory, występującym w SQL-u. Znacznie zwiększa to czytelność kodu;

- automatycznie wygenerował dokumentację projektu w pliku w formacie RTF na podstawie zdefiniowanego szablonu i występujących przy każdym obiekcie repozytorium informacji. Tego typu możliwości mogą sprawić, że dokumentacja techniczna w ogóle się nie pojawi w danym projekcie. Jak wiadomo, zawsze brak na nią czasu..

Hurtownia danych, w szczególności stosunkowo prosta, tak jak opisywana powyżej, może być dobrym wprowadzeniem do stosowania pakietu. Dzieje się tak dlatego, że omawiane zastosowanie wykorzystuje podstawową część możliwości pakietu, przez co nie trzeba poznawać go w całości (można szybciej pracować w nim produktywnie). Wydaje się, że część funkcji, takie jak opisy transakcji, zdarzeń, funkcji, obiektów użytkownika mają w tym przypadku mniejsze zastosowanie. Z drugiej jednak strony, dla bardziej skomplikowanych hurtowni danych mogą one dostarczyć dokumentację złożonych procesów.

Dobre narzędzie typu CASE pozwala na zachowanie dużej elastyczności projektu wobec nieuchronnych zmian, co szczególnie często występuje w omawianym zastosowaniu (to chyba nie jest gorycz ?). Zmienność ta nie wynika z niestałości użytkowników (ta objawia się raczej dopiero po wdrożeniu...), lecz z zależności hurtowni od zewnętrznych źródeł danych, które pozostają poza zakresem systemu i podlegają zmianom wynikającym z różnych względów, zależnych od natury danego zastosowania. Z reguły potrzeba zachowania interfejsu do hurtowni nie jest wtedy poważnie brana pod uwagę. Poza tym sukces implementacji rodzi życzenia, o których użytkownicy wcześniej albo bali się mówić, albo też nie uświadamiali sobie ich znaczenia.

Systems Engineer ze swoimi możliwościami generacji baz w całości lub fragmentach, edytorem SQL-a i automatycznym tworzeniem dokumentacji ułatwia reagowanie na zmiany. Jest to na tyle bezproblemowe, że większym problemem staje się np. przerzut danych do nowej struktury tablic niż zmiany w przetwarzaniu.

Powyższe uwagi nie mogą być w żadnym razie traktowane jako kompletny opis możliwości pakietu, nawet w ograniczeniu do rozważanych narzędzi. Sygnalizują one jedynie najbardziej oczywiste zalety, tak by odpowiedzieć na pytanie postawione w tytule.

Inne aspekty wykorzystania SE w hurtowniach danych

Narzędzie typu CASE dostarcza wielu możliwości zastosowania różnorodnych technik projektowania aplikacji. Część z nich ma ograniczone zastosowanie w przypadku hurtowni danych. Poniżej podałem garść uwag, będących próbą uogólnienia moich doświadczeń w tej dziedzinie:

- Model procesów - pozwala na opis zależności hurtowni od zewnętrznych źródeł danych oraz na przedstawienie procesu budowy zawartości hurtowni, kolejności wykonywanych operacji i tych, którzy je wykonują.

- Model danych - próby zbudowania znormalizowanego modelu danych są z góry skazane na porażkę. Z różnych względów, z których najważniejszym jest chyba dążenie do osiągnięcia jak najlepszej wydajności systemu. W danych występuje duża redundancja. Inną cechą charakterystyczną jest przechowywanie obliczonych wartości zagregowanych w celu uniknięcia konieczności długotrwałych przeliczeń. Nie oznacza to jednak, że model danych jest niepotrzebny. Baza danych zrealizowana będzie w technologii relacyjnej i w związku z tym należy ją poprawnie zdefiniować. Polecane w literaturze schematy typu "star-join", przedstawiające centralną tablicę "faktów" i powiązane z nią relacjami jeden-do-wielu tablice "wymiarów" (czas, produkt itp.), dają się bez problemów opisać za pomocą narzędzia Systems Engineer. Z drugiej strony, w systemie może występować wiele tablic pomocniczych (nie mówiąc już o tymczasowych), których zawartość będzie służyć do wykonywania przeliczeń i przygotowywania ostatecznych danych. Ich obecność nie jest istotna z punktu widzenia analizy końcowych danych, ale ma jednak znaczenie dla przetwarzania i w związku z tym powinna być właściwie udokumentowana.

- Procedury bazy danych - definiują sposób przetwarzania, który może być skomplikowany, szczególnie w sytuacji dużej różnorodności źródeł danych (i ich formatów). Tutaj widzę największą zaletę pakietu polegającą na integracji tych procedur z zawartością repozytorium. Możliwość zachowania spójności procedur ze strukturą bazy eliminuje mnóstwo błędów i znacznie przyspiesza przygotowanie aplikacji.

Poza tym hurtownia (szczególnie taka, która odnosi sukces i jest zaakceptowana przez użytkowników) ciągle żyje. Pojawiają się prośby o rozszerzenie zakresu przechowywanych informacji, umożliwienie innych rodzajów analiz, przyspieszenie dostępu do danych. Powoduje to konieczność zmian w strukturze bazy przez dodanie nowych agregacji. Dobrze jest móc zachować nad tym kontrolę.

Czego można by sobie jeszcze życzyć?

Pakiet Systems Engineer w używanej przeze mnie wersji (5.1.8) jest produktem uniwersalnym. Pojawił się jednak na rynku w chwili, gdy o hurtowniach danych dopiero zaczynało być głośno, co wskazuje na to, że potrzeby tak specyficznych zastosowań, jakim są hurtownie danych, nie były przy jego tworzeniu brane pod uwagę. Nie powinien więc nikogo zaskoczyć fakt, że brakuje w nim pewnych funkcji, które dodatkowo ułatwiłyby pracę projektanta:

- Hurtownia importuje danye z wielu zewnętrznych źródeł. Ich strukturę można przedstawić w oddzielnych modelach danych (zawartych w innych bazach SE), ale nie można skorzystać z zawartości tych modeli podczas pisania procedur SQL-owych. Trudno jest więc kontrolować spójność z repozytorium na stykach hurtowni z innymi źródłami danych. Można natomiast użyć ich do automatycznego generowania dokumentacji o źródłach danych.

- Podczas pisania procedur natknąłem się na drobną uciążliwość związaną z organizacją modułów. Struktura modułów jest dwupoziomowa z modułem głównym i modułami zależnymi. Jest to dobra koncepcja, ponieważ można w ten sposób grupować procedury logicznie ze sobą powiązane, np. importujące dane, przetwarzające je i procedury służące do prezentacji. Niestety, podczas generowania kodu zmienionych modułów nie można ograniczyć zakresu generacji poniżej poziomu modułu głównego. Jeżeli chcemy przesłać do bazy tylko jeden poprawiony moduł, to dostajemy ich całą grupę i trzeba posłużyć się edytorem w celu wyłowienia interesującego nas kodu (albo zregenerować również i te moduły w grupie, które nie uległy zmianie).

- Automatyczne tworzenie dokumentacji działa bez zarzutu i pozwala na stworzenie sformatowanych dokumentów projektowych i opisów technicznych. W zasadzie atrybuty poszczególnych obiektów repozytorium pozwalają na ich pełny opis. Pominięto jedynie opisy poszczególnych modułów, które czasem przydałyby się w tworzeniu dokumentacji (komentarze zawarte w kodzie nie zawsze go zastąpią).

Dane przechowywane są w bazie zarządzanej przez Microsoft SQL Serwer. Ładowanie danych do bazy z plików z poziomu systemu operacyjnego jest wykonywane przy pomocy programu bcp dostarczanego wraz z SQL Server'em. W tym artykule chciałbym skoncentrować się tylko na swoich doświadczeniach związanych z wykorzystaniem pakietu Systems Engineer, pomijając przy tym inną, równie ważną część prac, związaną z przygotowaniem części danych źródłowych i prezentacją wyników wykonaną przez współpracujących ze mną Ewę Nowakowską i Mariusza Orlińskiego.

Podsumowanie

Wykorzystanie Systems Engineer w projektowaniu hurtowni danych nawet jeśli obejmuje również fazę implementacji tak jak w tym wypadku (procedury SQL-owe definiujące sposób przetwarzania danych) nie wyczerpuje wszystkich aspektów pracy nad projektem. Bardzo ważny jest odpowiedni wybór innych narzędzi, które można użyć do:

- tworzenia programów do prezentacji lub też przygotowywania danych nie obsługiwanych przez żaden inny system informatyczny w przedsiębiorstwie (niewątpliwie bardzo często spotykana sytuacja). Tu można zastosować Visual Basic, Power Builder, Delphi, Microsoft Access

- manipulowania zbiorami danych podczas dokonywania zmian w strukturze bazy na serwerze, przechowywania danych. Odpowiednia baza danych powinna conajmniej zapewniaą wygodny (tzn. automatyczny i działający) interfejs do ładowania danych z plików systemu operacyjnego oraz dodatkowe możliwości indeksowania zbiorów danych, które mogą być przeciez olbrzymie.

- przetwarzania danych, które nie zawsze może odbywać się na docelowym serwerze przy użyciu SQL-a tak jak w omawianym przypadku.

Opisywany przeze mnie projekt był niewielki i w żadnym wypadku jego opis nie obejmuje wszystkich aspektów tworzenia hurtowni danych. Istnieje wiele narzędzi specjalizowanych, które są wykorzystywane zarówno do tworzenia hurtowni, przechowywania danych, jak i przygotowywania aplikacji do ich prezentacji. Warto się nimi również zainteresować, choćby po to by dokonać właściwego wyboru. Ich zastosowanie może przynieść duże skrócenie czasu spędzonego na implementacji projektu, a niekiedy jak np. w przypadku wyboru właściwej bazy może wręcz uniemożliwić jego realizację. Można się spodziewać, że również te bardziej zaawansowane narzędzia pozwalają na udany mariaż z pakietem typu CASE. O ich zastosowaniu decyduje przede wszystkim skala przedsięwzięcia, tzn. planowana ilość przechowywanych danych, ich organizacja oraz liczba i stopień skomplikowania analiz, a więc rośnie też i rola programów wspomagających projektowanie na etapie projektowania hurtowni.

Zaczynają wtedy grać rolę inne funkcje narzędzi, takie jak np. możliwość pracy grupowej nad projektem ze wspólnym repozytorium, modelem danych i pełną kontrolą uprawnień.

Piotr Wawak jest analitykiem/projektantem systemów informatycznych w Petrochemii Płockiej.