De relationeel model van databases 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..
Codd had geen idee hoe buitengewoon vitaal en invloedrijk zijn werk als platform voor relationele databases zou zijn. De meeste mensen zijn erg 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 velden die voor elke gerelateerde tabel gemeenschappelijk zijn..
Artikel index
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 de databasemanagementsysteemsoftware de leiding hebben over het beschrijven van de datastructuren voor opslag 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.
- 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, op elke rij- / kolompositie in de tabel is er maar één waarde.
De volgende afbeelding toont een tabel met de namen van de basiselementen, die samen een complete structuur vormen.
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.
Elke kolom in een tupel wordt een attribuut of veld genoemd. De kolom vertegenwoordigt de set waarden die een specifiek kenmerk kan hebben.
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. Wordt gebruikt om naar de primaire tabel te verwijzen.
Bij het ontwerpen van het relationele model definieert u enkele voorwaarden waaraan in de database moet worden voldaan, de zogenaamde integriteitsregels.
De primaire sleutel moet uniek zijn voor alle tuples en mag niet null zijn. Anders kunt u de rij niet uniek identificeren.
Voor een sleutel met meerdere kolommen kan geen van deze kolommen NULL bevatten.
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 bovenliggende tabel verandert, door de rij bij te werken of te verwijderen, dan moeten alle rijen in de onderliggende tabellen met deze externe sleutel dienovereenkomstig worden bijgewerkt of verwijderd.
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..
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.
Een database die bestaat uit onafhankelijke en 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:
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..
Omdat een leraar echter in veel klassen les kan geven, worden zijn gegevens in veel rijen van de tabel Klassen gedupliceerd.
Daarom moeten er twee tabellen worden ontworpen: 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..
Vervolgens kan de een-op-veel-relatie worden gemaakt door de primaire sleutel van de hoofdtabel (Master_Id) op te slaan in de klassentabel, 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.
In een "Productverkoop" -database kan de bestelling van een klant meerdere producten bevatten en kan een product in meerdere bestellingen voorkomen. Dit type relatie is bekend als velen tot velen.
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 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 bestellingen om dezelfde reden 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..
In de database "Verkoop van producten" kan een product optionele informatie bevatten, zoals een aanvullende beschrijving en de afbeelding. Als u het in de producttabel houdt, genereert u veel lege ruimtes.
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 primaire sleutel voor beide tabellen.
In het relationele databasemodel hebben wijzigingen in de databasestructuur geen invloed op de gegevenstoegang.
Wanneer het mogelijk is om wijzigingen aan te brengen in de structuur van de database zonder de mogelijkheid van het DBMS om toegang tot de gegevens te krijgen, aan te tasten, kan worden gesteld dat structurele onafhankelijkheid is bereikt.
Het relationele databasemodel is conceptueel zelfs nog eenvoudiger dan het hiërarchische of netwerkdatabasemodel.
Omdat het relationele databasemodel de ontwerper bevrijdt van de details van de fysieke opslag van de gegevens, kunnen ontwerpers zich concentreren op de logische weergave van de database.
Het relationele databasemodel bereikt zowel data-onafhankelijkheid als structuuronafhankelijkheid, wat het ontwerp, het onderhoud, de administratie en het gebruik van de database veel eenvoudiger maakt dan de andere modellen..
De aanwezigheid van een zeer krachtige, flexibele en gebruiksvriendelijke querycapaciteit is een van de belangrijkste redenen voor de immense populariteit van het relationele databasemodel.
De querytaal van het relationele databasemodel, genaamd Structured Query Language 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.
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..
De relationele database is eenvoudig te ontwerpen en te gebruiken. Gebruikers hoeven de complexe details van fysieke gegevensopslag 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..
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..
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..
Bij analyse van de verzendtabel kan als informatie worden verkregen 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. Geen verzending van rode schroeven.
Niemand heeft nog op dit artikel gereageerd.