Schemat Płatka Śniegu i Gwiazdy

Twój hurtownia prawdopodobnie nie rozpoczęła się od debaty na temat schematu. Zaczęło się od prośby o pulpit nawigacyjny, raportu o przychodach, widoku klienta, a następnie sterty nowych źródeł, które wszystkie musiały wylądować w jakimś rozsądnym miejscu. Miesiące później analitycy dodają złączenia z przyzwyczajenia, zapytania BI stają się wolniejsze i nikt nie zgadza się co do tego, czy model ma być prosty do raportowania, czy rygorystyczny pod kątem governance.

W tym miejscu zazwyczaj pojawia się dyskusja na temat tak zwanego schematu Star Snowflake Schema (gwiazda-płatek śniegu). W praktyce to sformułowanie jest mylące. Zespoły używają go, gdy nie pracują już z czystą gwiazdą ani czystym płatkiem śniegu i potrzebują praktycznego sposobu na rozmawianie o modelach mieszanych działających na produkcji. Kluczowe pytanie nie jest akademickie. Chodzi o to, czy Twoje tabele faktów, wymiary, złączenia i kontrole jakości nadal wspierają sposób, w jaki ludzie wysyłają zapytania do hurtowni i ugruntowują ich zaufanie do niej.

Większość artykułów kończy się na definicjach. To za mało, gdy model działa już na żywo, jest współdzielony przez zespoły i zmienia się pod obciążeniem. Trudniejszy problem ma charakter operacyjny: jak wybrać właściwy wzorzec, gdzie pomaga projekt hybrydowy i jak monitorować punkty krytyczne, które pojawiają się, gdy współistnieją struktury zdenormalizowane i znormalizowane.

Spis treści

• Rozdroża projektowania hurtowni danych

• Fundamentalne architektury: Schematy Gwiazdy i Płatka Śniegu

  • Schemat gwiazdy jako model typu hub

  • Schemat płatka śniegu jako model rozgałęziony

• Szczegółowe porównanie kluczowych różnic

  • Tabela wczesnego porównania

  • Wydajność i zachowanie złączeń

  • Integralność, przechowywanie i utrzymanie operacyjne

• Wzrost popularności hybrydowych modeli Gwiazda-Płatek Śniegu

  • Gdzie pojawiają się modele hybrydowe

  • Co działa, a co się psuje

• Jak wybrać właściwy schemat dla swojego przypadku użycia

  • Praktyczne kryterium decyzyjne

  • Przypadki użycia jako punkty wyjścia

• Monitorowanie i Observability dla Twojego schematu

  • Wybór schematu to nie koniec pracy

  • Co monitorować w modelach mieszanych

• Przykładowe modele danych i zapytania SQL

  • Przykład schematu gwiazdy

  • Przykład schematu płatka śniegu

Rozdroża projektowania hurtowni danych

W rosnących zespołach danych pojawia się znajomy wzorzec. Pierwszy model hurtowni powstaje szybko, zazwyczaj wokół kilku pulpitów nawigacyjnych i kilku dobrze zrozumiałych źródeł. To działa. Następnie firma dodaje raportowanie regionalne, zmiany w hierarchii produktów, finanse chcą ściślejszego uzgadniania danych i ktoś pyta, dlaczego pulpit nawigacyjny, który kiedyś ładował się natychmiast, teraz ciągnie się przez kilka złączeń.

W tym momencie projektowanie schematu przestaje być kwestią preferencji modelowania, a staje się ograniczeniem operacyjnym. Sposób ustrukturyzowania faktów i wymiarów wpływa na szybkość zapytań, użyteczność systemów BI, zachowanie pamięci masowej oraz na to, jak bolesne będą przyszłe zmiany. Wpływa również na to, kto może bezpiecznie pracować z modelem. Spłaszczony projekt pomaga analitykom działać szybko. Bardziej znormalizowany daje inżynierom ściślejszą kontrolę nad spójnością wymiarów.

Zespoły rzadko żałują świadomie podjętych decyzji. Żałują natomiast dziedziczenia struktury, która powstała przez przypadek.

