Wyliczanie miar kalkulowanych bezpośrednio po stronie bazy danych

Okazuje się że niezależnie od tego czy programista pracuje dla klienta z branży energetycznej, farmaceutycznej czy bankowej, analizy i raporty które tworzy są z reguły bardzo podobne. Większość analiz posiada miary kalkulowane, takie jak:
   -sumy narastające na przykład: Year-To-Date (YTD), Quarter-To-Date (QTD)
   -wartości z poprzedniego okresu: Previous Year(PY), Previous Month(PM)
i tym podobne.

Są one bardzo popularne ponieważ pozwalają odnieść się do wyników uzyskanych w przeszłości (PY,PQ,...) lub pokazać stopień realizacji planu (YTD,QTD,...). Z biznesowego punktu widzenia to niezwykle cenne informacje.

I tu przejdę do sedna strony technicznej. Są to miary bardzo często wyliczane przez narzędzia warstwy prezentacji (przez aplikacje w których budujemy analizy i raporty). Co za tym idzie? Wyliczanie skomplikowanych miar po stronie warstwy prezentacji nie zawsze jest najwydajniejszą z dostępnych metod. Jeżeli zauważymy że nasz raport ma problem z wydajnością i posiada tego typu miary warto sprawdzić czy da się go usprawnić.

Przykład1. Mamy raport pokazujących wydatki na rozwój aplikacji używanych w banku. Oprócz kosztów miesięcznych, raport zawiera pola typu:
-YTD - suma narastająca kosztów z bieżącego roku, ta miara pokazuje jak wiele środków pochłonęły aplikacje w bieżącym roku
-PY(YTD) - suma narastająca kosztów z zeszłego roku.
-Budżet – ta miara została dodana do raportu ponieważ pokazuje jak bardzo YTD zbliżyło się do limitu wydatków ujętych w budżecie.

Co musi 'zrobić' warstwa prezentacyjna raportu aby obliczyć powyższe pola? W każdym przypadku coś innego:
I) Zacznijmy od YTD. Jeżeli na raporcie wyświetlamy wartości od początku roku to aby obliczyć tę miarę wystarczy skorzystać z danych jakie zostały dostarczone do tej pory. Nie trzeba sięgać do bazy danych po dodatkowe pola, a to już bardzo komfortowa sytuacja. Silnik sumuje wszystkie wartości występujące od początku roku do miesiąca bieżącego i miara gotowa.
II) Z wartością YTD z poprzedniego roku PY(YTD) jest już nieco gorzej. W tym wypadku aby uzyskać rekordy z roku minionego, musimy dodatkowo odpytać bazę danych. Trzeba to zrobić, ponieważ na chwilę obecną nie posiadamy rekordów pozwalających na wyliczenie wspomnianej miary. Jeżeli raport nawet bez wartości PY jest wolny, odpytywanie bazy danych o dodatkowe rekordy, z poprzedniego roku może sprawić że spowolni na tyle że czas wykonywania raportu przestanie być na poziomie akceptowalnym przez użytkownika.

III) Najtrudniejszym zadaniem w przytoczonym przykładzie wydaje się być dodanie kolumny zawierającej informacje o budżecie. Dlaczego? Ponieważ najczęściej ponoszone koszty oraz budżety przechowuje się w odrębnych tabelach faktów. Co za tym idzie warstwa prezentacyjna musi odpytać kolejną tabelę, żeby móc wyświetlić dodatkową kolumnę. Jak by nie patrzeć jest to kolejna potencjalnie czasochłonna czynność.

Mamy trzy różne zadania. Wśród nich dwa w których potrzebujemy dodatkowego odpytania bazy danych.

Czy da się to usprawnić? Często tak. Możemy rozszerzyć tabelę faktów i przechowywać w niej miary kalkulowane razem z miarami podstawowymi. Jaki będzie wpływ dodatkowych miar na prezentowane przypadki jeżeli do tabeli faktów dodamy nowe kolumny z gotowymi wartościami miar? Różny:

