RELATIONSDATABASEMODEL: ELEMENTER, HVORDAN MAN GØR DET, EKSEMPEL - TEKNOLOGI - 2025

Den relationelle databasemodel er en metode til strukturering af data ved hjælp af relationer, ved hjælp af gitterlignende strukturer, der består af kolonner og rækker. Det er det konceptuelle princip for relationelle databaser. Det blev foreslået af Edgar F. Codd i 1969.

Det er siden blevet den dominerende databasemodel for forretningsapplikationer sammenlignet med andre databasemodeller, såsom hierarkiske, netværk og objekt.

Kilde: pixabay.com

Codd anede ikke, hvor ekstremt vigtigt og indflydelsesrig hans arbejde som platform for relationelle databaser ville være. De fleste mennesker er meget fortrolige med det fysiske udtryk for et forhold i en database: tabellen.

Den relationelle model er defineret som den database, der tillader gruppering af dens dataelementer i en eller flere uafhængige tabeller, som kan relateres til hinanden ved hjælp af felter, der er fælles for hver relateret tabel.

Databasestyring

En databasetabel ligner et regneark. De forhold, der kan oprettes mellem tabellerne, tillader imidlertid en relationsdatabase at lagre en stor mængde data, som kan hentes effektivt.

Formålet med den relationelle model er at tilvejebringe en deklarativ metode til at specificere data og forespørgsler: brugere erklærer direkte, hvilke oplysninger databasen indeholder, og hvilke oplysninger de ønsker fra den.

På den anden side overlader de det til databasestyringssystemets software for at beskrive datastrukturer til opbevaring og hentningsproceduren for at besvare spørgsmålene.

De fleste relationelle databaser bruger SQL-sproget til forespørgsel og definition af dataene. I øjeblikket er der mange relationelle databasestyringssystemer eller RDBMS (Relational Data Base Management System), såsom Oracle, IBM DB2 og Microsoft SQL Server.

Funktioner og elementer

- Alle data er konceptuelt repræsenteret som et ordnet arrangement af data i rækker og kolonner, kaldet en relation eller tabel.

- Hver tabel skal have en overskrift og et organ. Overskriften er simpelthen listen over kolonner. Organet er det datasæt, der udfylder tabellen, organiseret i rækker.

- Alle værdier er skalarer. Det vil sige, at der på en given række / søjleposition i tabellen kun er en enkelt værdi.

-elementer

Den følgende figur viser en tabel med navnene på dens grundlæggende elementer, der udgør en komplet struktur.

tupel

Hver række med data er en tuple, også kendt som en post. Hver række er en n-tuple, men "n-" kasseres generelt.

Kolonne

Hver kolonne i en tuple kaldes en attribut eller felt. Kolonnen repræsenterer det sæt værdier, som en bestemt attribut kan have.

Nøgle

Hver række har en eller flere kolonner kaldet en tabelnøgle. Denne kombinerede værdi er unik for alle rækker i en tabel. Ved hjælp af denne nøgle identificeres hver tuple unikt. Det vil sige, at nøglen ikke kan duplikeres. Det kaldes den primære nøgle.

På den anden side er en fremmed eller sekundær nøgle feltet i en tabel, der henviser til den primære nøgle i en anden tabel. Det bruges til at henvise til den primære tabel.

- Integritetsregler

Når du designer den relationelle model, definerer du nogle betingelser, der skal være opfyldt i databasen, kaldet integritetsregler.

Nøgleintegritet

Den primære nøgle skal være unik for alle tuple og kan ikke være null (NULL). Ellers kan du ikke identificere rækken entydigt.

For en nøgle med flere kolonner kan ingen af ​​disse kolonner indeholde NULL.

Henvisningsintegritet

Hver værdi af en fremmed nøgle skal svare til en værdi af den primære nøgle i den refererede eller primære tabel.

En række med en fremmed nøgle kan kun indsættes i den sekundære tabel, hvis denne værdi findes i en primær tabel.

Hvis værdien af ​​nøglen ændres i den primære tabel på grund af rækken, der opdateres eller slettes, skal alle rækkerne i de sekundære tabeller med denne fremmednøgle opdateres eller slettes i overensstemmelse hermed.

Hvordan laver man en relationel model?

-Indsamle data

De nødvendige data skal indsamles for at blive gemt i databasen. Disse data er opdelt i forskellige tabeller.

Der skal vælges en passende datatype for hver kolonne. For eksempel: hele tal, flydende punktnumre, tekst, dato osv.

-Definer primære nøgler

