Denormalisering

Innen databaser er **denormalisering** en strategi for å manipulere en tidligere normalisert tabell for å forbedre leseytelsen til en database, på bekostning av å miste noe skriveytelse, ved å legge til redundante kopier av data eller ved å gruppere data. Det er ofte motivert av ytelse eller skalerbarhet i relasjonsdatabaser der det trengs å utføres et stort antall leseoperasjoner.

Denormalisering må ikke forveksles med unormalisert form. Fordelene ved denormalisering kan kun realiseres på en datamodell som ellers er normalisert.

## Implenentering
Et 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 databasespørring som henter informasjon fra flere relasjoner (en 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å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 konsistente. Denne metoden implementeres ofte i SQL som indekserte visninger (Microsoft SQL Server) eller materialiserte visninger (Oracle, PostgreSQL). En visning kan representere informasjon i et format som er praktisk for spørring, og 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 inkonsistente. Det kan implementeres ved å lage regler i databasen kalt begrensninger () 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 i databasedesignet som medfører risiko. Dessuten introduserer begrensninger en avveining ved at man øker hastigheten på lesingen (`[[Select (SQL)|SELECT]]` i SQL) men også bremser skriving (`[[Insert (SQL)|INSERT]]`, `[[Update (SQL)|UPDATE]]` og `[[Delete (SQL)|DELETE]]`). Dette betyr at en denormalisert database som belastes med mye skriving kan få *dårligere* ytelse sammenlignet med en funksjonelt lik normalisert motpart.

## Denormalisering kontra ikke-normaliserte data
En denormalisert datamodell er ikke det samme som en datamodell som unormalisert. Denormalisering bør bare gjøres etter at det er gjennomført en tilfredsstillende grad av normalisering, samt at det er laget eventuelle nødvendige begrensninger og/eller regler for å håndtere uregelmessigheter i dataene. Et eksempel kan være hvis alle relasjonene er på tredje normalform, og alle relasjoner med skjøteavhengigheter og flervaluerte avhengigheter håndteres på riktig måte.

Eksempler på teknikker for denormalisering inkluderer:

* Lagre antallet "mange"-elementer i en en-til-mange-relasjon som en attributt for "en"-relasjonen
* Legge attributter til en relasjon fra en annen relasjon som den skal skjøtes med
* Bruke stjernemodeller, som også er kjent som fakta-dimensjonsmodeller og har blitt utvidet til snøflakmodeller
* Forhåndsbygd summering eller OLAP-kuber

Med fortsatt dramatiske økning i lagring, prosessorkraft og båndbredde har denormalisering i databaser gått seg fra å være uvanlig til norm. For eksempel var det tidligere en stor ulempe at denormalisering bruker mer lagringsplass (bokstavelig talt flere kolonner i en database).  Med unntak av virkelig enorme systemer har dette blitt så å si irrelevant etter fremvekst av billig lagring, og bruk av lagringsplass har i 2020-årene ofte relativt blitt ansett som et lite problem.

## Se også
* Normalisering, databasedesign som minimerer duplisering av informasjon
* Skalerbarhet

## Referanser