Ankermodellering

Ankermodellering er en teknikk for smidig database-modellering, og er egnet for informasjon som over tid endrer både struktur og innhold. Metoden gir en grafisk notasjon for konseptuell modellering som ligner på entitet–relasjonsmodellering, og har utvidelser for å arbeide med temporale data.

Figur for å demonstrere konseptet med ankermodellering

Modelleringsteknikken involverer 4 modelleringskonstruksjoner som hver fanger opp forskjellige aspekter av domenet som skal modelleres:

• Ankere (anchors)
• Attributter (attributes)
• Bånd (tie)
• Knute (knot), som er en oppslagstabell

I tillegg har man strømmer.

De resulterende modellene kan oversettes til fysiske databasedesign ved hjelp av formaliserte regler. Når en slik oversettelse er gjort vil tabellene i relasjonsdatabasen stort sett være av sjette normalform.

En fordel med ankermodellering er at den bruker et billedspråk som gjør det lettere å kjenne seg igjen og sette seg inn i komplekse krav. I likhet med datahvelv er det en entitetsbasert modelleringsmetode.

Filosofi

Ankermodellering oppstod for å utnytte av fordelene ved en høy grad av normalisering samtidig som man unngår ulempene som høyere normalform har med tanke på menneskelig lesbarhet. Fordeler med ankermodellering inkluderer at man kan utvikle modellen ikke-destruktivt, unngå NULL-verdier og holde informasjonen fri for redundans. Ytelsesproblemer på grunn av ekstra skjøtinger unngås i stor grad takket være en funksjon i moderne databasemotorer kalt skjøt-eliminering (join elimination) eller tabell-eliminering. For å håndtere endringer i informasjonsinnholdet emulerer ankermodellering aspekter av en temporal database i den resulterende relasjonsdatabase-modellen.

Historie

I 2004 i Sverige kom de tidligste installasjonene med ankermodellering da et datavarehus for et forsikringsselskap ble bygget ved hjelp av denne teknikken.

I 2007 ble teknikken brukt i noen få datavarehus og et online transaksjonsprosesserings (OLTP) -system, og ble samme år presentert internasjonalt av Lars Rönnnbäck på konferansen Transforming Data with Intelligence (TDWI) i Amsterdam. Dette vekket nok interesse for teknikken til å motivere en mer formell beskrivelse, og siden den gang har det blitt forsket på ankermodellering i et samarbeid mellom oppfinnerne Olle Regardt og Lars Rönnebäck samt et team ved Institutionen för data- och systemvetenskap (DSV) ved Stockholms universitet.

Den første vitenskapelige artikkelen der ankermodellering var formalisert ble presentert i 2009 på den 28. International Conference on Conceptual Modeling, og vant prisen for beste artikkel.

Et kommersielt nettsted tilbyr materiale om ankermodellering som er gratis å bruke under en Creative Commons-lisens. Et online modelleringsverktøy er også tilgjengelig som er gratis å bruke og har åpen kildekode.

Grunnleggende konsepter

Ankermodellering har 4 grunnleggende modelleringskonsepter, som er ankere, attributter, bånd og knuter (anchors, attributes, ties, knots).

• Ankere brukes til å modellere entiteter og hendelser
• Attributter brukes til å modellere egenskaper til ankere
• Bånd modellerer relasjonene mellom ankrene
• Knuter brukes til å modellere delte egenskaper, som for eksempel tilstander

Attributter og bånd kan beholde historikk dersom man ønsker å ta vare på endringer i informasjonen de modellerer.

Eksempelmodellen under viser de forskjellige grafiske symbolene som brukes for grunnkonseptene. Symbolene ligner de som brukes i entitet–relasjonsmodellering med et par utvidelser. For å indikere hvorvidt endringshistorikk tas vare på kan det brukes et dobbelt ytre skall. I eksempelet er dette vist for 3 historiserte attributter og 3 historiserte bånd. Knutesymbolet (en hul firkant med avrundede hjørner) er også tilgjengelig, men kan ikke historiseres. Ankersymbolet er en helfarget firkant.

Temporale aspekter

Ankermodellering håndterer to typer informasjonsutvikling, hvilket er strukturelle endringer og innholdsendringer.

