Systemy Wspomagania Podejmowania Decyzji

W każdym przedsiębiorstwie wykorzystującym system informatyczny do wspomagania zarządzania można wyróżnić następujące typy systemów przetwarzania informacji przeznaczone dla różnych grup użytkowników. Są to:

Systemy transakcyjne - aplikacje wspierające bieżącą aktywność przedsiębiorstwa w zakresie księgowości, finansów, kadr, produkcji, gromadzące dane i udostępniające dane w postaci raportów i zestawień - wykorzystywane przez bezpośrednich wykonawców operacji;

Systemy informacyjne (ang. Management Information Systems - MIS) - aplikacje wspierające zarządzanie, dostarczające informacji, działające na bazach transakcyjnych (np. FK, Kadry, Płace, Magazyn, itp.), wykorzystywane przez analityków i kierowników średniego szczebla;

Systemy Wspomagające Podejmowanie Decyzji (ang. Decision Support Systems - DSS) - aplikacje dostarczające wiedzy, wykorzystywane przez kierownictwo średniego i wysokiego szczebla oraz analityków biznesu;

Systemy Informowania Kierownictwa (ang. Executive Information Systems - EIS) SIK - aplikacje dostarczające kierownictwu wybrane zestawienia i raporty z systemu DSS.

Systemy te przedstawiane są graficznie w postaci piramidy (rysunek 1), której podstawą są systemy transakcyjne i związane z nimi bazy danych transakcyjnych, a wyżej znajdują się systemy informacyjne (raporty, analizy), systemy wspomagania decyzji i związane z nimi hurtownie danych.

Jak wynika z przedstawionych definicji zarówno Systemy Wspomagania Decyzji (DSS) jak i Systemy Informowania Kierownictwa (SIK), to systemy zapytań stosowane dla uzyskania informacji niezbędnej dla podjęcia decyzji biznesowej. Różnica między systemami DSS i EIS sprowadza się do typu informacji jaką dysponuje my w systemie oraz predefiniowanych w systemie zapytań.

Rysunek 1: Hierarchia systemów informatycznych w przedsiębiorstwie.

System DSS dysponuje danymi i dokonuje analizy w oparciu o dane, które są zarządzane w obrębie organizacji przez różne transakcyjne systemy informacyjne, natomiast EIS często korzysta z informacji spoza wewnętrznych źródeł informacyjnych.

Generalnie DSS odnosi się do systemu, który uwzględnia specyficzną skalę danego biznesu: sprzedaż/dystrybucja, wytwarzanie/produktywność, itd. Taki system zarządza informacją o biznesie i jest używany do podejmowania decyzji takich jak:

czy powinniśmy produkować nadal wyrób X?,

czy powinniśmy łączyć sprzedaż X z Y?, itp.

SIK odnosi się do systemu, który zarządza całą informacją o biznesie i dlatego powinien zawierać dodatkowo dane zewnętrzne, które mogą oddziaływać na biznes, takie jak:

• klimat polityczny,

• ilość towaru na rynku,

• zapotrzebowanie na dany towar, itp.

System jest zaprojektowany z myślą o kierownikach podejmujących decyzje strategiczne typu:

czy powinno się otworzyć biuro w Rosji ?,

czy istnieją odpowiednie zdolności wytwórcze do wejścia na nowy rynek ?, itp.

Systemy DSS i SIK są tworzone dla użytkowników, którzy nie znając języków programowania, chcą z systemu uzyskać odpowiedzi, zarówno na pytania kompleksowe jak i bardzo nietypowe (ad-hoc), przedstawione w formacie łatwym do interpretacji (tabele, grafy, wykresy słupkowe).

System Wspomagania Podejmowania Decyzji (DSS) powinien wspomagać proces decyzyjny przez udzielenie na przykład odpowiedzi na następujące pytania:

• których dostawców wybrać ?

• jaka jest zdolność kredytowa ?

• jaki jest optymalny plan produkcji na następny rok ?

• jak dużo wydaje się miesięcznie w każdym oddziale w stosunku do założonego planu?

• jaka była sprzedaż produktu X w regionie Z w ostatnim miesiącu?

• co będzie się najlepiej sprzedawało w regionie Z w przyszłym roku ?

Dla udzielenia takich odpowiedzi system musi opierać się na wskaźnikach decyzyjnych takich jak:

• rentowność kapitału,

• udział w rynku,

• efektywność działań,

• zwrot inwestycji, itp.

i musi stosować różne techniki analitycznego przetwarzania danych (Analitycal Processing), np. rachunek prawdopodobieństwa, wnioskowanie statystyczne, analiza regresji, analiza korelacji, analiza trendów, analiza wrażliwości, analiza typu "co jeśli", itp.

Przed wprowadzeniem Systemu Wspomagania Podejmowania Decyzji i hurtowni danych w przedsiębiorstwie należy odpowiedzieć na pytanie czy i dlaczego system taki jest potrzebny. Najczęściej uzasadnieniem dla jego wprowadzenia są:

• poprawa planowania;

• zwiększenie kontroli nad procesem zarządzania;

• redukcja kosztów;

• zorientowanie rynkowe przedsiębiorstwa;

• konkurencja.

Jeśli

• firma małej lub średniej wielkości jest dobrze zarządzana;

• dane zawarte w systemach transakcyjnych są dobrej jakości i zawierają również dane historyczne;

• raporty są dostarczane przez system transakcyjny na bieżąco i są wystarczające dla podejmowania decyzji;

• nie ma potrzeby tworzenia nietypowych raportów ad hoc

to wprowadzanie systemu Wspomagania Podejmowania Decyzji nie jest konieczne.

Tworzenie systemu DSS jest uzasadnione w firmie, która jest:

• zrestrukturyzowana,

• posiada dobrze zdefiniowane cele,

• strategię

• ma przygotowane szczegółowe procedury rozliczania kosztów, budżetowania, obliczania zysku, analizy rynku, itp.

Wdrażanie systemów DSS jest konieczne w dużych przedsiębiorstwach. Obecnie uzasadnimy tezę, że docelowy system DSS powinien być budowany w oparciu o

