Redigerer Denormalisering

Innen [[Database|databaser]] er '''denormalisering''' en strategi for å manipulere en tidligere [[Databasenormalisering|normalisert]] [[Entitet (informatikk)|tabell]] for å forbedre [[Opprett, les, oppdater og slett|leseytelsen]] til en [[database]], på bekostning av å miste noe [[Opprett, les, oppdater og slett|skriveytelse]], ved å legge til [[Redundans|redundante]] kopier av data eller ved å gruppere data.<ref>G. L. Sanders and S. K. Shin. [https://web.archive.org/web/20171201030308/https://pdfs.semanticscholar.org/2c79/069c01ba8d598f32e61fe367ef6d261a0cb4.pdf Denormalization effects on performance of RDBMS]. In Proceedings of the HICSS Conference, January 2001.</ref><ref>S. K. Shin and G. L. Sanders. [http://portal.acm.org/citation.cfm?id=1217757 Denormalization strategies for data retrieval from data warehouses]. Decision Support Systems, 42(1):267-282, October 2006.</ref> Det er ofte motivert av ytelse eller [[skalerbarhet]] i [[Relasjonsmodellen|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 [[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.

== Denormalisering kontra ikke-normaliserte data ==
{{hoved|Unormalisert form}}En denormalisert datamodell er ikke det samme som en datamodell som [[Unormalisert form|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øteavhengighet|skjøteavhengigheter]] og [[Multivaluert avhengighet|flervaluerte avhengigheter]] håndteres på riktig måte.

Eksempler på teknikker for denormalisering inkluderer:

* Lagre antallet "mange"-elementer i en [[En-til-mange (datamodellering)|en-til-mange-relasjon]] som en [[attributt]] for "en"-relasjonen
* Legge [[Attributt|attributter]] til en relasjon fra en annen relasjon som den skal skjøtes med
* Bruke [[Stjernemodell|stjernemodeller]], som også er kjent som fakta-dimensjonsmodeller og har blitt utvidet til [[Snøflakmodell|snøflakmodeller]]
* Forhåndsbygd summering eller [[OLAP-kube|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.{{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.

== Se også ==
* [[Databasenormalisering|Normalisering]], databasedesign som minimerer duplisering av informasjon
* [[Skalerbarhet]]

== Referanser ==
<references/>

{{Databasenormalisering}}

[[Kategori:Databaser]]