I) YTD - ta miara nie miała potrzeby sięgania do bazy danych. Można ją było obliczyć na podstawie dostępnych danych. W tym wypadku narzędzie warstwy prezentacji nie będzie musiało sumować poszczególnych miesięcy w celu uzyskania ostatecznej miary.

II) PY(YTD), miara jest gotowa, warstwa prezentacji tak jak w przykładzie powyżej nie musi wykonywać żadnych sumowań, co bez wątpienia jest korzystne. Jednak zdecydowanie większą zaletą jest uniknięcie ponownego odpytywania bazy o rekordy z poprzedniego roku. Tak jak to miało miejsce kiedy miara kalkulowana po stronie bazy danych była niedostępna.

III) Budżet - kolumna z zupełnie innej tabeli faktów. Czy może znaleźć się wśród miar wyliczanych po stronie bazy danych? Tak, pod warunkiem że obie tabele da się sprowadzić do tego samego poziomu granuralności. Często dane o budżetach oraz dane o wydatkach posiadają takie same wymiary, więc ten warunek może zostać spełniony. W tym wypadku dodanie kolumny do miar wyliczanych po stronie bazy danych pozwoliło uniknąć dodatkowego zapytania do odrębnej tabeli faktów.

Dodatkową korzyścią jest porządek jaki otrzymujemy po implementacji tego typu miar po stronie bazy danych. Dla programisty budującego analizę jest to bardzo komfortowe rozwiązanie, wszystkie miary ma 'pod ręką' i nie musi budować skomplikowanych formuł obliczających dla każdej analizy z osobna.

Czy istnieją niebezpieczeństwa związane z dodawaniem miar kalkulowanych bezpośrednio do tabeli faktów? Niestety tak. Każde dodatkowe pole przetrzymywane po stronie bazy danych potrzebuje pamięci, przekłada się to bezpośrednio na ilość potrzebnej przestrzeni dyskowej. W dzisiejszych czasach sama przestrzeń nie jest problemem ale odczytanie wszystkich wierszy z danej tabeli wiąże się z pobraniem wszystkich bloków danych. W tym momencie warto nadmienić że często to z jak dużymi tabelami faktów ma się do czynienia ocenia się po ilości wierszy. Jest to bardzo zgubna metoda! Ponieważ to od ilości megabajtów jaką zajmuje tabela a nie od ilości wierszy będzie zależał czas jej pełnego przeszukiwania. Spójrzmy na poniższy rysunek.

 

Pomarańczowa ramka pokazuje jak wiele pamięci na dysku zajmują bloki tabeli zawierającej wyłącznie miary podstawowe. Czerwona ramka obrazuje ile dodatkowej pamięci będą potrzebowały nowe miary kalkulowane, oraz dodatkowe wiersze związane z miarami kalkulowanymi. Dlaczego ilustracja przedstawia dodatkowe wiersze, skoro dodaliśmy kolumny? Miary kalkulowane często powodują że tabela nie tylko posiada więcej kolumn, ale i wierszy. Widać to na przykładzie z tabeli prezentującej wydatki na aplikacje. Aplikacja 2 nie posiada wydatków w miesiącach: luty i marzec. W takim wypadku pierwotna tabela nie posiada wierszy z nimi związanych. Jednak jeżeli zdecydujemy się na rozszerzenie tabeli o miary typu YTD, będziemy musieli dodać dwa wiersze dla lutego i marca, przechowuje wartości 0 dla wydatków miesięcznych oraz 20000 dla miary YTD.
Brałem kiedyś udział w optymalizacji raportów opartych o tabele wydatków i budżetów. Podjęliśmy decyzje o zastosowaniu miar kalkulowanych po stronie bazy danych. Okazało się że dane o wydatkach nie były danymi gęstymi, wpisy występowały co kilka miesięcy. Jednak dodanie miary YTD dla każdego miesiąca spowodowało że tabela nie dość że urosła znacznie 'w szerz' – przybyły nowe kolumny, to i urosła kilkukrotnie 'wzdłuż' przybyły wiersze które zapełniły danymi YTD miesiące w których nie było kosztów. Efekt? Tabela rozrosła się kilkukrotnie a raporty które do tej pory działały bardzo wolno zaczęły działać 'dramatycznie wolno'. Pokazuje to jak ostrożnie trzeba podchodzić do tego typu zmian i że stosowanie tej samej metody optymalizacji może przynieść różne skutki w różnych przypadkach.

