Database. SQL – Primærnøkkel

Oversettelse

Jeg legger ut en fortsettelse av oversettelsen av en serie artikler for nybegynnere.
I de nåværende og påfølgende - mer informasjon i bunn og grunn.
Start - .

4. TABELLER OG PRIMÆRE NØKLER

Som du allerede vet fra tidligere deler, lagres data i tabeller, som inneholder linjer eller på annen måte poster. Tidligere ga jeg et eksempel på en tabell som inneholder informasjon om leksjoner. La oss ta en titt på det igjen.

Det er 6 leksjoner i tabellen. Alle 6 er forskjellige, men for hver leksjon lagres verdiene til de samme feltene i tabellen, nemlig: tutorial_id (leksjonsidentifikator), tittel (tittel) og kategori (kategori). Tutorial_id – primærnøkkel leksjonstabeller. En primærnøkkel er en verdi som er unik for hver post i en tabell.
I kundetabellen nedenfor er kunde_id primærnøkkelen. I i dette tilfellet primærnøkkel er også unik verdi(nummer) for hver oppføring.

Primære nøkler i hverdagen

I en database brukes primærnøkler for identifikasjon. I livet er primærnøkler overalt rundt oss. Hver gang du støter på et unikt nummer, kan dette nummeret fungere som en primærnøkkel i databasen (kan, men trenger ikke nødvendigvis, brukes som sådan. Alle databaser er i stand til automatisk å generere en unik verdi for hver post som et nummer som automatisk økes og settes inn sammen med hver Ny inngang[Såkalt syntetisk eller surrogat primærnøkkel – ca. overs.]).

Noen få eksempler

Ordrenummeret du mottar ved kjøp i en nettbutikk kan være primærnøkkelen til en ordretabell i databasen til denne butikken, fordi det er en unik verdi.
Personnummeret kan være primærnøkkelen i en tabell i databasen offentlig etat, fordi den er også unik, som i forrige eksempel.
Fakturanummeret kan brukes som primærnøkkel i en databasetabell som lagrer fakturaer utstedt til kunder.
Det numeriske kundenummeret brukes ofte som primærnøkkel i en kundetabell.

Hva har disse eksemplene til felles? Det faktum at i alle av dem er en unik, ikke-repeterende verdi for hver post valgt som primærnøkkel. En gang til. Verdien til databasetabellfeltet valgt som primærnøkkel er alltid unik.

Hva kjennetegner en primærnøkkel? Kjennetegn ved primærnøkkelen.

Primærnøkkelen brukes til å identifisere poster.

Primærnøkkelen brukes til identifikasjon poster i tabellen, slik at hver post blir unik. En annen analogi... Når du ringer kundeservice teknisk støtte, ber operatøren deg vanligvis om å oppgi et nummer (kontrakt, telefon osv.) som du kan identifiseres med i systemet.
Hvis du har glemt nummeret ditt, vil operatøren for teknisk støtte be deg om å oppgi annen informasjon som vil hjelpe deg med å identifisere deg. For eksempel en kombinasjon av fødselsdagen din og etternavnet. De kan også være en primærnøkkel, eller snarere en kombinasjon av dem.

Hovednøkkelen er unik.

Primærnøkkelen har alltid en unik verdi. Tenk deg at betydningen ikke er unik. Da kunne den ikke brukes til å identifisere dataene i tabellen. Dette betyr at enhver primærnøkkelverdi bare kan vises én gang i kolonnen som er valgt som primærnøkkel. RDBMS-er er utformet på en slik måte at de ikke vil tillate deg å sette inn duplikater i et primærnøkkelfelt, du vil få en feilmelding.
Et eksempel til. Tenk deg at du har en tabell med feltene fornavn og etternavn, og det er to poster:

De. det er to Vasyaer. Du vil velge en spesifikk Vasya fra tabellen. Hvordan gjøre det? Oppføringene er ikke forskjellige fra hverandre. Det er her hovednøkkelen hjelper. Legg til en id-kolonne (den klassiske versjonen av en syntetisk primærnøkkel) og...

Nå er hver Vasya unik.

Typer primærnøkler.

Vanligvis er primærnøkkelen numerisk verdi. Men det kan også være en hvilken som helst annen datatype. Det er ikke vanlig praksis å bruke en streng som primærnøkkel (en streng er et stykke tekst), men det er teoretisk og praktisk mulig.
Sammensatte primærnøkler.
Ofte består en primærnøkkel av et enkelt felt, men det kan også være en kombinasjon av flere kolonner, for eksempel to (tre, fire...). Men du husker at primærnøkkelen alltid er unik, noe som betyr at kombinasjonen av det n-te antallet felt, i dette tilfellet 2, må være unikt. Jeg skal fortelle deg mer om dette senere.

Automatisk nummerering.

Primærnøkkelfeltet blir ofte, men ikke alltid, behandlet av selve databasen. Du kan i utgangspunktet fortelle databasen at den automatisk tildeler en unik numerisk verdi til hver post når den opprettes. Databasen begynner vanligvis å nummerere ved 1 og øker dette tallet med én for hver post. En slik primærnøkkel kalles automatisk inkrementering eller autonummerering. Bruk av auto-inkrementeringsnøkler – riktig vei for å angi unike primærnøkler. Det klassiske navnet på en slik nøkkel er en surrogat primærnøkkel [Som nevnt ovenfor. – ca. overs.]. Denne nøkkelen inneholder ikke nyttig informasjon, knyttet til enheten (objektet), informasjon om hvilken er lagret i tabellen, og det er derfor den kalles surrogat.

5. LINKING AV TABELLER VED BRUK AV UTENLANDSKE NØKLER

Da jeg begynte å utvikle databaser, prøvde jeg ofte å lagre informasjon som virket relatert i en enkelt tabell. Jeg kunne for eksempel lagre ordreinformasjon i en kundetabell. Tross alt tilhører bestillingene kundene, ikke sant? Nei. Kunder og bestillinger er separate enheter i databasen. Begge trenger sitt eget bord. Og postene i disse to tabellene kan kobles sammen for å etablere en relasjon mellom dem. Databasedesign er en løsning på to problemer:

definere hvilke enheter du vil lagre i den
hvilke forbindelser finnes mellom disse enhetene?

En-til-mange.

