Normaliseren
Door Elwin - Fratsloos, 25 jaar geleden, 128.410x bekeken
In deze tutorial ga ik je de beginselen bijbrengen van het Normaliseren. Dit doe ik aan de hand van een voorbeeld.
Gesponsorde koppelingen
Inhoudsopgave
- Normaliseren inleiding
- Nulde Normaalvorm
- Eerste Normaalvorm
- Tweede Normaalvorm
- Derde Normaalvorm
- Afsluiting
- Begrippen & Literatuur
Er zijn 69 reacties op 'Normaliseren'
Gesponsorde koppelingen
Misschien kun je eens een kijkje nemen op http://www.yapf.net/faq.php?cmd=100&itemid=700 :-)
@Bart
In de inleiding schrijf ik ook dat het een manier is... niet de manier. Ik zelf doe het door gelijk een ERD te maken.
En over de BCNV doe ik geen uitspraken, ik zeg niet dat die niet nuttig zal zijn, want waarom is die er anders? Maar het is voor de meeste DB's niet nodig.
@Timon
Het is waarschijnlijk maar net hoe je het leert. Ik heb me aangeleerd om de 0NV te beschouwen als een inventarisatie van de gegevens die men in de database wilt zien. Om dan naar de 1NV te komen moet je inderdaad de RG's en de procesgegevens (constante gegevens?) verplaatsen/verwijderen. Misschien komt dat niet helemaal duidelijk uit mijn tutorial.
@Koos
In princiepe heb je gelijk, maar het gaat wel heel erg ver. Normaal gesproken heb je in een CRM-pakket o.i.d. (maar dit lijkt wel veel op CRM omdat we te maken hebben met een afleverbon) genoeg aan het invullen van de gegevens.
Ga echter een stukje verder, zoals bijvoorbeeld op de website van Way2Pay gebeurd (kies adres ophalen), en je hebt het wel nodig.
Daar ga je volgens mij nog een stap verder, omdat de postcode zowel de plaats als de straat kan identificeren.
Elwin
In de inleiding schrijf ik ook dat het een manier is... niet de manier. Ik zelf doe het door gelijk een ERD te maken.
En over de BCNV doe ik geen uitspraken, ik zeg niet dat die niet nuttig zal zijn, want waarom is die er anders? Maar het is voor de meeste DB's niet nodig.
@Timon
Het is waarschijnlijk maar net hoe je het leert. Ik heb me aangeleerd om de 0NV te beschouwen als een inventarisatie van de gegevens die men in de database wilt zien. Om dan naar de 1NV te komen moet je inderdaad de RG's en de procesgegevens (constante gegevens?) verplaatsen/verwijderen. Misschien komt dat niet helemaal duidelijk uit mijn tutorial.
@Koos
In princiepe heb je gelijk, maar het gaat wel heel erg ver. Normaal gesproken heb je in een CRM-pakket o.i.d. (maar dit lijkt wel veel op CRM omdat we te maken hebben met een afleverbon) genoeg aan het invullen van de gegevens.
Ga echter een stukje verder, zoals bijvoorbeeld op de website van Way2Pay gebeurd (kies adres ophalen), en je hebt het wel nodig.
Daar ga je volgens mij nog een stap verder, omdat de postcode zowel de plaats als de straat kan identificeren.
Elwin
Het is misschien niet een nette manier om zo te handelen , maar ik denk dat ik een foutje heb gevonden.
Ik weet het niet zeker, want ik ben ook geen expert, maar als je naar de tabel
BESTELDE_ARTIKELEN kijkt klopt er iets niet.
BESTELDE_ARTIKELEN
ordernr
artnr
aantal
Ik neem aan dat je meerdere ordernr?s hebt maar je hebt ook meerdere artnr?s.
B.V.
Dit kan, maar dit kan alleen als je met 1 ordernr werkt want als je er meer hebt kan dit niet meer. Maar meer orders in een database is wel normaal denk ik.
Artnr Ordernr Aantal
15201 3405 1
21987 3405 6
12365 3405 1
12366 3405 7
Het probleem is je heb geen unieke waarde, dus deze klopt zo niet.
B.V.
Artnr Ordernr Aantal
15201 3405 1
12365 3405 1
15201 3506 1
12365 3506 1
Wat je wel zou kunnen doen is een unieke waarden toevoegen om het kloppend te maken.
B.V.
Regelnr Artnr Ordernr Aantal
1 15201 3405 1
2 12365 3405 1
3 15201 3506 1
4 12365 3506 1
Zo zou het wel moeten kloppen.
Ik weet niet helemaal zeker of ik hier gelijk in heb, dus als dit fout is hoor ik het graag.
Ik weet het niet zeker, want ik ben ook geen expert, maar als je naar de tabel
BESTELDE_ARTIKELEN kijkt klopt er iets niet.
BESTELDE_ARTIKELEN
ordernr
artnr
aantal
Ik neem aan dat je meerdere ordernr?s hebt maar je hebt ook meerdere artnr?s.
B.V.
Dit kan, maar dit kan alleen als je met 1 ordernr werkt want als je er meer hebt kan dit niet meer. Maar meer orders in een database is wel normaal denk ik.
Artnr Ordernr Aantal
15201 3405 1
21987 3405 6
12365 3405 1
12366 3405 7
Het probleem is je heb geen unieke waarde, dus deze klopt zo niet.
B.V.
Artnr Ordernr Aantal
15201 3405 1
12365 3405 1
15201 3506 1
12365 3506 1
Wat je wel zou kunnen doen is een unieke waarden toevoegen om het kloppend te maken.
B.V.
Regelnr Artnr Ordernr Aantal
1 15201 3405 1
2 12365 3405 1
3 15201 3506 1
4 12365 3506 1
Zo zou het wel moeten kloppen.
Ik weet niet helemaal zeker of ik hier gelijk in heb, dus als dit fout is hoor ik het graag.
@Arjan van Balen
In principe heb je gelijk. Maar het zou alleen opgaan als je ?f artnr, ?f ordernr in de tabel bestelde_artikelen als primaire sleutel hebt.
Ik heb echter gebruik gemaakt van een samengestelde primaire sleutel. Namelijk een combinatie van artnr en ordernr.
Op deze manier heb je altijd een unieke regel, want een artikel die twee keer in een order voorkomt kan simpelweg gewoon bij elkaar gevoegd worden:
artnr ordnr aantal
15201 3405 8
12365 3405 10
15201 3405 6
wordt vanzelfsprekend:
artnr ordnr aantal
15201 3405 14
12365 3405 10
De sleutels in de tut kan je herkennen aan de onderstreepte woorden. Daar zal je zien dat bij bestelde_artikelen ordernr en artnr onderstreept zijn.
Edit:
Stukje uit de Eerste Normaalvorm
Elwin
In principe heb je gelijk. Maar het zou alleen opgaan als je ?f artnr, ?f ordernr in de tabel bestelde_artikelen als primaire sleutel hebt.
Ik heb echter gebruik gemaakt van een samengestelde primaire sleutel. Namelijk een combinatie van artnr en ordernr.
Op deze manier heb je altijd een unieke regel, want een artikel die twee keer in een order voorkomt kan simpelweg gewoon bij elkaar gevoegd worden:
artnr ordnr aantal
15201 3405 8
12365 3405 10
15201 3405 6
wordt vanzelfsprekend:
artnr ordnr aantal
15201 3405 14
12365 3405 10
De sleutels in de tut kan je herkennen aan de onderstreepte woorden. Daar zal je zien dat bij bestelde_artikelen ordernr en artnr onderstreept zijn.
Edit:
Stukje uit de Eerste Normaalvorm
Quote:
Meestal kun je een combinatie nemen van de sleutel van de oorspronkelijke groep en het gegeven dat in de Repeterende Groep de sleutelrol vervult. De sleutel wordt in dit geval een combinatie van ordernr en artnr.
Elwin
Ik zal anders even een uitwerking uit mijn boek uitwerken, kun je dan even aangeven of dat ?e goed is?
Het is zeg maar een opgave over APK van een auto. In de 0e normaalvorm vind ik het volgende:
0NV:
Klant
Klantnaam
Adres
Postcode
Woonplaats
Kenteken RG
APKdatum RG
Vervolgens markeer ik de herhalende items met RG, en neem ik die samen met een kopie van de originele PK in een nieuwe groep:
1NV:
Klantnummer PK
Klantnaam
Adres
Postcode
Woonplaats
Klantnummer PK en FK aan de PK in de bovenste groep
Kenteken PK
APKdatum
Vervolgens kijk ik of er niet sleutelattributen zijn, die afhankelijk zijn van een van de sleutels, bij de gecombineerde sleutels hierboven:
2 NV
Klantnummer PK
Klantnaam
Adres
Postcode
Woonplaats
Klantnummer PK en FK aan de PK hierboven
Kenteken PK : Klantnummer en kenteken vormen een gecombineerde sleutel
Kenteken PK en FK aan de PK hierboven
APKdatum
En als laatste kijk je of er niet sleutelattributen zijn, die afhankelijk zijn van niet sleutel attributen:
3NV:
Klantnummer PK
Klantnaam FK aan klantnaam in een tabel hier beneden
Adres
Postcode
Woonplaats
Klantnummer PK en FK aan de PK hierboven
Kenteken PK : Klantnummer en kenteken vormen een gecombineerde sleutel
Kenteken PK en FK aan de PK hierboven
APKdatum
Klantnaam PK
Adres
Postcode
Woonplaats
Is deze normalisatie goed? :)
Het is zeg maar een opgave over APK van een auto. In de 0e normaalvorm vind ik het volgende:
0NV:
Klant
Klantnaam
Adres
Postcode
Woonplaats
Kenteken RG
APKdatum RG
Vervolgens markeer ik de herhalende items met RG, en neem ik die samen met een kopie van de originele PK in een nieuwe groep:
1NV:
Klantnummer PK
Klantnaam
Adres
Postcode
Woonplaats
Klantnummer PK en FK aan de PK in de bovenste groep
Kenteken PK
APKdatum
Vervolgens kijk ik of er niet sleutelattributen zijn, die afhankelijk zijn van een van de sleutels, bij de gecombineerde sleutels hierboven:
2 NV
Klantnummer PK
Klantnaam
Adres
Postcode
Woonplaats
Klantnummer PK en FK aan de PK hierboven
Kenteken PK : Klantnummer en kenteken vormen een gecombineerde sleutel
Kenteken PK en FK aan de PK hierboven
APKdatum
En als laatste kijk je of er niet sleutelattributen zijn, die afhankelijk zijn van niet sleutel attributen:
3NV:
Klantnummer PK
Klantnaam FK aan klantnaam in een tabel hier beneden
Adres
Postcode
Woonplaats
Klantnummer PK en FK aan de PK hierboven
Kenteken PK : Klantnummer en kenteken vormen een gecombineerde sleutel
Kenteken PK en FK aan de PK hierboven
APKdatum
Klantnaam PK
Adres
Postcode
Woonplaats
Is deze normalisatie goed? :)
En dan heb ik er nog een. Deze normalisatie is gemaakt aan de hand van een vuurwerkbestelbon. In de 0e normaalvorm vind ik het volgende:
0NV:
Bestelnummer PK
Klantnaam
Artikelnr RG
Omschrijving RG
Prijs RG
Aantal RG
Kortings% RG
Vervolgens neem ik de PK van hierboven met de RG items samen in een nieuwe groep:
1 NV:
Bestelnummer PK
Klantnaam
Bestelnummer FK aan de PK hierboven
Artikelnr: bestelnummer en Artikelnr vormen een gecombineerde sleutel
Omschrijving
Prijs p/s
Aantal
Kortings%
Dan ga ik kijken of er niet sleutelattributen afhankelijk zijn van een van de bovenstaande sleutels (in de gecombineerde sleutelvorm):
2NV:
Bestelnummer PK
Klantnaam
Bestelnummer FK aan de PK hierboven
Artikelnr: bestelnummer en Artikelnr vormen een gecombineerde sleutel
Aantal
Kortings%
Artikelnr FK aan Artikelnr hierboven
Omschrijving
Prijs p/s
En als laatste moet je weer kijken of er niet sleutelattributen zijn, die van niet sleutel attributen afhankelijk zijn. Maar volgens mij kan dat nu niet meer toch? In dit geval is het toch 2NV = 3NV ?
0NV:
Bestelnummer PK
Klantnaam
Artikelnr RG
Omschrijving RG
Prijs RG
Aantal RG
Kortings% RG
Vervolgens neem ik de PK van hierboven met de RG items samen in een nieuwe groep:
1 NV:
Bestelnummer PK
Klantnaam
Bestelnummer FK aan de PK hierboven
Artikelnr: bestelnummer en Artikelnr vormen een gecombineerde sleutel
Omschrijving
Prijs p/s
Aantal
Kortings%
Dan ga ik kijken of er niet sleutelattributen afhankelijk zijn van een van de bovenstaande sleutels (in de gecombineerde sleutelvorm):
2NV:
Bestelnummer PK
Klantnaam
Bestelnummer FK aan de PK hierboven
Artikelnr: bestelnummer en Artikelnr vormen een gecombineerde sleutel
Aantal
Kortings%
Artikelnr FK aan Artikelnr hierboven
Omschrijving
Prijs p/s
En als laatste moet je weer kijken of er niet sleutelattributen zijn, die van niet sleutel attributen afhankelijk zijn. Maar volgens mij kan dat nu niet meer toch? In dit geval is het toch 2NV = 3NV ?
En dan heb ik er weer eentje.
Deze maak ik aan de hand van een factuur. Het is een tooltheek die van alles verhuurt. In de 0e normaalvorm vind ik het volgende:
0NV
Factuurnr
Datum
Klantnaam
Adres
Postcode
Plaats
Artikelnr
Omschrijving
Aantal dagen
En procesgegevens:
Totaal
Totaal BTW
Te betalen
Vervolgens ga ik de RG markeren, en met de PK (factuurnr samennemen in een nieuwe groep).
1 NV:
Factuurnr PK
datum
Klantnaam
Adres
Postcode
Plaats
Factuurnr FK aan de PK hierboven
Artikelnr PK
Omschrijving
Aantal_dagen
Factuurnr en Artikelnr vormen hier de gecombineerde sleutel.
Dan ga ik kijken welke niet sleutelattributen afhankelijk zijn, van een van de sleutels.
2NV:
Factuurnr PK
datum
Klantnaam
Adres
Postcode
Plaats
Factuurnr PK en FK aan de PK hierboven
Artikelnr PK (gecombineerde sleutel samen met Factuurnr)
Aantal
Artikelnr PK en FK aan de PK hierboven
Omschrijving
Als laatste moet je weer kijken, welke niet sleutelattributen afhankelijk zijn van niet sleutelattributen. Eerst was ik van plan om klantnaam, adres, postcode en plaats ook samen te nemen, maar kwam ik tot de conclusie dat iemand niet uniek kan zijn door zijn/haar naam. Zo kunnen er 2 Jansen bestaan. Is het hier weer zo dat de 2NV gelijk ook de 3e NV is?
Deze maak ik aan de hand van een factuur. Het is een tooltheek die van alles verhuurt. In de 0e normaalvorm vind ik het volgende:
0NV
Factuurnr
Datum
Klantnaam
Adres
Postcode
Plaats
Artikelnr
Omschrijving
Aantal dagen
En procesgegevens:
Totaal
Totaal BTW
Te betalen
Vervolgens ga ik de RG markeren, en met de PK (factuurnr samennemen in een nieuwe groep).
1 NV:
Factuurnr PK
datum
Klantnaam
Adres
Postcode
Plaats
Factuurnr FK aan de PK hierboven
Artikelnr PK
Omschrijving
Aantal_dagen
Factuurnr en Artikelnr vormen hier de gecombineerde sleutel.
Dan ga ik kijken welke niet sleutelattributen afhankelijk zijn, van een van de sleutels.
2NV:
Factuurnr PK
datum
Klantnaam
Adres
Postcode
Plaats
Factuurnr PK en FK aan de PK hierboven
Artikelnr PK (gecombineerde sleutel samen met Factuurnr)
Aantal
Artikelnr PK en FK aan de PK hierboven
Omschrijving
Als laatste moet je weer kijken, welke niet sleutelattributen afhankelijk zijn van niet sleutelattributen. Eerst was ik van plan om klantnaam, adres, postcode en plaats ook samen te nemen, maar kwam ik tot de conclusie dat iemand niet uniek kan zijn door zijn/haar naam. Zo kunnen er 2 Jansen bestaan. Is het hier weer zo dat de 2NV gelijk ook de 3e NV is?
Ok?... die eerste is lastig. Ik denk dat dat op twee tabellen blijft steken. Behalve als er meer gegevens van de auto worden opgeslagen.
0NV
KLANTEN
klantnr
klantnaam
adres
postcode
woonplaats
RG kenteken
RG apkdatum
1NV
KLANTEN
klantnr
klantnaam
adres
postcode
woonplaats
KEURING
klantnr
kenteken
apkdatum
3NV = 2NV = 1NV
Je tweede normalisatie ziet er goed uit in 2e en dus 3e NV.
De laatste lijkt me fout. Die is wel een beetje te vergelijken met het voorbeeld in de tutorial. Ik ben van mening dat een klantnaam niet bij het factuurnummer hoort. Verzin dan eventueel een nieuwe PK voor de klant (-nummer).
Mijn basis voor klanten met bestellingen is zo:
KLANT
nr, naam, adres, contact, etc
ARTIKEL
nr, naam, prijs, eventueel (sub)cat (dan ook die tabellen inrichten)
ORDERS
nr, klantnr, datum, korting
ORDERREGEL (Bestelde_artikel in het voorbeeld)
ordernr, aantal, eventueel prijs (als die afwijkt door een prijsafspraak)
In jouw geval zou ik op zoiets komen:
KLANTEN
klantnr
klantnaam
adres
postcode
plaats
ORDERS
ordernr
klantnr (FK)
datum
ORDERREGEL
ordernr (FK)
artikelnr (FK)
aantal_dagen (waarom dat _dagen?)
ARTIKEL
artikelnr
omschrijving
prijs (zie ik niet in je inventarisatie)
Succes verder!
Elwin
0NV
KLANTEN
klantnr
klantnaam
adres
postcode
woonplaats
RG kenteken
RG apkdatum
1NV
KLANTEN
klantnr
klantnaam
adres
postcode
woonplaats
KEURING
klantnr
kenteken
apkdatum
3NV = 2NV = 1NV
Je tweede normalisatie ziet er goed uit in 2e en dus 3e NV.
De laatste lijkt me fout. Die is wel een beetje te vergelijken met het voorbeeld in de tutorial. Ik ben van mening dat een klantnaam niet bij het factuurnummer hoort. Verzin dan eventueel een nieuwe PK voor de klant (-nummer).
Mijn basis voor klanten met bestellingen is zo:
KLANT
nr, naam, adres, contact, etc
ARTIKEL
nr, naam, prijs, eventueel (sub)cat (dan ook die tabellen inrichten)
ORDERS
nr, klantnr, datum, korting
ORDERREGEL (Bestelde_artikel in het voorbeeld)
ordernr, aantal, eventueel prijs (als die afwijkt door een prijsafspraak)
In jouw geval zou ik op zoiets komen:
KLANTEN
klantnr
klantnaam
adres
postcode
plaats
ORDERS
ordernr
klantnr (FK)
datum
ORDERREGEL
ordernr (FK)
artikelnr (FK)
aantal_dagen (waarom dat _dagen?)
ARTIKEL
artikelnr
omschrijving
prijs (zie ik niet in je inventarisatie)
Succes verder!
Elwin
Ah ok ben dus wel aardig goed bezig, alleen had ik bij die eerste niet verder moeten normaliseren, was ook ff een twijfel. Nu weet ik ook hoe ik zoiets moet hanteren. nog even een paar vragen:
3e NVvraagje: Wanneer er bijvoorbeeld niet sleutelattr. afhankelijk zijn van niet sleutelattrib., mag je dus gewoon een PK verzinnen, om ze alsnog in een aparte groep samen te nemen, als het op dat moment niet mogelijk is door het ontbreken van bijv een klantnummer? Aangezien ik tijdens de inventarisatie van die laatste opgave geen klantnr heb gezien.
En had nog wat vraagjes over die 3e normalisatie. Ik zag dat je factuurnummer niet meeneemt, is die niet belangrijk? Of klopt me vermoeden en gebruik je ordernummer i.p.v. factuurnummer. :)
Oja dat aantal dagen had ik beter gewoon op aantal kunnen houden. :)
3e NVvraagje: Wanneer er bijvoorbeeld niet sleutelattr. afhankelijk zijn van niet sleutelattrib., mag je dus gewoon een PK verzinnen, om ze alsnog in een aparte groep samen te nemen, als het op dat moment niet mogelijk is door het ontbreken van bijv een klantnummer? Aangezien ik tijdens de inventarisatie van die laatste opgave geen klantnr heb gezien.
En had nog wat vraagjes over die 3e normalisatie. Ik zag dat je factuurnummer niet meeneemt, is die niet belangrijk? Of klopt me vermoeden en gebruik je ordernummer i.p.v. factuurnummer. :)
Oja dat aantal dagen had ik beter gewoon op aantal kunnen houden. :)
Nog eens eentje, aangezien deze best lastig is. Zal eerst even de opgave maken, en dan apart mijn uitwerking.
Het gaat om een tandarts rekening met daarop de volgende gegevens:
Tandarts L. de Groot Bank: AMRO
Meerlaan 234 Reknr: 8957849
1088 AF Amsterdam
__________________________________________________________
Nota: 2004795
Behandeling van:
Klantnr: 1986243
Naam: J.H. van den Briel, jr.
Betaling door:
Klantnr: 1986240
Naam: J.A van den Briel, sr
Adres: Ransdorpweg 14
Woonplaats: Amsterdam
_____________________________________________________________
Datum | Code | Omschrijving | Prijs |
14 jan 2004 CH0 Controle 25 euro
22 jan 2004 AP1 Verdoving 20 euro
22 jan 2004 CX2 2-vlaks vulling 75 euro
_____________________________________________________________
Totaal: | 120 euro
_____________________________________________________________
Gelieve binnen drie weken te betalen.
_____________________________________________________________
_____________________________________________________________
Het gaat om een tandarts rekening met daarop de volgende gegevens:
Tandarts L. de Groot Bank: AMRO
Meerlaan 234 Reknr: 8957849
1088 AF Amsterdam
__________________________________________________________
Nota: 2004795
Behandeling van:
Klantnr: 1986243
Naam: J.H. van den Briel, jr.
Betaling door:
Klantnr: 1986240
Naam: J.A van den Briel, sr
Adres: Ransdorpweg 14
Woonplaats: Amsterdam
_____________________________________________________________
Datum | Code | Omschrijving | Prijs |
14 jan 2004 CH0 Controle 25 euro
22 jan 2004 AP1 Verdoving 20 euro
22 jan 2004 CX2 2-vlaks vulling 75 euro
_____________________________________________________________
Totaal: | 120 euro
_____________________________________________________________
Gelieve binnen drie weken te betalen.
_____________________________________________________________
_____________________________________________________________
In ben begonnen met de inventarisatie voor de 0e vorm:
0NV:
Tandartsnaam
Adres
Postcode
Plaats
Bank
Reknr.
Notanr PK
Klantnr
Naam
Klantnr
Naam
Adres
Plaats
Datum RG
Code RG
Omschrijving RG
Prijs RG
Vervolgens heb ik de PK en de RG items in een nieuwe tabel gezet:
1 NV:
Tandartsnaam
Adres
Postcode
Plaats
Bank
Reknr
Notanr
Klantnr
Naam
Klantnr
Naam
Adres
Plaats
Notanr PK
Datum PK
Code PK
Omschrijving
Prijs
Daarna heb ik gekeken welke niet sleutelattributen afhankelijk zijn van een deel van de gecombineerde sleutel:
2NV:
Tandartsnaam
Adres
Postcode
Plaats
Bank
Reknr
Notanr
Klantnr
Naam
Klantnr
Naam
Adres
Plaats
Notanr PK
Datum PK
Code PK (FK)
Code PK
Omschrijving
Prijs
En als laatste heb ik de niet sleutel attributen die van niet sleutelattributen afhankelijk zijn, in een groep gezet:
3NV:
Tandarts:
Naam
Adres
Postcode
Plaats
Bank
Reknr
Behandeling:
Klantnr PK
Naam
Betalende:
Klantnr PK (FK)
Naam
Adres
Plaats
Soort behandeling:
Code PK
Omschrijving
Prijs
Nota:
Notanr PK
Datum
Code FK
Enig id of dit zo'n btje klopt?
0NV:
Tandartsnaam
Adres
Postcode
Plaats
Bank
Reknr.
Notanr PK
Klantnr
Naam
Klantnr
Naam
Adres
Plaats
Datum RG
Code RG
Omschrijving RG
Prijs RG
Vervolgens heb ik de PK en de RG items in een nieuwe tabel gezet:
1 NV:
Tandartsnaam
Adres
Postcode
Plaats
Bank
Reknr
Notanr
Klantnr
Naam
Klantnr
Naam
Adres
Plaats
Notanr PK
Datum PK
Code PK
Omschrijving
Prijs
Daarna heb ik gekeken welke niet sleutelattributen afhankelijk zijn van een deel van de gecombineerde sleutel:
2NV:
Tandartsnaam
Adres
Postcode
Plaats
Bank
Reknr
Notanr
Klantnr
Naam
Klantnr
Naam
Adres
Plaats
Notanr PK
Datum PK
Code PK (FK)
Code PK
Omschrijving
Prijs
En als laatste heb ik de niet sleutel attributen die van niet sleutelattributen afhankelijk zijn, in een groep gezet:
3NV:
Tandarts:
Naam
Adres
Postcode
Plaats
Bank
Reknr
Behandeling:
Klantnr PK
Naam
Betalende:
Klantnr PK (FK)
Naam
Adres
Plaats
Soort behandeling:
Code PK
Omschrijving
Prijs
Nota:
Notanr PK
Datum
Code FK
Enig id of dit zo'n btje klopt?
hey, ben ook bezig met een database voor materieelgegevens in op te slaan alleen kom ik er niet echt uit. Heb de volgende gegevens.
Merk PK
Model PK
Uitvoering PK
Bouwjaar PK
Werking
Datum in gebruikname
Capaciteit
Motor
Draaiuren
Km-stand
Conditie
Brandstof
Gewicht
Afmetingen
Bandenmaat
Prijs
Voor zover ik kan zien kan ik de tabel niet vereenvoudigen...maar het lijkt me sterk dat dit hem al is... Kan iemand mij even helpen?
Alvast bedankt.
Jochem
Merk PK
Model PK
Uitvoering PK
Bouwjaar PK
Werking
Datum in gebruikname
Capaciteit
Motor
Draaiuren
Km-stand
Conditie
Brandstof
Gewicht
Afmetingen
Bandenmaat
Prijs
Voor zover ik kan zien kan ik de tabel niet vereenvoudigen...maar het lijkt me sterk dat dit hem al is... Kan iemand mij even helpen?
Alvast bedankt.
Jochem
Nu weet ik dat deze vraag niet met normaliseren te maken heeft, maar met de stap na het verwerken van de gegevens in een ERD, toch doe ik ff een poging.
Wanneer je SQL code schrijft, dingen als create scripts, geef je ook constraints mee. Ik vraag me alleen af hoe je gecombineerde sleutels moet definieren, wanneer ze tegelijkertijd ook FK zijn aan een PK in een andere tabel? Is het voldoende om ze alleen als een fk te vermelden, dus iets als:
constraint nr_fk foreign key (nr) references nummer(nr), of je moet tijdens de create script ook aangeven dat deze ook deel is van een gecombineerde sleutel. Oftewel een pk constraint meegeven met daarin alle pk's, die samen een gecombineerde sleutel vormen? Iemand hier misschien een antwoord op?
Wanneer je SQL code schrijft, dingen als create scripts, geef je ook constraints mee. Ik vraag me alleen af hoe je gecombineerde sleutels moet definieren, wanneer ze tegelijkertijd ook FK zijn aan een PK in een andere tabel? Is het voldoende om ze alleen als een fk te vermelden, dus iets als:
constraint nr_fk foreign key (nr) references nummer(nr), of je moet tijdens de create script ook aangeven dat deze ook deel is van een gecombineerde sleutel. Oftewel een pk constraint meegeven met daarin alle pk's, die samen een gecombineerde sleutel vormen? Iemand hier misschien een antwoord op?
Prachtig uitgelegd, ik ben al weken bezig om het door te krijgen, maar jouw TUT heeft me de ogen geopend, werkelijk waar prachtig, zelfs mijn leerkracht kan het zo makkelijk niet uitleggen... als je zijn formulieren met normaliseringsmethoden moet bestuderen zou je gek worden, zeker als je weet dat er extreem makkelijke TUT's zijn op internet.
Mijn persoonlijke rating: 4/5
spelfouten zijn nog grif aanwezig en ook sommige opmerkingen zijn niet echt duidelijk, zo heb ik zeker een kwartier liggen denken wat t.o.v nou betekende.
Maar verder is het een TOPPER!
GrtZ
Ap
Mijn persoonlijke rating: 4/5
spelfouten zijn nog grif aanwezig en ook sommige opmerkingen zijn niet echt duidelijk, zo heb ik zeker een kwartier liggen denken wat t.o.v nou betekende.
Maar verder is het een TOPPER!
GrtZ
Ap
Cheers voor de laatste goede reacties.. :)
Wat betreft die spelfouten.. wat kan ik zeggen.. :) Heb hem in Word geschreven en na een week er nog eens doorheen gehaald. Blijkbaar niet genoeg. :) Zal het binnenkort nog eens doen. :)
Elwin
Wat betreft die spelfouten.. wat kan ik zeggen.. :) Heb hem in Word geschreven en na een week er nog eens doorheen gehaald. Blijkbaar niet genoeg. :) Zal het binnenkort nog eens doen. :)
Appie:
Simpel toch? ;)wat t.o.v nou betekende
Elwin
http://www.yapf.net/Articles/ArticleView/789 ook een goede
maar deze is ook _erg_ goed!
maar deze is ook _erg_ goed!
HELP !!
Ik heb woensdag een toets en ik moet de volgende vraag kunnen beantwoorden:
VRAAG
Leg uit wat normaliseren inhoudt aan de hand van een voorbeeld.
Wat is het nut van normaliseren. Is normaliseren wel of niet achterhaald?
Dat mooie voorbeeld kan ik natuurlijk niet tijdens mijn toets gebruiken, dan ben ik 2 pagina's aan het schrijven!!
Wie kan mij helpen
een korte versie normaliseren + voorbeeld van normaliseren>zie vraag hierboven!!
Ik heb woensdag een toets en ik moet de volgende vraag kunnen beantwoorden:
VRAAG
Leg uit wat normaliseren inhoudt aan de hand van een voorbeeld.
Wat is het nut van normaliseren. Is normaliseren wel of niet achterhaald?
Dat mooie voorbeeld kan ik natuurlijk niet tijdens mijn toets gebruiken, dan ben ik 2 pagina's aan het schrijven!!
Wie kan mij helpen
een korte versie normaliseren + voorbeeld van normaliseren>zie vraag hierboven!!
Mondy schreef op 05.03.2007 13:05 edit | delete
HELP !!
Ik heb woensdag een toets en ik moet de volgende vraag kunnen beantwoorden:
VRAAG
Leg uit wat normaliseren inhoudt aan de hand van een voorbeeld.
Wat is het nut van normaliseren. Is normaliseren wel of niet achterhaald?
Dat mooie voorbeeld kan ik natuurlijk niet tijdens mijn toets gebruiken, dan ben ik 2 pagina's aan het schrijven!!
Wie kan mij helpen
een korte versie normaliseren + voorbeeld van normaliseren>zie vraag hierboven!!
HELP !!
Ik heb woensdag een toets en ik moet de volgende vraag kunnen beantwoorden:
VRAAG
Leg uit wat normaliseren inhoudt aan de hand van een voorbeeld.
Wat is het nut van normaliseren. Is normaliseren wel of niet achterhaald?
Dat mooie voorbeeld kan ik natuurlijk niet tijdens mijn toets gebruiken, dan ben ik 2 pagina's aan het schrijven!!
Wie kan mij helpen
een korte versie normaliseren + voorbeeld van normaliseren>zie vraag hierboven!!
@Mondy
Kan je aan de hand van de tutorial niet zelf een voorbeeld bedenken?
Naja, een heel simpele dan:
Een foto-album met de volgende gegevens:
album, foto, album_omschrijving, foto_omschrijving
Als je dit in 1 tabel zou zetten dan krijg je voor elke foto in een album weer opnieuw de albumgegevens. Dit is overbodige/ dubbele data -> heb je meteen de reden voor normaliseren.
Gebruik dit voorbeeld dan maar eens en loop daarmee door de tut. Dan heb je ene mooi klein voorbeeld.
Kan je aan de hand van de tutorial niet zelf een voorbeeld bedenken?
Naja, een heel simpele dan:
Een foto-album met de volgende gegevens:
album, foto, album_omschrijving, foto_omschrijving
Als je dit in 1 tabel zou zetten dan krijg je voor elke foto in een album weer opnieuw de albumgegevens. Dit is overbodige/ dubbele data -> heb je meteen de reden voor normaliseren.
Gebruik dit voorbeeld dan maar eens en loop daarmee door de tut. Dan heb je ene mooi klein voorbeeld.
Mooie tutorial!
Voor mijn werk als junior-docent leg ik mijn studenten de techniek van het normaliseren uit. Mijn uitleg verschilt niet veel van de uitleg in de tutorial. E?n ding wijkt echter af: in de derde normaalvorm neemt u in het entiteittype ORDER het attribuut klantnr op in de (samengestelde) sleutel.
Ik ben het ermee eens dat het attribuut klantnr blijft staan in het attribuut ORDER. Maar ik ben het er niet mee eens dat het attribuut klantnr wordt opgenomen in de sleutel van dit entiteittype.
Het attribuut ordernr is toch al genoeg als sleutel? Ordernr maakt de order uniek.
Ik leer mijn studenten dat alles, incl. de sleutel doeltreffend maar wel zo simpel mogelijk moet zijn. Ik zie niet in, waarom klantnr toegevoegd moet worden aan de sleutel van ORDER. Ik zou het wel gewoon als attribuut laten staan in ORDER (maar dus niet toevoegen aan de sleutel). De rest is hetzelfde als mijn uitwerking van het gegeven voorbeeld.
Graag uw reactie...
M.v.g.
E. KErbusch
Voor mijn werk als junior-docent leg ik mijn studenten de techniek van het normaliseren uit. Mijn uitleg verschilt niet veel van de uitleg in de tutorial. E?n ding wijkt echter af: in de derde normaalvorm neemt u in het entiteittype ORDER het attribuut klantnr op in de (samengestelde) sleutel.
Ik ben het ermee eens dat het attribuut klantnr blijft staan in het attribuut ORDER. Maar ik ben het er niet mee eens dat het attribuut klantnr wordt opgenomen in de sleutel van dit entiteittype.
Het attribuut ordernr is toch al genoeg als sleutel? Ordernr maakt de order uniek.
Ik leer mijn studenten dat alles, incl. de sleutel doeltreffend maar wel zo simpel mogelijk moet zijn. Ik zie niet in, waarom klantnr toegevoegd moet worden aan de sleutel van ORDER. Ik zou het wel gewoon als attribuut laten staan in ORDER (maar dus niet toevoegen aan de sleutel). De rest is hetzelfde als mijn uitwerking van het gegeven voorbeeld.
Graag uw reactie...
M.v.g.
E. KErbusch
Ik kan niet anders zeggen dan dat ik dit een heel goede opmerking vind van dhr. Kerbusch. Inderdaad is die sleutel zoals hij hem noemt al voldoende om de integriteit en het unieke aan een order te waarborgen. -> Immers, een order kan maar voor 1 klant zijn, maar 1 klant kan wel meerdere orders hebben.
Word hier soms nog gekeken? Oh ik hoop het. Ik heb hulp nodig. Ik moet een database maken, maar ik word helemaal gek van die normalisatie regels en het lukt mij langs geen kanten. Het zou een database moeten worden van aquariumvissen. De bedoeling is om allerhande informatie van vissoorten gemakkelijke te kunnen opzoeken. En een andere toepassing die ik in gedachten had is om gemakkelijk en rap een care sheet te kunnen afdrukken van een vissoort. Probleem is dat dit dus helemaal iets anders is dan allemaal die "order" voorbeelden die overal staan, en dat dus van dit soort database nergens een voorbeeld ivm normalisatie te vinden is. Hier zijn alle gegevens die ik er in wil zetten.
-Wet_naam (de latijnse naam van de vissoort; dit zou mijn primaire sleutel worden dan)
- Synoniemen (Latijnse synoniemen van de vissoort; dus bv verouderde benamingen etc..)
- Ned_naam (de Nederlandstalige naam of namen)
- Eng_naam (de nederlandstalige naam of namen)
- Werelddeel (waarvan de vis afkomstig is)
- kweekvormen (De verschillende kweekvormen van de vis; dit laat ik mischien gewoon vallen want ik heb zo het gevoel dat het alles nog eens zo ingewikkeld maakt, zeker als ik dan ook van elke kweekvorm een foto en beschrijving zou willen geven?)
- Max_lengte (de lengte die de vis kan bereiken)
- Max_hoogte (de hoogte die de vis kan bereiken; is voor maar enkele vissen van toepassing)
- waterlaag (de waterlaag waarin de vis meestal vertoeft, met als mogelijkheden boven, boven-midden, midden, midden-onder, onder, overal)
- voedseleisen (het 'dieet' van de soort; plantaardig, dierlijk, slakken of/en droogvoer)
- sociaal (schoolvis, groepsvis, solitair, harem, koppel)
- kweek (manier van voortplanten; eilevendbarend, eierleggen (vrijlegger, schuimnestbouwer, etc), muilbroeder, ..)
- geslachtsonderscheid
- man
- vrouw
- familie (wetenschappelijke naam van de familie)
- eig_familie (de eigenschappen van de familie)
- Ph (zuurtegraad)
- Gh (algemene hardheid)
- KH (tijdelijke hardheid)
- temp (temperatuur van het water)
- min_lengte_aqua (minimum lengte van het aquarium)
- min_hoogte_aqua (minimum hoogte van het aquarium)
- min_inhoud_aqua (minimum liter inhoud van het aquarium)
- inrichting_aqua (voorstel voor beste inrichting van het aquarium)
- opmerkingen (nog eventuele aanvullingen over de soort)
- verkoopprijs (prijs van in de winkel)
- aankoopprijs (prijs van aankoop)
- Ltste_best (datum van de laatste keer dat deze vis is aangekocht)
Zo dat was het. Die laatste drie regels heb ik er bijgezet omdat die misschien kunnen gebruikt worden in de dierenwinkel waar ik werk, maar heel nuttig zullen ze niet zijn.
Als eerste normaalvorm had ik deze:
Vissoort
- *wet_naam
- synoniemen
- ned_naam
- eng_naam
- werelddeel
- kweekvormen
- max_lengte
- max_hoogte
- waterlaag
- voedseleisen
- sociaal
- kweek
- opmerkingen
- verkoopprijs
- aankoopprijs
- Ltste_best
Geslacht
- *Geslachtsonderscheid_ID
- *wet_naam
- man
- vrouw
Familie
- *familie
- *wet_naam
- eig_familie
Waterwaarden
- *waterwaarden_ID
- *wet_naam
- Ph
- GH
- KH
- Temp
Aquarium
- *Aquarium_ID
- *wet_naam
- min_lengte
- min_hoogte
- min_inhoud
- inrichting
Zag er eerst goed uit in mijn ogen, maar dan begon ik mij nog wat meer te verdiepen en ik denk niet dat dit helemaal juist is :s
Als tweede normalisatievorm had ik dan tenslotte nog dit:
Vissoort
- *wet_naam
- synoniemen
- ned_naam
- eng_naam
- werelddeel
- kweekvormen
- max_lengte
- max_hoogte
- waterlaag
- voedseleisen
- sociaal
- kweek
- opmerkingen
- verkoopprijs
- aankoopprijs
- Ltste_best
- *Geslachtsonderscheid_ID
- *wet_naam
- *Geslachtsonderscheid_ID
- man
- vrouw
- *familie
- *wet_naam
- *familie
- eig_familie
- *waterwaarden_ID
- *wet_naam
- waterwaarden_ID
- PH
- GH
- KH
- temp
- *Aquarium_ID
- *wet_naam
- *aquarium_ID
- min_lengte
- min_hoogte
- min_inhoud
- inrichting
Hm ja, da was't. zo heb ik het op papier, maar twas inmiddels ook wel al enkele dagen geleden dat ik er nog naar gekeken had, dus waarom ik wat gedaan had weet ik niet meer. Maar volgens mij klopt het toch wel helemaaaaaal niet :(
Wie o wie kan mij op weg zetten, of goeie tips geven?
Dankuwel aan iedereen die een nobele poging wil wagen...
-Wet_naam (de latijnse naam van de vissoort; dit zou mijn primaire sleutel worden dan)
- Synoniemen (Latijnse synoniemen van de vissoort; dus bv verouderde benamingen etc..)
- Ned_naam (de Nederlandstalige naam of namen)
- Eng_naam (de nederlandstalige naam of namen)
- Werelddeel (waarvan de vis afkomstig is)
- kweekvormen (De verschillende kweekvormen van de vis; dit laat ik mischien gewoon vallen want ik heb zo het gevoel dat het alles nog eens zo ingewikkeld maakt, zeker als ik dan ook van elke kweekvorm een foto en beschrijving zou willen geven?)
- Max_lengte (de lengte die de vis kan bereiken)
- Max_hoogte (de hoogte die de vis kan bereiken; is voor maar enkele vissen van toepassing)
- waterlaag (de waterlaag waarin de vis meestal vertoeft, met als mogelijkheden boven, boven-midden, midden, midden-onder, onder, overal)
- voedseleisen (het 'dieet' van de soort; plantaardig, dierlijk, slakken of/en droogvoer)
- sociaal (schoolvis, groepsvis, solitair, harem, koppel)
- kweek (manier van voortplanten; eilevendbarend, eierleggen (vrijlegger, schuimnestbouwer, etc), muilbroeder, ..)
- geslachtsonderscheid
- man
- vrouw
- familie (wetenschappelijke naam van de familie)
- eig_familie (de eigenschappen van de familie)
- Ph (zuurtegraad)
- Gh (algemene hardheid)
- KH (tijdelijke hardheid)
- temp (temperatuur van het water)
- min_lengte_aqua (minimum lengte van het aquarium)
- min_hoogte_aqua (minimum hoogte van het aquarium)
- min_inhoud_aqua (minimum liter inhoud van het aquarium)
- inrichting_aqua (voorstel voor beste inrichting van het aquarium)
- opmerkingen (nog eventuele aanvullingen over de soort)
- verkoopprijs (prijs van in de winkel)
- aankoopprijs (prijs van aankoop)
- Ltste_best (datum van de laatste keer dat deze vis is aangekocht)
Zo dat was het. Die laatste drie regels heb ik er bijgezet omdat die misschien kunnen gebruikt worden in de dierenwinkel waar ik werk, maar heel nuttig zullen ze niet zijn.
Als eerste normaalvorm had ik deze:
Vissoort
- *wet_naam
- synoniemen
- ned_naam
- eng_naam
- werelddeel
- kweekvormen
- max_lengte
- max_hoogte
- waterlaag
- voedseleisen
- sociaal
- kweek
- opmerkingen
- verkoopprijs
- aankoopprijs
- Ltste_best
Geslacht
- *Geslachtsonderscheid_ID
- *wet_naam
- man
- vrouw
Familie
- *familie
- *wet_naam
- eig_familie
Waterwaarden
- *waterwaarden_ID
- *wet_naam
- Ph
- GH
- KH
- Temp
Aquarium
- *Aquarium_ID
- *wet_naam
- min_lengte
- min_hoogte
- min_inhoud
- inrichting
Zag er eerst goed uit in mijn ogen, maar dan begon ik mij nog wat meer te verdiepen en ik denk niet dat dit helemaal juist is :s
Als tweede normalisatievorm had ik dan tenslotte nog dit:
Vissoort
- *wet_naam
- synoniemen
- ned_naam
- eng_naam
- werelddeel
- kweekvormen
- max_lengte
- max_hoogte
- waterlaag
- voedseleisen
- sociaal
- kweek
- opmerkingen
- verkoopprijs
- aankoopprijs
- Ltste_best
- *Geslachtsonderscheid_ID
- *wet_naam
- *Geslachtsonderscheid_ID
- man
- vrouw
- *familie
- *wet_naam
- *familie
- eig_familie
- *waterwaarden_ID
- *wet_naam
- waterwaarden_ID
- PH
- GH
- KH
- temp
- *Aquarium_ID
- *wet_naam
- *aquarium_ID
- min_lengte
- min_hoogte
- min_inhoud
- inrichting
Hm ja, da was't. zo heb ik het op papier, maar twas inmiddels ook wel al enkele dagen geleden dat ik er nog naar gekeken had, dus waarom ik wat gedaan had weet ik niet meer. Maar volgens mij klopt het toch wel helemaaaaaal niet :(
Wie o wie kan mij op weg zetten, of goeie tips geven?
Dankuwel aan iedereen die een nobele poging wil wagen...
Hallo kan iemand mij misschien helpen. Ik moet deze twee formulieren normaliseren. Daarna moet ik de gegevensstructuurdiagrammen maken, de uitkomsten integreren van het normalisatieproces en maak daarna het gegevensstructuur diagram van de ge?ntegreerde bestanden.
Het lukt me eerlijk gezegd nog geen eens om de 0e normaalvorm te maken.
Mocht er iemand zijn die het geheel voor mij kan maken, laat het me dan even weten, stuur je mailadress en dan kunnen we het over een eventuele vergoeding hebben.
Groeten
http://www.plaatjesupload.nl/bekijken/1360755.html
http://www.plaatjesupload.nl/bekijken/1360760.html
Het lukt me eerlijk gezegd nog geen eens om de 0e normaalvorm te maken.
Mocht er iemand zijn die het geheel voor mij kan maken, laat het me dan even weten, stuur je mailadress en dan kunnen we het over een eventuele vergoeding hebben.
Groeten
http://www.plaatjesupload.nl/bekijken/1360755.html
http://www.plaatjesupload.nl/bekijken/1360760.html
Ik hoop niet dat deze orderdatabase ooit in productie gebruikt gaat worden.
Er wordt in de tutorial namelijk een klassieke fout gemaakt: overnormalisatie.
De artikelprijs wordt weggenormaliseerd naar een aparte tabel, terwijl deze eigenlijk (redundant!) opgenomen dient te worden in de orderregel.
Artikelprijzen hebben namelijk de neiging om te veranderen. Zoals de database nu opgezet is, zou bij een prijswijziging ook de prijs van het artikel in de al uitgeleverde orders veranderen, en dat is niet de bedoeling.
Er wordt in de tutorial namelijk een klassieke fout gemaakt: overnormalisatie.
De artikelprijs wordt weggenormaliseerd naar een aparte tabel, terwijl deze eigenlijk (redundant!) opgenomen dient te worden in de orderregel.
Artikelprijzen hebben namelijk de neiging om te veranderen. Zoals de database nu opgezet is, zou bij een prijswijziging ook de prijs van het artikel in de al uitgeleverde orders veranderen, en dat is niet de bedoeling.
Vervolgens krijg je te maken met staffelkortingen, contractkortingen, actiekortingen, incidentele kortingen en verzin er nog maar een paar. Je database wordt dan ontzettend complex en je gaat je in de meest rare bochten wringen om de data maar niet redundant te hoeven opslaan.
Soms is een beetje redundantie echt beter ;-)
Edit: Wat ik denk ik vooral wil zeggen, is dat ik het geen handige keuze vind om een ordersysteem te gebruiken voor een normalisatie-tutorial. Als je het eenvoudig wilt houden, normaliseer je op de verkeerde manier, en als je goed wilt normaliseren wordt het veel te complex.
Soms is een beetje redundantie echt beter ;-)
Edit: Wat ik denk ik vooral wil zeggen, is dat ik het geen handige keuze vind om een ordersysteem te gebruiken voor een normalisatie-tutorial. Als je het eenvoudig wilt houden, normaliseer je op de verkeerde manier, en als je goed wilt normaliseren wordt het veel te complex.
Strikt gezien is de derde normaalvorm nog niet klaar zo. Postcode en plaats zijn namelijk functioneel van elkaar afhankelijk; veranderd de een dan veranderd de ander ook. Daarom dien je ze los te koppelen. Samen vormen ze een goede primaire sleutel maar dat moet je in dit geval dus ook niet doen:p
In praktijk worden plaatsnaam en postcode nooit losgekoppeld, omdat in praktijk nooit iets veranderd aan plaats/postcode combinaties, maar conceptueel is het goed om dit wel te illustreren. Er zijn veel situaties waarin dit wel van toepassing is.
Misschien is het goed om dit in ieder geval te vermelden. Ik lees hierboven dat je dit erg ver vind gaan, maar doe je dit niet in andere situaties waarin het van toepassing is dan ben je feitelijk gewoon niet in de derde normaalvorm gekomen.
In praktijk worden plaatsnaam en postcode nooit losgekoppeld, omdat in praktijk nooit iets veranderd aan plaats/postcode combinaties, maar conceptueel is het goed om dit wel te illustreren. Er zijn veel situaties waarin dit wel van toepassing is.
Misschien is het goed om dit in ieder geval te vermelden. Ik lees hierboven dat je dit erg ver vind gaan, maar doe je dit niet in andere situaties waarin het van toepassing is dan ben je feitelijk gewoon niet in de derde normaalvorm gekomen.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
Inhoudsopgave
- Normaliseren inleiding
- Nulde Normaalvorm
- Eerste Normaalvorm
- Tweede Normaalvorm
- Derde Normaalvorm
- Afsluiting
- Begrippen & Literatuur
PHP hulp
0 seconden vanaf nu