Star vs Snowflake schema: Jak modelovat datový sklad

Co je dimenzionální modelování

Dimenzionální modelování je metoda návrhu datového skladu, kterou v 90. letech zpopularizoval Ralph Kimball. Data dělí na dvě role: faktové tabulky (měřitelné události — objednávky, kliky, transakce) a dimenzionální tabulky (kontext — zákazník, produkt, čas).

Cílem je optimalizovat pro analytické dotazy a snadné porozumění. Místo desítek normalizovaných tabulek máte málo tabulek s jasným významem — typicky 1 fakt obklopený 5–15 dimenzemi. Konkrétní organizace dimenzí pak rozlišuje star od snowflake schématu.

Star schema

Star schema je nejjednodušší varianta: faktová tabulka uprostřed a kolem ní plně denormalizované dimenze. Každá dimenze je jedna tabulka, která obsahuje všechny atributy včetně hierarchií.

Příklad: dim_product obsahuje sloupce product_id, product_name, category, subcategory, brand, supplier_name — všechno v jedné tabulce. Joiny v dotazech jsou jednoduché (1 fakt ↔ N dimenzí) a query plan je předvídatelný.

Star je výchozí volba pro BI a reporting. Power BI, Tableau, Looker — všechny preferují star, protože jejich engine je na něj optimalizovaný a analytici se v něm rychle zorientují.

Snowflake schema

Snowflake schema (nesouvisí s platformou Snowflake) jde o krok dál — dimenze normalizuje do více tabulek podle hierarchií. Z dim_product se stane dim_product → dim_category → dim_department a dim_product → dim_brand → dim_supplier.

Výsledné schéma připomíná sněhovou vločku — odtud název. Storage je menší (žádná duplikace hierarchií), zato dotazy potřebují víc joinů a query plan se komplikuje.

V praxi se snowflake schema dnes používá vzácněji — typicky tam, kde dimenze mají skutečně složité hierarchie (organizační struktura nadnárodní firmy, geografické členění s desítkami úrovní) nebo kde se používá master data management.

Srovnávací tabulka

Klíčové rozdíly mezi star a snowflake schématem v jednom přehledu.

Kdy zvolit star schema

Star je výchozí volba pro většinu projektů. Konkrétně ho zvolte, pokud:

• Hlavním use case je BI a dashboarding (Power BI, Tableau, Looker).
• Chcete maximální výkon dotazů na sloupcových enginech (Snowflake, BigQuery, Redshift).
• Analytici si data modelují sami a oceníte snadno pochopitelné schéma.
• Storage není primární náklad — moderní cloud DW účtuje hlavně za compute.

Kdy zvolit snowflake schema

Snowflake schema má smysl ve specifických případech:

• Dimenze mají skutečně hluboké hierarchie (5+ úrovní), které se nezávisle udržují.
• Pracujete v on-premise prostředí, kde je storage nákladný (klasické SQL Server, Oracle).
• Máte MDM proces, který udržuje samostatné dimenzionální tabulky jako zdroj pravdy.
• Regulace vyžaduje referenční integritu a explicitní normalizaci.

V kontextu moderního stacku

V éře sloupcových databází jako Snowflake nebo BigQuery argument pro snowflake schema kvůli storage prakticky vymizel. Komprese sloupcových formátů eliminuje duplikaci hierarchií a compute náklady jsou drahší než storage. Praktický doporučovaný přístup: stavte všechno jako star, snowflake nasaďte jen tam, kde to dává byznysový smysl.

V dbt typicky držíme staging vrstvu normalizovanou (1:1 mapování zdrojových systémů) a mart vrstvu jako čisté star schéma. To dává nejlepší kompromis mezi udržovatelností a výkonem. Pro konkrétní návrh datového modelu na váš use case si u nás můžete domluvit audit zdarma.

Praktický příklad: e-commerce model objednávek

Představte si datový sklad e-shopu sledující online objednávky. Ve star schématu postavíte jednu faktovou tabulku fct_orders s cizími klíči na dim_customer, dim_product, dim_date, dim_store a dim_promotion. Každá dimenze je široká a soběstačná: dim_product nese product_id, sku, name, category, subcategory, brand, supplier, country_of_origin a unit_cost v jednom řádku. Typický dotaz na tržby podle kategorie spojí fct_orders s dim_product přes product_id a seskupí podle category — jeden join, předvídatelný scan, rychlý i nad miliardami řádků.

Snowflake varianta rozdělí dim_product na dim_product (product_id, sku, name, brand_id, category_id, supplier_id) plus dim_brand, dim_category, dim_supplier a dim_country. Stejný dotaz teď spojuje fct_orders → dim_product → dim_category, tedy dva joiny na řádek faktu. Storage klesne, protože názvy značek a kategorií jsou uloženy jednou, ale SQL je delší a analytici, kteří model neznají, snadno zvolí špatnou cestu spojení.

V praxi moderní týmy drží snowflake dekompozici ve staging vrstvě (aby se změny pojmenování značek či kategorií šířily čistě) a do BI nástroje publikují denormalizovanou hvězdu. Nejlepší z obou světů a žádné runtime joiny na straně konzumenta.

Výkon a náklady v moderním cloud DW

