Database ontwikkeling

Nut en noodzaak van mormalisatie

Voordat je een database maakt moet je er heel goed over nadenken.
Databases gaan vaak langer mee dan hun makers.
Als je in het ontwerpstadium 10 minuten te kort nadenkt heb je daar jaren last van.
Beter een dag langer denken dan overhaast handelen!

Voordat je achter een computer kruipt moet je op papier al een aantal zaken duidelijk hebben.
Dit zijn de eerste opdrachten van het project (geen toeval)

Een beschrijving van wat je wilt. (PVA met daarin doelstelling en resultaat, activiteiten en producten, testcriteria kortom SDM) en hoe je dat in een DataBase wilt zetten.

SDM

Na de analyse moet men voor een bepaalde oplossing kiezen. In deze fase wordt voor die
oplossing het ontwerp opgesteld. Allereerst moet een functionele beschrijving van het te bouwen systeem worden gegeven ofwel WAT het systeem moet doen. We noemen dit een functioneel ontwerp. Op de tweede plaats kan dan worden aangegeven HOE het systeem moet werken om die functies uit te voeren. Hiervoor wordt een technisch ontwerp gemaakt. Iedereen die bij het project betrokken is zal achter deze specificaties moeten staan: op grond hiervan zal het systeem worden gebouwd. Voor elke fase wordt een PVA gemaakt met toetsbare mijlpalen. Zie voor meer details de cursus SDM op Moodle.

DataBases zijn ingericht als verzameling van tabellen.
Tabellen zijn 2 dimensionaal, ze bestaan uit kolomen en rijen.
Bovendien zijn er in relationele DataBases ook nog speciale tabellen met de relaties.

Tabellen openen kost tijd dus moet je het aantal tabellen beperken tot een optimaal minimum. Verder moet je ervoor zorgen dat gegevens niet in meerdere tabellen zitten, dit kost onnodig veel ruimte, bovendien is het nooit zeker dat alle tabellen tegelijk veranderd worden.

Elke rij moet een sleutelveld hebben, dit is een veld waarop de rij het beste benaderd kan worden, vaak een (index)nummer in de eerste kolom.

In ons geval hebben we te maken met een schoolomgeving voor leerling en eigen personeel. Deze schoolomgeving is afgeschermd voor buitenstaanders, er moet dus een register met gebruikers zijn die kunnen inloggen. Leerlingen zien alleen hun eigen gegevens maar kunnen die niet veranderen.

Ten minste moet er een tabel met leerlinggegevens zijn.
Een ID-nummer
Naam (3 delen?) meisjesnaam?
Adres (2 delen?)
Postcode
Plaats
Telefoon
Mobiel
Geboortedatum
Geslacht
Jaar van instroom, profiel
e-mail
2^e thuis adres mailing (gescheiden ouders)
status (leerling, personeel, beheer)
Je zou kunnen besluiten om de voortgang (cijfers etc ook hier te registreren)
Ook pasfoto’s worden weleens gebruikt.

Je kunt ervoor kiezen om de cijfers en voortgang in een eigen tabel te zetten met als index het ID-nummer en dan per kolom de resultaten (denk dan ook aan mogelijkheden voor herkansing, datum behaald etc.)

Als je alles op een rijtje hebt, kun je een schatting gaan maken van de omvang en aard van de velden die je moet aanmaken.
Natuurlijk kun je alles in een blob kwijt, maar dat kost erg veel ruimte, beter is het om de kleinst mogelijke vorm van een bepaald type te kiezen, door het juiste type te kiezen bewaak je ook de invoer, als je letters in een nummeriek veld wilt stoppen krijg je een foutmelding.

De ontwikkelling van DataBases is in de loop van de tijd genormaliseerd:

Database normaliseren
De regels voor goed relationeel database-ontwerp zijn samengevat in 5 'normaalvormen', waarbij de eerste normaalvorm de laagste en de vijfde de hoogste (meest genormaliseerd) is. Deze normaalvormen zijn richtlijnen voor het juist ontwerpen van een relationele database.
Normaliseren heeft een aantal doelen.

Flexibiliteit. De genormaliseerde structuur van de database zorgt ervoor dat gegevens op veel verschillende manieren opgevraagd en bijgewerkt kunnen worden.
Integriteit. In een genormaliseerde database ben je gegevens zeer betrouwbaar opslaan.
In een genormaliseerde database worden gegevens maar op 1 plek opgeslagen. Als je data wil invoeren, aanpassen of verwijderen hoef je dat dus maar op 1 plek te doen.

Het normaliseren van een database komt eigenlijk neer op het nastreven van de volgende zaken en die zijn met een beetje oefening en puzzelen vaak redelijk gemakkelijk te realiseren.