Kunder og bestillinger har en forbindelse (er i et forhold) en-til-mange fordi en klienten kan ha mye av bestillinger, men hver spesifikke bestilling (deres en haug med) kun utstedt en klient, dvs. kan bare ha én klient. Ikke bekymre deg hvis dette øyeblikket forståelsen av denne sammenhengen er vag. Jeg vil snakke mer om forbindelser i fremtidige deler.

En ting som er viktig nå er at for en-til-mange-kommunikasjon er det nødvendig to separate tabeller. En for kunder, den andre for bestillinger. La oss øve litt på å lage disse to tabellene.

Hvilken informasjon vil vi lagre? La oss løse det første spørsmålet.

Til å begynne med vil vi bestemme hvilken informasjon om bestillinger og om klienter vi skal lagre. For å gjøre dette må vi stille oss selv spørsmålet: "Hvilke informasjonsenheter er relatert til kunder, og hvilke informasjonsenheter er relatert til bestillinger?"

Design av kundebord.

Bestillinger egentlig tilhører kundene, men rekkefølgen er det ikke minimumsblokk med informasjon, som er knyttet til kunder (dvs. denne blokken kan deles inn i mindre: for eksempel ordredato, ordreleveringsadresse osv.).
Feltene nedenfor er minimale blokker informasjon som er relatert til kunder:

kunde_id (primærnøkkel) – kundeidentifikator
fornavn - navn
etternavn - mellomnavn
adresse - adresse
postnummer – postnummer
land - land
fødselsdato – fødselsdato
brukernavn – brukerregistreringsnavn (pålogging)
passord – passord

La oss gå videre til å lage denne tabellen direkte i SQLyog (selvfølgelig kan du bruke et hvilket som helst annet program). Nedenfor er et eksempel på hvordan en tabell kan se ut i SQLyog når den er opprettet. Alle grafiske applikasjoner for databasebehandling har omtrent samme grensesnittstruktur. Du kan også lage en tabell ved hjelp av kommandolinje uten å bruke et grafisk verktøy.

Opprette en tabell i SQLyog. Legg merke til at avmerkingsboksen for primærnøkkel (PK) for kunde_id-feltet er valgt. Customer_id-feltet er primærnøkkelen. Avmerkingsboksen Auto Incr er også valgt, noe som betyr at databasen automatisk vil sette inn en unik numerisk verdi som starter på null og øker med én hver gang.

Design av et ordrebord.
Hva er minimumsopplysningene vi trenger for en bestilling?

order_id (primærnøkkel) – ordreidentifikator
ordredato – ordredato og -klokkeslett
kunde – kunden som foretok bestillingen

Nedenfor er et eksempel på en tabell i SQLyog.

Disse to tabellene ( klienter Og bestillinger) er koblet sammen fordi feltet kunde i ordretabellen refererer til primærnøkkelen ( Kunde ID) kundetabeller. Denne forbindelsen kalles utenlandsk nøkkelforhold. Du bør tenke på en fremmednøkkel som en enkel kopi (en kopi av verdien) av en annen tabells primærnøkkel. I vårt tilfelle er feltverdien Kunde ID fra bordet klienter kopiert til tabellen bestillinger hver gang en post settes inn. Dermed er hver ordre hos oss knyttet til kunden. Og hver klient kan ha mange bestillinger, som nevnt ovenfor.

Opprette et fremmednøkkelforhold.

Du lurer kanskje på: "Hvordan kan jeg forsikre meg om, eller hvordan kan jeg se at kundefeltet i ordretabellen refererer til customer_id-feltet i kundetabellen." Svaret er enkelt - du kan ikke gjøre dette fordi jeg ennå ikke har vist deg hvordan du oppretter en tilkobling.
Nedenfor er SQLyog-vinduet med vinduet jeg brukte for å lage forholdet mellom tabellene.

Opprette et fremmednøkkelforhold mellom ordre- og kundetabellene.

I vinduet over kan du se hvordan kundefeltet til ordretabellen til venstre er knyttet til primærnøkkelen (customer_id) til kundetabellen til høyre.

Nå når du ser på dataene som kan være i tabellene, vil du se at de to tabellene er relatert.

Bestillinger knyttes til kunder gjennom kundefeltet, som refererer til kundetabellen.

På bildet kan du se at klienten mary lagt inn tre bestillinger, kunde pablo plassert en, og klienten john- ingen.
Du kan spørre: "A Hva Er det det alle disse menneskene bestilte?» Det er et godt spørsmål. Du har kanskje forventet å se bestilte varer i bestillingstabellen. Men dette dårlig eksempel design. Hvordan ville du passet inn flere produkter i en enkelt oppføring? Varer er separate enheter som må lagres i en egen tabell. Og forholdet mellom bordene bestillinger Og varer vil være et en-til-mange forhold. Jeg skal snakke om dette videre.

6. LAG ET DIAGRAM FOR ENHETSRELASJON

Tidligere har du lært hvordan poster fra ulike tabeller er knyttet til hverandre i relasjonsdatabaser. Før du oppretter og kobler tabeller, er det viktig at du tenker deg om enheter som finnes på systemet ditt (som du oppretter en database for) og bestemme hvordan disse enhetene vil gjøre det kontaktet sammen. I databasedesign er enheter og deres relasjoner vanligvis gitt i entity-relationship diagram (ERD). Dette diagrammet er resultatet av databasedesignprosessen.

Enheter.

Du lurer kanskje på hva en enhet er. Vel... det er en "ting" i systemet. Der. Moren min ønsket alltid at jeg skulle bli lærer fordi jeg er veldig flink til å forklare ting.

I konteksten database design essens er noe som fortjener din egen tabell i databasemodellen din. Når du designer en database, må du definere disse essens på systemet du oppretter databasen for. Det er mer et spørsmål om dialog med klienten eller med deg selv for å finne ut hvilke data systemet ditt vil jobbe med.

La oss ta en nettbutikk som eksempel. Nettbutikk selger varer. Produkt kan bli en åpenbar enhet i nettbutikksystemet. Varer blir bestiltklienter. Så du og jeg så to mer åpenbare enheter: bestillinger Og klienter.

Bestillingen betales av klienten... dette er interessant. Vi skal skape separat bord for betalinger i databasen til nettbutikken vår? Kan være. Men er betalinger virkelig den minste informasjonen som er knyttet til bestillinger? Dette er også mulig.

