RELATIONEEL DATABASEMODEL: ELEMENTEN, HOE HET TE DOEN, VOORBEELD - TECHNOLOGIE - 2026

Het relationele databasemodel is een methode om gegevens te structureren met behulp van relaties, met behulp van rastervormige structuren, bestaande uit kolommen en rijen. Het is het conceptuele principe van relationele databases. Het werd in 1969 voorgesteld door Edgar F. Codd.

Het is sindsdien het dominante databasemodel voor bedrijfstoepassingen geworden, in vergelijking met andere databasemodellen, zoals hiërarchisch, netwerk en object.

Bron: pixabay.com

Codd had geen idee hoe buitengewoon vitaal en invloedrijk zijn werk als platform voor relationele databases zou zijn. De meeste mensen zijn goed bekend met de fysieke uitdrukking van een relatie in een database: de tabel.

Het relationele model wordt gedefinieerd als de database waarmee de gegevenselementen in een of meer onafhankelijke tabellen kunnen worden gegroepeerd, die aan elkaar kunnen worden gerelateerd door het gebruik van gemeenschappelijke velden voor elke gerelateerde tabel.

Database management

Een databasetabel is vergelijkbaar met een spreadsheet. Door de relaties die tussen de tabellen kunnen worden gemaakt, kan een relationele database echter efficiënt een grote hoeveelheid gegevens opslaan, die effectief kunnen worden opgehaald.

Het doel van het relationele model is om een ​​declaratieve methode te bieden voor het specificeren van gegevens en queries: gebruikers geven direct aan welke informatie de database bevat en welke informatie ze ervan willen.

Aan de andere kant laten ze het aan de databasebeheersysteemsoftware over om de datastructuren voor opslag te beschrijven en de ophaalprocedure om de vragen te beantwoorden.

De meeste relationele databases gebruiken de SQL-taal voor het opvragen en definiëren van de gegevens. Momenteel zijn er veel relationele databasebeheersystemen of RDBMS (Relational Data Base Management System), zoals Oracle, IBM DB2 en Microsoft SQL Server.

Functies en elementen

- Alle gegevens worden conceptueel weergegeven als een geordende rangschikking van gegevens in rijen en kolommen, een relatie of tabel genoemd.

- Elke tabel moet een koptekst en een hoofdtekst hebben. De koptekst is gewoon de lijst met kolommen. De body is de set gegevens die de tabel vult, georganiseerd in rijen.

- Alle waarden zijn scalair. Dat wil zeggen dat er op elke rij- / kolompositie in de tabel slechts één waarde is.

-Elementen

De volgende afbeelding toont een tabel met de namen van de basiselementen, die samen een complete structuur vormen.

Tuple

Elke rij met gegevens is een tupel, ook wel een record genoemd. Elke rij is een n-tupel, maar de "n-" wordt over het algemeen weggegooid.

Kolom

Elke kolom in een tuple wordt een attribuut of veld genoemd. De kolom vertegenwoordigt de set waarden die een specifiek kenmerk kan hebben.

Sleutel

Elke rij heeft een of meer kolommen die een tabelsleutel worden genoemd. Deze gecombineerde waarde is uniek voor alle rijen in een tabel. Door middel van deze sleutel wordt elk tupel uniek geïdentificeerd. Dat wil zeggen, de sleutel kan niet worden gedupliceerd. Het wordt de primaire sleutel genoemd.

Aan de andere kant is een vreemde of secundaire sleutel het veld in een tabel dat verwijst naar de primaire sleutel van een andere tabel. Het wordt gebruikt om naar de primaire tabel te verwijzen.

-Regels van integriteit

Bij het ontwerpen van het relationele model definieert u enkele voorwaarden waaraan in de database moet worden voldaan, de zogenaamde integriteitsregels.

Sleutelintegriteit

De primaire sleutel moet uniek zijn voor alle tuples en mag niet null (NULL) zijn. Anders kunt u de rij niet uniek identificeren.

Voor een sleutel met meerdere kolommen kan geen van deze kolommen NULL bevatten.

Referentiële integriteit

Elke waarde van een externe sleutel moet overeenkomen met een waarde van de primaire sleutel van de tabel waarnaar wordt verwezen of de primaire tabel.

Een rij met een externe sleutel kan alleen in de secundaire tabel worden ingevoegd als die waarde in een primaire tabel voorkomt.

Als de waarde van de sleutel in de primaire tabel verandert doordat de rij wordt bijgewerkt of verwijderd, moeten alle rijen in de secundaire tabellen met deze externe sleutel dienovereenkomstig worden bijgewerkt of verwijderd.

Hoe maak je een relationeel model?

-Data verzamelen

De benodigde gegevens moeten worden verzameld om in de database te worden opgeslagen. Deze gegevens zijn onderverdeeld in verschillende tabellen.

Voor elke kolom moet een geschikt gegevenstype worden gekozen. Bijvoorbeeld: hele getallen, getallen met drijvende komma, tekst, datum, etc.

-Definieer primaire sleutels

