Normaliseren

Zal er ne keer naar kijken als ik wat meer tijd heb :D

Het ziet er goed uit, mooie voorbeelden, goed te begrijpen..

prima tutorial! dit scheelt een boel extra/dubbel werk als je dit volgt!

Ik snap er niet veel van je zou eens wat makkelijker woorden moten gebruiken :D

Zeg welk woord nog te moeilijk was en ik plaats de definitie bij de begrippen...

Elwin

Te weinig kleurplaten elwin ;)

Misschien wel aardig een iets pragmatischere tutorial te schrijven - maar interessant!

Elwin++

?Que?

Elwin

Misschien kun je eens een kijkje nemen op http://www.yapf.net/faq.php?cmd=100&itemid=700 :-)

Een mooie, duidelijke uitleg. Prima gestructureerd (eerst de regels, dan een voorbeeld).
Ik zou alleen de spelling nog wat normaliseren; er staan veel fyptouten in.

Wow, aan deze tutorial zal ik veel gaan hebben! Bedankt.

Normaal zie je de databasestructuur via
- voorafgaande programma-analyse
- ervaring

Maar voor een typische php gebruiker zal het misschien wel nuttig zijn.
En btw Boyce-Codd kan wel degelijk nuttig zijn, 4e en 5e al wat minder.

Goede uitleg, mijn complimenten!

Erg duidelijk is het wel. Alleen heb ik het toch anders geleerd ! BV in de 0NV al repeating groups noteren, en constante gegevens weglaten.

Het veld "plaats" is functioneel afhankelijk van de "postcode".
Je zou dus nog een tabel "Plaatsen" kunnen maken:

Plaatsen(Postcode PK, Plaatsnaam)

Of gaat dat te ver?

@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

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.

@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

Sorry, je heb gelijk nu zie ik het.

Bedankt voor je snelle reactie.

Groetjes Arjan

Coool thanks for je uitleg, k heb morgen toets over normaliseren..heheh

Hey maar op me toets moest ik een bachman diagram maken? uitleg plz

Hallo,
Weet iemand een goede site waar ik goede voor beelden kan vinden van het normalisren (stuklijst,leverencierlijst,voorraadlijst artikellijst enz,,
hoop snel iets te horen.
gr jop

morgen heb ik hier een examen over
ik zal het eens goed doornemen :D

Vind dit wel een super tutorial, well done! Ik snap het helemaal maar had toch even de vraag of je misschien wat andere voorbeelden heb die ik kan oefenen, zodat ik ook de wat grip krijg op de moeilijkere situaties.

Alvast bedankt

@j.
Ik kan niet even 1, 2, 3 een aantal voorbeelden verzinnen. Maar anders kan je misschien je eigen normalisatie maken. Dan op internet zetten en dan zal ik (of iemand anders die eerder is) kijken hoe het er uit ziet.

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? :)

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 ?

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?

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

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. :)

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.
_____________________________________________________________



_____________________________________________________________

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?

"Voor het bepalen van de indeling van de database bestaan verschillende technieken."

Welke technieken zijn er dan nog meer?

ik moet voor school een verslag maken over tabellen die ik moet normaliseren maar snep er geen bal van zou iemand me kunnen helpen of het een stuk voor me maken voeg me toe op msn alvast bedankt

Maar niemand heeft een id hoe je de bovenste tandarts rekening zou doen? Of dat de normalisering die ik daaruit kreeg goed is?

Goede tutorial, we gebruiken hem hier zelfs in de les als extra oefening en als extra uitleg. Je mag jezelf wel eens een schouderklopje geven :P.

Groetjes,
Ivan

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

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?

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

Heb het even doorgelezen en ziet er erg goed uit. Als ik deze tutorial bij m'n vorige tentamen had gehad had ik het glansrijk gehaald. Dinsdag de herkansing nu met deze tutorial dus zal hem wel gaan halen nu. Erg bedankt het ziet er netjes uit en is erg duidelijk.

Groetjes Martin

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. :)

Simpel toch? ;)

Elwin

thanks its a gread job . het is precies wat ik nodig had

http://www.yapf.net/Articles/ArticleView/789 ook een goede
maar deze is ook _erg_ goed!

Elwin u got a place in my heart, buddy!

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 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!!

@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.

Heb ik even geluk dat ik dit al heb gehad in school :-p
Ik vond het maar nix!

Prima uitleg, mijn compliment.

Cees

Inderdaad een mooie tutor.
Ik kan hem zeker en vast gebruiken, en ik heb zeker iets bijgeleerd!

Mvg Jens.

Dit is nog steeds een van de betere manieren om tot een goed database ontwerp te komen. Het wordt hier dan ook goed uitgelegd. Zelfs nog duidelijker dan bij mij op school :P

"Heb ik even geluk dat ik dit al heb gehad in school :-p
Ik vond het maar nix!"
Lol dit is de basis van database ontwerp!

"Zelfs nog duidelijker dan bij mij op school :P"
Welke school?

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

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.

@Kerbusch, Robert
Jullie hebben gelijk. Ik kan me niet indenken dat ik dit als sleutel heb verzonnen. Ik denk eerder dat het komt doordat ik de FK wilde aangeven, immers klantnr in de tabel order is afhankelijk van klantnr in de tabel klant. Ik heb het inmiddels aangepast.

Elwin

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...

@nathalie: Open gewoon een topic, dat is een stuk handiger dan hier in de tutorial. Jouw vraag gaat namelijk niet over de tutorial, maar over jouw specifieke situatie.

S.v.p. even verplaatsen!

Oei, excuse me, 'k weet mijn weg hier nog niet zo goed.. :s

Elwin, een groot compliment voor deze duidelijke tutorial. De boeken over PHP&MySQL die ik heb, blinken uit in onduidelijkheden omtrent het normaliseren. Je brengt helderheid met deze tutorial! (goeie tip Arjan K.)

Merci, eindelijk begrijp ik hoe het in elkaar zit. In mijn cursus van DB staat het ook halvelings uitgelegd, maar valt het niet te begrijpen.

Hartelijk dank voor deze mooie tut.

groeten Thomas

Compliment voor deze goede tutorial, heel goed uitgelegd.

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

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.

Dat is wil je eigenlijk niet redundant opslaan, maar temporeel. Dan is het alsnog mooi genormaliseerd en sla je niks te vaak op.

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.

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.

Waar het de afleverbon gif bestand gebleven?
Kan iemand het zelfde bestand of een nieuw bestand uploaden?

hier in GC staat hij er gewoon in

Wat is er gebeurd met de procesgegevens?
1. Verwijder alle procesgegevens.
X regeltotaal (procesgegeven)
X eindtotaal (procesgegeven)

Deze kolommen kunnen weggelaten worden omdat je sommen 'on-the-fly' kunt uitrekenen zonder kolom te gebruiken.