Sformułowanie star snowflake schema często pojawia się właśnie tutaj, w punkcie, w którym hurtownia nie jest już w czysty sposób jedną lub drugą rzeczą. To przydatny skrót myślowy w rozmowie, ale ukrywa ważny szczegół. Nie wybierasz formalnego standardu hybrydowego. Decydujesz, gdzie zachować płaskie wymiary, gdzie je znormalizować i co to oznacza dla wydajności, governance oraz Observability na produkcji.

Fundamentalne architektury: Schematy Gwiazdy i Płatka Śniegu

Termin star snowflake schema brzmi jak jedna technika modelowania. Tak nie jest. Łączy on dwa odrębne wzorce wymiarowe, które rozwiązują różne problemy.

Pierwszy to schemat gwiazdy. Drugi to schemat płatka śniegu. Zgodnie z wyjaśnieniem podstaw schematu gwiazdy przygotowanym przez Snowflake, schemat gwiazdy jest podejściem najszerzej stosowanym do tworzenia hurtowni danych, z jedną lub kilkoma tabelami faktów połączonymi ze zdenormalizowanymi tabelami wymiarów w celu uproszczenia zapytań i szybszego działania. Schemat płatka śniegu jest rozszerzoną formą, w której te wymiary są znormalizowane do tabel podwymiarów.

Dla zespołów projektujących modele analityczne ta różnica to klucz do całej gry.

Schemat gwiazdy jako model typu hub

Schemat gwiazdy umieszcza tabelę faktów w centrum i łączy ją bezpośrednio z otaczającymi ją tabelami wymiarów. Wyobraź sobie fakty dotyczące sprzedaży w środku, a wokół nich wymiary produktu, klienta, daty i sklepu. Każdy wymiar niesie ze sobą atrybuty opisowe, których analitycy potrzebują do grupowania i filtrowania.

Ten bezpośredni kształt ma znaczenie, ponieważ sprawia, że kod SQL jest krótki i przewidywalny. Analitycy mogą łączyć tabelę faktów z wymiarami bez konieczności poruszania się po tabelach hierarchii dla kategorii, regionu czy działu. Jeśli Twoim priorytetem jest szybkość raportowania i czytelność modelu, właśnie dlatego schematy gwiazdy pozostają domyślnym punktem wyjścia.

Praktyczny przewodnik po modelowaniu hurtowni, taki jak przewodnik po modelowaniu danych w hurtowni marki digna, jest tutaj przydatny, ponieważ osadza wybór projektu wokół zachowania analityki, a nie tylko podręcznikowej normalizacji.

Schemat płatka śniegu jako model rozgałęziony

Schemat płatka śniegu zaczyna się w tym samym centrum, ale tabele wymiarów rozgałęziają się na powiązane podwymiary. Produkt może dzielić się na tabele podkategorii i kategorii. Geografia może dzielić się na miasto, region i kraj. Kształt staje się bardziej hierarchiczny, a warstwa wymiarów wyraźniej odzwierciedla współdzielone dane referencyjne.

Ta normalizacja zmniejsza nadmiarowość i wspiera silniejszą spójność atrybutów wymiarowych. Jeśli zmienia się nazwa kategorii, aktualizujesz odpowiedni wiersz wymiaru, zamiast powtarzać zmianę w płaskiej, zdenormalizowanej tabeli. Kompromis jest oczywisty w SQL. Więcej tabel oznacza więcej złączeń. Więcej złączeń oznacza większą złożoność w zapytaniach BI, planowaniu zapytań i rozwiązywaniu problemów.

Praktyczna zasada: Używaj gwiazdy, gdy ludzie stale wysyłają zapytania. Używaj płatka śniegu, gdy błędy w spójności wymiarów są kosztowne.

Szczegółowe porównanie kluczowych różnic

Wybór projektu zaczyna mieć znaczenie, gdy trafia na niego ruch produkcyjny. Różnica między gwiazdą a płatkiem śniegu ujawnia się najpierw w trzech miejscach: opóźnieniu zapytań, utrzymaniu modelu oraz ilości monitoringu wymaganego do utrzymania wiarygodności wymiarów w czasie.

Tabela wczesnego porównania

Wydajność i zachowanie złączeń

