RELASJONSDATABASEMODELL: ELEMENTER, HVORDAN GJØRE DET, EKSEMPEL - TEKNOLOGI - 2026

Den relasjonsdatabasemodellen er en metode for å strukturere data ved å bruke relasjoner, ved å bruke rutenettlignende strukturer, bestående av kolonner og rader. Det er det konseptuelle prinsippet for relasjonsdatabaser. Det ble foreslått av Edgar F. Codd i 1969.

Siden har den blitt den dominerende databasemodellen for forretningsapplikasjoner, sammenlignet med andre databasemodeller, for eksempel hierarkiske, nettverk og objekt.

Kilde: pixabay.com

Codd hadde ingen anelse om hvor ekstremt viktig og innflytelsesrikt hans arbeid som plattform for relasjonsdatabaser ville være. De fleste er veldig kjent med det fysiske uttrykket til et forhold i en database: tabellen.

Den relasjonsmodellen er definert som databasen som gjør det mulig å gruppere dataelementene i en eller flere uavhengige tabeller, som kan relateres til hverandre ved bruk av felt som er felles for hver relatert tabell.

Database ledelse

En databasetabell ligner et regneark. Forholdene som kan opprettes mellom tabellene gjør det imidlertid mulig for en relasjonsdatabase å lagre en stor mengde data som kan hentes effektivt.

Hensikten med den relasjonsmodellen er å gi en deklarativ metode for å spesifisere data og spørsmål: brukere erklærer direkte hvilken informasjon databasen inneholder og hvilken informasjon de vil ha fra den.

På den annen side overlater de det til databasestyringssystemprogramvaren for å beskrive datastrukturer for lagring og gjenfinningsprosedyre for å svare på spørsmålene.

De fleste relasjonsdatabaser bruker SQL-språket for spørring og definering av dataene. For tiden er det mange relasjonsdatabasestyringssystemer eller RDBMS (Relational Data Base Management System), for eksempel Oracle, IBM DB2 og Microsoft SQL Server.

Funksjoner og elementer

- Alle data er konseptuelt representert som et ordnet arrangement av data i rader og kolonner, kalt en relasjon eller tabell.

- Hver tabell må ha en overskrift og et hovedstykke. Overskriften er ganske enkelt listen over kolonner. Kroppen er datasettet som fyller tabellen, organisert i rader.

- Alle verdier er skalarer. Det vil si at det ved en gitt stilling på rad / kolonne i tabellen bare er en verdi.

-Elements

Følgende figur viser en tabell med navnene på de grunnleggende elementene som utgjør en fullstendig struktur.

tuppel

Hver rad med data er en tuple, også kjent som en post. Hver rad er en n-tuple, men "n-" kastes vanligvis.

Kolonne

Hver kolonne i en tuple kalles et attributt eller felt. Kolonnen representerer settet med verdier som et spesifikt attributt kan ha.

Nøkkel

Hver rad har en eller flere kolonner kalt en tabellnøkkel. Denne kombinerte verdien er unik for alle radene i en tabell. Ved hjelp av denne nøkkelen vil hver tupel identifiseres unikt. Det vil si at nøkkelen ikke kan dupliseres. Det kalles den primære nøkkelen.

På den annen side er en fremmed eller sekundær nøkkel feltet i en tabell som refererer til den primære nøkkelen til en annen tabell. Den brukes til å referere til den primære tabellen.

-Regler om integritet

Når du utformer den relasjonsmodellen, definerer du noen betingelser som må oppfylles i databasen, kalt integritetsregler.

Nøkkelintegritet

Den primære nøkkelen må være unik for alle tupler og kan ikke være null (NULL). Ellers vil du ikke kunne identifisere raden på en unik måte.

For en nøkkel med flere kolonner, kan ingen av disse kolonnene inneholde NULL.

Referanseintegritet

Hver verdi på en fremmed nøkkel må samsvare med en verdi av den primære nøkkelen til den refererte eller primære tabellen.

En rad med fremmed nøkkel kan bare settes inn i den sekundære tabellen hvis den verdien eksisterer i en primær tabell.

Hvis verdien av nøkkelen endres i den primære tabellen, på grunn av at raden blir oppdatert eller slettet, bør alle radene i de sekundære tabellene med denne fremmednøkkelen oppdateres eller slettes tilsvarende.

Hvordan lage en relasjonsmodell?

-Samle data

De nødvendige dataene må samles for å bli lagret i databasen. Disse dataene er delt inn i forskjellige tabeller.

En passende datatype må velges for hver kolonne. For eksempel: hele tall, flytende punktnumre, tekst, dato osv.

-Definere primærnøkler

