Databaseontwikkeling Access 2003

Databaseontwikkeling 4 (Access 2003)

Database-ontwikkeling 4 (Access 2003)

Ies Korpershoek

Ben Groenendijk

Meer informatie over deze en andere uitgaven kunt u verkrijgen bij:Sdu KlantenservicePostbus 200142500 EA Den Haagtel.: (070) 378 98 80fax: (070) 378 97 83

2007 Sdu Uitgevers bv, Den HaagAcademic Service is een imprint van Sdu Uitgevers bv

1e druk, juli 20052e druk, maart 2007

Vormgeving en omslag: Studio Bassa, Culemborg

Zetwerk: Redactiebureau Heijer, Markelo

ISBN 978 90 395 2483 1NUR 124

Alle rechten voorbehouden. Alle auteursrechten en databank-rechten ten aanzien van deze uitgave worden uitdrukkelijk voorbehouden. Deze rechten berusten bij Sdu Uitgevers bv.

Behoudens de in of krachtens de Auteurswet 1912 gestelde uitzonderingen, mag niets uit deze uitgave worden verveel-voudigd, opgeslagen in een geautomatiseerd gegevensbestand of openbaar gemaakt in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopien, opnamen of enige andere manier, zonder voorafgaande schriftelijke toestemming van de uitgever.

Voorzover het maken van reprograsche verveelvoudigin-gen uit deze uitgave is toegestaan op grond van artikel 16 h Auteurswet 1912, dient men de daarvoor wettelijk verschul-digde vergoedingen te voldoen aan de Stichting Reprorecht (postbus 3051, 2130 KB Hoofddorp, www.reprorecht.nl). Voor het overnemen van gedeelte(n) uit deze uitgave in bloemlezingen, readers en andere compilatiewerken (artikel 16 Auteurswet 1912) dient men zich te wenden tot de Stichting PRO (Stichting Publicatie- en Reproductierechten Organisatie, Postbus 3060, 2130 KB Hoofddorp, www.cedar.nl/pro). Voor het overnemen van een gedeelte van deze uitgave ten behoeve van commercile doeleinden dient men zich te wenden tot de uitgever.

Hoewel aan de totstandkoming van deze uitgave de uiter-ste zorg is besteed, kan voor de afwezigheid van eventuele (druk)fouten en onvolledigheden niet worden ingestaan en aanvaarden de auteur(s), redacteur(en) en uitgever deswege geen aansprakelijkheid voor de gevolgen van eventueel voor-komende fouten en onvolledigheden.

All rights reserved. No part of this publication may be repro-duced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recor-ding or otherwise, without the publishers prior consent.

While every effort has been made to ensure the reliability of the information presented in this publication, Sdu Uitgevers neither guarantees the accuracy of the data contained herein nor accepts responsibility for errors or omissions or their con-sequences.

Woord vooraf

Dit boek is bestemd voor de niveau 4-opleiding ICT-beheerder op basis van de nieuwe competentiegerichte eindtermen voor MBO-ICT die vanaf 2007 van kracht zijn.

Bij de ontwikkeling van de leerstof voor de nieuwe competentie-gerichte eindtermen is ervoor gekozen om de competenties van de kerntaken in samenhang te behandelen. Zeker bij het onderwerp databases is het logisch om de competenties van zowel het ont-wikkelen (ontwerpen/realiseren) als het beheren/onderhouden van een informatiesysteem aan de hand van de toepassing van de po-pulaire applicatie Access (in dit geval versie 2003) te behandelen.

In dit boek is gestreefd naar een praktische benadering van de informatie- en gegevensanalyse. Het verdient aanbeveling om de inhoud van dit boek af te wisselen met de inhoud van de afzon-derlijke uitgave over informatieanalyse. De kandidaat kan met dit boek over Access 2003 zelfstandig de opdrachten maken en daar-voor terugvallen op de eerder behandelde theorie. De docent kan als begeleider optreden, maar als hij dat verkiest ook klassikaal de theoretische onderdelen behandelen. In ieder geval zal de deel-nemer in of buiten het klaslokaal veel tijd aan de computer door-brengen. Aan het einde van dit deel moet de deelnemer in staat zijn zelfstandig een eenvoudige probleemanalyse uit te voeren en deze uit te werken in een werkende, gebruikersvriendelijke relationele databasetoepassing.

In het boek wordt ieder onderwerp eerst besproken en toegelicht, waarbij volop gebruik gemaakt is van relevante schermafdrukken. Vervolgens wordt er bij ieder onderwerp een opgave aangeboden waarin de theoretische kennis direct praktisch kan worden toege-past. In de opgaven wordt een aantal bestaande databases gebruikt. Op de hierin opgeslagen gegevens moeten vervolgens de nodige bewerkingen worden uitgevoerd.

Databaseontw ikke l ing 4 (Access 2003)vi

Het is niet noodzakelijk eerst het deel Informatieanalyse te behan-delen alvorens over te gaan op het deel gegevensanalyse en eventu-eel te besluiten met SQL. De delen staan los van elkaar en kunnen dus in willekeurige volgorde naast of na elkaar gebruikt worden.

Uiteraard moet er bij dit boek gewerkt kunnen worden met Microsoft Access versie 2003 in de Nederlandse versie. De bij dit boek behorende databases zijn te vinden op de cd-rom die u achter in het boek aantreft.

Bij dit boek is een docentenhandleiding beschikbaar. Hierin is per hoofdstuk toegelicht op welke wijze het betreffende hoofdstuk zou kunnen worden behandeld. Verder wordt bij de in het boek opgeno-men vragen extra toelichting gegeven.

Daarnaast zijn de antwoorden (querys) van het laatste hoofdstuk, werken met SQL, beschikbaar. Bovendien zijn er cases om de deelnemers extra te laten oefenen met het opzetten, inrichten en gebruiken van databases. Een voorbeeld van een uitgewerkte case is te vinden in bijlage C.

De eerste serie cases richt zich met name op de eerste zeven hoofd-stukken van het boek, dus normaliseren, eenvoudige bewerkingen in Access en het werken met rapporten en formulieren. De tweede serie cases richt zich op het werken met SQL. Daarbij is ook een vrij grote database beschikbaar. Iedere serie cases bestaat uit 18 verschillende opgaven. De opgaven zijn in Word-formaat beschikbaar en dus eventueel nog aan te pas-sen aan uw eigen wensen. Cases worden voortdurend aangepast of vernieuwd. Docenten kunnen hierover contact opnemen met de auteurs via e-mail. Ook vragen of opmerkingen zijn welkom. De adressen zijn: [email protected] en [email protected].

Ben Groenendijk februari 2007Ies korpershoek

vii

Inhoud

Inleiding xiii

1 Gegevens en betrouwbaarheid 11.1 Gegevens en informatie 11.2 Integriteit 21.3 Consistentie en redundantie 41.4 Klassieke en moderne wijze van gegevensopslag 61.5 Samenvatting 10

2 Relationele databases 132.1 Databasemanagementsysteem 132.2 Relationele databases 162.3 Samenvatting 21

3 Normaliseren, inleiding 233.1 Stap 1, de nulde normaalvorm 233.2 Stap 2, de eerste normaalvorm 283.3 Stap 3, de tweede normaalvorm 313.4 Stap 4, de derde normaalvorm 333.5 Entiteit Relatie Diagram (ERD) 363.6 Samenvatting 40

4 Normaliseren, verdieping 474.1 Dubbele (geneste) repeterende groepen 474.2 Dubbele (opeenvolgende) repeterende groepen 524.3 Opmerkingen met betrekking tot normaliseren 564.4 Integreren 574.5 Datadictionary 604.6 Samenvatting 62

5 Eenvoudige bewerkingen in Access 695.1 Inleiding 695.2 Het programma Access starten 705.3 De database en de tabel creren 715.4 Een bestaande database openen 775.5 Records manipuleren 80

Databaseontw ikke l ing 4 (Access 2003)viii

5.6 De bestandsweergave wijzigen 855.7 Afdrukken van gegevens 885.8 Met meerdere tabellen tegelijkertijd werken 905.9 Gegevens selecteren en manipuleren 1005.10 Rapporten 1245.11 Formulieren 1355.12 Webpaginas 140

6 Uitgebreide formulieren 1456.1 Keuzemogelijkheden 1456.2 Afbeeldingen OLE-objecten 1516.3 Keuzelijsten 1566.4 Hoofd- en subformulieren 1656.5 Tabbladen 1746.6 Opdrachtknoppen 1806.7 Draaitabellen/Draaigraeken 1856.8 Webpaginas 198

7 Uitgebreide rapporten 2117.1 Rapport zonder duplicaten 2117.2 Rapport met groepen 2167.3 Rapport met meerdere groepen 236

8 Macros 2478.1 Een eenvoudige macro 2488.2 Geavanceerde macros 253

9 Het bouwen van een toepassing 2719.1 Tabellen en relaties 2729.2 Menustructuur 2759.3 De formulieren 2779.4 De rapporten 3049.5 Schakelborden 328

10 SQL, Structured Query Language 34110.1 Inleiding 34110.2 Begrippen 34210.3 Opbouw hoofdstuk 343

I nhoud ix

10.4 Database Bibliotheek (theorieopdrachten) 34410.5 Database Alco (praktijkopdrachten) 34510.6 Opvragingen uit n tabel 34510.7 SQL gebruiken in Access 35110.8 Eenvoudige opvragingen uit meerdere tabellen 35510.9 Wijzigen van de volgorde 35910.10 Rekenkundige bewerkingen 36110.11 Groeperen 36410.12 Subquerys 37010.13 Speciale joins en views 38010.14 SQL, meer mogelijkheden 384

Appendix A Veldeigenschappen 387

Appendix B Opties 403

Appendix C Een grote, uitgewerkteopdracht 413

Index 433

Inleiding

Datases zijn in het dagelijkse leven niet meer weg te denken. Van een afgestudeerde op MBO-niveau mag worden verwacht dat hij/zij kennis van en inzicht in databases heeft. Naast de theoretische kennis dienen er ook praktische vaardigheden aanwezig te zijn.

Dit boek beoogt de kennis van en vaardigheden met databases aan te reiken. Dat gebeurt door stapsgewijs in te gaan op het totale pro-ces van het (op papier) ontwerpen van een database tot het gebruik van de database (in Microsoft Access) om de benodigde informatie te genereren.

Allereerst zal het ontwerpen van databases ter sprake komen. Hierbij wordt de techniek van het normaliseren gehanteerd. Uitgaande van een informatiebehoefte zal via het normalisatie-proces de informatiestructuur bepaald worden. Deze structuur wordt vervolgens grasch weergegeven door middel van een Entiteit Relatie Diagram. Hierbij geldt dat hoofdstuk 3 de basis legt en hoofdstuk 4 een verdieping aanbrengt. Hierna wordt besproken hoe een gevonden gegevensstructuur kan worden omgezet in een database, gebruikmakend van het programma Access. De database wordt gebouwd, gevuld en ten slotte gebruikt voor het opvragen van informatie.

De volgende stap die wordt gezet, is die waarbij de wijze van gege-vens opvragen steeds meer geautomatiseerd zal worden. Er zullen formulieren, rapporten en macros worden ontworpen en gebruikt.

Databaseontwikkeling 4 Access 2003xii

De ontworpen rapporten, formulieren en macros worden vervol-gens gebruikt bij het opzetten van een applicatie. Bij het opzetten van de applicatie zal niet worden geprogrammeerd in de zin van het ouderwetse coderen. De applicatie wordt gebouwd door op grasche wijze bouwstenen te selecteren, deze iets aan te passen en vervolgens samen te voegen tot professioneel ogende applica-ties.