Liczba złączeń jest nadal najbardziej jednoznacznym wskaźnikiem codziennego zachowania zapytań. W schemacie gwiazdy analitycy zazwyczaj łączą tabelę faktów z małym zestawem szerokich wymiarów i na tym kończą. W schemacie płatka śniegu te wymiary często dzielą się na tabele hierarchii, więc każdy raport, który grupuje według kategorii, regionu lub działu, dodaje silnikowi pracy związanej ze złączeniami i zwiększa ryzyko błędów w SQL.

Porównanie schematu gwiazdy i wzorców jednej dużej tabeli (OBT) przygotowane przez Fivetran potwierdza ogólny kierunek tego kompromisu w systemach Redshift, Snowflake i BigQuery. Płaskie modele zazwyczaj czytają się szybciej. To nie czyni z płatka śniegu złego projektu. Oznacza to jedynie, że każda znormalizowana gałąź musi uzasadnić swój koszt w postaci opóźnień, złożoności semantycznej i obciążenia wsparcia technicznego.

To szybko uwidacznia się w narzędziach BI. Warstwy semantyczne są łatwiejsze do modelowania na gwiazdach, ponieważ graf złączeń jest mniejszy i bardziej stabilny. Plany zapytań są również łatwiejsze do przeanalizowania podczas reagowania na incydenty. Gdy pulpit nawigacyjny zwalnia po zmianie schematu, płaski model wymiarów daje inżynierom mniej miejsc do zbadania.

Integralność, przechowywanie i utrzymanie operacyjne

Schematy płatka śniegu zyskują na znaczeniu, gdy spójność wymiarowa niesie za sobą realny koszt operacyjny. Taksonomia produktów, struktury podmiotów prawnych, regulowane klasyfikacje klientów i hierarchie geograficzne często zmieniają się pod ściślejszym nadzorem (governance) niż fakty, które się do nich odnoszą. Normalizacja tych struktur zmniejsza duplikowanie atrybutów i obniża szansę, że dwa raporty użyją różnych wersji tej samej wartości referencyjnej.

Wydajność przechowywania jest korzyścią drugorzędną teraz, gdy moc obliczeniowa hurtowni zazwyczaj kosztuje więcej uwagi niż surowy dysk. Większym problemem jest zarządzanie zmianami. Schemat gwiazdy przenosi złożoność do potoków ETL lub ELT, które spłaszczają wymiary, zanim analitycy wykonają na nich zapytania. Schemat płatka śniegu utrzymuje model referencyjny w czystszej postaci, ale przenosi więcej złożoności na złączenia, definicje semantyczne i śledzenie zależności.

Ten kompromis wpływa na różne zespoły w różny sposób:

• Analitycy piszą krótszy SQL w przypadku gwiazd i spędzają mniej czasu na śledzeniu logiki hierarchii w wielu tabelach.

• Inżynierowie danych spędzają mniej czasu na udostępnianiu wyselekcjonowanych martów na prostych gwiazdach, ale więcej czasu na zarządzaniu zduplikowanymi atrybutami i uzupełnianiu danych wstecznych (backfills), gdy wartości wymiarów się rozjeżdżają.

• Programiści BI i inżynierowie analityczni wykonują więcej pracy nad modelowaniem semantycznym na płatkach śniegu, ponieważ każda dodatkowa gałąź wymaga przetestowanej logiki złączeń, jasnego nazewnictwa i zabezpieczeń przed błędami typu fan-out (mnożenie wierszy).

• Zespoły platformowe potrzebują silniejszego Observability na płatkach śniegu. Uszkodzone powiązania hierarchii, osierocone klucze i opóźnione ładowanie wymiarów mogą pogorszyć poprawność raportów bez wywoływania twardego błędu potoku.

Na produkcji ten ostatni punkt ma większe znaczenie, niż przyznaje wiele podręczników projektowania. Schemat gwiazdy zazwyczaj ulega awarii w widoczny sposób, np. poprzez nieaktualne atrybuty zdenormalizowane lub wolniejsze przebudowywanie. Schemat płatka śniegu może zepsuć się w sposób subtelny. Jeden brakujący wiersz w podwymiarze może zmienić agregaty, usunąć kategorie z pulpitów nawigacyjnych lub wywołać niespójne ścieżki szczegółowości (drill paths) w różnych narzędziach. Dlatego wybór schematu powinien obejmować pytanie operacyjne, a nie tylko modelowe: który tryb awarii jest łatwiejszy do wykrycia, wyjaśnienia i naprawienia przez Twój zespół?

