[acces] probleem met normaliseren

[St@m]

Goedenavond,

Ik ben nu al een tijdje bezig met een normaliseringsprojectje,

Ik wil de volgende gegevens graag in een database zetten, alleen krijg ik steeds een foutmelding.

voetbalclub
divisie
speler
datum
club
gele kaart
rode kaart
doelpunten

De bedoeling is dat ik strax een rapport kan uitdraaien waar de gegevens in deze volgorde op komen te staan:

Land:
Divisie:
Voetbalclub:
Speler:

gele kaart -- rode kaart -- doelpunt -- datum

Nu heb ik deze tabellen gemaakt:
(zwart is sleutel)

Tabel 1
land (relatie met land in tabel 2)

Tabel 2
land (relatie met land in tabel 1)
divisie (relatie met divisie in tabel 3)
speler (relatie met speler in tabel 4)

Tabel 3
divisie (relatie met divisie in tabel 2)
datum
club

Tabel 4
speler (relatie met speler in tabel 2)
gele kaart
rode kaart
doelpunt

Tot zover gaat het nog goed, wanneer ik nu een proefformulier wil maken, dan geeft acces de foutmelding:
'kan veld niett bijwerken'
Ga ik dan toch door, krijg ik de foutmelding:
'Een index of primaire sleutel kan geen Null-waarde bevatten'
Terwijl ik toch echt overal iets ingevuld heb.

Ik weet dat ik geen database topper ben, maar misschien zouden jullie mij kunnen vertellen wat ik fout doe, want ik kom er echt niet meer uit.

Alvast bedankt.

offtopic:
en ja ik heb teveel tijd als ik dit allemaal wil gaan bijhouden

edit:

verkeerde foutmelding

[ Voor 9% gewijzigd door St@m op 25-11-2002 21:35 ]

[robjanssen]

Wil je zoiets dan?

[St@m]

ja, zo heb ik het nu ook staan in het relatie scherm (zonder de xtra ID, waarvoor heb je die erbij gedaan?), maar ik blijf de foutmeldingen krijgen. (zie edit first post)

[robjanssen]

ID's zijn altijd beter als primaire keys dan een naam.
Wat nou als je bijvoorbeeld 2 spelers hebt met dezelfde naam.
Hoe maak je dan onderscheid tussen die 2?

Probeer mijn datamodel eens na te maken dan.
En kijk eens of het dan wel werkt?

[St@m]

Ik krijg nu de foutmelding: Yhe MS jet-database-engine kan geen record vinden in tabel speler waarvoor de sleutel overeenkomt met het veld (de velden) Speler ID

ok ik snap waarom er een ID gebruikt wordt bij speler, vanwege de spelers met dezelfde naam.
Ik heb de ID's bij divisie en Land weggelaten omdat die allemaal anders zijn.
Ik heb het ook geprobeerd met die ID's en ik kreeg dezelfde foutmelding, dus daar kan het niet aan liggen.

Maar denk je dat ik zo in de goeie richting zit te prutsen, ik heb iig wel het idee dat ik alweer een stapje verder ben, maar meer hulp is altijd welkom

[Verwijderd]

hahaha moeilijk he voor school op opdr8je maken

B.T.W. move SA

[ Voor 19% gewijzigd door Verwijderd op 26-11-2002 09:41 ]

[whoami]

Verwijderd schreef op 26 november 2002 @ 09:40:
hahaha moeilijk he voor school op opdr8je maken

B.T.W. move SA

Dergelijke opmerkingen zijn hier niet gewenst. Als je een mening hebt, onderbouw die dan. Heb je geen mening zwijg dan.
Reacties zoals de jouwe kunnen we missen als kiespijn.
En ik zie ook niet in waarom dit topic naar SA zou moeten.

[Bobco]

St@m schreef op 25 November 2002 @ 22:43:

Maar denk je dat ik zo in de goeie richting zit te prutsen, ik heb iig wel het idee dat ik alweer een stapje verder ben, maar meer hulp is altijd welkom

Het gaat er niet om of je uiteindelijk een werkend iets in elkaar zet maar om of je begrijpt waar je mee bezig bent. Normaliseren draait om het toepassen van een aantal regels die gegarandeerd leiden tot een datamodel waarbij je geen dingen dubbel opslaat. Altijd handig dus.

Waar je geod naar moet kijken is of je duidelijk kunt zien welke entiteiten (dingen) en attributen (eigenschappen van die dingen) je op wilt slaan. Het kiezen van de juiste sleutels is dus erg belangrijk. Zoals je bij de eniteit speler al hebt gezien is de naam van een speler niet erg geschikt als sleutel: de naam is immers niet gegarandeerd uniek.

Dat is de reden waarom in databases veel wordt gewerkt met 'kunstmatige' sleutels. Vaak is dat gewoon een getal. Voordeel is dat dit soort sleutels kort zijn en dus weinig extra ruimte innemen. Bovendien kun je er voor gemakkelijk voor zorgen dat ze gegarandeerd uniek zijn.

Je zou ook kunnen denken aan zoiets (sleutels in vet:

land(landCode, landNaam)
divisie(divisieCode, landCode, divisieNaam)
club(clubCode, divisieCode, clubnaam)
speler(spelerCode, clubCode, spelerNaam, rodeKaart, geleKaart, doelPunten)