Voor elke tabel moet een kolom (of enkele kolommen) worden gekozen als de primaire sleutel, die elke rij in de tabel uniek identificeert. De primaire sleutel wordt ook gebruikt om naar andere tabellen te verwijzen.

-Creëer relaties tussen tabellen

Een database die bestaat uit onafhankelijke, niet-gerelateerde tabellen heeft weinig nut.

Het meest cruciale aspect bij het ontwerpen van een relationele database is het identificeren van de relaties tussen de tabellen. De relatietypen zijn:

Een te veel

In een "Class Listing" -database kan een leraar nul of meer klassen lesgeven, terwijl een klas wordt gegeven door één leraar. Dit type relatie staat bekend als een-op-veel.

Deze relatie kan niet in één tabel worden weergegeven. In de database «Lijst met klassen» kunt u een tabel hebben met de naam Leraren, waarin informatie over leraren wordt opgeslagen.

Om de lessen van elke docent op te slaan, zou je extra kolommen kunnen maken, maar je zou een probleem tegenkomen: hoeveel kolommen je moet maken.

Aan de andere kant, als je een tabel hebt met de naam Klassen, waarin informatie over een klas wordt opgeslagen, kun je extra kolommen maken om informatie over de leraar op te slaan.

Aangezien een docent echter veel klassen kan lesgeven, worden zijn gegevens over veel rijen in de tabel Klassen gedupliceerd.

Ontwerp twee tafels

Daarom moet u twee tabellen ontwerpen: een Classes-tabel om informatie over de klassen op te slaan, met Class_Id als de primaire sleutel, en een Teachers-tabel om informatie over de docenten op te slaan, met Teacher_Id als de primaire sleutel.

De een-op-veel-relatie kan vervolgens worden gemaakt door de primaire sleutel uit de Master-tabel (Master_Id) op te slaan in de Classes-tabel, zoals hieronder wordt geïllustreerd.

De kolom Master_Id in de tabel Klassen staat bekend als een externe sleutel of secundaire sleutel.

Voor elke Master_Id-waarde in de Master-tabel kunnen er nul of meer rijen in de Classes-tabel zijn. Voor elke Class_Id-waarde in de Classes-tabel is er slechts één rij in de Teachers-tabel.

Veel te veel

In een "Productverkoop" -database kan een klantorder meerdere producten bevatten, en een product kan in meerdere bestellingen voorkomen. Dit type relatie is voor velen bekend.

U kunt de database "Productverkoop" starten met twee tabellen: Producten en Bestellingen. De tabel Producten bevat informatie over de producten, met productID als primaire sleutel.

Aan de andere kant bevat de tabel Orders de bestellingen van de klant, met orderID als de primaire sleutel.

U kunt de bestelde producten niet opslaan in de tabel Bestellingen, aangezien u niet weet hoeveel kolommen u voor de producten moet reserveren. Evenmin kunnen om dezelfde reden bestellingen in de tabel Producten worden opgeslagen.

Om een ​​veel-op-veel-relatie te ondersteunen, moet u een derde tabel maken, een zogenaamde join-tafel (OrderDetails), waarbij elke rij een item in een bepaalde volgorde vertegenwoordigt.

Voor de OrderDetails-tabel bestaat de primaire sleutel uit twee kolommen: orderID en productID, die elke rij uniek identificeert.

De kolommen orderID en productID in de tabel OrderDetails worden gebruikt om te verwijzen naar de tabellen Orders en Products. Daarom zijn het ook externe sleutels in de tabel OrderDetails.

Een voor een

In de database "Verkoop van producten" kan een product optionele informatie bevatten, zoals een aanvullende beschrijving en de afbeelding. Als u het in de tabel Producten houdt, worden er veel lege ruimtes gegenereerd.

Daarom kan een andere tabel (ProductExtras) worden gemaakt om de optionele gegevens op te slaan. Er wordt slechts één record gemaakt voor producten met optionele gegevens.

De twee tabellen, Products en ProductExtras, hebben een één-op-één relatie. Voor elke rij in de Products-tabel is er maximaal één rij in de ProductExtras-tabel. Dezelfde productID moet worden gebruikt als de primaire sleutel voor beide tabellen.

Voordeel

Structurele onafhankelijkheid

In het relationele databasemodel hebben wijzigingen in de structuur van de database geen invloed op de toegang tot de gegevens.

Wanneer het mogelijk is om wijzigingen aan te brengen in de databasestructuur zonder de mogelijkheid van het DBMS om toegang tot de gegevens te krijgen, aan te tasten, kan worden gesteld dat structurele onafhankelijkheid is bereikt.

Conceptuele eenvoud

Het relationele databasemodel is conceptueel zelfs nog eenvoudiger dan het hiërarchische of netwerkdatabasemodel.

Omdat het relationele databasemodel de ontwerper ontlast van de details van de fysieke opslag van de gegevens, kunnen ontwerpers zich concentreren op de logische weergave van de database.

Eenvoudig ontwerp, implementatie, onderhoud en gebruik

Het relationele databasemodel bereikt zowel gegevensonafhankelijkheid als structuuronafhankelijkheid, waardoor het ontwerp, het onderhoud, de administratie en het gebruik van de database veel eenvoudiger is dan de andere modellen.

