4.1 Introduksjon

Ved å konvertere databasetabellene til vanlige tabeller kan du nå analysere relasjonene mellom dem. Antall elementer som samhandler mellom to relaterte tabeller kalles kardinalitet. Cardinality hjelper deg med å kontrollere hvor effektivt du partisjonerte dataene dine i tabeller.

Teoretisk sett kan alle enheter opprettholde relasjoner med hverandre, men i praksis er det tre typer relasjoner mellom enheter:

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

4.2 En-til-en kommunikasjon

Hvis det bare er én forekomst av enhet A for hver forekomst av enhet B, sies de å ha en en-til-en-relasjon (ofte betegnet som "1:1"). På ER-diagrammer er et slikt forhold indikert med en linje med en liten stolpe i hver ende:

Et 1:1-forhold indikerer generelt at med mindre du har en god grunn til å holde dem adskilt, er dataene for de to tabellene best kombinert til én.

I noen tilfeller er det imidlertid rimelig å bruke tabeller med 1:1-forhold. Hvis tabellene dine har felt med valgfrie data, for eksempel beskrivelser, og i mange tilfeller er tomme, er det fornuftig å flytte alle beskrivelser til en egen tabell, som vil tillate deg å bli kvitt hyppige hull og øke effektiviteten til databasen din. .

Deretter, for å kartlegge dataene riktig, må du inkludere minst én identisk kolonne i hver tabell (det er best å velge en primærnøkkel for dette).

Java university

4.3 En-til-mange-forhold

Denne typen relasjoner oppstår når en post i en tabell er knyttet til flere enheter i en annen. For eksempel kan den samme kunden legge inn flere bestillinger, eller en bibliotekbesøker kan låne flere bøker på ett besøk. En-til-mange-forhold (eller 1:M for kort) uttrykkes i et diagram med kråkeføtter-notasjon, som vist i eksemplet nedenfor:

For å bruke en 1:M-relasjon når du planlegger en database, legger du bare til primærnøkkelen fra "en"-tabellen som et attributt til "mange"-tabellen. Hvis primærnøkkelen er i en annen tabell, kalles den en "fremmednøkkel". "En"-tabellen regnes som den overordnede tabellen, mens "mange"-tabellen regnes som den underordnede tabellen.

4.4 Mange-til-mange-forhold

Når flere enheter i en tabell kan kobles til flere enheter i en annen, anses de å ha en mange-til-mange (eller M:M)-relasjon. For eksempel eksisterer et slikt forhold mellom elever og klasser, siden hver elev kan delta på flere forskjellige klasser, og følgelig kan mange elever komme til hver klasse.

På ER-diagrammet vises denne typen forhold som følger:

Dessverre er det umulig å implementere et slikt forhold direkte i databasen. Derfor vil det måtte deles opp i to en-til-mange-forhold.

For å gjøre dette, må du opprette en ny enhet mellom de to tabellene. Hvis det etableres et M:M-forhold mellom salg og produkter, kan den nye enheten kalles "solgte produkter" fordi den vil representere innholdet i hvert salg.

Med "varer solgt" og tabellen "salg" og tabellen "varer" vil bli koblet sammen med type 1:M. I forskjellige modeller kalles slike mellomliggende enheter forskjellig - "forbindelsestabeller", "assosiative enheter" eller "nodetabeller".

Hver koblingstabelloppføring forbinder to forskjellige enheter av tilstøtende tabeller (og kan også inneholde tilleggsinformasjon). En koblingstabell mellom elever og klasser kan for eksempel se slik ut:

4.5 Obligatorisk eller ikke?

En annen tilnærming til koblingsanalyse er å bestemme hvilken av de tilknyttede enhetene som er en forutsetning for tilstedeværelsen av en annen enhet. Den valgfrie lenkesiden er merket med en sirkel på stammen.

For eksempel, for at en stat skal ha sin egen representant i FN, må den eksistere på verdenskartet, men påstanden om det motsatte vil være falsk:

To enheter kan være avhengige av hverandre (det vil si at den ene kan ikke eksistere uten den andre).

Rekursive lenker

Noen ganger kan en tabell referere til seg selv. For eksempel kan en ansatttabell ha et "manager"-attributt som vil henvise oss til en annen ansatt i samme tabell. Dette er det rekursive forholdet.

Ekstra tilkoblinger

Lenker anses som overflødige hvis de uttrykkes mer enn én gang. Som regel kan en av dem slettes uten å miste viktig informasjon. For eksempel, hvis enheten "studenter" er koblet til enheten "lærere" ikke bare direkte, men også indirekte gjennom "klasser", er det fornuftig å fjerne forholdet mellom enhetene "studenter" og "lærere". Denne avgjørelsen er begrunnet med det faktum at det er mulig å tildele elever til lærere bare gjennom klasser.

4.6 Referensiell integritet av data

Når du endrer primær- og fremmednøkler, bør man observere et slikt aspekt som referanseintegriteten til data . Hovedideen er å holde to tabeller i en database som lagrer de samme dataene konsistente.

Dataintegritet representerer riktig bygde relasjoner mellom tabeller med korrekt kobling mellom dem. I hvilke tilfeller kan dataintegriteten krenkes:

  • Slettingsavvik . Oppstår når en rad slettes fra hovedtabellen. I dette tilfellet fortsetter fremmednøkkelen fra den avhengige tabellen å referere til den slettede raden fra hovedtabellen.
  • Anomali ved innsetting . 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 anomali. Med en slik anomali kan flere rader i en tabell inneholde data som tilhører samme objekt. Hvis du endrer dataene i én rad, kan de komme i konflikt med dataene fra en annen rad.

Slettingsavvik

For å løse sletteanomalien, bør fremmednøkkelen settes til en av to begrensninger:

Hvis en rad fra en avhengig tabell nødvendigvis krever en rad fra hovedtabellen, er fremmednøkkelen satt til kaskadesletting. 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 til 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 innsettingsavviket når du legger til en avhengig datatabell, må kolonnen som representerer fremmednøkkelen være nullbar. Og dermed, hvis objektet som legges til ikke har noen forbindelse med hovedtabellen, vil fremmednøkkelkolonnen ha en NULL-verdi.

Oppdater avvik

For å løse problemet med oppdateringsavvik brukes normalisering, som ble diskutert tidligere.