V tomto článku se podívám podrobněji na dimenze, jejich typy – STAR/SNOWFLAKE/CONSTELLATION, jejich plnění, úrovně historizace a typické dimenze v datovém skladu.
Jak už jistě víte s existencí dimenzí je nutně propojená existence faktových tabulek. Faktová tabulka obsahuje metriky a dimenze statické atributy a různá dělení přes, která lze nahlížet na fakta. Obě struktury najdeme v l2 nejvyšší vrstvě datového skladu.
STAR vs SNOWFLAKE dimenze
Pro začátek je třeba připomenout si STAR/SNOWFLAKE systém uspořádání dimenzí. STAR znamená denormalizovaná dimenze s redundantními daty – hierarchická struktura je přímo v jedné tabulce. SNOWFLAKE znamená normalizovaná dimenze s cizími klíči do další dimenze – hierarchická struktura ve více tabulkách. Pro jednodušší pochopení uvedu příklad na produktové hierarchii.
Mám dimenzi produktů DIM_PRODUCT, ve které mám odkaz na dimenzi DIM_BRAND, ve které jsou informace o značce daného produktu. Například vyrábím výrobky z kožešiny a mám dvě značky. Jednu klasickou, která se jmenuje LASICA a pak luxusní značku GRIZZLY. Každá má trochu jiný segment zákazníků. No a pak mám dva produkty ‚Rukavice LASICA šedé‘ a ‚Luxusní rukavice GRIZZLY šedé‘. V dimenzi produktu mám informaci o názvu, barvě a odkaz do dimenze značky. V dimenzi značky mám pak rozdělení LASICA a GRIZZLY. Toto je typický snowflake. Případ kdy budu mít vše v dimenzi DIM_PRODUCT a dimenze DIM_BRAND neexistuje je STAR. Pro lepší pochopení přikládám obrázky.
Pojmenování po hvězdě a sněhové vločce velmi odpovídá grafickému uspořádání tabulek. Data ze zdrojového systému se budou blížit spíše SNOWFLAKE uspořádání, doporučuji však data analyzovat dle potřeb a spíše využít STAR uspořádání. Ve výsledku používáte kombinaci STAR/SNOWFLAKE, pro velmi používané atributy je lepší použít STAR (o JOIN méně v loadech), a pro méně používané postačí SOWFLAKE.
Ještě malá poznámka k dělení na značku. Nemusí být nutně jen značka a konec. Můžu mít ještě také pod značku – na to je krásný příklad do pivovarnictví, kdy mám značku piva a pod značkou rozlišuji ještě stupňovitost.
V obou případech jsme měli 1 faktovou tabulku, CONSTELLATION pak je jen rozšíření o více faktových tabulek.
XNA záznam v dimenzi
Na obrázcích jste si jistě všimli záznamu s XNA. Takový záznam vkládám do dimenze automaticky po vytvoření. Je to velmi častá praxe v datových skladech. Ve výsledku je to jen o tom, že když píši SELECT z faktové tabulky a připojuji dimenzi pomocí INNER JOINu, nezmizí mi záznamy co se nepropojí. Dělá to z toho LEFT JOIN, protože když připojujete dimenzi, nechcete, aby záznamy zmizely. Takže to zabraňuje především chybě na straně vývojáře.
Historizace dimenze
Dimenze není jen o master datech. Na většinu dimenzí nejspíš MD pohled postačí, ovšem existují i jiné pohledy. Nejčastěji se potkáte se základními třemi: MD pohled, MD pohled + historické hodnoty, TD pohled. Na pohledy lze nahlížet jako na podmnožiny, kdy každý pohled více vpravo přidává nějakou hodnotu navíc. Kromě těchto nejčastějších pak existují různé modifikace pro konkrétní potřeby – v literatuře je najdete pod pojmem SCD (= Slowly Changing Dimension). Defaultně doporučuji používat alespoň druhou úroveň, tedy MD pohled + historické hodnoty a pro konkrétní potřeby sáhnout po TD pohledu.
Historizace dimenze – Master Datový pohled
MD pohled je 1:1 tak jak je tomu v současném časovém okamžiku.
Historizace dimenze – Master Datový pohled + historické hodnoty
Následující pohled je MD pohled a navíc obsahuje hodnoty, které se vyskytly v dimenzi v minulosti, ale současně se již nepoužívají. Tyto hodnoty lze označit například příznakem, ale není to nutné – záleží na vaší potřebě. Tento pohled je velmi užitečný jakmile se pustíte do historických záznamů, pouze MD pohled by nestačil.
Za touto dimenzí už je schovaný mechanismus, který automaticky zajistí, že již nepoužívané hodnoty z dimenze nezmizí. Jednoduše toho lze docílit pomocí ‚mezi‘ tabulky a speciálního loadu (v přiloženém SQL s příklady). Mechanismus není třeba, pokud už toto obstarává zdrojový systém a sám obsahuje pole, ve kterém označuje nepoužívané záznamy.
Transakční dimenze
Transakční dimenze obsahuje všechny hodnoty, které se v dimenzi vyskytly a navíc obsahuje sloupce DATE_FROM a DATE_TO, takže znáte konkrétní období výskytu hodnot. Dimenzi pak připojím stejně jako předchozí s tím rozdílem, že musím přidat podmínku na období DATE_DAY BETWEEN DATE_FROM and DATE_TO.
Za takovou dimenzí je opět schovaný mechanismus, který automaticky takové uchování dat zajistí. Je ovšem komplexní a budu se mu v budoucnu věnovat v samostatném článku. Tento mechanismus lze aplikovat nejen na dimenze, ale i jakékoliv jiné tabulky.
Základní dimenze v datovém skladu
Za základní dimenze v datovém skladu považuji dimenze zákazník, produkt, kalendář, perioda, organizační struktura. Některé jsem už popsal dříve. Každopádně sem dimenze uvedu ve formě popisu datové struktury tabulek.
DIM_CALENDAR
Sloupec
Typ
Vlastnosti
Popis
DIM_CALENDAR_DATE
DATE
PRIMARY KEY
Den př.: ‚2023-12-31‘
WEEK_DAY
SMALLINT
NOT NULL
Den v týdnu. Neděle = 0, pondělí= 1, …, sobota = 6
WEEK_DAY_DESCR
VARCHAR(50)
NOT NULL
Texty ke dnu v týdnu: Sunday, Monday, …, Saturday
WEEK_DAY_DESCR_SHORT
VARCHAR(10)
NOT NULL
Krátké texty ke dnu v týdnu: Sun, Mon, …, Sat
WEEK_NUMBER
SMALLINT
NOT NULL
Číslo týdne v roce
QUARTER_ID
VARCHAR(10)
NOT NULL
Kvartál ve formátu ‚Q4 2023‘
FLAG_WORKING_DAY
SMALLINT
NOT NULL
Flag 1/0 -> 1 = pracovní den (není víkend, není svátek)
FLAG_WEEKEND
SMALLINT
NOT NULL
Flag 1/0 -> 1 = víkend (sobota nebo neděle)
FLAG_HOLIDAY
SMALLINT
NOT NULL
Flag 1/0 -> 1 = svátek
Datová struktura dimenze kalendáře
DIM_PERIOD
Sloupec
Typ
Vlastnosti
Popis
DIM_PERIOD_ID
VARCHAR(10)
PRIMARY KEY
Identifikátor měsíce ve formátu: ‚yyyyMM‘
PERIOD_FIRST_DATE
DATE
NOT NULL
První den měsíce
PERIOD_LAST_DATE
DATE
NOT NULL
Poslední den měsíce
QUARTER_ID
VARCHAR(10)
NOT NULL
Kvartál ve formátu ‚Q4 2023‘
CNT_WD
INT
NOT NULL
Počet pracovních dní
QUARTER_FIRST_DATE
DATE
NOT NULL
První den kvartálu
QUARTER_LAST_DATE
DATE
NOT NULL
Poslední den kvartálu
CNT_QTD_WD
INT
NOT NULL
Počet pracovních dní v kvartále po současný měsíc včetně
YEAR_FIRST_DATE
DATE
NOT NULL
První den v roce
CNT_YTD_WD
INT
NOT NULL
Počet pracovních dní v roce po současný měsíc včetně
Dimenze periody – agregace z DIM_CALENDAR pro měsíc
Faktová tabulka obsahuje metriky a dimenze statické atributy a různá dělení přes, která lze nahlížet na fakta
STAR je denormalizovaná dimenze s redundantními daty – hierarhie je přímo v tabulce. SNOWFLAKE je normalizovaná dimenze s cizími klíči do další dimenze – hierarchická struktura ve více tabulkách. Ve výsledku používáte kombinaci STAR/SNOWFLAKE, pro velmi používané atributy je lepší použít STAR.
Do dimenze se po vytvoření vkládá 1 záznam s XNA hodnotami – při JOINu nezmizí záznamy co se nepropojí, ale připojí se přes XNA.
Historizace dimenze – 3 hlavní způsoby: MD pohled, MD pohled + historické hodnoty, TD pohled. Lze najít pod termínem Slowly Changing Dimension. Za historizací je schovaný mechanismus co ji zajišťuje.
Základní dimenze v DWH jsou dimenze zákazník, produkt, kalendář, perioda, organizační struktura.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Vždy aktivní
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Předvolby
Technické uložení nebo přístup je nezbytný pro legitimní účel ukládání preferencí, které nejsou požadovány odběratelem nebo uživatelem.
Statistics
Technické uložení nebo přístup, který se používá výhradně pro statistické účely.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
