01. Kiedy zachodzi potrzeba budowy hurtowni danych?

Kiedy zachodzi potrzeba budowy hurtowni danych? 

   W pewnym momencie ilość informacji zebranych w bazie danych oraz stopień skomplikowania powiązań danych zgromadzonych w tabelach, uniemożliwiają swobodne raportowanie. Co za tym idzie analizowanie stanu przedsiębiorstwa staje się utrudnione. Architekci baz danych zaczęli szukać sposobu na zapewnienie zarówno sprawnego działania aplikacji mających na celu wsparcie działań operacyjnych (np. obsługa magazynu, faktur, wpłat, …) jak i zapewnienie sprawnej analizy zgromadzonych danych mającej na celu analizowanie stanu przedsiębiorstwa.

Zaproponowane rozwiązanie poległo na oddzieleniu danych operacyjnych (Online Transaction Processing - OLTP) od danych analitycznych (Online Analytical Processing - OLAP).

Czym jest OLAP?

Architektura charakteryzująca się podziałem na dwa typy tabel: tabele wymiarów oraz tabele faktów. Podział taki ma swoje uzasadnienie nie tylko od strony technicznej o której więcej za chwile, ale również biznesowej. Użytkownicy szczebla kierowniczego aby podejmować trafne decyzje związane z prowadzeniem przedsiębiorstwa potrzebują jasnych informacji o aktualnej sytuacji firmy. Aby takie informacje były wygodne w interpretacji najlepiej żeby można było je zmierzyć. I stąd pomysł na tabelę faktów zawierającą miary, czyli wartości które są mierzone: dodawane, uśredniane, itp.  Przykładowymi miarami w tabeli faktów mogą być: wartość towarów dla danej faktury w tabeli faktur, ilość danego towaru na magazynie w tabeli stanu magazynu, kwota podpisanej umowy w tabeli umów, i tym podobne. Aby jednoznacznie zidentyfikować okoliczności wystąpienia danego faktu należy skorzystać z informacji zawartych w połączonych z nim wymiarach. Przykładowe tabele wymiarów mogą opisywać: obszar administracyjny (w postaci hierarchii: województwo, powiat, miejscowość), czas (również najczęściej w postaci hierarchii: rok,  kwartał, miesiąc dzień), czy produkty w postaci nie hierarchicznej z nazwą i innymi atrybutami.

Podział na tabele faktów i odpowiednio zaprojektowane tabele wymiarów ma swoje uzasadnienie również od strony technicznej. Zapytania wykonywane przez raport na źródle o takiej architekturze są maksymalnie uproszczone (szczególnie w architekturze gwiazdy o czym informacji będzie można znaleźć w kolejnej części), ponieważ do minimum zostaje ograniczona liczba złączeń pomiędzy tabelami. Ponad to w wymiarach najczęściej przedstawia się dane w formie takiej jaka powinna wystąpić w parametrach wywołania raportów. Należy zauważyć że parametr taki może odpowiadać skomplikowanemu zapytaniu na analogicznych danych OLTP.

Dodatkowo wiele systemów bazodanowych posiada specjalne mechanizmy wspierające architektury OLAP. 

Poniższa tabla zawiera porównanie struktur OLTP i OLAP.

	OLTP	OLAP
Zastosowanie	Operacyjna baza danych - obsługa bieżących procesów biznesowych związanych z funkcjonalnościami jakie oferuje aplikacja (np. obsługa magazynu, faktur, wpłat, …)	Systemy analityczne - obsługa systemów wspierających podejmowanie strategicznych decyzji dotyczących przedsiębiorstw.
Normalizacja struktury bazy danych	Najczęściej trzecia postać normalna 3F	W zależności od architektury wymiarów, najczęściej w postaci zdenormalizowanej 2F
Operacje zapisu	Podczas pracy operacyjnej aplikacji	Podczas przetwarzania ETL (najczęściej nocnego)
Operacje odczytu	Podczas pracy operacyjnej aplikacji oraz podczas przetwarzania ETL (najczęściej nocnego)	Podczas korzystania z raportów
Operacje aktualizacji	Podczas pracy operacyjnej aplikacji	Unikane
Bezpieczeństwo danych	Zalecane jest robienie kopii bezpieczeństwa danych	Alternatywą dla kopii bezpieczeństwa jest ponowne załadowanie danych na podstawie źródeł OLTP

Pozostałe korzyści z zastosowania hurtowni danych:

• Optymalizacja dobowego obciążenia serwerów bazy danych

Wyobraźmy sobie sytuację w której dzienne obciążenie bazy danych przedsiębiorstwa ilustruje poniższy wykres:

Widać na nim że baza danych w czasie szczytu pracy użytkowników systemu jest niewystarczająco wydajna. Załóżmy że obsługuje ona zarówno procesy operacyjne (takie jak: obsługa magazynów, fakturowanie, itp.), ale również analityczne (czyli szeroko rozumowane raportowanie).
Zastosowanie hurtowni danych sprawi że obciążenie będzie mogło przyjąć postać jak na wykresach poniżej.

Widać że:

1. po pierwsze obciążenie rozłożyło się na dwie fizyczne instancje: bazy danych oraz hurtowni danych. Tradycyjna baza danych służy celom operacyjnym a hurtownia danych celom analitycznym. 
2. nocne przetwarzanie za pomocą narzędzi ETL upraszcza strukturę danych które służą do analizy, ponieważ przekształca je z OLTP na OLAP. Co za tym idzie kosztem nocnego obciążenia bazy danych, w dzień można korzystać z prostszych z punktu widzenia analizy zapytań.

• Przechowywanie danych historycznych

Jednym z podstawowych założeń hurtowni danych jest nieulotność danych. Jednak aplikacje oparte o architekturę OLTP rzadko przechowują wartości historyczne. Wiąże się to z wieloma niedogodnościami. Na przykład, kiedy zmienia się atrybut słownikowy (ma miejsce fizyczny update), z punktu widzenia bazy operacyjnej tracimy informacje o poprzedniej wartości i zastępujemy ją aktualną. Ponieważ hurtownie danych posiadają mechanizmy zapewniające obsługę danych historycznych (takie jak slowly changing dimension (SCD)), istnieje możliwość podglądu również historycznych - updateowanych danych. Ponad to, aby zapewnić wysoką wydajność działania zapytań OLTP (bardziej skomplikowanych w stosunku do OLAP), często stosuje się mechanizmy archiwizacji danych historycznych. Wiąże się to z niedostępnością danych archiwalnych w procesie analizy. Hurtownie danych z założenia przechowują wszystkie dane historyczne, pozwalając na analizowanie nawet odległych czasowo zdarzeń.

•  Przechowywanie tak zwanej 'jednej wersji prawdy' 

Często te same dane przechowywane są w różnych miejscach, w różnej postaci. Można sobie wyobrazić sytuacje w której dane o klientach znajdują się w aplikacji stworzonej specjalnie dla działu marketingu. Podobny zbiór informacji o klientach znajdować będzie w dziale sprzedaży, który korzysta z oprogramowania stworzonego przez innego dostawce. W tym momencie dane o klientach z punktu widzenia analityka, przechowywane są w dwóch nie spójnych zbiorach w różnych formatach. Zbiory te można zastąpić pojedynczym spójnym zbiorem, najczęściej w postaci wymiaru hurtowni danych. Rozsądnym podejściem jest odnalezienie unikalnego elementu wspólnego (w przykładzie z klientami może to być numer NIP lub PESEL) i umieszczenie go jako klucz źródła danych w atrybutach wymiaru.