Podczas wybierania schematu bazy danych dla hurtowni danych, płatek śniegu i schematy gwiezdne bywają popularnymi wyborami. To porównanie omawia przydatność schematów gwiazda vs. płatek śniegu w różnych scenariuszach i ich cechy.
Schemat płatka śniegu | Schemat gwiezdny | |
---|---|---|
Łatwość konserwacji / wymiany | Brak redundancji, więc schematy płatków śniegu są łatwiejsze do utrzymania i zmiany. | Ma nadmiarowe dane, a zatem jest trudniejszy do utrzymania / zmiany |
Łatwość użycia | Bardziej złożone zapytania, a zatem trudniejsze do zrozumienia | Niższa złożoność zapytań i łatwa do zrozumienia |
Wydajność zapytania | Więcej kluczy obcych, a tym samym dłuższy czas wykonywania zapytania (wolniej) | Mniejsza liczba kluczy obcych, a tym samym krótszy czas wykonywania zapytania (szybciej) |
Rodzaj magazynu danych | Dobry w użyciu dla rdzenia bazy danych, aby uprościć złożone relacje (wiele: wiele) | Dobry dla kart danych z prostymi relacjami (1: 1 lub 1: wiele) |
Łączy się | Wyższa liczba połączeń | Mniej połączeń |
Tabela wymiarów | Schemat płatka śniegu może mieć więcej niż jedną tabelę wymiarów dla każdego wymiaru. | Schemat gwiazdy zawiera tylko jedną tabelę wymiarów dla każdego wymiaru. |
Kiedy użyć | Gdy tabela wymiarów jest stosunkowo duża, płatek śniegu jest lepszy, ponieważ zmniejsza przestrzeń. | Gdy tabela wymiarów zawiera mniejszą liczbę wierszy, możemy wybrać schemat gwiazdy. |
Normalizacja / Dezormalizacja | Tabele wymiarów są w formie znormalizowanej, ale tabela faktów jest w formie zdenormalizowanej | Tabele wymiarów i faktów są w formie zdenormalizowanej |
Model danych | Podejście oddolne | Podejście z góry na dół |
Rozważ bazę danych dla detalisty, który ma wiele sklepów, przy czym każdy sklep sprzedaje wiele produktów w wielu kategoriach produktów i różnych marek. Hurtownia danych lub hurtownia danych dla takiego detalisty musieliby zapewnić analitykom możliwość uruchamiania raportów sprzedaży pogrupowanych według sklepu, daty (lub miesiąca, kwartału lub roku), kategorii produktu lub marki.
Jeśli ta baza danych używa schematu gwiazdy, wyglądałaby następująco:
Przykład schematu gwiazdyTabela faktów byłaby zapisem transakcji sprzedaży, podczas gdy istnieją tabele wymiarów dla daty, sklepu i produktu. Tabele wymiarów są połączone z tabelą faktów za pomocą klucza podstawowego, który jest kluczem obcym dla tabeli faktów. Na przykład zamiast przechowywać aktualną datę transakcji w wierszu tabeli faktów, data_id jest przechowywana. Ten date_id odpowiada unikatowemu wierszowi w tabeli Dim_Date, a ten wiersz przechowuje także inne atrybuty daty, które są wymagane do grupowania w raportach. np. dzień tygodnia, miesiąc, kwartał i tak dalej. Dane są denormalizowane w celu łatwiejszego raportowania.
Oto, w jaki sposób można uzyskać raport o liczbie telewizorów sprzedawanych według marki i kraju za pomocą wewnętrznych połączeń.
Ten sam scenariusz może również wykorzystywać schemat płatka śniegu, w którym to przypadku miałby następującą strukturę:
Przykład schematu płatka śniegu (kliknij, aby powiększyć)Główną różnicą w porównaniu ze schematem gwiazdy jest to, że dane w tabelach wymiarów są bardziej znormalizowane. Na przykład zamiast przechowywać miesiąc, kwartał i dzień tygodnia w każdym wierszu tabeli Dim_Date, są one dalej dzielone na własne tabele wymiarów. Podobnie dla tabeli Dim_Store, stan i kraj to atrybuty geograficzne, które zostały usunięte o jeden krok - zamiast być przechowywane w tabeli Dim_Store, są one teraz przechowywane w osobnej tabeli Dim_Geography.
Ten sam raport - liczba telewizorów sprzedawanych według kraju i marki - jest teraz nieco bardziej skomplikowany niż w schemacie gwiazdy:
Zapytanie SQL, aby uzyskać liczbę produktów sprzedawanych według kraju i marki, gdy baza danych używa schematu płatka śniegu.