Relasjonsdatamodell i DBMS: Concepts & Eksempel

Hva er den relasjonelle modellen?

Relasjonsmodell (RM) representerer databasen som en samling av relasjoner. En relasjon er ikke annet enn en verditabell. Hver rad i tabellen representerer en samling av relaterte dataverdier. Disse radene i tabellen angir en reell enhet eller relasjon.

Tabellnavnet og kolonnenavnene hjelper til med å tolke betydningen av verdiene i hver rad. Dataene er representert som et sett med relasjoner. I relasjonsmodellen lagres data som tabeller. Den fysiske lagringen av dataene er imidlertid uavhengig av hvordan dataene er logisk organisert.

Modellen ble foreslått av EF Codd i 1970 og er fortsatt grunnlaget for nesten alle vanlige databaser som er i bruk i dag. Noen populære relasjonsdatabasehåndteringssystemer er:

• DB2 og Informix Dynamic Server – IBM
• Oracle og RDB – Oracle
• SQL Server og tilgang – Microsoft

Relasjonsmodell Concepts i DBMS

1. Egenskap: Hver kolonne i en tabell. Attributter er egenskapene som definerer en relasjon, f.eks. Student_Rollnr, NAVN osv.
2. bord: I relasjonsmodellen lagres relasjoner i tabellformat. De lagres sammen med enhetene. En tabell har to egenskaper, rader og kolonner. Rader representerer poster og kolonner representerer attributter.
3. Tuppel: Det er ikke annet enn en enkelt rad i en tabell, som inneholder én enkelt post.
4. Relasjonsskjema: Et relasjonsskjema representerer navnet på relasjonen med dens attributter.
5. Grad: Det totale antallet attributter i relasjonen kalles relasjonens grad.
6. Kardinalitet: Det totale antallet rader som finnes i tabellen.
7. Kolonne: Kolonnen representerer settet med verdier for et spesifikt attributt.
8. Relasjonsinstans: En relasjonsinstans er et endelig sett med tupler i RDBMS-systemet. Relasjonsinstanser har aldri dupliserte tupler.
9. Relasjonsnøkkel: Hver rad har ett, to eller flere attributter, som kalles relasjonsnøkkelen.
10. Attributtdomene: Hvert attributt har en forhåndsdefinert verdi og omfang, som er kjent som attributtdomenet.

Med vokabularet på plass, er neste bekymring å holdeping dataene i disse relasjonene er gyldige, som er jobben med integritetsbegrensninger.

Relasjonelt Integrity begrensninger

Relasjonsintegritetsbegrensninger i DBMS refererer til betingelser som må være til stede for en gyldig relasjon. Disse relasjonsbegrensningene er avledet fra reglene i miniverdenen som databasen representerer.

Det finnes mange typer integritetsbegrensninger. Begrensninger på relasjonsdatabaseadministrasjonssystemet er stort sett delt inn i tre hovedkategorier:

1. Domenebegrensninger
2. Nøkkelbegrensninger
3. Referensielt Integrity begrensninger

Domenebegrensninger

Domenebegrensninger kan brytes hvis en attributtverdi ikke vises i det tilsvarende domenet, eller hvis den ikke er av riktig datatype.

Domenebegrensninger spesifiserer at innenfor hver tuple må verdien til hvert attributt være atomisk og hentet fra riktig domene. Domener er spesifisert som datatyper, som inkluderer standardtyper som heltall, reelle tall, tegn, boolske verdier og strenger med variabel lengde.

Eksempel:

CREATE DOMAIN CustomerName
CHECK (value NOT NULL)

Eksemplet som vises demonstrerer hvordan man oppretter en domenebegrensning slik at CustomerName ikke er NULL.

Nøkkelbegrensninger

Et attributt som unikt kan identifisere en tuppel i en relasjon kalles nøkkelen til tabellen. Verdien av attributtet for forskjellige tupler i relasjonen må være unik.

Eksempel:

I den gitte tabellen er KundeID et nøkkelattributt i Kundetabellen. Det er mest sannsynlig at den har én enkelt nøkkel for én kunde; KundeID = 1 er bare for Kundenavnet.GoogleEn fullstendig behandling av de ulike nøkkeltypene er dekket i veiledningen til DBMS-nøkler.

