Archief - [ALG] Normaliseren van database

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Obliv`

Legacy Member
Z!rtox zei:
samegestelde sletel dan... :p
is die tabel herstellinge nu juist?
en wat is de PK in zo ne samegestelde sleutel?

grtz en merci :love:

Die twee Fk's die in die tussentabel staan. Ofwel een extra veld dat je zelf kies (makkelijkste manier).

Bijv:
UwGekozenPk
VerwijzingNaarTabel1Id
VerwijzingNaarTabel2Id

Ik raad u aan om eens eerst wat opzoek werkt te doen ivm normalisatie (de normal forms, boyce-codd etc). Moeilijk is het echt niet, het vraagt gewoon wat tijd en oefeningen.

Z!rtox

Legacy Member
k thx...
mja, tijd hebbek dus nie want tmoet vrijdag af zijn :p

kzal drekt men resultaat ne keer poste se en dan zoudet nog ne laatste keer moge verbetere as ge wilt :)

AsinuS

Legacy Member
Z!rtox zei:
nu is alleen mijn vraag nu hoe de relaties moeten komen tussen die samengestelde sleutel en die echte tabel... :doh:

hoe .. uwe samengestelde sleutel is toch steeds opgebouwd uit 2 Foreign Keys .. dus bv bij CpuComputer, verwijst computer_ID nr de tabel Computer en cpu_ID naar de tabel CPU

De Relatie Computer - Herstelling moet wel 1 op veel zijn ipv veel op 1 zoals je nu hebt staan (een herstelling kan maar tot net 1 computer behoren, maar een computer kan wel meerdere keren hersteld worden)

AsinuS

Legacy Member
ziet er goed uit, alleen blijf ik niet snappen waarom iedereen perse nen extra id wilt meegeven aan zijn tussentabel .. de samengestelde sleutel is de primary key, dus bv die cpu_computer_ID is imo overbodig .. als je dat id weglaat is het wel nodig om in je tussentabel een veldje aantal bij te maken aangezien een computer bv 2 dezelfde latjes RAM kan hebben en dat zou problemen geven als je dat extra id weglaat ..

edit: wat die relatie betreft, gebruik mssql express ipv de kindjes database access die je nu gebruikt .. de relatie moet gelegd worden door zowel in tabel Computer en Herstelling de FK in te stellen

Z!rtox

Legacy Member
ok thx...

dan ng alleen nog die relatie van die herstellingen. As ik die relatie wil maken doe tem die atomatisch zo, en kzie nerges iets waarmee ik da zo kunnen veranderen :x

edit: mja, ben op stageplaats, en hier hebbe ze alleen ma access :( (en dat is eiglk ook het enige waarmee ik heb lere werken op school spijtig genoeg)

Z!rtox

Legacy Member
en mag ik in de hoofdtabel eigelijk de kolommen zoals "cpu_id" enzo niet verwijderen? die worden daar toch niet gebruikt?

en die klote relatie blijft ma tege werke he van herstellingen... :sop:

AsinuS

Legacy Member
Z!rtox zei:
en mag ik in de hoofdtabel eigelijk de kolommen zoals "cp_id" enzo niet verwijderen? die worden daar toch niet gebruikt?

en die klote relatie blijft ma tege werke he van herstellingen... :sop:

ja natuurlijk, als je met een tussentabel werkt (veel op veel dus) dan moet je geen FK opnemen aan je veel kanten, de relatie wordt net gelegd door te tussentabel .. in tblComputer mag dus mem_id en cpu_id enzo weg.

We helpen je hier wel, maar het is de bedoeling dat je alles snapt ook he, dat wij niet steeds in uw plaats moeten denken ..

Z!rtox

Legacy Member
mja, ksnap het wel... ma alleen zoas gelle het uitlegt, nie zoals mijne cursus er over bezig is :D

iemand nu misschien die mijn relatie kan late omdraaie bij die herstellingen, dan is mijne nest klaar... :$

Yamakazi

Legacy Member
Haal HERSTEL_ID eens uit je Computer tabel.
Je moet daat geen HERSTEL_ID hebben. Je cardinaliteit moet je ook omdraaien. 't Is 1 aan de computer kant en veel (infinite teken) aan de herstel kan. De join gebeurd met behulp van de comp_id.

crimineels

Legacy Member
Z!rtox zei:
samegestelde sleutel dan... :p
is die tabel herstellinge nu juist?
en wat is de PK in zo ne samegestelde sleutel?

grtz en merci :love:

Een tussentabel(associatie-entiteit) heeft een samengestelde sluetel==> dit is dus de PK.
Vb. bij de memory tabel is de PK de combinatie van computer_id, en memory_id.
computer_id = FK die verwijst naar de computer.
memory_id = FK die verwijst naar het gehuegen.
(FK-specificatie van zo'n tabel is altijd NNA(nulls not allowed) en DTC(delete target cascade) om ff moeilijk te doen :p

crimineels

Legacy Member
Yamakazi zei:
Haal HERSTEL_ID eens uit je Computer tabel.
Je moet daat geen HERSTEL_ID hebben. Je cardinaliteit moet je ook omdraaien. 't Is 1 aan de computer kant en veel (infinite teken) aan de herstel kan. De join gebeurd met behulp van de comp_id.

idd..
Die herstel_id moet uit de hoofd-tabel, want de koppeling wordt gelegd via computer_id..

En volges mé moete al die dinge als mem_id, bios_id, ... UIT de hoofdtabel, en die tblBios en al waarom doede die ni op dezelfde manier als al die linkse tabellen???

Yamakazi

Legacy Member
Omdat een bios geen tussentabel nodig heeft. Een pc kan maximum één bios hebben.

En die mem_id, hd_id moet inderdaad uit de hoofdtabel, dat had hij al zelf aangehaald.

Obliv`

