normalisatie: meer op meer op meer

[feint]

Hallo allemaal,

Ik loop op het moment tegen een probleem en ik hoop dat jullie mij kunnen helpen.

Ik ben bezig met het normaliseren van gegevens voor het opzetten van een databae maar loop tegen het probleem aan dat ik een meer op meer op meer relatie heb.

Het zit als volgt:
Ik heb persoons gegevens (id, naam, adres, postcode etc), competentie gegevens (id, naam) en afdeling gegevens (id, naam, type, afdelingshoofd).

Deze hebben allemaal een meer op meer relatie op elkaar dus:
1 afdeling kan meerdere personen hebben maar 1 persoon kan op meerdere afdelingen gewerkt hebben (of werken).
1 afdeling kan meerdere competenties hebben, maar 1 competentie kan ook op meerdere afdelingen voorkomen.
1 persoon kan meerdere competenties halen, maar 1 competentie kan ook bij meerdere personen behaald worden.

hier loop ik dus op vast.

ik dacht eventueel een koppeltabel te maken met alle 3 de sleutels (persoon_id, afdeling_id en competentie_id) maar dan kan ik nooit van tevoren vaststellen op welke afdeling welke competenties behaald kunnen worden.

Ik wil per afdeling kunnen opvragen welke competenties mogelijk zijn.
Ik wil per persoon kunnen opvragen welke competenties die heeft voltooid, wanneer en op welke afdeling.
ik wil per competentie kunnen opvragen op welke afdeling deze behaald kan worden.

heeft iemand een idee, want ik zie het namelijk niet meer :<

ps. wist niet of dit het goede forum was maar dit gaat uiteindelijk over access db

 

[OctaFish]

Je zult dus koppeltabellen moeten toevoegen, bijvoorbeeld Persoon_Competentie, Persoon_Afdeling etc. In al die koppeltabellen neem je in ieder geval de sleutelvelden op de te koppelen tabellen. Volgens mij kan een afdeling geen competentie hebben, maar een persoon wel. M.b.v. de koppeltabellen kun je een query maken die per afdeling via de koppeling [Persoon_Afdeling] laat zien welke competenties er zijn via de koppeling Persoon_Competentie.

 

[feint]

Dit heb ik inderdaad al geprobeerd en kwam uit op de volgende tabellen
persoon
persoon_afdeling
afdeling
persoon_competentie
competentie

Maar dit gaf niet het gewenste resultaat.

Een afdeling heeft in het concept wel degelijk een competentie.

Als voorbeeld bijv een ziekenhuis.
Een persoon kan bijvoorbeeld een injectie zetten leren op de kinderafdeling of de gehandicaptezorg maar bijvoorbeeld weer niet leren op de afdeling voor apotheker (nu noem ik maar een voorbeeld, maar het geeft denk ik duidelijk weer waar ik heen wil).

 

[OctaFish]

Dan heb je ook nog een tabel Afdeling_Competenties nodig. Werkt verder op dezelfde manier.

 

[feint]

Krijg je dan geen driehoek verhouding?
Ik dacht dat dit niet mocht in een database?

misschien dat ik niet helemaal snap wat je bedoelt maar ik denk dat je het volgende bedoelt:

competentie heeft relatie op competentieafdeling
competentieafdeling heeft relatie op afdeling
afdeling heeft relatie op afdelingpersoon
afdelingpersoon heeft relatie op persoon
persoon heeft relatie op persooncompetentie
persooncompetentie heeft relatie op competentie

 

[OctaFish]

Zoiets, ja. Een driehoekverhouding is dit niet, omdat de competenties die je aan een afdeling koppelt niet dezelfde zijn als de competenties die je aan een persoon hangt. Hooguit gebruik je dezelfde brontabel. Maar dat geeft verder niks. Je zou in die tabel Competenties zelfs nog via een kolom kunnen aangeven of een competentie geldt voor Persoon, Afdeling of Beide. Je kunt dan op de bijbehorende formulieren daar dan nog apart op filteren.

 

[feint]

bedankt voor je reacties.
Ik ga ermee aan de slag

 

[feint]

Ik heb het een en ander eens uitgeprobeerd en ben tot het volgende resultaat gekomen .

Is dit wat jij bedoelde?

Nogmaals bedankt voor je replies!

 

[OctaFish]

Lijkt mij prima! Overigens kun je de relaties vanuit de Competentietabel nog weglaten, als je de tabellen voedt vanuit formulieren, waarbij je de keuzelijsten uit de Competentietabel haalt. Referentiële Integriteit is een belangrijk aspect van een genormaliseerde database, maar met keuzelijsten dwing je de integriteit ook af. En uiteindelijk gaat het er om dat je tabellen goed gevuld worden, met de juiste gegevens. Overigens raad ik het niet af, maar het zou eventueel kunnen, mocht je in de knel komen...

 

[feint]

Top, bedankt voor je antwoord.
De database doet het op het moment nog altijd goed. Ik voed hem uiteindelijk idd via formulieren (heb hem op het moment met de hand gevuld voor te testen maar uiteindelijk zou ik via de formulieren de informatie invoeren).

Ik zal jou advies in mijn achterhoofd houden mocht ik in de problemen komen.

Bedankt voor je adviezen!