HURTOWNIE DANYCH

Hurtownie danych, w odróżnieniu od innych dużych systemów biznesowych, ułatwiają podejmowanie strategicznych decyzji, a nie wspierają codziennej działalność przedsiębiorstwa. Aby z powodzeniem zaprojektować i uruchomić hurtownię danych, należy zrozumieć niuanse i wątki związane z tym rozróżnieniem.

Co wyróżnia hurtownię danych?

Hurtownie danych różnią się drastycznie od systemów operacyjnych poczynając od informacji, które przechowują, a kończąc na zadaniach, które wykonują.

Hurtownie danych potrzebują danych historycznych (archiwalnych) z wielu lat, aby użytkownicy mogli analizować trendy biznesowe, takie jak zmiany w sprzedaży czy zmiany demograficzne.

Systemy operacyjne potrzebują tylko tych informacji archiwalnych, które są niezbędne do zapewnienia codziennej dostawy produktów lub usług.

Na przykład, zeszłoroczne salda i transakcje są nieistotne dla systemu operacyjnego. Faktycznie, żeby nadzorować koszty i wskaźniki wydajności, systemy operacyjne utrzymują informacje archiwalne na minimalnym poziomie. Prawie wszystkie systemy operacyjne, przynajmniej raz w roku, pozbywają się starych informacji o dokonanych transakcjach, zamkniętych kontach i innych, niepotrzebnych do prowadzenia codziennej działalności.

System wspomagania podejmowania decyzji musi natomiast utrzymywać zarówno zeszłoroczne salda i transakcje klientów, jak i te bieżące (lub ich ostatni wyciąg). Użytkownicy systemu DSS chcą znać:

• czynniki, które doprowadziły do zamknięcia konta;

• charakterystykę demograficzną zamkniętych kont.

Dla użytkowników systemów DSS zamknięte konta są często tak samo ważne jak konta otwarte.

Zamknięte konta są nieistotne dla systemów operacyjnych, gdyż jedynie konta otwarte są aktywne.

W wyniku zapotrzebowania na wieloletnie dane historyczne, baza danych do wspomagania podejmowania decyzji często jest dwukrotnie lub trzykrotnie większa od bazy danych do przetwarzania operacyjnego. Nierzadko spotyka się hurtownie danych przechowujące historyczne dane z dwóch, trzech lub nawet siedmiu lat (dla starszych danych często w postaci sumarycznej).

Wraz ze spadkiem kosztów pamięci dyskowej, w stosunku do wartości informacji, obserwuje się tendencję wydłużania czasu przechowywania danych historycznych w systemach wspomagania podejmowania decyzji.

Po co hurtownia danych?

Gdy zrozumie się, czym różni się hurtownia danych od tradycyjnego systemu operacyjnego, pytaniem staje się:

Jakie nowe wartości wniesie do organizacji przedsiębiorstwa?

Wiedza o tym, dlaczego hurtownia danych jest potrzebna, ułatwia jej projektowanie i pozwala przekonać do niej pracowników firmy.

Główne korzyści ze stworzenia hurtowni danych są następujące:

1. Zintegrowany i całościowy obraz przedsiębiorstwa.

2. Dostęp do archiwalnej informacji o przedsiębiorstwie.

3. Wewnątrz przedsiębiorstwa jednoznaczne źródło informacji, które jest godne zaufania.

4. Wspomaganie podejmowania decyzji bez ingerencji w systemy operacyjne.

Pełni obraz przedsiębiorstwa

Hurtownia danych scala informacje z zasadniczo odmiennych systemów operacyjnych w jeden pełny obraz przedsiębiorstwa. Wspólne struktury kluczy, zintegrowana organizacja danych i ujednolicony zbiór definicji danych dostarczają środków umożliwiających wspomaganie podejmowania decyzji nie do osiągnięcia w inny sposób. Otrzymany w ten sposób pełny obraz przedsiębiorstwa daje analitykom informacje niezbędne do podjęcia trafnych decyzji dotyczących zagadnień strategicznych, które mają znaczący, dalekosiężny wpływ na działalność przedsiębiorstwa. To jest zasadnicza różnica w stosunku do decyzji szczegółowych podejmowanych na podstawie danych z jednego obszaru działalności.

Przeszłość najlepiej przewiduje przyszłość

Zrozumienie dotychczasowych trendów i zachowań, a następnie po­znanie, w jaki sposób aktualne otoczenie biznesowe wynikło z przeszłości, umożliwiają firmom opracowanie planów analiz ilościowych w celu podejmowania decyzji. Zamiast ograniczać się do modeli decyzji jakościowych, hurtownia danych wyposaża użytkowników końcowych w analityczne podstawy do podejmowania decyzji.

Rozważmy np. firmę próbującą zwiększyć swój udział w rynku przez obniżenie ceny swojego produktu. Bez historycznych danych o cenie i popycie na produkt, podejmujący decyzje muszą prognozować na podstawie tylko intuicji i doświadczenia, żeby ocenić wpływ spadku ceny na udział w rynku. Jednakże, gdy historyczne dane o cenach i produkcie są w hurtowni, analitycy mogą przewidzieć ten wpływ. Prawdziwa siła hurtowni danych w tym przykładzie pochodzi z możliwości stawiania pytania „co-jeśli" w celu określenia wyników różnych strategii ustalania ceny. Zamiast wypróbowywania tych strategii na rynku i czekania na to, co się stanie (z potencjalnymi fatalnymi rezultatami), analitycy rynkowi mogą testować proponowane obniżki cen w środowisku wspomagania podejmowania decyzji i stawiać pytania aż do zoptymalizowania ceny, udziału w rynku i zysku. Oczywiście, dostęp do historycznych danych jako podstawa wspomagania podejmowania decyzji jest kluczowy.

CEL BUDOWANIA HURTOWNI

1. Hurtownie danych istnieją, aby ułatwić podejmowanie taktycznych i strategicznych decyzji.

2. Hurtownie danych różnią się od systemów operacyjnych w na­stępujących aspektach:

• Hurtownie danych przechowują dane archiwalne i umożliwiają użytkownikom podejmowanie ważnych decyzji biznesowych. Systemy operacyjne przechowują jedynie dane niezbędne w co­dziennej działalności.

• Hurtownia danych jest aktualizowana okresowo we wcześniej określony sposób; system operacyjny jest aktualizowany w cza­sie rzeczywistym.

• Poziomy usług hurtowni danych nie są zazwyczaj tak sztywne jak systemów operacyjnych. Początkowo hurtownia danych może działać 12 godzin dziennie, przez 6 dni w tygodniu, chociaż wymóg ten z czasem wzrośnie, gdy użytkownicy uzależnią się od hurtowni.

• Tradycyjne systemy raportowania udostępniają zestandaryzowane raporty o ograniczonej liczbie szablonów. Hurtownia danych musi uwzględniać użytkowników wykonujących analizy interakcyjnie i ad hoc.

• Ścieżki dostępu i nieustrukturyzowane środowisko zapytań wymaga innej organizacji bazy danych w hurtowni niż w sy­stemie operacyjnym, gdzie zachowanie transakcji jest prze­widywalne i bardziej selektywne w liczbie rekordów wymaga­nych w procesie przetwarzania.

• Hurtownia danych integruje informacje z wielu operacyjnych i zewnętrznych systemów w jeden, pełny obraz całego przed­siębiorstwa.

3. Hurtownia danych daje użytkownikowi analityczną podstawę do podejmowania decyzji. Informacje archiwalne z hurtowni danych są wykorzystane do tworzenia aplikacji, algorytmów i modeli dla decyzji biznesowych.

4. Zintegrowana hurtownia danych dostarcza firmie zgodnych danych liczbowych, tak aby podejmujący decyzje opierali się na tych samych danych.

5. Hurtownia danych ma większe szanse powodzenia, jeśli jej baza danych jest oddzielona od operacyjnej bazy danych, w środowisku sprzętowym niezależnym od systemów operacyjnych. W ten sposób użytkownicy mogą korzystać z hurtowni danych bez wpływania na wykonywanie codziennych operacji.

6. W udanej hurtowni danych dane archiwalne są wykorzystywane do tworzenia aplikacji o jasnych korzyściach biznesowych, bezpo­średnio wpływających na wyniki finansowe firmy. Do aplikacji zwiększających zyski firm w wielu dziedzinach można zaliczyć:

• Wykrywanie oszustw i przeciwdziałanie oszustwom zanim pojawią się straty.

• Systemy ukierunkowanego marketingu umożliwiają firmie zrozumienie zachowania się klientów i zapotrzebowania na produkt, tak aby kampanie marketingowe mogły być skie­rowane do tych, którzy odpowiedzą na nie pozytywnie.

• Analiza rentowności pokazuje firmom, którzy klienci są dochodowi, a którzy nie; pozwala to na opracowanie progra­mów oddziaływania na klientów.

• Aplikacje zatrzymywania klientów pomagają firmom ziden­tyfikować i zatrzymać klientów dochodowych, co jest tańsze od pozyskiwania nowych klientów.

• Zarządzanie zapasami umożliwia producentom i handlowcom posiadanie właściwych produktów we właściwym miejscu i cza­sie, co zapobiega nadmiernym stratom wynikającym z braku lub nadmiaru produktów.

• Analiza ryzyka kredytowego umożliwia firmom uniknięcie złych długów przez wychwycenie wśród klientów o mieszanej historii kredytowej tych, którym udzielenie kredytu jest naj­mniej ryzykowne.

• Długoterminowa ocena wartości klienta pozwala firmom prze­widywać, którzy klienci będą w przyszłości dochodowi, a którzy nie.

• Ustalanie konkurencyjnych cen umożliwia firmom stworzenie nowych metod kalkulacji przez rozpoznanie popytu na produkt, konkurencyjności na rynku i marż zysku.

Kluczowymi elementami zapewniającymi sukces hurtowni danych są:

• Projekt hurtowni danych koncentrujący się na biznesie, a nie na technologii. W udanych implementacjach hurtowni danych podejmowane decyzje są decyzjami biznesowymi, a nie tech­nologicznymi.

• Należy stosować metodykę iteracyjnego rozwoju z krótkimi cykla­mi i częstym udostępnianiem nowych usług.

• Należy włączyć użytkowników do zespołu implementującego. Ich udział jest niezbędny w podejmowaniu decyzji projektowych, które umożliwią hurtowni osiągnięcie celów biznesowych.

Projektowanie baz danych wspomagających podejmowanie decyzji

Tego typu systemy są projektowane w celu umożliwienia analitykom łatwego i szybkiego zdobywania danych. Analizowanie danych jest z natury historyczne i pochodzą z różnych okresów.

Pożądane cechy:

• Klarowność: struktury muszą być zrozumiałe dla użytkowników

• Statyczność: większość zmian w bazie odbywa się w sposób kontrolowany

• Nieprzewidywalne i złożone zapytania SQL

• Złożone kryteria oceny działalności firmy wymagają często użycia zaawansowanych konstrukcji SQL

• Duże i złożone zbiory wyników powinny być w odpowiedni sposób projektowane.

• Odzyskiwalność: regularne tworzenie kopii zapasowych lub zrzuty chronią bazy przed utratą danych.

Architektura Hurtowni danych

Hurtownia danych (Data Warehouse) jest aplikacyjnie zorientowaną bazą do odczytu wykorzystywaną jako podstawa do wspomagania podejmowania decyzji. Zasadniczą koncepcją hurtowni jest połączenie danych z różnych baz w jednej bazie. System hurtowni danych różni się od transakcyjnych baz danych przedsiębiorstwa w następujących obszarach:

• istniejące systemy baz danych pozostają w użyciu

• dane wspólne są powielone w hurtowni danych

• dane w hurtowni nie są uaktualniane w czasie rzeczywistym (na bieżąco) lecz okresowo

Systemy DSS oraz SIK mogą czytać dane wprost z hurtowni lub dane mogą być kopiowane do innych mniejszych, dziedzinowych hurtowni danych określanych jako "Data Mart" (ang. mart - hala targowa, targowisko).

