Når vi starter et data warehousing-projekt, er det første, vi gør, at definere dimensionstabellerne. Dimensionstabeller er de interessante bits, den ramme, som vi bygger vores målinger omkring. De kommer i mange former og størrelser. I denne artikel skal vi se nærmere på hver type dimensionsbord.
Dimensionstabeller giver kontekst til de forretningsprocesser, vi ønsker at måle. De fortæller os alt, hvad vi behøver at vide om en begivenhed. Da de giver indhold til målingerne (dvs. faktatabeller) af data warehouse-systemet (DWH), bruger vi mere tid på deres definition og identifikation end på noget andet aspekt af projektet. Faktatabeller definerer målingerne; dimensionelle tabeller giver kontekst. (For at læse mere om faktatabeller, tjek disse indlæg om data warehousing, stjerneskemaet, snefnugskemaet og fakta om faktatabeller).
Det vigtigste kendetegn ved dimensionstabeller er deres mange attributter . Attributter er de kolonner, som vi opsummerer, filtrerer eller samler. De har lav kardinalitet og er normalt tekstuelle og tidsmæssige. Dimensionstabeller har én primær nøgle baseret på den underliggende virksomhedsnøgle eller en surrogatnøgle . Denne primære nøgle er grundlaget for at forbinde dimensionstabellen med en eller flere faktatabeller.
Sammenlignet med faktatabeller er dimensionstabeller små i størrelse, nemme at opbevare og har ringe indflydelse på ydeevnen.
Lad os nu tage et kig på nogle af de dimensionstabeller, du vil støde på i et datavarehusmiljø.
En almindelig dimensionstabel:Den tilpassede dimension
Vi starter med en grundlæggende type:den tilpassede dimension. Disse har flere attributter, som kan adresseres i flere kildetabeller, men som refererer til det samme domæne (kunde, kontrakt, aftale osv.) Overensstemmende dimensioner bruges med mange fakta og bør være unikke for korn-/domæneværdi i datavarehuset.
Eksempel:
Lad os se på en typisk dimensionstabel, DIM_CUSTOMER .
Vi definerer:
id– Dimensionstabellens primære nøgle.cust_natural_key– Den naturlige nøgle for kunden.first_name– Kundens fornavn.last_name– Kundens efternavn.address_residence– Kundens bopælsadresse.date_of_birth– Kundens fødselsdato.marital_status– Er kunden gift? Defineret som Y (ja) eller N (nej).gender– Kundens køn, M (mand) eller F (kvinde).
Dimensionstabellens attributter afhænger af virksomhedens behov. Vi kan udvide denne type tabel til at indeholde branchespecifikke oplysninger (dato for standard, aktivitet osv.)
Langsomt skiftende dimensionstabeller
Som tiden går, kan dimensioner ændre deres værdier. I de følgende afsnit vil vi undersøge dimensioner klassificeret efter, hvordan de lagrer (eller ikke gemmer) historiske data.
Lad os sige, at du har en kundedimension. Nogle egenskaber vil sandsynligvis ændre sig i kundens levetid - f.eks. telefonnummer, adresse, civilstand osv. Denne type tabel kalder Ralph Kimball en langsomt skiftende dimension eller SCD.
SCD findes i mange typer; otte af dem er ret almindelige. Af disse vil du mest se typer 0 til 4; type 5, 6 og 7 er hybrider af de første fem. (Bemærk:Nummerskemaet for disse SCD'er starter med et 0 i stedet for et 1.)
Hybrid SCD'er giver mere fleksibilitet og bedre ydeevne, men på bekostning af enkelhed. Vi bruger disse tabeltyper, når vi skal lave analytisk analyse af aktuel data med nogle historiske overvejelser.
SCD Type 0:Påfyldning én gang
Dette er den mest grundlæggende type af dimensionstabellen:du udfylder den én gang og aldrig fylde det igen. Betragt dette som referencedata. Et typisk eksempel på dette er datodimensionen. Vi behøver ikke at fylde denne dimension med hver DWH-belastning. Den dimensionelle tabel ændrer sig ikke med tiden. Du kan ikke få flere datoer eller ændre datoer.
Faktatabellen forbinder til dimensionens oprindelige attributter.
Eksempel
Lad os se på tidsdimensionen:
Strukturen er ret ligetil:
id– Surrogatnøgletime_date– Faktisk datotime_day– Dag i månedentime_week– Uge i årettime_month– Måned om et årtime_year– Talangivelse af et år
SCD Type 1:Omskrivning af data
Som navnet antyder, omskriver vi denne type dimensionstabeller med hver DWH-belastning. Vi behøver ikke at føre en historie over dem, men vi forventer, at der vil ske nogle ændringer.
Forskellen mellem en Type 0 SCD og en Type 1 ligger ikke i tabellens struktur. Det har at gøre med opfriskning af data. Du opdaterer aldrig dataene i en Type 0, men det gør du nogle gange i en Type 1.
En genskrivbar tabel er den enkleste måde at håndtere ændringer på (slet/indsæt), men den tilføjer ringe forretningsværdi. Når først du har defineret en dimensionstabel som denne, er det svært at installere historisk sporing.
Faktatabellen forbinder til de aktuelle attributter for dimensionen.
Eksempel
Lad os se på kontodimensionen:
Dens struktur er som følger:
id– Tabellens surrogatnøgleaccount_name– Navnet på kontoenaccount_type– Kontoens kategoriaccount_activity– Markerer forskellige typer aktivitet
Hvis vi ser på dataene før ændringen, vil vi se dette:
Hvis kontotypen er ændret, vil dataene simpelthen blive overskrevet:
SCD Type 2:Sporing af historiske attributter efter række
Dette er den mest almindelige form for historisk sporing i et DWH-system. SCD Type 2-tabeller tilføjer nye rækker for hver historisk ændring af dimensionelle attributter mellem DWH-belastninger . I denne type definerer vi den primære nøgle som en surrogatnøgle, fordi forretningsnøglen vil have flere repræsentationer over tid. Når rækker, der indeholder ændringen af data, ændres, definerer vi en ny værdi for surrogatnøglen, der svarer til værdien i faktatabellen. Vi skal tilføje mindst to kolonner, valid_from og valid_to , for at gemme historie på denne måde.
Faktatabellen forbinder til dimensionens historiske attributter via surrogatnøglen. Sammenlægningen sker på den naturlige nøgle .
Eksempel
Lad os se på den tidligere kundedimensionstabel, nu udvidet med to datokolonner:
Lad os se på dataene:
Punkter at overveje:
- Hvordan kan vi markere den aktuelle række,
valid_to? (Sædvanligvis med 31.12.9999 eller NULL .) - Hvordan kan vi markere den første række,
valid_from? (Sædvanligvis med 01.01.1900 eller datoen for den første indsættelse). - Definerer du en inkluderende eller eksklusiv række? (Ovenfor bruger vi en inkluderende
valid_fromog en eksklusivvalid_to).
SCD Type 3:Sporing af historiske attributter efter kolonne
Som med Type 2 SCD tilføjer denne type noget til at repræsentere historiske værdier. I dette tilfælde tilføjer vi dog nye kolonner. Disse repræsenterer værdien af en dimensionel rækkeattribut, før den ændres. Normalt beholder vi kun den tidligere version af attributten.
Bemærk:Denne SCD bruges sjældent.
Faktatabellen forbinder til de aktuelle og tidligere attributter for dimensionen.
Eksempel
Lad os se på kundedimensionen, denne gang med en tidligere boligadresse:
I dette eksempel tilføjede vi en ny kolonne, previous_address_residence , for at repræsentere kundens gamle adresse. Hvis vi ser på vores første eksempel, vil dataene i denne tabel se sådan ud:
Alle historiske oplysninger, undtagen kundens tidligere adresse, går tabt.
SCD Type 4:Tilføjelse af en minidimension
Denne type dimension er ikke baseret på strukturelle (type 3) eller værdiændringer (type 2). Det er snarere baseret på designændringer af modellen. Hvis vores dimensionelle tabel indeholder meget flygtige data - dvs. data, der ændrer sig ofte - ville størrelsen af dimensionstabellen vokse betydeligt.
For at afbøde dette udtrækker vi de flygtige attributter til en minidimension . Disse minidimensioner kunne derefter aggregeres til det virksomhedsrelevante niveau. denne sammenlægning bør dog ikke forveksles med faktaaggregation . Eksemplet vil opklare dette.
Faktatabellen forbinder til dimensionens historiske attributter.
Eksempel
Lad os se på et eksempel fra et simpelt finansielt datamarked. Antag, at du skal spore, hvor sent visse kunder er med deres betalinger. Lad os kalde denne egenskab for forfaldne dage eller DPD. Hvis vi skulle spore DPD hver dag i en Type 2-dimension, ville bordets størrelse hurtigt eksplodere ud over håndterbare grænser. Så vi udtrækker attributten og finder forretningsrelevante perioder for DPD – f.eks. i intervaller på 30 dage (0-30 DPD, 30-60 DPD, 60-90 DPD osv.)
Vi kan tage andre attributter med høj volatilitet, såsom alder, og konstruere forretningsrelevante perioder for dem også (f.eks. 20-30 år, 30-40 år osv.)
Hvis vi ser på dataene i kundeminidimensionen, ville vi have noget som dette:
Attributterne er:
id– Surrogat primærnøgleDPD_period– Dage efter forfaldsperiodeDEM_period– Demografisk periode
Det simple stjerneskema ville se sådan ud:
Bemærk, at hvis vi skal foretage nogen analyser af attributter fra begge tabeller, skal vi bygge bro mellem dem gennem faktatabellen.
SCD Type 5:Oprettelse af en minidimension med en genskrivbar udvidelse
Dette er den første af vores hybriddimensionelle bordkonstruktioner. I en Type 5 SCD tilføjer vi den aktuelle version af minidimensionelle data til dimensionstabellen. Vi skal huske på, at vi kun tilføjer den aktuelle repræsentation af minidimensionen til hoveddimensionen.
Vi genopfylder denne minidimensionsudvidelse med hver belastning (type 1 "genskrivbare" SCD).
Selvom historiseringen af denne udvidelse meget vel kan føre til størrelsesproblemer, har vi allerede afhjulpet dem med minidimensionstabellen.
Vi bruger denne teknik, når vi ønsker at lave analyser direkte på dimensionstabellerne.
Eksempel
Udvider vi det foregående eksempel med den aktuelle minidimension, får vi:
dim_mini_customer_current tabel indeholder de seneste attributværdier, der svarer til dim_customer bord. Nu kan vi lave kundespecifikke analyser uden at bygge bro gennem faktatabellen (som er meget langsom).
Faktatabellen forbinder til dimensionens historiske attributter.
Type 6:Type 2 (historisk række) dimension med en genskrivbar egenskab
Dette er en meget almindelig dimensionel konstruktion. Vi tilføjer en attribut, som gemmer én ting, normalt den sidst kendte værdi, som vi omskriver med hver belastning. Dette gør det muligt for os at gruppere alle fakta efter deres aktuelle værdi, mens den historiske attribut viser data, som de var, da begivenhederne fandt sted.
Faktatabellen forbinder til de dimensionelle værdier på begivenhedstidspunktet med ekstra aktuelle dimensionelle værdier.
Eksempel
Lad os udvide den tidligere kundetabel med en current_address_residence kolonne.
Nu har vi en attribut, som vi vil opdatere til den aktuelle værdi ved hjælp af den naturlige nøgle (cust_natural_key ).
Type 7:Type 2 (historisk række) dimensioner med et aktuelt spejl
Vi kan kun bruge denne type, hvis der er en naturlig nøgle i tabeldimensionen. Nøglen må ikke ændres i enhedens levetid.
Ideen er enkel:vi tilføjer en aktuel repræsentation af dimensionstabellen til snefnugskemaet. Så indsætter vi den naturlige nøgle til den nye dimension i faktatabellen. (Surrogatnøglen til den historiske dimension er stadig til stede.)
Faktatabellen forbinder til de dimensionelle værdier på begivenhedstidspunktet og til de aktuelle dimensionelle værdier.
Eksempel
Lad os se på vores kundekontostjerneskema. Vi tilføjer den nye dimension, dim_current_customer , til faktatabellen. Denne tabel er forbundet med faktatabellen via en naturlig nøgle, cust_natural_key .
Denne konstruktion gør det muligt for os at lave analytiske forespørgsler på stjerneskemaet med både de aktuelle og historiske værdier af kundeattributter.
Domænedimensioner
En domænedimension er en simpel form for dimensionel tabel. Den indeholder oplysninger om domænet for den underliggende måling af en dimensionsattribut. Disse tabeller gemmer forskellige koder og forklarende værdier.
Eksempel
Et simpelt eksempel ville være en valutatabel.
I denne tabel gemmer vi beskrivende oplysninger om forskellige pengeenheder.
Efter min personlige mening er den bedste brug af domænedimensionen i dokumentationen af de dataværdier, vi finder i DWH-systemet.
Junk Dimensions
Transaktionelle kildesystemer genererer masser af indikatorer og flag. Disse attributter kan betragtes som kategoriske data, men de er ikke forretningsrelevante eller selvforklarende. Vi kan arkivere alle disse indikatorer og flag i en dimensionel tabel kaldet en junk dimension . Uønsket dimension er alternativet til at bruge degenererede dimensioner. Hvis vi ikke ønsker at belaste faktatabellen med mange degenererede dimensioner, skaber vi én junk-dimension.
Vi skal bemærke, at vi ikke udfylder alle mulige kombinationer af indikatorer og flag. Vi udfylder kun dem, der findes i kildesystemet.
Eksempel
Dimensionstabeller er skeletterne i data warehousingverdenen:alt er bygget op omkring dem. De er ikke så store som faktatabeller, men deres struktur kan være mere kompleks.
Du kan sammensætte mange typer dimensionstabeller, også ud over dem, vi lige har diskuteret. Hvad med din virksomhed og branche? Hvis du har kombineret dimensionelle bordtyper til noget nyt, så fortæl os om det!