Czy istnieją jeszcze jakieś przeciwwskazania? Tak, opisany powyżej sposób działania dotyczy analiz opartych o ROLAP i HOLAP. W przypadkach w których korzystamy z modelu danych opartym o kostki OLAP, które nie sięgają po dane z bazy w czasie pracy raportów i analiz (robią to tylko w czasie procesu ładowania kostki), nie ma sensu kalkulowanie miar po stronie bazy danych. Silniki OLAP nie odpytują bazy o żadne rekordy ponieważ przechowują je w kostce. Wyliczenie ich po stronie bazy danych może przyspieszyć proces ładowania kostki ale nie będzie miało wpływu na działanie analiz i raportów (więcej na temat kostek OLAP).

Implementacja kostek OLAP

Podstawą większości systemów analitycznych są hurtownie danych. Dane przechowywane są w tabelach ulokowanych na tradycyjnych serwerach bazy danych. Najczęściej w architekturze płatków śniegu lub gwiazd. Czy jest to dobre rozwiązanie? Zdecydowanie tak. Architektura tego typu pozwala na optymalne wykorzystanie tradycyjnych silników bazodanowych z punktu widzenia zadań analitycznych. A czy da się zrobić coś więcej? Przed odpowiedzią na to pytanie należało by się zastanowić jak w rzeczywistości działają silniki bazodanowe wiodących dostawców. I czy wszystkie dobrodziejstwa bazodanowe niezbędne w architekturze OLTP są korzystne z punktu widzenia zadań analitycznych. Prawdopodobnie takie pytanie zadali sobie twórcy pierwszych narzędzi pozwalających na implementacje kostek OLAP.

Nie wchodząc zbyt mocno w szczegóły, jednym z najbardziej rozbudowanych mechanizmów niezwykle istotnym dla systemów OLTP jest obsługa sesji. W systemach transakcyjnych dane są praktycznie bez przerwy dodawane i aktualizowane. Zupełnie inaczej wygląda to w systemach analitycznych. Dane z punktu widzenia użytkowników są praktycznie tylko odczytywane, nie potrzebny jest rozbudowany mechanizm obsługi sesji, ponieważ użytkownicy nie modyfikują danych. Jest to jedna z furtek pozwalających na optymalizację. Okazało się że rezygnując z mechanizmów niezbędnych w systemach OLTP, lecz nie przydatnych z punktu widzenia OLAP, da się stworzyć bardzo szybkie mechanizmy dostępu do danych. Wystarczy do powyższego dodać mechanizm obsługujący miary i wymiary i ... oto mamy to co nazywamy kostką OLAP.

Oczywiście producenci narzędzi do budowy kostek OLAP prześcigają się między sobą implementując coraz więcej mechanizmów pozwalających na przyspieszenie odczytu danych. Silniki OLAP posiadają mechanizmy agregacji danych, przechowywania danych w pamięci RAM, itp.

Poniżej znajduje się grafika obrazującą potencjalny rozwój systemów analitycznych w przedsiębiorstwie:

I Po wdrożeniu systemu informatycznego, pierwsze raporty i analizy wykonywane są na danych transakcyjnych (OLTP)

II Jeżeli ilość danych jest zbyt duża i raporty nie wykonują się w czasie akceptowalnym przez użytkownika, czas na implementację hurtowni danych.

