Wanneer we een datawarehousing-project starten, is het eerste wat we doen de maattabellen definiëren. Maattabellen zijn de interessante stukjes, het raamwerk waarrond we onze metingen bouwen. Ze zijn er in vele soorten en maten. In dit artikel gaan we elk type dimensionale tabel nader bekijken.
Maattabellen geven context aan de bedrijfsprocessen die we willen meten. Ze vertellen ons alles wat we moeten weten over een evenement. Omdat ze inhoud geven aan de metingen (d.w.z. feitentabellen) van het datawarehouse (DWH)-systeem, besteden we meer tijd aan hun definitie en identificatie dan aan enig ander aspect van het project. Feitentabellen definiëren de maten; dimensionale tabellen geven context. (Voor meer informatie over feitentabellen, bekijk deze berichten over datawarehousing, het sterrenschema, het sneeuwvlokschema en feiten over feitentabellen).
Het belangrijkste kenmerk van dimensietabellen is hun veelvoud aan attributen . Attributen zijn de kolommen die we samenvatten, filteren of aggregeren. Ze hebben een lage kardinaliteit en zijn meestal tekstueel en tijdelijk. Dimensionale tabellen hebben één primaire sleutel op basis van de onderliggende bedrijfssleutel of een surrogaatsleutel . Deze primaire sleutel is de basis voor het koppelen van de dimensietabel aan een of meer feitentabellen.
In vergelijking met feitentabellen zijn dimensietabellen klein van formaat, gemakkelijk op te bergen en hebben ze weinig invloed op de prestaties.
Laten we nu eens kijken naar enkele van de dimensietabellen die u tegenkomt in een datawarehouse-omgeving.
Een gemeenschappelijke dimensionale tabel:de conforme dimensie
We beginnen met een basistype:de geconformeerde dimensie. Deze bevatten meerdere attributen, die in verschillende brontabellen kunnen worden geadresseerd, maar die verwijzen naar hetzelfde domein (klant, contract, deal, etc.) Conforme dimensies worden gebruikt met veel feiten en moeten uniek zijn voor graan/domeinwaarde in het datawarehouse.
Voorbeeld:
Laten we eens kijken naar een typische dimensionale tabel, DIM_CUSTOMER .
We definiëren:
id– De primaire sleutel van de dimensietabel.cust_natural_key– De natuurlijke sleutel voor de klant.first_name– De voornaam van de klant.last_name– De achternaam van de klant.address_residence– Het woonadres van de klant.date_of_birth– De geboortedatum van de klant.marital_status– Is de klant getrouwd? Gedefinieerd als Y (ja) of N (nee).gender– Het geslacht van de klant, M (mannelijk) of F (vrouwelijk).
Dimensietabelkenmerken zijn afhankelijk van de zakelijke behoefte. We kunnen dit type tabel uitbreiden om branchespecifieke informatie te bevatten (standaarddatum, activiteit, enz.)
Langzaam veranderende maattabellen
Naarmate de tijd verstrijkt, kunnen dimensies hun waarden wijzigen. In de volgende paragrafen onderzoeken we dimensies die zijn geclassificeerd op basis van hoe ze historische gegevens wel of niet opslaan.
Stel dat u een klantdimensie heeft. Sommige kenmerken zullen waarschijnlijk veranderen tijdens de levensduur van de klant, bijv. telefoonnummer, adres, burgerlijke staat, enz. Dit type tafel noemt Ralph Kimball een langzaam veranderende dimensie, of SCD.
De SCD is er in vele soorten; acht van hen zijn vrij algemeen. Hiervan zie je de typen 0 tot en met 4 het meest; typen 5, 6 en 7 zijn hybriden van de eerste vijf. (Opmerking:het nummeringsschema van deze SCD's begint met een 0 in plaats van een 1.)
Hybride SCD's bieden meer flexibiliteit en betere prestaties, maar ten koste van eenvoud. We gebruiken deze tabeltypen wanneer we een analytische analyse moeten uitvoeren van huidige gegevens met wat historische overwegingen.
SCD-type 0:eenmaal vullen
Dit is het meest elementaire type dimensietabel:u vult deze één keer in en nooit vul het opnieuw. Beschouw dit als referentiegegevens. Een typisch voorbeeld hiervan is de datumdimensie. We hoeven deze maat niet bij elke DWH-lading te vullen. De maattabel verandert niet met de tijd. U kunt geen datums meer krijgen of datums wijzigen.
De feitentabel sluit aan op de originele attributen van de dimensie.
Voorbeeld
Laten we eens kijken naar de tijdsdimensie:
De structuur is vrij eenvoudig:
id– Surrogaatsleuteltime_date– Werkelijke datumtime_day– Dag van de maandtime_week– Week in het jaartime_month– Maand in een jaartime_year– Cijferweergave van een jaar
SCD-type 1:gegevens herschrijven
Zoals de naam al doet vermoeden, herschrijven we dit type maattabel bij elke DWH-belasting. We hoeven er geen geschiedenis van bij te houden, maar we verwachten dat er enkele veranderingen zullen zijn.
Het verschil tussen een Type 0 SCD en een Type 1 zit niet in de structuur van de tabel. Het heeft te maken met het verversen van de gegevens. U ververst nooit de gegevens in een Type 0, maar soms wel in een Type 1.
Een herschrijfbare tabel is de eenvoudigste manier om met wijzigingen om te gaan (verwijderen/invoegen), maar het voegt weinig zakelijke waarde toe. Als u eenmaal een dimensietabel als deze heeft gedefinieerd, is het moeilijk om historische tracering te installeren.
De feitentabel sluit aan op de huidige attributen van de dimensie.
Voorbeeld
Laten we eens kijken naar de accountdimensie:
De structuur is als volgt:
id– De surrogaatsleutel van de tafelaccount_name– De naam van het accountaccount_type– De categorie van het accountaccount_activity– Markeert verschillende soorten activiteiten
Als we naar de gegevens van vóór de wijziging kijken, zien we dit:
Als het accounttype is gewijzigd, worden de gegevens gewoon overschreven:
SCD Type 2:Historische attributen per rij bijhouden
Dit is de meest voorkomende vorm van historische tracking in een DWH-systeem. SCD Type 2-tabellen voegen nieuwe rijen toe voor elke historische wijziging van dimensionale attributen tussen DWH-ladingen . In dit type definiëren we de primaire sleutel als een surrogaatsleutel omdat de bedrijfssleutel in de loop van de tijd meerdere representaties zal hebben. Wanneer rijen die de wijziging van gegevens bevatten, veranderen, definiëren we een nieuwe waarde voor de surrogaatsleutel die overeenkomt met de waarde in de feitentabel. We moeten minimaal twee kolommen toevoegen, valid_from en valid_to , om de geschiedenis op deze manier op te slaan.
De feitentabel maakt via de surrogaatsleutel verbinding met de historische attributen van de dimensie. De aggregatie gebeurt op de natuurlijke sleutel .
Voorbeeld
Laten we eens kijken naar de vorige klantdimensietabel, nu uitgebreid met twee datumkolommen:
Laten we eens kijken naar de gegevens:
Aandachtspunten:
- Hoe kunnen we de huidige rij markeren,
valid_to? (Meestal met 31.12.999, of NULL .) - Hoe kunnen we de eerste rij markeren,
valid_from? (Meestal met 01.01.1900, of de datum van de eerste invoeging). - Definieert u een inclusieve of exclusieve rij? (Hierboven gebruiken we een inclusief
valid_fromen een exclusievevalid_to).
SCD Type 3:Historische attributen volgen per kolom
Net als bij de Type 2 SCD voegt dit type iets toe om historische waarden weer te geven. In dit geval voegen we echter nieuwe kolommen toe. Deze vertegenwoordigen de waarde van een dimensionaal rijkenmerk voordat het verandert. Gewoonlijk bewaren we alleen de vorige versie van het kenmerk.
Opmerking:deze SCD wordt zelden gebruikt.
De feitentabel sluit aan op de huidige en eerdere attributen van de dimensie.
Voorbeeld
Laten we eens kijken naar de klantdimensie, dit keer met een eerder woonadres:
In dit voorbeeld hebben we een nieuwe kolom toegevoegd, previous_address_residence , om het oude adres van de klant weer te geven. Als we naar ons eerste voorbeeld kijken, zien de gegevens in deze tabel er als volgt uit:
Alle historische informatie, behalve het vorige adres van de klant, gaat verloren.
SCD Type 4:Een mini-dimensie toevoegen
Dit type dimensie is niet gebaseerd op structurele (Type 3) of waardeveranderingen (Type 2). Het is eerder gebaseerd op ontwerpwijzigingen in het model. Als onze dimensionale tabel zeer vluchtige gegevens bevat - d.w.z. gegevens die regelmatig veranderen - zou de grootte van de dimensionale tabel aanzienlijk toenemen.
Om dit te verminderen, extraheren we de vluchtige attributen in een mini-dimensie . Deze minidimensies kunnen vervolgens worden geaggregeerd tot het bedrijfsrelevante niveau. deze aggregatie mag echter niet verward worden met feitenaggregatie . Het voorbeeld zal dit duidelijk maken.
De feitentabel sluit aan op de historische kenmerken van de dimensie.
Voorbeeld
Laten we eens kijken naar een voorbeeld van een eenvoudige financiële datamart. Stel dat u moet bijhouden hoe laat bepaalde klanten zijn met hun betalingen. Laten we dit kenmerk dagen achterstallig noemen, of DPD. Als we DPD elke dag zouden volgen in een Type 2-dimensie, zou de grootte van de tafel al snel voorbij de beheersbare limieten exploderen. Dus we extraheren het attribuut en vinden bedrijfsrelevante perioden van DPD, bijvoorbeeld in stappen van 30 dagen (0-30 DPD, 30-60 DPD, 60-90 DPD, enz.)
We kunnen andere kenmerken met hoge volatiliteit nemen, zoals leeftijd, en er ook bedrijfsrelevante perioden voor construeren (bijvoorbeeld 20-30 jaar oud, 30-40 jaar oud, enz.)
Als we naar de gegevens in de mini-dimensie van de klant kijken, zien we zoiets als dit:
De attributen zijn:
id– Surrogaat primaire sleutelDPD_period– Dagen achterstallige periodeDEM_period– Demografische periode
Het eenvoudige sterrenschema ziet er als volgt uit:
Merk op dat om analyses van attributen uit beide tabellen te doen, we ze zouden moeten overbruggen via de feitentabel.
SCD Type 5:Een mini-dimensie creëren met een herschrijfbare extensie
Dit is de eerste van onze hybride dimensionale tabelconstructies. In een Type 5 SCD voegen we de huidige versie van mini-dimensionale gegevens toe aan de dimensionale tabel. We moeten er rekening mee houden dat we alleen de huidige . zullen toevoegen weergave van de mini-dimensie naar de hoofddimensie.
We vullen deze mini-dimensieverlenging bij elke lading (de Type 1 "herschrijfbare" SCD).
Hoewel de historisering van deze extensie heel goed tot problemen met de afmetingen zou kunnen leiden, hebben we deze al verholpen met de mini-afmetingstabel.
We gebruiken deze techniek wanneer we direct analyses willen uitvoeren op de maattabellen.
Voorbeeld
Als we het vorige voorbeeld uitbreiden met de huidige mini-dimensie, krijgen we:
De dim_mini_customer_current tabel bevat de meest recente attribuutwaarden die overeenkomen met de dim_customer tafel. Nu kunnen we klantspecifieke analyses doen zonder de feitentabel te overbruggen (wat erg traag is).
De feitentabel sluit aan op de historische kenmerken van de dimensie.
Type 6:Type 2 (historische rij) dimensie met een herschrijfbaar kenmerk
Dit is een veel voorkomende dimensionale constructie. We voegen een attribuut toe dat één ding opslaat, meestal de laatst bekende waarde, die we bij elke lading herschrijven. Dit stelt ons in staat om alle feiten te groeperen op hun huidige waarde, terwijl het historisch attribuut gegevens weergeeft zoals het was toen de gebeurtenissen plaatsvonden.
De feitentabel sluit aan op de dimensionale waarden op het moment van de gebeurtenis met extra actuele dimensionale waarden.
Voorbeeld
Laten we de vorige klantentabel uitbreiden met een current_address_residence kolom.
Nu hebben we een attribuut dat we zullen updaten naar de huidige waarde, met behulp van de natuurlijke sleutel (cust_natural_key ).
Type 7:Type 2 (Historische rij) Afmetingen met een huidige spiegel
We kunnen dit type alleen gebruiken als er een natuurlijke sleutel is in de tabeldimensie. De sleutel mag niet veranderen tijdens de levensduur van de entiteit.
Het idee is eenvoudig:we voegen een huidige weergave van de dimensionale tabel toe aan het sneeuwvlokschema. Vervolgens voegen we de natuurlijke sleutel van de nieuwe dimensie toe aan de feitentabel. (De surrogaatsleutel van de historische dimensie is nog steeds aanwezig.)
De feitentabel sluit aan op de dimensionale waarden op het moment van de gebeurtenis en op de huidige dimensionale waarden.
Voorbeeld
Laten we eens kijken naar ons sterschema voor klantaccounts. We voegen de nieuwe dimensie toe, dim_current_customer , naar de feitentabel. Deze tabel is verbonden met de feitentabel via een natuurlijke sleutel, cust_natural_key .
Deze constructie stelt ons in staat analytische query's uit te voeren op het sterschema met zowel de huidige als historische waarden van klantkenmerken.
Domeinafmetingen
Een domeindimensie is een eenvoudige vorm van een dimensionale tabel. Het bevat informatie over het domein van de onderliggende meting van een dimensionaal attribuut. In deze tabellen zijn verschillende codes en verklarende waarden opgeslagen.
Voorbeeld
Een eenvoudig voorbeeld is een valutatabel.
In deze tabel slaan we beschrijvende informatie op over verschillende geldeenheden.
Naar mijn persoonlijke mening is het beste gebruik van de domeindimensie in de documentatie van de gegevenswaarden die we in het DWH-systeem vinden.
Ongewenste afmetingen
Transactionele bronsystemen genereren veel indicatoren en vlaggen. Deze kenmerken kunnen worden beschouwd als categorische gegevens, maar zijn niet bedrijfsrelevant of spreken voor zich. We kunnen al deze indicatoren en vlaggen opslaan in een dimensionale tabel die een ongewenste dimensie wordt genoemd . De junk-dimensie is het alternatief voor het gebruik van gedegenereerde dimensies. Als we de feitentabel niet willen belasten met veel gedegenereerde dimensies, creëren we één junk-dimensie.
Houd er rekening mee dat we niet alle mogelijke combinaties van indicatoren en vlaggen vullen. We vullen alleen die in het bronsysteem.
Voorbeeld
Dimensietabellen zijn de skeletten van de wereld van datawarehousing:alles is eromheen gebouwd. Ze zijn niet zo groot als feitentabellen, maar hun structuur kan complexer zijn.
U kunt vele soorten maattabellen samenstellen, zelfs buiten de tabellen die we zojuist hebben besproken. Hoe zit het met uw bedrijf en branche? Als je dimensionale tabeltypen hebt gecombineerd tot iets nieuws, vertel het ons dan!