Wzrost popularności hybrydowych modeli Gwiazda-Płatek Śniegu

Bardzo niewiele produkcyjnych hurtowni danych pozostaje czystymi strukturami przez długi czas. Wymiary produktów pozostają płaskie, ponieważ analitycy korzystają z nich codziennie. Geografia ulega normalizacji, ponieważ hierarchie regionalne się zmieniają. Atrybuty klientów dzielą się, ponieważ zasady governance wymagają ściślejszej kontroli nad niektórymi polami, a nad innymi nie. To opisuje to, co często określa się mianem star snowflake schema.

Nie jest to trzecia kanoniczna architektura. To praktyczny model mieszany.

Gdzie pojawiają się modele hybrydowe

Wzorce hybrydowe zazwyczaj wyłaniają się na jeden z trzech sposobów.

• Głównie hurtownia w układzie gwiazdy z jednym wymiarem w układzie płatka śniegu. Jest to powszechne w przypadku geografii, taksonomii produktów lub hierarchii organizacyjnej.

• Zarządzany pod kątem governance rdzeń ze spłaszczonymi martami danych. Hurtownia przechowuje znormalizowane wymiary referencyjne, a następnie marty położone na dalszych etapach udostępniają zdenormalizowane widoki na potrzeby konsumpcji przez narzędzia BI.

• Model, który ewoluował w czasie. Nowe wymiary były dodawane przy różnych ograniczeniach, więc niektóre pozostały płaskie, podczas gdy inne zostały znormalizowane.

To mieszane podejście jest często uzasadnione. Zgodnie z porównaniem Big Data Boutique, schematy gwiazdy pozostają optymalnym punktem wyjścia dla 90% analitycznych przypadków użycia, a wzorce płatka śniegu są zarezerwowane dla dużych wymiarów lub rygorystycznych wymogów governance.

Co działa, a co się psuje

To, co działa, to selektywna normalizacja. Zespół może zachować często używane wymiary w postaci płaskiej dla wydajności pulpitów nawigacyjnych i zastosować strukturę płatka śniegu dla nielicznych wymiarów, w których nadmiarowość lub koszty ładu danych są realne. Może to być zdyscyplinowany projekt.

To, co nie działa, to przypadkowa niespójność. Jeden wymiar jest zgodny ze spójnym nazewnictwem. Inny przechowuje zduplikowane atrybuty w dwóch miejscach. Analitycy nie wiedzą, czy kategoria powinna pochodzić z płaskiej tabeli produktów, czy ze znormalizowanej tabeli kategorii. SQL zaczyna zwracać technicznie poprawne, ale logicznie niespójne odpowiedzi.

Model hybrydowy zwiększa również obciążenie operacyjne:

Modele hybrydowe zawodzą, gdy zespoły mieszają wzorce bez dyscypliny w zakresie nazewnictwa, własności i walidacji.

Jak wybrać właściwy schemat dla swojego przypadku użycia

Decyzja o schemacie jest zazwyczaj wymuszana przez problem produkcyjny, a nie przez teorię. Zespół BI otrzymuje skargi na wolno działające pulpity. Lider ds. governance znajduje sprzeczne hierarchie produktów w raportach finansowych i sprzedażowych. Zespół platformowy spędza zbyt dużo czasu na naprawianiu aktualizacji wymiarów po zmianach w źródłach. Właściwy wybór zaczyna się od zidentyfikowania trybu awarii, który musisz ograniczyć.

Praktyczne kryterium decyzyjne

Zacznij od ścieżki zapytania. Jeśli analitycy, programiści BI lub narzędzia na kolejnych etapach bezpośrednio odpytują tabele hurtowni, gwiazda jest zazwyczaj bezpieczniejszym domyślnym wyborem, ponieważ zachowuje przewidywalność złączeń i ułatwia dostrzeżenie błędów semantycznych. Jeśli warstwa semantyczna ukrywa złożoność modelu, masz większe pole do normalizacji, ale koszt utrzymania nie znika. Inżynierowie danych nadal odpowiadają za złączenia, zarządzanie kluczami i logikę hierarchii pod spodem.

