Wat is een Relationeel Schema? Hoe maak je een efficiënte database?
Er is geen enkele databasestructuur die altijd efficiënter is dan een andere. Dit komt omdat het type en de hoeveelheid opgeslagen gegevens de optimale structuur van de database veranderen.
Echter, er is een groot verschil tussen het bouwen van een database die is geoptimaliseerd voor prestaties versus een die is geoptimaliseerd voor datavolume.
Met behulp van relationele schema’s in MySQL, kunt u een database maken die is geoptimaliseerd voor datavolume. Dit is ideaal in situaties waar de kosten van opslag, verwerking, en geheugen onbetaalbaar duur zijn.
Hoewel dit niet meer het geval is voor standaard elektronica, zijn er nog tal van situaties waarin programmeurs en ontwikkelaars een relationeel schema zouden willen gebruiken. Hoewel opslag, verwerkingskracht en geheugen goedkoop zijn voor gebruikers van conventionele computers, zijn deze dingen massaal duur in de wereld van quantum computing.
Ook is een relationeel schema belangrijk in MySQL-databases die vertrouwen op relaties om betekenis te genereren. Werknemer en academische records, bijvoorbeeld, kan gemakkelijk worden gedacht van netwerken van relaties beter beschreven met behulp van relationele schema dan, bijvoorbeeld, key-value of graph databases.
Het relationele schema is het primaire element van de relationele database. Deze databases worden beheerd met behulp van taal en structuur die consistent is met eerste-orde logica. Dit maakt databasemanagement op basis van entiteitsrelaties mogelijk, waardoor ze gemakkelijk naar volume zijn in te delen.
Relationeel schema verwijst naar de meta-data die de structuur van gegevens binnen een bepaald domein beschrijft. Het is de blauwdruk van een database die de manier schetst waarop de structuur gegevens in tabellen ordent.
Als uw database bijvoorbeeld werknemersrecords bevat voor een grote onderneming, dan hebt u misschien entiteitsrelaties die elke werknemer als een sterke entiteit als volgt beschrijven:
- Employee Name
- ID Number
- Address
- Employee Skillset
- Hiring Date
- Years of Service
In dit voorbeeld zou u twee attributen van relationele schema-gegevens hebben. Ten eerste zou u het kenmerk Werknemer hebben, dat de primaire sleutel van de tabel is (aangezien alles betrekking heeft op de werknemer) en een kenmerk Adres, dat een samengesteld kenmerk is dat uit verschillende elementen bestaat.
Het Adres-attribuut zou uit de volgende waarden bestaan:
- Stad
- Straat
- Adresnummer
- Geboorteplaats
Nu u dit weet, bent u klaar om een entiteit-relatieschema naar een relationeel schema te vertalen. Het zou er als volgt uit moeten zien:
- Werknemer (Naam, ID Nummer, Adres Nummer, Straat, Stad, Postcode, Aanstellingsdatum)
- Werknemer Vaardigheidsset (ID Nummer, Vaardigheidsset)
U zou moeten opmerken dat Jaren van Dienst uitgesloten is van deze lijst. Dat komt omdat het een afgeleid attribuut is dat kan worden berekend door de Aanwervingsdatum af te trekken van de huidige datum. De reden dat de vaardigheden van de werknemer een eigen schema hebben, is dat het een attribuut is met meerdere waarden.
Voor relationele schema’s wordt elk entiteittype zijn eigen tabel, en elk attribuut met één waarde is een kolom in die tabel. Afgeleide attributen kunnen veilig worden genegeerd, terwijl attributen met meerdere waarden aparte tabellen worden.
De methode voor het converteren van zwakke entiteittypen naar het relationele schema is vergelijkbaar met het hierboven beschreven proces, behalve dat zwakke entiteittypen eigen tabellen worden en de primaire sleutel van de sterke entiteit fungeert als een foreign key in de tabel.
Dit betekent dat u voor de sterke entiteit Employee een samengestelde primaire sleutel zou maken die bestaat uit de foreign key Dependent en de sleutel van de zwakke entiteit zelf. Het schema zou er dan als volgt uitzien:
- Werknemer (Naam, ID-nummer, Adresnummer, Straat, Stad, Postcode, Aanstellingsdatum)
- Afhankelijke (Werknemer, Afhankelijke ID, Naam, Adres)
De correlatie hier is tussen het ID-nummer in de tabel Werknemer en het Werknemer-element van de tabel Afhankelijke.
Met dit werk gedaan, bent u klaar om te beginnen met het converteren van relaties. Dit vereist inzicht in de kardinaliteit en graad van elke relatie.
- Er zijn drie mogelijke kardinaliteiten – 1:1, 1:M, 1:N
- Er zijn drie mogelijke graden – unair, binair, en ternair.
Het bovenstaande voorbeeld verder nemend, zou Werknemer kunnen worden gecombineerd met een nieuwe Afdeling-tabel om een binaire 1:1-relatie te vormen. Indien de werknemer een specifieke afdeling beheert, dan kan hij of zij worden beschreven als een gedeeltelijke deelnemer, terwijl de afdeling zou worden beschreven als een totale deelnemer.
Het relationele schema zou er als volgt uitzien:
- Werknemer (Naam, ID-nummer, Adresnummer, Straat, Stad, Postcode, Aanstellingsdatum)
- Afdeling (Manager ID-nummer, Afdeling-ID, Naam, Adres)
In dit geval wordt de primaire sleutel van de gedeeltelijke deelnemer de vreemde sleutel van de totale deelnemer. Het ID-nummer van de manager correleert met het ID-nummer van de juiste werknemer.
Dit laat een belangrijk onderdeel zien van het maken van het relationele schema. De primaire sleutel van een van beide deelnemers in een binaire 1:1 relatie kan een vreemde sleutel worden in de andere. Een andere manier om de bovenstaande relatie te beschrijven zou zijn Manages te gebruiken als de vreemde sleutel onder Employee, correlerend met de primaire sleutel Department ID onder Department.
Een voorbeeld van een binaire 1:N-relatie zou zijn die tussen een Docent die lesgeeft aan een Vak. In een bepaald klaslokaal kunnen docenten meer dan één vak onderwijzen aan een verscheidenheid van leerlingen, maar alle vakken delen dezelfde relatie met de docent.
In de binaire 1:1 relatie hierboven had elke afdeling een unieke manager. Met deze binaire 1:N-relatie kan een variabel aantal studenten dezelfde leraar delen. De primaire sleutel van Leraar zou de Leraar-ID zijn, die zou correleren met de vreemde sleutel van Onderwerp, onder Leraar.
Om een binaire M:N-relatie te beschrijven, stel je een student voor die zich voor een cursus inschrijft. Maak een nieuwe tabel die Student beschrijft en een andere die Cursus beschrijft. Beide tabellen zijn gerelateerd door de handeling van inschrijving, en beide hebben foreign keys.
- De foreign key voor Student is de Student ID.
- De foreign key voor Cursus is de Cursus ID.
De primaire sleutel van de nieuwe tabel is de combinatie van de foreign keys van elke entiteit. Je zou het omschrijven als (Studenten-ID, Cursus-ID). Dit is een uniek binair M:N-relationeel schema dat individuele studenten aan cursussen koppelt.
Dit werkt omdat ID’s van nature worden gemaakt met het doel als vreemde sleutels in relationele databases te fungeren.
U kunt een relationeel schema gebruiken om zelfverwijzende relaties te beschrijven. Bijvoorbeeld, twee werknemers die getrouwd zijn met elkaar kunnen de Spouse foreign key hebben. Voor de foreign keys van deze beide werknemers zal worden verwezen naar de Employee ID van de andere werknemer, die de primaire sleutel is van de respectieve tabel van elke werknemer.
Dit werkt ook in relatieschema’s met een 1:N cardinaliteit. Het primaire sleutelveld zelf zou in dit geval de vreemde sleutel van dezelfde tabel worden. Dit is hetzelfde als een unair 1:1 schema.
Bijv. een Werknemer die de manager is van een Ondergeschikte kan manager als zijn of haar foreign key hebben. In dat geval zou de ID van de werknemer de primaire sleutel in dezelfde tabel zijn.
Zelfverwijzing naar een M:N-relatie vereist twee tabellen. De ene moet de entiteit in kwestie weergeven en de andere moet de M:N-relatie weergeven.
Stel u een werknemer voor die verantwoordelijk is voor het garanderen van de kwaliteit van een bepaald product of een bepaalde dienst. Deze relatie zou zowel de Garant als de Begunstigde moeten omvatten als vreemde sleutels die samen correleren met de Werknemer-ID van de Werknemer-tabel. Zowel Guarantor en Beneficiary zou fungeren als primaire en buitenlandse sleutels binnen de nieuw gecreëerde relationele schema tabel.
Hoewel binaire en unaire relaties zijn eenvoudig te beschrijven met behulp van het relationele schema met een of twee tabellen. Ternary tabellen vereisen een derde, nieuwe tabel.
De primaire sleutel van deze nieuwe tabel bestaat uit de foreign key van elke deelnemende entiteit, bij elkaar opgeteld. Dit betekent dat de nieuwe tabel drie foreign keys moet bevatten om mee te correleren.
Bijv. de relatie tussen een arts en haar patiënt bestaat in feite uit drie entiteiten: De dokter, de patiënt en de medicijnen. Om deze relatie goed te beschrijven als een relationeel schema, moet u foreign keys toewijzen aan elk van deze entiteiten en ze correleren aan een nieuwe tabel met de naam Prescription.
Dit is een eenvoudige manier om te visualiseren hoe een ternaire tabel werkt. De primaire sleutel van de nieuw aangemaakte tabel Prescription is (Doctor ID, Patient ID, Drug ID). Elk schema dat deze drie belangrijke stukjes gegevens niet bevat, mist een belangrijk deel van de puzzel.
Met deze aanpak zou een database-manager een georganiseerd archief van recepten kunnen maken dat rekenschap geeft van specifieke medicijntypen, onmiddellijk gecorreleerd aan de namen van patiënten die ze gebruiken en de namen bieden van de artsen die ze hebben voorgeschreven.
Voor de volledigheid kunt u misschien de vervaldatum toevoegen aan de tabel Medicijnen, zodat deze gegevens beschikbaar zijn binnen de hoofdmatrix. U kunt de datum van de volgende afspraak of de datum van de navulling toevoegen aan de tabel met het voorschrift. U zou logischerwijs Geboortedatum, Adres, en andere belangrijke relationele gegevens willen toevoegen aan de Patiënt tabel.
Al deze tools maken samen het maken van relatie-georiënteerde databases mogelijk in MySQL. U kunt oefenen met het maken van uw eigen MySQL-databases online met elke browser met behulp van SQLDBM.