III Implementacja hurtowni danych na pewno znacząco przyspieszyła raporty i analizy, jednak możliwe że nadal istnieją podzbiory danych tak duże że wydajność wykonywanych na nich zapytań nie jest satysfakcjonująca. W tym momencie przychodzi czas na kostki OLAP. Pobiorą dane z hurtowni w (zazwyczaj nocnym) procesie ładowania kostki, i pozwolą na bardzo szybki odczyt w momencie kiedy raport lub analiza będą ich potrzebować.

Optymalizacja hurtowni danych, czyli nie magia a konkretne kroki.

W projektach w których w pojedynczym datamarcie przechowywana jest bardzo duża ilość danych często pojawiają się problemy z wydajnością. Czasami można by pomyśleć: 'nie małym wysiłkiem (kosztem) zbudowano hurtownie danych, a raporty i analizy wykonują się wolno. Po co było to wszystko?…' Można, ale trzeba wziąć pod uwagę że w takim przypadku baza danych bez hurtowni tym bardziej nie miała by szans wykonać złożonych analiz. Czy można coś w takim przypadku zrobić? Prawdopodobnie tak, wykorzystując metody optymalizacji hurtowni danych istnieje duże prawdopodobieństwo że wydajność da się znacznie poprawić.

Od czego należy zacząć?

Architektura – Warto zacząć od przeglądu mającego na celu sprawdzenie czy wszystkie datamarty są budowane zgodnie ze sztuką (więcej na ten temat).

Optymalizacja z użyciem narzędzi dostępnych na poziomie bazy danych. Dzisiejsze bazy danych oferują wiele rozwiązań umożliwiających optymalizację. Jeżeli jesteśmy pewni że nasza hurtownia jest zaprojektowana zgodnie ze sztuką, należy spróbować optymalizacji z użyciem narzędzi które dostarcza nam baza danych. Co mam na myśli? Indeksy, partycje, widoki zmaterializowane, itp. (więcej na ten temat).

Wyliczanie miar kalkulowanych po stronie tabeli faktów. Często zdarza się że problemy z wydajnością są spowodowane skomplikowanymi zapytaniami mającymi na celu wyliczenie miar kalkulowanych. Wyliczanie tego typu miar przez narzędzia ETL i przetrzymywanie ich jako dodatkowe kolumny tabeli faktów może znacznie poprawić wydajność (więcej na ten temat).

Tworzenie tabel agregatów powalających na obniżenie ilości analizowanych danych. Bardzo często zdarza się że tabela faktów przechowuje informacje na bardzo wysokim poziomie szczegółowości. Jednak nie wszystkie raporty które z niej korzystają potrzebują takiej granuralności danych. W tego typu przypadkach warto stworzyć tabele agregatów przechowujących dane mniej szczegółowe, przez co liczba wierszy takiej tabeli znacznie się zmniejszy a wydajność z punktu widzenia raportu zwiększy (więcej na ten temat).

Implementacja kostek OLAP. Podstawą większości systemów analitycznych są hurtownie danych. Dane przechowywane są w tabelach ulokowanych na tradycyjnych serwerach bazy danych. Najczęściej w architekturze płatków śniegu lub gwiazd. Czy jest to dobre rozwiązanie? Zdecydowanie tak. Architektura tego typu pozwala na optymalne wykorzystanie tradycyjnych silników bazodanowych z punktu widzenia zadań analitycznych. A czy da się zrobić coś więcej? (więcej na tentemat).

Zmiany sprzętowe. Problemy z wydajnością można próbować rozwiązywać poprzez usprawnienia sprzętowe. Jednak w tym wypadku wypadało by się skonsultować z doświadczonym administratorem. Osoba znająca system będzie wiedziała czego brakuje: pamięci dyskowej, pamięci operacyjnej, lub mocy procesora. Często pomaga również zamiana dysków serwera na SSD. Jednak należy pamiętać o ich ograniczeniach. Dyski SSD mają ograniczoną ilość zapisów jakich mogą dokonywać. Na jednym ze szkoleń słyszałem o przypadku w którym dysk SSD został umieszczony w miejscu w którym zapisy były tak częste że ich limit został przekroczony po kilku dniach pracy serwera.