Endringer i informasjonsstrukturen representeres gjennom utvidelser. Den høye graden av normalisering gjør det er mulig å ikke-destruktivt legge til de nødvendige modelleringskonseptene som trengs for å fange opp en endring på en slik måte at alle tidligere databasemodeller forblir en delmengde av den gjeldende modellen. Siden den eksisterende modellen ikke berøres gir dette fordelen at man kan utvikle databasen på en svært iterativ måte og uten å forårsake nedetid.

Endringer i innholdet i informasjonen gjøres ved å emulere lignende funksjoner fra temporale databaser i en relasjonsdatabase. I ankermodellering kan biter av informasjon knyttes til spesifikke tidspunkter eller tidsintervaller (både åpne og lukkede).

• Attributter brukes for å modellere tidspunkter for hendelser. Eksempler på slike hendelser kan være fødselsdatoer for personer eller tidspunkter for kjøp.
• Historisering av attributter og bånd brukes for å fange opp tidsintervaller hvor en verdi er gyldig, som for eksempel endringer i hårfargen til en person eller tidsperioden en person var gift.

I en relasjonsdatabase oppnås dette ved å ta utgangspunkt i tabellen som tilsvarer den historiserte attributten eller båndet og legge til en enkelt kolonne med en datatype som er granulær nok til å fange hastigheten på endringene. Dette legger til litt kompleksitet ettersom mer enn en rad i tabellen må undersøkes for å vite om et intervall er lukket eller ikke.

I ankermodellering brukes i stedet metadata for å håndtere punkter eller tidsintervaller som ikke er direkte relaterte til domenet som modelleres (som for eksempel informasjon om tidspunkter som er lagt inn i databasen) snarere enn noen av de ovennevnte konstruksjonene for relasjonsdatabaser. Dersom informasjon om slike endringer i databasen må oppbevares så kan bitemporal ankermodellering brukes, da vil ikke bare oppdateringer men også slette-kommandoer bli ikke-destruktive.

Relasjonell representasjon

I ankermodellering er det en en-til-en avbilding mellom symbolene som brukes i den konseptuelle modellen og tabellene i relasjonsdatabasen. Hvert anker, attributt, bånd og knute har en tilsvarende tabell i databasen med en entydig definert struktur. En konseptuell modell kan dermed oversettes til en relasjonsdatabasemodell ved hjelp av enkle automatiserte regler, og omvendt kan en relasjonsdatabasemodell enkelt oversettes til en konseptuell modell. Dette er ulikt fra mange andre modelleringsteknikker der det er komplekse og noen ganger subjektive steg for å oversette mellom konseptuelt, logisk og fysisk nivå.

Ankertabeller inneholder en enkelt kolonne hvor identiteter er lagret. En identitet antas å være den eneste egenskapen til en entitet som alltid er til stede og er uforanderlig. Siden identiteter sjelden er tilgjengelige fra domenet som modelleres genereres de i stedet teknisk, for eksempel ved å bruke en økende nummersekvens.