For hver tabell må en kolonne (eller få kolonner) velges som primærnøkkel, som unikt identifiserer hver rad i tabellen. Den primære nøkkelen brukes også til å referere til andre tabeller.

-Lage forhold mellom tabeller

En database som består av uavhengige, ikke-relaterte tabeller tjener lite formål.

Det mest avgjørende aspektet i utformingen av en relasjonsdatabase er å identifisere sammenhengene mellom tabellene. Forholdstypene er:

En til mange

I en "Class Listing" -database kan en lærer undervise i null eller flere klasser, mens en klasse blir undervist av en enkelt lærer. Denne typen forhold er kjent som en-til-mange.

Dette forholdet kan ikke representeres i en enkelt tabell. I databasen «Liste over klasser» kan du ha en tabell som heter Lærere, som lagrer informasjon om lærere.

Hvis du vil lagre klassene som læres av hver lærer, kan du lage flere kolonner, men du vil få et problem: hvor mange kolonner du vil lage.

På den annen side, hvis du har en tabell som heter Klasser, som lagrer informasjon om en klasse, kan du lage flere kolonner for å lagre informasjon om læreren.

Men siden en lærer kan undervise i mange klasser, vil dataene hans bli duplisert på mange rader i tabellen Klasser.

Design to bord

Derfor må du designe to tabeller: en Classes-tabell for å lagre informasjon om klassene, med Class_Id som primærnøkkel, og en Teachers-tabell for å lagre informasjon om lærerne, med Teacher_Id som den primære nøkkelen.

Forholdet mellom mange og flere kan deretter opprettes ved å lagre primærnøkkelen fra Master-tabellen (Master_Id) i Classes-tabellen, som illustrert nedenfor.

Kolonnen Master_Id i klassen-tabellen er kjent som en fremmednøkkel eller sekundærnøkkel.

For hver Master_Id-verdi i Master-tabellen kan det være null eller flere rader i Classes-tabellen. For hver klasse_Id-verdi i klassetabellen er det bare en rad i lærertabellen.

Mange til mange

I en "produktsalg" -database kan en kundeordre inneholde flere produkter, og et produkt kan vises i flere ordrer. Denne typen forhold er kjent som mange til mange.

Du kan starte "Produktsalg" -databasen med to tabeller: Produkter og ordrer. Produkttabellen inneholder informasjon om produktene, med produktID som den viktigste nøkkelen.

På den annen side inneholder ordretabellen kundens ordrer, med ordre-ID som primærnøkkel.

Du kan ikke lagre de bestilte produktene i ordretabellen, siden du ikke vet hvor mange kolonner som skal reserveres for produktene. Bestillinger kan ikke lagres i produkttabellen av samme grunn.

For å støtte et forhold mellom mange til mange må du opprette en tredje tabell, kjent som en sammenføyningstabell (OrderDetails), der hver rad representerer et element i en bestemt rekkefølge.

For OrderDetails-tabellen består den primære nøkkelen av to kolonner: orderID og productID, som unikt identifiserer hver rad.

Kolonnene OrderID og ProductID i OrderDetails-tabellen brukes til å referere til Order- og Products-tabellene. Derfor er de også utenlandske nøkler i OrderDetails-tabellen.

En etter en

I "Salg av produkter" -databasen kan et produkt ha valgfri informasjon, for eksempel tilleggsbeskrivelse og dets bilde. Å holde den inne i Products-tabellen ville generert mange tomme mellomrom.

Derfor kan en annen tabell (ProductExtras) opprettes for å lagre valgfrie data. Bare en post vil bli opprettet for produkter med valgfri data.

De to tabellene, Products and ProductExtras, har et en-til-en-forhold. For hver rad i Products-tabellen er det maksimalt en rad i ProductExtras-tabellen. Det samme produkt-ID må brukes som hovednøkkel for begge tabeller.

Fordel

Strukturell uavhengighet

I den relasjonsdatabasemodellen påvirker ikke endringer i databasens struktur tilgangen til dataene.

Når det er mulig å gjøre endringer i databasestrukturen uten å påvirke DBMS 'evne til å få tilgang til dataene, kan det sies at strukturell uavhengighet er oppnådd.

Konseptuell enkelhet

Den relasjonsdatabasemodellen er enda mer konseptuelt enkel enn den hierarkiske eller nettverksdatabasemodellen.

Siden den relative databasemodellen frigjør designeren fra detaljene i den fysiske lagringen av dataene, kan designere fokusere på den logiske visningen av databasen.

Enkel design, implementering, vedlikehold og bruk

