Schéma sněhové vločky je normalizované hvězdicové schéma, jsou zde normalizovány tabulky dimenzí. Ve schématu jsou dimenze uspořádány v hierarchiích.[1]
Pokud jsou tabulky nakresleny s tabulkou faktů ve středu a související tabulky dimenzí vedle sebe, následný obrázek vypadá jako sněhová vločka. Z toho plyne název Schéma sněhové vločky.[2]
Každé schéma sněhové vločky má vždy entitu faktu. Jeden datový sklad se může skládat z několika entit faktů, a tedy i z více hvězdicových schémat a/nebo sněhových vloček. Jeden datový model může obsahovat více tabulek faktů, a tedy i více hvězdicových schémat. Jednotlivé tabulky dimenze mohou také ukazovat na více tabulek faktů.[3]
Schémata sněhových vloček popisují stejné typy datových modelů jako hvězdicová schémata, s tím rozdílem, že jsou normalizovaná. Normalizace může být částečná nebo úplná podle pravidel třetí normalizační podoby.[4]
Schéma 3. normální formy je v podstatě transakční nebo OLTP struktura, která zajišťuje malé množství vysoce souběžně přístupných (sdílených) datových struktur. Na rozdíl od schémat hvězdic a vločky jsou schémata 3. normální formy pro datové sklady obecně neúčinná a pokud je to možné, je nejlepší se jim vyhnout.[3]
Schéma sněhové vločky má centrální tabulku faktů a tabulky dimenzí. Pro každou dimenzi a její další úroveň obsahuje další tabulky dimenzí. To znamená, že nedojde k redundanci dat, což může být v některých situacích výhodné. Hierarchie jsou tedy v dimenzích explicitně vyjádřeny.[2]
Tabulky dimenzí obsahují primární klíč a sloupec obsahující textové popisy hodnot úrovní, případně další sloupce pro charakteristiku vlastností dané úrovně. Tabulky pro nižší úrovně dále obsahují cizí klíč k úrovni vyšší.[2]
U dimenzí ve schématu sněhové vločky je hierarchie tvořena řetězcem provázaných tabulek kardinalitou 1:N. Redundance dat je tímto snížena a můžeme hovořit o normalizované struktuře.[5]
Ve schématu databáze je znázorněn model pro záznam dat ze sklizní pro zemědělský podnik. V tabulce FA_Sklizeno se uchovávají záznamy o sklizních. Konkrétně záznamy o počtu sklizených tun a výměře sekání. Dále jsou zde hodnoty cizích klíčů pro dimenze DIM_Cas, DIM_Pole, DIM_Plodina. DIM_Cas je časová dimenze; jedná se o speciální dimenzi generovanou nejčastěji automaticky. Pro tuto dimenzi není v praxi obvyklé, aby se například jednotlivé dny, nebo měsíce umísťovaly do dimenzí vyšších úrovní. Pro DIM_Pole, DIM_Plodina jsou přes cizí klíč propojeny s dimenzemi vyšší úrovně.
Bylo náhodně vygenerováno 500 záznamů pro dimenzi DIM_Pole a DIM_Plodina. Z těchto záznamů byly vyselektovány jedinečné záznamy a byly umístěny do dimenzí vyšší úrovně: Pro dimenzi DIM_Odruda 93 a pro dimenzi DIM_Katastr 131. V tabulce faktů FA_Sklizeno bylo vygenerováno 500 000 záznamů.
FA_Sklizeno | DIM_Cas | DIM_Pole | DIM_Plodina | DIM_Odruda | DIM_Katastr | |
---|---|---|---|---|---|---|
Počet záznamů | 500 000 | 1 000 | 500 | 500 | 131 | 93 |
Naplněné schéma bylo vloženo do modelu aplikace Power BI Desktop. Následně byl vytvořen jednoduchý vizuál, do kterého byla zadána data pro: součet hodnot sklizní, názvů odrůd a katastrů. Vizuál byl vyfiltrován rokem z časové dimenze. Poté byl spuštěn Analyzátor výkonu a byla provedena aktualizace vizuálu 10x za sebou.
Časové jednotky v řádku pro Dotaz DAX v Analyzátor výkonu znamenají: „Pokud byl požadován dotaz DAX, jedná se o čas mezi tím, kdy vizuál odešle dotaz, a okamžikem, kdy služba Analysis Services vrátí výsledky.“[6]
Hvězdicové schéma | Schéma sněhové vločky | |||||
---|---|---|---|---|---|---|
Minimální hodnota |
Maximální hodnota |
Průměrná hodnota |
Minimální hodnota |
Maximální hodnota |
Průměrná hodnota |
Rozdíl průměrů |
8ms | 10ms | 9ms | 13ms | 14ms | 13ms | 4ms |
I pro hvězdicové schéma bylo použito stejné množství dat, s tím rozdílem, že u hvězdy nebyla data transponována do vyšších úrovní. Při porovnání dat z tabulek pro obě schémata a jejich rozdílu, je patrné, že hvězdicové schéma dosahuje lepšího výkonu než schéma sněhové vločky. Je nutné brát v potaz, že množství dat v tomto příkladu je zanedbatelné oproti reálným datům. Proto je nutné obzvlášť dbát na architekturu datového modelu, aby byly dotazy vykonávány v co nejkratším čase.