Hvězdné schéma vs. schéma sněhové vločky

V předchozích dvou článcích jsme zvažovali dva nejběžnější modely datových skladů:hvězdné schéma a schéma sněhové vločky. Dnes prozkoumáme rozdíly mezi těmito dvěma schématy a vysvětlíme, kdy je lepší použít jedno nebo druhé.

Hvězdicové schéma a schéma sněhové vločky jsou způsoby, jak organizovat datové tržiště nebo celé datové sklady pomocí relačních databází. Oba používají tabulky rozměrů k popisu dat agregovaných v tabulce faktů .

Každý něco prodává, ať už jde o znalosti, produkt nebo službu. Potřeba je také ukládání těchto informací, ať už v operačním systému nebo v systému hlášení. Můžeme tedy očekávat, že v datovém skladu téměř každé společnosti najdeme nějaký typ prodejního modelu.

Podívejme se ještě jednou na model prodeje ve schématech hvězd a sněhových vloček.

Hvězdné schéma

Nejviditelnější charakteristikou hvězdicového schématu je, že tabulky rozměrů nejsou normalizovány. Ve výše uvedeném modelu je růžový fact_sales tabulka ukládá agregovaná data vytvořená z našich provozních databází. Světle modré tabulky jsou tabulky rozměrů. Rozhodli jsme se použít těchto pět dimenzí, protože potřebujeme vytvářet sestavy, které je používají jako parametry. Zrnitost uvnitř každé dimenze je také určena našimi potřebami vytváření přehledů.

Z tohoto modelu snadno pochopíme, proč se tomuto schématu říká „hvězdné schéma“:vypadá jako hvězda, přičemž tabulky dimenzí obklopují centrální tabulku faktů.

Schéma sněhových vloček

Toto schéma sněhové vločky ukládá přesně stejná data jako schéma hvězdy. Tabulka faktů má stejné rozměry jako v příkladu hvězdného schématu. Nejdůležitější rozdíl je v tom, že tabulky rozměrů ve schématu sněhových vloček jsou normalizovány. Je zajímavé, že proces normalizace tabulek rozměrů se nazývá sněhové vločky.

Ještě jednou, vizuálně nám schéma sněhové vločky připomíná svého jmenovce s několika vrstvami tabulek rozměrů vytvářejících nepravidelný tvar připomínající sněhovou vločku.

První rozdíl:Normalizace

Jak již bylo zmíněno, normalizace je klíčovým rozdílem mezi schématy hvězd a sněhových vloček. V této souvislosti je třeba vědět několik věcí:

• Schémata sněhových vloček zaberou méně místa k uložení tabulek dimenzí. Je to proto, že jakákoli normalizovaná databáze zpravidla produkuje mnohem méně nadbytečných záznamů.
• Denormalizované datové modely zvyšují pravděpodobnost problémů s integritou dat. Tyto problémy také zkomplikují budoucí úpravy a údržbu.
• Zkušeným datovým modelářům se schéma sněhových vloček zdá logičtější než schéma hvězdy. (Toto je můj osobní názor, nikoli tvrdý fakt. :) )

Pojďme k druhému hlavnímu rozdílu mezi těmito dvěma schématy.

Druhý rozdíl:Složitost dotazu

V našich prvních dvou článcích jsme demonstrovali dotaz, který lze použít na prodejní model k získání množství všech produktů typu telefon prodaných v berlínských obchodech v roce 2016.

Dotaz na hvězdicové schéma vypadá takto:

SELECT 
  dim_store.store_address,
  SUM(fact_sales.quantity) AS quantity_sold

FROM 
  fact_sales
  INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id

WHERE 
  dim_time.action_year = 2016
  AND dim_store.city = 'Berlin'
  AND dim_product.product_type = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

Abychom získali stejný výsledek ze schématu sněhové vločky, musíme použít tento dotaz:

SELECT 
  dim_store.store_address,
  SUM(fact_sales.quantity) AS quantity_sold

FROM 
  fact_sales
  INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
  INNER JOIN dim_product_type ON dim_product.product_type_id = dim_product_type.product_type_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_year ON dim_time.year_id = dim_year.year_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id
  INNER JOIN dim_city ON dim_store.city_id = dim_city.city_id

WHERE 
  dim_year.action_year = 2016
  AND dim_city.city = 'Berlin'
  AND dim_product_type.product_type_name = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

Je zřejmé, že dotaz na schéma sněhové vločky je složitější. Protože tabulky dimenzí jsou normalizované, musíme sáhnout hlouběji, abychom získali název typu produktu a město. Pro každou novou úroveň ve stejné dimenzi musíme přidat další JOIN.