Ad-hoc querycapaciteit

De aanwezigheid van een zeer krachtige, flexibele en eenvoudig te gebruiken zoekfunctie is een van de belangrijkste redenen voor de immense populariteit van het relationele databasemodel.

De querytaal van het relationele databasemodel, de zogenaamde gestructureerde querytaal of SQL, maakt ad-hocquery's werkelijkheid. SQL is een taal van de vierde generatie (4GL).

Met een 4GL kan de gebruiker aangeven wat er moet gebeuren, zonder te specificeren hoe het moet worden gedaan. Met SQL kunnen gebruikers dus specificeren welke informatie ze willen en de details achterlaten over hoe ze de informatie naar de database kunnen krijgen.

Nadelen

Hardware-uitgaven

Het relationele databasemodel verbergt de complexiteit van de implementatie en de details van de fysieke opslag van gebruikersgegevens.

Om dit te doen, hebben relationele databasesystemen computers nodig met krachtigere hardware en apparaten voor gegevensopslag.

Daarom heeft het RDBMS krachtige machines nodig om soepel te werken. Omdat de verwerkingskracht van moderne computers echter exponentieel toeneemt, is de behoefte aan meer verwerkingskracht in het huidige scenario niet langer een erg groot probleem.

Ontwerpgemak kan leiden tot een slecht ontwerp

De relationele database is eenvoudig te ontwerpen en te gebruiken. Gebruikers hoeven de complexe details van de fysieke opslag van gegevens niet te kennen. Ze hoeven niet te weten hoe de gegevens daadwerkelijk zijn opgeslagen om er toegang toe te krijgen.

Dit eenvoudige ontwerp en gebruik kan leiden tot de ontwikkeling en implementatie van slecht ontworpen databasebeheersystemen. Omdat de database efficiënt is, zullen deze ontwerpinefficiënties niet aan het licht komen wanneer de database is ontworpen en er slechts een kleine hoeveelheid gegevens is.

Naarmate de database groeit, zullen slecht ontworpen databases het systeem vertragen en leiden tot prestatieverlies en gegevensbeschadiging.

Fenomeen van «informatie-eilanden»

Zoals eerder vermeld, zijn relationele databasesystemen eenvoudig te implementeren en te gebruiken. Hierdoor ontstaat een situatie waarin te veel mensen of afdelingen hun eigen databases en applicaties zullen aanmaken.

Deze informatie-eilanden verhinderen de integratie van informatie, wat essentieel is voor het vlot en efficiënt functioneren van de organisatie.

Deze individuele databases zullen ook problemen veroorzaken zoals inconsistentie van gegevens, gegevensduplicatie, gegevensredundantie, enz.

Voorbeeld

Stel een database voor die bestaat uit de tabellen Leveranciers, Onderdelen en Zendingen. De structuur van de tabellen en enkele voorbeeldrecords is als volgt:

Elke rij in de tabel Leveranciers wordt geïdentificeerd door een uniek leveranciersnummer (SNo), waarmee elke rij in de tabel uniek wordt geïdentificeerd. Evenzo heeft elk onderdeel een uniek onderdeelnummer (PNo).

Bovendien kan er niet meer dan één zending zijn voor een bepaalde combinatie van leverancier / onderdeel in de tabel met zendingen, aangezien deze combinatie de primaire sleutel van zendingen is, die dient als een unietabel, aangezien het een veel-op-veel-relatie is.

De relatie tussen de tabellen Onderdelen en Zendingen wordt gegeven door het veld PNo (onderdeelnummer) gemeenschappelijk te hebben en de relatie tussen leveranciers en zendingen ontstaat doordat het veld SNo (leveranciersnummer) gemeenschappelijk is.

Door de zendingen tabel te analyseren, is het mogelijk om informatie te verkrijgen dat er in totaal 500 noten worden verzonden van Suneet en Ankit leveranciers, elk 250.

Evenzo werden in totaal 1.100 bouten verzonden door drie verschillende leveranciers. Er zijn 500 blauwe schroeven verzonden vanaf de leverancier van Suneet. Er zijn geen verzendingen van rode schroeven.

Referenties

1. Wikipedia, de gratis encyclopedie (2019). Relationeel model. Ontleend aan: en.wikipedia.org.
2. Techopedia (2019). Relationeel model. Genomen van: ceilingpedia.com.
3. Dinesh Thakur (2019). Relationeel model. Ecomputer-opmerkingen. Overgenomen van: ecomputernotes.com.
4. Geeks for Geeks (2019). Relationeel model. Ontleend aan: geeksforgeeks.org.
5. Nanyang Technologische Universiteit (2019). Een snelstart-zelfstudie over relationeel databaseontwerp. Genomen uit: ntu.edu.sg.
6. Adrienne Watt (2019). Hoofdstuk 7 Het relationele gegevensmodel. BC Open Textbooks. Genomen uit: opentextbc.ca.
7. Toppr (2019). Relationele databases en schema's. Genomen van: toppr.com.