Første normalform (1NF) er en egenskap for en relasjon i en relasjonsdatabase som uformelt betyr at ingen kolonner i en tabell kan ha tabeller som verdier.
Formulert mer formelt tilfredsstilles 1NF hvis og bare hvis ingen attributtdomener har relasjoner som elementer.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
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 tabellvaluerte kolonner, hvilket gitt at man bruker bare tradisjonelle relasjonsdatabase-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-atomiske typer, som inkluderer sammensatte typer. Selv nyere versjoner som SQL:2016 tillater JSON.
Oversikt I en 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økler i stedet for å direkte inneholde dem.
Hensikten med denne normaliseringen er å øke fleksibiliteten og datauavhengigheten, og å forenkle dataspråket. Det åpner også opp for ytterligere normalisering, hvilket eliminerer redundans og 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 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: Codd, E.F (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM. Classics. 13 (6): 377–87.
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-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 dokumentdatabaser 1NF. Objektorienterte språk representerer kjøretidstilstanden som trær eller rettede grafer av objekter forbundet via pekere eller referanser. Dette kan ikke avbildes ryddig til en 1NF-relasjonsdatabase, et problem som noen ganger kalles 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.
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.Codd, E. F. (1971). Further Normalization of the Relational Model. Courant Computer Science Symposium 6 in Data Base Systems edited by Rustin, R.
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: Kunde Kunde-ID Transaksjoner Abraham 1 Transaksjons-ID Dato Beløp 12890 2003-10-14 87 12904 2003-10-15 50 Isak 2 Transaksjons-ID Dato Beløp 12898 2003-10-1421 Jacob 3 Transaksjons-ID Dato Beløp 12907 2003-10-1518 14920 2003-11-2070 15003 2003-11-2760
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 rekursivt på ikke-enkle domener nøstet i flere nivå.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
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: Kunde Kunde-IDAnne 1Ida 2Jan 3 Kunde-ID Transaksjons-ID Dato Beløp 1 12890 2003-10-1487 1 12904 2003-10-1550 2 12898 2003-10-1421 3 12907 2003-10-1518 3 14920 2003-11-2070 3 15003 2003-11-2760 I den endrede strukturen er 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 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åndteringssystemet.Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990). Codd definerer en atomisk verdi som en verdi som ikke kan dekomponeres til mindre biter av databasehåndteringssystemet (unntatt visse spesialfunksjoner),Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990), p. 6. 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.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). 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-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, 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 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 Ifølge Dates definisjon er en tabell i første normalform hvis og bare hvis den er isomorf til en relasjon, hvilket betyr at den spesifikt tilfredsstiller følgende fem betingelser:
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 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 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 SQL i henhold til SQL:2003-standarden.) Dette bryter med betingelse 1. Tupler i ekte relasjoner er ikke ordnet i forhold til hverandre.