Na sloupcových enginech jako Snowflake, BigQuery a Redshift je cena dotazu dominantně daná naskenovanými bajty a sekundami compute, ne počtem řádků nebo šířkou tabulky. Star schéma je obvykle levnější, protože optimalizér broadcastuje malé dimenze a faktovou tabulku skenuje s efektivním predicate pushdown. Snowflake schéma vynucuje více shuffle fází nad velkými fakty, což pro stejnou odpověď dokáže zdvojnásobit warehouse seconds.

Běžný benchmark, který u klientů spouštíme: 2 miliardy řádků faktové tabulky spojené s pěti dimenzemi vrátí agregaci na úrovni kategorie zhruba za 3 sekundy na Snowflake Medium warehouse se star schématem a kolem 7 sekund s ekvivalentním snowflake modelem. Při soustavném provozu to znamená přibližně 2× kredity za stejný dashboard.

Úspora storage z normalizace je na sloupcových enginech díky dictionary encoding a Zstandard kompresi obvykle pod 5 %. Pokud nemáte gigabajtové dimenze dotazované jen zřídka, optimalizovat storage snowflakováním je falešná úspora.

Časté chyby a best practices

Ať zvolíte kterýkoli model, několik pastí trefuje týmy opakovaně:

• Použití přirozených klíčů (email, sku) jako primárních klíčů v dimenzích — rozbíjí historii SCD2 a zpomaluje joiny. Vždy přidělte surrogate celočíselný klíč.
• Vkládání metrik do dimenzí (např. customer_lifetime_value na dim_customer) — okamžitě zastarají. Míry počítejte ve faktové vrstvě nebo v BI nástroji.
• Míchání zrnitostí v jedné faktové tabulce — objednávky a položky objednávek tam nepatří spolu. Stavte fct_orders a fct_order_items jako oddělené fakty se sdílenými konformovanými dimenzemi.
• Snowflakování jen jedné dimenze z deseti — nekonzistentní styl mate analytiky a přínos pro storage je minimální. Zvolte konvenci pro každý data mart a držte ji.

Zvolený přístup zdokumentujte v krátkém modelovacím guideu a procházejte ho s novými lidmi při onboardingu. Konzistentní a dobře vysvětlené star schéma vždy přebije chytré, ale nedokumentované snowflake.

Historizace dimenzí: SCD typ 1, 2 a 6

Atributy v dimenzích se v čase mění — zákazník se přestěhuje, produkt změní kategorii, obchodník přejde do jiného regionu. Kimballova metodika definuje slowly changing dimensions (SCD) jako vzorec pro tyto změny. SCD typ 1 atribut přepíše bez historie (jednoduché, ale ztrácíte schopnost reportovat „jaká byla kategorie v Q1?"). SCD typ 2 vloží novou verzi řádku s valid_from / valid_to a is_current flagem — fact tabulka pak joinuje na surrogate key dimenze platný v okamžiku události. SCD typ 6 kombinuje oba přístupy: drží current i historickou hodnotu vedle sebe pro situace, kdy chcete oboje.

V moderním stacku se SCD typ 2 typicky generuje pomocí dbt snapshotů (dbt snapshot), Dagster asset-based pipeline nebo přímo MERGE statementem ve Snowflake/BigQuery. Pozor na surrogate key: nikdy nepoužívejte natural key (např. customer_id) jako primární klíč dimenze, vždy vygenerujte hash nebo sequence — jinak při změně atributu zlomíte vazbu na historické fakty.

Star i snowflake schema podporují všechny typy SCD, ale ve snowflake schématu je SCD typ 2 dražší — musíte verzionovat i pomocné dimenze (např. product_category), což vede k explozi řádků a složitějším joinům. To je další důvod, proč pro reportingové marty preferujeme denormalizovaný star — historizace je čistší a dotazy zůstávají rychlé.

Governance, data contracts a dbt testy

Dimenzionální model je smlouvou mezi datovým týmem a businessem — definuje, co znamená „zákazník", „objednávka" nebo „revenue". Bez governance se tato smlouva rychle rozpadá: každý analytik si vyrobí vlastní dim_customer_v2, metriky se rozcházejí mezi nástroji a důvěra v reporty klesá. Data contracts formalizují schéma, owners, SLA a povolené breaking changes — typicky v YAML manifestu kontrolovaném v CI.

V dbt projektu doporučujeme minimum: unique a not_null testy na primárních klíčích dimenzí, relationships testy na cizích klíčích z faktů, accepted_values na statusech a kategoriích a dbt-expectations pro statistické checky (row count delta, distribuce). Tyto testy běží v CI před každým merge a v produkci jako součást orchestrace — Dagster nebo Airflow je spouští jako asset checks po každé materializaci.

Pro enterprise nasazení doplňujeme semantic layer (dbt Semantic Layer, Cube, AtScale nebo LookML), který drží metriky definované jednou a konzumované všemi BI nástroji. Tím odpadne klasický problém „tři dashboardy, tři čísla pro stejnou metriku". V kombinaci se server-side data quality frameworkem (Great Expectations, Soda) získáte plnou pozorovatelnost modelu — od schema driftu po anomálie v hodnotách. Detaily nasazení rádi probereme v rámci bezplatného 30minutového auditu.

Časté dotazy