Hvězdné schéma

Dnes jsou reporty a analýzy téměř stejně důležité jako hlavní byznys. Z vašich aktuálních dat lze vytvářet sestavy; tento přístup často postačí pro malé a střední společnosti bez velkého množství dat. Ale když se věci zvětší – nebo se množství dat začne dramaticky zvyšovat – je čas přemýšlet o oddělení vašich provozních a reportovacích systémů.

Než se pustíme do základního datového modelování, potřebujeme nějaké znalosti o příslušných systémech. Systémy můžeme zhruba rozdělit do dvou kategorií:operační a reportovací systémy. Operační systémy se často nazývají Online Transaction Processing (OLTP). Vykazovací a analytické systémy se označují jako Online Analytical Processing (OLAP). Systémy OLTP podporují obchodní procesy. Pracují s „živými“ provozními daty, jsou vysoce normalizované a velmi rychle reagují na akce uživatele. Na druhou stranu je primárním účelem systémů OLAP analytika. Tyto systémy používají souhrnná data, která jsou obvykle umístěna v denormalizované struktuře datového skladu, jako je hvězdné schéma. (Co je denormalizace? Jednoduše řečeno, má redundantní datové záznamy kvůli lepšímu výkonu. Přečtěte si více.)

Nyní, když víme něco o systémech, začněme zkoumat datový sklad a jeho části a procesy.

Datové sklady vs. Data Marts

Datový sklad (DWH) je systém používaný k ukládání informací pro použití při analýze dat a reportování. Datové tržiště jsou oblasti datových skladů používané k ukládání informací potřebných pro jedno oddělení nebo dokonce pro jednotlivého uživatele. (Představte si DWH jako budovu a datové tržiště jako kanceláře uvnitř budovy.)

Proč jsou potřeba datové obchody? Všechna relevantní data jsou uložena uvnitř společnosti DWH. Většina uživatelů však potřebuje přístup pouze k určitým podmnožinám dat, jako jsou údaje týkající se prodeje, výroby, logistiky nebo marketingu. Datové tržiště jsou důležité jak z hlediska zabezpečení (omezení zbytečného přístupu), tak z hlediska uživatele (nechceme je plést ani je nutit brodit se cizími daty).

Existují dva různé přístupy ke vztahu datového skladu a datového trhu:

Shora dolů :Datové tržiště se vytvářejí z datového skladu. (To je něco, s čím by souhlasil Bill Inmon, „otec datového skladu“, spolu s myšlenkou, že sklady by měly být v 3NF.)
zdola nahoru :Datové tržiště jsou nejprve vytvořeny a poté spojeny do datového skladu. (Tento přístup je bližší tomu, co obhajuje Ralph Kimball, odborník na datové sklady a dimenzionální modelování.)

Proces ETL se používá k pravidelnému přidávání „nových“ dat do systému OLAP. ETL je zkratka pro Extrahovat, Transformovat a Načíst. Jak název napovídá, extrahujeme data z jedné nebo více provozních databází, transformujeme je tak, aby odpovídala struktuře našeho skladu, a načteme data do DWH.

Rozměrové modelování , který je součástí návrhu datového skladu, vede k vytvoření rozměrového modelu. Jedná se o dva typy tabulek:

Tabulky dimenzí se používají k popisu dat, která chceme uložit. Například:maloobchodník může chtít uložit datum, obchod a zaměstnance zapojené do konkrétního nákupu. Každá tabulka dimenzí má svou vlastní kategorii (datum, zaměstnanec, obchod) a může mít jeden nebo více atributů . U každé prodejny můžeme uložit její polohu na úrovni města, regionu, státu a země. Ke každému datu můžeme uložit rok, měsíc, den v měsíci, den v týdnu atd. S tím souvisí hierarchie atributů v tabulce dimenzí.

Ve hvězdicovém schématu obvykle zjistíme, že některé atributy jsou podmnožinou jiných atributů ve stejném záznamu. Tato redundance je záměrná a provádí se ve jménu lepšího výkonu. K agregaci (transformační část procesu ETL) a uložení dat v DWH bychom mohli použít dimenze data, umístění a obchodního zástupce. Při rozměrovém modelování je velmi důležité definovat správné rozměry a zvolit správnou granulaci.
Tabulky faktů obsahovat data, která chceme zahrnout do přehledů, agregovaná na základě hodnot v souvisejících tabulkách dimenzí. Tabulka faktů má pouze sloupce, které ukládají hodnoty a cizí klíče odkazující na tabulky dimenzí. Kombinace všech cizích klíčů tvoří primární klíč tabulky faktů. Například tabulka faktů může ukládat počet kontaktů a počet prodejů vyplývajících z těchto kontaktů.

S těmito informacemi se nyní můžeme ponořit do datového modelu hvězdného schématu.

Hvězdné schéma

Hvězdové schéma je nejjednodušší model používaný v DWH. Protože tabulka faktů je ve středu schématu s tabulkami dimenzí kolem ní, vypadá zhruba jako hvězda. To je zvláště patrné, když je tabulka faktů obklopena pěti tabulkami dimenzí. Varianta hvězdného schématu schéma stonožky , kde je tabulka faktů obklopena velkým počtem tabulek malých rozměrů.

