Afhængigheder mellem tabeller i en database

4.1 Indledning

Ved at konvertere databasetabellerne til almindelige tabeller kan du nu analysere relationerne mellem dem. Antallet af elementer, der interagerer mellem to relaterede tabeller, kaldes kardinalitet. Cardinality hjælper dig med at kontrollere, hvor effektivt du har opdelt dine data i tabeller.

Teoretisk set kan alle entiteter opretholde relationer med hinanden, men i praksis er der tre typer relationer mellem entiteter:

• En til en
• En til mange
• mange til mange

4.2 En-til-en kommunikation

Hvis der kun er én forekomst af entitet A for hver forekomst af entitet B, siges de at have en en-til-en-relation (ofte betegnet som "1:1"). På ER-diagrammer er et sådant forhold angivet med en linje med en lille søjle i hver ende:

Et 1:1 forhold indikerer generelt, at medmindre du har en god grund til at holde dem adskilt, er de to tabellers data bedst kombineret til én.

Men i nogle tilfælde er det rimeligt at bruge tabeller med 1:1 relationer. Hvis dine tabeller har felter med valgfri data, såsom beskrivelser, og de i mange tilfælde er tomme, giver det mening at flytte alle beskrivelser til en separat tabel, hvilket vil give dig mulighed for at slippe af med hyppige huller og øge effektiviteten af ​​din database .

Derefter, for at kortlægge dataene korrekt, skal du inkludere mindst én identisk kolonne i hver tabel (det er bedst at vælge en primær nøgle til dette).

4.3 En-til-mange forhold

Denne type relation opstår, når en post i en tabel er knyttet til flere enheder i en anden. For eksempel kan den samme kunde afgive flere ordrer, eller en biblioteksgæst kan låne flere bøger på et besøg. En-til-mange relationer (eller 1:M for kort) er udtrykt i et diagram ved hjælp af kragetæer-notation, som vist i eksemplet nedenfor:

For at anvende et 1:M-forhold, når du planlægger en database, skal du blot tilføje den primære nøgle fra "én"-tabellen som en attribut til "mange"-tabellen. Hvis den primære nøgle er i en anden tabel, kaldes den en "fremmednøgle". Tabellen "én" betragtes som den overordnede tabel, mens tabellen "mange" betragtes som den underordnede tabel.

4.4 Mange-til-mange forhold

Når flere entiteter i en tabel kan forbindes med flere entiteter i en anden, anses de for at have en mange-til-mange (eller M:M) relation. For eksempel eksisterer et sådant forhold mellem elever og klasser, da hver elev kan deltage i flere forskellige klasser, og derfor kan mange elever komme til hver klasse.

På ER-diagrammet vises denne type relation som følger:

Desværre er det umuligt at implementere et sådant forhold direkte i databasen. Derfor vil det skulle opdeles i to en-til-mange-forhold.

For at gøre dette skal du oprette en ny enhed mellem de to tabeller. Hvis der etableres et M:M-forhold mellem salg og produkter, kan den nye enhed kaldes "solgte produkter", fordi den repræsenterer indholdet af hvert salg.

Med "sælgte varer" og tabellen "salg" og tabellen "varer" vil være forbundet med type 1:M. I forskellige modeller kaldes sådanne mellemliggende enheder forskelligt - "forbindelsestabeller", "associative entiteter" eller "knudetabeller".

Hver linktabelpost forbinder to forskellige enheder af tilstødende tabeller (og kan også indeholde yderligere information). For eksempel kan en linktabel mellem elever og klasser se sådan ud:

4.5 Obligatorisk eller ej?

En anden tilgang til linkanalyse er at bestemme, hvilken af ​​de forbundne enheder, der er en forudsætning for tilstedeværelsen af ​​en anden enhed. Den valgfrie linkside er markeret med en cirkel på stammen.

For at en stat for eksempel skal have sin egen repræsentant i FN, skal den eksistere på verdenskortet, men udsagnet om det modsatte vil være falsk:

To enheder kan være indbyrdes afhængige (det vil sige, den ene kan ikke eksistere uden den anden).

Rekursive links

Nogle gange kan en tabel referere til sig selv. For eksempel kan en medarbejdertabel have en "manager"-attribut, der henviser os til en anden medarbejder i samme tabel. Dette er det rekursive forhold.

Ekstra tilslutninger

Links betragtes som overflødige, hvis de udtrykkes mere end én gang. Som regel kan en af ​​dem slettes uden at miste vigtige oplysninger. For eksempel, hvis entiteten "studerende" er forbundet med enheden "lærere" ikke kun direkte, men også indirekte gennem "klasser", giver det mening at fjerne forholdet mellem enhederne "elever" og "lærere". Denne beslutning begrundes med, at det kun er muligt at tildele elever til lærere gennem klasser.

4.6 Referenceintegritet af data

Når du ændrer primære og fremmede nøgler, bør man observere et sådant aspekt som referentiel integritet af data . Dens hovedidé er at holde to tabeller i en database, der gemmer de samme data konsekvente.

Dataintegritet repræsenterer korrekt opbyggede relationer mellem tabeller med korrekt kobling mellem dem. I hvilke tilfælde kan dataintegriteten krænkes:

• Sletningsanomali . Opstår, når en række slettes fra hovedtabellen. I dette tilfælde fortsætter fremmednøglen fra den afhængige tabel med at henvise til den slettede række fra mastertabellen.
• Anomali ved indsættelse . Opstår, når en række indsættes i en afhængig tabel. I dette tilfælde matcher fremmednøglen fra den afhængige tabel ikke den primære nøgle i nogen af ​​rækkerne fra mastertabellen.
• Opdater anomali. Med en sådan anomali kan flere rækker i en tabel indeholde data, der tilhører det samme objekt. Hvis du ændrer dataene i én række, kan de komme i konflikt med dataene fra en anden række.

Sletningsanomali

For at løse sletteanomalien skal fremmednøglen indstilles til en af ​​to begrænsninger:

Hvis en række fra en afhængig tabel nødvendigvis kræver en række fra mastertabellen, er fremmednøglen indstillet til kaskadesletning. Det vil sige, at når en række slettes fra mastertabellen, slettes den eller de tilknyttede rækker fra den afhængige tabel.

Hvis en række fra en afhængig tabel ikke tillader nogen relation til en række fra hovedtabellen (det vil sige, en sådan relation er valgfri), så sættes fremmednøglen til NULL, når den relaterede række slettes fra hovedtabellen. Kolonnen med fremmednøgle skal være nullbar.

Anomali ved indsættelse

For at løse insert-anomalien ved tilføjelse til en afhængig datatabel skal kolonnen, der repræsenterer fremmednøglen, være nullbar. Og derfor, hvis objektet, der tilføjes, ikke har nogen forbindelse med hovedtabellen, vil fremmednøglekolonnen have en NULL-værdi.

Opdater uregelmæssigheder

For at løse problemet med opdateringsanomali anvendes normalisering, som blev diskuteret tidligere.