Celem IT jest wspomaganie pracowników w ich codziennej pracy oraz pomaganie osobom podejmującym strategiczne decyzje (np. kierownikom, analitykom) w podejmowaniu szybszych i skuteczniejszych działań. I tak jak do realizacji pierwszego z tych celów w zupełności wystarczą systemy przetwarzania transakcyjnego, które, gromadząc informacje o bieżących działaniach firmy, znakomicie usprawniają codzienne funkcjonowanie przedsiębiorstwa, tak do realizacji drugiego z wymienionych zadań potrzebne są systemy, których główną siłą jest informacja historyczna – systemy wspomagania decyzji.

Lekarstwem na tę bolączkę jest właśnie hurtownia danych, pozwalająca na:

• Zebranie w jednym miejscu informacji rozproszonej po różnych firmowych systemach w celu umożliwienia zadawania zapytań wspomagających podejmowanie decyzji
• Oddzielenie systemów wspomagania decyzji od systemów transakcyjnych

Stworzenie hurtowni danych jest przedsięwzięciem po pierwsze niełatwym, po drugie wysoce kosztownym. Toteż rozpoczynając je powinniśmy dokładnie określić cel, do którego dążymy, aby na koniec móc stwierdzić, czy cel ten osiągnęliśmy. Warto pamiętać, że hurtownię danych budujemy dla firmy i że sukces odnosimy wówczas, gdy firma osiągnie cel, który miała na uwadze, decydując się na budowę hurtowni danych. Toteż jako projektanci hurtowni musimy dążyć do tego, aby kierownictwo firmy owe cele biznesowe sformułowało. Właściwie sformułowany cel biznesowy powinien być: mierzalny, ograniczony czasowo oraz zorientowany na klienta. Przykładowym celem biznesowym może być pozyskanie w bieżącym roku o 20% więcej dobrych klientów niż w zeszłym roku bądź też zwiększenie w bieżącym roku sprzedaży o 30% w stosunku do sprzedaży z zeszłego roku.

Hurtownia danych w znacznym stopniu ułatwia tzw. zarządzanie kontaktami z klientami (CMR, ang. Customer Relationship Management)

Rozumiemy przez to przede wszystkim lepsze poznanie klientów oraz odpowiednie kontaktowanie się z klientami.

Hurtownia danych w znacznym stopniu przyczynia się do usprawnienia tego, co składa się na CRM, czyli:

• uchwycenia skali i opisania przyczyn odejść klientów
• poznawania klientów
• dokonania segmentacji rynku
• zarządzania kampaniami marketingowymi
• personalizacji klientów
• kontaktów z klientami

Systemy wspomagania decyzji ( DSS, ang. Decision Support Systems ) można scharakteryzować następująco:

Pytania operacyjne dotyczą tu i teraz:

• Ile pozostało niezrealizowanych zamówień?
• Których produktów nie ma w magazynie?
• Jaki jest stan konkretnego zamówienia?
• Ilu klientów mamy obecnie?
• Jakie było ostatnie zamówienie klienta X.

Pytania strategiczne poza tu i teraz znacznie wykraczają:

• Popularność jakich linii produktów wzrosła, a jakich zmalała?
• Jaki linie produktów są sezonowe?
• Którzy klienci składają regularnie takie same zamówienia?
• Czy niektóre produkty są bardziej popularne w różnych częściach kraju?
• Czy klienci maja tendencje
  do nabywania szczególnej kategorii produktów?

Te różnice w znacznym stopniu przyczyniły się do rozdzielenia tych dwóch typów informacji.

• OLTP - On-line Transaction Processing - bezpośrednie przetwarzanie transakcyjne, którego głównym celem jest niezawodne i skuteczne przetwarzanie dużej liczby transakcji oraz zapewnienie spójności danych. Opisuje przetwarzanie w operacyjnej (transakcyjnej) bazie danych
• OLAP - On-Line Analytical Processing - bezpośrednie przetwarzanie analityczne, którego głównym celem jest skuteczne wielowymiarowe przetwarzanie ogromnych ilości danych. Opisuje przetwarzanie w hurtowni danych.