Omdat databases algemeen toepasbaar zijn, wordt het boek af-gesloten met een hoofdstuk waarin de standaard vraagtaal SQL wordt behandeld. Deze taal wordt niet alleen door Access onder-steund, maar door vrijwel ieder databasemanagementpakket dat op de markt te verkrijgen is. Enige kennis van deze taal is dus onont-beerlijk.

1 Gegevens en betrouwbaarheid

In dit hoofdstuk wordt aan de hand van voorbeelden de historie van klassieke gegevensopslag in computersystemen besproken. In de begintijd van de automatisering werd veelal per afdeling geauto-matiseerd, eerst de afdeling Boekhouding, dan de Inkoopafdeling, vervolgens de afdeling Verkoop en ten slotte het Voorraadbeheer. Dit wordt eilandautomatisering genoemd. Die verschillende eiland-jes kunnen niet of slecht gegevens met elkaar uitwisselen. Hierdoor worden er bijvoorbeeld 30 scooters aan een winkel verkocht die helemaal niet in het magazijn staan. Het informatiesysteem wordt dan onbetrouwbaar genoemd. Hiervoor is uiteraard een oplossing gevonden, de database. De ontwikkeling van eilandautomatisering naar database wordt in dit hoofdstuk toegelicht. Verder worden belangrijke begrippen zoals integriteit, consistentie, redundantie en betrouwbaarheid toegelicht.

1.1 Gegevens en informatie

Computers zijn niet meer weg te denken uit onze maatschappij. Ze nemen een steeds belangrijker plaats in. Wij kunnen onder andere met de computer spelletjes spelen, e-mailen, internet-ten, werkstukken maken met behulp van een tekstverwerker of multimediapresentaties maken. Bedrijven en instellingen kunnen niet meer functioneren zonder computers. Alle gegevens voor de bedrijfsvoering worden opgeslagen in de computer. Denk hierbij aan klantgegevens, artikelgegevens, leveranciergegevens, produc-tiegegevens. Van onszelf liggen ook bij vele instanties gegevens opgeslagen. Van iedere volwassen inwoner van Nederland liggen de persoonsgegevens in honderden computersystemen opgesla-

Databaseontwikkeling 4 Access 20032

gen. Denk hierbij aan de banken, verzekeringsmaatschappijen, belastingdienst, gemeentelijke instellingen, sportverenigingen, motorrijtuigadministratie, school, krantadministratie, salarisadmi-nistratie, enzovoort.

De begrippen gegevens en informatie worden nogal eens door elkaar gehaald. Gegevens zijn feiten of gebeurtenissen die op een bepaalde manier zijn vastgelegd. Bijvoorbeeld adresgegevens op papier, maar ook het vastleggen van diezelfde gegevens op magne-tisch materiaal zodat de computer ze kan lezen, valt onder deze denitie, net als fotos, geluid of beelden. Informatie is de beteke-nis die aan die gegevens ontleend kan worden. Een telefoonboek staat vol met gegevens. De gegevens daarin worden informatie als we het telefoonnummer van iemand willen opzoeken. Het gevon-den telefoonnummer betekent iets voor ons. In dezelfde gegevens kunnen verschillende soorten informatie zitten. Na een repetitie-week worden per klas alle behaalde cijfers van de leerlingen op een lijst weergegeven. Voor de leerling zijn de behaalde cijfers infor-matie. Voor een docent Engels zijn in hetzelfde overzicht de cijfers die voor het vak Engels zijn behaald informatie.

1.2 Integriteit

Gegevens in computersystemen moeten zo opgeslagen worden dat ze eenvoudig zijn op te vragen en dat ze eenvoudig gemuteerd kunnen worden. Onder muteren verstaan we het toevoegen, wij-zigen of verwijderen van gegevens. Tevens mogen die gegevens geen onjuistheden of onduidelijkheden bevatten. We noemen dit de integriteit van het computersysteem. Hiermee bedoelen we dat de gegevens in het computersysteem een juiste weergave moeten zijn van de werkelijkheid. Het cijfer zeven voor een repetitie wiskunde moet ook op de computeruitdraai van de cijferlijst een zeven zijn en niet een vier. Als de computer toont dat het banksaldo 120 euro in het rood is, terwijl het in het zwart moet zijn, is er duidelijk iets mis. Het computersysteem geeft dan niet de werkelijkheid weer, de integriteit van het computersysteem voldoet niet, het is een onbe-trouwbaar informatiesysteem. Dit lijkt misschien allemaal logisch, maar dat is in vele praktijkgevallen nog niet het geval. Met twee voorbeelden zullen we dit duidelijk maken.

gegevens

informatie

muteren

integriteit

1 Gegevens en betrouwbaarheid 3

Na een verhuizing ontvangen mensen nogal eens onduidelijke brie-ven zoals in de volgende brief:

Er is met deze brief iets merkwaardigs aan de hand. Het adres in Capelle aan den IJssel (links bovenin) is het nieuwe en correcte adres. Op diezelfde brief staat ook het oude adres in Ridderkerk. Volgens de basketbalvereniging is dat ook het nieuwe adres. De persoonsgegevens staan dus ten minste twee keer opgeslagen in hun computersysteem, waarbij de adreswijziging maar n keer is doorgevoerd. De gegevens zijn dus op een onjuiste manier op-geslagen. Mevrouw Den Hoed zal ongetwijfeld weten waar zij nu woont, maar de basketbalvereniging heeft nu twee tegenstrijdige adressen geregistreerd en weet het niet meer.

Een ander voorbeeld: bij een verhuizing naar een koopwoning wordt vaak ook een nieuwe hypotheek afgesloten. Vanwege het nancile risico is het gebruikelijk om naast de hypotheek ook een levensverzekering af te sluiten. Zo ook in dit voorbeeld. Naast de hypotheek zijn bij dezelfde maatschappij twee levensverzekeringen afgesloten, voor elke partner een. Na ontvangst van de sleutel van het nieuwe huis is een adreswijziging naar de verzekeringsmaat-schappij gestuurd. Tot zover geen problemen, maar in de maand januari kwamen er geen overzichten van de levensverzekeringen. Bij navraag naar het uitblijven van deze overzichten werd aan de telefoon gevraagd om de postcode en het huisnummer. Deze bleken

Basketbalvereniging DunkyPostbus 20503070 AB Rotterdam

M.C. den HoedLeiweg 122907 TV Capelle a/d IJsselGeachte mevrouw Den Hoed,Hierbij ontvangt u uw nieuwe teamgegevens en het trainingschema voor hetkomende basketbalseizoen. Hieronder staan de gegevens zoals deze in onscomputersysteem liggen opgeslagen.M.C. den HoedLarenstraat 262984 EK Ridderkerk

Team: dames 1Training: maandag van 19.00-20.30, woensdag van 19.30-21.00

Indien er onvolledige of onjuiste gegevens zijn vermeld, kunt u telefonisch con-tact opnemen met de heer Verkerk (010 4830554).


echter niet in het systeem van de verzekeringsmaatschappij voor te komen. Toch is er meermalen post op het nieuwe adres ontvangen. Bij verder speurwerk bleek dat de levensverzekeringsoverzichten naar het oude adres gestuurd waren, omdat dat nog steeds in de administratie als juist vermeld stond. Blijkbaar was de adreswijzi-ging wel aangebracht bij de afdeling Hypotheken maar niet in de levensverzekeringadministratie. Na deze constatering en de aan-passing bij de levensverzekeringsmaatschappij kwamen al snel de gegevens van de levensverzekering. De adresgegevens waren dus in twee verschillende computersystemen opgeslagen.

1.3 Consistentie en redundantie

De gegevens zouden opgeslagen kunnen zijn zoals in guur 1.1. In computertermen noemen we dit bestanden of tabellen.

Figuur 1.1 Levensverzekering

Polis- Naam Adres Postcode Plaats Polisbedrag Premienummer

6798316 R. Ederzeel Hoofdweg 67 1067 RT Amsterdam 191.000,00 62,50

6798317 T. de Vries Steenstraat 34 1380 VB Weesp 161.000,00 40,50

6798318 E. van der Nieuwendam 67 1621 AP Hoorn 145.000,00 124,80Wouden

6798319 E.R. Spruyt Ringweg 56 1200 GH Hilversum 127.000,00 113,90

6798320 B.J. Larenstraat 26 2984 EK Ridderkerk 168.000,00 48,50Groenendijk

.

Hypotheek

Hypo- Naam Adres Postcode Plaats Hypotheek Rentenummer Bedrag Perc.

33-812347 R. van Dam Loefweg 56 3965 JJ Houten 113.500,00 6,1

33-812348 T. de Vries Steenstraat 34 1380 VB Weesp 191.000,00 5,9

33-812349 R. Ederzeel Hoofdweg 67 1067 RT Amsterdam 113.500,00 5,8

33-812350 B.J. Leiweg 12 2907 TV Capelle a/d 127.000,00 6,0Groenendijk IJssel

33-812351 E. van der Nieuwendam 67 1621 AP Hoorn 181.500,00 5,9Wouden


.


Merk op dat niet iedereen die een hypotheek afsluit ook voorkomt bij de levensverzekeringen. Men kan namelijk zon verzeker-ing al bij een andere maatschappij hebben. Daarnaast kan een levensverzekering afgesloten worden zonder een hypotheek. De gegevens kunnen dus in die beide systemen in een andere volgorde voorkomen.

Als een hypotheek gelijktijdig met een levensverzekering wordt afgesloten, komen in beide bestanden nieuwe vermeldingen. De adresgegevens worden dan twee keer opgeslagen. Hierdoor kunnen er problemen ontstaan, zoals in het voorbeeld van guur 1.1 bij B.J. Groenendijk. Maar ook bij R. van Dam kunnen er problemen ontstaan. R. van Dam heeft namelijk nog een vakantiewoning waarop ook een hypotheek is afgesloten.

In deze voorbeelden zijn de gegevens in tegenspraak met elkaar. Groenendijk woont volgens de computer in Ridderkerk n in Capelle a/d IJssel. Met een moeilijk woord zeggen we dat de gege-vens inconsistent (onbetrouwbaar) zijn. Het is dus niet zo gemak-kelijk om gegevens in een computersysteem op te slaan en ervoor te zorgen dat de gegevens consistent blijven. We moeten er dan voor zorgen dat dezelfde gegevens niet meerdere keren opgeslagen worden. Het meerdere keren opslaan van gegevens noemt men redundantie. Redundantie betekent overtolligheid. Het is helemaal niet nodig om gegevens meerdere keren in de computer op te slaan, n keer is voldoende.

Toch komt het meervoudig opslaan van gegevens vaak voor. In een recent onderzoek bij een niet nader te noemen grote gemeente bleken persoonsgegevens in 37 verschillende computerbestanden opgeslagen te zijn! Hoe kan zoiets ontstaan met onze moderne computers? Of liever, hoe komen we ervan af? Daarvoor moeten we een aantal jaren in de historie teruggaan.

De levensverzekeringmaatschappij ging automatiseren. Hiervoor werd een computerprogramma (applicatie) gemaakt waarmee de gegevens ingevoerd, opgeslagen en afgedrukt konden worden. Later ging die levensverzekeringmaatschappij ook hypotheken ver-strekken. Hiervoor werd ook een applicatie gemaakt waarmee men de afgesloten hypotheken kon registreren. Bij het verkopen van de hypotheken bemerkte men dat de klanten ook graag een inboe-

inconsistent

redundantie


delverzekering en opstalverzekering (verzekeringen tegen brand, waterschade, enzovoort) wilden afsluiten. Die gingen ze dus ook verkopen en er moesten opnieuw twee applicaties gemaakt worden voor de verkoop van die verzekeringen. Hierdoor is de situatie zoals afgebeeld in guur 1.2 ontstaan. De rechthoeken stellen de computerprogrammas voor en de cilinders de bestanden (tabellen) met de gegevens.