Ve hvězdicovém schématu spojujeme tabulku faktů pouze s těmi tabulkami dimenzí, které potřebujeme. Maximálně budeme mít pouze jeden JOIN na tabulku dimenzí. A pokud nepoužíváme tabulku rozměrů, nemusíme se s ní ani obtěžovat. V dotazu na schéma sněhové vločky nevíme, jak hluboko budeme muset jít, abychom získali správnou úroveň dimenze, takže to komplikuje proces psaní dotazů.

Spojení dvou stolů nějakou dobu trvá, protože zpracování požadavku trvá DMBS déle. dim_store a dim_city tabulky jsou v našem modelu umístěny v těsné blízkosti, ale na disku nemusí být umístěny nikde blízko sebe. Je větší pravděpodobnost, že data budou na disku fyzicky blíže, pokud budou uložena ve stejné tabulce.

V zásadě se dotaz spuštěný proti datovému trhu schématu sněhových vloček bude provádět pomaleji. Ale ve většině případů to nebude představovat problém:nezáleží na tom, jestli výsledek dostaneme za jednu milisekundu nebo jednu sekundu.

Urychlení

Pro urychlení hlášení můžeme:

• Agregovat data na úroveň, kterou potřebujeme v přehledech. Tím dojde k výrazné komprimaci dat. Budeme muset vytvořit postupy, které transformují naše živá data, aby zapadla do struktury schématu vykazování (proces ETL).
• Vybudujte centrální úložiště pro všechny agregované údaje společnosti, nejen údaje o prodeji.
• Poskytujte uživatelům pouze data, která potřebují pro analýzu a sestavy.

Sněhová vločka vs. schémata hvězd:Které byste měli použít?

Nyní, když jsme se podívali na teorii a rychlost dotazů, pojďme přímo k jádru věci:jak víte, které schéma použít v daném projektu?

Zvažte použití schéma sněhových vloček :

• V datových skladech. Protože je sklad pro společnost Data Central, mohli bychom tímto způsobem ušetřit spoustu místa.
• Když tabulky dimenzí vyžadují značné množství úložného prostoru. Ve většině případů budou tabulky faktů ty, které zaberou většinu místa. Pravděpodobně také porostou mnohem rychleji než tabulky dimenzí. Ale jsou určité situace, kdy to neplatí. Například tabulky dimenzí mohou obsahovat mnoho nadbytečných, ale potřebných atributů. V našem příkladu jsme použili město atribut popisující město, kde se obchod nachází. Co kdybychom chtěli mnohem podrobnější popis města včetně počtu obyvatel, PSČ, demografických údajů atd.? Popis dalších poddimenzí – například obchod , region , stát a země – s více atributy by se změnilo dim_store rozměrovou tabulku do jedné velké tabulky s velkým množstvím redundance.
• Pokud používáte nástroje, které vyžadují na pozadí schéma sněhové vločky. (Naštěstí většina moderních nástrojů podporuje jak schémata, tak i schéma galaxie.)

Zvažte použití hvězdičkového schématu :

• V data marketech. Datové tržiště jsou podmnožiny dat odebraných z centrálního datového skladu. Obvykle jsou vytvořeny pro různá oddělení a neobsahují ani všechna historická data. V tomto nastavení není úspora úložného prostoru prioritou.

  Na druhou stranu hvězdné schéma analýzu zjednodušuje. Nejde jen o efektivitu dotazů, ale také o zjednodušení budoucích akcí pro podnikové uživatele. Možná rozumí databázím a vědí, jak psát dotazy, ale proč věci komplikovat a zahrnout více spojení, když se tomu můžeme vyhnout? Obchodní uživatel by mohl mít šablonový dotaz, který spojuje tabulku faktů se všemi tabulkami dimenzí. Poté stačí přidat příslušné výběry a seskupení. (Tento přístup je blízký kontingenčním tabulkám Excelu.)

• Pokud používáte nástroje, které vyžadují hvězdicové schéma na pozadí. (Opět to obvykle není problém.)

Jak schéma hvězdy, tak schéma sněhové vločky jsou relační modely používané k organizaci datových skladů a/nebo datových tržišť. Bez ohledu na to, jak jsou podobné, demonstrují dva různé přístupy a mají své výhody a nevýhody. Osobně bych při implementaci datového skladu zvolil schéma sněhové vločky (pro úsporu místa v úložišti) a hvězdicové schéma pro datové tržiště (pro usnadnění života podnikovým uživatelům).