Dane do hurtowni Data Mart pochodzą z baz danych zorientowanych na konkretne aplikacje.

Środowisko hurtowni danych jest z założenia nadmiarowe. Wiele systemów baz danych dla obsługi przedsiębiorstwa i systemów archiwalnych umieszcza dane we wspólnej bazie, która z kolei może być powielona w jednej lub kilku hurtowniach tematycznych.

Na modelowe środowisko Wspomagania Podejmowania Decyzji składają się następujące warstwy oprogramowania:

1. Warstwa przetwarzania transakcyjnego (OLTP Layer) - odpowiedzialna za działanie operacyjne i administracyjne systemu. Współczesne systemy OLTP przechowują w znormalizowanej relacyjnej bazie bieżące dane operacyjne.

2. Warstwa hurtowni danych (Data Warehouse Layer) - dane przechowywane są często w postaci nie znormalizowanej, co powoduje nadmiarowość danych, jednak ułatwia operacje analityczne i tworzenie raportów. Przenoszenie danych z warstwy OLTP do warstwy Data Warehouse (ekstrakcja danych) jest najtrudniejszym i najbardziej czasochłonnym zadaniem w procesie tworzenia środowiska DSS. Ta warstwa często jest usytuowana na specjalizowanym sprzęcie i korzysta z wyspecjalizowanego oprogramowania.

3. Data Mart Layer - w tej warstwie przechowywane są dane sumaryczne utworzone w oparciu o dane warstwy Data Warehouse. Dane te przechowywane są w formacie, który pozwala na szybki, intuicyjny i efektywny dostęp do danych. Zwykle każda baza Data Mart jest bazą tematyczną i dotyczy wybranego zagadnienia (np. budżet, analiza finansowa, analiza sprzedaży, itp.).

4 Warstwa prezentacji - to warstwa środowiska graficznego adresowanego do końcowych użytkowników Data Mart lub Data Warehouse. W tej warstwie wyróżnia się zwykle oprogramowanie typu:

• OLAP GUI - dla końcowych użytkowników Data Mart

• Managed Query Environment (MQE) - dla końcowych użytkowników Data Warehouse

• Geographic Information Systems (GIS) - dla wizualizacji danych topograficznych

Rysunek: Cztery obszary działania systemów DSS

Narzędzia warstwy prezentacji działają zawsze na stacjach klientów w środowisku o architekturze klient-serwer.

Przetwarzanie analityczne

Dla bardziej efektywnego realizowania dostępu do danych i budowania systemów DSS konieczne są nowe sposoby analitycznego przetwarzania danych. Najczęściej wyróżnia się cztery obszary zastosowań przetwarzania analitycznego.

1. Raportowanie nie wymaga przetwarzania analitycznego, a jedynie dostępu do danych. Może być zwykle realizowane wsadowo (off-line) i prezentowane w formie wydruku. Ten obszar wspomagania podejmowania decyzji jest zwykle wbudowany w każdy współczesny SQL-owy system transakcyjny.

2. Interaktywne przetwarzanie analityczne (On-Line Analitycal Processing - OLAP), które dostarcza pogłębionych analiz finansowych i marketingowych.

3. Przetwarzanie predykcyjne - ma umożliwić przewidywanie zachowań naszego przedsiębiorstwa, rynku, biznesu w oparciu o posiadane dane i założone wskaźniki - do tego celu stosuje się technologię drążenia danych (Data Mining).

4. Modelowanie biznesu, przewidywania przyszłości, kreowania planów.

Stosowane są trzy koncepcje realizacji przetwarzania OLAP:

• MOLAP - w oparciu o serwer bazy wielowymiarowej (MDD lub MDDB - Multidimensional Database Server);

• ROLAP - w oparciu o relacyjne serwer bazy danych, przez stosowanie schematów danych typu gwiazda (star) lub płatek śniegu (snowflake).

• HOLAP - w oparciu o bazę hybrydową, relacyjno-macierzową lub kilka baz różnego typu

Modelowanie danych

Hurtownie danych zarówno Data Warehouse jak i Data Mart stosowane w DSS lub EIS mogą być relacyjną lub wielowymiarową hierarchiczną bazą danych.

Należy zdawać sobie sprawę, że relacyjna struktura ROLAP odbiega od znormalizowanych struktur baz danych stosowanych w systemach transakcyjnych i doświadczenia nabyte w tworzeniu systemów OLTP nie są wystarczające przy tworzeniu systemów OLAP, bez względu na to, czy wybiera się strukturę baz danych MDDB czy ROLAP.

Wielowymiarowa analiza danych MOLAP

Wielowymiarowe systemy MOLAP wykorzystują wielowymiarową strukturę danych, dla prowadzenia interaktywnego analitycznego przetwarzania. Istotną cechą tych systemów jest to, że konieczne jest przechowywanie danych w formacie wielowymiarowym po to, by prezentować je również w sposób wielowymiarowy, przyjazny dla użytkownika. Ideę przetwarzania wielowymiarowego wyjaśnia Rys. 3.

Dane z różnorodnych systemów transakcyjnych są ładowane do wielowymiarowej bazy danych (MDDB) w sposób wsadowy, a następnie również wsadowo są obliczane i zapamiętywane pewne dane zagregowane, które również są zapisywane w MDDB.

Po zakończeniu tego procesu system wielowymiarowej bazy danych jest gotowy do użycia.

W systemie MDDB wyróżniamy dwie warstwy:

• warstwę bazy danych

• warstwę aplikacji

Rysunek 3: Warstwowa architektura systemów MOLAP

Warstwa aplikacji otrzymuje żądania wyszukania danych od użytkowników, przeszukuje dane zapisane w bazie i przekazuje je do warstwy prezentacji zintegrowanej z oprogramowaniem użytkownika.

Trzecia warstwa, to warstwa prezentacji wyników przetwarzania.

Zazwyczaj uważa się, że systemy MOLAP są dwuwarstwowe, gdyż warstwy bazy danych i aplikacji rezydujące na serwerze MDDB i wykorzystujące tę samą architekturę są traktowane jako jedna, a warstwa prezentacji rezydująca zwykle na stacji klienta jako druga.