De gegevens worden in vier verschillende computersystemen opgeslagen. Dit noemen we ook wel eilandautomatisering. Iedere afdeling werkt op zijn eigen eilandje. Hierdoor worden gegevens meerdere keren opgeslagen. Niet alleen de adresgegevens. Een hypotheek moet een onderpand hebben en hiervoor is onder andere de waarde en het bouwjaar van de woning noodzakelijk. Maar de waarde en het bouwjaar van de woning is ook nodig voor de opstalverzekering. Om aan de nadelen hiervan tegemoet te komen is een oplossing bedacht. De vier applicaties die ze gebruiken, zijn verbeterd door de gezamenlijke gegevens apart op te slaan. Hierdoor kunnen de verschillende afdelingen gebruikmaken van n klantenbestand en n woningbestand, zie guur 1.3.

Gegevens worden nu dus niet meer dubbel opgeslagen (geen redun-dantie) en inconsistentie (onbetrouwbaarheid) wordt voorkomen.

1.4 Klassieke en moderne wijze van gegevensopslag

Dit lijkt een mooie oplossing, maar er ontstaan nieuwe problemen. Laten we als voorbeeld het klantenbestand nemen. Hierin liggen de klantgegevens opgeslagen. De klantgegevens die opgeslagen liggen zijn klantnummer, naam, adres, postcode en plaats. Van

Figuur 1.2Hypotheek

Hypotheek

Levens-verzekering

Inboedel-verzekering

Opstal-verzekering

Levens-verzekering


Opstal-verzekering


iedere klant worden die vijf gegevens opgeslagen, dit wordt de gegevensstructuur van het klantenbestand genoemd. Stel dat de afdeling Levensverzekeringen ook graag de geboortedatum van een klant wenst op te slaan. De gegevensstructuur van het klanten-bestand moet hiervoor aangepast worden. Er moet een zesde item (geboortedatum) aan toegevoegd worden. Het klantenbestand moet hiervoor geconverteerd worden. Converteren is de oude gegevens-structuur omzetten naar de nieuwe gegevensstructuur: klantnum-mer, naam, adres, postcode, plaats en geboortedatum. De klant-gegevens liggen als een kralenketting opgeslagen. Bijvoorbeeld 10001, T. de Vries, Steenstraat 34, 1380 VB, Weesp, 10002, R. Ederzeel, Hoofdweg 67, 1067 RT, Amsterdam, 10003, B.J. Groenendijk, enzovoort. Aangezien nu ook de geboortedatum erbij moet, worden de eerste vijf gegevens (kraal klantnummer t/m kraal plaats) van het oude klantenbestand gelezen en deze worden op de nieuwe ketting geregen (geschreven). Vervolgens wordt een nieuwe kraal geboortedatum aan de nieuwe ketting toegevoegd. Vervolgens worden de volgende vijf gegevens van het oude klant-bestand gelezen en naar het nieuwe klantenbestand geschreven.

Figuur 1.3

converteren

Hypotheek

Klant

Levens-verzekering


Opstal-verzekering

Woning

Hypotheek Levens-verzekering


Opstal-verzekering


Vervolgens wordt de geboortedatum van die klant aan het nieuwe bestand toegevoegd. Dit proces gaat net zo lang door tot alle klan-tengegevens geconverteerd zijn.

Het klantenbestand is nu geconverteerd zodat klantnummer, naam, adres, postcode, plaats en geboortedatum van een klant bekend zijn. Het computerprogramma van de afdeling Levensverzekering moet nog aangepast worden aan de nieuwe situatie. De geboor-tedatum was in het oude computerprogramma niet aanwezig en moet dus worden toegevoegd, zodat deze onder andere ingevoerd en afgedrukt kan worden. Nadat het computerprogramma van de afdeling Levensverzekering is aangepast, verloopt voor de afdeling Levensverzekering alles naar wens. Er werd zelfs een klein feestje georganiseerd. Op het moment dat er feest werd gevierd op de af-deling Levensverzekeringen sloegen schijnbaar de computers van de andere afdelingen op hol. Wat is daar namelijk aan de hand? De applicaties van de overige afdelingen waren niet aangepast, ze zijn immers niet in de geboortedatum genteresseerd. Maar ze maken nu wel gebruik van de nieuwe gegevensstructuur, dus inclusief de geboortedatum. Het computerprogramma van bijvoorbeeld de afdeling Hypotheken werkt nog steeds met klantnummer, naam, adres, postcode en plaats. Als nu de klantgegevens van klantnum-mer 10003 opgeroepen moet worden, weet de computer dat het de derde klant is (aangenomen dat 10001 het laagste klantnummer is). Het computerprogramma werkt volgens het principe van de kralenketting. De derde klant betekent, sla twee keer vijf kra-len (klantnummer, naam, adres, postcode en plaats) over en lees vervolgens kraal elf (klantnummer) tot en met kraal vijftien (plaats). Echter, door de nieuwe structuur van het klantenbestand is de elfde kraal nu de plaats van een klant en de twaalfde kraal geen naam, maar de geboortedatum. Hierdoor verschijnt op het


beeldscherm van de afdeling Hypotheken volslagen onzin en denkt men dat de computer op hol is geslagen.

Na enig onderzoek komt men tot de ontdekking dat men de appli-caties van de andere afdelingen ook moet aanpassen aan de nieuwe gegevensstructuur van het klantenbestand, ook al zijn ze niet ge-interesseerd in de geboortedatum van een klant. In plaats van vijf gegevens (klantnummer tot en met plaats) moeten in de nieuwe situatie zes gegevens (klantnummer tot en met geboortedatum) per klant verwerkt worden. Als een afdeling meer gegevens van een klant nodig heeft, vergt dat grote aanpassingen aan de compu-terprogrammas voor alle andere afdelingen die van het klanten-bestand gebruikmaken, ook al zijn ze in die nieuwe gegevens niet genteresseerd.

De moderne manier van gegevensopslag voorziet in een oplos-sing van het hiervoor genoemde probleem. Die moderne manier van gegevensopslag noemen we een database (gegevensbank).De oude manier van gegevensopslag noemen we sindsdien klas-sieke bestandsorganisatie. Er zijn nog veel bedrijven en instellin-gen die gebruikmaken van die klassieke gegevensopslag. Het zijn veelal bedrijven die in een vroeg stadium zijn gaan automatiseren, zoals banken, nancile instellingen, belastingdienst en olie-maatschappijen. Dit wordt de wet van de remmende voorsprong genoemd. Het millenniumprobleem kwam voor een groot deel op rekening van die systemen. En daar werden wereldwijd miljarden euros aan besteed. Het wil overigens niet zeggen dat die systemen slecht zijn, ze voldoen uitstekend. Ze zijn echter kostbaar in het onderhoud. Denk hierbij aan een enkele wijziging in de gegevens-structuur. Maar ook bij moderne systemen kunnen problemen ontstaan als bijvoorbeeld twee bedrijven fuseren. Ook al hebben

database


ze beide een modern computersysteem voor de gegevensopslag, na de fusie hebben ze twee moderne systemen waarin klantgegevens opnieuw dubbel opgeslagen kunnen liggen. Die twee systemen moeten dan samengevoegd (gentegreerd) worden tot n nieuw gentegreerd computersysteem. Daar zijn hoge kosten aan verbon-den.

In het volgende hoofdstuk zullen we het begrip database toelichten en in het bijzonder de relationele database.

1.5 Samenvatting

In dit eerste hoofdstuk hebben we besproken wat het verschil is tussen gegevens (feiten) en informatie (betekenis van die ge-gevens). Bij eilandautomatisering (klassieke bestandsorganisatie)worden dezelfde gegevens meerdere keren opgeslagen (redun-dantie). Hierdoor moeten wijzigingen in die gegevens meerdere keren doorgevoerd worden. Wordt dit niet consequent gedaan, dan ontstaan er tegenstrijdigheden in het informatiesysteem (inconsis-tentie). Om die problemen op te lossen zijn databases ontworpen. Hierin kunnen de gegevens voor alle bedrijfsprocessen eenduidig worden opgeslagen en gewijzigd. De mate van juistheid van de in-formatie die het informatiesysteem produceert, wordt de integriteitvan het informatiesysteem genoemd.

Opgaven

1. Waarom is in de klassieke bestandsorganisatie de kans op inconsis-tentie (onbetrouwbaarheid) erg groot?

2. Wat wordt verstaan onder redundantie (overtolligheid)?

3. Wat wordt verstaan onder de integriteit van het computersysteem?

4. Converteren van computergegevens, wat bedoelt men daarmee?

5. Waarom zijn computersystemen die gebruikmaken van de klas-sieke bestandsorganisatie kostbaar in het onderhoud?

1 Gegevens en betrouwbaarheid 111 Gegevens en betrouwbaarheid 11

6. Bij voetbalvereniging HGS wordt de nancile administratie ver-zorgd door de penningmeester, de heer Van Vliet. De ledenadmi-nistratie wordt verzorgd door de heer Rietman. Hiervoor gebruiken ze beiden hun priv-computer. In de ledenadministratie worden de adresgegevens en elftalgegevens vastgelegd. De penningmeester registreert op de computer de adresgegevens en de maandelijkse betalingen.a. Welke gegevens zijn redundant opgeslagen?b. Geef twee voorbeelden waarbij inconsistentie kan ontstaan.c. Welke afspraken moet de penningmeester maken met de leden-

administrateur om de gegevens betrouwbaar te houden?

7. Veel grote ondernemingen maken nog gebruik van de klassieke bestandsorganisatie. Waarom is dat?

8. De afdeling Levensverzekering van de hypotheekmaatschappij wenst voor vrouwen een korting toe te kennen op de maandelijkse premie. Vrouwen blijken langer te leven dan mannen, waardoor een korting op de premie mogelijk is. In de klantgegevens moet hiervoor een nieuw item Geslacht worden toegevoegd, waarin men Man of Vrouw kan invullen. Wat heeft dat voor gevolgen voor de automatiseringsafdeling van de afdeling Levensverzekering en voor de overige afdelingen die van het klantenbestand gebruik-maken?

2 Relationele databases

In dit hoofdstuk wordt uitgelegd wat een databasemanagement-systeem is. Ook wordt toegelicht wat een datamodel en een relati-onele database is, en verklaren we enkele begrippen uit de gege-vensanalyse.

2.1 Databasemanagementsysteem

Een moderne manier van gegevensopslag in een computersysteem is een database. Hierin zijn de problemen bij gegevensopslag zoals in hoofdstuk 1 beschreven, opgelost. Gezamenlijke gegevens wor-den voor de verschillende afdelingen niet meer dubbel opgeslagen, waardoor redundantie (overtolligheid) en inconsistentie (tegenstrij-digheid) van gegevens wordt voorkomen. Bij een database hoort een databasemanagementsysteem, afgekort DBMS. Zon DBMS is afbeeld in guur 2.1. Dit systeem vormt een sluis tussen diverse computerprogrammas en de gegevensbestanden. Het DBMS regelt

DBMS

Figuur 2.1Hypotheek Levens-

verzekeringInboedel-verzekering

Opstal-verzekering

WoningHypotheek Levens-verzekering


Opstal-verzekering

DBMS

Klant


de toevoegingen en wijzigingen in de database en zorgt er dus voor dat er geen redundantie en inconsistentie kan optreden.

In het databasemanagementsysteem worden de volledige gegevensstructuren van alle benodigde bestanden vastgelegd. Zo wordt daar de gegevensstructuur voor het klantenbestand vast-gelegd, klantnummer, naam, adres, postcode, plaats en geboor-tedatum. Dit is de verzameling gegevens die de vier afdelingen nodig hebben voor de klantgegevens. Het wil niet zeggen dat een afdeling alle gegevens nodig heeft, maar de gegevens die ze nodig hebben, zitten er wel bij. Zo wordt voor alle bestanden de volledige gegevensstructuur vastgelegd. Dit noemen we het volledige data-model van de database. Het ontwerpen van het datamodel wordt in hoofdstuk 3 en hoofdstuk 4 uitgelegd. Het datamodel dat op papier is ontworpen, wordt ook wel conceptueel of functioneel datamodelgenoemd.

Nadat alle volledige gegevensstructuren zijn vastgelegd, wordt vervolgens per afdeling vastgelegd welke gegevens zij nodig heb-ben uit de verschillende bestanden. Zo wordt voor de afdeling Hypotheken vastgelegd dat zij van het klantenbestand alleen klant-nummer, naam, adres, postcode en plaats kunnen oproepen. De geboortedatum hebben zij niet nodig. De geboortedatum wordt als het ware verborgen voor de afdeling Hypotheken. Net zoals in een spreadsheetprogramma kolommen verborgen kunnen wor-den. Mocht iemand van de klantenadministratie van de afdeling Hypotheken een overzicht wensen van alle bekende klantengege-vens, dan krijgt deze van alle klanten alleen klantnummer, naam, adres, postcode en plaats te zien. Ondanks dat die persoon alle gegevens heeft opgevraagd, krijgt deze de geboortedatums van de klanten niet te zien. Voor de afdeling Hypotheken zijn dat immers geen relevante gegevens. De afdeling Hypotheken ziet als het ware van het klantenbestand alleen klantnummer, naam, adres, postcode en plaats. Zo wordt voor iedere afdeling vastgelegd welke gegevens ze uit welke gegevensbestanden mogen zien. Men noemt dit de view op de database, zoals men tegen de database aankijkt. De volledige structuur van de database is alleen bij het DBMS bekend. Diegene die het DBMS beheert, noemt men de database-admini-strator. De database-administrator legt de volledige structuur vast en per afdeling de view op de database. Ook kan de database-administrator de view per afdeling wijzigen, vergroten of ver-kleinen.

conceptueel of functioneel

view

database-administrator

2 Relationele database 15

Als nu de gegevensstructuur van een bestand aangepast moet wor-den, wordt dat doorgegeven aan de database-administrator. Stel dat de afdeling Inboedelverzekeringen het telefoonnummer van een klant wenst, dan wijzigt de database-administrator de gegevens-structuur van het klantenbestand door het telefoonnummer toe te voegen. Nadat de database-administrator dat heeft gedaan, zal het DBMS vragen om een bevestiging. Hierna wordt door het DBMS de conversie van de gegevens die liggen opgeslagen automatisch uitgevoerd (omzetten van de gegevens naar de nieuwe structuur, zoals is uitgelegd in hoofdstuk 1). De computerprogrammas van bijvoorbeeld de afdeling Hypotheken ondervinden hier geen enke-le hinder van. Het enige dat zij zien van het klantenbestand is klantnummer, naam, adres, postcode en plaats. Al zouden er nog tien andere items van klanten zijn vastgelegd, zij weten dat niet, waarom zouden ze het ook moeten weten?

We hebben al gezegd dat de view op de database wordt vastge-legd per afdeling. Het kan zelfs verder gaan. We kunnen zelfs per persoon aangeven wat zijn view op de database is. Veel gegevens zijn privacygevoelig, vertrouwelijke bedrijfsgegevens of volkomen nutteloos op deze werkplek. Eigenlijk hoort een medewerker alleen de beschikking te krijgen over voor hem relevante gegevens. De medewerker heeft een autorisatie voor deze gegevens, oftewel toe-stemming om deze gegevens te gebruiken. Zo kan bijvoorbeeld al-leen de personeelsfunctionaris het salaris van een werknemer zien en de andere personen die gebruikmaken van de werknemergege-vens niet. Vertegenwoordigers die in rayons werken, bijvoorbeeld provincies, zien alleen de klantgegevens uit hun rayon. Een over-zicht van alle klanten levert dan bijvoorbeeld alleen maar klanten uit de provincie Utrecht.

Met autorisatie kunnen we ook vastleggen dat een gebruiker de gegevens alleen mag raadplegen. Het toevoegen, wijzigen of ver-wijderen van gegevens is dan niet toegestaan. Natuurlijk zijn alle variaties hierop mogelijk, zoals wel toevoegen van nieuwe gege-vens maar niet het verwijderen van gegevens.

Het DBMS kan nog meer taken uitvoeren, zoals back-ups ma-ken en de database over meerdere computers verspreiden als dat noodzakelijk is, bijvoorbeeld bij grote ondernemingen. Het DBMS zorgt er ook voor dat twee personen niet tegelijkertijd hetzelfde

autorisatie


gegeven kunnen wijzigen. Dit wordt record-locking genoemd. We zullen dit toelichten met een voorbeeld. Het bedrijf Sunparks ver-huurt vakantiehuisjes in Nederland en Belgi. Die vakantiehuisjes moeten geboekt worden door Sunparks te bellen. Er zijn meerdere personen die de reserveringen boeken. De beide verkopers krijgen tegelijkertijd een familie (Jansen en Maertens) aan de lijn, die in dezelfde week twee huisjes willen huren. De twee verkopers toetsen de gewenste vakantieweek in en zien nu beiden op het beeldscherm van hun computer dat er in die week nog precies twee huisjes vrij zijn. Tegen de familie Jansen wordt door de ene verkoper gezegd dat er in die week nog precies twee vakantiehuis-jes zijn. De andere verkoper vertelt mevrouw Maertens hetzelfde: er zijn in die week nog precies twee vakantiehuisjes. Er zijn nu vier vakantiewoningen geboekt, terwijl er maar twee vakantie-huisjes in die periode vrij waren. Hierdoor zouden de gegevens in de database niet meer kloppen met de werkelijkheid (integriteit). Uiteraard helpt het DBMS ons met dit probleem. De verkoper die als eerste de gegevens van de vrije vakantiehuisjes via de compu-ter oproept, blokkeert tegelijkertijd die gegevens: record-locking. Iedere andere verkoper kan die gegevens nog wel oproepen, maar niet meer wijzigen. Op het beeldscherm verschijnt dan een extra melding waarin staat dat de gegevens door een andere verkoper zijn geblokkeerd. Nadat deze de boeking heeft afgesloten, wordt de blokkering opgeheven en wordt het beeldscherm van de andere verkoper aangepast aan de nieuwe gegevens (refresh). Die ziet de twee vrije vakantiehuisjes veranderen in nul vrije vakantiehuisjes.

2.2 Relationele databases

Historisch gezien zijn er drie typen databases: eerst kwam de hirarchische database, toen de netwerkdatabase en ten slotte de relationele database. De verschillen in deze databases zit in de manier waarop de gegevens worden opgeslagen om redundantie en daardoor inconsistentie te voorkomen. De moderne databases zijn relationele databases. We zullen de werking van de relatio-nele databases aan de hand van een voorbeeld toelichten. Op de afdeling Hypotheek zijn de hypotheekgegevens nog volgens de klassieke opslagmethode opgeslagen, zie guur 2.2. Bij de afde-ling Levensverzekeringen zijn weer andere gegevens gewenst, zie guur 2.3, ook op de klassieke manier opgeslagen.

record-locking


Hierin is duidelijk de redundantie en inconsistentie te zien. Klantgegevens liggen op de verschillende afdelingen dubbel op-geslagen, waardoor inconsistentie kan optreden. Bijvoorbeeld B.J. Groenendijk woont bij de afdeling Levensverzekering in Ridderkerk, terwijl dat Capelle a/d IJssel moet zijn. Ook binnen n afdeling kan redundantie optreden. De klant R. van Dam heeft twee hypotheken, zijn woning en vakantiewoning.

Bij relationele databases wordt redundantie en daardoor incon-sistentie als volgt opgelost. Men slaat de klantgegevens van alle afdelingen apart op en geeft aan iedere klant een uniek klantnum-mer. De gegevens van iedere klant worden slechts n keer opge-slagen. De hypotheekgegevens en polisgegevens van de klanten worden daarna via het klantnummer gekoppeld (gerelateerd) aan de klantgegevens, zie guur 2.4.

Hypotheek

Hypo- Naam Adres Postcode Plaats Hypotheek Rentenummer Bedrag Perc.


33-812348 T. de Vries Steenstraat 34 1380 VB Weesp 191.000,00 5,9

33-812349 R. Ederzeel Hoofdweg 67 1067 RT Amsterdam 113.500,00 5,8

33-812350 B.J. Leiweg 12 2907 TV Capelle a/d 127.000,00 6,0Groenendijk IJssel

33-812351 E. van der Nieuwendam 67 1621 AP Hoorn 181.500,00 5,9Wouden


.

Figuur 2.2

Figuur 2.3 Levensverzekering

Polis- Naam Adres Postcode Plaats Polisbedrag Premienummer

6798317 T. de Vries Steenstraat 34 1380 VB Weesp 161.000,00 140,50

6798318 E. van der Nieuwendam 67 1621 AP Hoorn 145.000,00 124,80Wouden

6798319 E.R. Spruyt Ringweg 56 1200 GH Hilversum 127.000,00 113,90

6798320 B.J. Larenstraat 26 2984 EK Ridderkerk 168.000,00 148,50Groenendijk

.


Er is geen redundantie meer, alle gegevens zijn maar n keer opgeslagen. De relatie tussen de hypotheekgegevens en klant-gegevens verloopt via het klantnummer. Voor de levensverzeke-ringgegevens geldt hetzelfde. Een adreswijziging van een klant wordt in het klantenbestand (tabel Klant) aangebracht. Alle andere afdelingen beschikken nu direct over de juiste adresgegevens. In het DBMS moeten niet alleen de gegevensstructuren vastgelegd worden, maar ook de relaties tussen de verschillende bestanden (tabellen). De relatie tussen de tabel Klant en de tabel Hypotheek

Klant

Klantnr Naam Adres Postcode Plaats

10001 T. de Vries Steenstraat 34 1380 VB Weesp

10002 R. Ederzeel Hoofdweg 67 1067 RT Amsterdam

10003 B.J. Groenendijk Leiweg 12 2907 TV Capelle a/d IJssel

10004 E. van der Wouden Nieuwendam 67 1621 AP Hoorn

10005 E.R. Spruyt Ringweg 56 1200 GH Hilversum

10006 R. van Dam Loefweg 56 3965 JJ Houten

.

Hypotheek

Hyponummer Hypotheek Rente KlantnrBedrag Perc.

33-812347 113.500,00 6,1 10006

33-812348 191.000,00 5,9 10001

33-812349 113.500,00 5,8 10002

33-812350 127.000,00 6,0 10003

33-812351 181.500,00 5,9 10004

33-812352 168.000,00 5,5 10006

.

Levensverzekering

Polisnummer Polisbedrag Premie Klantnr

6798316 191.000,00 162,50 10002

6798317 161.000,00 140,50 10001

6798318 145.000,00 124,80 10004

6798319 127.000,00 113,90 10005

6798320 168.000,00 148,50 10003

.

Figuur 2.4


luidt: het klantnummer uit de tabel Klant is gelijk aan het klant-nummer uit de tabel Hypotheek.

Nu kunnen we ook de denitie van een database geven. Een data-base is een verzameling bij elkaar behorende tabellen inclusief hun onderlinge relaties.

Als nu een hypotheek in de database wordt opgezocht, worden automatisch de bijbehorende klantgegevens, via het klantnummer, in de tabel klant opgezocht, zie guur 2.5.

Maar het kan ook andersom. Als de heer R. van Dam belt voor informatie over zijn hypotheek, worden de gegevens van de heer R. van Dam in de computer opgezocht. Door de relatie met de tabel Hypotheek kunnen die gegevens op het beeldscherm worden getoond, zie guur 2.6.

Tegen de heer Van Dam kan direct gezegd worden: Ik zie dat u twee hypotheken bij ons hebt afgesloten. Wat kan ik voor u doen?

denitie database

Hypotheek


33-812350 127.000,00 6,0 10003

Klant


10003 B.J. Groenendijk Leiweg 12 2907 TV Capelle a/d IJssel

Figuur 2.5

Klant


10006 R. van Dam Loefweg 56 3965 JJ Houten

Hypotheek


33-812347 113.500,00 6,1 10006

33-812352 168.000,00 5,5 10006

Figuur 2.6


Door het klantnummer van Van Dam (nummeridenticatie) wor-den automatisch de bijbehorende klanten hypotheekgegevens gevonden.

Hoe wordt een database ontworpen? Welke tabellen hebben we nodig om de gegevens zonder redundantie en inconsistentie op te slaan? Voordat we een database kunnen ontwerpen, moeten we ons eerst afvragen welke gegevens we nodig hebben. Per werk-plek moet vastgelegd worden welke informatie daar nodig is, de informatiebehoefte. Dat kan een rapport zijn op papier of bepaalde klantgegevens op het beeldscherm. Dat moet per werkplek beke-ken worden. Een inkoper heeft andere informatie nodig dan een verkoper. Een belastingambtenaar die de belastingaangifte van particulieren moet vaststellen, heeft andere informatie nodig dan zijn collega die de belastingaangifte voor bedrijven moet vaststel-len. Uiteraard is het vaststellen van die informatiebehoefte een ingewikkelde klus. Niet alleen moet vastgesteld worden welke gegevens waar opgeslagen worden, maar ook vanuit welke invals-hoeken er gewerkt wordt. Dit proces wordt informatie-analyse ge-noemd. Daarna moeten de informatiebehoeften worden vertaald naar gegevensstructuren, zodat de gegevens zonder redundantie en inconsistentie worden opgeslagen. We noemen dit gegevensana-lyse. We maken daarbij gebruik van een manier die is bedacht door de Amerikaan Edgar Codd. Deze wordt normaliseren genoemd. Zo ontstaat op papier de te maken database, het conceptuele of functionele datamodel. In de volgende twee hoofdstukken wordt het normaliseren uitgelegd. Het ontworpen datamodel wordt hierna gebouwd met behulp van een databasepakket. Dat is software waarin het DBMS aanwezig is, inclusief gereedschappen waarmee we gegevens via formulieren kunnen invoeren, wijzigen, verwijde-ren of overzichten/rapporten kunnen afdrukken.

Er zijn vele databasepakketten te koop. Voor de pcs zijn de be-kendste pakketten Access, FoxPro en Paradox. Het databasepakket Access van Microsoft wordt het meest gebruikt. Vanaf hoofdstuk 5 wordt dit databasepakket uitgelegd. De zware databases die door middelgrote tot zeer grote ondernemingen worden gebruikt, zijn bijvoorbeeld Oracle, Sybase en SQL-Server. SQL-Server is de zware database van Microsoft. De rma Oracle is na Microsoft de grootste softwarefabrikant ter wereld.

Access wordt veel toegepast op pcs waarbij de database lokaal op de harde schijf van de computer wordt opgeslagen. Anderen

informatiebehoefte

informatie-analyse

gegevensanalyse


kunnen die database niet gebruiken als zij geen toegang hebben tot de harde schijf van die computer. De grote databases worden op de hoofdcomputer (server) in het netwerk geplaatst, waardoor honderden personen van de gegevens in de database gebruik kun-nen maken. Vaak is dit een ander databasepakket, zoals Oracle of SQL-server. Omdat Access eenvoudig is in het gebruik, vooral bij het maken van allerlei formulieren en rapporten, wordt Access ook toegepast op pcs (clients) waarbij Access gebruikmaakt van de Oracle-database op de server. Access wordt dan front-end software genoemd en Oracle op de server de back-end. Access wordt dan dus alleen gebruikt voor de in- en uitvoer, niet voor de echte opslag. Dat doet de Oracle-database. Het front-end/back-end-prin-cipe wordt in grotere organisaties voor hun databases veel toege-past. De combinatie van gebruiksgemak aan de front-endkant en degelijkheid aan de back-endkant is dan ook een heel aantrekke-lijke. Helaas vergeten vele gebruikers eerst de informatiebehoefte nauwkeurig te bepalen. Het normaliseren van de gegevens wordt dan niet of slechts intutief uitgevoerd. Al snel na het werken met de database zullen daardoor problemen ontstaan. Deze worden dan met trucs, kunst- en vliegwerk opgelost. Uiteraard ontstaat hierdoor weer redundantie en inconsistentie aangezien de gegevens niet goed geanalyseerd zijn, waardoor het datamodel niet correct is. Men kan het beste Access spelenderwijs leren door gebruik te maken van n of twee tabellen. Maar voor een bedrijfsmatige aanpak dient men eerst de benodigde informatie te verzamelen, te analyseren en vervolgens te normaliseren. Met het dan ontstane conceptuele datamodel kunnen in Access de tabellen en relaties worden gemaakt. Dat wordt ook wel het indelen / inrichten van de database genoemd. Het op een juiste manier leren werken met Access wordt vanaf hoofdstuk 5 uitgelegd.

2.3 Samenvatting

In dit hoofdstuk hebben we besproken dat een relationele data-base een verzameling tabellen is met hun onderlinge relaties. Om de structuur van een database te ontwerpen moet eerst vastgelegd worden wat de informatiebehoefte is. Hierin wordt bepaald wat de gewenste uitvoer van het nieuwe computersysteem is. Die ge-gevens worden geanalyseerd om tot een datamodel te komen. Dit ontworpen datamodel kan vervolgens toegepast worden in een relationele database. Een database beschikt over een database-managementsysteem (DBMS). Hiermee kunnen de tabellen wor-

front-end/

back-end


den gemaakt, de relaties worden gelegd, de tabellen gevuld wor-den, gegevens worden geraadpleegd, gemuteerd, enzovoort. Verder kunnen met behulp van het DBMS rechten worden toegekend en wordt de integriteit van de database bewaakt. De database wordt beheerd door de database-administrator. Er zijn verschillende databasepakketten, zoals Access, Sybase en Oracle. De Access-database is ook te gebruiken aan de gebruikerskant (client) terwijl de gegevens liggen opgeslagen in een grote database, zoals Oracle (server). Access is dan de front-end- en Oracle de back-endkant.

Opgaven

1. Omschrijf in het kort de taak van het DBMS.

2. Wat wordt bedoeld met een conceptueel of functioneel datamodel?

3. De rma Innovision verkoopt computers via vertegenwoordigers. Het is een modern bedrijf, alle gegevens liggen in een relationele database opgeslagen. Per provincie is n vertegenwoordiger actief. Als een vertegenwoordiger een afdruk laat maken van alle klanten uit de database, worden alleen de klanten uit zijn provincie afgedrukt. Hoe noemen we dit principe?

4. Wat wordt verstaan onder autorisatie?

5. Wat is de taak van de database-administrator?

6. Welke drie typen databases onderscheiden we?

7. Wat wordt bedoeld met informatie-analyse?

8. Wat is record-locking?

9. Reisorganisatie TravelCheap heeft n grote database (Oracle) waarin alle reizen en boekingen worden opgeslagen. Bij een groot aantal reisbureaus heeft men Access-software genstalleerd op de lokale pcs, zodat direct reizen geboekt kunnen worden. Die boe-kingen worden door middel van datacommunicatie direct in de Oracle-database verwerkt. De Access-database doet alleen dienst als in- en uitvoermedium. Hoe wordt dit principe genoemd?

3 Normaliseren, inleiding

In dit hoofdstuk laten we aan de hand van een aantal concrete voorbeelden zien hoe we er achter kunnen komen hoe we een database moeten inrichten. Daarbij zullen we steeds uitgaan van de overzichten, informatie, die de gebruiker van de database wenst te zien. Als er meer dan n gebruiker is, of als er meer dan n overzicht moet worden getoond, zullen we daar uiteraard rekening mee houden.

Voor het bepalen van de indeling van de database bestaan verschil-lende technieken. Wij zullen gebruikmaken van de techniek van het normaliseren, zoals die door de Amerikaan Edgar Codd in de jaren zeventig is opgesteld. Normaliseren houdt in dat we in een viertal stappen de gegevens uiteenrafelen en indelen in een beperkt aantal, overzichtelijke tabellen. De stappen die we daarbij zullen uitvoeren, zijn klein van omvang en daardoor goed te begrijpen en toe te passen. Hierbij geldt echter wel: oefening baart kunst. Alleen door veel en goed te oefenen kunnen we de kunst van het normali-seren in onze vingers krijgen.

3.1 Stap 1, de nulde normaalvorm

Uitgangspunt van het normaliseren is steeds de informatiebehoefte van de toekomstige gebruiker van de database. De indeling en inhoud van de tabellen wordt bepaald door de informatie die de gebruiker wenst te zien. Stel dat een gebruiker een database wil met daarin de gegevens van zijn muziekcollectie. Als hij aangeeft genteresseerd te zijn in het jaar van uitbrengen van de cd, dan zul-len we dit jaartal uiteraard moeten opnemen in de database. Als hij aangeeft absoluut niet te willen weten door welke muziekmaat-schappij een cd is uitgegeven, heeft het geen zin om dit gegeven

normaliseren


wel in de database op nemen. Voor een andere opdrachtgever zou het precies andersom kunnen zijn. Die zou juist wel in de naam van de maatschappij, maar weer niet in het jaar van uitbrengen genteresseerd kunnen zijn. Hieruit blijkt dat we niet kunnen pra-ten over een uniek, algemeen geldend ontwerp van een database. We zullen ons altijd moeten baseren op de gewenste overzichten, de informatiebehoefte. Deze behoefte kan van gebruiker tot ge-bruiker verschillen. Het is dus noodzakelijk om tijdens het ont-werpen van een database veel en vaak contact te hebben met de toekomstige gebruiker. Alleen dan kunnen we ervoor zorgen dat de indeling van de database past bij de wensen van de gebruiker.

We zullen de theorie uitleggen aan de hand van een praktijkgeval.Paul, DJ bij de lokale radio, verzorgt driemaal per week een twee uur durend programma waarin hij zijn favoriete muziek laat horen en nieuwe cds onder de aandacht wil brengen. Hij krijgt hiervoor een kleine onkostenvergoeding die hij gebruikt om zijn cd-collec-tie langzaam uit te breiden. Aan het einde van iedere maand moet Paul een overzicht inleveren van alle nummers die hij die maand heeft laten horen. Aan de hand van deze overzichten zorgt de stichting BUMA/STEMRA ervoor dat de betreffende artiesten een kleine vergoeding krijgen.

Paul weet meestal aan het einde van de maand niet meer pre-cies wat hij aan het begin van de maand allemaal heeft gedraaid. Daarom maakt hij het betreffende overzicht (zie guur 3.1) direct na aoop van het programma. Daarop staat vermeld welke num-mers hij heeft gedraaid. Ieder nummer heeft een eigen code. Deze code is bepaald door een van de medewerkers van het lokale ra-diostation. Natuurlijk is van ieder nummer ook bekend wat de titel is en wie de uitvoerende artiest(en) is/zijn. Ten slotte noteert men ook of het nummer van een gewone cd afkomstig is of dat het op een single cd staat. Aan het einde van de maand levert hij dan de stapel met deze dagelijkse overzichten in. Hij is echter al een paar keer zon dagoverzicht kwijtgeraakt, met alle gevolgen van dien. Hij vraagt ons daarom om voor hem een database te ontwerpen waarmee hij aan het einde van de maand het gewenste overzicht kan maken.

Uitgangspunt voor het ontwerp van een database is dus altijd de gewenste informatie. Vaak ligt deze wens vast in de vorm van overzichten die met de database moeten kunnen worden gemaakt, gegenereerd. We zullen daarom bij het normaliseren altijd uitgaan

3 Normaliseren, inleiding 25

van een of meer overzichten en ervoor zorgen dat de daarop aan-wezige informatie kan worden verzorgd. Het door Paul gewenste overzicht is afgebeeld in guur 3.1.

We nemen aan de hand van guur 3.1 de eerste stap om de gege-vens uiteen te rafelen. We krijgen dan de zogenaamde nulde nor-maalvorm. We bepalen de nulde normaalvorm door alle elemen-taire, relevante gegevens te bepalen en op te schrijven.

Op ons overzicht staat een aantal verschillende gegevens.

Allereerst zien we een koptekst boven het overzicht. Deze kop-tekst is op ieder overzicht van Paul hetzelfde (constant), ongeacht de datum en ongeacht de gedraaide nummers. We zouden deze koptekst kunnen voorbedrukken op het papier. Omdat de koptekst onveranderlijk is, nemen we deze niet op in de database. Constante gegevens nemen we nooit op in de database.

TerzijdeWe zien op dit moment de naam DJ Paul als een constante. We kunnen ons echter ook afvragen of dit systeem in de toekomst ook door andere DJs gaat worden gebruikt. In dat geval kunnen we de naam natuurlijk niet als een constante opvatten. Houd daarom bij alle afwegingen die je maakt tijdens het normaliseren altijd rekening met mogelijke wensen en uitbreidingen die in de toekomst een rol kunnen gaan spelen!

Figuur 3.1


Vervolgens zien we een aantal gegevens die iedere keer zullen ver-schillen: de datum en de gegevens van de gedraaide muziek. Deze gegevens moeten we natuurlijk wel opnemen in de database omdat we ze anders kwijt zijn.

Ten slotte zien we onder in het overzicht nog een totaal aantal getoond. Dit totaal is af te leiden uit het overzicht door simpelweg het aantal afgedrukte en dus gedraaide nummers te tellen. Als het totaal niet onder in het overzicht zou staan afgedrukt, zou-den we het zelf op eenvoudige wijze even kunnen bepalen. Het totaal aantal kunnen we daarom ook weglaten uit de database. We noemen het totaal aantal een procesgegeven. We kunnen het gegeven namelijk bepalen door een rekenproces te laten uitvoeren. Procesgegevens nemen we nooit op in de database.

Wat we overhouden aan relevante gegevens bestaat uit: datum, code, titel, artiest en soort. De aanduiding soort is echter niet elementair. Met de aanduiding soort bedoelen we twee gegevens, te weten een soortcode (bijvoorbeeld S) en een soortomschrijving (bijvoorbeeld Single). We moeten de aanduiding soort daarom splitsen in twee elementaire gegevens, te weten soortcode en soortomschrijving. Dit splitsen moeten we altijd doen in het geval dat we te maken hebben met samengestelde gegevens.

We houden nu dus over de elementaire gegevens: datum, code, titel, artiest, soortcode en soortomschrijving. In plaats van gege-vens zullen we meestal de term attributen gebruiken.

Met de door ons gevonden attributen is iets speciaals aan de hand. Het eerste gegeven, de datum, komen we maar n keer tegen. De andere gegevens komen we meerdere keren tegen. Om dit verschil duidelijk te maken noteren we onze gegevens daarom op de vol-gende manier:

datum, RG (code, titel, artiest, soortcode, soortomschrijving)

Daarbij staat RG voor repeterende groep (repeating group). Alle gegevens die meerdere keren, repeterend, voorkomen, staan ver-volgens tussen ronde haken vermeld.

procesgegeven

elementaire gegevens

samengestelde gegevens

attributen

repeterende groep


Het overzicht uit guur 3.1 is het overzicht van 17 februari 2001. Paul beschikt echter voor iedere dag dat hij een programma heeft gepresenteerd over een dergelijk overzicht. Om uit de hele stapel met alle overzichten precies het door ons getoonde overzicht te pakken, moeten we weten van welke datum we iets willen weten. De datum wijst in ons geval precies n overzicht aan. De datum geeft ons toegang tot precies n overzicht. We noemen daarom de datum ook wel het sleutelgegeven ofwel sleutelattribuut. We geven het sleutelattribuut aan door dit te onderstrepen. We hebben nu uiteindelijk de nulde normaalvorm gevonden. We noteren dit op de volgende manier:

0 NV (datum, RG (code, titel, artiest, soortcode, soortomschrijving))

Bij het begrip sleutelattribuut kunnen we nog het volgende opmer-ken. Allereerst zal een sleutelattribuut altijd een waarde moeten hebben. Stel namelijk dat in onze stapel met overzichten er een drietal zit waarop de datum niet staat vermeld. Hoe moeten we dan n van deze overzichten aanwijzen? En bij welke uitzenddag horen ze thuis?Daarnaast moet een sleutelwaarde altijd uniek zijn. Met andere woorden, er mogen in onze stapel geen twee overzichten voor-komen met daarop dezelfde datum. In dat geval zouden we immers niet weten welke van de twee de juiste is.Vervolgens geldt dat een sleutelattribuut altijd zo minimaal moge-lijk moet zijn. Als de datum volstaat als sleutel, dan zal ook de combinatie dagaanduiding met datum volstaan. We zouden dan de sleutel datum + dag krijgen (bijvoorbeeld : 23-1-2001 + zaterdag). Omdat we echter ook met een deel hiervan (datum) als sleutel kun-nen werken, zijn we verplicht het overtollige deel, de dagaandui-ding, weg te laten. We kunnen volstaan met alleen de datum omdat bij iedere datum slechts n dagaanduiding hoort.

Ten slotte merken we nog even op dat er soms sprake is van meer-dere attributen die als sleutelattribuut zouden kunnen fungeren. We noemen dit kandidaatsleutels. Een voorbeeld hiervan is het leerlingnummer zoals dat op school gebruikt wordt en het CRI-nummer waaronder iemand in Groningen bekend is. Ook het CRI-nummer is op school bekend. Men heeft daar nu om een leerling te kunnen aanwijzen twee mogelijkheden, twee kandidaatsleutels.

sleutelattribuut

kandidaatsleutels


Zou men ook nog het SoFi-nummer kennen, dan zou er zelfs sprake zijn van een drietal kandidaatsleutels. In het algemeen kiest men uit de kandidaatsleutels er n die als sleutelattribuut zal gaan fungeren.

Maak opdracht 3.1.

3.2 Stap 2, de eerste normaalvorm

We hebben op dit moment de nulde normaalvorm in handen. Deze ziet eruit als:

0 NV (datum, RG (code, titel, artiest, soortcode, soortomschrijving))

In deze nulde normaalvorm zit een aantal problemen verborgen. We zullen nu een van de hoofdproblemen aanpakken. Dit zal auto-matisch resulteren in de eerste normaalvorm. Het probleem dat we aanpakken, is het probleem dat optreedt als een nummer meerdere keren door Paul is gedraaid. Iedere keer zal hij steeds alle gege-vens van dat nummer noteren, dus code, titel, artiest, soortcode en soortomschrijving. Het lijkt misschien alsof we slechts n keer een code, titel, enzovoort noteren, maar de afkorting RG geeft aan dat we dat herhaaldelijk doen, zo vaak als er nummers gedraaid zijn. Dat betekent dat als Paul het nummer Coming Home van Romeo in een jaar totaal zestig keer heeft gedraaid, hij ook zestig keer alle gegevens heeft genoteerd. Dat is toch raar? Waarom kun-nen we niet volstaan met het n keer noteren van alle gegevens? Natuurlijk moeten we dan wel iedere keer even noteren dat we dat nummer hebben gedraaid, maar dat doen we dan kortweg via het noteren van alleen maar de code. In de eerste normaalvorm wordt dit probleem gedeeltelijk opgelost.

We bepalen de eerste normaalvorm door de repeterende groep apart te nemen en uit te breiden met de sleutel van de originele nulde normaalvorm. Hierna bepalen we in de nu nieuw gevonden reeks weer een sleutel.

In ons geval bestaat de repeterende groep uit (code, titel, artiest, soortcode, soortomschrijving). Deze nemen we apart en we voegen de sleutel (datum) eraan toe.


We krijgen dan:

(datum, code, titel, artiest, soortcode, soortomschrijving)

Let erop dat we de datum, hoewel die in de eerste normaalvorm sleutel was en dus onderstreept, nu niet zonder meer opnieuw onderstrepen. We gaan nu een nieuwe sleutel aanwijzen. Daartoe moeten we ons eerst afvragen hoe we de nu ontstane groep terug-zien op het originele overzicht. Dan weten we namelijk wat we proberen aan te wijzen en kunnen we bepalen wat een goede sleu-telkeuze is. Kijk eens naar guur 3.2.

Onze groep gegevens, met eenmaal een datum, eenmaal een code, eenmaal een titel, enzovoort vinden we terug als een enkele regel van het overzicht. Om precies n regel op een bepaald formulier aan te duiden moeten we eerst aangeven naar welke formulier, van welke datum, we willen kijken. Daartoe dienen we dus de datum op te geven. Vervolgens selecteren we n enkele regel van het betreffende overzicht door de code van het betreffende nummer op te geven. Iedere code komt hooguit n keer op een overzicht voor omdat Paul nooit twee maal hetzelfde nummer in dezelfde uitzen-ding draait. De combinatie van datum en code kan dus fungeren als sleutel. We krijgen dan:


Omdat de sleutel nu bestaat uit twee delen en omdat een sleutel altijd minimaal moet zijn, moeten we wel even controleren of een kleinere sleutel misschien ook voldoet. Dus we gaan na of alleen

Figuur 3.2


de datum als sleutel ook voldoet. Dat is natuurlijk niet zo, want bij n datum vinden we meerdere nummers die Paul heeft gedraaid, dus meerdere regels, en we zoeken precies n regel.

Kunnen we misschien volstaan met alleen de code van het nummer als sleutel? Dat zou kunnen als Paul een nummer nooit meer dan n keer draait, ook niet op verschillende dagen. Omdat wij weten dat Paul wel degelijk nummers vaker draait, ontstaat het probleem dat we een bepaalde code op meerdere overzichten, van verschil-lende datums, kunnen terugvinden. Daardoor wijzen we dus niet slechts n, maar meerdere regels aan, hoewel die op verschillende overzichten liggen. Dus alleen de code voldoet ook niet als sleu-tel. De door ons eerder gekozen, gecombineerde, sleutel is dus de juiste.

We hebben nu echter nog niet de eerste normaalvorm. We moeten ons werk nog afmaken. Dat doen we door in de originele nulde normaalvorm de door ons apart genomen repeterende groep te ver-wijderen en te kijken wat er overblijft. Wat er overblijft, voegen we als aparte groep toe aan de eerste normaalvorm.

We hadden als nulde normaalvorm gevonden:

(datum, RG (code, titel, artiest, soortcode, soortomschrijving))

Door de repeterende groep te verwijderen houden we alleen over:

(datum)

Deze groep voegen we toe. We krijgen dan uiteindelijk de eerste normaalvorm:

1 NV (datum) (datum, code, titel, artiest, soortcode, soortomschrijving)

We zien dat we nu geen repeterende groep meer over hebben. We zijn dus gedeeltelijk geslaagd in onze opzet. Nog steeds zitten we met het probleem dat als Paul een nummer vaker draait, we steeds opnieuw alle gegevens zitten te noteren. We zijn dus nog steeds niet klaar.


In het toegelichte voorbeeld zien we dat de sleutel uit de nulde nor-maalvorm (datum) ook in de eerste normaalvorm weer onderdeel van de sleutel is. Vaak is dat zo, maar lang niet altijd. Let dus goed op bij het kiezen van een nieuwe sleutel!

Maak opdracht 3.2.

3.3 Stap 3, de tweede normaalvorm

Zoals reeds gezegd heeft de door ons gevonden eerste normaal-vorm nog steeds het nadeel dat dezelfde gegevens steeds opnieuw worden opgeslagen. In de volgende stap, de stap naar de tweede normaalvorm, zullen we dit nadeel grotendeels wegwerken.

Om te komen tot de tweede normaalvorm onderzoeken we in de eerste normaalvorm of er attributen (gegevens) zijn die niet tot de sleutel behoren (niet onderstreept) en die niet van de gehele sleutel afhangen, maar slechts van een gedeelte van de sleutel. We zullen deze moeilijk lijkende regel aan de hand van ons voorbeeld toelich-ten. We kijken alleen maar naar groepen in de eerste normaalvorm waarbij de sleutel samengesteld is, dus uit meerdere attributen bestaat. In ons geval de groep:


We moeten nu zoeken naar niet-sleutelattributen die slechts af-hankelijk zijn van een deel van de sleutel, dus in ons voorbeeld van alleen de datum of alleen de code. De gegevens titel, artiest, soortcode en soortomschrijving hebben niets te maken met de datum, maar zijn alleen maar afhankelijk van de code van het ge-draaide nummer (vertel ons de code en wij vertellen u de artiest, de titel, enzovoort). Die hebben dus niets te maken met de datum. Kortom, de gegevens titel, artiest, soortcode en soortomschrijving zijn niet afhankelijk van de gehele sleutel, maar slechts van een deel van de sleutel. Deze gegevens nemen we apart, tezamen met het deel van de sleutel waarvan ze afhankelijk blijken te zijn. We krijgen dan:

(code, titel, artiest, soortcode, soortomschrijving)


In de originele groep laten we de betreffende niet-sleutelvelden achterwege. We hadden:


en we krijgen nu dus:

(datum, code)

Let erop dat het sleuteldeel waarvan de niet-sleutelvelden afhan-kelijk waren (code) in deze groep gewoon blijft bestaan.

De nu gevonden groepen:

(code, titel, artiest, soortcode, soortomschrijving) (datum, code)

vullen we ten slotte aan met de groepen die we in de eerste nor-maalvorm al hadden gevonden maar waar geen samengestelde sleutel in aanwezig was.

We krijgen dan uiteindelijk de tweede normaalvorm:

2 NV (code, titel, artiest, soortcode, soortomschrijving) (datum, code) (datum)

We hebben nu veel overtolligheid (redundantie) opgeheven. Dat komt doordat in de eerste groep de code de sleutel is. Ieder num-mer wordt hierin hooguit n keer opgenomen. Wordt een nummer nu vaker gedraaid, dan wordt het zo vaak als nodig opgenomen in de tweede groep (datum, code). De gegevens van het nummer zelf, zoals de titel, zijn echter al bekend in de eerste groep en worden daar dus niet nog eens opgenomen. Het achteraf corrigeren van een typefout in de naam van de artiest is nu dus eenvoudig, want het behoeft slechts n maal te worden uitgevoerd.

Maak opdracht 3.3.


3.4 Stap 4, de derde normaalvorm

We zijn op dit moment gevorderd tot en met de tweede normaal-vorm. We nemen nu de laatste stap, het bepalen van de derde nor-maalvorm. De door ons gevonden tweede normaalvorm zag eruit als:


Er zit in deze tweede normaalvorm nog een vorm van overtollig-heid (redundantie). Die heeft te maken met de attributen soortcode en soortomschrijving. Bij ieder nummer staan beide gegevens opgenomen. Als we de gegevens van 1000 nummers op single heb-ben, zal de combinatie S, Single dus 1000 keer zijn opgenomen. Ook hier zouden we met n keer klaar moeten zijn. Wel bij iedere single noteren dat het een single is (soortcode = S), maar slechts n maal noteren dat de code S staat voor de omschrijving Single. Door deze overtolligheid eruit te halen ontstaat de derde normaal-vorm.Om de derde normaalvorm te bepalen vragen we ons of er niet-sleutelattributen (niet-onderstreepte gegevens) zijn die niet af-hangen van de sleutel, maar die eigenlijk afhangen van andere niet-sleutelattributen. Als dat zo is, nemen we deze gegevens op in een nieuwe groep, geven daar de sleutel aan en verwijderen uit de originele groep het afhankelijke attribuut.

Zoals bekend, we hadden al de volgende 2NV gevonden:


In ons voorbeeld hoeven we dus alleen maar in de eerste groep te kijken, want alleen daar is er sprake van een aantal niet-sleutel-attributen. We gaan deze allemaal langs en vragen ons steeds af of ze afhankelijk zijn van de sleutel of van een ander niet-sleutelat-tribuut. Om de titel van een nummer te weten te komen hebben we niets aan de artiest, die kan immers meerdere nummers op zijn repertoire hebben staan. Het heeft ook niets te maken met de soort


muziekdrager, single of cd. Nee, de titel is geheel afhankelijk van de code van het nummer: vertel ons de code en wij vertellen u welke titel daarbij hoort. De titel is dus geheel afhankelijk van de sleutel. We laten de titel met rust. Om dezelfde reden doen we niets met artiest en soortcode.

Met de soortomschrijving is wel iets speciaals aan de hand. Om deze te weten te komen hoeven we niet te weten over welk num-mer we precies praten (de code) maar moeten we weten welke soortcode van toepassing is: vertel ons de soortcode en wij vertel-len u de soortomschrijving. De soortcode heeft dus niets te maken met de sleutel, maar alles met een ander niet-sleutelattribuut. We nemen deze twee attributen daarom apart op in een afzonderlijke groep:

(soortcode, soortomschrijving)

Daarbij geldt dat de soortcode het sleutelattribuut zal worden: ver-tel ons de code en wij vertellen u de omschrijving. Dus:

(soortcode, soortomschrijving)

In de originele groep laten we het nu het afhankelijke niet-sleute-lattribuut (soortomschrijving) achterwege. We houden dan over:

(code, titel, artiest, soortcode)

Let erop dat het attribuut dat sleutel is geworden in de nieuwe groep, in de oorspronkelijke groep gewoon blijft bestaan!

Door de beide zojuist gevonden groepen aan te vullen met de ande-re, niet veranderde groepen uit de tweede normaalvorm, ontstaat de volgende derde normaalvorm:

3 NV (soortcode, soortomschrijving) (code, titel, artiest, soortcode) (datum, code) (datum)

Deze derde normaalvorm is het uiteindelijke doel geweest van het normalisatieproces. Deze nu gevonden groepen kunnen we later op eenvoudige wijze opnemen in een database. Iedere gevonden groep


zal daarbij worden vertaald in een afzonderlijke tabel. Hierdoor kunnen we later op relatief eenvoudige wijze alle gegevens invoe-ren en alle gewenste informatie opvragen. We zullen daar in latere hoofdstukken uitgebreid op terugkomen.

Eerst moeten we nog een paar afrondende handelingen verrich-ten. De eerste handeling bestaat uit het toekennen van namen aan de gevonden groepen, aan de gevonden tabellen. De eerste tabel geven we de naam SOORT, omdat daarin de soort muziek-drager wordt bijgehouden, single of cd. De tweede tabel noemen we TRACK omdat daarin de gegevens van de tracks worden bijgehouden. In de derde tabel worden de gegevens bijgehouden van de nummers die gedraaid zijn, we kunnen dit zien als een DRAAILIJST. Ten slotte hebben we nog de laatste tabel waarin de datums liggen opgeslagen van de dagen waarop Paul een program-ma heeft verzorgd. Deze tabel noemen we DATUM.

3 NV SOORT (soortcode, soortomschrijving) TRACK (code, titel, artiest, soortcode) DRAAILIJST (datum, code) DATUM (datum)

We kunnen ons echter afvragen of het zin heeft om deze tabel bij te houden. Immers, een overzicht van alle draaidatums kunnen we ook aeiden uit de tabel DRAAILIJST. Tenslotte komen alle datums daar ook in voor. Omdat de tabel DATUM verder geen speciale betekenis heeft, zullen we deze weglaten. Daardoor gaan er geen gegevens verloren.We houden dan dus over:

3 NV SOORT (soortcode, soortomschrijving) TRACK (code, titel, artiest, soortcode) DRAAILIJST (datum, code)

Het komt vaker voor dat een van de gevonden groepen in de derde normaalvorm mag worden weggelaten. Dit zijn dan altijd tabel-len waarin alleen maar sleutelattributen voorkomen. De tabellen mogen alleen maar worden weggelaten als er daardoor verder geen informatie verloren gaat. Niet iedere tabel die bestaat uit alleen maar sleutelattributen mag dus worden weggelaten! Controleer altijd terdege. De groep DRAAILIJST mag in ons voorbeeld niet


weggelaten worden omdat daar nu precies in staat welke nummers op welke datum zijn gedraaid. Zonder deze groep zouden we alleen maar de gegevens van de nummers hebben. En dan kunnen we dus niet het door Paul gewenste overzicht maken.

Ten slotte willen we nog even opmerken dat het niet altijd zo is dat er bij de stap van de ene naar de andere normaalvorm altijd iets gedaan kan worden. Regelmatig blijken twee normaalvormen gelijk aan elkaar te zijn. In dat geval zullen we gebruikmaken van een verkorte notatiewijze. Als de tweede normaalvorm gelijk blijkt te zijn aan de eerste normaalvorm, noteren we bij de tweede nor-maalvorm: 2NV = 1NV.

Maak opdracht 3.4.

3.5 Entiteit Relatie Diagram (ERD)

Tijdens het normalisatieproces hebben we voornamelijk gesproken in termen van gegevens en groepen met gegevens. Ofcieel zijn er echter andere termen in gebruik.


In plaats van gegevens hebben we het ofcieel over attributen. Zo staat in het bovenstaande voorbeeld onder andere het attribuut titel vermeld. Een attribuut kan een bepaalde waarde aannemen, de zogenaamde attribuutwaarde. Bij het attribuut titel zou de attribuutwaarde So close kunnen optreden. De attributen zien we in het schema van guur 3.3 terug als kolommen. Attributen beschrijven groepen, groepen die voor de gebruiker, in ons geval Paul, betekenisvol zijn. In plaats van de term groepen gebruiken we meestal de term entiteit. In de voorgaande derde normaalvorm komen we de entiteiten SOORT, TRACK en DRAAILIJST tegen. De entiteit TRACK bevat dus de gegevens van alle tracks die voor PAUL van belang zijn. Een afzonderlijke track wordt wel een entiteit-occurence genoemd. Deze bevat dus alle gegevens van n enkele track, de afzonderlijke rijen in het schema van guur 3.3.

atribuutwaarde

entiteit

entiteit-occurence


In ons voorbeeld zijn in totaal drie entiteiten gevonden. Deze drie entiteiten hangen niet als los zand aan elkaar maar hebben duide-lijk met elkaar te maken.


Om te achterhalen welke nummers er op een bepaalde datum gedraaid zijn, dienen we in de entiteit DRAAILIJST de door ons gewenste datum op te zoeken. Die komen we daar meerdere keren tegen, iedere keer in combinatie met de code van een gedraaide track. Als we willen weten welke tracks dat precies zijn, moeten we met de gevonden codes naar de entiteit TRACK om daar de betreffende codes op te zoeken. We vinden dan titel, artiest en soortcode. Op soortgelijke wijze kunnen we bij iedere track de juiste soort opzoeken aan de hand van de soortcode. Zie guur 3.4.