Hvis du ikke er sikker, bare tenk på hvilken betalingsinformasjon du vil lagre. Det kan være lurt å lagre betalingsmetode eller betalingsdato. Men dette er fortsatt minimale opplysninger som kan relateres til rekkefølge. Du kan endre ordlyden. Betalingsmåte - betalingsmåte for bestillingen. Betalingsdato – dato for betaling av bestillingen. Så jeg ser ikke behovet for å holde ut betalinger inn i en egen tabell, selv om du konseptuelt kan skille betalinger som en enhet, fordi du kan tenke på betalinger som en beholder med informasjon (betalingsmåte, betalingsdato).

La oss ikke bli for akademiske.

Som du kan se er det forskjell på en enhet og selve tabellen i databasen, dvs. det er ikke det samme. Bransjespesialister informasjonsteknologier kan være VELDIG akademisk og pedantisk i denne saken. Jeg er ikke en slik spesialist. Denne forskjellen avhenger av ditt synspunkt på dataene dine, informasjonen din. Hvis du ser på datamodellering fra synspunktet programvare, så kan du ende opp med mange enheter som ikke kan overføres direkte til databasen. I denne håndboken vi ser på data strengt tatt fra et databaseperspektiv og i vårt liten verden enhet er en tabell.

Hold ut, du er veldig nær å få databasegraden din.

Som du kan se, er det å bestemme hvilke enheter systemet ditt har litt av en intellektuell prosess som krever litt erfaring og ofte er gjenstand for endring, revisjon, refleksjon, men det er selvfølgelig ikke rakettvitenskap.

Et enhetsforholdsdiagram kan være ganske stort hvis du jobber med kompleks applikasjon. Noen diagrammer kan inneholde hundrevis eller til og med tusenvis av tabeller.

Tilkoblinger

Det andre trinnet i databasedesign er å velge hvilke relasjoner som eksisterer mellom enhetene i systemet ditt. Dette kan være litt vanskelig å forstå nå, men igjen, det er ikke rakettvitenskap. Med litt erfaring og nytenkning av arbeidet som er utført, vil du fullføre neste databasemodell riktig eller nesten riktig.

Så. Jeg fortalte deg om forbindelsen en-til-mange og jeg skal fortelle deg mer om tilkoblinger i senere deler av denne veiledningen, så jeg vil ikke dvele mer ved det foreløpig. Bare husk at det er en viktig del å bestemme hvilke relasjoner enhetene dine skal ha database design og disse forbindelsene vises i diagrammet enhetsforhold.

Oversettelse

Jeg legger ut en fortsettelse av oversettelsen av en serie artikler for nybegynnere.
Disse og påfølgende inneholder mer informasjon om fordelene.
Start - .

4. TABELLER OG PRIMÆRE NØKLER

Det er 6 leksjoner i tabellen. Alle 6 er forskjellige, men for hver leksjon lagres verdiene til de samme feltene i tabellen, nemlig: tutorial_id (leksjonsidentifikator), tittel (tittel) og kategori (kategori). Tutorial_id – primærnøkkel leksjonstabeller. En primærnøkkel er en verdi som er unik for hver post i en tabell.
I kundetabellen nedenfor er kunde_id primærnøkkelen. I dette tilfellet er primærnøkkelen også en unik verdi (tall) for hver post.

Primære nøkler i hverdagen

I en database brukes primærnøkler for identifikasjon. I livet er primærnøkler overalt rundt oss. Hver gang du støter på et unikt nummer, kan dette nummeret fungere som en primærnøkkel i databasen (kan, men trenger ikke nødvendigvis, brukes som sådan. Alle databaser er i stand til automatisk å generere en unik verdi for hver post som et nummer som automatisk økes og settes inn sammen med hver ny post [Såkalt syntetisk eller surrogat primærnøkkel – omtrentlig oversettelse]).

Noen få eksempler

Ordrenummeret du mottar ved kjøp i en nettbutikk kan være primærnøkkelen til en ordretabell i databasen til denne butikken, fordi det er en unik verdi.
Et personnummer kan være en primærnøkkel i en tabell i en offentlig database fordi... den er også unik, som i forrige eksempel.
Fakturanummeret kan brukes som primærnøkkel i en databasetabell som lagrer fakturaer utstedt til kunder.
Det numeriske kundenummeret brukes ofte som primærnøkkel i en kundetabell.

Hva kjennetegner en primærnøkkel? Kjennetegn ved primærnøkkelen.

Primærnøkkelen brukes til å identifisere poster.

Primærnøkkelen brukes til identifikasjon poster i tabellen, slik at hver post blir unik. En annen analogi... Når du ringer teknisk støtte, ber operatøren deg vanligvis om å oppgi et nummer (kontrakt, telefon osv.) som du kan identifiseres med i systemet.
Hvis du har glemt nummeret ditt, vil operatøren for teknisk støtte be deg om å oppgi annen informasjon som vil hjelpe deg med å identifisere deg. For eksempel en kombinasjon av fødselsdagen din og etternavnet. De kan også være en primærnøkkel, eller snarere en kombinasjon av dem.

Hovednøkkelen er unik.

Nå er hver Vasya unik.

Typer primærnøkler.

Vanligvis er primærnøkkelen en numerisk verdi. Men det kan også være en hvilken som helst annen datatype. Det er ikke vanlig praksis å bruke en streng som primærnøkkel (en streng er et stykke tekst), men det er teoretisk og praktisk mulig.
Sammensatte primærnøkler.
Ofte består en primærnøkkel av et enkelt felt, men det kan også være en kombinasjon av flere kolonner, for eksempel to (tre, fire...). Men du husker at primærnøkkelen alltid er unik, noe som betyr at kombinasjonen av det n-te antallet felt, i dette tilfellet 2, må være unikt. Jeg skal fortelle deg mer om dette senere.

Automatisk nummerering.

Primærnøkkelfeltet blir ofte, men ikke alltid, behandlet av selve databasen. Du kan i utgangspunktet fortelle databasen at den automatisk tildeler en unik numerisk verdi til hver post når den opprettes. Databasen begynner vanligvis å nummerere ved 1 og øker dette tallet med én for hver post. En slik primærnøkkel kalles automatisk inkrementering eller autonummerering. Å bruke auto-inkrementerende nøkler er en god måte å definere unike primærnøkler. Det klassiske navnet på en slik nøkkel er en surrogat primærnøkkel [Som nevnt ovenfor. – ca. overs.]. En slik nøkkel inneholder ikke nyttig informasjon knyttet til entiteten (objektet), informasjon om hvilken er lagret i tabellen, og det er derfor den kalles surrogat.

5. LINKING AV TABELLER VED BRUK AV UTENLANDSKE NØKLER

