03. Gwiazdy a płatki śniegu - konfrontacja najpopularniejszych architektur hurtowni danych

Zarówno architektura gwiazdy (ang. star schema), jak i płatka śniegu (ang. snowflake schema) to podejścia typu ROLAP. Oba składają się z centralnie umieszczonej tabeli faktów, którą otaczają tabele wymiarów. Tabela faktów przechowuje informacje o miarach - czyli polach które posłużą do agregacji. Przykładem może być tabela faktów o nazwie sprzedaż zawierająca miary: kwota oraz ilość, pozwalająca na zliczanie wartości sprzedaży lub ilości sprzedanych produktów. Trzeba mieć na uwadze fakt, że rzadko analizowane są wszystkie wiersze jakie przechowuje tabela. Mało komu potrzebna jest informacja o ilości sprzedanych produktów od początku istnienia przedsiębiorstwa, bez możliwości wyznaczenia wartości w konkretnych latach. Aby ograniczyć dane do zbioru wartości interesujących odbiorcę, potrzebne są również wymiary. Każda tabela faktów posiada referencje do odpowiednich wymiarów, dzięki czemu możliwe jest zidentyfikowanie okoliczności wystąpienia faktu. Co za tym idzie, istnieje możliwość grupowania zebranych danych, bądź ograniczenia zbioru danych do interesującego podzbioru. Przykładem wymiaru może być data określająca moment w którym dokonano sprzedaży lub obszar określający miejsce sprzedaży.

Tabela faktów zawiera dane najczęściej w 3 postaci normalnej. Budowa tabeli faktów w obu architekturach jest praktycznie taka sama. Zawiera ona: swój klucz główny, wartości miar - czyli pól które będą agregowane na potrzeby raportów i analiz, oraz klucze główne do wymiarów. 

Różnice pomiędzy schematem płatka śniegu i gwiazdy pojawiają się w budowie tabel opisujących wymiary. Oba podejścia mają swoje plusy i minusy. Ale zaczynając od podstaw, ... skąd te nazwy?

Schemat gwiazdy

Płatek śniegu

	Gwiazda	Płatek śniegu
Łatwość utrzymania	Posiada nadmiarowe dane (ze względu na denormalizacje) w związku z tym wymiary są trudniejsze w utrzymaniu	Nie posiada nadmiarowych danych w związku z tym wymiary są łatwiejsze w utrzymaniu
Łatwość odpytywania	Wyjątkowo proste zapytania	Zapytania wymagają dodatkowego joinowania przez co są bardziej skomplikowane
Wydajność zapytań	Minimalna ilość kluczy obcych sprawia że zapytania wykonywane są w maksymalnie krótkim czasie	Więcej kluczy obcych powoduje wydłużenia czasu wykonania zapytania
Normalizacja wymiarów	Postać zdenormalizowana	Wymiary w formie znormalizowanej
Rekomendacja	Jeżeli projektant nie przewiduje problemów z utrzymaniem zbyt dużej ilości wierszy w wymiarze zaleca się korzystać z gwiazd, charakteryzujących się prostotą i szybkością działania	Kiedy rozmiar wymiaru jest na tyle duży że może stwarzać problemy związane z utrzymaniem struktury, lepiej jest użyć płatka śniegu który przechowuje dane w postaci znormalizowanej, co za tym idzie redukuje objętość danych. Płatki śniegu pozwalają przechowywać informacje które wymagają relacji wiele do wielu.

A czy można by spróbować uprościć powyższe architektury i rozbić wymiary posiadające hierarchie na odrębne tabele? Na przykład zamiast wymiaru obszar przechowującego informacje o: kraju, województwie, powiecie, miejscowości, zbudować osobne wymiary: kraj, województwo, powiat i miejscowość. Można by, ale rozwiązanie tego typu miało by poważne wady. Począwszy od tego że ilość wymiarów wzrosła czterokrotnie (4 tabele zamiast pojedynczej). Jednak bardziej bolesnym skutkiem, nie widocznym na pierwszy rzut oka, jest utrata bezpośredniej informacji o relacji pomiędzy elementami hierarchii: nadrzędnym i podrzędnym. Bazując na analizowanym przykładzie, aby jednoznacznie określić które miasta znajdują się w wybranym województwie trzeba przeszukać całą tabelę faktów, aby wybrać wiersze które w kluczach obcych mają wartości łączące oba wymiary. Przed rozbiciem wymiaru hierarchicznego na kilka pojedynczych wymiarów obszar (zaprojektowany jako gwiazda, lub płatek śniegu) posiadał informacje pozwalające na szukanie takich powiązań w tabelach wymiaru, bez odczytu rekordów tabeli faktów. A to znacząco upraszcza na przykład budowę parametrów wejściowych raportu.