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.