Architektura MOLAP posiada zwykle ograniczone możliwości dynamicznego obliczania danych zagregowanych. Korzysta raczej z obliczonych wcześniej, prekompilowanych i zapamiętanych w bazie MDDB wartości.

Wielowymiarowa analiza z relacyjną bazą danych (ROLAP)

W systemach ROLAP wielowymiarowe interaktywne analityczne przetwarzanie danych jest realizowane w oparciu o dane przechowywane w bazie relacyjnej nazywanej "Data Warehouse". Idea takiego przetwarzania jest pokazana na Rys. 4.

Dane są w sposób wsadowy importowane z baz transakcyjnych do hurtowni danych, następnie są uruchamiane odpowiednie procedury obliczania danych zagregowanych (jeśli jest to wymagane w przyjętym modelu danych) oraz tworzenia indeksów.

Użytkownicy końcowi zlecają wykonanie analiz wielowymiarowych motorowi ROLAP, który w sposób dynamiczny transformuje żądania na komendy SQL'a do relacyjnej bazy "Data Warehouse". Wyniki przeszukiwania danych są transformowane do formatów wielowymiarowych akceptowanych przez narzędzia prezentacji danych i przekazywane użytkownikowi.

Obydwie architektury systemów

Rysunek 4: Warstwowa architektura systemów ROLAP.

OLAP charakteryzują się tym, że:

• wspomagają analizę danych

• są skalowalne w zakresie liczby wymiarów

• są przygotowane do zarządzania dużą liczbą danych.

Różnica dotyczy sposobu przygotowania danych wyjściowych (zagregowanych, miar danych - metrics). I tak:

1. W przypadku architektury MOLAP dane zagregowane są wstępnie obliczane i przechowywane w bazie. Baza jest tak skonstruowana by ułatwić prezentację danych przez wybór odpowiedniego przekroju przestrzeni danych.

2. W przypadku architektury ROLAP dane zagregowane są zarówno wyszukiwane w bazie jak i obliczane na żądanie. Baza jest tak skonstruowana by ułatwić wyszukiwanie i obliczanie danych do prezentacji.

Środowisko DSS a transakcyjne bazy danych OLTP.

Należy wyraźnie powiedzieć, że każda akcja dostępu do danych, którą można wykonać na danych w architekturze wielowymiarowej (MOLAP lub ROLAP), jest także możliwa w bazach transakcyjnych o strukturze relacyjnej (OLTP). Jednak przetwarzanie wielowymiarowe oferuje szereg udogodnień:

Prostsze jest prezentowanie danych z bazy wielowymiarowej (MOLAP lub ROLAP) i nawigowanie w bazie, ponieważ oczekiwana przez użytkowników prezentacja danych w postaci tabel lub wykresów (w układzie osi X, Y) jest bardziej naturalna i nie wymaga pisania przez użytkownika złożonych zapytań SQL.

Prostsze jest zarządzanie bazą wielowymiarową MOLAP, ponieważ dane są przechowywane w postaci zbliżonej do tej w jakiej będą prezentowane.

Uzyskuje się znacznie lepszą wydajność - zwykle o rząd wyższą niż w bazach OLTP - dla poprawienia efektywności baza OLTP wymaga indeksowania, ale nie można indeksować wszystkich zmiennych. Jeśli lista pytań użytkownika jest z góry znana, to jest to możliwe, ale gdy użytkownik ma formułować własne zapytania, efektywność dostępu do baz OLTP znacznie spada.

Zalecane jest rozdzielenie środowiska DSS od środowiska bieżącej transakcyjnej obsługi przedsiębiorstwa (baz OLTP). Wynika to z różnicy obciążeń systemów transakcyjnych i analitycznych.

W typowym systemie OLTP wykorzystanie procesora i zasobów jest zwykle ustabilizowane i wykazuje niewielkie odchylenia od średniej.

Natomiast system DSS charakteryzuje się okresami przestojów i niewielkich obciążeń oraz stosunkowo krótkimi okresami dużego obciążenia związanymi z intensywnym przetwarzaniem lub wyszukiwaniem danych.

Nałożenie się tych dwóch charakterystyk może doprowadzić do przeciążenia systemu i wystawić cierpliwość użytkowników na poważną próbę.

Dlatego zwykle praktykuje się posadowienie systemów baz danych transakcyjnych i hurtowni danych w różnych środowiskach (rozdzielenie systemów, serwerów) i okresowe przenoszenie danych. Istotne różnice między systemami relacyjnymi i systemami DSS ilustruje tabela.

Charakterystyka	System transakcyjny z relacyjną bazą danych OLTP	System DSS z relacyjną bazą danych ROLAP	System DSS z wielowymiarową bazą danych MOLAP
Typowe odwołania	Aktualizacja, odczyt, prosty raport	Raport, Analiza	Raport, Analiza
Poziom analizy	Niski	Wysoki	Wysoki
Ekrany	Niezmienne	Definiowane przez użytkownika	Definiowane przez użytkownika
Liczba danych na transakcję	Mała	Zmienna	Bardzo duża
Złożoność danych	Proste, szczegółowe	Szczegółowe, sumaryczne i analityczne	Sumaryczne i analityczne
Rodzaj danych	Bieżące	Historyczne i bieżące	Przwidywane
Orientacja danych	Rekordy danych	Rekordy i tablice danych	Tablice danych

Tabela 1. Transakcyjne bazy danych i hurtownie danych - porównanie własności.

Podsumowanie

Przedstawiona powyżej ogólna prezentacja problematyki środowiska DSS pozwala sformułować następujące pytania szczegółowe:

1 Jaką architekturę hurtowni danych stosować?

2 Jak modelować dane dla hurtowni danych?

3 Kiedy stosować analizę danych MOLAP a kiedy ROLAP?

4 Jak zapewnić prawidłową ekstrakcję danych z baz transakcyjnych do hurtowni danych?

5 W jaki sposób porównywać i wybierać dostępne środowiska Data Warehouse i narzędzia OLAP?