Inne sztuczki. Często narzędzia w których budujemy analizy i raporty posiadają wbudowane mechanizmy służące do optymalizacji. Chociażby mechanizmy pamięci podręcznej przechowujące wyniki ostatnich zapytań do bazy. Pozwalają zaoszczędzić czas w momencie kiedy używamy ponownie tego samego zapytania. Z użyciem tego mechanizmu można pokusić się o implementację sztuczki zwanej: 'cache heating'. Wyobraźmy sobie sytuacje w której istnieje zasobożerny raport, bardzo ważny dla użytkownika, uruchamiany co dziennie około godziny 8 rano. Raport jest na tyle skomplikowany że wyniki pojawiają się dopiero po kilku minutach od uruchomienia. Korzystając z mechanizmu cache heating, można zaimplementować automat do wywoływania raportu o godzinie 7:30, dzięki czemu w momencie wywołania raportu przez użytkownika (ok godziny 8-ej) dane będą dostępne w pamięci podręcznej i wynik pojawi się natychmiast.

Granularność danych - dobór ziarna datamartu

W dziedzinie hurtowni danych granularność (ang. granularity) związana jest z pojęciem doboru tak zwanego ziarna tabeli faktów. Można ją rozumieć jako dobór poziomu szczegółowości danych przechowywanych w pojedynczym data marcie. Zakładamy że wysoka granularność odpowiada wysokiej szczegółowości danych. Ziarno data martu jest ściśle uzależnione od wymagań biznesowych stawianych przed budowaną strukturą. Należy dobrać taki poziom szczegółowości aby możliwe było wykonanie wszystkich założonych analiz. Jednocześnie ziarno musi być dobrane na takim poziomie aby analizy wykonywały się optymalnie z punktu widzenia wydajności.

Dobór granularności można rozpatrywać zarówno w kontekście informacji znajdujących się w wymiarach, jak i miarach.

Granularność rozpatrywana na poziomie wymiarów

Granularność danych na poziomie konkretnego wymiaru należy rozumieć jako wybór najniższego poziomu hierarchii jaki będzie osiągalny.

Przykład 1. Analityk korzystający z raportu prezentującego informacje o rezerwacjach pokoi w sieci hoteli wymaga aby wymiar czasu umożliwiał prezentację danych na poziomach: roku, miesiąca oraz dnia. Dane w tej części hurtowni będą przechowywane z granularnością na poziomie dnia. Hierarchia wymiaru czasu będzie miała postać: rok -> miesiąc - > dzień

Przykład 2. Analityk korzystający z raportu prezentującego informację o połączeniach telefonicznych wykonywanych przez klientów operatora telekomunikacyjnego wymaga aby wymiar czasu umożliwiał prezentację danych na poziomach: roku, miesiąca, dnia, godziny. Dane w tej części hurtowni danych będą przechowywane z granularnością na poziomie godziny: rok -> miesiąc -> dzień -> godzina

Wiele narzędzi klasy BI pozwala na wybór alternatywnych hierarchii dla części analiz, niezależnie od granularności data martu. Jednak z oczywistych względów alternatywna hierarchia jest zawsze tą 'okrojoną' w stosunku do pierwotnej.

Przykład 3. Data mart na najniższym poziomie hierarchii czasu przechowuje informacje o dniach. Raporty mogą korzystać z hierarchii rok -> miesiąc -> dzień. Nie przeszkadza to jednak w stworzeniu hierarchii alternatywnej, ograniczonej do poziomów: rok -> miesiąc, i to bez ingerencji w dane data martu. W takim wypadku, tabela faktów przechowuje dane z granularnością dzienną ale aplikacja jest wstanie stworzyć hierarchię alternatywną (okrojoną w stosunku do oryginału) w której najniższy poziom to miesiąc.