Kolejnym pytaniem jest częstotliwość zmian. Strukturyzacja płatka śniegu opłaca się, gdy struktury wymiarów zmieniają się na tyle często, że powtarzające się aktualizacje atrybutów stają się realnym kosztem operacyjnym. Taksonomia produktów, zestawienia podmiotów prawnych, mapowania regionalne i plany kont to typowe przykłady. W takich przypadkach normalizacja służy mniej elegancji, a bardziej kontrolowaniu ścieżek aktualizacji, ograniczaniu zduplikowanej logiki biznesowej i zmniejszaniu prawdopodobieństwa, że jeden raport użyje nieaktualnych danych referencyjnych.

Wydajność wciąż ma znaczenie, ale kompromis jest szerszy niż sama liczba złączeń. Schematy gwiazdy zazwyczaj przyspieszają analizy ad-hoc i ułatwiają ich tuning. Schematy płatka śniegu mogą poprawić spójność we współdzielonych wymiarach, ale tworzą również więcej zależności, więcej pochodzenia do śledzenia i więcej sposobów, w jakie zmiany na wcześniejszych etapach mogą zepsuć zapytania na dalszych etapach.

Użyj tych pytań, aby urealnić decyzję:

1. Kto odpowiada za ostatni etap zapytań? Bezpośredni użytkownicy SQL zazwyczaj lepiej radzą sobie z płaskimi wymiarami.

2. Które wymiary zmieniają się strukturalnie, a nie tylko pod względem liczby wierszy? Częste zmiany struktury hierarchii często uzasadniają normalizację.

3. Gdzie błędne dane generują największy koszt? Jeśli zduplikowane lub sprzeczne wartości referencyjne powodują problemy z audytem, finansami lub regulacjami (Compliance), kontrola może mieć większe znaczenie niż szybkość.

4. Ile modeli na kolejnych etapach ponownie wykorzystuje tę samą logikę wymiarów? Współdzielona logika popycha projekt w stronę silniejszej kontroli centralnej.

5. Czy zespół jest w stanie monitorować model na tyle dobrze, by udźwignąć dodatkową złożoność? Projekt w układzie płatka śniegu lub hybrydowy wymaga ściślejszego pochodzenia danych, kontroli świeżości i monitorowania integralności kluczy. Zespoły, które już inwestują w praktyki Data Observability, mogą bezpieczniej radzić sobie z tą złożonością.

Przypadki użycia jako punkty wyjścia

Niektóre domyślne założenia dobrze sprawdzają się w praktyce.

• Analityka sprzedaży detalicznej: Zacznij od gwiazdy. Wymiary produktu, sklepu, klienta i daty są stale filtrowane, a szybkość reakcji pulpitów nawigacyjnych zazwyczaj ma większe znaczenie niż ograniczenie skromnej ilości nadmiarowości wymiarowej.

• Raportowanie finansowe z kontrolowanymi hierarchiami: Zacznij od selektywnego płatka śniegu lub zarządzanej hybrydy. Struktury kont i podmiotów zmieniają się pod formalną kontrolą, a niespójne zestawienia szybko generują ryzyko raportowania.

• Zachowanie użytkowników i analityka produktu: Zachowaj płaską strukturę, chyba że wymiar jest zarówno duży, jak i intensywnie wykorzystywany ponownie. Te zespoły szybko zmieniają definicje, a każde dodatkowe złączenie spowalnia analizę i zwiększa ryzyko niespójnego kodu SQL.

• Ochrona zdrowia i operacje regulowane praniem: Spodziewaj się hybrydy. Użytkownicy raportów nadal potrzebują użytecznych martów, ale dane referencyjne dostawców, lokalizacji, zestawów kodów i dane organizacyjne często wymagają ściślejszej kontroli i wyraźniejszej własności.

Krótka weryfikacja decyzji pozwala wychwycić wiele złych wdrożeń:

• Zapytaj zespół BI, które wymiary obsługują większość filtrów, ścieżek szczegółowości i opóźnień pulpitów nawigacyjnych.

• Zapytaj właścicieli governance, które atrybuty muszą pochodzić z jednej kontrolowanej tabeli.

• Zapytaj analityków, gdzie logika złączeń powoduje już niespójne odpowiedzi.