6 Jak projektować, realizować i wdrażać systemy DSS w przedsiębiorstwach?

Modelowanie danych

Projekt systemu - model danych

U podstaw implementacji dobrego systemu DSS leży dobry projekt modelu danych. Projekt ten powinien umożliwiać prostą realizację takich cech systemu DSS jak:

• efektywne wspomaganie podejmowania decyzji,

• duża szybkość uzyskiwania wyników zapytań,

• bezpieczeństwo systemu i łatwość jego użytkowania.

Jako mierniki dobrego projektu danych można przyjąć:

• efektywność wydajności modelu danych,

• prostotę i uniwersalność zastosowanego modelu danych,

• efektywność składowania informacji w modelu danych.

Podstawowym sposobem przetwarzania danych w systemach DSS jest analiza wielowymiarowa. Analizę tę można prowadzić w oparciu o dwa modele baz danych: wielowymiarowy lub relacyjny.

Baza wielowymiarowa to matematycznie macierz 2, 3, ... n - wymiarowa.

Macierz 2 i 3 - wymiarowa posiadają interpretację geometryczną odpowiednio w postaci płaskiej tablicy lub przestrzennej kostki. W przypadku większej liczby wymiarów interpretacją geometryczną jest zbiór tablic lub zbiór kostek.

Prezentacja danych zapisanych w modelu wielowymiarowym polega na wybraniu odpowiedniego widoku danych, czyli odpowiedniej podprzestrzeni, tabeli, kolumny lub wiersza danych z całej struktury wielowymiarowej i jej wyświetlenie na ekranie monitora w wymaganej postaci graficznej lub tabelarycznej.

Idea prezentacji danych wielowymiarowych jest więc bardzo prosta i intuicyjna.

Stosowane są dwa technologicznie różne podejścia do realizacji wielowymiarowej analizy danych i systemów DSS.

Model pierwszy - zakłada stosowanie wielowymiarowej (macierzowej) bazy danych i takich języków zapytań, by w sposób możliwie prosty uzyskać dostęp do danych i ich prezentację - jest to model MOLAP (Multidimensional OLAP);

Model drugi - zakłada taką modyfikację struktury relacyjnej danych, by za pomocą zapytań SQL otrzymać równoważny sposób prezentacji danych - jest to model ROLAP.

W chwili obecnej istnieje szereg komercyjnych systemów OLAP wspomagających tworzenie systemów DSS.

Modelowanie danych MOLAP zostało szeroko opisane i spopularyzowane w literaturze. Technologia ta posiada jednak szereg ograniczeń pojemności baz danych i wydajności przetwarzania.

Technologia ROLAP zapewnia ten sam efekt bez tych ograniczeń

Na technologii ROLAP skupia się dalsza część materiału.

Model danych oparty o ERD

W oparciu o model ERD działającego systemu transakcyjnego trudno jest zbudować efektywny system DSS. Systemy transakcyjne zoptymalizowane są pod kątem szybkości modyfikacji danych, a nie pod kątem wymagań systemów wspomagania decyzji.

Modele danych powstałe w oparciu o ERD posiadają następujące cechy:

• występowanie dużej ilości obiektów (encji, zwłaszcza dla schematów w 3NP),

• występowanie dużej ilości powiązań między obiektami,

• jednorodność modelu - wizualny brak obiektu(-ów) wyróżnionego (najważniejszego) i największego.

Cechy te wynikają z faktu, że zazwyczaj schemat systemu transakcyjnego stara się objąć (lub wystarczająco dobrze przybliżyć) całą złożoność procesów zachodzących w świecie rzeczywistym.

Występowanie przytoczonych cech implikuje, że:

modele ERD są skomplikowane - występuje w nich duża ilość obiektów i połączeń między nimi, co powoduje:

• trudności w rozumowym objęciu całości schematu przez końcowego użytkownika,

• trudności w definicji kryteriów zapytania i wartości, o które chcemy pytać,

• modele ERD są mało wydajne w dostępie do danych - ze względu na występowanie w modelu dużej liczby połączeń:

• w generowanych zapytaniach występuje duża ilość złączeń,

• może istnieć wiele możliwości realizacji zapytania (według różnych połączeń), co utrudnia pracę optymalizatora,

• modele ERD mogą mało efektywnie przechowywać dane, co ma szczególne znaczenie w przypadku projektowania systemów operujących na bardzo dużych ilościach informacji,

• każdy model ERD posiada cechy unikalności i dlatego też trudno napisać uniwersalne narzędzia projektowe do tworzenia systemów DSS, które współpracowałby z każdym modelem ERD.

Uproszczenie modelu ERD polegające na odrzuceniu obiektów nadmiarowych nie prowadzi do schematu dobrego pod względem wydajności, efektywności przechowywania danych ani prostoty przetwarzania.

Model danych w schemacie gwiazdy

W odróżnieniu od systemów OLTP, które starają się objąć grupę procesów, podstawowe składniki systemu OLAP koncentrują się na pojedynczym procesie, którego przetwarzanie (analiza) ma być maksymalnie efektywne. Podstawowym modelem realizującym ten postulat jest model zwany gwiazdą (ang. star). Struktura ta zawiera:

• tabelę(e) faktów (ang. base table),

• tabele wymiarów (ang. lookup tables).

Cechami charakterystycznymi tej struktury są (rys. 2):

• model nie jest jednorodny - posiada wyraźne centrum - tabelę bazową,

• na schemacie występuje minimalna liczba połączeń,

• tabele wymiarów nie są znormalizowane.

Zastosowanie modelu gwiazdy w implementacji systemu DSS ma wiele zalet:

• model jest bardzo prosty i czytelny (niewielka liczba obiektów oraz minimalna liczba połączeń): użytkownik wie, jaka jest dziedzina systemu (wymiary) i co on przechowuje (fakty),

• zoptymalizowany jest dostęp do danych: w zapytaniach pojawia się niewielka liczba złączeń, istnieje prosty algorytm wyznaczania wynikowego zbioru rozwiązań (przetworzenie wymiarów, a następnie tablicy faktów) oraz specjalne techniki optymalizacji zapytań,

