Redigerer Denormalisering (avsnitt)

== Implenentering ==
Et [[Databasenormalisering|normalisert]] design vil ofte lagre forskjellige men relaterte opplysninger i separate logiske tabeller (kalt relasjoner). Hvis disse relasjonene lagres fysisk som separate filer kan det gå tregt å kjøre en [[Informasjonsgjenfinning|databasespørring]] som henter informasjon fra flere relasjoner (en [[Join (SQL)|skjøteoperasjon]]). Dersom mange store relasjoner skal skjøtes sammen kan det gå veldig tregt. Det finnes to strategier for å håndtere dette med denormalisering.

* Støtte i databasehåndteringssystemet: Programvaren lagrer redundante kopier i bakgrunnen, som holdes konsistente av programvaren
* Manuell implementering: Databaseadministratoren (eller designeren) designer rundt problemet ved å denormalisere det logiske datadesignet

=== Støtte i databasehåndteringssystemet ===
En metode er å beholde den logiske utformingen normalisert, men la [[Databasehåndteringssystem|databasehåndteringssystemet]] (DBMS) lagre ekstra redundant informasjon på disken for å optimere spørreresponsen. I dette tilfellet er det programvarens ansvar å sørge for at eventuelle overflødige kopier holdes [[Konsistens (informatikk)|konsistente]]. Denne metoden implementeres ofte i [[Structured Query Language|SQL]] som indekserte visninger ([[Microsoft SQL Server]]) eller [[Materialisert visning|materialiserte visninger]] ([[Oracle Database|Oracle]], [[PostgreSQL]]). En visning kan representere informasjon i et format som er praktisk for spørring, og [[Indeksering (datateknologi)|indeksen]] sikrer at søk mot visningen optimeres fysisk.

=== Manuell implementering ===
En annen tilnærming er å denormalisere det logiske datadesignet. Dette kan gi lignende forbedring i spørrerespons, men legger mye ansvar på databasedesigneren for å unngå at resultatene blir [[Atomisk, konsistent, isolert, durabel|inkonsistente]]. Det kan implementeres ved å lage regler i databasen kalt [[Tilfredsstillelse av begrensninger|begrensninger]] (<nowiki><i>constraints</i></nowiki>) som spesifiserer hvordan de redundante kopiene av informasjon må holdes synkronisert, hvilket fort kan gjøre denormaliseringsprosedyren meningsløs. De de ekstra begrensningene gir en økning i logisk [[Kompleksitet ved tilfredsstillelse av begrensninger|kompleksitet]] i databasedesignet som medfører risiko. Dessuten introduserer begrensninger en [[avveining]] ved at man øker hastigheten på lesingen (<code>[[Select (SQL)|SELECT]]</code> i SQL) men også bremser skriving (<code>[[Insert (SQL)|INSERT]]</code>, <code>[[Update (SQL)|UPDATE]]</code> og <code>[[Delete (SQL)|DELETE]]</code>). Dette betyr at en denormalisert database som belastes med mye skriving kan få ''dårligere'' ytelse sammenlignet med en funksjonelt lik normalisert motpart.