sql >> Database teknologi >  >> RDS >> Database

Hvad er en kandidatnøgle i databasedesign?

En kandidatnøgle er et vigtigt begreb i databasenormalisering. Læs videre for at finde ud af, hvad en kandidatnøgle er, og hvordan du kontrollerer, om et sæt attributter er en kandidatnøgle.

kandidatnøglen, også blot kaldet en nøgle er en vigtig del af databasedesign. Det er det teoretiske grundlag for tekniske begreber som primære og alternative (unikke) nøgler. Enhver databasedesigner bør være opmærksom på, hvordan man identificerer kandidatnøgler, og hvordan man vælger den rigtige til deres bord.

Begrebet kandidatnøglen undervises i alle universitetets databasekurser som en del af databasenormaliseringsteorien. De almindelige problemer, du vil støde på, når du lærer om kandidatnøgler, er at verificere, om et givet sæt attributter er en kandidatnøgle, og at finde alle kandidatnøgler til en relation.

Det er vigtigt at forstå kandidatnøgler for at forstå de normale former i databasetabeller. Denne viden vil hjælpe dig med at huske reglerne for de mest almindelige normale former.

I denne artikel vil vi forklare konceptet med kandidatnøgler i enkle vendinger. Derudover viser vi dig, hvordan du bekræfter, om et sæt attributter er en kandidatnøgle.

Grundlæggende terminologi for databasenormalisering

Før du læser om kandidatnøgler, skal du sikre dig, at du er fortrolig med den grundlæggende normaliseringsterminologi. Lad os kort gennemgå de vigtigste udtryk.

En relation er det teoretiske navn for en databasetabel. En relation (tabel) har et navn og består af navngivne attributter (kolonner).

En funktionel afhængighed i en relation (A -> B ) fortæller dig, at når to rækker har de samme værdier for alle attributter i sæt A, vil de også have de samme værdier for alle attributter i sæt B.

lukningen af et sæt attributter er det sæt af de attributter, der funktionelt kan bestemmes ud fra dette sæt. Du kan gennemgå algoritmen til at beregne lukningen af ​​attributter her.

Supernøgler

Uformelt er en kandidatnøgle et sæt attributter, der entydigt identificerer en række.

Per definition er en kandidatnøgle en minimal supernøgle. Så hvad betyder det? En supernøgle er en attribut eller et sæt attributter, således at dens lukning er alle attributter i relationen.

Lad os se nogle eksempler. Her har vi tabellen CourseEditions. Den gemmer oplysninger om kursusudgaver.

Hvert år kan et givet kursus undervises af en anden lærer, med en anden pris og forskellig pladsbegrænsning. Vi har således følgende funktionelle afhængigheder:

  • id -> kursus, årgang, lærer, pris, pladser – ID'et bestemmer alle andre attributter
  • kursus, årstal -> id, lærer, pris, pladser – kurset og året bestemmer ID, lærer, pris og pladser.

CourseEditions

id kursus år lærer pris pletter
1 Databaser 2019 Chris Cape 100 45
2 Matematik 2019 Daniel Parr 80 34
3 Databaser 2020 Jennifer Clock 110 30

Hvad er supernøglerne i denne tabel? For det første danner alle attributterne en supernøgle, så sættet {id, kursus, år, lærer, pris, spots} er en supernøgle. Husk at sættet af alle attributter er en supernøgle i alle tabeller.

Er der nogle mindre supernøgler i denne tabel? Ja der er. Sættet {id} er en supernøgle. Vi har den funktionelle afhængighed id -> kursus, år, lærer, pris, pladser , og selvfølgelig har vi den trivielle afhængighed id -> id . Når vi har id, vi kan bestemme alle de andre attributter ud fra de funktionelle afhængigheder.