For hver tabel skal en kolonne (eller få kolonner) vælges som den primære nøgle, der identificerer hver række i tabellen unikt. Den primære nøgle bruges også til at henvise til andre tabeller.

-Opret forhold mellem tabeller

En database, der består af uafhængige, ikke-relaterede tabeller tjener kun et lille formål.

Det mest afgørende aspekt ved design af en relationsdatabase er at identificere forholdet mellem tabellerne. Forholdstyperne er:

En til mange

I en "Class Listing" -database kan en lærer undervise i nul eller flere klasser, mens en klasse undervises af en enkelt lærer. Denne type forhold er kendt som en-til-mange.

Dette forhold kan ikke repræsenteres i en enkelt tabel. I databasen «Liste over klasser» kan du have en tabel kaldet Lærere, som gemmer information om lærere.

Hvis du vil gemme de klasser, der er undervist af hver lærer, kan du oprette yderligere kolonner, men du vil have et problem: hvor mange kolonner der skal oprettes.

På den anden side, hvis du har en tabel kaldet Klasser, der gemmer information om en klasse, kan du oprette yderligere kolonner til at gemme oplysninger om læreren.

Da en lærer imidlertid kan undervise i mange klasser, vil hans data blive duplikeret på tværs af mange rækker i tabellen Klasser.

Design to borde

Derfor er du nødt til at designe to tabeller: en klassetabel til at gemme information om klasser, med Class_Id som den primære nøgle, og en lærer-tabel til at gemme information om lærere, med Teacher_Id som primær nøgle.

Forholdet en til mange kan derefter oprettes ved at gemme den primære nøgle fra Master-tabellen (Master_Id) i tabellen Klasser, som illustreret nedenfor.

Kolonnen Master_Id i tabellen Klasser er kendt som en fremmed nøgle eller sekundær nøgle.

For hver Master_Id-værdi i Master-tabellen kan der være nul eller flere rækker i Classes-tabellen. For hver klasse_Id-værdi i tabellen Klasser er der kun en række i tabellen Lærere.

Mange til mange

I en "Produktsalg" -database kan en kundeordre indeholde flere produkter, og et produkt kan vises i flere ordrer. Denne type forhold er kendt som mange til mange.

Du kan starte databasen "Produktsalg" med to tabeller: Produkter og ordrer. Produkttabellen indeholder oplysninger om produkterne, med produktID som den primære nøgle.

På den anden side indeholder ordrer-tabellen kundens ordrer med ordre-ID som den primære nøgle.

Du kan ikke gemme de bestilte produkter i ordrestabellen, da du ikke ved, hvor mange kolonner der skal reserveres til produkterne. Bestillinger kan heller ikke gemmes i produkttabellen af ​​samme grund.

For at understøtte et forhold mellem mange og mange skal du oprette en tredje tabel, kendt som en sammenlægningstabel (OrderDetails), hvor hver række repræsenterer et element i en bestemt rækkefølge.

I tabellen OrderDetails består den primære nøgle af to kolonner: orderID og productID, der unikt identificerer hver række.

Kolonnerne OrderID og ProductID i tabellen OrderDetails bruges til at henvise til tabellerne Bestillinger og produkter. Derfor er de også udenlandske nøgler i OrderDetails-tabellen.

En efter en

I databasen "Salg af produkter" kan et produkt have valgfri information, såsom yderligere beskrivelse og dets billede. At holde det inde i Products-tabellen ville generere en masse tomme rum.

Derfor kan en anden tabel (ProductExtras) oprettes for at gemme de valgfri data. Der oprettes kun en post for produkter med valgfri data.

De to tabeller, Produkter og ProductExtras, har et forhold til én. For hver række i tabellen Produkter er der maksimalt en række i tabellen ProductExtras. Det samme produkt-ID skal bruges som den primære nøgle til begge tabeller.

Fordel

Strukturel uafhængighed

I den relationelle databasemodel påvirker ændringer af databasens struktur ikke adgangen til dataene.

Når det er muligt at foretage ændringer i databasens struktur uden at påvirke DBMS 'evne til at få adgang til dataene, kan det siges, at strukturel uafhængighed er opnået.

Konceptuel enkelhed

Den relationelle databasemodel er endnu mere konceptuelt enkel end den hierarkiske eller netværksdatabasemodellen.

Da den relationelle databasemodel frigør designeren fra detaljerne i den fysiske lagring af dataene, kan designere fokusere på den logiske visning af databasen.

Let design, implementering, vedligeholdelse og brug