• Zapytaj inżynierów platformy, które wymiary najczęściej zawodzą podczas zmian schematu źródłowego lub późno przychodzących aktualizacji.

Jeśli te odpowiedzi są niejasne, projekt nie jest gotowy. Schemat powinien odzwierciedlać sposób, w jaki hurtownia jest obsługiwana, monitorowana i debugowana na produkcji, a nie tylko jak wygląda na tablicy.

Monitorowanie i Observability dla Twojego schematu

Projektowanie schematu nie jest jednorazowym wyborem. To obszar operacyjny, który stale zmienia się pod wpływem aktualizacji pozyskiwania danych, rewizji modeli, wydań aplikacji źródłowych i nowych konsumentów na dalszych etapach. Model, który był poprawny w zeszłym kwartale, może stać się niestabilny bez formalnego przeprojektowania przez kogokolwiek.

Dotyczy to szczególnie schematu star snowflake w praktycznym sensie mieszanego modelu produkcyjnego.

Wybór schematu to nie koniec pracy

Zespoły często monitorują powodzenie rurociągów danych i koszty hurtowni, ale nie monitorują wystarczająco dokładnie samego modelu. Ta luka objawia się jako dryf schematu (schema drift), cichy dryf dystrybucji w tabelach faktów, późno przybywające wymiary, osierocone klucze obce lub logika biznesowa, która przechodzi pomyślnie pod względem strukturalnym, jednocześnie zawodząc pod kątem analitycznym.

Problem staje się wyraźniejszy w środowiskach hybrydowych. Dyskusja ThoughtSpot na temat złożoności schematów wskazuje, że 40% zespołów analitycznych korzysta obecnie z modeli hybrydowych, aby zrównoważyć szybkość zapytań i przechowywanie danych, podczas gdy główne wytyczne nadal pozostawiają lukę wokół walidacji logiki biznesowej na poziomie rekordów w tych niespójnych strukturach.

Ogólny program Observability dla tych modeli powinien śledzić cztery obszary:

• Zmiany strukturalne: Dodane kolumny, usunięte kolumny i zmiany typów danych w tabelach faktów lub wymiarów.

• Kondycja relacyjna: Uszkodzone klucze obce, brakujące wiersze wymiarów i błędne mapowania hierarchii.

• Dryf zachowania (behavioral drift): Nieoczekiwane przesunięcia w wolumenie, rozkładach wartości lub wzorcach wartości null, nawet gdy schemat się nie zmienił.

• Czas dostarczenia dynamicznego: Spóźnione ładowania, które nie psują kodu SQL, ale niszczą zaufanie do raportów.

Co monitorować w modelach mieszanych

Jedną z praktycznych opcji jest podejście do Data Observability marki digna, szczególnie gdy zespół potrzebuje monitorowania wewnątrz bazy danych w chmurze prywatnej lub środowisku on-premise. Dokumentacja platformy wskazuje, że obliczenia metryk, punkty odniesienia i analiza trendów działają wewnątrz bazy danych klienta bez przenoszenia danych, a funkcja Schema Tracker oznacza zmiany strukturalne, takie jak dodane lub usunięte kolumny i zmiany typów danych w czasie rzeczywistym. Wykrywanie anomalii uczy się normalnego zachowania dla wzorców czasowych i sezonowych oraz potrafi wykryć odchylenia w wolumenach rekordów, dystrybucjach, problemach ze złożonymi kluczami biznesowymi oraz osieroconych rekordach kluczy obcych. Monitorowanie terminowości śledzi również oczekiwane wzorce dostarczania, dzięki czemu opóźnienia są wychwytywane, zanim przeniosą się do raportów.

Ma to znaczenie, ponieważ modele gwiazdy i płatka śniegu ulegają awariom w różny sposób. W projekcie gwiazdy zdenormalizowane wymiary mają tendencję do ukrywania duplikacji i nieaktualnych atrybutów opisowych. W projekcie płatka śniegu ryzyko przenosi się na uszkodzone łańcuchy złączeń, pominięte aktualizacje hierarchii i utajone regresje wydajności. W modelu hybrydowym otrzymujesz obie te klasy awarii.

Nie monitoruj tylko tego, czy tabele się załadowały. Monitoruj, czy model nadal oznacza to, co myślą Twoi użytkownicy.