Et eksempel på et anker for identiteten til nevøene til Donald Duck er en mengde av 1-tupler: {⟨#42⟩, ⟨#43⟩, ⟨#44⟩}

Knuter kan betraktes som kombinasjonen av et anker og en enkelt attributt. Knutetabeller inneholder to kolonner, en for en identitet og en for en verdi. På grunn av at identiteter og verdier lagres sammen kan ikke knuter historiseres. Nytten deres kommer av å kunne redusere lagringskravene og forbedre ytelsen, ettersom tabeller som refererer til knuter kan lagre en kort verdi i stedet for en lang streng.

Et eksempel på en knute for kjønn er en mengde av 2-tupler: {⟨#1, "Mann"⟩, ⟨#2, 'Kvinnelige'⟩}

Statiske attributtabeller inneholder to kolonner, en for identiteten til enheten som verdien tilhører og en for den faktiske egenskapsverdien. Historiserte attributtabeller har en ekstra kolonne for lagring av starttidspunktet for et tidsintervall. I en knyttet attributttabell er verdikolonnen en identitet som refererer til en knutetabell.

Et eksempel på et statisk attributt for navnene til tegneseriefigurene er en mengde av 2-tupler: {⟨#42, 'Ole'⟩, ⟨#43, 'Dole'⟩, ⟨#44, 'Doffen'⟩}

Et eksempel på et knyttet statisk attributt for deres kjønn er en mengde av 2-tupler: {⟨#42, #1⟩, ⟨#43, #1⟩, ⟨#44, #1⟩}

Et eksempel på en historisert attributt for (skiftende) farger på antrekkene deres er en mengde av 3-tupler: {#44, 'Oransje', 1938-04-15⟩, ⟨#44, 'Grønn', 1939-04-28⟩, ⟨#44, 'Blå', 1940-12-13}

Statiske bindingstabeller relaterer to eller flere ankere til hverandre, og inneholder to eller flere kolonner for lagring av identitetene. Historiserte båndtabeller har en ekstra kolonne for lagring av starttidspunktet for et tidsintervall. Knyttede båndtabeller har en ekstra kolonne for hver refererte knute.

Et eksempel på et statisk bånd for søskenforholdet er en mengde av 2-tupler: {⟨#42, #43⟩, ⟨#42, #44⟩, ⟨#43, #42⟩, ⟨#43, #44⟩, ⟨#44, #42⟩, ⟨#44, #43⟩}

De resulterende tabellene vil alle være av sjette normalform, bortsett fra bånd hvor ikke alle kolonnene er en del av primærnøkkelen.

Sammenlignet med andre tilnærminger

På 2000-tallet har det blitt introdusert flere modelleringsmønstre for datavarehus med mål å oppnå smidige datavarehus, inkludert ensemble-modelleringtyper som ankermodellering, datahvelvmodellering, brennpunktmodellering, med flere.

Sammenligning med datahvelv

I 2013 på modelleringskonferansen BI Podium i Nederland presenterte Lars Rönnbäck en sammenligning av ankermodellering og datahvelv. Følgende tabell er basert på denne sammenligningen (2013 copyleft anchormodeling.com):

Sammenlignet egenskap	Datahvelv	Fordel	Anker
Familie	Ensemble-modellering	-	Ensemble-modellering
Paradigme	Datadrevet Reviderbarhet prioriteres	-	Datadrevet Behov prioriteres
Arkitektur	Hybrid (flere vedlikeholdsobjekter)	-	Replikert (enkelt vedlikeholdsobjekt)
Gruppering	As much as possible	-	As little as possible
Hoved-tidslinje	Tidspunkt for opprettelse	-	Tidspunkt for endring
Endringsdeteksjon	Multippel rad/kolonne-tilgang	AM	Enkelt rad/kolonne-tilgang
Strenghet	Løst formalisert Ingen navnekonvensjon	-	Strengt formalisert Har navnekonvensjon
Skjemaevolusjon	Destruktiv	AM	Ikke-destruktiv
Temporalisering	Any-temporal by hand, bruk av sluttdatering valgfritt (ikke anbefalt)	AM	Concurrent-temporal by design, ingen sluttdatering
Stramming	Oppdateringer kan være nødvendig	AM	Kun insert
Verktøystøtte	Mange verktøy (2013) Stort sett kommersielle	DV	Få verktøy (2013) Bare åpen kildekode
Tilpasning til endringer	Fortsatt tungvindt	AM	Nesten uanstrengt
Modellutveksling	Rå SQL med trykte diagrammer i ulike former	AM	Standardisert XML-format og grafisk notasjon
Uforanderlighet	Surrogat-identitet og naturlig nøkkel	AM	Bare surrogat-identitet
Naturlig-til-surrogat	En-til-en, statisk Fysisk realisert (hub)	AM	Mange-til-en, historiserbar Logisk visning av dataene
Optimalisering av spørringer	Litt viktig Nylige databaser	DV	Veldig viktig Siste-versjon databaser
Skriptbarhet	Med litt innsats	AM	Formalisert, automatisert for alle bruksområder
Visninger og utløsere	Nevnt, håndlaget fra gang til gang	AM	Formalisert, automatisert for alle bruksområder
Antagelser	Bygd for å vare Behøver antagelser	AM	Bygd for å endres Ingen antagelser
Markedsandel	Liten <1000 installasjoner (2013)	DV	Veldig liten <100 installasjoner (2013)