• Het verdelen van gegevens in logische samenhangende groepen.
• Het minimaliseren van de hoeveelheid data die dubbel opgeslagen is, ofwel het voorkomen van 'redundancy'.
• De gegevens zo organiseren dat het aanpassen of verwijderen van een gegeven altijd maar op één pek hoeft te gebeuren.
• Gegevens zo organiseren dat ze snel en efficiënt op te vragen zijn.

Tabellen en de primaire sleutel
Een relationele database bestaat uit tabellen. In deze tabellen zijn gegevens van dezelfde soort in rijen of in vaktaal records opgeslagen.

Hoe kun je in een tabel een klant selecteren? Je zou kunnen zoeken op de voornaam. Dat is geen goed idee, want naarmate het aantal klanten in de tabel groeit wordt de kans groter dat er nog een klant komt die Jan heet en dan kun je niet meer met zekerheid de juiste Jan selecteren. Je zou kunnen zoeken op een combinatie, bijvoorbeeld de voornaam en achternaam. Maar hoe lang zou het duren voordat zich een tweede Jan Jansen aanmeldt als klant?

Om klanten uniek te kunnen identificeren moet elke klant gekoppeld zijn aan een uniek stukje informatie, bijvoorbeeld een klantnummer. Deze unieke informatie wordt de primaire sleutel (primary key) genoemd. Een van de belangrijkste regels van het relationeel model is dat alle rijen in een tabel uniek te identificeren zijn door middel van de primaire sleutel.
De wet van Codd; "De sleutel, de hele sleutel, en niets dan de sleutel, zo waarlijk helpe mij Codd".

Er zijn tal van voorbeelden te bedenken van nummers en codes uit het dagelijks leven die waarschijnlijk dienen als primaire sleutel in een database.

Bestelnummer
Rekeningnummer
Sofinummer
Factuurnummer
Klantnummer
Productnummer (al dan niet in streepjescode)

Wat hebben al deze codes gemeen?
Ze zijn allemaal uniek. Jouw rekeningnummer bestaat altijd maar één keer, net als een factuurnummer, je sofinummer, etc.
Ze werken allemaal als toegangsweg naar meer informatie. Aan een factuurnummer is een datum, een bedrag, etc. gekoppeld. Aan een productnummer kan een productbeschrijving, een plaatje, etc. gekoppeld zijn.
De primaire sleutel wordt dus gebruikt om rijen in tabellen uniek te identificeren en om gegevens in verschillende tabellen aan elkaar te koppelen. Primaire sleutels zijn zoals gezegd altijd uniek en mogen daarom maar 1 keer voorkomen in de kolom.

Geef je aan dat het nummer in een bepaalde kolom de primaire sleutel is, dan zal het databasesysteem er (voor zover ik weet altijd) automatisch voor zorgen dat de nummers in die kolom uniek zijn.

De eerste normaalvorm (1NF)
De eerste normaalvorm is een set basale ontwerpregels die op elke database van toepassing moeten zijn. Een tabel is de representatie van een 'object' uit het systeem dat je maakt. Bijvoorbeeld bestellingen, klanten, lessen, producten, etc. Elke rij in de tabel is een uniek exemplaar van dat 'object'. Een rij vertegenwoordigt bijvoorbeeld 1 bestelling, 1 klant, 1 cursus, 1 bestelling, etc.

Elke tabel heeft een primaire sleutel: een zo klein mogelijk aantal velden dat een rij (record) uniek identificeert.
Atomiciteit: elk veld bevat maar één waarde. Een adres bijvoorbeeld hoor je op te slaan in aparte velden voor de straatnaam, het huisnummer en de huisnummerextensie.
De volgorde van de rijen in de tabel is onbelangrijk (als je wil weten in welke volgorde bestellingen zijn binnengekomen moet je hiervoor een datum en tijd veld maken. Hiervoor de rijvolgorde in de database gebruiken is niet de bedoeling)

De tweede normaalvorm (2NF)
De tweede normaalvorm: het verwijderen van redundante gegevens

De database voldoet aan alle regels van de eerste normaalvorm.
Zo min mogelijk gegevens worden dubbel opgeslagen in de database.
De velden die geen primaire sleutel zijn, zijn afhankelijk van de primaire sleutel.
Je moet bij de tweede normaalvorm je tabellen goed inspecteren op gegevens die dubbel opgeslagen worden in een kolom. Gegevens die dubbel opgeslagen worden komen in aanmerking voor afsplitsing in een aparte tabel.

Merk overigens op dat er altijd wel een beetje herhaling van gegevens is. Het leerlingnummer bijvoorbeeld wordt steeds dubbel opgeslagen, maar dat is een herhaling die niet te voorkomen is. We willen immers wel dat elk behaalde cijfer ook aan een leerling gekoppeld is.