Granularność rozpatrywana na poziomie miar

Granularność danych rozpatrywaną w kontekście miar należy rozumieć jako wybór formy w jakiej będą przechowywane informacje w tabeli faktów, w stosunku do elementarnego źródła informacji. Głównymi kryteriami są tu: relacja danych przechowywanych w tabeli faktów w stosunku do tabeli przechowującej dane transakcyjne oraz biznesowy aspekt przechowywanej informacji. Dobrą praktyką jest założenie że pojedyncza tabela faktów nie powinna zawierać wierszy o różnej granularności danych.

1. Fakty przechowywane na poziomie transakcyjnym.
   W tym wypadku pojedynczy rekord w hurtowni danych odpowiada rekordowi z tabeli źródłowej systemu transakcyjnego. Dobór ziarna na najniższym, tak zwanym 'atomowym' poziomie, powinien być zawsze pierwszą opcją którą projektant bierze pod uwagę. Podejście tego typu uodparnia strukturę na problemy związane z dodawaniem nowych wymagań które w bieżącym momencie są nie do przewidzenia a mogły by zmienić kontekst przechowywanych danych. Miary w tej postaci nie są agregowane, więc mogą być interpretowane dokładnie w ten sam sposób jak wartości po stronie bazy relacyjnej a jeżeli zaistnieje taka potrzeba zawsze można dodać nowy wymiar do tabeli faktów nie martwiąc się że zmieni on granularność przechowywanych informacji (w przypadku kiedy dane są zagregowane trzeba to robić bardzo ostrożnie, ponieważ dodanie nowego wymiaru praktycznie z automatu powoduje zmianę granuralności).
   
   Przykład 4. Wystawienie paragonu w sklepie należącym do sieci handlowej, skutkuje pojedynczym wpisem w tabeli transakcyjnej bazy danych oraz pojedynczym wpisem w tabeli faktów przechowującej informacje o paragonach.
   
   W tego typu podejściu często tabela faktów przechowuje również klucz biznesowy bądź główny z tabeli bazy transakcyjnej. Jest on przydatny do zidentyfikowania odpowiadających sobie rekordów (po stronie bazy transakcyjnej i hurtowni) i używany przez narzędzia ETL podczas procesu ładowania danych hurtowni. W powyższym przykładzie kluczem biznesowym może być numer sklepu wraz z numerem paragonu. Nie należy wysnuwać pochopnych wniosków że skoro dane w data marcie przechowywane są na takim samym poziomie jak dane w bazie transakcyjnej to warstwa hurtowni danych jest zbyteczna, ponieważ prawdziwą siłą hurtowni danych jest to że poprzez odpowiedni dobór miar i wymiarów umożliwiają wykonywanie skomplikowanych z punktu widzenia transakcyjnego źródła danych zapytań analitycznych.
   
