normaliseren uitleg acces cursus

[deheugden]

Hallo,

Ik heb nog wat vragen m.b.t. de cursus van acces(het normaliseer gedeelte) welke hier op de site staat.


1- is de pk altijd gelijk aan de fk? Dus Pk is klannr en fk is ook klantnr? of zijn daar uitzonderingen op, zo ja, hoe?

2- kan ik meerdere fk's of pk's in een tabel hebben?

3- in de uitleg van de acces cursus staat ook : Kleur en maat zijn deelbaar , maar hoe zijn kleur en maat dan deelbaar?

4- voor de 2e nv, staat het volgende vermeld:
Voorraad: de kleur van het artikel is niet belangrijk om de voorraad te weten

maar waarom is dat niet van belang? het is toch belangrijk om te weten of je nog rood, geel of blauw genoeg op voorraad hebt?

dank voor de hulp.

 

[OctaFish]

Je had deze vraag beter in het topic van de cursus zelf kunnen stellen, want dan blijft de uitleg beschikbaar (want in het eerste topic), want dat is daar voor, maar dat geeft verder niks .

Ad 1: Een Primary Key neem je altijd in zijn geheel over in de gekoppelde tabel, dus die zijn inderdaad identiek. Die PK mag best uit meer velden bestaan, die dan ook allemaal als FK moeten worden overgenomen. Puur uit gemakzucht doe ik dat maar heel zelden.

Ad 2: In een tabel is altijd maar één PK aanwezig. Een sleutel is primair zodra die uit het minimale aantal velden bestaat dat nodig is om de sleutel te definiëren. Een combinatie PC+Huisnummer+Woonplaats kan wél een sleutel zijn, maar is (in Nederland zeker) niet primair, want het veld Plaats is niet nodig; de combinatie PC+Huisnummer is namelijk ook al uniek. PC+Huisnummer is dus in dit voorbeeld wél een primaire sleutel.
Een koppeltabel kun je koppelen aan meerdere tabellen. Die koppeltabel zal zelf een PK hebben, maar de koppelingen (FK's) zijn koppelingen met de PK van de hoofdtabellen. Je hebt dan dus meer FK's in die tabel zitten.

Ad 3: Een jas kan in meerdere kleuren leverbaar zijn, en schoenen (geldt uiteraard ook voor kleding) in meerdere maten. Dat is dus de deelbaarheid.

Ad 4: zoals je het opschrijft: ja . Het heeft weinig zin om in de winkel een blauwe broek te verkopen als de voorraad daarvan 0 is, en de klant dan een gele aan te reiken omdat je er daar 12 van hebt. Maar ik weet zo uit mijn hoofd niet (moet het hoofdstuk er nog even op na lezen) in welke context ik dat geschreven heb. Dus wellicht dat het in de tekst wel klopt.

 

[deheugden]

ok, dank je. Normaliseren is, wanneer je het een tijd niet gedaan hebt, best wel lastig

 

[OctaFish]

Kan ik mij indenken . Hoewel het eigenlijk niet veel meer is dan logisch denken; waar is een bepaald attribuut (veld) van afhankelijk, waar is een entiteit (record) van afhankelijk? Als je dat ziet, dan weet je eigenlijk al of je dat gegeven moet overzetten naar een eigen tabel of niet. Zo is de keuze om plaatsnamen op te nemen in de tabel Klanten grotendeels afhankelijk van de vraag of je lokaal werkt nationaal, of internationaal. Een plaatselijke bakker die een adressenbestand bijhoudt van zijn lokale klanten, kan best met tekstvelden volstaan voor de adressen. Die hoeft geen postcode database abonnement te kopen. Werk je landelijk, dan is dat ineens een veel betere optie om een koppeling te gebruiken met de postcode tabellen. Afwegingen maken dus!