Można sobie wyobrazić wiele sposobów na przechowanie informacji o czasie zaistnienia danego faktu. Jednak dobre praktyki budowania hurtowni danych nakazują wyodrębnienie informacji o czasie, w postaci osobnego wymiaru. Dlaczego w ten sposób, a nie na przykład bezpośrednio w tabeli faktów jako typ datetime? Głównie dlatego że typ taki charakteryzuje się wysoką gęstością danych, która z punktu widzenia analizy danych najczęściej nie jest konieczna. Aby pokryć wszystkimi wartościami zakres pełnego roku przy użyciu typu datetime potrzeba 31622400 wpisów (60s * 60m * 24h * 366d). Budowa indeksu który obsługiwał by taką kolumnę nie jest niemożliwa ale jest nie optymalna. W takim przypadku warto utworzyć wymiar daty przechowujący wpisy o dacie z granularnością do dnia. Dlaczego akurat do dnia? Ponieważ zdecydowana większość raportów prezentuje dane w których dzień jest elementarnym ziarnem analizy. Wymiar taki warto zaprezentować w formie hierarchii: rok, kwartał, miesiąc, dzień, gdzie tabela wymiaru mogła by mieć następującą postać:
W tym wypadku indeks zbudowany na polu kluczącym do wymiaru daty musiał by obsłużyć jedynie 366 wartości, dla każdego roku - czyli do 86400 raza mniej niż dla pola typu datetime.
Powyższy sposób pokazuje jak optymalnie przechowywać informację o dniu wystąpienia zdarzenia. Jednak często analiza wymaga przechowywania informacji o godzinie, a nawet minucie bądź sekundzie wystąpienia zdarzenia. Wyobraźmy sobie hurtownie danych operatora telekomunikacyjnego. W gwieździe przechowującej informacje o nawiązanych połączeniach istotne będą zarówno: data nawiązania połączenia, godzina nawiązania połączenia, jak i czas trwania połączenia. Jest to wyjątkowo dobry przykład na pokazanie że każdą z przytoczonych wartości warto przechowywać w inny sposób. O dacie już wspomniałem. teraz kilka słów o czasie. Czas, w raportach dla klientów z branży telekomunikacyjnej musi być określony bardzo precyzyjnie. Często analizy uwzględniają podział na: dzień/noc, szczyt/poza szczytem, co automatycznie wymusza precyzje definiowania czasu uwzględniającą co najmniej godzinę, a czasami nawet minutę i sekundę. W takich przypadkach warto utworzyć osobny wymiar czasu i przy okazji rozważyć budowę hierarchii czasu, zawierającą informację o np.: porze (noc/dzień), godzinie, minucie. Tabela takiego wymiaru mogla by wyglądać następująco:
Dlaczego warto stworzyć osobny wymiar czasu a nie jeden wspólny z datą? Po pierwsze dlatego że stracili byśmy większość zalet wynikających z przechowywania informacji o dacie i czasie w wymiarach a nie w polu typu datetime. Po części dlatego że, analogicznie jak to miało miejsce w przypadku daty, samemu dobierzemy granularność danych. Ale kluczowe w rozdzieleniu wspomnianych wymiarów jest to że, często analizy będą prowadzone na dwóch osobnych płaszczyznach (czasu i daty) nie koniecznie bezpośrednio związanych ze sobą. Na przykład, można sobie wyobrazić kwartalny raport prezentujący ilość nawiązanych połączeń w porze nocnej, pomiędzy godziną 23:00 a 5:00. Słupki wykresu mogły by prezentować ilości połączeń dla każdej godziny. Wymiar czasu miał by 24 rekordy a dzięki odpowiedniemu indeksowi (nałożonemu na klucz do wymiaru czasu z tabeli faktów) w bardzo wydajny sposób ze zbioru wszystkich połączeń wybierali byśmy tylko te które wystąpiły między 23:00 a 5:00 (6 z 24 wartości klucza). Natomiast klucz do wymiaru daty związany z parametrami wyboru kwartału zawierał by się w zbiorze około 92 z 366 wartości (1/4 z 366dni w roku), przy założeniu że mamy do czynienia ze zbiorem danych rocznych.
Wróćmy do ostatniej informacji jaką założyliśmy że przechowa przykładowa gwiazda - czasu trwania połączenia. Jest to wartość która na raportach będzie agregowana (sumowana, uśredniana, itp), nie tak jak dwie poprzednie, które służyły do ograniczania analizowanego zbioru danych. Taka wartość nie jest więc wymiarem. Jest miarą. Dlatego nie występuje w wymiarach, lecz bezpośrednio w tabeli faktów w postaci numerycznej.
Czy w związku z powyższym jest sens przechowywania informacji o dacie zdarzenia bezpośrednio w tabeli faktów? Na przykład w formacie datetime? Czasami tak. W niektórych przypadkach warto przechowywać taką informację, jako atrybut który będzie wyświetlany w tak zwanych raportach wykazów bądź szczegółów. Czyli raportach które nie prezentują agregowanych danych (np. sumy wartości sprzedaży w zadanym miesiącu), tylko prezentują listę elementarnych zdarzeń mających wpływ na wyliczaną wartość (zgodnie z wcześniejszym przykładem może to być lista wykonanych połączeń). W takim wypadku parametry wejściowe powinny zostać oparte o wymiary: daty i czasu dzięki czemu odpowiednie dane zostaną sprawnie odfiltrowane. Natomiast kolumna atrybutu szczegółowej daty i godziny będzie mogła zostać użyta aby w prosty sposób wyświetlić datę i czas połączenia. Raporty tego typu często występują jako raporty podrzędne wywoływane poprzez opcję drążenia wszerz (drill through).
Brak komentarzy:
Prześlij komentarz