2. Fakty przechowywane na poziomie danych zagregowanych.
   Czasami tabele faktów nie przechowują informacji na poziomie 'atomowym', a jedynie na poziomie odpowiednich agregacji rekordów rekordów źródłowych. Podejście tego typu charakteryzuje wyższa wydajność zapytań, które zamiast wyliczać wartość na podstawie danych z niższego poziomu, korzystają z gotowej, zagregowanej prędzej miary. Scenariusz taki ma szanse się sprawdzić jeżeli weźmie się pod uwagę że analiza biznesowa nie przewiduje wglądu w szczegóły danych zagregowanych. Często podejście tego typu uniemożliwia tworzenie na przykład raportów wykazowych, które potrzebowały by dostępu do danych na takim poziomie jak te z systemu transakcyjnego.
   
   Przykład 5. Raport kosztów zatrudnienia pracowników porównujący koszty działalności oddziałów z całego świata korzysta z datamartu w którym dane o zarobkach w danej lokalizacji prezentowane są przez dwie miary: suma zarobków na danej pozycji i ilość osób pracujących na danej pozycji. Na podstawie tych dwóch miar można obliczyć również średnią zarobków – więc wszystko co mogło by interesować analityka porównującego koszty prowadzenia działalności w różnych częściach świata. Analitykowi nigdy nie będzie potrzebny raport wykazowy z listą wszystkich pracowników firmy zatrudnionych na danej pozycji wraz z ich konkretnymi zarobkami. Te informacje znajdują się w systemie transakcyjnym ale są nie przydatne z punktu widzenia rozpatrywanej analizy. Załóżmy że na danej pozycji w przeciętnej lokalizacji pracuje średnio 50 osób. W tym momencie zamiast potencjalnych 50 rekordów tabela faktów przechowuje jeden rekord. A wartość przechowywanej informacji z punktu widzenia analizy jest dokładnie taka sama. Widać jak duży potencjał mają dane odpowiednio zagregowane. Wyobraźmy sobie tabele faktów która na poziomie 'atomowym' posiadała by 100 milionów wierszy, a po odpowiednim zagregowaniu mogła by posiadać 2 miliony wierszy, czyli 50 razy mniej.
   
   Oczywiście to że główna tabela faktów posiada dane zagregowane nie oznacza że, jeżeli zajdzie potrzeba nie wolno korzystać dodatkowych tabel agregujących. Jest to jedna z popularniejszych metod optymalizacji (na temat której więcej informacji można znaleźć tutaj) i można ją stosować również w momencie kiedy dane w podstawowej tabeli faktów są już w jakiś sposób zagregowane.
   
3. Fakty przechowywane na poziomie wyższym niż dane transakcyjne ale nie jako typowe dane zagregowane.
   Zdarza się że analitycy mają potrzebę rozpatrywania zdarzeń na stosunkowo niskim poziomie, zbliżonym do poziomu pojedynczej transakcji, lecz obwarowywanym pewnymi biznesowymi warunkami.
   
   Przykład 6. Analityk operatora energetycznego sprawdza ilości awarii sieci energetycznej, aby sprawdzić który fragment sieci należy poddać remontowi. Zakłada się że ilość awarii powinna być liczona w następujący sposób: jeżeli kolejne przerwy w dostawie energii elektrycznej były oddalone od siebie o mniej niż 3 minuty, powinny być zaliczone do jednej awarii.
   
   W rozpatrywanym przykładzie dojdzie do scalenia zdarzeń na poziomie transakcyjnym, pod pewnymi warunkami biznesowymi. Zaleca się aby data mart przechowywał wpisy na poziomie awarii a nie przerwy ponieważ to właśnie awarie są analizowane. Przechowywanie danych na poziomie pojedynczej przerwy, było by kłopotliwe ponieważ wymagało by wykonania dodatkowych operacji scalania bezpośrednio przed wykonaniem analizy. Największą niedogodnością takiego podejścia jest konieczność implementacji bardziej złożonego (w stosunku do przechowywania danych na poziomie transakcyjnym) procesu ETL. Który realizował by założoną funkcjonalność. Poza tym w tego typu przypadkach w tabeli faktów najczęściej nie da się przechowywać informacji o kluczu biznesowym danych źródłowych. Chociażby dlatego że dane hurtowni są w relacji 1 do N w stosunku do danych źródłowych.

Ważnym aspektem w kontekście doboru miar tabeli faktów jest to aby miary zawsze były zgodne z ziarnem tabeli. Dobrym przykładem (zaczerpniętym z porad Kimball Group) jest data mart przechowujący informacje o sprzedaży towarów w sklepie. O ile prawidłowe jest umieszczenie w nim miar: ilość sprzedanego towaru oraz wartość sprzedanego towaru, o tyle błędem było by umieszczanie kolumny przechowującej informacje o zarobkach kierownika sklepu, która ma się nijak do transakcji sprzedaży.

Hurtownie danych w praktyce

Poniżej znajdziecie Państwo artykuły zawierające zbiór 'dobrych praktyk' związanych z budową hurtowni danych.