definere hvilke enheter du vil lagre i den
hvilke forbindelser finnes mellom disse enhetene?

En-til-mange.

Kunder og bestillinger har en forbindelse (er i et forhold) en-til-mange fordi en klienten kan ha mye av bestillinger, men hver spesifikke bestilling (deres en haug med) kun utstedt en klient, dvs. kan bare ha én klient. Ikke bekymre deg hvis forståelsen din av denne forbindelsen er uklar på dette tidspunktet. Jeg vil snakke mer om forbindelser i fremtidige deler.

En ting som er viktig nå er at for en-til-mange-kommunikasjon er det nødvendig to separate tabeller. En for kunder, den andre for bestillinger. La oss øve litt på å lage disse to tabellene.

Hvilken informasjon vil vi lagre? La oss løse det første spørsmålet.

Design av kundebord.

kunde_id (primærnøkkel) – kundeidentifikator
fornavn - navn
etternavn - mellomnavn
adresse - adresse
postnummer – postnummer
land - land
fødselsdato – fødselsdato
brukernavn – brukerregistreringsnavn (pålogging)
passord – passord

La oss gå videre til å lage denne tabellen direkte i SQLyog (selvfølgelig kan du bruke et hvilket som helst annet program). Nedenfor er et eksempel på hvordan en tabell kan se ut i SQLyog når den er opprettet. Alle grafiske har omtrent samme grensesnittstruktur. Du kan også lage en tabell ved hjelp av kommandolinjen uten å bruke et grafisk verktøy.

Design av et ordrebord.
Hva er minimumsopplysningene vi trenger for en bestilling?

order_id (primærnøkkel) – ordreidentifikator
ordredato – ordredato og -klokkeslett
kunde – kunden som foretok bestillingen

Nedenfor er et eksempel på en tabell i SQLyog.

Opprette et fremmednøkkelforhold.

Opprette et fremmednøkkelforhold mellom ordre- og kundetabellene.

I vinduet over kan du se hvordan kundefeltet til ordretabellen til venstre er knyttet til primærnøkkelen (customer_id) til kundetabellen til høyre.

Nå når du ser på dataene som kan være i tabellene, vil du se at de to tabellene er relatert.

Bestillinger knyttes til kunder gjennom kundefeltet, som refererer til kundetabellen.

På bildet kan du se at klienten mary lagt inn tre bestillinger, kunde pablo plassert en, og klienten john- ingen.
Du kan spørre: "A Hva Er det det alle disse menneskene bestilte?» Det er et godt spørsmål. Du har kanskje forventet å se bestilte varer i bestillingstabellen. Men dette er et dårlig eksempel på design. Hvordan ville du passet inn flere produkter i en enkelt oppføring? Varer er separate enheter som må lagres i en egen tabell. Og forholdet mellom bordene bestillinger Og varer vil være et en-til-mange forhold. Jeg skal snakke om dette videre.

6. LAG ET DIAGRAM FOR ENHETSRELASJON

Enheter.

Du lurer kanskje på hva en enhet er. Vel... det er en "ting" i systemet. Der. Moren min ønsket alltid at jeg skulle bli lærer fordi jeg er veldig flink til å forklare ting.

Bestillingen betales av klienten... dette er interessant. Skal vi lage en egen tabell for betalinger i vår nettbutikkdatabase? Kan være. Men er betalinger virkelig den minste informasjonen som er knyttet til bestillinger? Dette er også mulig.

La oss ikke bli for akademiske.

Som du kan se er det forskjell på en enhet og selve tabellen i databasen, dvs. det er ikke det samme. IT-fagfolk kan være VELDIG akademiske og pedantiske om dette. Jeg er ikke en slik spesialist. Denne forskjellen avhenger av ditt synspunkt på dataene dine, informasjonen din. Hvis du ser på datamodellering fra et programvareperspektiv, kan du ende opp med mange enheter som ikke kan overføres direkte til databasen. I denne opplæringen ser vi på data strengt tatt fra et databaseperspektiv, og i vår lille verden er enheten en tabell.

Hold ut, du er veldig nær å få databasegraden din.

Entitetsforholdsdiagrammet kan være ganske stort hvis du jobber med en kompleks applikasjon. Noen diagrammer kan inneholde hundrevis eller til og med tusenvis av tabeller.

Tilkoblinger

Sist oppdatert: 07/02/2017

Databaser kan inneholde tabeller som er relatert til hverandre ulike forbindelser. Et forhold representerer en assosiasjon mellom enheter av forskjellige typer.

Når du velger en relasjon, velges en primær eller overordnet tabell (primærnøkkeltabell / hovedtabell) og en avhengig underordnet tabell (fremmednøkkeltabell / underordnet tabell). Underordnet tabellen avhenger av overordnet tabellen.

Fremmednøkler brukes til å organisere kommunikasjon. En fremmednøkkel representerer en eller flere kolonner fra en tabell som også er en potensiell nøkkel fra en annen tabell. Fremmednøkkelen trenger ikke samsvare med primærnøkkelen fra hovedtabellen. Selv om som regel en fremmednøkkel fra en avhengig tabell peker til en primærnøkkel fra hovedtabellen.

Forholdet mellom tabeller er av følgende typer:

En til en

En til mange

mange til mange(Mange til mange)

En til en kommunikasjon

Denne typen tilkobling finnes ikke ofte. I dette tilfellet kan et objekt til en enhet bare assosieres med ett objekt til en annen enhet. For eksempel, på noen nettsteder kan en bruker bare ha én blogg. Det vil si at det oppstår et forhold: én bruker – én blogg.

Ofte innebærer denne typen forhold å dele ett stort bord i flere små. Den primære overordnede tabellen fortsetter i dette tilfellet å inneholde data som ofte brukes, mens den underordnede tabellen vanligvis lagrer data som brukes sjeldnere.

I denne forbindelse er primærnøkkelen til den avhengige tabellen samtidig en fremmednøkkel som refererer til primærnøkkelen til hovedtabellen.

Brukere-tabellen representerer for eksempel brukere og har følgende kolonner:

UserId(id, primærnøkkel)

Navn (brukernavn)

Og blogger-tabellen representerer brukerblogger og har følgende kolonner:

BlogId (identifikator, primær- og fremmednøkkel)

Navn (bloggnavn)

I dette tilfellet vil BlogId-kolonnen lagre verdien fra UserId-kolonnen fra brukertabellen. Det vil si at BlogId-kolonnen vil fungere som både en primær og en fremmednøkkel.

Ett til mange forhold

Dette er den vanligste typen tilkobling. I denne typen relasjoner er flere rader fra en underordnet tabell avhengig av en enkelt rad i den overordnede tabellen. En blogg kan for eksempel ha flere artikler. I dette tilfellet er bloggtabellen overordnet og artikkeltabellen er barnet. Det vil si én blogg – mange artikler. Eller et annet eksempel, flere fotballspillere kan spille på et fotballag. Og samtidig kan én fotballspiller kun spille på ett lag om gangen. Det vil si ett lag – mange spillere.

La oss for eksempel ha en tabell kalt Artikler som representerer bloggartikler og har følgende kolonner:

Artikkel-ID(id, primærnøkkel)

BlogId (fremmednøkkel)

Tittel (artikkeltittel)

Tekst (artikkeltekst)

I dette tilfellet vil BlogId-kolonnen fra artikkeltabellen lagre verdien fra BlogId-kolonnen fra bloggtabellen.

mange til mange forhold

Med denne typen relasjoner kan én rad fra tabell A knyttes til mange rader fra tabell B. På sin side kan én rad fra tabell B knyttes til mange rader fra tabell A. Et typisk eksempel er studenter og kurs: én student kan ta flere kurs, og følgelig kan flere studenter melde seg på ett kurs.

Et annet eksempel er artikler og tagger: flere tagger kan defineres for én artikkel, og én tag kan defineres for flere artikler.

Men i SQL Server på databasenivå kan vi ikke etablere en direkte mange-til-mange-relasjon mellom to tabeller. Dette gjøres gjennom et ekstra staging-bord. Noen ganger representerer dataene fra denne oppsamlingstabellen en egen enhet.

Hvis det for eksempel gjelder artikler og tagger, la det være en Tags-tabell som har to kolonner:

TagId(identifikator, primærnøkkel)

Tekst (tag tekst)

La det også være en mellomtabell ArticleTags med følgende felt:

TagId (identifikator, primær- og fremmednøkkel)

ArticleIdId (identifikator, primær- og fremmednøkkel)

Teknisk sett vil vi få to en-til-mange-forhold. TagId-kolonnen fra ArticleTags-tabellen vil referere til TagId-kolonnen fra Tags-tabellen. Og ArticleId-kolonnen fra ArticleTags-tabellen vil referere til ArticleId-kolonnen fra Article-tabellen. Det vil si at kolonnene TagId og ArticleId i ArticleTags-tabellen representerer en sammensatt primærnøkkel og er også fremmednøkler for forholdet til Articles- og Tags-tabellene.

Referensiell dataintegritet

Når du endrer primær- og fremmednøkler, bør følgende aspekter observeres: referansedataintegritet(referanseintegritet). Den grunnleggende ideen er at to tabeller i en database lagrer de samme dataene for å opprettholde konsistens. Dataintegritet representerer riktig konstruerte relasjoner mellom tabeller med riktig installasjon koblinger mellom dem. I hvilke tilfeller kan dataintegriteten krenkes:

Slettingsavvik(slettingsavvik). Oppstår når en rad slettes fra hovedtabellen. I dette tilfellet fortsetter fremmednøkkelen fra den avhengige tabellen å referere slettet linje fra hovedtabellen

Anomali ved innsetting(innsettingsavvik). Oppstår når en rad settes inn i en avhengig tabell. I dette tilfellet samsvarer ikke fremmednøkkelen fra den avhengige tabellen med primærnøkkelen til noen av radene fra hovedtabellen.

Oppdater avvik(oppdateringsavvik). Med en slik anomali kan flere rader i samme tabell inneholde data som tilhører samme objekt. Når du endrer data i én rad, kan det komme i konflikt med data i en annen rad.

Slettingsavvik

For å løse en sletteanomali, må du angi en av to begrensninger på en fremmednøkkel:

Hvis en rad fra en avhengig tabell nødvendigvis krever en rad fra hovedtabellen, settes en kaskadesletting for fremmednøkkelen. Det vil si at når en rad slettes fra hovedtabellen, slettes de tilknyttede raden(e) fra den avhengige tabellen.

Hvis en rad fra en avhengig tabell ikke tillater noen relasjon med en rad fra hovedtabellen (det vil si at et slikt forhold er valgfritt), settes fremmednøkkelen til NULL når den relaterte raden slettes fra hovedtabellen. Kolonnen for fremmednøkkel må være nullbar.

Anomali ved innsetting

For å løse en innsettingsavvik når du legger til data i en avhengig tabell, må kolonnen som representerer fremmednøkkelen være nullbar. Og derfor, hvis det tilføyde objektet ikke har noen forbindelse med hovedtabellen, vil fremmednøkkelkolonnen inneholde en NULL-verdi.

Oppdater avvik

For å løse problemet med oppdateringsavvik brukes normalisering, som vil bli diskutert senere.

Tre hovedenhetsklasser er definert:

1) stang– en selvstendig enhet. Navnene er plassert i et rektangel.

2) Assosiativ– et mange-til-mange-forhold mellom to eller flere enheter. Foreninger behandles som enheter i seg selv. De kan delta i andre foreninger og ha et sett med attributter.

en. Betegnelser (som angir en enhet) er mange-til-en eller en-til-en relasjoner mellom to enheter. Den skiller seg fra en egenskap ved at den ikke er avhengig av den utpekende enheten.

3) Kjennetegn(karakteristisk) – et mange-til-en- eller en-til-en-forhold mellom to enheter. Det er et spesielt tilfelle av assosiasjon. Det eneste formålet med en egenskap er å beskrive eller tydeliggjøre en annen enhet. Eksistensen av en egenskap avhenger helt av enheten som karakteriseres.

En nøkkel eller potensiell nøkkel er bare et sett med attributter hvis verdier kan brukes til å unikt finne den nødvendige forekomsten av en enhet.

Minimalitet betyr at leksikalt sett fra et sett med noen attributter ikke tillater å identifisere enheten med de gjenværende.

En av nøklene tas som primærnøkkel og resten kalles alternative nøkler. En nøkkel som består av ett attributt kalles potensielt enkel. Det er ikke tillatt at primærnøkkelen til en kjerneenhet får en udefinert verdi, ellers oppstår det en motstridende situasjon - en ikke-individuell og derfor ikke-eksisterende forekomst av kjerneenheten vil dukke opp. Av samme grunner er det nødvendig å sørge for at hovednøkkelen er unik.