Sættet {kursus, år er også en supernøgle. Vi har den funktionelle afhængighed kursus, år -> id, lærer, pris, pladser , og vi har de trivielle funktionelle afhængigheder kursus -> kursus og år -> år . Når vi har kursus og år , kan vi bestemme alle de andre attributter fra de funktionelle afhængigheder.

Sættet {id, kursus, år, lærer} er også en supernøgle. Vi har id , kursus og år . Så vi kan bestemme alle de andre attributter i tabellen med disse tre attributter.

På den anden side er sættet {lærer} er ikke en supernøgle. Hvis vi kender læreren, vi kan ikke bestemme nogen anden egenskab end læreren. Sættet {lærer, pris} er heller ikke en supernøgle. Når vi har lærer og pris , vi kan ikke bestemme flere attributter.

Minimale supernøgler

Ikke alle supernøgler er kandidatnøgler. For at være en kandidatnøgle skal en supernøgle være minimal, hvilket betyder, at hvis du tager nogen attributter ud af det, vil det ikke være en supernøgle længere. Lad os se på nogle eksempler.

Sættet {id} er en supernøgle, og den er minimal. Du kan ikke tage attributter ud af det, fordi du så har et tomt sæt, og et tomt sæt er ikke en supernøgle. Således er sættet {id} er en kandidatnøgle.

Sættet {kursus, år} er også en supernøgle og en kandidatnøgle. Hvis du tager nogen af ​​attributterne ud af det, er det resterende sæt ikke længere en supernøgle. Du skal bruge begge kursus og år for at bestemme de andre attributter i sættet.

Men sættet {id, kursus, år, lærer} er en supernøgle, men ikke en kandidatnøgle. For eksempel, hvis du fjerner attributten lærer, det resterende sæt er stadig en supernøgle. Faktisk kan du i dette tilfælde fjerne enhver attribut fra {id, kursus, år, lærer} , og det resterende sæt vil stadig være en supernøgle.

Bemærk, at en minimal supernøgle ikke betyder den supernøgle med det mindste antal elementer. Begge {id} og {kursus, år er kandidatnøgler, selvom de har et andet antal elementer.

Algorithme:Bekræftelse af, at et sæt attributter er en kandidatnøgle

Dette er det almindelige databasedesignproblem:hvordan verificerer man, om et sæt attributter er en kandidatnøgle?

Her er algoritmen til at bekræfte det:

  • Trin 1:Tjek, om det givne sæt er en supernøgle. Beregn lukningen af ​​attributter i sættet. Hvis lukningen er sættet af alle attributter, er sættet en supernøgle.
  • Trin 2:Tjek, om supernøglen er minimal. Fjern hver egenskab, én ad gangen. Hvis det resterende sæt er en supernøgle, er supernøglen ikke minimal, og sættet er ikke en kandidatnøgle. Hvis du ikke kan fjerne nogen af ​​attributterne og beholde supernøgleegenskaben, er sættet en kandidatnøgle.

Lad os f.eks. tjekke, om sættet {kursus, år} er faktisk en kandidatnøgle.

  • Trin 1:Lad os beregne lukningen af ​​{kursus, år}. Ved at bruge lukningsalgoritmen konkluderer vi, at lukningen faktisk er {id, kursus, år, lærer, pris, spots}. Således er sættet {kursus, år} er virkelig en supernøgle.
  • Trin 2. Lad os prøve at fjerne kursus fra sættet. Vi står tilbage med sættet {year}. Der er ingen funktionel afhængighed med kun år som venstre side. Derfor er lukningen af ​​dette sæt {year} . På samme måde, når vi fjerner attributten year, lukningen af ​​det resterende sæt er {kursus}. Hverken {year} heller ikke {kursus} er supernøgler, så sættet {kursus, år} er en minimal supernøgle og dermed en kandidatnøgle.

Hvis du kunne lide denne artikel, så tjek andre normaliseringsartikler på vores blog.

Hvis du er studerende, der tager databasekurser, skal du sørge for at oprette en gratis akademisk konto i Vertabelo, vores online ER-diagramtegneværktøj. Det giver dig mulighed for at tegne logiske og fysiske ER-diagrammer direkte i din browser.

Vertabelo understøtter PostgreSQL, SQL Server, Oracle, MySQL, Google BigQuery, Amazon Redshift og andre relationelle databaser. Prøv det, og se, hvor nemt det er at komme i gang!


  1. ORA-00932:inkonsistente datatyper:forventet - fik CLOB

  2. Sådan fungerer Ceiling() i PostgreSQL

  3. Visninger i SQL Server

  4. CEIL() Funktion i Oracle