Legacy Member
AsinuS zei:
ziet er goed uit, alleen blijf ik niet snappen waarom iedereen perse nen extra id wilt meegeven aan zijn tussentabel ..

Toch gewoon voor de eenvoud zeker :).

Op papier zou ik ook gaan om als sleutel de combinatie van die twee FK's te nemen, maar als ik het omzet naar de praktijk vind ik het gewoon veel aangenamer om met slechts 1 sleutelveld te werken.

AsinuS

Legacy Member
Obliv` zei:
Toch gewoon voor de eenvoud zeker :).

Op papier zou ik ook gaan om als sleutel de combinatie van die twee FK's te nemen, maar als ik het omzet naar de praktijk vind ik het gewoon veel aangenamer om met slechts 1 sleutelveld te werken.

nuja op zich maakt het niet zoveel uit, ik doe het niet, das mijn voorkeur en aan de andere kant, int neemt nu ook weer niet zoveel plaats in he in de db :D

Z!rtox

Legacy Member
nja, als ik met 1 veld als PK kan werken zal ik het ook doen, kheb nog nooit met 2 velden als PK gewerkt, dusja. En als ik met 2 velden als PK werk moet ik ook een extra veld aanmaken. Toch merci voor den informatie zodak weet dat het ook kan :)

kdenk da het af is... als iemand nog comments hierop heeft, be my guest

http://img99.imageshack.us/my.php?image=relaties3gr2.jpg

kheb veel bijgeleerd in deze tread, en kzou iedereen die me geholpen heeft wille bedanke. Zonder die zou ik nooit tot nen deftige database gekomen zijn. THX :)


edit: ahja, kheb die velden nog niet uit de hoofdtabel verwijdert, maar dat is ondertussen ook weer gebeurt.

AsinuS

Legacy Member
de samengestelde sleutel is dan ook 1 pk he .. en een extra veld .. dat veld moet er sowieso staan .. helemaal snap je het nog steeds niet imo

in je computer tabel moet je herstellingen_ID nog steeds verwijderen, dat staat daar niets meer te doen. (is eerder fout zelfs en zal problemen opleveren imo)

Z!rtox

Legacy Member
herstellingen_id en andere overbodige velden heb ik al uit de computer tabel gesmete, was ik nog vergeten (zie edit vorig post ;) )

en wat is dan wel je PK als je enkel met die samengestelde sleutel werkt (zonder zelf een PK veld bij aan te maken)? welk veld?

thx

Bubba

Legacy Member
Z!rtox zei:
herstellingen_id en andere overbodige velden heb ik al uit de computer tabel gesmete, was ik nog vergeten (zie edit vorig post ;) )

en wat is dan wel je PK als je enkel met die samengestelde sleutel werkt (zonder zelf een PK veld bij aan te maken)? welk veld?

thx

De combinatie van de velden is dan je PK.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan