Innendatabaser erdenormalisering en strategi for å manipulere en tidligerenormaliserttabell for å forbedreleseytelsen til endatabase, på bekostning av å miste noeskriveytelse, ved å legge tilredundante kopier av data eller ved å gruppere data.[1][2] Det er ofte motivert av ytelse ellerskalerbarhet irelasjonsdatabaser der det trengs å utføres et stort antall leseoperasjoner.
Denormalisering må ikke forveksles medunormalisert form. Fordelene ved denormalisering kan kun realiseres på en datamodell som ellers er normalisert.
Etnormalisert 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 endatabasespørring som henter informasjon fra flere relasjoner (enskjøteoperasjon). Dersom mange store relasjoner skal skjøtes sammen kan det gå veldig tregt. Det finnes to strategier for å håndtere dette med denormalisering.
En metode er å beholde den logiske utformingen normalisert, men ladatabasehå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 holdeskonsistente. Denne metoden implementeres ofte iSQL som indekserte visninger (Microsoft SQL Server) ellermaterialiserte visninger (Oracle,PostgreSQL). En visning kan representere informasjon i et format som er praktisk for spørring, ogindeksen sikrer at søk mot visningen optimeres fysisk.
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 blirinkonsistente. Det kan implementeres ved å lage regler i databasen kaltbegrensninger (<i>constraints</i>) 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 logiskkompleksitet i databasedesignet som medfører risiko. Dessuten introduserer begrensninger enavveining ved at man øker hastigheten på lesingen (SELECT i SQL) men også bremser skriving (INSERT,UPDATE ogDELETE). Dette betyr at en denormalisert database som belastes med mye skriving kan fådårligere ytelse sammenlignet med en funksjonelt lik normalisert motpart.
Utdypende artikkel:Unormalisert form
En denormalisert datamodell er ikke det samme som en datamodell somunormalisert. 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 medskjøteavhengigheter ogflervaluerte avhengigheter håndteres på riktig måte.
Eksempler på teknikker for denormalisering inkluderer:
Med fortsatt dramatiske økning i lagring, prosessorkraft og båndbredde har denormalisering i databaser gått seg fra å være uvanlig til norm.[når?] 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.