Hvis enhet C kobler sammen enhetene A og B, må den inkludere fremmednøkler som tilsvarer primærnøklene til enhetene A og B.

For hver fremmednøkkel må tre spørsmål besvares:

1) Kan en ekstra fremmednøkkel godta nullverdier, kort sagt, kan det være en forekomst av en enhet som målenheten spesifisert av fremmednøkkelen er kjent for.

2) Hva skal skje når du prøver å slette målenhet, som refereres til av fremmednøkkelen.

Det er tre muligheter for å løse dette problemet:

· Cascading

· Begrensning

· Innstilling til en bestemt verdi

3) Hva skal skje når du prøver å oppdatere primærnøkkelen til en målenhet som refereres til av en fremmednøkkel.

For hver fremmednøkkel i et databaseprosjekt er det derfor nødvendig å spesialisere ikke bare feltet eller kombinasjonen av felt som utgjør den fremmednøkkelen, men også svarene på spørsmålene ovenfor.

Datatyper og domener.

Den relasjonsdatamodellen er preget av en enkel datastruktur og brukervennlig presentasjon.

Den relasjonsmodellen er designet for å organisere data i form av todimensjonale tabeller. En relasjonstabell er todimensjonal matrise og har følgende egenskaper:

1) Hvert tabellelement er ett dataelement

2) Alle kolonner i tabellen er homogene - alle elementer i kolonnen har samme type og datalengde

3) Hver kolonne har unikt navn

4) Det er ingen identiske rader i tabellen

5) Rekkefølgen på kolonneradene kan være vilkårlig

Datatyper

Alle data som brukes i programmering har sine egne datatyper. Relasjonsmodellen krever at datatypene som brukes er enkle.

Vanligvis er datatyper delt inn i tre grupper:

1) Enkle datatyper

2) Strukturerte typer data

3) referansedatatyper

Enkle (atomære) datatyper har ingen intern struktur. Denne typen data kalles skalar. Disse inkluderer logiske, numeriske og strengdatatyper. Begrepet atomitet er ganske relativt. Dermed kan strengdatatypen betraktes som en endimensjonal rekke av tegn, og hele typen data som et sett med biter. Det eneste viktige her er at når man bytter til slikt lavt nivå semantikk, det vil si betydningen av dataene, går tapt.

Struktureringsdatatyper er ment å spesifisere komplekse strukturer data som er konstruert fra konstituerende elementer, som igjen kan ha en intern struktur (matriser, poster, strukturer).

En referansedatatype er utformet for å gi muligheten til å peke til andre data. Denne datatypen er beregnet på prosedyrespråk som har minneområder for lagring av data.

Til relasjonsmodell data, er ikke typen data som brukes så viktig. Kravet om at datatypen skal være enkel må forstås slik at den ikke skal tas hensyn til i relasjonsoperasjoner intern struktur data.

Domene porno.ru

I den relasjonelle datamodellen er begrepet datatype nært knyttet til begrepet domene, som kan betraktes som en presisering av datatypen.

Domene - semantisk konsept. Det kan betraktes som en delmengde av verdiene til en eller annen datatype.

Domeneegenskaper:

1) domenet har et unikt navn i databasen

2) domenet er definert på noen enkel type data eller på et annet domene

3) et domene kan ha en eller annen logisk tilstand som gjør at man kan beskrive et undersett av data som er gyldig for et gitt domene.

4) domenet har en viss semantisk betydning

For eksempel kan et domene D, som betyr "ansattes alder", beskrives som en delmengde av settet med naturlige tall

D=(nϵN: n ≥ 18 og n ≤ 60)

Forskjellen mellom domenet til begrepet en delmengde er nettopp at domenet reflekterer semantikken til en viss fagområde. Det kan være flere domener som faller sammen som en delmengde, men som har forskjellige betydninger. For eksempel kan domenene "delvekt" og "tilgjengelig mengde" beskrives som et sett med ikke-negative heltall, men betydningen av disse domenene vil være forskjellig, og de vil være forskjellige domener. Hovedbetydningen av domene er at domener begrenser sammenligninger. Det er ikke logisk riktig å sammenligne verdier for forskjellige domener, selv om de er av samme type. Det er syntaktisk riktig å lage en liste over alle deler hvis delvekt er større enn tilgjengelig kvantum, samsvarer ikke med betydningen av begrepene mengde og vekt.

5. Relasjoner og deres egenskaper, attributter og tupler.
Konseptet om et forhold er et grunnleggende konsept i den relasjonsdatamodellen. Relasjonsattributt:<Имя_атрибута: Имя_домена>. Attributtnavn må være unike i forholdet. Ofte er attributtnavnene de samme som de tilsvarende domenenavnene. En eller annen relasjon R, definert på settet av domener D 1 , D 2 , ... D n, inneholder to deler: en overskrift og en kropp. Relasjonshodet inneholder et fast antall relasjonsattributter.

(,,…)

Kroppen i et forhold inneholder mange relasjonskart. Hvert relasjonskart representerer et sett med par av skjemaet

<Имя_атрибута: Значение_атрибута>

(,,… ).

I dette tilfellet tilhører verdien Val i attributten A i D i . verdien er skrevet:

R ( ,,…).

Antall attributter i en relasjon kalles graden eller ariteten til relasjonen. Antall relasjonskort kalles relasjonens kardinalitet. Relasjonshodet beskriver det kartesiske produktet av domener som relasjonen er definert på. Overskriften er statisk. Den endres ikke mens du arbeider med databasen. Hvis attributter endres, legges til eller fjernes fra en relasjon, er resultatet en annen relasjon. Kroppen til en relasjon er et sett med cartes, det vil si en delmengde av det kartesiske produktet av domener og er en relasjon i ordets matematiske betydning. Kroppen i forholdet kan endres mens du arbeider med databasen, det vil si at kort kan endres, legges til og så videre.

En relasjonsdatabase er et sett med relasjoner. Et relasjonsdatabaseskjema er et sett med relasjonsoverskrifter inkludert i en database.

Selv om enhver relasjon kan representeres som en tabell, er en relasjon ikke en tabell. Dette er nære, men ikke tilsvarende begreper. Begrepene som relasjonsdatamodellen opererer har tilsvarende "tabellformede" synonymer.

Egenskaper til relasjoner

Egenskapene til relasjoner består hovedsakelig av forskjeller mellom relasjoner