Het bijzoeken van gegevens lukt natuurlijk alleen maar als de co-des in DRAAILIJST ook voorkomen in TRACK. In dat geval zou-den namelijk de titel en artiest er niet bijgezocht kunnen worden. We kunnen dan ook onze draailijsten niet meer laten afdrukken. Een probleem dus.

Om dit te voorkomen zullen we een aantal dingen afspreken. Als eerste de term vreemde sleutel (foreign key). Hiermee bedoelen we een gegeven (attribuut) dat verwijst naar de sleutel van een tabel (entiteit). In ons voorbeeld is er sprake van een tweetal vreemde sleutels. Als eerste het attribuut code in DRAAILIJST. Dit is een

Attributen

Code Titel Artiest Soortcode

R2734 Coming home Romeo S

B1954 To the limit Boys II Men C

T5985 CrazySexyCool TLS C

..

Entiteit-occurencesAttribuutwaarden

Entiteit : TRACKFiguur 3.3

vreemde sleutel


vreemde sleutel omdat het verwijst naar het attribuut code in de tabel TRACK, dus naar een sleutel. Ook het attribuut soortcode in TRACK is een vreemde sleutel, want het verwijst naar de sleutel van de tabel SOORT (soortcode). We geven vreemde sleutels wel aan door ze met een stippellijn te onderstrepen. Dus:


Vreemde sleutels verwijzen in het algemeen naar andere tabel-len. Dit lukt alleen maar als iedere waarde die de vreemde sleutel aanneemt ook als sleutelwaarde voorkomt in de tabel waarnaar verwezen wordt. Met andere woorden: als in de DRAAILIJST de code R7734 voorkomt, moet deze waarde ook voorkomen als code in TRACK, met daarbij de naam van de artiest en de titel van het nummer. De eis dat iedere waarde die een vreemde sleutel aan-

Figuur 3.4 DRAAILIJST

Datum Code

17-2-2001 R2734

17-2-2001 B1954

17-2-2001 T5985

17-2-2001 R4288

18-2-2001 N2773

18-2-2001 T5985

.. ..

TRACK

Code Titel Artiest Soortcode

B1954 To the limit Boys II Men C

N2773 Hes my favourite DJ Nance S

R2734 Coming Home Romeo S

R4288 Got to be Romeo C

.. ..

SOORT

Soortcode Soortomschrijving

S Single

C CD


neemt ook als sleutelwaarde moet voorkomen in de andere entiteit, staat bekend onder de eis van referentile integriteit (referential integrity).

Andersom geldt deze eis niet. Er kan in TRACK best een waarde voor code voorkomen die we nog niet tegenkomen in DRAAILIJST. De track is dan gewoon nog nooit gedraaid in het programma! Zoals uit de derde normaalvorm blijkt, kan een vreemde sleutel zelf deel van een sleutel zijn. Kijk naar het attri-buut code in de tabel DRAAILIJST. Een vreemde sleutel kan ech-ter ook een niet-sleutelattribuut zijn. Kijk maar naar het attribuut soortcode in de tabel TRACK.

Via de vreemde sleutels zijn de entiteiten met elkaar verbonden. Deze verbondenheid geven we graag weer door middel van een diagram, omdat dat over het algemeen veel duidelijker is. Dit diagram noemen we Entiteit Relatie Diagram oftewel een Entity Relationship Diagram, kortweg ERD.

Om weer te geven dat twee entiteiten iets gemeenschappelijks heb-ben, via een vreemde sleutel, nemen we de beide entiteiten op door middel van een rechthoek en verbinden deze beide rechthoeken door middel van een rechte lijn. Tevens vermelden we bij de lijn op basis van welke vreemde sleutel het verband bestaat.

We zien dat de lijnen aan de ene kant eindigen in een enkelvoudig einde van de lijn en aan de andere kant eindigen in een vertakt einde van de lijn. Als we vanuit de entiteit DRAAILIJST naar de entiteit TRACK gaan, komen we aan via een enkelvoudig einde van de lijn. Dat betekent dat ieder gegeven in DRAAILIJST, iedere entiteitoccurence, steeds te maken heeft met n track. Andersom, gaan we uit van TRACK en gaan we naar DRAAILIJST, dan komen we bij een vertakt einde van de lijn uit. Dat betekent dat we bij iedere entiteit-occurence uit TRACK, dus bij ieder nummer, meer dan n keer gegevens uit DRAAILIJST kunnen vinden. Dat is ook logisch want een nummer kan meerdere keren zijn gedraaid.

Het bepalen of er een enkelvoudig einde of een vertakt einde moet worden getekend, is eenvoudig. Aan de kant van de lijn waar het

referentile integriteit

Entity Relationship Diagram

DRAAILIJST TRACK SOORT

o.b.v. code o.b.v. soortcode

Figuur 3.5


gemeenschappelijke attribuut, de vreemde sleutel, ook als sleutel optreedt, moet een enkelvoudig einde worden opgenomen. Een sleutelwaarde moet immers altijd uniek zijn en kan dus maar n keer voorkomen, dus een enkelvoudig einde. Aan de andere kant van de lijn, waar het geen sleutel is, gelden geen beperkingen en kan iedere waarde vaker optreden, dus een vertakt einde.

Soms zie je ook dat aan een van de einden een rondje is opgeno-men in de lijn. Dat geeft aan dat er niet altijd aan die kant iets bij hoeft te worden gevonden. Zo hoeft nog niet iedere track al een keer gedraaid te zijn. Niet iedere code die in TRACK voorkomt, hoeft dus voor te komen in DRAAILIJST. Dat is de reden dat er aan die kant een rondje is opgenomen in de lijn. Het rondje staat voor nul.

Hieronder staan alle mogelijkheden kort weergegeven:

er wordt er precies n bij gevonden:

er wordt er nul of n bij gevonden:

er worden er n of meer bij gevonden:

er worden er nul, n of meer bij gevonden:

Maak opdracht 3.5.

3.6 Samenvatting

In dit hoofdstuk hebben we de eerste beginselen van het normali-seren geleerd. Daarbij rafelen we de ongestructureerde gegevens, zoals die op een overzicht worden getoond, in een aantal stappen uiteen tot een gestructureerd geheel. Daarbij maken we gebruik van de techniek van het normaliseren.Eerst stellen we de nulde normaalvorm op door alle elementaire gegevens te noteren. Daarbij laten we alle vaste teksten (constan-ten) en procesgegevens achterwege. We bepalen de sleutel. Het bepalen van de sleutel doen we ook bij iedere volgende stap.Vervolgens bepalen we de eerste normaalvorm door de repeating group te verwijderen.


Hierna bepalen we de tweede normaalvorm. Daarbij nemen we alle gegevens apart die slechts van een deel van de sleutel afhangen en niet van de gehele sleutel. Ten slotte bepalen we de derde normaalvorm. Daarbij nemen we alle gegevens apart die helemaal niet van de sleutel afhangen, maar die van een ander niet-sleutelattribuut afhangen.Nadat we derde normaalvorm hebben gevonden, gaan we na of er misschien groepen zijn die weggelaten mogen worden zonder dat we informatie verliezen. We hoeven hierbij alleen maar de groepen te onderzoeken die uit alleen maar sleutelattributen bestaan.De gegevensstructuur die we nu hebben gevonden, geven we vervolgens grasch weer door middel van een Entiteit Relatie Diagram (ERD). We laten daarbij het verband tussen de diverse tabellen zien. Deze verbanden zijn gebaseerd op vreemde sleutels.Een vreemde sleutel mag alleen maar waarden aannemen die ook in de overeenkomstige andere tabel voorkomen (referentile inte-griteit).

Opdrachten

3,1 Nulde normaalvorma. In de nulde normaalvorm mogen geen procesgegevens worden

opgenomen. Geef aan waarom dat is en gebruik in het antwoord de termen efcint ruimtegebruik en consistentie.

b. In een bibliotheek zal men de afzonderlijke boeken moeten kun-nen aanduiden. Hiertoe zullen zij een sleutelattribuut hebben gedenieerd. Zou men hiervoor het ISBN gebruiken? Verklaar het antwoord.

c. Gegeven het overzicht uit guur 3.6. Stel hiervan de nulde nor-maalvorm op.

Figuur 3.6

Databaseontwikkeling 4 Access 200342 Databaseontwikkeling 4 Access 200342

3.2 Eerste normaalvorma. Gegeven is het overzicht uit guur 3.7. Iemand heeft daarbij de

volgende nulde normaalvorm gevonden.

0 NV (Bestelnummer, naam klant, RG (artikelnr, omschrijving, prijs p/s, aantal), kortings%)

Waarom zijn het bedrag per regel, het subtotaal, het kortings-bedrag en het eindtotaal niet opgenomen in de nulde normaal-vorm?

Bepaal uitgaande van de genoemde nulde normaalvorm de eer-ste normaalvorm.

b. Ga uit van de nulde normaalvorm die je eerder bij opdracht 3.1c gevonden hebt en bepaal de daarbij behorende eerste normaal-vorm. Controleer goed of de gekozen sleutel niet korter kan.

3.3 Tweede normaalvorma. Gegeven is het overzicht uit guur 3.8. Iemand heeft daarbij de

volgende eerste normaalvorm gevonden.

Figuur 3.7

3 Normaliseren, inleiding 433 Normaliseren, inleiding 43

1 NV (Bestelnummer, naam klant, kortings%) (Bestelnummer, artikelnr, omschrijving, prijs p/s, aantal)

Bepaal uitgaande van de bovenstaande eerste normaalvorm de tweede normaalvorm.

b. Wat is het wezenlijke verschil tussen de 1 NV zoals die bij op-dracht 3.3a is gegeven en zoals die hieronder staat afgedrukt?

1 NV (Bestelnummer, naam klant) (Bestelnummer, artikelnr, omschrijving, prijs p/s, aantal, kortings%)

3.4 Derde normaalvorma. Iemand heeft de volgende tweede normaalvorm gevonden. Deze

hoort bij een order die door een klant is geplaatst. Daarbij geldt dat de korting, het percentage, alleen maar afhankelijk is van het aantal dat men van n artikel koopt. Bij n stuk ontvangt men 2% korting, bij twee stuks 3%, bij drie stuks 5%, enzo-voort. Ten slotte geldt dat iedere klant een eigen uniek klant-nummer heeft dat altijd voor hem gebruikt wordt.

Figuur 3.8

Databaseontwikkeling 4 Access 200344 Databaseontwikkeling 4 Access 200344

2 NV (ordernummer, klantnummer, klantnaam) (ordernummer, artikelnr, aantal, kortings%) (artikelnr, omschrijving, prijs p/s)

Bepaal uitgaande van deze tweede normaalvorm de derde nor-maalvorm.

b. Een voetbalvereniging maakt gebruik van (onder andere) het overzicht van guur 3.9. Een lid van de vereniging hoeft geen commissiewerk te doen, maar mag het wel. Indien gewenst kan hij (of zij) zelfs deel uitmaken van meerdere commissies.

Normaliseer het overzicht tot en met de derde normaalvorm.

c. Het overzicht van guur 3.10 wordt bij een camping gebruikt om de reserveringen bij te houden. Op die manier probeert men te voorkomen dat een plaats aan meer dan n klant tegelijker-tijd wordt toegekend. Normaliseer dit overzicht tot en met de derde normaalvorm.

Commissie : BC, Barcommissie

Lidnummer Naam Telefoon

34 L. Ketelaar 010-4883922

122 V. Borrelaar 0180-499302

307 M. Vervat 010-7559403

Figuur 3.9

Camping Zee en Strand, OuddorpPlaatsnummer 23 Klant

Databaseontwikkeling Access 2003

Documents

Transcript of Databaseontwikkeling Access 2003