Przykładowe modele danych i zapytania SQL

Różnica projektowa staje się oczywista po napisaniu kodu SQL dla obu wzorców. Poniżej znajduje się ten sam przypadek użycia sprzedaży zmodelowany na dwa sposoby: całkowita sprzedaż według kategorii produktów i regionu klienta.

Przykład schematu gwiazdy

Model gwiazdy utrzymuje kategorię i region bezpośrednio w wymiarach, z których korzysta już większość analityków.

CREATE TABLE fact_sales (
  sale_id BIGINT,
  date_id INT,
  product_id INT,
  customer_id INT,
  quantity INT,
  revenue NUMERIC(18,2)
);

CREATE TABLE dim_product (
  product_id INT,
  product_name VARCHAR(255),
  category_name VARCHAR(255)
);

CREATE TABLE dim_customer (
  customer_id INT,
  customer_name VARCHAR(255),
  region_name VARCHAR(255)
);

CREATE TABLE dim_date (
  date_id INT,
  calendar_date DATE,
  month_name VARCHAR(20),
  year_num INT
);

CREATE TABLE fact_sales (
  sale_id BIGINT,
  date_id INT,
  product_id INT,
  customer_id INT,
  quantity INT,
  revenue NUMERIC(18,2)
);

CREATE TABLE dim_product (
  product_id INT,
  product_name VARCHAR(255),
  category_name VARCHAR(255)
);

CREATE TABLE dim_customer (
  customer_id INT,
  customer_name VARCHAR(255),
  region_name VARCHAR(255)
);

CREATE TABLE dim_date (
  date_id INT,
  calendar_date DATE,
  month_name VARCHAR(20),
  year_num INT
);

CREATE TABLE fact_sales (
  sale_id BIGINT,
  date_id INT,
  product_id INT,
  customer_id INT,
  quantity INT,
  revenue NUMERIC(18,2)
);

CREATE TABLE dim_product (
  product_id INT,
  product_name VARCHAR(255),
  category_name VARCHAR(255)
);

CREATE TABLE dim_customer (
  customer_id INT,
  customer_name VARCHAR(255),
  region_name VARCHAR(255)
);

CREATE TABLE dim_date (
  date_id INT,
  calendar_date DATE,
  month_name VARCHAR(20),
  year_num INT
);

Zapytanie:

SELECT
  p.category_name,
  c.region_name,
  SUM(f.revenue) AS total_revenue
FROM fact_sales f
JOIN dim_product p
  ON f.product_id = p.product_id
JOIN dim_customer c
  ON f.customer_id = c.customer_id
GROUP BY
  p.category_name,
  c.region_name
ORDER BY
  total_revenue DESC;

SELECT
  p.category_name,
  c.region_name,
  SUM(f.revenue) AS total_revenue
FROM fact_sales f
JOIN dim_product p
  ON f.product_id = p.product_id
JOIN dim_customer c
  ON f.customer_id = c.customer_id
GROUP BY
  p.category_name,
  c.region_name
ORDER BY
  total_revenue DESC;

SELECT
  p.category_name,
  c.region_name,
  SUM(f.revenue) AS total_revenue
FROM fact_sales f
JOIN dim_product p
  ON f.product_id = p.product_id
JOIN dim_customer c
  ON f.customer_id = c.customer_id
GROUP BY
  p.category_name,
  c.region_name
ORDER BY
  total_revenue DESC;

To zapytanie jest krótkie, czytelne i trudne do błędnego użycia. W przypadku większości obciążeń BI o to właśnie chodzi.

Przykład schematu płatka śniegu

Model płatka śniegu przenosi kategorię i region do znormalizowanych tabel hierarchii.

CREATE TABLE fact_sales (
  sale_id BIGINT,
  date_id INT,
  product_id INT,
  customer_id INT,
  quantity INT,
  revenue NUMERIC(18,2)
);

CREATE TABLE dim_product (
  product_id INT,
  product_name VARCHAR(255),
  category_id INT
);

CREATE TABLE dim_category (
  category_id INT,
  category_name VARCHAR(255)
);

CREATE TABLE dim_customer (
  customer_id INT,
  customer_name VARCHAR(255),
  region_id INT
);

CREATE TABLE dim_region (
  region_id INT,
  region_name VARCHAR(255)
);