Den relasjonsdatabasemodellen oppnår både datauavhengighet og strukturuavhengighet, noe som gjør design, vedlikehold, administrasjon og bruk av databasen mye enklere enn andre modeller.

Ad-hoc spørringskapasitet

Tilstedeværelsen av en veldig kraftig, fleksibel og brukervennlig spørringskapasitet er en av hovedårsakene til den enorme populariteten til den relasjonsdatabasemodellen.

Spørrespråket i den relasjonsdatabasemodellen, kalt strukturert spørrespråk, eller SQL, gjør ad-hoc-spørsmål til virkelighet. SQL er et fjerde generasjonsspråk (4GL).

En 4GL lar brukeren spesifisere hva som skal gjøres, uten å spesifisere hvordan det skal gjøres. Dermed, med SQL, kan brukere spesifisere hvilken informasjon de ønsker og legge igjen detaljene om hvordan de kan få informasjonen til databasen.

ulemper

Maskinvareutgifter

Den relative databasemodellen skjuler kompleksiteten i implementeringen og detaljene om fysisk lagring av brukerdata.

For å gjøre dette trenger relasjonsdatabasesystemer datamaskiner med kraftigere maskinvare- og datalagringsenheter.

Derfor trenger RDBMS kraftige maskiner for å kunne fungere problemfritt. Ettersom prosessorkraften til moderne datamaskiner øker eksponentielt, er behovet for mer prosessorkraft i dagens scenario ikke lenger et veldig stort problem.

Enkel design kan føre til dårlig design

Relasjonsdatabasen er enkel å designe og bruke. Brukere trenger ikke å vite de komplekse detaljene om fysisk lagring av data. De trenger ikke å vite hvordan dataene faktisk lagres for å få tilgang til dem.

Denne enkle utformingen og bruken kan føre til utvikling og implementering av dårlig utformede databasesystemer. Fordi databasen er effektiv, vil ikke disse designeffektivitetene komme fram når databasen er designet og når det bare er en liten mengde data.

Når databasen vokser, vil dårlige designede databaser bremse systemet og føre til ytelsesforringelse og datakorrupsjon.

Fenomen av «informasjonsøyer»

Som nevnt før, er relasjonsdatabasesystemer enkle å implementere og bruke. Dette vil skape en situasjon der for mange mennesker eller avdelinger lager egne databaser og applikasjoner.

Disse informasjonsøyene vil forhindre integrering av informasjon, som er avgjørende for at organisasjonen skal fungere jevnt og effektivt.

Disse individuelle databasene vil også skape problemer som datakonsekvens, duplisering av data, redundans av data, etc.

Eksempel

Anta at en database som består av tabellene Leverandører, deler og forsendelser. Strukturen til tabellene og noen eksempler på poster er som følger:

Hver rad i leverandørtabellen identifiseres av et unikt leverandørnummer (SNo), og identifiserer hver rad i tabellen på en unik måte. Likeledes har hver del et unikt delenummer (PNo).

Videre kan det ikke være mer enn en forsendelse for en gitt leverandør / del-kombinasjon i forsendelsestabellen, siden denne kombinasjonen er den primære nøkkelen til forsendelser, som fungerer som et forbundstabell, ettersom det er et forhold mellom mange til mange.

Forholdet mellom tabellene Deler og forsendelser er gitt ved å ha feltet PNo (delnummer) til felles og forholdet mellom leverandører og forsendelser oppstår ved å ha SNo-feltet (leverandørnummer) felles.

Ved å analysere forsendelsestabellen kan du få informasjon om at det sendes totalt 500 nøtter fra leverandører av Suneet og Ankit, 250 hver.

Tilsvarende ble 1100 bolter totalt sendt fra tre forskjellige leverandører. 500 blå skruer ble sendt fra Suneet-leverandøren. Det er ingen forsendelser med røde skruer.

referanser

1. Wikipedia, gratis leksikon (2019). Relasjonsmodell. Hentet fra: en.wikipedia.org.
2. Techopedia (2019). Relasjonsmodell. Hentet fra: ceilingpedia.com.
3. Dinesh Thakur (2019). Relasjonsmodell. E-datamaskinnotater. Hentet fra: ecomputernotes.com.
4. Geeks for Geeks (2019). Relasjonsmodell. Hentet fra: geeksforgeeks.org.
5. Nanyang Technological University (2019). En hurtigstartveiledning for relasjonsdatabasedesign. Hentet fra: ntu.edu.sg.
6. Adrienne Watt (2019). Kapittel 7 Den relasjonelle datamodellen. BC Åpne lærebøker. Hentet fra: opentextbc.ca.
7. Toppr (2019). Relasjonsdatabaser og skjemaer. Hentet fra: toppr.com.