Innen dataforvaltning og datavarehus er en endringstreg dimensjon er en dimensjon som inneholder relativt statiske data, men som kan endre seg med uforutsigbare tidsintervaller. Vanlige eksempler på endringstrege dimensjoner er entiteter som navn på geografiske lokasjoner, kundenavn eller produktdetaljer.
Noen scenarier kan føre til problemer med referanseintegritet.
Motiverende eksempel For eksempel kan en database inneholde en faktatabell som holder på salgskolonner. Denne faktatabellen vil ofte være koblet til en dimensjon ved hjelp av fremmednøkler. En av disse dimensjonene kan inneholde data om selskapets selgere, som for eksempel det regionale kontoret hvor de jobber. Det er imidlertid ikke uvanlig at selgerne blir overført fra ett regionskontor til et annet. For historisk salgsrapportering kan det da være nødvendig å holde en oversikt over hvilke kontorer en bestemt selger har jobbet på til ulike tidspunkt.
Håndtering av slike spørsmål innebærer bruk av ulike typer endrigstrege dimensjoner. Det finnes da 7 ulike metoder som blir referert til som type 0 til 6, pluss noen hybrider av disse. Type 6 kalles også av og til for en hybrid type endringstreg dimensjon.
Type 0: behold originalen Med en type 0 endringstreg dimensjon vil dimensjonsattributtene aldri forandre seg, og blir tilordnet attributter som har persistente (varige) verdier og kan beskrives som "originale". Noen eksempler kan være en fødselsdato eller opprinnelig kredittskår. Type 0 kan anvendes for de fleste dimensjonsattributter for datoerhttp://www.kimballgroup.com/2013/02/design-tip-152-slowly-changing-dimension-types-0-4-5-6-7/ ettersom satte datoer stort sett ikke behøver endres.
Type 1: overskriv Med en type 1 endringstreg dimensjon overskrives gamle data med nye, og det blir ikke ført historikk på historiske data.
Et eksempel kan være en leverandør som bytter adresse, og man ikke har behov for å beholde historikk for den gamle adressen eller når adressen ble endret i systemet. Eksempel på en tabell leverandør: Supplier_KeySupplier_CodeSupplier_NameSupplier_State123ABCAcme Supply CoCA I eksemplet ovenfor er Supplier_Code den naturlige nøkkelen og Supplier_Key er en surrogatnøkkel. (Teknisk sett er ikke surrogatnøkkelen nødvendig, siden raden vil være unik med den naturlige nøkkelen Supplier_Code.)
Dersom leverandøren flytter hovedkvarteret fra California (CA) til Illinois (IL) vil oppføringen bli overskrevet: Supplier_KeySupplier_CodeSupplier_NameSupplier_State123ABCAcme Supply CoIL En ulempe med Type 1-metoden er at databasen ikke inneholder historikk. En fordel er dog at den er enkel å vedlikeholde.
Dersom man har gjort utregninger som oppsummerer faktaene i tabellen etter Supplier_State må man sørge for at disse aggregerte faktaene beregnes på nytt når Supplier_State endres.
Type 2: legg til en ny rad Med en type 2 endringstreg dimensjon vil man ta vare på historiske data ved å opprette nye oppføringer for en gitt naturlig nøkkel i dimensjonstabellene, men med unike surrogatnøkler og/eller versjonsnumre. På denne måten bevarer man all historikk uten begrensning ved hver insert-kommando. Det finnes mange måter å implementere en type 2 endringstreg dimensjon på.
Eksempelvis kan et versjonsnummer øke sekvensielt når leverandøren flytter til Illinois: Supplier_KeySupplier_CodeSupplier_NameSupplier_StateVersjon123ABCAcme Supply CoCA0123ABCAcme Supply CoIL1 En annen metode er å legge til kolonner for ikrafttredelsesdato: Supplier_KeySupplier_CodeSupplier_NameSupplier_StateStart_Datesluttdato123ABCAcme Supply CoCA2000-01-01T00:00:002004-12-22T00:00:00123ABCAcme Supply CoIL2004-12-22T00:00:00NULL Her er sluttdato/klokkeslett lik startdato/klokkeslett i påfølgende rad, mens NULL for sluttdato indikerer at den nåværende raden er siste element i tuppelen. Alternativt kan man velge en "standardisert" dato langt frem i tid som brukes som sluttdato i systemet (f.eks. 9999-12-31, som er ISO-notasjon for 31. desember i år 9999) slik at feltet kan inkluderes i en indeks, samtidig som at substitusjon av NULL-verdier ikke er nødvendig ved spørring.
En tredje variant er å bruke dato for ikrafttredelse og et flagg for hva som er gjeldende versjon. Supplier_KeySupplier_CodeSupplier_NameSupplier_StateEffective_DateCurrent_Flag123ABCAcme Supply CoCA2000-01-01T00:00:00N123ABCAcme Supply CoIL2004-12-22T00:00:00Y Flaggverdien "Y" indikerer her elementet i i tuppelen som er gjeldende versjon.
Transaksjoner som refererer til en bestemt surrogatnøkkel (Supplier_Key) er dermed permanent bundet til tidsintervaller definert av den aktuelle raden i den endringstrege dimensjonstabellen. En aggregattabell som oppsummerer fakta basert på supplier state vil fortsette å gjenspeile den historiske staten (altså den staten som leverandøren holdt til i på den tiden transaksjonen ble utført) og dermed er ingen oppdatering nødvendig. For å referere til entiteten via naturlige nøkkelen er det nødvendig å fjerne unikhets-begrensninger, hvilket vil gjøre referanseintegritet av databasehåndteringssystemet umulig.
Dersom det gjøres tilbakevirkende endringer i innholdet i en dimensjon, eller dersom nye attributter legges til i dimensjonmen (for eksempel en Sales_Rep-kolonne) som har forskjelliger ikrafttredelsesdatoer enn de som allerede er definert kan dette føre til at de tidligere transaksjoner må oppdateres for å gjenspeile den nye situasjonen. Dette kan være en beregningsmessig dyr databaseoperasjon, og type 2 endringstrege dimensjoner er følgelig ikke et godt valg dersom dimensjonsmodellen er gjenstand for hyppige endringer.
Type 3: legg til en ny attributt Med en type 3 endringstreg dimensjon spores endringer ved hjelp av egne kolonner, og man beholder på denne måten begrenset historikk. Begrensningen ligger her på antall kolonner som er avsatt til lagring av historiske data. Tabellstrukturen kan ellers være ganske lik den som brukes for type 1 og type 2, men type 3 legger altså til en eller flere ekstra kolonner.
I eksempelet under har en ekstra kolonne blitt lagt til i tabellen for å ha historikk på staten hvor leverandøren opprinnelig hadde tilholdssted. Merk at dersom leverandøren flytter tilholdssted på nytt vil nåværende tilholdssted bli overskrevet, og har dermed ikke historikk over tidligere tilholdssteder med unntak av det første. Supplier_KeySupplier_CodeSupplier_NameOriginal_Supplier_StateEffective_DateCurrent_Supplier_State123ABCAcme Supply CoCA2004-12-22T00:00:00IL Historikken kan dermed ikke spores dersom leverandøren flytter tilholdssted en andre gang.
En variant av type 3 er å å opprette en kolonne for Previous_Supplier_State istedet for Original_Supplier_State. Dette vil medføre at man bare holder historikk over nåværende verdi og tilholdsstedet ved den forrige tilstandsendringen, og man kan altså bare spore nylige endringer.
Type 4: legge til historikktabell Med en type 4 endringstreg dimensjon benytter man "historikktabeller" hvor en tabell inneholder de nåværende versjonen av dataene, og en annen tabell holder oversikt av noen eller alle endringene som har blitt gjort. Begge surrogatnøklene blir refererte i faktatabellen for å hjelpe ytelsen under spørringer.
I eksempelet nedenfor er det opprinnelige tabellnavnet Supplier og historikktabellen heter Supplier_History: +SupplierSupplier_KeySupplier_CodeSupplier_NameSupplier_State124ABCAcme & Johnson Supply CoIL +Supplier_HistorySupplier_KeySupplier_CodeSupplier_NameSupplier_StateCreate_Date123ABCAcme Supply CoSERTIFISERINGSINSTANS2003-06-14T00:00:00124ABCAcme & Johnson Supply CoIL2004-12-22T00:00:00 Denne metoden ligner på hvordan man går frem for å lage revisjonstabeller i databaser og fangst av dataendringer.
Type 5 Med en type 5 endringstreg dimensjon bygger man på en type 4 minidimensjon ved å bygge inn en minidimensjons-nøkkel for "nåværende profil" i basedimensjonen, som blir overskrevet som en type 1 attributt. Fremgangsmåten har fått navnet fordi det er en kombinasjon av type 1 og type 4, og 4+1 blir 5. Type 5 gjør det mulig at de nåværende tildelte attibuttverdiene for minidimensjonen å bli aksesserte sammen med basedimensjonens andre uten at man lenker disse via en faktatabell. Logisk kan man dermed representere basedimensjonen og den nåværende minidimensjons-profilutriggeren som én enkelt tabell i presentasjonslaget. Utrigger-attributtene bør ha distinkte kolonnenavn, som for eksempel "Current Income Level" for å differensiere dem fra attributter i minidimensjonen lenket til faktatabellen. ETL-teamet må sørge for å kontinuerlig oppdatering eller overskriving av type 1 minidimensjones-referansen når enn den nåværende minidimensjonen endrer seg. Dersom tilnærmingen med utriggere ikke tilfredsstiller behovet for ytelse under spørringer kan man gjøre minidimensjons-attributtene tiil en fysisk innebygd (og oppdatert) del av basedimensjonen.https://www.kimballgroup.com/2013/02/design-tip-152-slowly-changing-dimension-types-0-4-5-6-7/
Type 6: kombinert tilnærming Med en type 6 endringstreg dimensjon kombinerer man fremgangsmåtene for type 1, type 2 og type 3, og navnet kommer dermed fra at 1+2+3 = 6. Det er muligens Ralph Kimball som kom på begrepet under en samtale med Stephen Tempo fra Kalido. I boken Data Warehouse Toolkit kaller Ralph Kimball metoden for Unpredictable Changes with Single-Version Overlay, direkte oversatt "uforutsigbare endringer med enkelt-versjons overlegg".
I følgende eksempel begynner leverandørtabellen med én oppføring for én leverandør: Supplier_KeyRow_KeySupplier_CodeSupplier_NameCurrent_StateHistorical_StateStart_DateEnd_DateCurrent_Flag1231ABCAcme Supply CoCACA2000-01-01T00:00:009999-12-31T23:59:59Y Det er her samme innhold i cellene Current_State og Historical_State. Den valgfrie attributten Current_Flag indikerer at dette er den gjeldende eller mest nylige oppføringen for denne leverandøren.
Når selskapet Acme Supply Co flytter til Illinois legges det til en ny oppføring på lignende måte som for type 2, men med forskjellen at en radnøkkel blir inkludert for å sikre at man har en unik nøkkel for hver rad. Supplier_KeyRow_KeySupplier_CodeSupplier_NameCurrent_StateHistorical_StateStart_DateEnd_DateCurrent_Flag1231ABCAcme Supply CoILCA2000-01-01T00:00:002004-12-22T00:00:00N1232ABCAcme Supply CoILIL2004-12-22T00:00:009999-12-31T23:59:59Y Man overskriver så informasjonen i cellen Current_State for den første oppføringen (hvor Row_Key = 1) med den nye informasjonen, som ved type 1-prosessering. Deretter opprettes en ny oppføring slik at man kan spore endringer, som ved type 2-prosessering. Til slutt lagres historikken i en annen State-kolonne (her: Historical_State), hvilket innebærer type 3-prosessering.
Eksempelvis dersom leverandøren skulle flytte igjen kan man dermed legge til en annen oppføring i Supplier-dimensjonen, og man overskriver innholdet i Current_State-kolonnen: Supplier_KeyRow_KeySupplier_CodeSupplier_NameCurrent_StateHistorical_StateStart_DateEnd_DateCurrent_Flag1231ABCAcme Supply CoNYCA2000-01-01T00:00:002004-12-22T00:00:00N1232ABCAcme Supply CoNYIL2004-12-22T00:00:002008-02-04T00:00:00N1233ABCAcme Supply CoNYNY2008-02-04T00:00:009999-12-31T23:59:59Y
Type 2 / type 6 faktaimplementasjon Type 2-surrogatnøkler med type 3-attributter I mange implementasjoner av endringstrege dimensjoner med type 2 og type 6 blir surrogatnøkkelen fra dimensjonen puttet inn i faktatabellen istedenfor den naturlige nøkkelen når faktadataene blir lastet inn i data-oppbevaringsstedet (data repository). Surrogatnøkkelen blir valgt for en gitt oppføring i faktatabellen basert på den effektive datoen, samt Start_Date og End_Date fra dimensjonstabelen. Dette gjør at faktadataene skal være lette å joine med de korrekte dimensjonsdataene for den korresponderende effektive datoen.
Under er Supplier-tabellen som ble opprettet ovenfor ved å bruke type 6 hybridmetoden: