Misschien heb je ooit al eens je cd’s of dvd's ‘in de computer’ gezet, of alle gegevens van je vrienden en kennissen in Outlook. Daarmee heb je een vorm van een database gemaakt. Maar een database met een cd-verzameling is niet te vergelijken met een database die in een gemiddeld bedrijf wordt gebruikt, bijvoorbeeld één met alle klantgegevens of alle productgegevens. In dat geval gaat het om grote aantallen gegevens, die regelmatig veranderd moeten worden en die van groot belang zijn voor het functioneren van het bedrijf.

De eerste vraag die gesteld moet worden, is: hoe kan een database bijdragen aan het realiseren van de doelstellingen van een bedrijf of organisatie? Belangrijk is dan ook dat je niet zonder meer begint, maar dat je eerst nadenkt over wat je eigenlijk nodig hebt – de gegevensanalyse. Bijvoorbeeld:

• Welke gegevens wil je registreren?
• Welke relaties zijn er tussen die gegevens?
• Moet het mogelijk zijn om selecties te maken?
• Wil je kunnen sorteren, en zo ja, waarop?
• Enzovoort.

Het maken van een bruikbare en betrouwbare database is een vak apart. Daar hoort ook een bepaald jargon bij. We gaan eerst proberen om je daarmee vertrouwd te maken.

In de wereld van de gegevensanalyse en het database-ontwerp is een entiteit: een object waarvan gegevens worden opgeslagen. Die gegevens moeten relevant zijn binnen het bedrijf of de organisatie waarvoor de database wordt ontwikkeld. Voorbeelden zijn:

• een leerling
• een boek
• een tafel
• het vak Nederlands
• de studentenadministratie

Van elke entiteit moeten in de database de relevante kenmerken worden vastgelegd, met andere woorden: de eigenschappen die beantwoorden aan het doel waarvoor gegevens in een database worden opgenomen. Deze eigenschappen worden attributen genoemd.

Voorbeeld: Studentenadministratie
De studentenadministratie van een onderwijsinstelling is geïnteresseerd in de volgende gegevens van alle studenten: achternaam, voornaam, adres, woonplaats, geboortedatum, geslacht, wanneer de student met de opleiding begonnen is, in welke klas deze zit e.d.

Petra Hoving is student aan deze instelling. We kunnen dan in database-jargon zeggen dat van het object ‘student’ de entiteit Petra Hoving in de database wordt opgenomen. De vastgelegde attributen zijn in dit geval:

• Hoving
• Petra
• Jansstraat 12
• 6811 GJ
• Arnhem
• 1994-08-15
• V(rouwelijk)
• 2006
• 2C

In de volgende tabel zie je een voorbeeld van een mogelijke tabel (ingekort) van de studentenadministratie.

Een tabel bestaat uit kolommen en rijen:

• In de kolommen plaatsen we de attributen, bijvoorbeeld naam, adres, woonplaats, geboortedatum, klas, enzovoort.
• In de rijen komen de entiteiten, in het schoolvoorbeeld zijn dit alle leerlingen. Als een school duizend leerlingen telt, zal de tabel duizend rijen omvatten.

Het boek Stationsarchitectuur bezit een aantal eigenschappen. Het heet ‘Stationsarchitectuur’: dat is de titel van het boek. Het heeft ook een unieke aanduiding. Dat is 978 57300 09 5: dat wordt het ISBN van het boek genoemd. Het boek is geschreven door C. Douma: dat is de auteur. Al deze eigenschappen worden attributen genoemd. Een paar attributen van deze entiteit zijn dus:

• Titel: Stationsarchitectuur
• ISBN: 978 57300 09 5
• Auteur: Douma, C.

Welke attributen horen nu wel en welke horen niet bij een bepaalde entiteit? De attributen

• Jansstraat 12
• 6811 GJ
• Arnhem
• 1989-08-15
• V(rouwelijk)

Een student zit in een klas. Is bijvoorbeeld 2C een attribuut van Petra Hoving? Ja en nee. Ja, want de studentenadministratie moet weten in welke klas Petra zit. Voor de studentenadministratie is 2C dus wel degelijk een eigenschap van Petra Hoving. Maar 2C is wel een tijdelijke eigenschap van Petra. Niet alleen omdat zij volgend jaar (hopelijk) in een andere klas zit. Als Petra van school af is, is het helemaal niet meer interessant dat ze in een klas zit. In dat laatste verband is het antwoord dus: nee.

Het hangt van de omgeving af of iets als een eigenschap van een object wordt beschouwd. Die ‘omgeving’ is hier de studentenadministratie.

De attributen van de entiteit ‘Petra Hoving’.

• Khalid el Bahri bezit ‘Stationsarchitectuur’.
• Khalid el Bahri heeft geleend ‘Stationsarchitectuur’.

Het heeft geen zin om een model te maken op basis van alle entiteiten en hun relaties. In de eerste plaats zou dat wel een erg omvangrijk model worden, want er zijn honderden studenten, boeken en tientallen klassen. In de tweede plaats is de keuze van al deze objecten en relaties een momentopname. De verzameling gegevens kan over een uur alweer veranderd zijn.

Daarom gaan we zoeken naar een eenvoudiger methode om een informatiemodel te maken. Een goede manier om dit probleem aan te pakken is classificeren.

Classificatie houdt in dat je:

• alle entiteiten van een bepaalde soort samen neemt tot entiteittype;
• alle attributen van een bepaalde soort samen neemt tot attribuuttype;
• alle relaties van een bepaalde soort samen neemt tot relatietype.

Ook de klassen 2A, 2B, 2C enzovoort kunnen worden geclassificeerd tot een entiteittype, namelijk Klas. Zo is er ook het entiteittype Boek.

Petra, Hoving, Khalid en El Bahri zijn in de database dus attribuutwaarden. Eigenlijk is er sprake van de attribuutwaarde Petra en de attribuutwaarde Hoving. Evenzo is er sprake van de attribuutwaarde Khalid en de attribuutwaarde El Bahri.

In het ene geval gaat het om een voornaam en in het andere geval om een achternaam, en dat zijn gescheiden kolommen in de tabel. Het ligt dan ook voor de hand om bij de classificatie van deze attributen de aanduiding attribuuttype te gebruiken. Een attribuuttype is de classificatie van gelijksoortige waarden.

Zo spreken we van het attribuuttype Voornaam en het attribuuttype Achternaam. Voornaam en Achternaam zijn allebei attribuuttypen van het entiteittype Student. Het entiteittype Student kent nog meer attribuuttypen; denk aan:

• Adres
• Postcode
• Woonplaats
• Geboortedatum
• Geslacht

Ook bij het boek Stationsarchitectuur is sprake van attribuutwaarden, namelijk:

• Stationsarchitectuur
• 978 57300 09 5
• Douma, C.

Er is weinig verschil tussen relaties en relatietypen. De zin ‘Petra Hoving zit in 2C’, heeft als relatie ‘zit in’. De beschrijving van die relatie verandert niet wanneer de zin gaat luiden: ‘Khalid el Bahri zit in 2C’ en ook niet bij de zin: ‘Wim Janssen zit in 4A’.

Wanneer we deze zinnen gaan classificeren, wordt de geclassificeerde zin: ‘Student zit in Klas’. De naam van het relatietype wordt dus ‘zit in’.

Benoem de relatie bij voorkeur in het enkelvoud. Dat past ook beter bij de enkelvoudige benamingen van de entiteittypen. Een zin als: ‘Student zitten in Klas’ klinkt niet, vandaar alles in het enkelvoud.