Między tymi dwoma modelami przetwarzania występuje sporo różnic, począwszy od grup użytkowników korzystających z tych systemów, poprzez funkcjonalność, projekt bazy danych, rodzaj trzymanych danych, użycie, dostęp, wykonywane zadania, liczbę rekordów zwracanych w zapytaniach, liczbę korzystających z systemu użytkowników, a skończywszy na rozmiarze docelowej bazy danych.

• zorientowana na temat (subject orinted)
• nieulotna (nonvolatile)
• zintegrowana (integrated)
• zróżnicowana czasowo (time variant)

Zorientowanie na temat oznacza, że zbierane dane dotyczą tematu (np. sprzedaży) , a nie działań (np. zbierania zamówień).

Nieulotność oznacza, że dane, raz umieszczone w hurtowni, zazwyczaj pozostają nie zmienione. Każdy użytkownik bazy danych ma pewność, że zapytanie zawsze zwróci taki sam wynik, niezależnie od tego jak często jest wykonywane.

Zintegrowanie oznacza, że dane są jednolite, czyli na przykład daty przechowywane są zawsze w tym samym formacie, znaki kodowane są w ten sam sposób, pola zawierające tę samą informację mają tę samą postać

Hurtownię danych powinno oddzielać się od innych aplikacji z wielu powodów. Po pierwsze hurtownia danych jest zorientowana na temat, podczas gdy operacyjne bazy danych zorientowane są na działanie. I tak jak w hurtowni koncentrujemy się wokół sprzedaży (temat), tak w operacyjnych bazach danych koncentrujemy się wokół składania i realizacji zamówień (działanie). Po drugie, podczas gdy dane w hurtowni danych muszą być nieulotne, w operacyjnej bazie danych podlegają one nieustannym zmianom. Po trzecie istotą i siłą hurtowni danych jest informacja historyczna (zróżnicowanie czasowe), natomiast w operacyjnej bazie danych informacje historyczne stanowią, często niepotrzebne, obciążenie wydajnościowe, a nawet zdarza się, że bywają mylące (na przykład poprzedni, nieaktualny już adres klienta), toteż bardzo często są z bazy usuwane. Po czwarte schemat operacyjnej bazy danych jest z reguły wysoce skomplikowany. Zdarza się, że od jednej do drugiej tabeli prowadzi wiele ścieżek łączących. W hurtowni danych stawia się na prostotę schematu, dopuszczając jedną ścieżkę złączeń.

Co do względów funkcjonalnych to wspomniana już konieczność gromadzenia danych historycznych, jak również konieczność konsolidacji danych pochodzących z różnorodnych źródeł oraz konieczność zintegrowania formatów i semantyki także przemawiają za oddzieleniem hurtowni od innych systemów.

Na poniższym rysunku w sposób schematyczny została przedstawiona architektura hurtowni danych. Oczywiście konkretne rozwiązania mogą się różnić od poniższego, ale ten schemat ma za zadanie przybliżyć ogólną ideę. Jak widzimy, do hurtowni danych dane pobierane są z zewnętrznych źródeł danych. Zanim dane znajdą się w hurtowni muszą zostać pobrane (ang. extract – ekstrakcja), poddane transformacji (ang. transform – transformacja, przekształcanie), czyli zwalidowane (ang. validation - walidacja), zintegrowane (ang. integration - integracja) i odwzorowane (ang. mapping – mapowanie, odwzorowanie), a w końcu załadowane do hurtowni (ang. load - ładowanie). Oczywiście poza ładowaniem początkowym, wykonywanym jednokrotnie na początku, dokonywane są ładowania przyrostowe w celu odświeżania hurtowni (ang. refresh - odświeżanie). Do ekstrakcji, transformacji i ładowania służy narzędzie ETL, które może być częścią hurtowni bądź też narzędziem zewnętrznym. Należy zdawać sobie sprawę z tego, że dane do hurtowni mogą być pobierane z wielu różnych źródeł (aplikacji transakcyjnych, plików itp.), przy czym nie ze wszystkich zastanych w firmie źródeł pobrać dane jest łatwo. To właśnie różnorodność źródeł, trudność dostępu do niektórych z nich, duża dezintegracja, czynią budowanie hurtowni danych zadaniem nietrywialnym i kosztownym.

