Redigerer Første normalform

'''Første normalform''' ('''1NF''') er en egenskap for en [[relasjon]] i en [[relasjonsdatabase]] som uformelt betyr at ingen [[Kolonne (database)|kolonner]] i en [[Tabell (database)|tabell]] kan ha tabeller som verdier.

Formulert mer formelt tilfredsstilles 1NF [[hvis og bare hvis]] ingen [[Attributtdomene|attributtdomener]] har relasjoner som elementer.<ref>Codd, E.F (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM. Classics. 13 (6): 377–87. p. 380-381</ref>

[[Databasenormalisering]] handler om å bruke standard normalformer for å representere relasjoner i en [[relasjonsdatabase]], hvor første normalform er et minimumskrav. [[SQL-92]] støtter ikke oppretting eller bruk av [[Tabellvaluert kolonne|tabellvaluerte kolonner]], hvilket gitt at man bruker bare tradisjonelle relasjonsdatabase-[[Programvarefunksjon|funksjoner]] (og ser bort fra utvidelser, selv om de kan ha blitt standardisert i senere SQL-versjoner) medfører at de fleste relasjonsdatabaser nødvendigvis vil tilfredsstille første normalform.

Databasesystemer som ikke krever første normalform kalles ofte [[NoSQL]]-systemer. Nyere SQL-standarder som [[SQL:1999]] har begynt å tillate såkalte ikke-[[Atomisk operasjon|atomiske]] typer, som inkluderer [[Sammensatt datatype|sammensatte typer]]. Selv nyere versjoner som [[SQL:2016]] tillater [[JSON]].

== Oversikt ==
I en [[Hierarkisk databasemodell|hierarkisk database]] kan en oppføring inneholde en [[mengde]] barneoppføringer, kjent som repeterende grupper eller tabellvaluerte attributter. Hvis en slik datamodell representeres som relasjoner vil en repeterende gruppe være en attributt hvor verdien er en relasjon i seg selv. Den første normalformen eliminerer nøstede relasjoner ved å gjøre dem om til separate "toppnivå"-relasjoner knyttet til den foreldreraden gjennom [[Fremmednøkkel|fremmednøkler]] i stedet for å direkte inneholde dem.

Hensikten med denne normaliseringen er å øke fleksibiliteten og [[Datauavhengighet|datauavhengigheten]], og å forenkle dataspråket. Det åpner også opp for ytterligere normalisering, hvilket eliminerer [[redundans]] og [[Anomali|anomalier]].

De fleste administrasjonssystemer for relasjonsdatabaser støtter ikke nøstede oppføringer, hvilket medfører at tabeller er i første normalform som standard. Eksempelvis har vanlig [[Structured Query Language|SQL]] ikke opplegg for å opprette eller bruke nøstede tabeller. Normalisering til første normalform vil derfor være et nødvendig steg ved flytting av data fra en hierarkisk database til en relasjonsdatabase.

== Begrunnelse ==
Begrunnelsen for normalisering til 1NF er: <ref>Codd, E.F (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM. Classics. 13 (6): 377–87. </ref>

* Tillater presentasjon, lagring og utveksling av relasjonsdata i form av vanlige todimensjonale tabeller. Å støtte nøstede relasjoner vil kreve mer komplekse datastrukturer.
* Forenkler dataspråket siden alle dataelementer kan identifiseres bare ved relasjonsnavn, attributtnavn og nøkkel. Å støtte nøstede relasjoner vil kreve et mer komplekst språk med støtte for hierarkiske databaner for å adressere nøstede dataelementer.
* Å representere relasjoner ved hjelp av fremmednøkler er mer fleksibelt, mens en hierarkisk modell bare kan representere [[En-til-mange (datamodellering)|en-til-mange-relasjoner]].
* Siden lokalisering av dataelementer ikke er direkte koblet til forelder-barn-hierarkiet er databasen mer motstandsdyktig mot strukturelle endringer over tid.
* Ytterligere normalisering gjøres mulig, hvilket eliminerer dataredundans og anomalier.

== Ulemper og kritikk ==
* Ytelsen blir dårligere for visse operasjoner. I en hierarkisk modell lagres nøstede oppføringer fysisk etter den overordnede oppføringen, hvilket betyr at et helt undertre kan hentes i én enkelt leseoperasjon. På 1NF-form vil det kreve en skjøteoperasjon (''join operation'') per oppføringstype, hvilket kan være beregningsmessig kostbart, særlig for komplekse trær. Av denne grunn unngår [[Dokumentorientert database|dokumentdatabaser]] 1NF.
* [[Objektorientert programmering|Objektorienterte språk]] representerer kjøretidstilstanden som trær eller [[Rettet graf|rettede grafer]] av objekter forbundet via [[Peker (informatikk)|pekere]] eller referanser. Dette kan ikke [[Avbilding (matematikk)|avbildes]] ryddig til en 1NF-relasjonsdatabase, et problem som noen ganger kalles [[Objekt-relasjonell impedansmismatch|objekt-relasjonell impedansulikhet]] og som objekt-relasjonelle avbildingsbiblioteker prøver å løse.
* 1NF har blitt tolket som å ikke tillater komplekse datatyper for verdier. Dette er imidlertid åpent for tolkning, og Christopher John Date har hevdet at verdier kan være vilkårlig komplekse objekter.{{Trenger referanse|date=June 2023}}

== Historie ==
Første normalform ble introdusert i 1070 av Edger Frank Codd i artikkelen ''A Relational Model of Data for Large Shared Data Banks'', og ble opprinnelig bare referert til som "normalform". Den ble omdøpt til "første normalform" i 1971 da flere normalformer ble introdusert i artikkelen ''Further Normalization of the Relational Model''.<ref>Codd, E. F. (1971). Further Normalization of the Relational Model. Courant Computer Science Symposium 6 in Data Base Systems edited by Rustin, R.</ref>

== Eksempler ==
De følgende scenariene illustrerer først hvordan et databasedesign kan bryte første normalform, etterfulgt av eksempler som samsvarer.

=== Design som bryter med 1NF ===
Denne tabellen over kredittkorttransaksjoner samsvarer ikke med første normalform:
{| class="wikitable"
!Kunde
! Kunde-ID
! Transaksjoner
|-
| Abraham
| 1
|
{| class="wikitable"
! Transaksjons-ID
! Dato
! Beløp
|-
| 12890
| 2003-10-14
| 87
|-
| 12904
| 2003-10-15
| 50
|}
|-
| Isak
| 2
|
{| class="wikitable"
! Transaksjons-ID
! Dato
! Beløp
|-
| 12898
| 2003-10-14
|21
|}
|-
| Jacob
| 3
|
{| class="wikitable"
! Transaksjons-ID
! Dato
! Beløp
|-
| 12907
| 2003-10-15
|18
|-
| 14920
| 2003-11-20
|70
|-
| 15003
| 2003-11-27
|60
|}
|}

For hver kunde er det en korresponderende "gjentatt gruppe" av transaksjoner. Et slikt design kan representeres i en hierarkisk database, men ikke i en SQL-database siden SQL ikke støtter nøstede tabeller.

I dette eksempelet vil automatisert evaluering av ethvert spørsmål knyttet til kundenes transaksjoner stort sett omfatte to stadier:

# Utpakking av en eller flere kunders grupper av transaksjoner slik at de enkelte transaksjonene i en gruppe kan undersøkes, og
# Utlede et spørringsresultat basert på resultatene fra den første fasen

For eksempel: For å finne ut pengesummen av alle transaksjoner som skjedde i oktober 2003 for alle kunder må systemet vite at det først skal pakke ut ''transaksjonsgruppen'' til hver kunde, og deretter summere ''beløpene'' for alle transaksjoner hvor ''transaksjonsdatoen'' er 2003 oktober.

En av Codds viktige innsikter var at strukturell kompleksitet kan reduseres. Redusert strukturell kompleksitet gir brukere, applikasjoner og databasehåndteringssystemer mer kraft og fleksibilitet til å formulere og evaluere spørringene. En mer normalisert ekvivalent av strukturen ovenfor kan se slik ut:

=== Design som samsvarer med 1NF ===
For å bringe modellen til første normalform kan den normaliseres. Normalisering (til første normalform) er en prosess der attributter med ikke-enkle domener trekkes ut til separate frittstående relasjoner. De utpakkede relasjonene endres med fremmednøkler som refererer til primærnøkkelen til relasjonen som inneholdt den. Prosessen kan brukes [[Rekursjon|rekursivt]] på ikke-enkle domener nøstet i flere nivå.<ref>Codd, E.F (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM. Classics. 13 (6): 377–87. p. 381</ref>

I dette eksemplet er ''kunde-ID'' primærnøkkelen til de inneholdende relasjonene, og vil derfor bli lagt til som fremmednøkkel til den nye relasjonen:
{| class="wikitable"
!Kunde
! Kunde-ID
|-
|Anne
| 1
|-
|Ida
| 2
|-
|Jan
| 3
|}
{| class="wikitable"
!Kunde-ID
! Transaksjons-ID
! Dato
! Beløp
|-
| 1
| 12890
| 2003-10-14
|87
|-
| 1
| 12904
| 2003-10-15
|50
|-
| 2
| 12898
| 2003-10-14
|21
|-
| 3
| 12907
| 2003-10-15
|18
|-
| 3
| 14920
| 2003-11-20
|70
|-
| 3
| 15003
| 2003-11-27
|60
|}
I den endrede strukturen er [[Nøkkel|primærnøkkelen]] {Kunde-ID} i den første relasjonen, og {Kunde-ID, Transaksjons-ID} nøkkelen i den andre relasjonen.

Nå representerer hver rad en individuell kredittkorttransaksjon, og databasehåndteringssystemet kan finne svaret som ønskes ganske enkelt ved å finne alle rader med dato i 2003 oktober og summere disse beløpene. Datastrukturen plasserer alle verdiene i et konsistent skjema, og eksponerer hver enkelt rad for databasehåndteringssystemet direkte slik at potensielt hver enkelt rad kan delta direkte i spørringer. Til motsetning hadde det forrige unormaliserte eksempelet noen verdier innebygd i strukturer på lavere nivå som måtte håndteres spesielt. Følgelig egner det normaliserte designet seg til generelle spørringer, mens det unormaliserte designet ikke gjør det.

Det er verdt å merke seg at utformingen i dette eksempelet også oppfyller tilleggskravene for [[Andre normalform|andre]] og [[tredje normalform]].

== Atomisitet ==
[[Edgar F. Codd]] sin definisjon av 1NF refererer til begrepet "atomisitet". Ifølge Codd kreves det at verdiene i domenet hvor hver relasjon er definert må være atomiske med hensyn på [[Databasehåndteringssystem|databasehåndteringssystemet]].<ref name="CoddAtmReq">Codd, E. F. ''The Relational Model for Database Management Version 2'' (Addison-Wesley, 1990).</ref> Codd definerer en atomisk verdi som en verdi som ikke kan dekomponeres til mindre biter av databasehåndteringssystemet (unntatt visse spesialfunksjoner),<ref name="CoddAtmDefn">Codd, E. F. ''The Relational Model for Database Management Version 2'' (Addison-Wesley, 1990), p. 6.</ref> hvilket betyr at en kolonne ikke bør deles inn i deler med mer enn én type data i seg slik at hva en del betyr for databasehåndteringssystemet avhenger av en annen del i samme kolonne.

Hugh Darwen og Christopher John Date har antydet at Codd sitt konsept om en "atomisk verdi" er tvetydig, og at denne tvetydigheten har ført til stor forvirring om hvordan 1NF skal forstås.<ref name="Darwen">Darwen, Hugh. "Relation-Valued Attributes; or, Will the Real First Normal Form Please Stand Up?", in C. J. Date and Hugh Darwen, ''Relational Database Writings 1989-1991'' (Addison-Wesley, 1992).</ref><ref>{{Kilde bok|tittel=What First Normal Form Really Means|etternavn=Date|fornavn=C. J.|forfatter-lenke=Christopher J. Date|dato=2007|verk=Date on Database: Writings 2000–2006|utgiver=Apress|isbn=978-1-4842-2029-0|side=108|sitat='[F]or many years,' writes Date, 'I was as confused as anyone else. What's worse, I did my best (worst?) to spread that confusion through my writings, seminars, and other presentations.'}}</ref> Særlig er utsagnet om en "verdi som ikke kan dekomponeres" problematisk ettersom dette kan antyde at få (om noen) datatyper er atomiske:

* Tegnstrenger ser ikke ut til å være atomiske ettersom relasjonelle databasehåndteringssystem vanligvis tilbyr operatorer for å dekomponere dem til delstrenger.
* Fikspunkttall ser ikke ut til å være atomiske, ettersom relasjonelle databasehåndteringssystem vanligvis tilbyr operatorer for å dekomponere dem til heltalls- og brøkkomponenter.
* Et [[ISBN|ISBN-nummer]] ser ikke ut til å være atomisk, ettersom det inkluderer språk og utgiveridentifikator.

Christopher John Date antyder at begrepet atomisitet ikke har noen absolutt betydning,<ref>{{Kilde bok|tittel=What First Normal Form Really Means|etternavn=Date|fornavn=C. J.|forfatter-lenke=Christopher J. Date|dato=2007|verk=Date on Database: Writings 2000–2006|utgiver=Apress|isbn=978-1-4842-2029-0|side=112}}</ref><ref name="Date2015">{{Kilde bok|url=https://books.google.com/books?id=BCjkCgAAQBAJ&pg=PA50|tittel=SQL and Relational Theory: How to Write Accurate SQL Code|etternavn=Date|fornavn=C. J.|dato=6. november 2015|utgiver=O'Reilly Media|besøksdato=31. oktober 2018|isbn=978-1-4919-4115-7}}</ref> altså at en verdi kan betraktes som atomisk for noen formål, men som en sammenstilling av mer grunnleggende elementer for andre formål. Dersom dette aksepteres kan ikke 1NF defineres med hensyn på atomisitet. Kolonner av enhver tenkelig datatype (fra strengtyper og numeriske typer til [[Tabell (datastruktur)|tabell]] og matrisetyper) vil dermed være akseptable i en 1NF-tabell, selv om det kanskje ikke alltid er ønskelig. For eksempel kan det være mer ønskelig å dele opp en kundenavn-kolonne til separate kolonner for fornavn og etternavn.

== 1NF-tabeller som representasjoner av relasjoner ==
I følge Dates definisjon er en tabell i første normalform hvis og bare hvis den er [[Isomorfisme|isomorf]] til en relasjon, hvilket betyr at den spesifikt tilfredsstiller følgende fem betingelser:<ref>{{Kilde bok|tittel=What First Normal Form Really Means|etternavn=Date|fornavn=C. J.|forfatter-lenke=Christopher J. Date|dato=2007|verk=Date on Database: Writings 2000–2006|utgiver=Apress|isbn=978-1-4842-2029-0}}</ref>

# Det er ingen topp-til-bunn-sortering av radene
# Det er ingen venstre-til-høyre rekkefølge for kolonnene
# Det er ingen dupliserte rader
# Snittet av enhver rad og kolonne inneholder bare én verdi fra det aktuelle fra domenet (og ingenting annet)
# Alle kolonner er vanlige (altså ingen rader har skjulte komponenter som rad-ID-er, objekt-ID-er eller skjulte [[Tidsstempel|tidsstempler]].

Brudd på noen av disse betingelsene vil bety at tabellen ikke er strengt relasjonell, og derfor ikke er i første normal form.

Eksempler på tabeller (eller [[Visning (database)|visninger]] ) som ikke vil oppfylle denne definisjonen av første normalform er:

* En tabell uten krav til unik nøkkel. En slik tabell vil kunne inneholde dupliserte rader, som er i strid med betingelse 3.
* En visning hvis definisjon krever at resultater returneres i en bestemt rekkefølge, altså slik at rekkefølgen er et iboende og meningsfullt aspekt av visningen. (Slike visninger kan ikke opprettes med [[Structured Query Language|SQL]] i henhold til [[SQL:2003]]-standarden.) Dette bryter med betingelse 1. [[Tuppel|Tupler]] i ekte relasjoner er ikke ordnet i forhold til hverandre.
* En tabell med minst en [[NULL|nullbar]] attributt. En nullbar attributt vil være i strid med betingelse 4 som krever at hver kolonne inneholder nøyaktig én verdi fra kolonnens domene. Dette aspektet av betingelse 4 er kontroversielt. Det markerer et viktig avvik fra [[Edgar F. Codd|Codds]] senere visjon om [[relasjonsmodellen]]<ref>{{Kilde bok|tittel=SQL and Relational Theory|etternavn=Date|fornavn=C. J.|forfatter-lenke=Christopher J. Date|utgiver=O'Reilly|kapittel=Appendix A.2|sitat=Codd first defined the relational model in 1969 and didn't introduce nulls until 1979}}</ref> som ga eksplisitt bestemmelse for nil-verdier.<ref>{{cite magazine|last=Date|first=C. J.|author-link=Christopher J. Date|date=October 14, 1985|title=Is Your DBMS Really Relational?|magazine=Computerworld|quote=Null values ... [must be] supported in a fully relational DBMS for representing missing information and inapplicable information in a systematic way, independent of data type.}} (the third of Codd's 12 rules)</ref> Den første normalformen, som definert av Christoper John Date, tillater attributter med relasjonsvaluerte attributter (tabeller inni tabeller). Date argumenterer for at attributter med relasjonsvaluerte attributter er nyttige i sjeldne tilfeller.<ref>{{Kilde bok|tittel=What First Normal Form Really Means|etternavn=Date|fornavn=C. J.|forfatter-lenke=Christopher J. Date|dato=2007|verk=Date on Database: Writings 2000–2006|utgiver=Apress|isbn=978-1-4842-2029-0}}</ref>

== Referanser ==
<references/>

{{Databasenormalisering}}

[[Kategori:Datamodellering]]