1 Gegevens en betrouwbaarheid
Wat moet je kunnen?
- Gegevensgerelateerde begrippen zoals ‘entiteit’ en attribuut kunnen definiëren
- Opslaggerelateerde begrippen zoals ‘veld’, ‘record”, ‘tabel’ en sleutel kunnen definiëren
- De vier basisbewerkingen kunnen opnoemen die op opgeslagen gegevens kunnen worden uitgevoerd.
- Kunnen beschrijven waarvoor een index wordt gebruikt
- De begrippen redundantie en consistentie kunnen verklaren.
- Het principe van een database kunnen uitleggen.
- Normalisatiestappen kunnen toepassen.
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, internetten, werkstukken maken met behulp van Word, multimediapresentaties maken…
Bedrijven en instellingen kunnen zonder computers niet meer functioneren. Alle gegevens voor de bedrijfsvoering wordt opgeslagen op computer (klantgegevens, productgegevens, bestellingen,…).
De begrippen gegevens en informatie worden nogal eens door elkaar gehaald. We geven enkele voorbeelden van gegevens:
Jan Jansen
8,9,5,7
We noemen dit gegevens of data. De betekenis van deze gegevens is dat Jan Jansen een leerling is die voor het vak informatica respectievelijk 8, 9, 5 en 7 op 10 haalde voor testen.
Als we het gemiddelde berekenen van de 4 behaalde testen dan is dit gemiddelde 7,25. Dit gemiddelde noemen we informatie die we halen uit gegevens.
Informatie is dus het resultaat van gegevens die verwerkt zijn.
1.2 Integriteit
Gegevens in computersystemen moeten zo worden opgeslagen dat ze eenvoudig zijn op te vragen en dat ze eenvoudig kunnen gemuteerd worden. Onder muteren verstaan we toevoegen, verwijderen en wijzigen van gegevens.
De opgeslagen gegevens mogen geen fouten of onduidelijkheden bevatten. We noemen dit de integriteit van het computersysteem. Hiermee bedoelen we dat de gegevens van in het computersysteem een juiste weergave moeten zijn van de werkelijkheid. Bijvoorbeeld als de computer toont dat het banksaldo 120 euro in het rood is, terwijl het zwart moet zijn, is er duidelijk iets mis. Het computersysteem geeft dan niet de werkelijkheid weer, de integriteit van het computersysteem voldoet niet.
1.3 Gegevensgerelateerde begrippen
Aangezien een school gegevens nodig heeft van de studenten, hebben we een verzameling van feiten nodig over deze studenten. Onderstaande figuur geeft een deel van de verzameling weer.
| Studentnummer | Naam | Voornaam | Geboortejaar |
|---|---|---|---|
| 10025 | Vanopstal | Erik | 1985 |
| 10026 | Peters | Jan | 1986 |
| 10027 | Martens | Ronny | 1984 |
| 10028 | Vankerkhove | Tom | 1985 |
Deze verzameling geeft een overzicht van de studenten weer. Student is dus het ding, het onderwerp van deze verzameling dat we willen volgen. Dat specifieke ding wordt entiteit genoemd. We spreken over de entiteit student.
Een attribuut is een eigenschap of een kenmerk van een entiteit. Studentnummer, naam, voornaam en geboortejaar zijn allen attributen van de entiteit student.
1.4 Opslaggerelateerde begrippen
Met de structuur van de bovenstaande figuur kunnen we nu enkele standaardbegrippen definiëren. Elke rij in bovenstaande figuur beschri jft één enkele entiteit. Elke rij in zo’n structuur heet een record. De kolommen die de verschillende attributen voorstellen worden ook velden genoemd. De hele structuur noemen we een tabel.
Het veld studentnummer is verschillend van de andere velden in die mate dat dit veld steeds een verschillende waarde bevat. Elke student zal een uniek studentnummer hebben. We kunnen het studentnummer dus gebruiken om verschillende studenten uit elkaar te houden. Het veld studentnummer kan dus worden beschouwd als het sleutelveld of kortweg sleutel van de tabel.
1.5 De vier basisbewerkingen
Op gegevens die opgeslagen zijn zoals in een tabel, kunnen we vier basisbewerkingen doen. Elk van deze bewerkingen wordt steeds op één record tegelijk toegepast. Deze vier basisbewerkingen zijn:
-
Ophalen en lezen: het kijken naar de inhoud van een record zonder de inhoud ervan te
-
Invoegen: het toevoegen vaan een nieuwe student in de tabel.
-
Verwijderen: wanneer een student de school verlaat kan hij uit de tabel verwijderd
-
Bewerken: wanneer gegevens van de student gewijzigd moeten worden.
1.6 Bestandsorganisatie
1.6.1 Het doel: een record vinden
Veronderstel dat je één record nodig hebt en dat je de waarde van zijn sleutel kent. De vraag is dan, hoe weet de harddisk waar het record op de schijf staat. We moeten voorkomen dat de hele tabel moet ingelezen worden totdat we aan het bewuste record komen. Dit brengt ons bij de bestandsorganisatie, de manier hoe we gegevens opslaan om ze later terug te kunnen ophalen. Vanuit de bestandsorganisatie bezien, kunnen we een index gebruiken om directe toegang te verwezenlijken.
1.6.2 De index
De index is een hulpmiddel dat gebruikt wordt door een tabel om de directe toegang tot gegevens te verbeteren. We kunnen een index vergelijken met deze van een boek. Achteraan in een boek staat een alfabetische lijst van onderwerpen met daarachter een paginanummer. Bij de index van een tabel gaat het precies zo. Er wordt een gerangschikte lijst gemaakt, waarbij ieder item in de lijst een ‘pointer’ bevat. Deze ‘pointer’ verwijst naar het specifieke record, zoals het paginanummer ook een verwijzing is.
1.7 Het databasemanagementsysteem
1.7.1 Het probleem toen er geen databases bestonden
Voordat er databases waren, werden alle gegevens in informatiesystemen opgeslagen in eenvoudige lineaire bestanden ( bijvoorbeeld tekstbestanden). In het algemeen werden bestanden voor één toepassing gemaakt en werden ze ook effectief maar voor die ene toepassing gebruikt. Bestanden en gegevens werden daarom niet gedeeld door toepassingen, zodat dezelfde gegevens vaak in meerdere bestanden voorkwamen, dit noemen we gegevensredundantie, kortweg redundantie.
We bekijken even het onderstaande voorbeeld. We veronderstellen dat de onderstaande gegevens in twee aparte bestanden worden opgeslagen.
|
Polisnr |
Naam |
Adres |
Postcode |
Plaats |
Polisbedrag |
Premie |
|||||||||||||||||||||||||||||||||||
|
6798316 |
R. Ederzeel |
Hoofdweg 67 |
1000 |
Brussel |
91 000,00 |
62,50 |
|||||||||||||||||||||||||||||||||||
|
6798317 |
T. De Vries |
Steenstraat 5 |
3000 |
Leuven |
61 000,00 |
40,50 |
|||||||||||||||||||||||||||||||||||
|
6798318 |
E. Van der Wouden |
Ringweg 4 |
3800 |
St-Truiden |
145 000,00 |
113,90 |
|||||||||||||||||||||||||||||||||||
|
Hypotheek |
|||||||||||||||||||||||||||||||||||||||||
|
Hyponr |
Naam |
Adres |
Postcode |
Plaats |
Hypotheek-bedrag |
RentePerc |
|||||||||||||||||||||||||||||||||||
|
32-8127 |
R. Van Dam |
Loefweg 7 |
2000 |
Antwerpen |
113 500,00 |
6,1 |
|||||||||||||||||||||||||||||||||||
|
32-8128 |
T. De Vries |
Steenstraat |
3000 |
Leuven |
91 000,00 |
5,9 |
|||||||||||||||||||||||||||||||||||
|
32-8129 |
E. Van der Wouden |
Stapstraat 4 |
3800 |
St-Truiden |
113 500,00 |
5,8 |
|||||||||||||||||||||||||||||||||||
Merk op dat niet iedereen die een hypotheek afsluit ook voorkomt bij de levensverzekeringen. Als een hypotheek gelijktijdig met een levensverzekering wordt afgesloten, komen in beide bestanden nieuwe vermeldingen. De adresgegevens worden dan twee keer opgeslagen. 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. Door gegevens meerdere keren op te slaan kunnen er problemen ontstaan zoals bijvoorbeeld bij E. Van der Wouden. De gegevens van E. Van der Wouden zijn verschillend in de twee bestanden. Waarschijnlijk zal een adreswijziging doorgevoerd zijn in het ene bestand maar niet in het andere. Hierdoor krijg je gegevens die elkaar tegenspreken. Met een moeilijk woord zeggen we dat de gegevens inconsistent (onbetrouwbaar) zijn. Indien er dus gegevens moeten gewijzigd worden, moet je alle bestanden wijzigen. Je moet op meerdere plaatsen dezelfde wijzigingen doorvoeren.
Een ander probleem dat zich ook kan voordoen is dat er met de tijd in deze bestanden gegevens zitten die niet meer van belang zijn, die overtollig zijn.
Allemaal redenen om gegevens NIET op meerdere plaatsen op te slaan en op zoek te gaan naar een efficiënte manier voor het opslaan va n gegevens.
1.7.2 Het principe van een databank
Een database is een geïntegreerde verzameling gegevens die door één of meerdere gebruikers simultaan kan gemanipuleerd worden en waarbij ook enkele veiligheidsaspecten in acht worden genomen.
Deze bovenstaande omschrijving vraagt om meer uitleg en brengt ons bij enkele omschrijvingen of principes van een database:
Geïntegreerd: Er bestaan verbanden tussen gegevens. Relationele databases zijn hier een mooi voorbeeld van. Aan het woord relationeel kan je al merken dat we te doen hebben met gegevens die met elkaar in verbinding staan, dit om redundantie te vermijden.
Meerdere gebruikers: Een database kan gebruikt worden door meerdere gebruikers, door meerdere programma’s. De gegevens worden gedeeld.
Simultaan gemanipuleerd: Tegelijkertijd moeten gegevens kunnen gelezen worden en gegevens kunnen weggeschreven worden. Het moet perfect mogelijk zijn dat je gegevens in een database van een online webwinkel bekijkt, terwijl de beheerder van deze site een update van de prijzen doet.
Veiligheidsaspecten: Aangezien er meerdere gebruikers toegang tot de gegevens hebben, moeten we security voorzien in de database. Dit houdt in dat we kunnen specificeren welke gebruikers rechten hebben om bepaalde gegevens te lezen en/of te wijzigen.
1.7.3 DBMS
De software die het werken met een database mogelijk maakt is het databasemanagementsysteem (= DBMS). Access is een RDBMS, een relationeel databasemanagementsysteem.
2 Een databank ontwerpen
Als u een databank wilt opstellen, dan is het noodzakelijk dat u voldoende tijd neemt om na te denken over de structuur van die databank. Hieronder volgen enkele belangrijke factoren.
-
Welke gegevens wenst u op te slaan?
-
Moeten die gegevens aan bepaalde criteria voldoen?
-
Waarvoor moeten die gegevens achteraf gebruikt worden?
-
Op welke manieren wenst u die gegevens achteraf op te vragen en te sorteren?
-
Bestaan er relaties tussen de gegevens?
-
Enz
Een databank ontwerpen kan je met verschillende technieken doen. Normalisatie was de eerste geformaliseerde techniek hiervoor. Vandaag de dag is o.a. het entiteitsrelatiemodel (ERD) populair en kunnen de diagrammen geconverteerd worden naar databasestructuren. We bespreken hieronder beide technieken.
2.1 Normaliseren
Normalisatie is een methodologie voor het zodanig ordenen van attributen in tabellen, dat er geen sprake is van redundantie onder de attributen. Dus, dezelfde gegevens mogen niet op twee of meer plaatsen voorkomen. Elke tabel richt zich op één type gegeven, oftewel elke tabel beschrijft één entiteit ofwel één veel-op-veel-relatie. Ook staan er precies op de juiste plaatsen refererende sleutels. Met andere woorden het resultaat is een goedgestructureerde relationele database.
2.1.1 Stappen
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.
- de NV:
Breng alle gegevens in één entiteit - ste NV:
Laat de velden die kunnen berekend worden uit andere velden weg.
Bepaal de primaire sleutel.
Verwijder repeterende groepen en steek deze in een nieuwe entiteit.
Bij het afsplitsen van de repeterende groep wordt de sleutel van de oorspronkelijke groep meegenomen in de attributenlijst.
Duid in deze nieuwe entiteit de primaire sleutel aan
- de NV:
Zoek naar ieder attribuut dat geen deel uitmaakt van de sleutel en die afhankelijk is van slechts een deel van de sleutel.
Maak nieuwe entiteiten met gevonden attributen samen met dat deel van de sleutel waarvan ze afhankelijk zijn.
Definieer primaire sleutel in de nieuwe entiteiten. - de NV:
Zoek naar ieder niet-sleutelattribuut dat functioneel afhankelijk is van een ander niet-sleutelattribuut
Maak nieuwe entiteiten met gevonden attributen samen met het niet-sleutel attribuut waar ze functioneel afhankelijk van zijn.
Definieer primaire sleutels in deze nieuwe entiteiten.
2.1.2 Een eerste voorbeeld DJ Paul
Paul, DJ bij de lokale radio, verzorgt driemaal per week een twee uur durend programma waarin hij zijn favoriete muziek laat horen en nieuwe cd’s onder de aandacht wil brengen. Hij krijgt hiervoor een kleine onkostenvergoeding die hij gebruikt om zijn CD-collectie langzaam uit te breiden. Aan het einde van de 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 SABAM ervoor dat de betreffende artiesten een kleine vergoeding krijgen.
Per draaidag maakt Paul zo’n overzicht maar het is al gebeurd dat hij zo’n overzicht kwijtgeraakt is. Hij vraagt daarom een database te ontwikkelen waarmee hij aan het einde van de maand het gewenste overzicht kan maken.
| Lokale omroep, DJ Paultje | ||||
|---|---|---|---|---|
| Datum | Code | Titel | Artiest(en) | Soort |
| 21-11-2017 | RH5718 | Coming at home | Justin Bieber | S Single |
| BH9829 | Take it to the limit | Taylor Swift | C CD | |
| WH7373 | Tinder Tornado | Sydney | C CD | |
| YQ7587 | Thalapathy Vijay | Bartofso | B BR | |
| UU8375 | Schway | 6ix9ine | M Maxi | |
| … | … | … | … | |
| Totaal aantal tracks: 31 | ||||
0de Normaalvorm
We nemen aan de hand van de figuur op de vorige pagina de eerste stap om de gegevens uiteen te rafelen. We krijgen dan de zogenaamde nulde normaalvorm door alle elementaire, 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 koptekst is op ieder overzicht 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.
Vervolgens zien we een aantal gegevens die iedere keer zullen verschillen: de datum en de gegevens van de gedraaide muziek. Deze gegevens moeten we natuurlijk wel opnemen in de databank 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, zouden we het zelf op eenvoudige wijze even kunnen bepalen. Het totaal aantal kunnen we daarom ook weglaten uit de database. We noemen het een procesgegeven en deze nemen we nooit op in een databank.
Wat zijn nu de elementaire gegevens? Datum, code titel, artiest en soort. Met de aanduiding soort bedoelen we twee gegevens een soortcode (bijvoorbeeld S) en een soortomschrijving (bijvoorbeeld Single). Soort is een samengesteld gegeven en moet daarom gesplitst worden in twee elementaire gegevens: soortcode en soortomschrijving.
We houden nu dus over de elementaire gegevens of attributen: datum, code, titel, artiest, soortcode en soortomschrijving.
Met de door ons gevonden attributen is er iets speciaals aan de hand. Het eerste gegeven de datum, komen we maar één keer tegen. De andere gegevens komen we meerdere keren tegen. Dit zijn repeterende gegevens en dit noteren we als volgt:
Datum, RG(code, titel, artiest, soortcode, soortomschrijving)
Daarbij staat RG voor repeterende groep (repeating groups). Alle gegevens die meerdere keren, repeterend, voorkomen staan vervolgens tussen bolle () haakjes vermeld.
Het overzicht dat we hebben is van 21 november 2017. 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 sleutelattribuut. We geven het sleutelattribuut aan door dit te onderstrepen.
De 0de normaalvorm geeft
0 NV ( datum, RG(code, titel, artiest, soortcode, soortomschrijving))
De 1ste normaalvorm
Om de gegevens in de eerste normaalvorm te krijgen moeten de repeterende groepen verwijderd worden.
We bepalen de eerste normaalvorm door de repeterende groep apart te nemen en uit te breiden met de sleutel van de nulde normaalvorm. Hierna bepalen we in de 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
In deze nieuwe groep moeten we nu nog een sleutel aanwijzen. Om precies één regel op een bepaald formulier aan te duiden moeten we eerst aangeven naar welk formulier, van welke datum, we willen kijken. Daartoe dienen we dus de datum op te geven. Vervolgens selecteren we één enkel 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 tweemaal hetzelfde nummer in dezelfde uitzending draait. De combinatie van datum en code kan fungeren als sleutel. We krijgen dan:
Datum, code, titel, artiest, soortcode, soortomschrijving
We moeten ons werk nog afmaken. Dat doen we door in de originele nulde normaalvorm de door ons apart genomen repeterende groep te verwijderen 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:
0 NV ( 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:
1ste NV:
(datum)
(Datum, code, titel, artiest, soortcode, soortomschrijving)
De 2de normaalvorm
De eerste normaalvorm heeft nog steeds nadelen dat dezelfde gegevens steeds opnieuw worden opgeslagen. Paul draait nummers immers vaker (op verschillende dagen) en telkens worden alle gegevens van een nummer helemaal opnieuw genoteerd.
Om te komen tot de tweede normaalvorm onderzoeken we in de eerste normaalvorm of er attributen 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 kijken alleen maar naar de groepen in de eerste normaalvorm waarbij de sleutel samengesteld is, dus uit meerdere attributen bestaat. In ons geval de groep:
(Datum, code, titel, artiest, soortcode, soortomschrijving)
We moeten nu zoeken naar niet-sleutelattributen die slechts afhankelijk 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 gedraaide nummer (‘vertel ons de code en wij vertellen u de artiest, de titel, etc). 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-sleutelattributen weg. We hadden:
(Datum, code, titel, artiest, soortcode, soortomschrijving)
En we krijgen nu dus:
(Datum, code)
Let erop dat het sleuteldeel waarvan de niet-sleutelattributen afhankelijk 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 normaalvorm al hadden gevonden maar waar geen samengestelde sleutel in aanwezig was.
We krijgen dan uiteindelijk de tweede normaalvorm:
2de NV:
(code, titel, artiest, soortcode, soortomschrijving)
(Datum, code)
(Datum)
De 3de normaalvorm
We nemen nu de laatste stap, het bepalen van de derde normaalvorm. De door ons gevonden 2de normaalvorm zag eruit als:
(code, titel, artiest, soortcode, soortomschrijving)
(Datum, code)
(Datum)
Er zit in de tweede normaalvorm nog een vorm van overtolligheid (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 hebben, zal de combinatie S, Single dus 1000 keer zijn opgenomen. Door deze overtolligheid eruit te halen ontstaat de derde normaalvorm.
Om de derde normaalvorm te bepalen vragen we ons af of er niet-sleutelattributen zijn die niet afhangen 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 bovenstaande 2de NV gevonden.
In ons voorbeeld moeten we dus alleen maar in de eerste groep te kijken, want alleen daar is er spraken van een aantal niet-sleutelattributen. We gaan deze allemaal bekijken en vragen ons af of ze afhankelijk zijn van de sleutel of van een ander niet-sleutelattribuut. 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. De titel is geheel afhankelijk van de sleutel. 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 nummer het gaat maar moeten we weten welke soortcode van toepassing is: ‘vertelons de soortcode en wij vertellen u de soortomschrijving’. De soortomschrijving heeft dus niets te maken met de sleutel, maar alles met een ander niet-sleutelattribuut. We nemen deze twee attributen apart op in een afzonderlijke groep:
(soortcode, soortomschrijving)
Daarbij geldt dat de soortcode het sleutelattribuut zal worden: ‘vertel ons de soortcode en wij vertellen u de soortomschrijving’. Dus:
(soortcode, soortomschrijving)
In de originele groep laten we nu het afhankelijke niet-sleutelattribuut (soortomschrijving) weg. 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 en daar dienst doet als vreemde sleutel!
Door de beide zojuist gevonden groepen aan te vullen met de andere, niet veranderde groepen uit de tweede normaalvorm, ontstaat de derde normaalvorm:
3de 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. Eerst moeten we nog een paar afrondende handelingen verrichten. De eerste handeling bestaat uit het toekennen van namen aan de gevonden tabellen. De eerste tabel geven we de naam SOORT, omdat daarin de soort muziekdrager wordt bijgehouden. 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 programma heeft verzorgd. Deze tabel noemen we DATUM.
3de NV:
| SOORT | (soortcode, soortomschrijving) |
| TRACK | (code, titel, artiest, soortcode) |
| DRAAILIJST | (Datum, code) |
| DATUM | (Datum) |
De tweede handeling bestaat uit het EVENTUEEL weglaten van tabellen waarin alleen maar sleutelattributen voorkomen. De tabellen mogen alleen maar worden weggelaten als er daarvoor verder GEEN informatie verloren gaat.
NIET IEDERE TABEL DIE BESTAAT UIT ALLEEN SLEUTELATTRIBUTEN MAG DUS WORDEN WEGGELATEN!
Als we kijken naar ons voorbeeld moeten we twee tabellen bekijken nl:
| DRAAILIJST | (Datum, code) |
| DATUM | (Datum) |
Heeft het zin om de tabel DATUM bij te houden? Immers, een overzicht van alle draaidatums kunnen we ook afleiden uit de tabel DRAAILIJST. Ten slotte 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.
De tabel 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. Deze tabel moet dus behouden blijven ook al bestaat ze uitsluitend uit sleutelattributen.
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 mag je gebruik maken van een verkorte notatiewijze. Als de tweede normaalvorm gelijk blijkt te zijn aan de eerste normaalvorm, noteren we bij de tweede normaalvorm: 2 NV = 1 NV.