Hurtowni danych towarzyszy mocno rozbudowane repozytorium metadanych, w którym znajdują się wszystkie informacje z poziomu pojęciowego (opis zawartości, opis procesu integracji pojęciowej itp.), logicznego (nazwy tabel i kolumn, typy danych, rodzaje związków między tabelami, definicje perspektyw zmaterializowanych, definicje więzów integralności, definicje kostek danych i hierarchii wymiarów, opis logiczny procesu ładowania danych itp.) i fizycznego (definicja fizycznego rozmieszczenia danych i ich przepływu, informacje o lokalizacji fragmentów danych składających się na logiczne źródło danych, definicje wyzwalaczy, definicje procedur przeprowadzających ładowanie, czyszczenie i transformację itp.), statystyki danych i użycia oraz informacje administracyjne (zasady dostępu do danych, definicje użytkowników i ich grup, terminy wykonywania cyklicznych czynności w hurtowni danych, jak aktualizacja ze źródeł, czy backup itp.)

Projekt hurtowni danych w zasadniczym stopniu różni się od projektu operacyjnej bazy danych. Diagram związków encji, na którym opiera się znakomita większość aplikacji transakcyjnych jest normalizowany w celu uniknięcia anomalii podczas wstawiania danych, ich usuwania i aktualizacji. W hurtowni danych naszym nadrzędnym celem nie jest unikanie tych anomalii (choćby dlatego, że dane są do niej ładowane, nie zaś wstawiane przez wielu użytkowników, a i to znacznie rzadziej), ale wydajne i skuteczne wykonywanie bardzo skomplikowanych, i zwracających nawet miliony rekordów, zapytań.

Można by rzec, że podstawowy schemat, na którym opiera się hurtownia danych, tak zwany schemat gwiazdy, jest próbą przedstawienia czwartego, piątego itd. wymiaru podczas dokonywania analizy wymiarowej. Hurtownię danych budujemy bowiem dla firmy, a jak się okazuje, tym czego potrzebuje firma jest właśnie możliwość dokonywania analiz wymiarowych. Weźmy bowiem standardowe zadanie stawiane w firmie:

Aby zobrazować wykonanie tego zadania wystarczy dwuwymiarowy układ z osią produktu i osią czasu:

Dla zobrazowania wykonania tego zadania wystarczy trzywymiarowy układ z osią produktu, osią klienta i osią czasu:

Dla zobrazowania wykonania tego zadania “wystarczy” czterowymiarowy układ z osią produktu, osią klienta, osią obszaru sprzedaży i osią czasu

Przed omówieniem tego schematu spójrzmy jeszcze na pełny schemat z załączonymi atrybutami:

Centrum schematu gwiazdy tworzy tak zwana tabela faktów, czyli tabela gromadząca informacje o temacie, wokół którego skupia się hurtownia. Faktów tych będzie dotyczyła większość zapytań zadawanych hurtowni danych. Tabela faktów jest znormalizowana, jej klucz główny (obszar zaznaczony kolorem żółtym) stanowią klucze obce pochodzące z tabel: Produkt, Obszar, Klient i Czas, zaś kolumny niekluczowe, czyli tak zwane miary muszą być sumowalne. Patrząc od strony biznesowej, w tabeli faktów gromadzone są informacje dotyczące tego, co firmie przynosi zysk. Często zatem jest to właśnie sprzedaż, rozmowy telefoniczne, transakcje bankowe itp. Miary to w pewnym sensie wyznacznik tego zysku, czyli liczba sprzedanych sztuk, cena, liczba wydzwonionych sekund/minut, kwota operacji bankowej itp.