01. Optymalizacja hurtowni danych, czyli nie magia a konkretne kroki

02. Zastosowanie sztucznych kluczy w tabelach faktów i wymiarów - w opracowaniu

03. Wyliczanie miar kalkulowanych bezpośrednio po stronie bazy danych.

04. Implementacja kostek OLAP

04. ETL kurs praktyczny

Jak zacząć przygodę z narzędziami ETL?
Wydaje się że najlepiej rozpocząć od tutoriali opisujących podstawowe funkcjonalności narzędzi w których wykonywany będzie projekt. Proponuję przegląd najpopularniejszych narzędzi ETL (podział na popularne i nie popularne jest najbardziej subiektywną częścią bloga, ponieważ zależy od tego jakie narzędzia zna autor):

01. Talend Open Studio (TOS) - w opracowaniu
02. Sql Server Integration Services (SSIS) - w opracowaniu
03. SAS - w opracowaniu

Pierwszą umiejętnością jaką warto nabyć po wyborze narzędzia ETL jest pobranie rekordów z tabel bazy danych.

04. Kontrolki pozwalające na pobieranie danych z bazy danych w Talend Open Studio (TOS) - w opracowaniu
05. Kontrolki pozwalające na pobieranie danych z bazy danych w Sql Server Integration Services (SSIS) - w opracowaniu 
06. Kontrolki pozwalające na pobieranie danych z bazy danych w SAS - w opracowaniu

Kiedy wiadomo jak pobierać informacje z bazy danych, warto nauczyć się łączyć i mapować pobierane rekordy.

07. Mapowanie / joinowanie danych w Talend Open Studio (TOS) - w opracowaniu
08. Mapowanie / joinowanie danych w Sql Server Integration Services (SSIS) - w opracowaniu 
09. Mapowanie / joinowanie danych w SAS - w opracowaniu

Dane w odpowiednio przetworzonej formie najczęściej zapisujemy w tabeli docelowej.

10. Zapisywanie danych w Talend Open Studio (TOS) - w opracowaniu
11. Zapisywanie danych w Sql Server Integration Services (SSIS) - w opracowaniu
12. Zapisywanie danych w SAS - w opracowaniu

Hurtownie danych posiadają specjalistyczne mechanizmy pozwalające na przechowywanie danych historycznych. Poniżej opis jak korzystać z mechanizmów SCD, w omawianych narzędziach.

13. SCD w Talend Open Studio (TOS) - w opracowaniu
14. SCD w Sql Server Integration Services (SSIS) - w opracowaniu
15. SCD w SAS - w opracowaniu

Dla kogo piszę tego bloga?

Witam na blogu poświęconym tematyce szeroko pojętego Business Intelligence

  Przeszukując 'polski Internet' w poszukiwaniu rozwiązań problemów z którymi spotykałem się podczas wdrożeń systemów BI wielokrotnie napotykałem na strony wprowadzające czytelnika we wspomnianą tematykę. Niestety ciężko natrafić na informacje dla tak zwanych użytkowników średnio zaawansowanych lub zaawansowanych, którzy znają już podstawy chociażby hurtowni danych, ale napotkali na szczególny nie trywialny problem który muszą rozwiązać.
  Strona na której się Państwo znajdujecie ma z założenia nie tylko pomóc w poszerzaniu wiedzy związanej z Business Intelligence, ale również być narzędziem przydatnym w rozwiązywaniu specyficznych dla tej dziedziny IT problemów związanych z rzeczywistymi wdrożeniami. Dla mnie osobiście jest notatnikiem/'ściągawką'. Ponieważ zdarza się że w bieżących projektach spotykam problemy z którymi mierzyłem się już w przeszłości. A kilka słów spisanych podczas pierwszej analizy problemu pozwala mi w sprawny sposób przypomnieć sobie jego rozwiązanie.

Pozdrawiam
Rajmund Kulawinek