Referensielt Integrity begrensninger

Referanseintegritetsbegrensninger i DBMS er basert på konseptet med fremmednøkler. En fremmednøkkel er et viktig attributt for en relasjon som det skal refereres til i andre relasjoner. En referanseintegritetsbegrensning oppstår når en relasjon refererer til et nøkkelattributt for en annen eller samme relasjon. Dette nøkkelelementet må finnes i den refererte tabellen.

Eksempel:

I eksemplet ovenfor har vi to relasjoner, kunde og Billing.

Tuplet for CustomerID = 1 refereres to ganger i relasjonen. Billing. Så vi vet Kundenavn “Google«har et faktureringsbeløp på 300 dollar.»

Operasjoner i den relasjonelle modellen

Fire grunnleggende oppdateringsoperasjoner utføres på den relasjonelle databasemodellen: sett inn, oppdater, slett og velg.

• Insert brukes til å sette inn data i relasjonen.
• Slett brukes til å slette tupler fra tabellen.
• Modify lar deg endre verdiene til noen attributter i eksisterende tuples.
• Velg lar deg velge et spesifikt dataområde.

Når en av disse operasjonene brukes, må integritetsbegrensningene som er spesifisert i det relasjonelle databaseskjemaet aldri brytes.

innfelt Operasjon

Innsettingsoperasjonen gir verdier for attributtene for en ny tuple som skal settes inn i en relasjon.

Oppdater Operasjon

Du kan se at i relasjonstabellen nedenfor er kundenavnet «Apple» oppdatert fra inaktiv til aktiv.

Delete Operasjon

For å spesifisere sletting velger en betingelse på attributtene til relasjonen tuppelen som skal slettes.

I eksemplet ovenfor er kundenavnet «Apple» slettet fra tabellen.

Sletteoperasjonen kan krenke referensiell integritet hvis tuplen som slettes refereres til av fremmednøkler fra andre tupler i samme database.

Velg Operasjon

I eksemplet ovenfor, KundenavnAmazon”Er valgt.

Relasjonsmodell vs. hierarkiske og nettverksmodeller

Den relasjonelle modellen erstattet to tidligere tilnærminger, og kontrasten forklarer hvorfor den ble dominerende. Tabellen nedenfor setter de tre side om side.

Fordi relasjonsmodellen adresserer data etter verdi snarere enn ved å navigere i fysiske lenker, kan et høynivåspråk som SQL kan stille en forespørsel uten å vite hvordan dataene er lagret.

Beste praksis for å lage en relasjonsmodell

• Data må representeres som en samling av relasjoner.
• Hver sammenheng bør være tydelig vist i tabellen.
• Rader bør inneholde data om forekomster av en enhet.
• Kolonner må inneholde data om enhetens attributter.
• Cellene i tabellen skal inneholde én enkelt verdi.
• Hver kolonne bør gis et unikt navn.
• Ingen to rader kan være identiske.
• Verdiene til et attributt bør være fra samme domene.

Fordeler med relasjonsdatabasemodellen

• Enkelhet: En relasjonell datamodell i DBMS er enklere enn hierarkiske modeller og nettverksmodeller.
• Strukturell uavhengighet: Den relasjonelle databasen er kun opptatt av data og ikke av struktur, noe som kan forbedre modellens ytelse.
• Enkel å bruke: Relasjonsmodellen er enkel å bruke, ettersom tabeller som består av rader og kolonner er naturlige og enkle å forstå.
• Spørrefunksjon: Det gjør det mulig for et spørrespråk på høyt nivå som SQL å unngå kompleks databasenavigasjon.
• Datauavhengighet: Strukturen til en relasjonsdatabase kan endres uten å måtte endre noen applikasjon.
• Skalerbar: Når det gjelder antall poster eller rader og antall felt, kan en database utvides for å forbedre brukervennligheten.

Ulemper med den relasjonelle modellen

• Få relasjonsdatabaser har grenser for feltlengder, som ikke kan overskrides.
• Relasjonsdatabaser kan noen ganger bli komplekse etter hvert som datamengden vokser og forholdet mellom dataelementer blir mer komplisert.
• Komplekse relasjonelle databasesystemer kan føre til isolerte databaser der informasjon ikke kan deles fra ett system til et annet.

Spørsmål og svar