• bardzo efektywna metoda przechowywania danych: wraz z faktami przechowywane są tylko identyfikatory pochodzące z tabel wymiarów. Identyfikatory są liczbami całkowitymi, które łatwo się wyszukuje, które są pojemne (1-bajtowa liczba całkowita potrafi przechować 256 wartości, podczas gdy 1 bajtowa liczba binarna - 2 wartości, 1-bajtowy ciąg znakowy złożony z liter i cyfr - ok. 60 wartości) i co się z tym wiąże zajmują bardzo mało miejsca,

• model gwiazdy jest bardzo uniwersalny - w każdym modelu da się wyróżnić tabelę bazową z faktami oraz tabele wymiarów, stąd łatwo jest zbudować uniwersalną aplikację do projektowania systemów DSS mogącą pracować z dowolnym modelem hurtowni przypominającym strukturę gwiazdy.

Model danych w schemacie płatka śniegu

Rysunek: Hurtownia danych w schemacie płatka śniegu.

Za pewną wadę modelu gwiazdy można uważać brak normalizacji tabel wymiarów. Znormalizowany schemat gwiazdy przybiera postać schematu płatka śniegu (ang. snowflake) lub też rozwiniętej gwiazdy (ang. extended star) - rys.3. Normalizacja niesie ze sobą szereg zalet:

• uzyskanie eleganckiej struktury jawnie ukazującej rzeczywistą, hierarchiczną strukturę wymiarów, np. wymiaru czasu (rok-półrocze-kwartał-miesiąc-tydzień-dzień), położenia geograficznego, struktury przedsiębiorstwa, asortymenty produktów (podział wg klas, podklas, rodzajów),

• zmniejszenie objętości bazy danych poprzez eliminację powtórzeń wartości atrybutów wymiarów,

• uproszczenie niektórych zadań administracyjnych: tabele mają prostszą strukturę, łatwiej się je wypełnia i w prostszy sposób można sprawdzić jakości informacji zawartej w tabeli.

Przeciw normalizacji modelu hurtowni przemawiają następujące fakty:

• normalizacja może wywołać pewne problemy efektywnościowe, których nie ma w modelu zdenormalizowanym - generalnie w planie wykonania zapytania pojawia się większa ilość złączeń,

• normalizacja zakłóca maksymalną prostotę modelu gwarantowaną przez występowanie w nim minimalnej liczby obiektów i połączeń,

• fakt zmniejszenia objętości bazy danych w przypadku modelu znormalizowanego jest bardzo niewielki. Przy tabelach faktów wielkości gigabajtów oszczędności miejsca sięgają zwykle ułamków procenta,

• pojawienie się większej ilości tabel w modelu płatka śniegu rozszerza zakres obowiązków administratora.

Przy porównaniu modeli gwiazdy i płatka śniegu należy dokładnie rozważyć wszelkie złożone aspekty związane z szybkością wykonywania zapytań i zarządzaniem strukturą hurtowni

Szybkość wykonywania zapytań w modelu gwiazdy i płatka śniegu

Przyjęty model hurtowni danych musi zapewnić odpowiednią szybkość przetwarzania kierowanych doń zapytań. Szybkość przetwarzania zapytań zależy - biorąc pod uwagę oprogramowanie - m.in. od:

• rodzaju pytań kierowanych do hurtowni i ich optymalizacji,

• indeksacji danych,

• agregacji,

• możliwości wykorzystania wyników zapytań zadanych w przeszłości (np. przechowywanych w pamięci podręcznej),.

Spośród wymienionych punktów tylko możliwość wykorzystania istniejących wyników nie zależy od rodzaju modelu danych. Konstrukcja pytań kierowanych do hurtowni, indeksacja danych oraz sposób agregacji zależne są od wybranego modelu.

Konstrukcja pytań kierowanych do hurtowni

Generalnie aplikacje systemów DSS generują dwa rodzaje zapytań:

• pytania o atrybuty dostępne w wymiarze,

• pytania o fakty.

Pytania o atrybuty wymiaru

Pytania o atrybuty wymiaru związane są z wyborem kryteriów ograniczeń, które chcemy nałożyć na przetwarzane dane. Pytania te stanowią ważny etap wstępny poprzedzający pytanie o fakty. Duża waga przywiązywana do szybkości wykonania tych zapytań wynika z konieczności zachowania ciągłości procesu interakcji aplikacji DSS z użytkownikiem. Szczególnie ważne jest szybkie wyświetlenie atrybutów przyjmujących tylko kilka wartości, nawet przy dużych ilościach rekordów w wymiarze.

Pytania o atrybuty stanowią około 80% wszystkich pytań kierowanych do hurtowni. Można wyróżnić trzy typy zapytań o atrybuty:

1. pytania dotyczące tylko jednego atrybutu,

2. pytania dotyczące tylko jednego wymiaru,

3. pytania dotyczące wielu wymiarów.

Pierwsze z pytań jest najprostszym pytaniem występującym we wszystkich systemach DSS. Pytanie to pojawia się przy specyfikacji przez użytkownika pierwszego kryterium wyszukiwania. Kolejne kryteria mogą być podawane na dwa sposoby:

• bez uwzględnienia poprzednich ograniczeń - kryterium specyfikuje się na podstawie wszystkich dostępnych wartości atrybutu w wymiarze,

• z uwzględnieniem poprzednich kryteriów, które ograniczają możliwość wyboru tylko do wartości atrybutów, które występują w powiązaniu z wartościami poprzednio już wskazanymi.

Pierwsze podejście może prowadzić do uzyskania pustego wyniku zapytania - użytkownik może dokonać wyboru kryteriów, których nie spełnia żaden fakt. Druga technika gwarantuje otrzymanie jakiegoś wyniku - przynajmniej tych faktów, na podstawie których zdefiniowano ograniczenia. Pierwsza technika jest bardzo wydajna - wymaga tylko wykonania polecenia select bez frazy warunków (where). Druga z nich prowadzi do złożonych zapytań ze złączeniami w ramach wymiaru (pytanie typu 2) lub wielu wymiarów (pytanie typu 3).