CREATE TABLE dim_date (
  date_id INT,
  calendar_date DATE,
  month_name VARCHAR(20),
  year_num INT
);

CREATE TABLE fact_sales (
  sale_id BIGINT,
  date_id INT,
  product_id INT,
  customer_id INT,
  quantity INT,
  revenue NUMERIC(18,2)
);

CREATE TABLE dim_product (
  product_id INT,
  product_name VARCHAR(255),
  category_id INT
);

CREATE TABLE dim_category (
  category_id INT,
  category_name VARCHAR(255)
);

CREATE TABLE dim_customer (
  customer_id INT,
  customer_name VARCHAR(255),
  region_id INT
);

CREATE TABLE dim_region (
  region_id INT,
  region_name VARCHAR(255)
);

CREATE TABLE dim_date (
  date_id INT,
  calendar_date DATE,
  month_name VARCHAR(20),
  year_num INT
);

CREATE TABLE fact_sales (
  sale_id BIGINT,
  date_id INT,
  product_id INT,
  customer_id INT,
  quantity INT,
  revenue NUMERIC(18,2)
);

CREATE TABLE dim_product (
  product_id INT,
  product_name VARCHAR(255),
  category_id INT
);

CREATE TABLE dim_category (
  category_id INT,
  category_name VARCHAR(255)
);

CREATE TABLE dim_customer (
  customer_id INT,
  customer_name VARCHAR(255),
  region_id INT
);

CREATE TABLE dim_region (
  region_id INT,
  region_name VARCHAR(255)
);

CREATE TABLE dim_date (
  date_id INT,
  calendar_date DATE,
  month_name VARCHAR(20),
  year_num INT
);

Zapytanie:

SELECT
  cat.category_name,
  r.region_name,
  SUM(f.revenue) AS total_revenue
FROM fact_sales f
JOIN dim_product p
  ON f.product_id = p.product_id
JOIN dim_category cat
  ON p.category_id = cat.category_id
JOIN dim_customer c
  ON f.customer_id = c.customer_id
JOIN dim_region r
  ON c.region_id = r.region_id
GROUP BY
  cat.category_name,
  r.region_name
ORDER BY
  total_revenue DESC;

SELECT
  cat.category_name,
  r.region_name,
  SUM(f.revenue) AS total_revenue
FROM fact_sales f
JOIN dim_product p
  ON f.product_id = p.product_id
JOIN dim_category cat
  ON p.category_id = cat.category_id
JOIN dim_customer c
  ON f.customer_id = c.customer_id
JOIN dim_region r
  ON c.region_id = r.region_id
GROUP BY
  cat.category_name,
  r.region_name
ORDER BY
  total_revenue DESC;

SELECT
  cat.category_name,
  r.region_name,
  SUM(f.revenue) AS total_revenue
FROM fact_sales f
JOIN dim_product p
  ON f.product_id = p.product_id
JOIN dim_category cat
  ON p.category_id = cat.category_id
JOIN dim_customer c
  ON f.customer_id = c.customer_id
JOIN dim_region r
  ON c.region_id = r.region_id
GROUP BY
  cat.category_name,
  r.region_name
ORDER BY
  total_revenue DESC;

Dodatkowe złączenia nie są katastrofalne. Po prostu się kumulują. Jedno lub dwa są łatwe do opanowania. Głębsza hierarchia obejmująca kilka wymiarów staje się trudniejsza do utrzymania, wyjaśnienia i optymalizacji.

W praktyce właśnie to sprawia, że wiele zespołów decyduje się na selektywną hybrydę. Utrzymują wymiary, z którymi analitycy stykają się stale, w formie przypominającej gwiazdę, i normalizują te wymiary, które wymagają silniejszej kontroli.

Jeśli Twoja hurtownia już miesza płaskie i znormalizowane wymiary, trudność nie polega na nazewnictwie wzorca. Chodzi o utrzymanie wiarygodności modelu w miarę zmian struktur i zachowania danych. digna to jedna z opcji dla zespołów, które potrzebują śledzenia schematów, wykrywania anomalii, monitorowania terminowości i walidacji na poziomie rekordów w swoim własnym środowisku bazy danych, bez przenoszenia danych produkcyjnych poza swój obszar kontroli.