Den relationelle databasemodel opnår både datauafhængighed og strukturuafhængighed, hvilket gør design, vedligeholdelse, styring og brug af databasen meget lettere end andre modeller.

Ad-hoc forespørgselskapacitet

Tilstedeværelsen af ​​en meget kraftig, fleksibel og brugervenlig forespørgselsfunktion er en af ​​hovedårsagerne til den enorme popularitet af den relationelle databasemodel.

Forespørgselssprog i den relationelle databasemodel, kaldet struktureret forespørgselssprog, eller SQL, gør ad-hoc forespørgsler til virkelighed. SQL er et fjerde generations sprog (4GL).

En 4GL giver brugeren mulighed for at specificere, hvad der skal gøres, uden at specificere, hvordan det skal gøres. Med SQL kan brugerne således specificere, hvilke oplysninger de ønsker, og lade detaljerne om, hvordan man får oplysningerne til databasen.

Ulemper

Hardware-udgifter

Den relationelle databasemodel skjuler kompleksiteten i dens implementering og detaljerne om den fysiske lagring af brugerdata.

For at gøre dette har relationelle databasesystemer brug for computere med mere kraftfulde hardware- og datalagringsenheder.

Derfor har RDBMS brug for kraftige maskiner for at køre glat. Da moderne computers behandlingskraft imidlertid øges eksponentielt, er behovet for mere behandlingskraft i dagens scenarie ikke længere et meget stort problem.

Brugervenlighed kan føre til dårligt design

Den relationsdatabase er let at designe og bruge. Brugere behøver ikke at kende de komplekse detaljer om den fysiske lagring af data. De behøver ikke at vide, hvordan dataene faktisk gemmes for at få adgang til dem.

Denne lethed med design og brug kan føre til udvikling og implementering af dårligt designede databasestyringssystemer. Da databasen er effektiv, kommer disse designineffektiviteter ikke frem, når databasen er designet, og når der kun er en lille mængde data.

Når databasen vokser, vil dårligt designede databaser bremse systemet og føre til ydelsesnedbrydning og datakorruption.

Fænomen af ​​«informationsøer»

Som nævnt tidligere er relationelle databasesystemer let at implementere og bruge. Dette skaber en situation, hvor for mange mennesker eller afdelinger opretter deres egne databaser og applikationer.

Disse informationsøer vil forhindre integration af information, hvilket er vigtigt for, at organisationen kan fungere glat og effektivt.

Disse individuelle databaser vil også skabe problemer, såsom datakonsistens, duplikering af data, redundans af data osv.

Eksempel

Antag, at en database består af tabellerne Leverandører, Dele og forsendelser. Strukturen af ​​tabellerne og nogle eksempler er som følger:

Hver række i leverandørtabellen identificeres ved hjælp af et unikt leverandørnummer (SNo), idet de identisk identificerer hver række i tabellen. Ligeledes har hver del et unikt delnummer (PNo).

Desuden kan der ikke være mere end en forsendelse for en given leverandør / delkombination i forsendelsestabellen, da denne kombination er den primære nøgle for forsendelser, der tjener som en unionstabel, da det er et forhold mellem mange og mange.

Forholdet mellem tabellerne med dele og forsendelser er givet ved at have feltet PNo (delnummer) til fælles, og forholdet mellem leverandører og forsendelser opstår ved at have feltet SNo (leverandørnummer) til fælles.

Ved analyse af forsendelsestabellen kan det opnås som information, at der i alt sendes 500 nødder fra Suneet- og Ankit-leverandørerne, 250 hver.

Tilsvarende blev 1.100 bolte samlet sendt fra tre forskellige leverandører. 500 blå skruer blev sendt fra Suneet-leverandøren. Der er ingen forsendelser med røde skruer.

Referencer

1. Wikipedia, gratis encyklopædi (2019). Relationsmodel. Taget fra: en.wikipedia.org.
2. Techopedia (2019). Relationsmodel. Taget fra: ceilingpedia.com.
3. Dinesh Thakur (2019). Relationsmodel. Elektroniske bemærkninger. Taget fra: ecomputernotes.com.
4. Geeks for Geeks (2019). Relationsmodel. Taget fra: geeksforgeeks.org.
5. Nanyang Technological University (2019). En hurtigstartvejledning om relationel databasedesign. Taget fra: ntu.edu.sg.
6. Adrienne Watt (2019). Kapitel 7 Den relationelle datamodel. BC Åben lærebøger. Taget fra: opentextbc.ca.
7. Toppr (2019). Relationsdatabaser og skemaer. Taget fra: toppr.com.