Tabelę faktów otaczają tabele wymiarów, zawierające dane o wymiarach analizy, czyli o tym według czego będziemy analizowali dane z tabeli faktów, w naszym przypadku sprzedaż. Cechą charakterystyczną tabel wymiarów jest brak normalizacji. Na przykład w tabeli produkt znajdują się wszystkie potrzebne z punktu widzenia przyszłej analizy informacje o produkcie, łącznie z informacjami o kategorii produktu. Szczególnym wymiarem analizy jest wymiar Czasu. Jego wyjątkowość wynika z tego, że jest to wymiar występujący zawsze w hurtowni (czasem niejawnie), ponieważ każde zapytanie zadawane do hurtowni w jakiś sposób wiąże się z czasem. Niektóre systemy umożliwiają dodanie wymiaru czasu do kostki, nawet jeśli wymiar ten nie został jawnie zaprojektowany.

• produkt - kategoria
• data - miesiąc - kwartał - rok
• klient - miasto - kraj

W schemacie gwiazdy każda taka pojedyncza hierarchia zawiera się w jednej tabeli i tabela ta jest bezpośrednio przyłączana do tabeli faktów. Jest jednak możliwość (choć nie obsługiwana przez wszystkie serwery) częściowego znormalizowania wymiarów poprzez tworzenie hierarchii w wielu tabelach. Takim krokiem w kierunku normalizacji jest alternatywny schemat do hurtowni - schemat płatka śniegu.

Jak widzimy kategoria produktu (i wszystkie dotyczące jej atrybuty) stanowi tu oddzielną tabelę.

• jest łatwy do zrozumienia
• jest jednoznaczny
• odzwierciedla sposób, w jaki ludzie biznesu postrzegają swoje przedsiębiorstwa
• większość RDBMS dostarcza obecnie bezpośredniego wsparcia dla modeli wymiarowych
• zazwyczaj dobra jest wydajność wyszukiwania
• badania pokazują, że niemal cała literatura pochwala podejście wymiarowe

• Chris Todman: “Projektowanie hurtowni danych”, WNT
• Matthias Jarke, Maurizio Lenzerini, Yannis Vassiliou, Panos Vassiliadis: “Hurtownie danych. Podstawy organizacji i funkcjonowania”, WSiP

Mając dany schemat źródłowej bazy danych wraz z opisem oraz wymagania stawiane przed przyszłą hurtownią danych, zaproponuj stosowny schemat gwiazdy, na którym mogłaby opierać się ta hurtownia.

1. Jak zmieniała się w czasie liczba operacji wykonywanych na rachunkach otwartych w poszczególnych oddziałach banku?
2. Jaki był obrót na rachunkach klientów w kolejnych miesiącach i latach?
3. Jaki był obrót na rachunkach klientów w poszczególnych miesiącach i latach, z rozbiciem na grupy wiekowe i płeć?
4. Jak przedstawia się rozkład korzystania z bankomatów (częstotliwość, średnie pobierane kwoty) w zależności od dnia tygodnia i dnia miesiąca?
5. Jaka jest zależność struktury (rodzajów) wykonywanych operacji od średniego salda danego klienta?
6. Czy rodzaj posiadanej karty kredytowej wiąże się ze strukturą wydatków klientów? Jak ta zależność zmieniała się z upływem lat?
7. Ilu mamy klientów w poszczególnych grupach aktywności, zdefiniowanych na podstawie średniego obrotu i liczby wykonywanych miesięcznie operacji?
8. Jakie były przychody oddziałów banku z tytułu odsetek od pożyczek w poszczególnych miesiącach?
9. Jaki współczynnik klientów zakłada konto w swoim obszarze zamieszkania i czy to się jakoś zmienia na przestrzeni czasu?