Ankarmodellering är en datalagermodelleringsteknik lämplig för information som förändras över tid både i struktur och innehåll. Ger en grafik[ clarify ] används för konceptuell modellering, liknande entitets- och relationsmodellering , med tillägg för att arbeta med tidsdata. Modelleringstekniken använder fyra modelleringsmodeller: Anchor, Attribute, Link och Node, som var och en speglar olika aspekter av domänen som modelleras. De resulterande modellerna kan översättas till fysiska databasdesigner med hjälp av formaliserade regler. När en sådan översättning är gjord kommer tabellerna i en relationsdatabas mestadels att vara i sjätte normalform .
Ankarmodellering skapades för att dra fördel av den höga graden av databasnormalisering och undvika dess nackdelar. Det finns fördelar som möjligheten att inte förstöra modellen, att undvika tomma (det vill säga null ) värden och att inte tillåta redundant information. Prestandaproblem på grund av extra kopplingar elimineras till stor del av en funktion i moderna databasmotorer som kallas " tabelleliminering ".
De första datalagren på ankarmodeller byggdes i Sverige , det första av dem (2004) var åt ett försäkringsbolag. 2007 användes tekniken i flera datalager och ett OLTP- system och presenterades internationellt av Lars Rönbeck vid konferensen TDWI (Data Warehouse Institute) i Amsterdam [1] . Detta väckte ett intresse för tekniken för att få en mer formell beskrivning. Sedan dess har forskning relaterad till ankarmodellering bedrivits i samarbete mellan skaparna - Ulle Regardt och Lars Rönbeck, samt med deltagande av specialister från institutionen för data- och systemvetenskap vid Stockholms universitet . Det första dokumentet [2] , som formellt beskrev tekniken, presenterades vid den 28:e internationella konferensen om konceptuell modellering [3] och fick priset för bästa papper.
Ankarmodelleringsmaterial är tillgängligt under en Creative Commons-licens . Ett online-simuleringsverktyg finns också tillgängligt, som kan användas fritt och med öppen källkod.
Ankarmodellering har fyra grundläggande modelleringskoncept: ankare, attribut, länkar och noder. Ankare används för att modellera enheter och händelser, attribut används för att modellera egenskaper hos ankare, länkar modellrelationer mellan ankare, noder används för att modellera allmänna egenskaper såsom tillstånd. Attribut och relationer kan tolkas när ändringar i informationen de modellerar behöver sparas.
En exemplifierande modell som visar de olika grafiska symbolerna för de fyra modellkoncepten visas nedan. Symbolerna liknar de som används i Entity and Relationship Modeling- modellen , med flera tillägg.[ specificera ] . En dubbel kontur på ett attribut eller ankare indikerar att en historik över förändringar hålls och en nodsymbol (inringad fyrkant med rundade kanter) är också tillgänglig.
Ankarmodellering styr två typer av informationsutveckling[ förtydliga ] , strukturella förändringar och innehållsförändringar. Förändringar i informationsstrukturen representeras genom tillägg. En hög grad av datanormalisering gör att du oförstörande kan lägga till de nödvändiga modelleringskoncepten som behövs för att genomföra ändringar, så att varje tidigare databasschema alltid förblir som en delmängd av det aktuella schemat . Eftersom det befintliga schemat är orört har detta fördelen att det kan utvecklas till databasen på ett mycket iterativt sätt och inte orsaka några driftstopp.
Ändringar av innehållet i informationen görs genom att emulera liknande funktioner i en temporär databas i en relationsdatabas . I förankrad modellering kan informationsbitar knytas till tidpunkter eller till tidsperioder (både öppna och stängda). Tiderna då händelser inträffar modelleras med hjälp av attribut som människors födelsedatum eller köptider. Tidsintervallen under vilka värdet är giltigt är fixerade genom historisering[ term okänd ] attribut och relationer, såsom förändringar i en persons hårfärg eller hur länge en person har varit gift. I en relationsdatabas uppnås detta genom att lägga till en enda kolumn av datatyp , tillräckligt granulär för att fånga förändringshastigheten i tabellen, motsvarande det historiska attributet eller relationen. Detta lägger till lite komplexitet eftersom mer än en rad i tabellen måste undersökas för att se om intervallet är stängt eller inte.
Punkter eller tidsintervall som inte är direkt associerade med den modellerade domänen, såsom tidpunktsinformation inmatad i en databas, hanteras genom användning av metadata i ankarmodellering och inte i någon av de tidigare nämnda konstruktionerna. Om du vill spara information om sådana ändringar i databasen kan du använda modellering med hänvisning till bidemop[ okänd term ] ankare där, förutom uppdateringar, de borttagna uttalandena blir oförstörande.
Vid ankarmodellering finns det en en-till-en-överensstämmelse mellan symboler som används i en konceptuell modell och tabeller i en relationsdatabas. Varje ankare, attribut, länk och nod har en motsvarande tabell i databasen med en unikt definierad struktur. Således kan en konceptuell modell översättas till ett relationsdatabasschema med enkla automatiserade regler och vice versa. Detta skiljer sig från många andra modelleringstekniker där det finns komplexa och ibland subjektiva översättningssteg mellan de konceptuella, logiska och fysiska nivåerna.
Bindande tabeller innehåller en enda kolumn som lagrar identitetsinformation. Identitet anses vara den enda egenskapen hos ett objekt som alltid är närvarande och oföränderlig. Eftersom identiteter sällan är tillgängliga från domänen som modelleras, genereras de istället tekniskt, t.ex. från en stigande numerisk sekvens.
Ett exempel på ett ankare för att identifiera Kalle Ankas brorsöner är en uppsättning av 1 tuplar:
{⟨#42⟩, ⟨#43⟩, ⟨#44⟩}
Noder kan ses som en kombination av ett ankare och ett enda attribut. Nodtabeller innehåller två kolumner, en för ID och en för värdet. På grund av lagring av identiteter och värden kan noder inte tolkas. Deras användbarhet kommer från förmågan att minska minneskraven och förbättra prestanda, eftersom tabeller som refererar till noder kan lagra ett kort värde snarare än en lång sträng.
En exempelnod för könsgrupper är en uppsättning av två tupler:
{⟨#1, 'Male'⟩, ⟨#2, 'Female'⟩}
Statiska attributtabeller innehåller två kolumner, en för ID för objektet som värdet tillhör och en för det faktiska värdet på egenskapen. Historiska attributtabeller har en extra kolumn för att lagra startpunkten för ett tidsintervall. I en nodattributtabell är värdekolumnen en identifierare som refererar till nodtabellen.
Ett exempel på ett statiskt attribut för deras namn är en 2-tuppel uppsättning:
{⟨#42, 'Huey'⟩, ⟨#43, 'Dewey'⟩, ⟨#44, 'Louie'⟩}
Ett exempel på ett knutet statiskt attribut för deras kön är en uppsättning av två tupler:
{⟨#42, #1⟩, ⟨#43, #1⟩, ⟨#44, #1⟩}
Ett exempel på ett attribut med en historia för de (föränderliga) färgerna på deras outfits är en 3-dubbel uppsättning:
{⟨#44, 'Orange', 1938-04-15⟩, ⟨#44, 'Green', 1939-04-28⟩, ⟨#44, 'Blue', 1940-12-13⟩}
Statiska korsningstabeller länkar två eller flera ankare till varandra och innehåller två eller flera kolumner för att lagra identifierare. Historiskt sett har spännande tabeller en extra kolumn för att lagra startpunkten för tidsintervallet. Länkade tabeller med en nod har en extra kolumn för varje länknod.
Ett exempel på en statisk relation för ett syskonförhållande är en uppsättning av två tupler:
{⟨#42, #43⟩, ⟨#42, #44⟩, ⟨#43, #42⟩, ⟨#43, #44⟩, ⟨#44, #42⟩, ⟨#44, #43⟩}
Alla resulterande tabeller kommer att vara i sjätte normalform , förutom relationer där inte alla kolumner är en del av primärnyckeln.