De derde normaalvorm (3NF)
De derde normaalvorm: transitieve afhankelijkheden, een moeilijke term voor iets vrij eenvoudigs.

De database voldoet aan alle regels van de tweede normaalvorm.
Van een tabel die voldoet aan de derde normaalvorm zijn alle velden die geen primaire sleutel zijn uitsluitend afhankelijk van de primaire sleutel.

In een eenvoudige adressen tabel zijn niet alle gegevens uitsluitend afhankelijk van de primaire sleutel. Er zijn nog andere relaties tussen de gegevens in een record: uit de postcode is de plaatsnaam en de provincie af te leiden. Er bestaat een 'transitieve relatie' tussen deze gegevens.

Welnu, afsplitsen is zeker mogelijk en wordt in de praktijk ook weleens gedaan. Je kunt in de klantentabel voor elke klant alleen de (eerste 4 cijfers van de) postcode opslaan en de bijhorende gegevens (provincie, plaatsnaam) in een aparte tabel stoppen. Deze aparte postcode-plaatsnaam-provincie tabel kun je kopen.

In een prijstabel bijvoorbeeld is relatie tussen het totaalbedrag exclusief BTW en het totaalbedrag inclusief BTW duidelijk. Het bedrag inclusief BTW is altijd 19% hoger dan het bedrag exclusief BTW. De waardes van de twee prijskolommen zijn uit elkaar af te leiden. In dit geval zou je één van de twee kolommen moeten verwijderen. Het omrekenen tussen exclusief en inclusief BTW laat je over aan het programma dat van de database gebruik maakt. Kort gezegd: je hoort nooit gegevens op te slaan die af te leiden zijn uit andere gegevens in de tabel. In de praktijk wordt zeker bij kleinere applicaties de derde normaalvorm niet altijd toegepast.

Er bestaan ook nog hogere normaalvormen, maar die zijn voor de echte puristen.

We gaan een database ontwerpen die de resultaten van leerlingen bijhoudt voor diplomering en mentoren/opleidingscoördinatoren.

We hebben een database nodig met daarin:
Persoonsgegevens van leerlingen
Schoolgegevens van leerlingen (profiel, niveau)
gegevens van vakken/projecten (hoeveel toetsen welk leerjaar etc.)
gegevens van competenties (lijst met competenties en toetsingscriteria)
gegevens van ziek, te laat verwijderd en afwezig (data/uren)
gegevens van toegestane afwezigheid (verlof, telaatpas, uitloop toetsen dyslexie)
negatieve studieadvies of pitstraat trajecten
BPV registratie uren en resultaat.
Mentoren, verantwoordelijke vak docenten
Alternatieve opdrachten die als vervanging dienen van vakken/projecten/BPV
gegevens van toetsresultaten (cijfers of OVG, inclusief herkansingen, finale herkansingen)
gegevens van competentieontwikkeling (BGE, ontwikkellijnen)

Voor de implementatie moet er worden beschreven hoe we aan die gegevens komen, wie er verantwoordelijk is voor de integriteit en updating en het geheel. Waaruit die verantwoordelijkheden bestaan (bijvoorbeeld het tijdstip waarop absentie wordt vastgesteld, hoe lang het duurt voor een adreswijziging is doorgevoerd etc.)

We maken de database in MySQL met als basis onze klas en gegevens van bijvoorbeeld actie, presentielijsten, document coaching PDR, etc.

Een diplomeringscriteria query moet aantonen of de database werkt en of die ook te gebruiken is als tussentijdse rapportage. In percentage van het eindniveau afgezet tegen de tijd.

Opdracht 1 inleveren les 1.
Maak een samenvatting van dit document en de onderliggende (in dit geval SDM, coaching PDR, AcTIE, presentielijst)
Schrijf op wat niet duidelijk is en zoek dat uit (teamgenoot, Google, Goudappel)
Maak een plan van aanpak voor het hele project. Er wordt wel samengewerkt in het verzamelen van informatie maar de rapportage is individueel (dus niet sharen, anders share ik het cijfer!)
Maak een plan van aanpak met mijlpalen voor de informatieanalyse.

Opdracht 2 Voer het PVA informatieanalyse uit, inleveren volgens planning.

Opdracht 3 Maak een PVA met mijlpalen voor de definitiestudie en voer die uit, inleveren volgens planning.
Opdracht 4 Maak een PVA met mijlpalen voor het functioneel ontwerp en voer die uit, inleveren volgens planning.
Opdracht 5 Maak een PVA met mijlpalen voor het technisch ontwerp en voer die uit, inleveren volgens planning.
Opdracht 6 Maak een PVA met mijlpalen voor de realisatie en voer die uit, inleveren volgens planning.
Maak het verhaal verder zelf af en kleur de plaatjes……