1) Angående ulik kort.

Kroppen til en relasjon er et sett med cartes og kan, som ethvert sett, ikke inneholde utskillelige elementer. Tabeller, i motsetning til relasjoner, kan inneholde identiske rader.

2) Kartene er ikke sortert (fra topp til bunn) siden kroppen av relasjonen er et sett.

Den samme holdningen kan ikke skildres forskjellige bord, der linjene er i en annen rekkefølge

3) Attributter er ikke sortert fra venstre mot høyre. Siden hvert attributt har et unikt navn i forholdet, spiller ikke rekkefølgen på attributtene noen rolle. Det samme forholdet kan representeres av forskjellige tabeller der kolonnene er i forskjellige rekkefølger.

4) Alle attributtverdier er atomære.

Av egenskapene til en relasjon følger det at ikke hver tabell kan definere relasjoner. For å gjøre dette må hun ha enkel struktur, inneholder ikke identiske rader, noen av kolonnene må inneholde data av bare én type, og alle datatyper som brukes må være enkle.

Utfordringen i logisk design av en relasjonsdatabase er å ta informerte beslutninger om hvilke relasjoner databasen skal bestå av og hvilke attributter disse relasjonene skal ha.

Relasjonsdatamodellen fikser to grunnleggende integritetskrav som må støttes i ethvert relasjons-DBMS.

1) Kravet til integriteten til enheter, som er at ethvert kart over ethvert forhold må kunne skilles fra ethvert annet kart over dette forholdet, det vil si at ethvert forhold må inneholde en primærnøkkel.

2) Referensiell integritetskravet (krav til fremmednøkkelintegritet) er det for hver fremmednøkkelverdi i den refererte relasjonen. Det må være et kart med samme primærnøkkelverdi, eller fremmednøkkelverdien må være udefinert.

Figuren viser en tabell (grad 5) som inneholder noe informasjon om de ansatte i en hypotetisk virksomhet. Tabellrader tilsvarer tupler. Hver rad er faktisk en beskrivelse av ett objekt i den virkelige verden (i dette tilfellet en ansatt), hvis egenskaper er inneholdt i kolonnene. Relasjonelle relasjoner tilsvarer sett med enheter, og tupler tilsvarer enheter. Kolonnene i en tabell som representerer en relasjonsrelasjon kalles attributter.

Hvert attributt er definert på et domene, så et domene kan betraktes som et sett akseptable verdier av denne egenskapen. Flere attributter for samme relasjon, og til og med attributter av forskjellige relasjoner, kan defineres på samme domene.

Et attributt hvis verdi unikt identifiserer tupler kalles nøkkel (eller ganske enkelt nøkkel). Nøkkelen er Personal Number-attributtet, siden verdien er unik for hver ansatt i bedriften. Hvis tupler bare identifiseres ved å sette sammen verdiene til flere attributter, sies relasjonen å ha en sammensatt nøkkel.

Primærnøkkel- i en relasjonsdatamodell, en av de potensielle nøklene til en relasjon, valgt som primærnøkkel (eller standardnøkkel).

En relasjon kan inneholde flere nøkler. En av nøklene er alltid deklarert hoved, verdiene kan ikke oppdateres. Alle andre relasjonsnøkler kalles mulige nøkler.

Fra et teoretisk synspunkt er alle potensielle (mulige) relasjonsnøkler ekvivalente, det vil si at de har samme unikhet og minimalitetsegenskaper. Imidlertid velges primærnøkkelen vanligvis fra de potensielle nøklene som er mest hensiktsmessige for visse praktiske formål, for eksempel for å lage utvendig nøkler i andre henseender eller for å lage en gruppert indeks. Derfor er primærnøkkelen som regel valgt å være den som har minste størrelse(fysisk lagring) og/eller inkluderer det minste antallet attributter.

Hvis primærnøkkel består av et enkelt attributt, kalles det med en enkel nøkkel.

Hvis primærnøkkel består av to eller flere attributter, kalles det sammensatt nøkkel. Så fornavn, etternavn, patronym, passnummer, passserier kan ikke være primærnøkler individuelt, siden de kan være like for to eller flere personer. Men det er ikke to personlige dokumenter av samme type med samme serie og nummer. Derfor, i en relasjon som inneholder data om personer, kan primærnøkkelen være en undergruppe av attributter som består av den personlige dokumenttypen, dens serie og nummer.

I motsetning til hierarkisk og nettverksmodeller I relasjonsdata er det ikke noe begrep om gruppeforhold. For å reflektere assosiasjoner mellom tupler av forskjellige relasjoner, brukes duplisering av nøklene deres.

Attributter som er kopier av nøkler til andre relasjoner kalles fremmednøkler.

For eksempel opprettes relasjonen mellom AVDELINGS- og ANSATTE-relasjonene ved å kopiere primærnøkkelen "Department_number" fra det første forholdet til det andre. For å få en liste over ansatte i en gitt avdeling er det derfor nødvendig: 1) Fra AVDELINGStabellen, angi attributtverdien "Department_number" , som tilsvarer dette "Department_Name". 2) velg alle poster fra ANSATTE-tabellen, attributtverdi "Department_number" som er lik det som ble oppnådd ved forrige trinn. For å finne ut i hvilken avdeling en ansatt jobber, må du utføre omvendt operasjon: 1) Bestem "Department_number" fra ANSATTE-tabellen. 2) Ved å bruke den oppnådde verdien finner vi oppføringen i AVDELINGStabellen.

18. Normalisering i relasjonsdatabaser, konsept normal form ved utforming av databaser.

Normal form - en egenskap ved en relasjon i en relasjonsdatamodell, som karakteriserer den fra et redundanssynspunkt, som potensielt kan føre til logisk feilaktige resultater av sampling eller endring av data. Normalform er definert som et sett med krav som en relasjon skal tilfredsstille.

Prosessen med å konvertere en database til normal form kalles normalisering . Normalisering er ment å bringe databasestrukturen til en form som gir minimal redundans, det vil si at normalisering ikke er ment å redusere eller øke arbeidsproduktiviteten eller redusere eller øke volumet til databasen. Det endelige målet med normalisering er å redusere den potensielle inkonsistensen til informasjon som er lagret i databasen.

Eliminering av redundans utføres som regel ved å dekomponere relasjoner på en slik måte at kun primærfakta lagres i hver relasjon (det vil si fakta som ikke er utledet fra andre lagrede fakta).

Funksjonelle avhengigheter.