Hvězdná schémata se velmi běžně používají v datových tržištích. Můžeme je dát do souvislosti s přístupem k datovému modelu shora dolů. Budeme analyzovat dvě hvězdná schémata (datové trhy) a poté je zkombinujeme, abychom vytvořili jeden model.

Příklad hvězdicového schématu:Prodej

Zpráva o prodeji je dnes jednou z nejběžnějších zpráv. Jak jsme již zmínili, ve většině případů jsme mohli generovat zprávy o prodeji z živého systému. Ale když je to kvůli datům nebo velikosti firmy příliš těžkopádné, budeme muset vybudovat datový sklad nebo datový trh, abychom proces zefektivnili. Po navržení našeho hvězdného schématu ETL proces získá data z provozních databází, transformuje data do správného formátu pro DWH a načte data do skladu.

Výše uvedený model obsahuje jednu tabulku faktů (světle červená) a pět dimenzí (světle modrá). Tabulky v modelu jsou:

fact_sales – Tato tabulka obsahuje odkazy na tabulky rozměrů a dvě skutečnosti (cena a prodané množství). Všimněte si, že všech pět cizích klíčů dohromady tvoří primární klíč tabulky.
dim_sales_type – Toto je tabulka dimenzí typu prodeje s pouze jedním atributem „type_name “.
dim_employee – Toto je tabulka dimenzí zaměstnanců, která ukládá základní atributy zaměstnanců:celé jméno a rok narození.
dim_product – Toto je tabulka dimenzí produktu s pouze dvěma atributy (jinými než primární klíč):název produktu a typ produktu.
dim_time – Tato tabulka zpracovává časovou dimenzi. Kromě primárního klíče obsahuje pět atributů. Údaje na nejnižší úrovni jsou prodeje podle data (action_date ). action_week atribut je číslo týdne v daném roce (tj. první týden v lednu by dostal číslo 1; poslední týden v prosinci by dostal číslo 52 atd.) actual_month a actual_year atributy ukládají kalendářní měsíc a rok, kdy k prodeji došlo. Ty lze získat z action_date atribut. action_weekday atribut ukládá název dne, kdy se prodej uskutečnil.
dim_store – Toto je rozměr obchodu. U každého obchodu uložíme město, region, stát a zemi, kde se nachází. Zde si můžeme jasně všimnout, že hvězdné schéma je denormalizované.

Příklad hvězdicového schématu:Objednávky dodávek

Mezi tímto modelem uvedeným níže a modelem prodeje je mnoho podobností.

Tento model je určen k ukládání historie zadaných objednávek. Máme jednu tabulku faktů a čtyři tabulky dimenzí. Tabulky dimenzí dim_employee , dim_product a dim_time jsou úplně stejné jako v prodejním modelu. Následující tabulky se však liší:

fact_supply_order – obsahuje agregované údaje o zadaných objednávkách.
dim_supplier – je tabulka dimenzí, která ukládá dodavatelská data stejným způsobem jako dim_store uchovávala data obchodu v prodejním modelu.

Výhody a nevýhody hvězdného schématu

Použití hvězdicového schématu má spoustu výhod. Tabulka faktů souvisí s každou tabulkou dimenzí přesně jedním vztahem a k popisu tabulek dimenzí nepotřebujeme žádné další slovníky. To zjednodušuje dotazy a zkracuje dobu provádění dotazu. Mohli bychom vytvořit stejnou zprávu přímo z našeho systému OLTP, ale dotaz by byl mnohem složitější a mohl by ovlivnit celkový výkon systému. Následující ukázkový dotaz pro model prodeje vrátí množství všech produktů typu telefon prodaných v berlínských obchodech v roce 2016:

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

Největší nevýhodou hvězdicového schématu je redundance. Každá dimenze je uložena v samostatné tabulce dimenzí, což způsobuje denormalizaci. V našem příkladu město patří do regionu nebo státu, který patří zemi; tento vztah zpravidla neukládáme do naší databáze, ale neustále jej opakujeme. To znamená, že utratíme více místa na disku a budeme mít riziko integrity dat.

Schéma galaxie

Na dva předchozí modely se můžeme dívat jako na dva datové obchody, jeden pro obchodní oddělení a druhý pro zásobovací oddělení. Každá z nich se skládá pouze z jedné tabulky faktů a několika rozměrových tabulek. Pokud bychom chtěli, mohli bychom tyto dva datové tržiště spojit do jednoho modelu. Tento typ schématu, který obsahuje několik tabulek faktů a sdílí některé tabulky dimenzí, se nazývá schéma galaxií . Sdílení tabulek dimenzí může snížit velikost databáze, zejména tam, kde sdílené dimenze mají mnoho možných hodnot. V ideálním případě jsou v obou datových tržištích dimenze definovány stejným způsobem. Pokud tomu tak není, budeme muset upravit rozměry tak, aby vyhovovaly oběma potřebám.

Níže je zobrazeno schéma galaxie sestavené z našich dvou příkladů datových trhů:

Hvězdicové schéma je jedním z přístupů k organizaci datového skladu. Je velmi přímočarý a nejčastěji se používá v datových tržištích. Pokud se nemusíme starat o místo na disku a dobře se staráme o integritu dat, pak je hvězdné schéma životaschopnou první a nejlepší volbou. Pokud ne, měli bychom přemýšlet o jiném přístupu. Jedním z nich je schéma sněhové vločky, o kterém budeme diskutovat v nadcházejícím článku.