Database modellen

Gegevens die gemodelleerd zijn volgens het platte datamodel, worden geïmplementeerd in een platte database. Zo'n database is in wezen een eenvoudige tabel, waarbij alle elementen in dezelfde kolom gelijksoortige waarden bevatten, terwijl alle elementen van een rij aan elkaar gerelateerd zijn. Zo zouden kolommen voor naam en wachtwoord van toepassing kunnen zijn als onderdeel van een beveiligingsdatabase. Elke rij bevat dan het bij een specifieke gebruiker behorende wachtwoord. Vaak zijn kolommen verbonden met een gegevenstype, zoals: tekstuele informatie, datum- of tijdinformatie, gehele getallen, …

Een moderne en zeer veel gebruikte implementatie van het platte datamodel is de spreadsheet. In een spreadsheet is meestal ook sprake van een eenvoudige datastructuur van rijen en kolommen.

Het hiërarchische databasemodel gaat ervan uit dat elk record in een database weer kan verwijzen naar een n-aantal andere records. Het is zo een boomstructuur, die steeds verder kan vertakken. Kenmerkend is wel dat ieder recordtype één en niet meer dan één eigenaar kent.

Het hiërarchische model kent maar één boom per database, de takken hebben onderling geen samenhang en de enige ingang van de boomstructuur is van bovenaf.

Om een voorbeeld te nemen, de database bedrijf heeft als hoofdtakken vestigingen, producten, klanten. In dat geval is er geen relatie tussen vestiging en product, product A kan in elke vestiging gemaakt worden. Wanneer product A alleen in vestiging X gemaakt wordt, kan dat in dit hiërarchische model niet vastgelegd worden.

Wanneer nu in het bovenstaande model onder klanten een recordtype orders wordt toegevoegd, dan houdt dat in dat elke order bij één klant hoort, maar dat een klant meer dan één order kan hebben. De op de order voorkomende producten kunnen echter niet automatisch gekoppeld worden, omdat de gegevens van de order in een andere tak staan.

Dit schetst de zwakte van het hiërarchische model, de opvolger van dit model is het netwerkmodel.

Het netwerkmodel borduurt verder op het hiërarchische model door niet alleen 1 op n relaties tussen gegevensobjecten toe te staan (één ouder heeft mogelijk meerdere kinderen, maar één kind heeft altijd maar één ouder), maar ook n op m relaties (nu kan één kind ook meerdere ouders hebben). Op deze manier kan wel bijgehouden worden welke producten er in welke order voorkomen.

Indien we de gegevens van een database structureren via het relationele model, dan worden gegevens opgeslagen in tabellen (de wiskundige term daarvoor is relaties, vandaar de naam relationele model). Gegevens over bijvoorbeeld gerechten worden dan opgeslagen in een tabel Gerecht.

GERECHT

Coupe Kiwano

431

20

Schil de kiwano, snijd hem in stukjes, voeg de tequila toe en laat dit mengsel 15 minuten staan. Neem per persoon 3 bolletjes ijs en voeg hier de kiwano met tequila aan toe. Serveer met gezoete stijfgeslagen slagroom.

Glace Terrace

403

5

Neem drie bolletjes ijs, voeg hieraan de gesneden aardbeien toe, besprenkel dit rijkelijk met pernod en maak dit bijzondere gerecht af met versgemalen peper.

Mango Plus Plus

131

8

Snijd de geschilde mango in stukjes, meng deze met de gehalveerde aardbeien en serveer dit met de zure room.

De tabel heeft kolommen voor de verschillende wetenswaardigheden over gerechten (naam, energiewaarde per persoon, bereidingstijd en bereidingswijze). De tabel is gevuld met rijen, en wel één rij per gerecht.

We missen nog een manier om te voorkomen dat hetzelfde gerecht tweemaal wordt ingevoerd, en we hebben nog niet alle informatie over gerechten (waar zijn de ingrediënten?!). Voor het eerste gebruiken we sleutels, voor het tweede verwijzingen naar nieuwe tabellen.

Als we willen voorkomen dat hetzelfde gerecht tweemaal wordt ingevoerd, komen er twee vragen op: waaraan zien we dat het in beide gevallen om hetzelfde gerecht gaat, en waarom willen we eigenlijk niet dat een gerecht tweemaal genoemd wordt? Een antwoord op de eerste vraag vinden we in het algemeen door de werkelijkheid goed te bestuderen. Een voorbeeld: in het systeem van de belastingdienst worden verschillende personen uit elkaar gehouden door hun burgerservicenummer, dat speciaal voor dat doel in het leven is geroepen. In het voorbeeld van de gerechtendatabase kunnen we ervoor kiezen gerechten uit elkaar te houden door middel van hun namen. We geven dat aan door de kolom naam te promoveren tot primaire-sleutelkolom.

Vanaf nu let het databasemanagementsysteem erop dat gerechten niet tweemaal ingevoerd worden: zodra een gerechtsnaam wordt ingevoerd die al in de tabel voorkomt, komt er een foutmelding. Dit noemen we een genormaliseerd database model.

We hebben nu nog geen antwoord gegeven op de vraag waarom we niet tweemaal hetzelfde gerecht in onze tabel willen hebben. Dat antwoord luidt: omdat dat kan leiden tot inconsistentie in de database. Stel u maar voor dat er twee rijen voor Coupe Kiwano in de tabel Gerecht staan, met in de ene rij energiePP gelijk aan 431 en in de andere gelijk aan 134: wat is nu de juiste waarde?

Nu we een manier hebben om gerechten uit elkaar te houden (in databasetermen: rijen te identificeren) kunnen we die gebruiken om een ander probleem op te lossen: waar zijn de ingrediënten? De oplossing is: die staan in een aparte tabel. Maar dat levert weer een ander probleem op: hoe weten we welke ingrediënten bij welk gerecht horen?

Tabellen worden aan elkaar gekoppeld door middel van verwijzingen. Preciezer, in het gerechtenvoorbeeld: rijen uit de tabel Ingrediënt worden gekoppeld aan precies één rij in de tabel Gerecht, door middel van een verwijssleutel die wijst van de kolom gerecht in Ingrediënt naar de primaire-sleutelkolom naam van Gerecht:

Binnen deze cursus zullen we werken aan de hand van het relationele databasemodel. Dit via Microsoft Access.