Relasjonelt grunnlag data inneholder både strukturell og semantisk informasjon. Strukturen til en database bestemmes av antall og type relasjoner den inneholder, og en-til-mange-relasjonene som eksisterer mellom tuplene til disse relasjonene. Den semantiske delen beskriver settet med funksjonelle avhengigheter som eksisterer mellom egenskapene til disse relasjonene. La oss definere funksjonell avhengighet.

19. 1NF: Grunnleggende definisjoner og transformasjonsregler.

For å diskutere den første normalformen er det nødvendig med to definisjoner:

Enkelt attributt - et attributt hvis verdier er atomære (udelelige).

Kompleks attributt - oppnås ved å kombinere flere atomattributter som kan defineres på en eller forskjellige domener(også kalt en vektor eller dataaggregat).

Definisjon av første normalform:

en relasjon er i 1NF hvis verdiene til alle dens attributter er atomære. . Ellers er det ikke en tabell i det hele tatt, og slike attributter må dekomponeres.

La oss se på et eksempel:

I databasen til virksomhetens HR-avdeling er det nødvendig å lagre opplysninger om ansatte som kan forsøkes presentert ift.

ANSAT(EMPLOYEE_NUMBER, NAVN, FØDSELSDATO, ARBEIDSHISTORIE, BARN).

Fra en nøye vurdering av dette forholdet følger det at attributtene "arbeidshistorie" Og "barn" er komplekse, dessuten attributten "arbeidshistorie" inkluderer et annet komplekst attributt "lønnshistorie".
Disse enhetene ser slik ut:

 JOB_HISTORY (RECEPTION_DATE, NAME, SALARY_HISTORY),

 SALARY_HISTORY (APPOINTMENT_DATE, LØNN),

 CHILDREN (CHILD_NAME, BIRTH_YEAR).

Tilkoblingen deres er vist i fig. 3.3.

Fig.3.3. Innledende holdning.

For å bringe den opprinnelige relasjonen SERVANT til den første normale formen, er det nødvendig å dekomponere den i fire relasjoner, som dette er vist i følgende figur:

Fig.3.4. Normalisert sett med relasjoner.

Her er primærnøkkelen til hvert forhold uthevet med en blå ramme, navnene på fremmednøklene er med skrift av blå farge. Husk at fremmednøkler brukes til å representere funksjonelle avhengigheter som finnes i kilderelasjonen. Disse funksjonelle avhengighetene er indikert med linjer med piler.

Normaliseringsalgoritmen er beskrevet av E.F. Codd som følger:

Starter med relasjonen øverst i treet (Figur 3.3.), tas dens primærnøkkel, og hver umiddelbart underordnede relasjon utvides ved å sette inn et domene eller en kombinasjon av domener for den primærnøkkelen.
Primærnøkkelen til hver relasjon utvidet på denne måten består av primærnøkkelen som relasjonen hadde før utvidelsen og den ekstra primærnøkkelen til overordnet relasjon.
Etter dette blir alle ikke-enkle domener slettet fra overordnet relasjon, toppnoden i treet fjernes, og samme prosedyre gjentas for hvert av de gjenværende undertrærne.

20. 2NF: Grunnleggende definisjoner og transformasjonsregler.

Svært ofte inkluderer primærnøkkelen til et forhold flere attributter (i så fall kalles den sammensatte) - se for eksempel forholdet BARN vist i fig. 3.4 spørsmål 19. Samtidig introduseres begrepet full funksjonell avhengighet.

Definisjon:

et ikke-nøkkelattributt er funksjonelt fullstendig avhengig av en sammensatt nøkkel hvis det er funksjonelt avhengig av hele nøkkelen som helhet, men er ikke funksjonelt avhengig av noen av dens konstituerende attributter.

Eksempel:

La det være en relasjon SUPPLY (N_SUPPLIER, PRODUCT, PRICE).
En leverandør kan levere forskjellige produkter, og samme produkt kan leveres av forskjellige leverandører. Da er relasjonsnøkkelen "N_leverandør + produkt". La alle leverandører levere varer til samme pris. Da har vi følgende funksjonelle avhengigheter:

N_leverandør, produkt -> pris
produkt -> pris

Den ufullstendige funksjonelle avhengigheten til "pris"-attributtet på nøkkelen fører til følgende anomali: når prisen på et produkt endres, er det nødvendig Full utsikt forhold for å endre alle opplysninger om sine leverandører. Denne anomalien er en konsekvens av at to semantiske fakta er kombinert i én datastruktur. Følgende utvidelse gir relasjonene i 2NF:

LEVERING (N_SUPPLIER, PRODUKT)
PRODUCT_PRICE (PRODUCT, PRICE)

Så du kan gi

Definisjon av andre normalform: En relasjon er i 2NF hvis den er i 1NF og hvert ikke-nøkkelattributt er fullt funksjonelt avhengig av nøkkelen.

21. 3NF: Grunnleggende definisjoner og transformasjonsregler.

Før vi diskuterer tredje normalform, er det nødvendig å introdusere konseptet: transitiv funksjonell avhengighet.

Definisjon:

La X, Y, Z være tre attributter av en eller annen relasjon. I dette tilfellet X --> Y og Y --> Z, men det er ingen omvendt korrespondanse, dvs. Z -/-> Y og Y -/-> X. Da avhenger Z transitivt av X.
La det være en relasjon LAGRING ( FAST, WAREHOUSE, VOLUME), som inneholder informasjon om selskaper som mottar varer fra varehus og volumene til disse lagrene. Nøkkelattributt - "fast". Hvis hvert selskap kan motta varer fra bare ett lager, er det i denne forbindelse følgende funksjonelle avhengigheter:

fast -> lager
lager -> volum

I dette tilfellet oppstår anomalier:

hvis for øyeblikket ingen bedrifter mottar varer fra lageret, kan ikke data om volumet legges inn i databasen (siden nøkkelattributtet ikke er definert)
hvis lagervolumet endres, er det nødvendig å se hele forholdet og endre kortene for alle selskaper tilknyttet dette lageret.

For å eliminere disse anomaliene, er det nødvendig å dekomponere den opprinnelige relasjonen i to:

OPPBEVARING ( FAST, LAGER)
STORAGE_VOLUME ( LAGER, VOLUM)

Definisjon av tredje normalform:

En relasjon er i 3NF hvis den er i 2NF og hvert ikke-nøkkelattributt er ikke transitivt avhengig av primærnøkkelen.