Aan de slag met databases en Access 2013

Transcriptie

1 Aan de slag met databases en Access 2013 Van ontwerp tot professioneel gebruik Ben Groenendijk + ONLINE OEFENINGEN Zevende druk

2 Aan de slag met databases en Access 2013 Van ontwerp tot professioneel gebruik Ben Groenendijk

3 Meer informatie over deze en andere uitgaven kunt u verkrijgen bij: BIM Media B.V. Postbus BG Den Haag Tel.: (070) Gebruik onderstaande code om dit boek eenmalig toe te voegen aan uw boekenplank op Let op: u kunt deze code maar een keer gebruiken BIM Media B.V., Den Haag Academic Service is een imprint van BIM Media B.V. 7e druk 2014 (Access 2013) Ontwerp omslag en binnenwerk: Studio Bassa, Culemborg Zetwerk: Redactiebureau Ron Heijer, Markelo Omslag: Carlito s Design, Amsterdam ISBN: NUR: 123 Alle rechten voorbehouden. Alle auteursrechten en databankrechten ten aanzien van deze uitgave worden uitdrukkelijk voorbehouden. Deze rechten berusten bij BIM Media B.V. Behoudens de in of krachtens de Auteurswet gestelde uitzonderingen, mag niets uit deze uitgave worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand of openbaar gemaakt in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopieën, opnamen of enige andere manier, zonder voorafgaande schriftelijke toestemming van de uitgever. Voorzover het maken van reprografische verveelvoudigingen uit deze uitgave is toegestaan op grond van artikel 16 h Auteurswet, dient men de daarvoor wettelijk verschuldigde vergoedingen te voldoen aan de Stichting Reprorecht (postbus 3051, 2130 KB Hoofddorp, Voor het overnemen van gedeelte(n) uit deze uitgave in bloemlezingen, readers en andere compilatiewerken (artikel 16 Auteurswet) dient men zich te wenden tot de Stichting PRO (Stichting Publicatie- en Reproductierechten Organisatie, Postbus 3060, 2130 KB Hoofddorp, Voor het overnemen van een gedeelte van deze uitgave ten behoeve van commerciële doeleinden dient men zich te wenden tot de uitgever. Hoewel aan de totstandkoming van deze uitgave de uiterste 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 voorkomende fouten en onvolledigheden. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the publisher s prior consent. While every effort has been made to ensure the reliability of the information presented in this publication, BIM Media B.V. neither guarantees the accuracy of the data contained here in nor accepts responsibility for errors or omissions or their consequences.

4 Voorwoord Databases zijn in het dagelijks leven niet meer weg te denken. Van een afgestudeerde op HBO- of WO-niveau mag worden verwacht dat deze kennis van en inzicht in databases heeft. Naast de theoretische kennis dienen ook praktische vaardigheden aanwezig te zijn. Dit boek beoogt de kennis van en vaardigheden met databases aan te reiken. Dat gebeurt door in stappen te gaan van het (op papier) ontwerpen van een database tot en met het gebruik van de database (in Microsoft Access) teneinde de benodigde informatie te genereren. Allereerst komt het ontwerpen van databases ter sprake. Hierbij wordt de techniek van het normaliseren gehanteerd. Uitgaande van een informatiebehoefte zal via het normalisatieproces de informatiestructuur bepaald worden. Deze structuur wordt vervolgens grafisch weergegeven door middel van een Entiteit-Relatie-diagram. Hierna wordt besproken hoe een gevonden gegevensstructuur kan worden omgezet in een database, waarbij het programma Access zal worden gebruikt. De database wordt gebouwd, gevuld en ten slotte gebruikt voor het opvragen van informatie. Bij de volgende stap wordt de wijze van gegevens opvragen steeds meer geautomatiseerd. Er worden formulieren, rapporten en macro s ontworpen en gebruikt. Deze worden vervolgens gebruikt bij het opzetten van een applicatie. In dit verband wordt niet geprogrammeerd in de zin van het ouderwetse coderen. De applicatie wordt gebouwd door op grafische wijze bouwstenen te selecteren, deze iets aan te passen en ze vervolgens samen te voegen tot professioneel ogende applicaties. Omdat databases algemeen toepasbaar zijn, wordt het boek afge sloten met een hoofdstuk waarin de standaardvraagtaal SQL wordt behandeld. Deze taal wordt niet alleen door Access ondersteund, maar door vrijwel ieder databasemanagementpakket dat op de markt is. Enige kennis van deze taal is dus onontbeerlijk. In het boek wordt ieder onderwerp eerst besproken en toegelicht, waarbij volop gebruik wordt gemaakt van relevante schermafdrukken en instructiefilmpjes. Vervolgens worden bij ieder onderwerp opgaven aangeboden waarin de theoretische kennis direct praktisch kan worden toegepast. In de opgaven worden enkele bestaande databases gebruikt. Op de hierin opgeslagen gegevens moeten vervolgens de nodige bewerkingen worden uitgevoerd. De bij dit boek behorende databases en instructiefilmpjes kunnen worden gedownload of bekeken via de pagina bij dit boek op de portal nl. De uitwerkingen van elk hoofdstuk zijn hier ook te vinden. Op die portal zijn ook interactieve vragen en antwoorden uit hoofdstuk 2 te maken. Om met dit boek te kunnen werken dient u de beschikking te hebben over Access Daarbij maakt het niet uit of u de beschikking heeft over de Engelstalige of de Neder- v

5 Aan de slag met databases en Access 2013 landstalige versie. In het boek is uitgegaan van de Nederlandstalige versie, maar steeds is ook het Engelstalige equivalent erbij gegeven. Bij dit boek is een docentenhandleiding beschikbaar. Hierin wordt per hoofdstuk een extra toelichting gegeven. Verder wordt een toelichting gegeven bij de vragen in het boek. Ook PowerPoint-presentaties van de voorbeelden en opgaven van hoofdstuk 1 worden meegeleverd met de docentenhandleiding. De bestanden die gebruikt zijn in de instructiefilmpjes behoren ook tot het docentenmateriaal. Ook zijn er (voorbeeld) toetsen, inclusief uitwerkingen, beschikbaar. Bovendien wordt extra cursusmateriaal meegeleverd. Het extra cursusmateriaal bevat cases betreffende de eerste vier hoofdstukken, dus normaliseren, eenvoudige bewerkingen in Access en het werken met formulieren en rapporten. Verder zijn er cases voor het werken met SQL. Daarbij is ook een vrij grote database beschikbaar. Iedere serie cases bestaat uit 18 verschillende opgaven. U kunt de docentenhandleiding aanvragen via het adres: accountmanagement@academicservice.nl. Geef hierbij uw school, opleiding, uw naam en de gewenste uitgave op. Toetsen en extra oefeningen op AcademicX.nl AcademicX.nl is de toets- en oefenportal van Academic Service. Daar vinden studenten bij elk hoofdstuk uit dit boek een aantal vragen en opdrachten, met feedback op de resultaten. De activeringscode om te registreren en in te loggen op AcademicX.nl staat op de copyrightpagina van dit boek. Na registratie hebben studenten onbeperkt en kosteloos toegang tot het extra studiemateriaal. De activeringscode kan echter maar eenmaal gebruikt worden. Vragen of opmerkingen over dit boek zijn welkom. Stuur deze aan: b.j.groenendijk@hr.nl Ben Groenendijk januari 2014 vi

6 Inhoud Voorwoord v 1 Normaliseren Inleiding databases Inleiding normaliseren Entiteittypen Normaliseren, nulde normaalvorm Normaliseren, eerste normaalvorm Normaliseren, tweede normaalvorm Normaliseren, derde normaalvorm Normaliseren, voorbeeld Het integreren van gegevensstructuren ER-diagram Geen repeterende groep Dubbele (geneste) repeterende groepen Herhalende repeterende groepen Opmerkingen met betrekking tot normaliseren Opgaven 35 2 Eenvoudige bewerkingen in Access Inleiding Het starten van het programma Access Het creëren van de database en tabel Aanmaken van een database Aanmaken van een nieuwe tabel Het openen van een bestaande database Selecteren van een bestaande database Selecteren van een bestaande tabel Aanpassen van het ontwerp van de tabel Records manipuleren Records toevoegen Records wijzigen Records verwijderen Records sorteren Records filteren Records zoeken Records zoeken (en vervangen) Totalen 60 vii

7 Aan de slag met databases en Access Werken met meerdere tabellen tegelijkertijd Leggen van relaties Verwijderen/bewerken van relaties Gegevens selecteren en manipuleren Gegevens selecteren, selectiequery Gegevens opvragen, rekenkundige bewerkingen Gegevens opvragen, geavanceerde selectiequery Gegevens groeperen, group-by-query Gegevens wijzigen, bijwerkquery Gegevens verwijderen, verwijderquery Overige query s Toepassing van relaties, referentiële integriteit Rapporten Rapport ontwerpen (snelle methode) Rapport ontwerpen via de wizard Etiket ontwerpen Formulieren Formulier ontwerpen (snelle methode) Formulier ontwerpen via de wizard Uitgebreide formulieren Keuzemogelijkheden Bijlagen Keuzelijsten Keuzelijst met getypte invoer Keuzelijst met meerdere waarden Keuzelijst om te zoeken Hoofd- en subformulieren Tabbladen Opdrachtknoppen Uitgebreide rapporten Rapport zonder duplicaten Rapport met groepen Rapport met meerdere groepen Rapport met veel rekenvelden Macro s Een eenvoudige macro Een eenvoudige ingesloten macro Geavanceerde macro s Gegevensmacro s 210 viii

8 Inhoud 6 Een applicatie zonder programmeren Tabellen en relaties Menustructuur De formulieren Formulier Klant Formulier Bestemming Formulier Reis Formulier Boeking Formulier Constant Formulier Volgnummer Formulier Vertreklijst De rapporten Rapport Boeking Rapport Klantenlijst Rapport Vertreklijst Rapport Omzetlijst Voltooien van de applicatie Navigatieformulier Opstarten Lint verwijderen SQL, Structured Query Language Inleiding Begrippen Opbouw hoofdstuk Database Bibliotheek (theorieopdrachten) Database Alco (praktijkopdrachten) Opvragingen uit één tabel SQL gebruiken in Access Eenvoudige opvragingen uit meerdere tabellen Wijzigen van de volgorde Rekenkundige bewerkingen Groeperen Subquery s Speciale joins en views SQL, meer mogelijkheden 311 Bijlage A Veldeigenschappen 313 Veldlengte 313 Notatiewijze 315 Invoermasker 318 Bijschrift 321 Standaardwaarde 321 Validatieregel 321 Validatietekst 322 Vereist 322 ix

9 Aan de slag met databases en Access 2013 Lengte nul toegestaan 322 Geïndexeerd 322 Unicode-compressie 324 IME-modus / IME-zinmodus 324 Tekstuitlijning 324 Datumkiezer weergeven 324 Tekstopmaak 324 Alleen toevoegen 325 Expressie 325 Resultaattype 325 Bijlage B Opties 327 Categorie Algemeen (General) 328 Categorie Huidige database (Current Database) 328 Categorie Gegevensblad (Datasheet) 331 Categorie Ontwerpfuncties voor objecten (Object Designers) 332 Categorie Controle (Proofing) 334 Categorie Taal (Language) 334 Categorie Clientinstellingen (Client Settings) 336 Categorie Lint aanpassen (Customize Ribbon) 337 Categorie Werkbalk Snelle toegang (Quick Access Toolbar) 337 Categorie Invoertoepassingen (Add-Ins) 337 Categorie Vertrouwenscentrum (Trust Center) 339 Index 343 x

10 Hoofdstuk 1 Normaliseren 1.1 Inleiding databases De huidige maatschappij kenmerkt zich door de enorme hoeveelheid gegevens en informatie die ons continu wordt aangeboden. Internet, Facebook, Twitter, radio, televisie, reclame en telefoon overspoelen ons daarmee. Niet alleen in ons privé-leven worden we overspoeld, ook in onze contacten met de zakelijke wereld worden we er volop mee geconfronteerd. Een groot deel van de aangeboden gegevens/informatie ervaren we als niet-relevant. Maar er zijn ook zaken die we willen vastleggen. Soms omdat we daartoe verplicht zijn (bedrijfsleven), soms omdat we voor ons zelf zekerheid willen (afspraken in agenda, telefoonnummers van bekenden) en soms omdat we het gewoon leuk vinden (reisverslag van de vakantie, vliegtuigspotters, enzovoort). Voor het vastleggen van gegevens wordt tegenwoordig vrijwel altijd gebruik gemaakt van een computer. Alleen een computer volstaat niet, er dient ook software aan wezig te zijn waarmee de gegevens kunnen worden ingevoerd en opgeslagen. Daarbij hebben we de keus uit een grote verscheidenheid aan programma s. Er zijn daarbij verschillende categorieën programma s te onderkennen: tekstverwerkers (bijvoorbeeld Word), spread sheets (bijvoorbeeld Excel) en databases (bijvoorbeeld Access). Welk soort programma u gebruikt, is een beetje afhankelijk van het doel en van de omstandigheden. Zo zult u het reisverslag van de vakantie waarschijnlijk vastleggen met behulp van een tekstverwerker. Immers, u wilt de zaak vastleggen, opmaken, voorzien van uw digitale foto s en vervolgens verspreiden (internet of via ). Daarbij biedt de tekstverwerker u alle mogelijkheden die u wenst. Een docent zou de cijfers van een toets kunnen opslaan in een tekstverwerker. Regels met naam student, naam toets, score, datum toets, etc. Het wordt alleen lastig als u die gegevens op een andere manier wilt presenteren, bijvoorbeeld op volgorde van de behaalde score (van laag naar hoog). Of hoeveel voldoendes heeft een bepaalde toets? In dat geval kan beter gekozen worden voor een spreadsheet-applicatie, bijvoorbeeld Excel. In de verschillende kolommen kunnen de gegevens (naam student, naam toets, score, etc.) geplaatst worden. Hierdoor ontstaat de mogelijkheid om de gegevens op een willekeurige manier te sorteren en te presenteren. Bovendien kunnen er eenvoudig tellingen uitgevoerd worden, bijvoorbeeld het aantal voldoendes. Op dezelfde manier zou de huismeester van een kantoorgebouw een lijst kunnen bijhouden met kamernummers, namen van de gebruikers en de nummers van de toegangssleutels. Komt een andere medewerker in een kamer te zitten of krijgt het slot een nieuwe cilinder en dus een andere sleutel, dan kan de wijziging eenvoudig worden aangebracht. In eenvoudige gevallen werkt dit goed. Meestal is de praktijk echter niet zo simpel en willen we meer. Zo wil een juwelier die via internet producten verkoopt niet alleen de adresgegevens van zijn klanten bijhouden. Ook de producten die gekocht zijn, het bedrag van de producten, manier van betalen en de verkoopdatum worden onder andere vastgelegd. Uit die gegevens kan bijvoorbeeld het gemiddelde bestedingsbedrag per order worden bepaald, welke productgroep 1

11 Aan de slag met databases en Access 2013 behaalt de meeste omzet, welke betalingsmethode wordt het meest gebruikt? Maar ook het bepalen van ABC-klanten (bestellen vaak, gemiddeld of laag), op basis hiervan kan een mailing opgesteld worden. Ook kunnen we meten wat het effect is van een reclamecampagne. Om dit te kunnen bepalen is niet alleen de huidige bestelling nodig, maar ook de gegevens uit het verleden moeten worden geregistreerd, omdat u anders de gewenste informatie niet kunt genereren. Alle opgeslagen gegevens moet u vervolgens op allerlei manieren met elkaar in verband kunnen brengen, bewerken en presenteren, teneinde de gewenste informatie te kunnen leveren. Een spreadsheet schiet hier duidelijk tekort. Hier kunnen we beter een beroep doen op een database. Een databaseprogramma stelt ons in staat om grote hoeveelheden gegevens op een gestructureerde manier op te slaan. Deze gegevens kunnen dan later op allerlei manieren worden bewerkt, waarna de resultaten overzichtelijk in rapportvorm kunnen worden gepresenteerd. Op basis van dergelijke rapporten kunnen dan conclusies getrokken worden en acties worden ondernomen. We spreken nu eigenlijk over een informatiesysteem. Bij het beheren van grote hoeveelheden gegevens zal vaak een data base gebruikt worden. De gegevens zijn dan meestal samen gebracht in bestanden, te vergelijken met elektronische kaartenbakken. Bij de eerste toepassingen (applicaties), geschreven voor het beheren van bestanden, beschikte iedere gebruiker (iedere applicatie) over een eigen be stand. Iedereen werkte op zijn of haar eigen eilandje, zie figuur 1.1. Toepassing 1 Toepassing 2 Bestand A Bestand B Bestand B Bestand C Figuur 1.1 Het zal duidelijk zijn dat deze manier van werken nadelen heeft. Als verscheidene gebruikers over een eigen klantenbestand beschikken, zullen de gegevens in de diverse bestanden snel verouderd zijn. Wie ga randeert immers dat een adreswijziging in alle bestanden wordt doorgevoerd? De verouderde, onjuiste gegevens geven aanleiding tot inconsistentie (tegenstrijdigheid en dus onbetrouwbaar). In het ene klantenbestand staan de gegevens van de klant al op het nieuwe adres, maar in het andere klantenbestand nog op het oude adres. Bovendien kunnen tussen de diverse klantenbestanden kleine structuurverschillen optreden: niet iedereen neemt exact dezelfde gegevens op. Zo zal de afdeling Verzending geïnteresseerd zijn in het afleveradres, wil de financiële afdeling het postadres opnemen 2

12 Hoofdstuk 1 Normaliseren en is de afdeling Verkoop geïnteresseerd in het maximaal te verlenen krediet. De uitwisselbaarheid van gegevens komt hiermee in het geding. Ten slotte brengt deze wijze van werken redundantie met zich mee. Met redundantie wordt bedoeld dat dezelfde gegevens meer dan één keer liggen opgeslagen. Een wijziging in een enkel gegeven moet daardoor ook meermalen worden aangebracht. Dat kan nooit de bedoeling geweest zijn. Om deze nadelen op te heffen werd al snel overgestapt op toepassingen waarmee het mogelijk was bestanden gezamenlijk te gebruiken. Er bestaat slechts één klantenbestand. Alle gebruikers die klantgegevens nodig hebben, gebruiken hetzelfde bestand. Hierdoor wordt voor komen dat de gegevens inconsistent (onbetrouwbaar) worden. Verder is ook de redundantie teruggedrongen, zie figuur 1.2. Toepassing 1 Toepassing 2 Bestand A Bestand B Bestand C Figuur 1.2 Nu ontstaan echter nieuwe problemen. Omdat de gegevens eenmalig liggen opgeslagen, krijgt iedere gebruiker te maken met dezelfde gegevensstructuur. Iedere gebruiker wordt er bijvoorbeeld mee geconfronteerd dat van klanten het afleveradres wordt genoteerd, ook de afdelingen die totaal niet in dat gegeven geïnteresseerd zijn. Als een afdeling meer gegevens van klanten wenst op te slaan, en dus de structuur van het bestand aanpast, zullen alle andere gebruikers ook geconfronteerd worden met deze nieuwe structuur. Dit vergt grote aanpassingen in alle gebruikte toepassingen. De moderne manier van gegevensopslag voorziet in een oplossing van het hiervoor genoemde probleem. We maken daarbij gebruik van een database. Gebruikers krijgen zelf geen directe toegang meer tot de bestanden, maar werken via een databasemanagementsysteem (DBMS), zie figuur 1.3. Het DBMS beheert de volledige gegevensstructuur van alle bestanden. Als de financiële afdeling zijn klantgegevens opvraagt, handelt het DBMS dit af. De specifieke klantgegevens van deze afdeling worden geselecteerd uit het volledige klantenbestand. Indien wijzigingen aan het volledige klantenbestand plaatsvinden die geen betrekking hebben op de afdeling financiën, heeft dat geen gevolgen voor de toepassingen van die afdeling. Door het DBMS is het mogelijk dat iedere toepassing zijn eigen zienswijze heeft op de gegevensstructuur in de database. Dit wordt een view genoemd. Zo heeft bijvoorbeeld de afdeling financiën een andere view op de klantgegevens dan de afdeling expeditie. Het afleveradres is voor financiën niet van belang en wordt dan ook niet getoond bij het opvragen van alle klantgegevens. 3

13 Aan de slag met databases en Access 2013 Toepassing 1 Toepassing 2 DBMS Bestand A Bestand B Bestand C Figuur 1.3 De volledige structuur van alle klantgegevens is vastgelegd in het conceptuele schema, de zienswijze van de volledige organisatie. Ook wel aangeduid als functioneel of logisch datamodel. In dit datamodel wordt de volledige structuur van alle gegevens vastgelegd. Hoe een dergelijk datamodel wordt ontworpen staat in de volgende paragrafen uitgelegd. De persoon die verantwoordelijk is voor de opslag van de gegevens, de database-administrator, bepaalt in overleg met de gebruikers welke gegevens op welke manier zullen worden opgeslagen. De administrator heeft ook de bevoegdheid de structuur van de database op te stellen, deze eventueel aan te passen en per gebruiker te bepalen welke gegevens hij mag inzien of muteren. Gebruikers kunnen alleen maar de handelingen verrichten die de database-administrator hun toestaat op de gegevens die de administrator aan hen ter beschikking stelt. Dit wordt autorisatie, machtiging of permissie genoemd. De gebruiker kan gegevens opvragen via het DBMS, dat hier voor beschikt over speciale faciliteiten. In Access kan de gebruiker bijvoorbeeld gebruikmaken van een grafisch georiënteerde opvraagfaciliteit waarmee op eenvoudige wijze vragen (query s) kunnen worden samengesteld. In Access kan ook gebruik gemaakt worden van de standaardvraagtaal SQL (Struc tured Query Language). Bovendien beschikt een DBMS onder andere over faciliteiten waarmee op eenvoudige wijze backups gemaakt kunnen worden. Tevens kunnen beschadigde bestanden hersteld worden of kan voorkomen worden dat twee gebruikers tegelijkertijd hetzelfde gegeven willen wijzigen (record locking). Een databasemanagementsysteem dat daarnaast in staat is te werken met de relaties die tussen bestanden bestaan, noemt men een relationeel databasemanagementsysteem. De meeste hedendaagse databases zijn relationele databases. Ook Access is daar een voorbeeld van. 4

14 Hoofdstuk 1 Normaliseren 1.2 Inleiding normaliseren Bedrijven bestaan bij de gratie van de beschikbaarheid van de door hen benodigde informatie. De aard van de informatie kan divers zijn. Het kan gaan om een factuur, een prijslijst, een omzetstatistiek, een loonstaat, de bezettingsgraad van vrachtauto s, de tentamenresultaten van studenten, enzovoort. Deze informatie is over het algemeen niet direct beschikbaar maar moet worden gegenereerd uit de voorhanden zijnde gegevens. Een gegeven is te zien als een kaal feit, zonder directe waarde. De waarde ontstaat pas door gegevens te combineren en te bewerken tot infor matie. Op basis van deze informatie kunnen vervolgens beslissingen genomen worden. Het al dan niet beschikbaar zijn van de benodigde gegevens is dus van belang. Deze moeten daarom op een goede, overzichtelijke en be trouwbare wijze worden opgeslagen. De gegevens moeten correct zijn, dus onderhoudbaar, denk aan het kunnen aanbrengen van een adreswijziging van een klant. We kunnen gegevens zomaar, zonder enige structuur, opslaan in de computer. Een factuur kunnen we eenvoudig in Excel maken, opslaan en afdrukken. De factuur is de gewenste informatiebehoefte. Voor een kleine onderneming is het wellicht een goede methode, voor een onderneming die veel facturen per dag moet maken niet. Bol. com, bijvoorbeeld, maakt meer dan facturen per dag! Met facturen in Excel kan geen managementinformatie gemaakt worden. Denk hierbij aan per boek een voorspelling van het verkoopaantal voor de volgende dag, per klant de gemiddelde besteding, de omzet per week, een top-10 van de verkochte boeken, enzovoort. Dat is allemaal niet mogelijk als de facturen in Excel zijn gemaakt. Met een database is het wel mogelijk. In een database worden de gegevens (data) en de gewenste uitvoer apart opgeslagen. De gegevens van de facturen worden gestructureerd opgeslagen in gegevensgroepen. De factuur zelf (ongestructureerd) wordt via een rapport afgedrukt. Het rapport maakt daarbij gebruik van de data in de gegevensgroepen. In de gegevensgroepen wordt de data zo efficiënt mogelijk opgeslagen. Bijvoorbeeld een berekening uit Excel wordt niet opgeslagen. Dus een regeltotaal wordt niet opgeslagen, wel de gegevens waarmee de berekening is gemaakt (aantal en prijs per stuk). Het proces van informatiebehoefte (factuur) naar gestructureerde gegevensgroepen wordt normaliseren genoemd. Zoals eerder al verteld is, moet het uitgangspunt bij het ontwikkelen van een informatiesysteem de gewenste informatie zijn. Daarom zullen we ons in dit hoofdstuk bezighouden met het uiteenrafelen van de verlangde informatie in de elementaire gegevens en het structu reren van deze gegevens. Een werkwijze die daarvoor heel geschikt is, bestaat uit het toepassen van het normalisatieproces, zoals dat door E.F. Codd geïntroduceerd is. Het resultaat van normaliseren is een aantal gestructureerde gegevensgroepen. Tussen deze verschillende groepen bestaan verbanden. Deze verbanden zullen we aangeven in een ER-diagram (Entiteit-Relatie-diagram). 5

15 Aan de slag met databases en Access Gegevensgroepen (Entiteittypen) Voordat we ons gaan bezighouden met normaliseren, behandelen we enkele begrippen die daarbij aan de orde komen. Het doel van normaliseren is in feite het voorkomen van inconsistentie (tegenstrijdigheid, onbetrouwbaarheid) en redundantie (meervoudige opslag). We willen daartoe de ongestructureerde informatiebehoefte structureren door deze te splitsen in een aantal afzonderlijke gegevensgroepen. Zo kunnen gegevensgroepen ontstaan zoals KLANT, ORDER, ARTIKEL, TRANSPORT, PERSONEEL, etc. Een gegevensgroep is een verzameling van voor de gebruiker betekenisvolle kenmerken (eigenschappen, elementen, items), die samen een bepaalde eenheid vormen. Zo zal bijvoorbeeld de gegevensgroep ARTIKEL de kenmerken artikelnummer, omschrijving, artikelgroep, voorraad en verkoopprijs bezitten. De gegevensgroep en de kenmerken vertellen iets over de gehele groep, niet over één enkel exemplaar. We houden de diverse kenmerken immers bij voor alle exemplaren uit de gegevensgroep. Bij een exemplaar binnen de gegevensgroep horen de bijbehorende waarden van de kenmerken. Een exemplaar uit de gegevensgroep ARTIKEL is bijvoorbeeld: 87432; Bureaustoel Lena; Stoelen; 34; 79,95. Dit kunnen we ook schematisch weergeven, zie figuur 1.4. Gegevensgroep: ARTIKEL Artikelnr Omschrijving Artikelgroep Voorraad Verkoopprijs Tafel Bianca Tafels 3 895, Bureaustoel Lena Stoelen 34 79,95 Etc....,.. Figuur 1.4 De gegevensgroep ARTIKEL staat dus voor alle exemplaren binnen de gehele groep. Binnen het kenmerk (element, item, eigenschap) artikelnummer vallen alle waarden van het kenmerk. In een database worden de gegevens altijd op die manier opgeslagen: rijen met dezelfde soort gegevens en kolommen met allemaal dezelfde soort gegevens. Dit zou u in Excel ook op deze manier kunnen opslaan en dan verschillende tabbladen maken met de gegevens van de andere groepen. Het grote verschil tussen Excel en een database (bijvoorbeeld Access) is dat er tussen de groepen (tabbladen) relaties worden gelegd in een database. Als u zich de gegevens denkbeeldig voorstelt in Excel en u zou bijvoorbeeld in het tabblad KLANT een willekeurige klant selecteren en u selecteert daarna het tabblad ORDER (waarin alle orders staan; dit kunnen er miljoenen zijn in een database), dan zou u in een database alleen nog maar de orders zien van de geselecteerde klant, alle andere orders zijn automatisch gefilterd. Selecteert u daarna een willekeurige order in tabblad ORDER en selecteert u daarna tabblad ARTIKEL, dan zou u in een database alleen de artikelen zien van de geselecteerde order, alle andere artikelen zijn automatisch gefilterd. Dat is het grote verschil tussen een spreadsheetapplicatie zoals Excel en een database applicatie zoals Access. Een kenmerk of kenmerken waarmee een exemplaar uniek te selecteren is, noemen we sleutelkenmerk, kortweg sleutel of key. In ons voorbeeld is dat het kenmerk artikelnum- 6

16 Hoofdstuk 1 Normaliseren mer. Met een artikelnummer kunnen we uit alle exemplaren exact één uniek exemplaar selecteren. Voor een sleutelwaarde geldt altijd dat deze uniek is binnen de verzameling. We noemen dit ook wel identity integrity. Hierdoor is ieder exemplaar (regel) uniek, er zijn dus nooit twee of meer dezelfde exemplaren! Verder geldt dat een sleutel minimaal moet zijn, dat wil zeggen dat de sleutel geen kenmerken mag bevatten die niet absoluut noodzakelijk zijn voor het identificerende karakter. Zo is artikelnummer en omschrijving samen ook een sleutel, maar is niet minimaal. Verder geldt dat een sleutelwaarde nooit leeg mag zijn. Er moet altijd een waarde aanwezig zijn. Ten slotte merken we op dat het niet verstandig is, kenmerken die aan veranderingen onderhevig zijn op te nemen in de sleutel. Het identificerende karakter wordt dan immers tijdsafhankelijk. Het mobiele telefoonnummer van een persoon als sleutel kiezen is daarom niet verstandig. Bovendien kan een lege waarde optreden als iemand geen mobiele telefoon heeft. Het kan voorkomen dat in een gegevensgroep geen sleutel aanwezig is, zelfs als u alle kenmerken samen als sleutel kiest. In een dergelijke situatie dient een extra kenmerk als sleutel toegevoegd te worden. Als in ons voorbeeld het kenmerk artikelnummer niet had bestaan, dan zou geen sleutel aanwezig geweest zijn. Tafel Bianca is te bestellen in verschillende houtsoorten, met dezelfde prijs en bovendien kan de voorraad hetzelfde zijn. Indien u dan alle kenmerken als sleutel kiest kunnen meerdere exemplaren optreden. Dat is in strijd met de regel dat een sleutel uniek moet zijn. Er dient dan een extra kenmerk toegevoegd te worden, artikelnummer. In veel gegevensgroepen zitten van die sleutelkenmerken. Denk bijvoorbeeld aan studentnummer. Zonder een dergelijk nummer is een student niet uniek te identificeren. Een tweeling met dezelfde voorletters kan dan problemen opleveren. Het schema zoals in figuur 1.4 (in tabelvorm) is geen geschikte manier om de gegevensgroep ARTIKEL te beschrijven. Bij het beschrijven zijn we eigenlijk niet geïnteresseerd in de verschillende exemplaren en de waarden van hun kenmerken. Deze veranderen in de loop van de tijd voortdurend, waardoor de beschrijving achterhaald is. Het enige echt belangrijke van het voorgaande schema is de aanduiding van de betreffende gegevensgroep (waar gaat het over) en de verschillende kenmerken (welke kenmerken zijn van belang). Een betere beschrijving van de gegevensgroep ARTIKEL vindt u hieronder. Deze beschrijving toont alleen de belangrijke zaken. ARTIKEL (artikelnr, omschrijving, artikelgroep, voorraad, verkoopprijs) Let op De sleutel is onderstreept, omdat dit kenmerk een speciale rol speelt. De bovenstaande notatie zullen we in het vervolg veelvuldig hanteren. Terminologie In de literatuur wordt een gegevensgroep aangeduid als entiteittype, een kenmerk (element, item, eigenschap) als attribuuttype, een exemplaar met entiteit-occurrence en een kenmerkwaarde als attribuutwaarde. Deze termen worden veel toegepast aangezien E.F. Codd ze heeft gebruikt. E.F. Codd was wiskundige en heeft op basis daarvan dit model uitgedacht. Een praktisch model in de vorm van een relationele database is pas later 7

17 Aan de slag met databases en Access 2013 ontwikkeld. Om het nog iets ingewikkelder te maken, de gevonden entiteiten vormen later, bij de technische implementatie, de basis voor de database. De entiteiten worden dan tabellen of bestanden genoemd. Attribuuttypen worden kolommen of velden genoemd en entiteit-occurrences (exemplaren) rijen of records. Als u op internet extra informatie over normaliseren wilt zoeken, gebruik dan voor uw zoekopdracht de woorden normaliseren, entiteittype of attribuuttype. 1.4 Normaliseren, nulde normaalvorm De in de voorgaande paragraaf besproken notatiewijze voor gegevensgroepen is gemakkelijk te hanteren. Het blijkt ook eenvoudig te zijn een praktische uitwerking van die notatiewijze te implementeren in relationele databases. Men spreekt ook wel over het omzetten van het func tionele model naar het technische ontwerp. We zullen later terugkomen op de praktische implementatie in Access. Omdat we in onze informatiebehoefte willen voorzien door een re lationele database (Access) toe te passen, ligt het voor de hand de infor matiebehoefte op voorgaande wijze te beschrijven. Normaliseren gebeurt altijd op basis van de informatiebehoefte. Laten we een veel voorkomende informatiebehoefte als uitgangspunt nemen, zie figuur 1.5. De factuur moet gegenereerd kunnen worden aan de hand van de door ons te bepalen gegevensgroepen. Welke zijn dat en welke kenmerken onderscheiden we? Verschoor Groothandel Munsterstraat LP Rotterdam Factuurcode : PI Datum : Klant : Grootbroek P. Adres : Afnamestraat 78 Postc/plaats : 4832 TR Kleinstad Telefoon : Artikelnr Omschrijving Aantal Prijs Bedrag DVDREC3 KTV06-M DVDRecorder Arphlips Kleuren TV ANOY , , , ,00 Subtotaal 2845,00 Korting 200,00 BTWtotaal 2645,00 21% BTW 555,45 TOTAAL 3200,45 Figuur 1.5 8

18 Hoofdstuk 1 Normaliseren Het is niet in één oogopslag duidelijk welke gegevensgroepen en kenmerken (elementen, items) in het voorgaande overzicht een rol spelen. Daartoe is de informatiebehoefte te weinig gestructureerd. We zullen het een en ander moeten uitsplitsen. We maken daarbij gebruik van de techniek van het normaliseren, ontwikkeld door E.F.Codd. We zullen in vier stappen proberen te komen tot gestructureerde gegevensgroepen, die onderling geen afhankelijkheid vertonen. De stappen zijn nulde-, eerste-, tweede- en derde normaalvorm. (In de literatuur wordt nog een aantal extra stappen genoemd, deze vallen echter buiten het bestek van dit hoofdstuk.) De eerste stap is het bepalen van de nulde normaalvorm. Hierin bepalen we welke gegevens uit de informatiebehoefte werkelijk nodig zijn. Het blijkt dat niet alle gegevens uit de informatiebehoefte vastgelegd moet worden. Voordat we hiermee beginnen dient eerst de informatiebehoefte geanalyseerd te worden. Door gesprekken met gebruikers en het management kan noodzakelijke informatie ingewonnen worden. Binnen de ICT wordt deze analyse veelal uitgevoerd door informatieanalisten. In ons voorbeeld zijn de volgende punten uit de analyse gekomen: bij Factuurcode staat het factuurnummer en de code van de verkoper die de order heeft afgehandeld; op een factuur kan het artikelnummer slechts één keer voorkomen; de korting is een bedrag dat overeengekomen is met de verkoper. Kortingen worden altijd op deze manier vastgelegd; BTW percentage is voor alle artikelen gelijk. Binnen de nulde normaalvorm zijn vijf soorten gegevens te onderscheiden. Elementaire gegevens, constante gegevens, procesgegeven, samengestelde gegevens en groepen gegevens die repeteren; meerdere keren een waarde kunnen aannemen. V Elementaire gegevens: Alle gegevens van de normalisatie moeten enkelvoudig (elementair) zijn. Gegevens die niet verder te verkleinen zijn, ook wel atomair genoemd. In figuur 1.5 zijn dit bijvoorbeeld datum, klantnaam en adres. V Constante gegevens: Gegevens die op iedere factuur in ons voorbeeld hetzelfde zijn. Gegevens die niet aan veranderingen onderhevig zijn. We doelen hiermee op de gegevens van de groothandel zelf (naam en adresgegevens) en het BTW-percentage. Deze gegevens kunnen in de loop van de tijd uiteraard veranderen, maar gedurende een bepaalde periode mogen we ze als constanten beschouwen. Het is zelfs mogelijk deze gegevens vooraf op de facturen te drukken. Gegevens van dit type nemen we niet op in de lijst met benodigde gegevens. Deze constanten worden vaak in een apart bestand (tabel) opgenomen, zodat de gebruiker wel in staat is wijzigingen aan te brengen. V Procesgegevens: Dit zijn gegevens uit de informatiebehoefte die op eenvoudige wijze berekend kunnen worden uit andere gegevens. We onderkennen in het voorbeeld de procesgegevens Bedrag, Subtotaal, BTWtotaal, BTW en TOTAAL. Als u die gegevens niet hebt, zijn we toch in staat die met de overige gegevens te bepalen. Merk op dat Korting geen procesgegeven is. Het is een afgesproken bedrag met de verkoper, dat ook een ander bedrag had kunnen zijn. Ook de procesgegevens nemen we niet op in de lijst met benodigde gegevens. V Samengestelde gegevens: Gegevens die uit meerdere kenmerken bestaan. Het gegeven Factuurcode is een samengesteld gegeven omdat het bestaat uit het factuurnummer, gevolgd door de initialen van de verkoper. We splitsen de factuurcode dus in 9

19 Aan de slag met databases en Access 2013 twee elementaire gegevens, te weten factuurnr en verkopercode. Het gegeven Postc/ plaats is eveneens een samengesteld gegeven. We splitsen dat in postcode en plaats. De zo verkregen gegevens nemen we op in de lijst. V Repeterende groep gegevens: Indien waarden van kenmerken meerdere keren voorkomen op de informatiebehoefte, noemen we dat een repeterende groep (repeating group RG). In ons voorbeeld komen zowel de waarden van artikelnr (DVDREC3 en KTV06-M), omschrijving, aantal en prijs twee keer voor. Er zijn immers twee verschillende artikelen op de factuur. Op het moment dat op deze factuur nog een derde artikel wordt verkocht, worden de waarden opnieuw ingevuld. Dat groepje hoort dus bij elkaar. Voor iedere nieuwe regel wordt dit groepje gegevens ingevuld. Alle andere gegevens op de factuur hebben slechts één waarde, zoals factuurnummer (030458), verkopercode, datum, etc. Indien op een factuur slechts één artikel wordt verkocht staat voor artikelnummer, omschrijving, aantal en prijs ook maar één waarde ingevuld, maar het moet gelden voor alle facturen. Dus, als op één informatiebehoefte een bepaald kenmerk meerdere waarden kan bezitten, dan behoort dat kenmerk tot een repeterende groep. Ook al is het maar één kenmerk waarvoor dat geldt (kleinst mogelijke groep). Bedrag behoort ook tot de groep, maar wordt niet opgenomen aangezien het een procesgegeven is. We kunnen nu de lijst met benodigde gegevens (kenmerken) gaan opstellen. Deze lijst wordt onze eerste gegevensgroep. Voor iedere factuur moeten deze kenmerken worden vastgelegd. Voor de lijst met gegevens hanteren we de volgende notatiewijze, waarin de repeterende groep (RG) apart is aangegeven: (factuurnr, datum, verkopercode, klant, adres, postcode, plaats, telefoon, RG(artikelnr, omschrijving, aantal, prijs), korting) 10 Alle gegevens op deze lijst noemen we elementaire gegevens. Het zijn alle (elementaire) kenmerken die we moeten bijhouden van ieder afzonderlijke factuur. De gegevensgroep kunnen we al van een naam voorzien, bijvoorbeeld FACTUUR. We laten dit nog even achterwege. We willen passende namen voor onze gegevensgroepen hebben en dat is beter te bepalen nadat alle gegevensgroepen van onze factuur zijn bepaald. Ten slotte moeten we uit de lijst met kenmerken de sleutel kiezen van deze gegevensgroep. De gegevensgroep is een beschrijving voor alle facturen van de onderneming. Het is in dit voorbeeld eenvoudig te zien dat factuurnr het sleutelkenmerk is. Indien dit niet duidelijk te zien is, ga dan als volgt te werk. Stel u hebt alle facturen (pakbonnen, containerlaadlijsten, crediteurenlijsten, etc.) fysiek voor u. Met welk kenmerk (of kenmerken) op de facturen (pakbonnen, containerlaadlijsten, crediteurenlijsten, etc.) is precies één exemplaar te selecteren? Dat kenmerk of kenmerken is de sleutel. Ook als u meerdere kenmerken hebt, noem u dat de sleutel van de gegevensgroep (niet sleutels). Soms hebben we daarbij de vrijheid te kiezen uit meer kandidaten, we noemen dat kandidaat-sleutels. Een voorbeeld hiervan is het studentnummer zoals gebruikt op een instituut en het nummer waaronder de student staat ingeschreven bij de IB-groep in Groningen. In ons voorbeeld hebben we echter geen vrijheid. Alleen het kenmerk factuurnr komt in aanmerking als sleutel. Van alle andere kenmerken zijn de waarden over alle facturen immers niet uniek, alle waarden kunnen meer dan één keer voorkomen. Klanten kunnen meerdere keren bestellen, desgewenst op dezelfde dag, dus ook klant en datum samen is geen kandidaat-sleutel. De kenmerken die in aanmerking komen als

20 Hoofdstuk 1 Normaliseren sleutelkenmerk zijn de kenmerken die niet in de repeterende groep voorkomen. In de gevonden lijst is het de gewoonte de sleutel als eerste op te nemen en te onderstrepen. De op deze manier gevonden lijst staat in de nulde normaalvorm, kortweg 0NV. 0NV (factuurnr, datum, verkopercode, klant, adres, postcode, plaats, telefoon, RG(artikelnr, omschrijving, aantal, prijs), korting) Opmerking In de literatuur wordt de nulde normaalvorm ook wel op een andere wijze opgesteld. Daarbij neemt men de proces- en samengestelde gegevens ook op. Tevens laat men het bepalen van de sleutel (nog) achterwege. Het verwijderen van de proces- en samengestelde gegevens, alsmede het bepalen van de sleutel, vindt dan plaats tijdens het opstellen van de volgende normaalvorm. Er is voor de bovenstaande notatiewijze gekozen omdat deze manier van werken, naar mijn mening, beter aansluit bij de betekenis van de diverse normaalvormen. Er is een filmpje over dit onderwerp beschikbaar: 1-1 Normaliseren 0NV. Maak opgave 1.1 (paragraaf 1.15) tot en met 0NV. 1.5 Normaliseren, eerste normaalvorm De volgende stap het bepalen van de eerste normaalvorm is het verwijderen van de repeterende groep(en) uit de 0NV gegevensgroep. Hiervan wordt een nieuwe gegevensgroep gemaakt. Vervolgens wordt het sleutelkenmerk uit 0NV gekopieerd in de nieuwe gegevensgroep en als laatste wordt de sleutel bepaald in de nieuwe groep. Deze drie deelstappen gaan we toelichten. Stap 1 Verwijder de repeterende groep(en) en maak daarvan (een) nieuwe gegevensgroep(en). In ons voorbeeld krijgen we dan: (factuurnr, datum, verkopercode, klant, adres, postcode, plaats, telefoon, korting) (artikelnr, omschrijving, aantal, prijs) We hebben nu twee gegevensgroepen gekregen. De oorspronkelijke (zonder de repeterende groep) en de repeterende groep zelf. Stap 2 Voeg aan de nieuwe groep(en) het sleutelkenmerk uit de nulde normaalvorm toe; factuurnr dus. (factuurnr, datum, verkopercode, klant, adres, postcode, plaats, telefoon, korting) (factuurnr, artikelnr, omschrijving, aantal, prijs) 11

21 Aan de slag met databases en Access 2013 In die nieuwe gegevensgroep worden alle factuurregels van alle facturen geregistreerd. De factuurgegevens en de factuurregels zijn nu in twee groepen verdeeld. Door het toevoegen van het factuurnr in de nieuwe groep is te bepalen welke factuurregels bij welke factuur hoort. Merk op dat factuurnr in de nieuwe groep niet onderstreept is in stap 2. Het sleutelkenmerk wordt gekopieerd in de nieuwe groep, maar dat wil niet zeggen dat het tot de sleutel behoort in de nieuwe groep. Het bepalen van de sleutel vindt plaats in stap 3. Stap 3 Bepaal de sleutel van de nieuwe gegevensgroep. In deze stap treden de meeste fouten op. De gegevens van de factuurregels van alle facturen staan in deze nieuwe gegevensgroep, zie figuur 1.6. Factuurnr Artikelnr Omschrijving Aantal Prijs , DVDREC3 DVDRecorder Arphilips 2 625, KTV06-M Kleuren TV ANOY , HDREC163 HDRecorder Sany 5 293, KTV47-LCD Kleuren TV Panavisie , DVDREC3 DVDRecorder Arphilips 3 625, MP4-134A MP4 speler CVJ 8 39, ,.. Figuur 1.6 In deze groep komt het factuurnummer , uit ons voorbeeld, bij beide verkochte artikelen voor. Bij iedere regel wordt dus ook het factuurnummer genoteerd. Hierdoor kan factuurnr niet de sleutel zijn. Het is immers in deze gegevensgroep niet uniek. Ook artikelnummer kan niet de sleutel zijn. Het artikelnr DVDREC3 komt in figuur 1.6 al twee keer voor en is dus niet uniek. De combinatie factuurnummer en artikelnummer is wel uniek. In ons voorbeeld komt immers maar één keer het artikelnummer voor op een factuur, zoals bepaald in de informatiebehoefte. We spreken van een meervoudige- of samengestelde sleutel. We krijgen nu als eerste normaalvorm (1NV). 1NV (factuurnr, datum, verkopercode, klant, adres, postcode, plaats, telefoon, korting) (factuurnr, artikelnr, omschrijving, aantal, prijs) We merken op dat factuurnr in de oorspronkelijke groep de sleutel is en dat die in de nieuwe groep ook onderdeel is van de sleutel. Dat is niet altijd zo. Stel dat de artikelnummers wel meerdere keren op een factuur noodzakelijk zijn. Een keer voor een prijs van 100,00 euro en voor een prijs van 75,00 euro, in verband met een kleine beschadiging. U dient dan een dummy kenmerk toe te voegen, bijvoorbeeld regelnummer. Als dit een doorlopend regelnummer is voor alle facturen, is alleen regelnummer de sleutel! Het kenmerk factuurnr blijft wel bestaan, anders is er geen koppeling meer naar de eerste gegevensgroep. 12

22 Hoofdstuk 1 Normaliseren Tip Er is een filmpje over dit onderwerp beschikbaar: 1-2 Normaliseren 1NV. Het bepalen van de sleutel in de eerste normaalvorm is lastig. In stap 3 wordt in het voorbeeld gevraagd: wat is de sleutel van gegevensgroep (factuurnr, artikelnr, omschrijving, aantal, prijs)? Een hulpmiddel is deze gegevens voor te stellen als kolomkoppen in Excel. Daaronder staan dan de gegevens, zie figuur 1.6. Excel wordt hierbij denkbeeldig gebruikt en heeft niets te maken met een database. Het is alleen bedoeld als hulpmiddel voor het bepalen van de sleutel in de eerste normaalvorm. Nu moet je een filter gaan bepalen, zodanig dat altijd slechts één regel met gegevens wordt getoond. Als een filter wordt geplaatst op alleen factuurnr, worden bij al twee regels getoond en het moet altijd één regel zijn. Dus factuurnr als sleutel valt af. Zou gefilterd zijn op , dan is wel één regel zichtbaar, maar het moet gelden voor alle factuurnummers. Filteren op alleen artikelnr levert niet voor alle artikelnummers één regel op. Dat treedt alleen op als een artikel door slechts één klant is gekocht. Een filter op factuurnr en artikelnr samen levert wel altijd één regel, omdat is vastgelegd dat op een factuur maar één keer het artikel mag voorkomen. Factuurnr en artikelnr samen vormen dan de sleutel van deze gegevensgroep. Merk nog op dat indien alle omschrijvingen van de artikelen verschillend zouden zijn, ook factuurnr en omschrijving samen een kandidaat-sleutel zijn. Maar daarvoor wordt niet gekozen. Een vuistregel is omschrijvingen en namen niet als sleutelkenmerk te gebruiken, zie ook paragraaf Maak opgave 1.1 (paragraaf 1.15) tot en met 1NV. 1.6 Normaliseren, tweede normaalvorm Vanuit de eerste normaalvorm kunnen we de volgende stap gaan zetten. De tweede normaalvorm moet nu worden opgesteld. Om de tweede normaalvorm te bereiken, dienen we alle kenmerken te verwijderen die functioneel afhankelijk zijn van slechts een deel van de sleutel. Daarbij geldt dat kenmerk A functioneel afhankelijk is van kenmerk B, als bij iedere waarde van B precies één waarde van A hoort. De kenmerken die functioneel afhankelijk zijn vormen een nieuwe gegevensgroep. Dit verdient enige toelichting. In de eerste gegevensgroep uit 1NV zijn alle kenmerken functioneel afhankelijk van het sleutelkenmerk factuurnr. Als u een willekeurig factuurnummer neemt, dan hoort daar precies één datum, verkopercode, klant, adres, postcode, plaats, telefoon en korting bij. Dat geldt voor alle factuurnummers. Indien u bijvoorbeeld factuurnummer neemt, krijgt u de benoemde gegevens zoals in figuur 1.5 te zien. Uiteraard geldt dit niet andersom, want bij één datum kunnen 10-tallen factuurnummers horen. Bij gegevensgroepen met een enkelvoudig sleutelkenmerk is dat altijd zo. Bij de tweede normaalvorm is het dus niet nodig die gegevensgroepen te onderzoeken. Ze zullen geen nieuwe gegevensgroepen opleveren. We dienen dus alleen gegevensgroepen met een meervoudige sleutel (samengestelde sleutel) te onderzoeken. Indien u in 1NV alleen gegevensgroepen 13

23 Aan de slag met databases en Access 2013 hebt met een enkelvoudige sleutel, hoeft u verder niets te ondernemen in 2NV. Er geldt dan: 2NV = 1NV. Onze tweede gegevensgroep heeft een meervoudige sleutel. We moeten nu onderzoeken of er niet-sleutelkenmerken zijn (omschrijving, aantal, prijs) die functioneel afhankelijk zijn van een deel van de sleutelkenmerken, dat wil zeggen met alleen factuurnummer of artikelnummer. Met andere woorden, als u een willekeurig factuurnummer hebt, hoort daar dan altijd precies één omschrijving, aantal of prijs bij? Nee, bij één factuurnummer kunnen meerdere omschrijvingen, aantallen en prijzen horen, zie bijvoorbeeld figuur 1.6. Tussen factuurnr en de niet-sleutelkenmerken is geen functionele afhankelijkheid. Nu hetzelfde met artikelnummer. Als u een willekeurig artikelnummer hebt, hoort daar dan altijd precies één omschrijving, aantal of prijs bij? Een artikelnummer heeft altijd één omschrijving (afhankelijkheid!), maar meerdere aantallen (geen afhankelijkheid). Op de ene factuur verkoop u van hetzelfde artikel 3 stuks en op een andere factuur 2 stuks. Heeft een artikelnummer over alle facturen altijd één prijs? Nee (geen afhankelijkheid), prijzen kunnen immers in de tijd veranderen. Bij het aanbrengen van een prijswijziging mogen de prijzen bij eerder aangemaakte (en afgedrukte) facturen niet worden veranderd. Bovendien kan het voorkomen dat bij een artikel een afwijkende prijs wordt genoteerd, bijvoorbeeld als het artikel is beschadigd. Wel heeft een artikel (meestal) een adviesverkoopprijs. Als dat bestaat in de gegevensgroep, heeft ieder artikelnummer altijd precies één adviesverkoopprijs (afhankelijkheid!). Ook als de adviesverkoopprijs wordt verhoogd, heeft het artikelnummer nog steeds precies één adviesverkoopprijs (de nieuwe). Omschrijving en adviesverkoopprijs (extra toegevoegd) zijn dus functioneel afhankelijk van artikelnummer. Anders, een artikelnummer heeft altijd één omschrijving en één adviesverkoopprijs. De kenmerken die functioneel afhankelijk zijn van een deel van de sleutel (artikelnummer) nemen we op in een nieuwe gegevensgroep en verwijderen we uit de oorspronkelijke gegevensgroep. In die groep wordt het deel-sleutelkenmerk de sleutel. We krijgen dus een nieuwe gegevensgroep met artikelnummer als sleutel en de kenmerken omschrijving en adviesverkoopprijs. Zo ontstaat de tweede normaalvorm (2NV). 2NV (factuurnr, datum, verkopercode, klant, adres, postcode, plaats, telefoon, korting) (factuurnr, artikelnr, aantal, prijs) (artikelnr, omschrijving, adviesverkoopprijs) Merk op dat artikelnr uit de tweede gegevensgroep niet verwijderd is. Er zou anders geen koppeling meer zijn naar de derde gegevensgroep. In de eerste gegevensgroep staan de basisgegevens van de factuur. Via het factuurnummer in de eerste groep zijn in de tweede groep de bijbehorende artikelen te bepalen, inclusief het aantal dat besteld is en de betaalde prijs. Via het artikelnummer uit de tweede gegevensgroep valt in de derde gegevensgroep de omschrijving van het artikel en de adviesprijs te bepalen. 14