Første normalform
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.[1]
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[rediger | rediger kilde]
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[rediger | rediger kilde]
Begrunnelsen for normalisering til 1NF er: [2]
- 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[rediger | rediger kilde]
- 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.[trenger referanse]
Historie[rediger | rediger kilde]
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.[3]
Eksempler[rediger | rediger kilde]
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[rediger | rediger kilde]
Denne tabellen over kredittkorttransaksjoner samsvarer ikke med første normalform:
| Kunde | Kunde-ID | Transaksjoner | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Abraham | 1 |
| ||||||||||||
| Isak | 2 |
| ||||||||||||
| Jacob | 3 |
|
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[rediger | rediger kilde]
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å.[4]
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-ID |
|---|---|
| Anne | 1 |
| Ida | 2 |
| Jan | 3 |
| 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 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[rediger | rediger kilde]
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.[5] Codd definerer en atomisk verdi som en verdi som ikke kan dekomponeres til mindre biter av databasehåndteringssystemet (unntatt visse spesialfunksjoner),[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.[7][8] 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,[9][10] 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[rediger | rediger kilde]
I fø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:[11]
- 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.
- En tabell med minst en 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 Codds senere visjon om relasjonsmodellen[12] som ga eksplisitt bestemmelse for nil-verdier.[13] 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.[14]
Referanser[rediger | rediger kilde]
- ^ 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
- ^ Codd, E.F (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM. Classics. 13 (6): 377–87.
- ^ Codd, E. F. (1971). Further Normalization of the Relational Model. Courant Computer Science Symposium 6 in Data Base Systems edited by Rustin, R.
- ^ 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
- ^ Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990).
- ^ Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990), p. 6.
- ^ 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).
- ^ Date, C. J. (2007). What First Normal Form Really Means. Date on Database: Writings 2000–2006. Apress. s. 108. ISBN 978-1-4842-2029-0. «'[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.'»
- ^ Date, C. J. (2007). What First Normal Form Really Means. Date on Database: Writings 2000–2006. Apress. s. 112. ISBN 978-1-4842-2029-0.
- ^ Date, C. J. (6. november 2015). SQL and Relational Theory: How to Write Accurate SQL Code. O'Reilly Media. ISBN 978-1-4919-4115-7. Besøkt 31. oktober 2018.
- ^ Date, C. J. (2007). What First Normal Form Really Means. Date on Database: Writings 2000–2006. Apress. ISBN 978-1-4842-2029-0.
- ^ Date, C. J. «Appendix A.2». SQL and Relational Theory. O'Reilly. «Codd first defined the relational model in 1969 and didn't introduce nulls until 1979»
- ^ Date, C. J. (October 14, 1985). Is Your DBMS Really Relational?. Computerworld. «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.» Sjekk datoverdier i
|dato=(hjelp) (the third of Codd's 12 rules) - ^ Date, C. J. (2007). What First Normal Form Really Means. Date on Database: Writings 2000–2006. Apress. ISBN 978-1-4842-2029-0.