När vi startar ett datalagerprojekt är det första vi gör att definiera dimensionstabellerna. Dimensionstabeller är de intressanta bitarna, ramverket kring vilket vi bygger våra mått. De finns i många former och storlekar. I den här artikeln ska vi titta närmare på varje typ av dimensionstabell.
Dimensionstabeller ger sammanhang till de affärsprocesser vi vill mäta. De berättar allt vi behöver veta om en händelse. Eftersom de ger substans åt mätningarna (d.v.s. faktatabeller) i datalagersystemet (DWH), lägger vi mer tid på deras definition och identifiering än på någon annan aspekt av projektet. Faktatabeller definierar måtten; dimensionstabeller ger sammanhang. (För att läsa mer om faktatabeller, kolla in dessa inlägg om datalagring, stjärnschemat, snöflingeschemat och fakta om faktatabeller).
Det huvudsakliga kännetecknet för dimensionstabeller är deras mångfald av attribut . Attribut är de kolumner som vi sammanfattar, filtrerar eller aggregerar. De har låg kardinalitet och är vanligtvis textmässiga och tidsmässiga. Dimensionstabeller har en primärnyckel baserad på den underliggande affärsnyckeln eller en surrogatnyckel . Denna primärnyckel är grunden för att sammanfoga dimensionstabellen till en eller flera faktatabeller.
Jämfört med faktatabeller är dimensionstabeller små i storleken, lätta att lagra och har liten inverkan på prestanda.
Låt oss nu ta en titt på några av dimensionstabellerna du kommer att stöta på i en datalagermiljö.
En vanlig dimensionstabell:den anpassade dimensionen
Vi börjar med en grundläggande typ:den anpassade dimensionen. Dessa har flera attribut, som kan adresseras i flera källtabeller men som refererar till samma domän (kund, kontrakt, affär, etc.) Anpassade dimensioner används med många fakta och bör vara unika för korn-/domänvärde i datalagret.
Exempel:
Låt oss titta på en typisk dimensionstabell, DIM_CUSTOMER .
Vi definierar:
id– Dimensionstabellens primärnyckel.cust_natural_key– Den naturliga nyckeln för kunden.first_name– Kundens förnamn.last_name– Kundens efternamn.address_residence– Kundens bostadsadress.date_of_birth– Kundens födelsedatum.marital_status– Är kunden gift? Definierat som Y (ja) eller N (nej).gender– Kundens kön, M (man) eller F (kvinna).
Dimensionstabellens attribut beror på företagets behov. Vi kan utöka denna typ av tabell för att innehålla branschspecifik information (standarddatum, aktivitet, etc.)
Långsamt förändrade dimensionstabeller
Allt eftersom tiden går kan dimensioner ändra sina värden. I följande stycken kommer vi att undersöka dimensioner som klassificeras efter hur de lagrar (eller inte lagrar) historisk data.
Låt oss säga att du har en kunddimension. Vissa attribut kommer sannolikt att förändras under kundens livstid – t.ex. telefonnummer, adress, civilstånd, etc. Denna typ av tabell är vad Ralph Kimball kallar en långsamt föränderlig dimension, eller SCD.
SCD finns i många typer; åtta av dem är ganska vanliga. Av dessa kommer du att se typerna 0 till 4 mest; typerna 5, 6 och 7 är hybrider av de första fem. (Obs:Numreringsschemat för dessa SCD-skivor börjar med en 0 istället för en 1.)
Hybrid SCD ger mer flexibilitet och bättre prestanda, men på bekostnad av enkelheten. Vi använder dessa tabelltyper när vi behöver göra analytisk analys av aktuell data med några historiska överväganden.
SCD Typ 0:Fylls en gång
Detta är den mest grundläggande typen av dimensionstabellen:du fyller den en gång och aldrig fyll den igen. Se detta som referensdata. Ett typiskt exempel på detta är datumdimensionen. Vi behöver inte fylla denna dimension med varje DWH-last. Den dimensionella tabellen ändras inte med tiden. Du kan inte få fler datum eller ändra datum.
Faktatabellen ansluter till dimensionens ursprungliga attribut.
Exempel
Låt oss titta på tidsdimensionen:
Strukturen är ganska enkel:
id– Surrogatnyckeltime_date– Faktiskt datumtime_day– Dag i månadentime_week– Vecka på årettime_month– Månad på ett årtime_year– Sifferrepresentation av ett år
SCD Typ 1:Skriva om data
Som namnet antyder, skriver vi om denna typ av dimensionstabell med varje DWH-belastning. Vi behöver inte föra en historik över dem, men vi förväntar oss att det kommer att ske några förändringar.
Skillnaden mellan en typ 0 SCD och en typ 1 ligger inte i tabellens struktur. Det har att göra med uppdateringen av data. Du uppdaterar aldrig data i en typ 0, men det gör du ibland i en typ 1.
En omskrivbar tabell är det enklaste sättet att hantera ändringar (ta bort/infoga), men det tillför lite affärsvärde. När du väl har definierat en dimensionstabell som denna är det svårt att installera historisk spårning.
Faktatabellen ansluter till dimensionens aktuella attribut.
Exempel
Låt oss titta på kontodimensionen:
Dess struktur är följande:
id– Tabellens surrogatnyckelaccount_name– Namnet på kontotaccount_type– Kategorien för kontotaccount_activity– Flaggar olika typer av aktiviteter
Om vi tittar på data före ändringen skulle vi se detta:
Om kontotypen har ändrats kommer uppgifterna helt enkelt att skrivas över:
SCD Typ 2:Spåra historiska attribut efter rad
Detta är den vanligaste formen av historisk spårning i ett DWH-system. SCD Typ 2-tabeller lägger till nya rader för varje historisk förändring av dimensionsattribut mellan DWH laddar . I den här typen definierar vi primärnyckeln som en surrogatnyckel eftersom affärsnyckeln kommer att ha flera representationer över tiden. När rader som innehåller ändringen av data ändras, definierar vi ett nytt värde för surrogatnyckeln som motsvarar värdet i faktatabellen. Vi måste lägga till minst två kolumner, valid_from och valid_to , för att lagra historik på detta sätt.
Faktatabellen ansluter till dimensionens historiska attribut via surrogatnyckeln. Aggregeringen görs på den naturliga nyckeln .
Exempel
Låt oss titta på den tidigare kunddimensionstabellen, nu utökad med två datumkolumner:
Låt oss titta på data:
Poäng att tänka på:
- Hur kan vi flagga den aktuella raden,
valid_to? (Vanligtvis med 31.12.9999, eller NULL .) - Hur kan vi flagga den första raden,
valid_from? (Vanligtvis med 01.01.1900, eller datumet för den första infogningen). - Definierar du en inkluderande eller exklusiv rad? (Ovan använder vi en inkluderande
valid_fromoch en exklusivvalid_to).
SCD Typ 3:Spåra historiska attribut efter kolumn
Precis som med Type 2 SCD, lägger denna typ till något för att representera historiska värden. Men i det här fallet lägger vi till nya kolumner. Dessa representerar värdet av ett dimensionell radattribut innan det ändras. Vanligtvis behåller vi bara den tidigare versionen av attributet.
Obs:Denna SCD används sällan.
Faktatabellen ansluter till dimensionens nuvarande och tidigare attribut.
Exempel
Låt oss titta på kunddimensionen, den här gången med en tidigare bostadsadress:
I det här exemplet har vi lagt till en ny kolumn, previous_address_residence , för att representera kundens gamla adress. Om vi tittar på vårt första exempel skulle data i den här tabellen se ut så här:
All historisk information, förutom kundens tidigare adress, går förlorad.
SCD Typ 4:Lägga till en minidimension
Denna typ av dimension är inte baserad på strukturella (typ 3) eller värdeförändringar (typ 2). Snarare är det baserat på designförändringar av modellen. Om vår dimensionella tabell innehåller mycket flyktiga data – det vill säga data som ändras ofta – skulle storleken på dimensionstabellen växa avsevärt.
För att mildra detta extraherar vi de flyktiga attributen till en minidimension . Dessa minidimensioner kan sedan aggregeras till den affärsrelevanta nivån. Men denna sammanställning bör inte förväxlas med faktaaggregation . Exemplet kommer att reda ut detta.
Faktatabellen ansluter till dimensionens historiska attribut.
Exempel
Låt oss titta på ett exempel från en enkel finansiell datamarknad. Anta att du behöver spåra hur sena vissa kunder är med sina betalningar. Låt oss kalla detta attribut dagar förfallna, eller DPD. Om vi skulle spåra DPD varje dag i en typ 2-dimension skulle bordets storlek snart explodera bortom hanterbara gränser. Så vi extraherar attributet och hittar affärsrelevanta perioder av DPD – säg i steg om 30 dagar (0–30 DPD, 30–60 DPD, 60–90 DPD, etc.)
Vi kan ta andra högvolatilitetsattribut, såsom ålder, och konstruera affärsrelevanta perioder för dem också (t.ex. 20-30 år, 30-40 år, etc.)
Om vi tittar på data i kundminidimensionen skulle vi ha något sånt här:
Attributen är:
id– Surrogat primärnyckelDPD_period– Dagar efter förfallotidDEM_period– Demografiperiod
Det enkla stjärnschemat skulle se ut så här:
Lägg märke till att för att göra någon analys av attribut från båda tabellerna måste vi överbrygga dem genom faktatabellen.
SCD Typ 5:Skapa en minidimension med ett omskrivbart tillägg
Detta är den första av våra hybriddimensionella bordskonstruktioner. I en typ 5 SCD lägger vi till den aktuella versionen av minidimensionella data till dimensionstabellen. Vi måste komma ihåg att vi bara lägger till den aktuella representation av minidimensionen till huvuddimensionen.
Vi fyller på denna minidimensionsförlängning med varje laddning (typ 1 "omskrivbara" SCD).
Även om historiken av det här tillägget mycket väl kan leda till storleksproblem, har vi redan åtgärdat dem med minidimensionstabellen.
Vi använder den här tekniken när vi vill göra analyser direkt på dimensionstabellerna.
Exempel
Om vi utökar det föregående exemplet med den aktuella minidimensionen får vi:
dim_mini_customer_current Tabellen innehåller de senaste attributvärdena som motsvarar dim_customer tabell. Nu kan vi göra kundspecifika analyser utan att överbrygga faktatabellen (vilket är väldigt långsamt).
Faktatabellen ansluter till dimensionens historiska attribut.
Typ 6:Dimension typ 2 (historisk rad) med ett omskrivbart attribut
Detta är en mycket vanlig dimensionell konstruktion. Vi lägger till ett attribut som lagrar en sak, vanligtvis det senast kända värdet, som vi skriver om vid varje laddning. Detta gör det möjligt för oss att gruppera alla fakta efter deras aktuella värde, medan det historiska attributet visar data som de var när händelser inträffade.
Faktatabellen ansluter till dimensionsvärdena vid händelse-tidpunkten med extra aktuella dimensionella värden.
Exempel
Låt oss utöka den tidigare kundtabellen med en current_address_residence kolumn.
Nu har vi ett attribut som vi kommer att uppdatera till det aktuella värdet med hjälp av den naturliga nyckeln (cust_natural_key ).
Typ 7:Dimensioner av typ 2 (historisk rad) med en aktuell spegel
Vi kan bara använda den här typen om det finns en naturlig nyckel i tabelldimensionen. Nyckeln får inte ändras under enhetens livstid.
Tanken är enkel:vi lägger till en aktuell representation av dimensionstabellen till snöflingeschemat. Sedan infogar vi den naturliga nyckeln för den nya dimensionen i faktatabellen. (Surrogatnyckeln till den historiska dimensionen är fortfarande närvarande.)
Faktatabellen ansluter till dimensionsvärdena vid händelse-tidpunkten och till aktuella dimensionella värden.
Exempel
Låt oss titta på vårt stjärnschema för kundkonton. Vi lägger till den nya dimensionen, dim_current_customer , till faktatabellen. Denna tabell är kopplad till faktatabellen via en naturlig nyckel, cust_natural_key .
Denna konstruktion gör det möjligt för oss att göra analytiska frågor på stjärnschemat med både nuvarande och historiska värden för kundattribut.
Domändimensioner
En domändimension är en enkel form av dimensionstabell. Den innehåller information om domänen för det underliggande måttet av ett dimensionsattribut. Dessa tabeller lagrar olika koder och förklarande värden.
Exempel
Ett enkelt exempel skulle vara en valutatabell.
I den här tabellen lagrar vi beskrivande information om olika monetära enheter.
Enligt min personliga åsikt är den bästa användningen av domändimensionen i dokumentationen av de datavärden vi hittar i DWH-systemet.
Skräpmått
Transaktionella källsystem genererar massor av indikatorer och flaggor. Dessa attribut kan betraktas som kategoriska data, men de är inte affärsrelevanta eller självförklarande. Vi kan spara alla dessa indikatorer och flaggor i endimensionell tabell som kallas en skräpdimension . Skräpdimensionen är alternativet till att använda degenererade dimensioner. Om vi inte vill belasta faktatabellen med många degenererade dimensioner skapar vi en skräpdimension.
Vi bör notera att vi inte fyller i alla möjliga kombinationer av indikatorer och flaggor. Vi fyller bara i de som finns i källsystemet.
Exempel
Dimensionstabeller är skeletten i datalagervärlden:allt är byggt runt dem. De är inte lika stora som faktatabeller, men deras struktur kan vara mer komplex.
Du kan sätta ihop många typer av dimensionstabeller, även utöver de vi just har diskuterat. Hur är det med ditt företag och din bransch? Om du har kombinerat dimensionella tabelltyper till något nytt, berätta om det!