Pytanie typu 3 wymaga przejścia przez tablicę faktów - jego wykonanie jest z reguły bardzo czasochłonne i w praktyce nie korzysta się z tego typu zapytań.

Składnia poleceń SQL

Pytanie typu 1 o atrybuty

Gwiazda:

select distinct atr from wymiar

Płatek śniegu:

select atr from wymiar

Pytanie typu 2 o atrybuty z uwzględnieniem poprzednich wyborów (atr1):

Gwiazda:

select distinct atr2 from wymiar where atr1=...

Płatek śniegu: atrybuty w jednej tabeli:

select atr2 from wymiar where atr1=...

lub, gdy atrybuty w różnych tabelach wymiaru:

select w2.atr2 from wymiar w1, podwymiar w2

where w1.id=w2.id and w1.atr1=...

lub, gdy atrybuty w różnych tabelach

wymiaru i w różnych hierarchiach:

select w2.atr2 from wymiar w1, podwymiar w11, podwymiar w12

where w1.id_w11=w11.id and w1.id_w12=w12.id and w11.atr1=...

Pytanie typu 3 o atrybuty z uwzględnieniem poprzednich wyborów (atr1):

Gwiazda:

select distinct w2.atr2 from fakty f, wymiar w1, wymiar w2

where f.id_w1=w1.id and f.id_w2=w2.id and w1.atr1=...

Płatek śniegu:

select w2.atr2 from fakty f, wymiar w1, wymiar w2

where f.id_w1=w1.id and f.id_w2=w2.id and w1.atr1=...

Wnioski:

1. Schemat płatka śniegu pozwala na bardzo szybką realizację podstawowych zapytań o atrybuty (typ 1) poprzez wykonanie polecenia select bez modyfikatora distinct. Schemat gwiazdy wymaga zastosowania bardziej złożonego w wykonaniu polecenia select distinct. Inna składnia poleceń może mieć znaczenie w przypadku bardzo dużych wymiarów (wymiarów zawierających wiele atrybutów).

2. W przypadku płatka śniegu, koszt pytań o atrybuty jednego wymiaru, które nie należą do tej samej hierarchii w wymiarze może być bardzo duży. Konieczne może okazać się wykonanie operacji złączenia, która będzie czasochłonna jeżeli będzie dotyczyła dużych wymiarów. Denormalizacja modelu gwiazdy powoduje, że nie wymaga on takich złączeń.

Pytania o fakty

Po specyfikacji wszystkich warunków (dodatkowo warunki narzucone na atrybuty wymiarów można uzupełnić warunkami dotyczącymi samych faktów) następuje wykonanie pytania o fakty spełniające narzucone kryteria. Pytania te są zazwyczaj wykonywane o wiele dłużej niż poprzedzające je pytania o atrybuty. To one przetwarzają zawartość hurtowni danych i służą do generacji raportu. Użytkownicy systemu DSS, świadomi złożoności procesu obliczeniowego nie oczekują natychmiastowego wygenerowania rezultatów. Nie zwalnia to jednak programistów od optymalnego zaprojektowania i zaplanowania wykonania takiego zapytania - każde pytanie powinno być realizowalne w rozsądnym czasie. Pytania o fakty stanowią około 20% wszystkich pytań kierowanych do hurtowni.

Mając w pamięci modele struktury gwiazdy i płatka śniegu można stwierdzić, że różnice, które mogą pojawić się przy generacji zapytania o fakty dla tych dwóch struktur, będą związane z pojawieniem się większej ilości tabel we frazie from i większej ilości warunków złączeń we frazie where zapytania kierowanego do płatka śniegu. Występowanie większej ilości tabel powoduje, że optymalizator musi wykonać więcej obliczeń, a samo wykonanie zapytania będzie wymagało realizacji większej ilości złączeń.

Zazwyczaj wybrany przez optymalizator schemat wykonania zapytania ma przebieg:

1. wyznaczenie zbioru warunków na podstawie kryteriów podanych we frazie where,

2. wyznaczenie zbioru wyników na podstawie wyznaczonych warunków,

3. przeprowadzenie dodatkowych operacji na wynikach (np. agregacja, sortowanie).

Podsumowanie

Tworzenie systemów hurtowni danych jest procesem bardzo złożonym. U podstaw tego procesu należy powziąć decyzję dotyczącą ogólnego modelu danych. Kandydatami są dwa modele szczególnie dedykowane dla systemów wspomagania decyzji: model gwiazdy oraz model płatka śniegu. Modele wywodzące się z systemów transakcyjnych, ze względu na swoje skomplikowanie oraz problemy wydajnościowe, nie nadają do tego typu zastosowań.

W dobrym systemie DSS najważniejsza jest szybkość uzyskiwania wysokiej jakości informacji. W przypadku hurtowni danych, których tabele wymiarów nie zawierają dużej ilości atrybutów, wydajność systemów opartych o modele gwiazdy i płatka śniegu nie odbiega od siebie.

Wraz ze wzrostem ilości atrybutów w tablicach wymiarów, model gwiazdy okazuje się być lepszy od modelu płatka śniegu pod względem wydajności, zaczyna mu natomiast ustępować pod względem ilości wykorzystywanej przestrzeni dyskowej. Wspominając jednak wagę aspektu wydajności systemu, można mówić o lepszej pozycji modelu gwiazdy. Atrakcyjność modelu gwiazdy zwiększają dodatkowo możliwość bardzo efektywnego wykorzystania indeksów bitmapowych oraz związana z tym optymalizacja planu wykonywania zapytań przez ich transformację.

Z drugiej strony model płatka śniegu wydaje się być bardzo elegancki. Normalizacja modelu pozwala na uzyskanie większej ilość prostszych tabel oraz upraszcza implementację modelu agregacji, co w rezultacie ułatwia zadania administratora systemu.

Dokonując wyboru między dwoma modelami należy rozważyć też model mieszany. Model taki, zakładający normalizację tylko części tablic schematu, potrafi połączyć w sobie najlepsze cechy modeli gwiazdy i płatka śniegu.

---