Normalisering er en teknikk for databasedesign, som brukes til å designe en relasjonell databasetabell opp til høyere normalform. Prosessen er progressiv, og et høyere nivå av databasenormalisering kan ikke oppnås med mindre tidligere nivåer er oppfylt.
Det betyr at det å ha data i unormalisert form (den minst normaliserte) og sikte på å oppnå det høyeste normaliseringsnivå, ville det første trinnet være å sikre samsvar med den første normale formen, det andre trinnet ville være å sikre at den andre normale formen ble oppfylt, og så videre i den rekkefølgen som er nevnt ovenfor, til dataene samsvarer med sjette normale form. >
Det er imidlertid verdt å merke seg at normale former utover 4NF hovedsakelig er av akademisk interesse, ettersom problemene de eksisterer for å løse sjelden vises i praksis.
Vær oppmerksom på at dataene i følgende eksempel var med vilje designet for å motsi de fleste normale former. I det virkelige liv er det fullt mulig å kunne hoppe over noen av normaliseringstrinnene, fordi tabellen ikke inneholder noe som motsier den gitte normale formen. Det forekommer ofte at å fikse brudd på en normal form også løser brudd på en høyere normal form i prosessen. Det er også valgt en tabell for normalisering på hvert trinn, noe som betyr at det på slutten av denne eksempelprosessen fortsatt kan være noen tabeller som ikke tilfredsstiller den høyeste normale formen.
Initial dataEdit
La en databasetabell med følgende struktur:
| Tittel | Forfatter | Forfatter Nasjonalitet | Format | Pris | Emne | Sider | Tykkelse | Utgiver | Utgiverland | Publikasjonstype | Genre ID | Genre Name |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Start MySQL Database Design and Optimization | Chad Russell | American | Innbundet | 49,99 | MySQL,
Database, Design |
520 | Tykk | Apress | USA | E-bok | 1 | Veiledning |
Vi antar i dette eksemplet at hver bok bare har en forfatter.
Tilfredsstillende 1NFEdit
For å tilfredsstille 1NF må verdiene i hver kolonne i en tabell være atomare. I den første tabellen inneholder Emne et sett med emneverdier, noe som betyr at det ikke samsvarer.
En måte å oppnå 1NF på ville være å skille duplikatene i flere kolonner ved hjelp av gjentatte grupper Emne:
| Tittel | Format | Forfatter | Forfatter Nasjonalitet | Pris | Emne 1 | Emne 2 | Emne 3 | Sider | Tykkelse | Utgiver | Utgiverland | Genre ID | Genre Name |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Begynner MySQL-databasedesign og optimalisering | Innbundet | Chad Russell | Amerikansk | 49,99 | MySQL | Database | Design | 520 | Tykk | Apress | USA | 1 | Veiledning |
Selv om tabellen nå formelt samsvarer med 1NF (er atom), er problemet med denne løsningen åpenbar – hvis en bok har mer enn tre emner, den kan ikke legges til databasen uten å endre strukturen.
For å løse problemet på en mer elegant måte er det nødvendig å identifisere enheter representert i tabellen og skille dem inn i sine respektive respektive tabeller. I dette tilfellet vil det resultere i bok-, emne- og forlagstabeller:
| Tittel | Format | Forfatter | Forfatter Nasjonalitet | Pris | Sider | Tykkelse | Genre ID | Genre Name | Publisher ID |
|---|---|---|---|---|---|---|---|---|---|
| Begynner MySQL Database Design and Optimization | Hardcover | Chad Russell | American | 49.99 | 520 | Tykk | 1 | Veiledning | 1 |
|
|
Bare å skille de opprinnelige dataene i flere tabeller vil bryte forbindelsen mellom dataene. Det betyr at forholdet mellom de nylig introduserte tabellene må bestemmes. Legg merke til at kolonnen Publisher ID i bokens tabell er en fremmed nøkkel som realiserer mange-til-en-forhold mellom en bok og en forlegger.
En bok kan passe mange emner, så vel som et emne kan tilsvarer mange bøker. Det betyr også at mange-til-mange-forhold må defineres, oppnås ved å opprette en lenketabell:
|
I stedet for en tabell i unormalisert form, er det nå 4 tabeller som samsvarer med 1NF.
Tilfredsstille 2NFEdit
Boktabellen har en kandidatnøkkel (som derfor er den primære nøkkelen), den sammensatte nøkkelen {Tittel, Format}. Tenk på følgende tabellfragment:
| Tittel | Format | Forfatter | Forfatter Nasjonalitet | Pris | Sider | Tykkelse | Genre ID | Genre Name | Publisher ID |
|---|---|---|---|---|---|---|---|---|---|
| Start MySQL Database Design and Optimization | Innbundet | Chad Russell | Amerikansk | 49,99 | 520 | Tykt | 1 | Opplæring | 1 |
| Begynner MySQL-databasedesign og optimalisering | E-bok | Chad Russell | Amerikansk | 22.34 | 520 | Tykk | 1 | Opplæring | 1 |
| Relasjonsmodellen for databaseadministrasjon: Versjon 2 | E-bok | EFCodd | Britisk | 13,88 | 538 | Tykt | 2 | Populærvitenskap | 2 |
| Relasjonsmodellen for databasen Ma administrasjon: Versjon 2 | Paperback | EFCodd | Britisk | 39.99 | 538 | Tykk | 2 | Populærvitenskap | 2 |
Alle attributtene som ikke er en del av kandidatnøkkelen, avhenger av Tittel, men bare Pris avhenger også av Format. For å overholde 2NF og fjerne duplikater, må alle ikke-kandidatnøkkelattributter avhenge av hele kandidatnøkkelen, ikke bare en del av den.
For å normalisere denne tabellen, gjør du {Title} til en (enkel) kandidatnøkkel (den primære nøkkelen) slik at alle ikke-kandidat-nøkkelegenskaper avhenger av hele kandidatnøkkelen, og fjern Price i en egen tabell slik at dens avhengighet av Format kan bevares:
|
|
Nå, Boktabellen er i samsvar med 2NF.
Tilfredsstillende 3NFEdit
Boktabellen har fremdeles en transitiv funksjonell avhengighet ({Author Nationality} er avhengig av {Author}, som er avhengig av {Title }). Et lignende brudd eksisterer for sjanger ({Genre Name} er avhengig av {Genre ID}, som er avhengig av {Title}). Derfor er ikke Book-tabellen i 3NF. For å gjøre det i 3NF, la oss bruke følgende tabellstruktur, og dermed eliminere de transitive funksjonelle avhengighetene ved å plassere {Author Nationality} og {Genre Name} i sine egne respektive tabeller:
| Tittel | Forfatter | Sider | Tykkelse | Genre ID | Publisher ID |
|---|---|---|---|---|---|
| Begynner MySQL-databasedesign og Optimalisering | Chad Russell | 520 | Tykk | 1 | 1 |
| Relasjonsmodellen for databasestyring: Versjon 2 | EFCodd | 538 | Tykk | 2 | 2 |
|
| Forfatter | Forfatter Nasjonalitet |
|---|---|
| Chad Russell | Amerikansk |
| EFCodd | Britisk |
| Gen. re ID | Genre Name |
|---|---|
| 1 | Tutorial |
| 2 | Populærvitenskap |
Tilfredsstillende EKNFEdit
Elementær nøkkel normalform (EKNF) faller strengt mellom 3NF og BCNF og er ikke mye diskutert i litteraturen. Det er ment «å fange opp de fremtredende egenskapene til både 3NF og BCNF» og samtidig unngå problemene til begge deler (nemlig at 3NF er «for tilgivende» og BCNF er «utsatt for beregningskompleksitet»). det er ikke inkludert i dette eksemplet.
Tilfredsstillende 4NFEdit
Anta at databasen eies av en franchise for bokforhandlere som har flere franchisetakere som eier butikker forskjellige steder.Og derfor bestemte forhandleren seg for å legge til en tabell som inneholder data om tilgjengeligheten av bøkene på forskjellige steder:
| Franchisetaker-ID | Tittel | Plassering |
|---|---|---|
| 1 | Begynnelse av MySQL-databasedesign og optimalisering | California |
| 1 | Begynnelse av MySQL-databasedesign og optimalisering | Florida |
| 1 | Begynner MySQL-databasedesign og optimalisering | Texas |
| 1 | Relasjonsmodellen for databaseadministrasjon: Versjon 2 | California |
| 1 | Relasjonsmodellen for databaseadministrasjon: versjon 2 | Florida |
| 1 | Relasjonsmodellen for databasestyring: versjon 2 | Texas |
| 2 | Begynner MySQL-databasedesign og optimalisering | California |
| 2 | MySQL-databasedesign og optimalisering begynner | Florida |
| 2 | Begynner MySQL-databasedesign og optimalisering | Texas |
| 2 | Relasjonsmodellen for databaseadministrasjon: Versjon 2 | California |
| 2 | Relasjonsmodellen for databaseadministrasjon: Versjon 2 | Florida |
| 2 | Relasjonsmodellen for databaseadministrasjon: Versjon 2 | Texas |
| 3 | Begynner MySQL databasedesign og optimalisering | Texas |
Ettersom denne tabellstrukturen består av en sammensatt primærnøkkel, inneholder den ikke noen ikke-nøkkelattributter, og den er allerede i BCNF (og tilfredsstiller derfor også alle tidligere normale former). Imidlertid, hvis vi antar at alle tilgjengelige bøker tilbys i hvert område, vil vi kanskje legge merke til at tittelen ikke er entydig bundet til en bestemt plassering, og derfor tilfredsstiller tabellen ikke 4NF.
Det betyr at, for å tilfredsstille den fjerde normale formen, må denne tabellen også dekomponeres:
|
|
||||||||||||
| Franchisetaker-ID | Plassering | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | California | ||||||||||||
| 1 | Florida | ||||||||||||
| 1 | Texas | ||||||||||||
| 2 | California | ||||||||||||
| 2 | Florida | ||||||||||||
| 2 | Texas | ||||||||||||
| 3 | Texas |
Nå blir hver post entydig identifisert av en supernøkkel, derfor er 4NF tilfreds.
Tilfredsstillende ETNFEdit
Anta at franchisetakerne også kan bestille bøker fra forskjellige leverandører. La forholdet også være underlagt følgende begrensning:
- Hvis en bestemt leverandør leverer en viss tittel
- og tittelen blir levert til franchisetaker
- og franchisetaker blir levert av leverandøren,
- så leverer leverandøren tittelen til franchisetaker.
| Leverandør-ID | Tittel | Franchisetaker-ID |
|---|---|---|
| 1 | Begynner MySQL-databasedesign og optimalisering | 1 |
| 2 | Relasjonsmodellen for databasestyring: Versjon 2 | 2 |
| 3 | Læring SQL | 3 |
Denne tabellen er i 4NF, men leverandør-ID er lik sammenføyningen av fremskrivningene: {{leverandør-ID, bok}, {bok, franchisetaker-ID}, {franchisetaker-ID, leverandør ID}}.Ingen komponent i den tilknytningsavhengigheten er en supernøkkel (den eneste supernøkkelen er hele overskriften), så tabellen tilfredsstiller ikke ETNF og kan videre dekomponeres:
|
|
|
Nedbrytningen gir ETNF-samsvar.
Tilfredsstillende 5NFEdit
For å få øye på et bord som ikke tilfredsstiller 5NF, er det er vanligvis nødvendig for å undersøke dataene grundig. Anta at tabellen fra 4NF-eksemplet med en liten modifikasjon i data og la oss undersøke om den tilfredsstiller 5NF:
| Franchisetaker-ID | Tittel | Plassering |
|---|---|---|
| 1 | Begynner MySQL-databasedesign og optimalisering | California |
| 1 | Læring SQL | California |
| 1 | Relasjonsmodellen for databaseadministrasjon: Versjon 2 | Texas |
| 2 | Relasjonsmodellen for databaseadministrasjon: Versjon 2 | California |
Hvis vi nedbryter denne tabellen, reduserer vi permitteringer og får følgende to tabeller:
|
|
Hva skjer hvis vi prøver å bli med i disse tabellene? Spørringen vil returnere følgende data:
| Franchisetaker-ID | Tittel | Plassering |
|---|---|---|
| 1 | Begynner MySQL-databasedesign og Optimalisering | California |
| 1 | Læring SQL | California |
| 1 | Relasjonsmodellen for databaseadministrasjon: Versjon 2 | California |
| 1 | Relasjonsmodellen for databaseadministrasjon: Versjon 2 | Texas |
| 1 | Learning SQL | Texas |
| 1 | Begynner MySQL-databasedesign og optimalisering | Texas |
| 2 | Relasjonsmodellen for databasestyring: Versjon 2 | California |
JOIN returnerer tilsynelatende tre rader til enn det burde – la oss prøve å legge til ano tabellen for å avklare forholdet.Vi ender med tre separate tabeller:
|
|
|
Hva vil JOIN returnere nå? Det er faktisk ikke mulig å bli med i disse tre tabellene. Det betyr at det ikke var mulig å spalte franchisetaker – bokplassering uten tap av data, derfor oppfyller tabellen allerede 5NF.
CJ Date har hevdet at bare en database i 5NF virkelig er «normalisert».
Tilfredsstillende DKNFEdit
La oss se på boktabellen fra tidligere eksempler og se om den tilfredsstiller domenenøkkelens normale form:
| Tittel | Sider | Tykkelse | Genre ID | Publisher ID | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Start MySQL Database Design and Optimization | 520 | Tykt | 1 | 1 | ||||||||||||||||||||||||||
| Relasjonsmodellen for databaseadministrasjon: Versjon 2 | 538 | Tykt | 2 | 2 | ||||||||||||||||||||||||||
| Læring SQL | 338 | Slim | 1 | 3 | ||||||||||||||||||||||||||
| SQL Cookbook | 636 | Tykt | 1 | 3 |
|
|
På den måten er brudd på domeneintegriteten eliminert, og tabellen er i DKNF.
Tilfredsstillende 6NFEdit
En enkel og intuitiv definisjon av den sjette normale formen er at «en tabell er i 6NF når raden inneholder primærnøkkelen, og maksimalt ett annet attributt».
Det betyr for eksempel Publisher-tabellen designet mens du opprettet 1NF
| Publisher_ID | Name | Country |
|---|---|---|
| 1 | Apress | USA |
må være lenger dekomponert i to tabeller:
|
|
Den åpenbare ulempen med 6NF er spredning av tabeller som kreves for å representere informasjonen om en enkelt enhet. Hvis en tabell i 5NF har en primær nøkkelkolonne og N-attributter, vil det å representere den samme informasjonen i 6NF kreve N-tabeller; flerfeltoppdateringer til en enkelt konseptuell post vil kreve oppdateringer til flere tabeller; og innsatser og slettinger vil på samme måte kreve operasjoner på tvers av flere tabeller. Av denne grunn bør 6NF ikke brukes i databaser som er ment å betjene behovet for online transaksjonsbehandling.
Imidlertid i datalager som ikke tillater interaktive oppdateringer og som er spesialiserte for raske spørsmål på store datamengder. bestemte DBMS-er bruker en intern 6NF-representasjon – kjent som en Columnar-datalager. I situasjoner der antall unike verdier i en kolonne er langt mindre enn antall rader i tabellen, tillater kolonneorientert lagring betydelige besparelser i plass gjennom datakomprimering. Kolonnelagring tillater også rask kjøring av rekkeviddesøk (f.eks. Viser alle poster der en bestemt kolonne er mellom X og Y, eller mindre enn X.)
I alle disse tilfellene gjør databasedesigneren imidlertid ikke må utføre 6NF-normalisering manuelt ved å opprette separate tabeller. Noen DBMS-er som er spesialiserte for lagring, for eksempel Sybase IQ, bruker kolonnelagring som standard, men designeren ser fortsatt bare en enkelt flerkolonnetabell. Andre DBMSer, for eksempel Microsoft SQL Server 2012 og nyere, lar deg spesifisere en «kolonnelagerindeks» for en bestemt tabell.
