invoeren in many-to-many relatie

Status
Niet open voor verdere reacties.

ikselle

Gebruiker
Lid geworden
25 mei 2009
Berichten
198
Mijn database is eindelijk genormaliseerd. Met een jointtabel heb ik een many-to-many relatie gemaakt. Met een form en subform kan ik nu bladeren door de database. Mijn vraag is : er moet een mogelijkheid bestaan om via de frm_leden bijvoorbeeld nummerplaten toe te kennen aan een individu. Maar hoe moet dat juist ? Wordt dat gedaan met een commandbutton die dan een appendquery oproept of kan dit ook op een andere manier ?
 

Bijlagen

  • Leden2.zip
    61,7 KB · Weergaven: 49
Met een jointtabel heb ik een many-to-many relatie gemaakt.
Ik hoop dat-ie gesmaakt heeft, die jointtabel :). Ik snap je vraag niet helemaal, want je hébt volgens mij de oplossing al gebouwd. Al is dat niet op de mooiste manier, maar dat is simpel aan te passen. Nummerplaten aan een gebruiker hangen doe je uiteraard door records aan te maken in de tabel [tbl_jointL2Nrplt]. Dat is dus de enige tabel die je nodig hebt op het subformulier, en niet de query die je nu gebruikt. Het hoofdformulier koppel je aan het subformulier op basis van het veld [Lid_id].

Dat laat alleen het 'probleem' van de nummerplaten over, maar ook dat is simpel op te lossen. Om te beginnen: de tabel is m.i. een beetje te mager ingericht. Ik mis de begindatum en einddatum van een uitgifte. Het kán wel zonder, maar dan heb je geen historie meer, en dat lijkt mij nu wel zo handig. Dus als je een kenteken uitgeeft, leg je tegelijkertijd de begindatum vast, en als je een kenteken inneemt geef je het nummer een einddatum. Als je dat inricht, is het ook heel simpel om overzicht te houden op uitgegeven nummerplaten (laatste record heeft een begindatum maar geen einddatum of de einddatum is groter dan de huidige datum), nummers die nooit zijn uitgegeven (hebben geen begin- en einddatum) en nummers die weer vrij zijn (laatste record heeft een begindatum en een einddatum). Nummers die je uit kan geven zijn dus de nummers die nooit zijn uitgegeven, en de nummers die weer terug zijn.

In een keuzelijst is de voorraad makkelijk te filteren m.b.v. bovenstaande criteria, dus als je een nummer uitgeeft verdwijnt hij bij een nieuw record uit de lijst. Het formulier moet dus een keuzelijst hebben die alleen de beschikbare nummers laat zien, die je dan vervolgens kan kiezen. En bij opslaan wordt dan de keuzelijst bijgewerkt voor de volgende keuze.
 
Beste Octafish,
1.Laat mij de vraag concreter stellen : als ik het formulier frm_leden open zie ik met welke nummerplaten Wattoo gekoppeld is. Ondertussen gebruikt hij bijv. ook een wagen met nummerplaat aaa555. Ik meende dat ik op een of andere manier dit zou kunnen invoeren via het subformulier.
2.Daarnaast begrijp ik niet goed dat je zegt dat enkel de jointabel nodig is in het subformulier. Dus geen query ? Dan zie je toch enkel onbeduidende cijfers in het subformulier. En wanneer je enkel deze tabel aanpast wordt dan automatisch de tbl_nummerplaten aangepast ?
3.De uiteindelijke bedoeling is om een applicatie te maken die buitenstaanders aan de ingang van een parking toelaat te noteren welk voertuig (nrplaat) met welke chauffeur (naam,voornaam) op welk moment (dag en uur) de parking opgereden is. Ikzelf zou (hopelijk kan ik dat door met front- en backend te werken) op basis van de ingevoerde gegevens een "moederlijst" met juiste gegevens (de gegevens die het meest voorkomen) aanmaken/bijhouden. Telkens wanneer een voertuig zich aanbiedt zou de buitenstaander aan de ingang van de parking dan de "moederlijst" kunnen consulteren en zijn keuze maken waarna deze gegevens in een aparte tabel bijgehouden worden. Het is enkel het binnenkomend verkeer dat genoteerd wordt.
4.Ik heb in een vorig bericht reeds gemeld dat ikzelf periodiek gegevens aangegeven krijg in de vorm van een excelbestand (dat eertijds aangemaakt werd toen de dieren nog spraken en dat gewoon angevuld wordt) waarin dan ook nieuw geregistreerde voertuigen en leden (zonder voertuig) met nieuwe/aangepaste gegevens (bijv. foto) vermeld staan.

Ik hoop hiermee een beetje duidelijkheid verschaft te hebben omtrent de opzet van mijn geknoei met access.
 
Laatst bewerkt:
Ad 1: dat moet kunnen. Maar ik raad je aan om dat te doen door de tabel te koppelen, niet een query. Zie ook het vervolg.
2.Daarnaast begrijp ik niet goed dat je zegt dat enkel de jointabel nodig is in het subformulier. Dus geen query ? Dan zie je toch enkel onbeduidende cijfers in het subformulier. En wanneer je enkel deze tabel aanpast wordt dan automatisch de tbl_nummerplaten aangepast?
Ad 2: dat klopt. Je wilt de combinaties van nummerplaat en LedenID vastleggen en dat doe je in de Jointabel. Nergens anders. Die jointabel kun je op twee plekken als subformulier gebruiken: op frmLeden en op frmNummerplaten. Die laatste heb je niet, maar die kun je dus ook maken. Op frmLeden is de jointabel gekoppeld op basis van Lid_ID, op frmNummerplaten op basis van Nummerplaat_ID. Wat zie je dan? Op frmLeden zie je de nummerplaten die bij een Lid horen, en op frmNummerplaat zie je de leden die bij een nummerplaat horen. En ja, als je niks doet verder dan alleen de tabel als subformulier plaatsen, dan zie je alleen de nummers (ID's).
Dus wat moet je nog doen? Je moet op het subformulier frm_jointL2Nrplt de tekstvelden Lid_ID en Nummerplaat_ID vervangen door Keuzelijsten met invoervak. Die krijgen allebei een rijbron op basis van resp. tbl_Leden en tbl_Nummerplaten. In die keuzelijsten kun je dan meerdere velden opnemen die je ook op het subformulier wilt zien, zoals bijvoorbeeld het veld [Nummerplaat]. Al kun je in de keuzelijst dan al stoppen, want naast Nummerplaat_ID zit er verder niks in de tabel :).
Als je de keuzelijsten hebt gemaakt, en het sleutelveld onzichtbaar hebt gemaakt (dat is heel belangrijk, want dat veld wil je niet zien), dan zie je dus, als je een nummerplaat kiest, de Nummerplaten en niet meer de getallen. En dat is precies wat je wilt!

Puntje 3 en 4 snap ik nog niet helemaal, maar dat hoeft hopelijk ook niet. Puntje 1 had nog een extraatje:
Ondertussen gebruikt hij bijv. ook een wagen met nummerplaat aaa555. Ik meende dat ik op een of andere manier dit zou kunnen invoeren via het subformulier.
Dus als ik het goed begrijp, zit degene die de auto's (en bestuurders) binnenlaat met de database voor zijn/haar snufferd, en zoekt die eerst de persoon op. Vervolgens kiest hij/zij in het subformulier uit de beschikbare (lees: gekoppelde) nummerplaten. En als de persoon met een andere auto (nummerplaat) aankomt, dan kunnen er twee zaken spelen: 1) de persoon-nummerplaat combinatie bestaat niet en 2) de nummerplaat bestaat niet. Je geeft jammer genoeg niet aan wat er in die gevallen moet gebeuren. Maar ik kan dus twee scenario's bedenken:

1. Nummerplaat bestaat, combinatie Lid+Nummerplaat bestaat niet.
In deze situatie zou de gebruiker een nieuwe combinatie moeten kunnen maken in de tabel [tbl_jointL2Nrplt]. Dat is vrij simpel te doen, want een keuzelijst (en die gebruik je straks) kent de gebeurtenis <Bij niet in lijst>. De gebruiker typt dus in de keuzelijst met invoervak het onbekende nummerbord, en op basis van deze gebeurtenis gaat Access eerst kijken of het nummerbord bestaat (zo niet: scenario 2), en zo wel: maak een nieuw record aan in de koppeltabel [tbl_jointL2Nrplt] en gebruik vervolgens dit record om de toegang te registreren. Probleem 1 is daarmee opgelost.
2. Nummerplaat bestaat niet, combinatie Lid+Nummerplaat bestaat niet.
Dit is eigenlijk een makkelijker probleem, want op het moment dat het nummerbord wordt opgezocht in de tabel [tbl_Nummerplaten], hoeft dat nummer alleen maar te worden toegevoegd aan de brontabel. Daarna is het gelijk beschikbaar voor registratie.

Scenario 1 is dus een klein beetje moeilijker, omdat een nummerplaat wél kan bestaan, maar op een andere persoon. Maar dat is dus simpel te checken, zoals ik hopelijk duidelijk heb gemaakt.

Gebruik je een FE-BE dan monitor je 'live' op alle tabellen, want je werkt dan zelf uiteraard ook via een FE. Dus de noodzaak van aparte tabellen lijkt mij niet nodig.
 
Laatst bewerkt:
Best Octafish,
Mijn grootste dank voor deze uitvoerige uitleg. Ik ga er mee aan de slag.
Dus als ik het goed begrijp, zit degene die de auto's (en bestuurders) binnenlaat met de database voor zijn/haar snufferd, en zoekt die eerst de persoon op. Vervolgens kiest hij/zij in het subformulier uit de beschikbare (lees: gekoppelde) nummerplaten. En als de persoon met een andere auto (nummerplaat) aankomt, dan kunnen er twee zaken spelen: 1) de persoon-nummerplaat combinatie bestaat niet en 2) de nummerplaat bestaat niet. Je geeft jammer genoeg niet aan wat er in die gevallen moet gebeuren. Maar ik kan dus twee scenario's bedenken:

1. Nummerplaat bestaat, combinatie Lid+Nummerplaat bestaat niet.
In deze situatie zou de gebruiker een nieuwe combinatie moeten kunnen maken in de tabel [tbl_jointL2Nrplt]. Dat is vrij simpel te doen, want een keuzelijst (en die gebruik je straks) kent de gebeurtenis <Bij niet in lijst>. De gebruiker typt dus in de keuzelijst met invoervak het onbekende nummerbord, en op basis van deze gebeurtenis gaat Access eerst kijken of het nummerbord bestaat (zo niet: scenario 2), en zo wel: maak een nieuw record aan in de koppeltabel [tbl_jointL2Nrplt] en gebruik vervolgens dit record om de toegang te registreren. Probleem 1 is daarmee opgelost.
2. Nummerplaat bestaat, combinatie Lid+Nummerplaat bestaat niet.
Dit is eigenlijk een makkelijker probleem, want op het moment dat het nummerbord wordt opgezocht in de tabel [tbl_Nummerplaten], hoeft dat nummer alleen maar te worden toegevoegd aan de brontabel. Daarna is het gelijk beschikbaar voor registratie.

Ja het was wat misleidend maar inderdaad iemand zit aan de ingang van de parking en krijgt een voertuig voor zich. Hij geeft de nummerplaat in en er zijn 3 mogelijkheden :
a) de nummerplaat wordt gevonden én de bestuurdersnaam staat correct genoteerd => de gegevens worden genoteerd in een inkomtabel met de datum en het uur
b) de nummerplaat wordt gevonden maar de bestuurder is niet correct : (mogelijk is de persoon wel gekend maar heeft hij zijn nrplaat niet laten registreren; de parkwachter kan dan op naam zoeken) in dat geval dient hij de (nieuwe )bestuurdersnaam samen met de nummerplaat weg te schrijven in de inkomtabel met de datum en het uur
c) de nummerplaat wordt NIET gevonden : (mogelijk is de persoon wel gekend maar heeft hij zijn nrplaat niet laten registreren; de parkwachter kan dan op naam zoeken) alle nieuwe gegevens worden in de inkomtabel weggeschreven.
De applicatie moet erg gebruiksvriendelijk en tweetalig (NL/F) zijn en de registratie moet op een duidelijke niet mis te verstane manier snel kunnen gebeuren (op het spitsuur is er immers veel inkomend verkeer en gehaaste chauffeurs zijn niet altijd de meest begripvolle geduldige mensen);).
Je zal je nu afvragen waarom alle gegevens zo wegschrijven, zelfs als ze dubieus zijn (de autopapieren worden immers niet gecontroleerd) ? Wel herinner je je dat ik deze gegevens toebedeeld krijg in een desastreus ingevuld excelbestand ? Door achteraf na te gaan aan welke frekwentie bepaalde nummerplaten met bepaalde bestuurders gekoppeld werden geeft dit me toch de gelegenheid om fout ingevoerde gegevens te onderscheiden van de juiste. Gelukkig hadden koetsen destijds geen nummerplaten want dan had ik die misschien ook nog teruggevonden. :)
 
Dan is mijn werkwijze dus voor jou prima te gebruiken. De derde variant (Chauffeur bestaat niet) is simpel op te lossen door de persoon eerst in te voeren. Maar als ik het zo lees, dan gebruik je de verkeerde insteek. Wat je dus uiteindelijk wilt, is snel combinaties van chauffeur en nummerplaat vastleggen. Die informatie sla je op in de tabel [tbl_jointL2Nrplt]. Die bevat een keuzelijst met een Chauffeurslijst, en een keuzelijst met de gekoppelde nummerplaten. Afhankelijk van de gewenste werkwijze kies je eerst een chauffeur, of eerst een nummerplaat. In het eerste geval wil je dat de keuzelijst cboNummerplaten de beschikbare nummerplaten laat zien (gefilterd op chauffeur dus), in het tweede geval wil je dat de keuzelijst chauffeurs laat zien die gekoppeld zijn aan de nummerplaat. Je moet dus checken welke keuzelijst als eerste is aangeklikt. Da's niet zo moeilijk trouwens.

OK, je hebt dus één van de twee keuzelijsten gebruikt en dan kan er dus één van de twee gebeurtenissen zijn opgetreden:
1. De waarde is gevonden (chauffeur of nummerplaat)
2. De waarde is níet gevonden

Variant 1
Dat houdt dus in dat ofwel de nummerplaat, ofwel de chauffeur niet in de brontabel is terug te vinden. De oplossing is dan simpel: persoon of nummerplaat moeten worden ingevoerd in resp. [tbl_Leden] of [tbl_nummerplaten]. De eerste variant is wat lastiger wellicht dan de tweede, want de laatste bevat alleen een nummerplaat. Kun je simpel toevoegen, is het record gelijk klaar. De eerste variant (leden) bevat behalve een aantal gegevens die je wellicht ook ingevoerd wilt hebben. Maar vanwege de snelheid van werken, is daar eigenlijk geen tijd voor: je vraagt dus alleen de naam. Daarmee maak je dan het leden record aan, en dan is dat ook in orde.

Ok, we hebben dus in de keuzelijst nu een ingevoerde waarde staan (dank zij de gebeurtenis <Bij niet in lijst> en die kan worden gebruikt in de tabel [tbl_jointL2Nrplt] (dat was immers de tabel/formulier waarop je werkt). Automatisch treedt dan variant 1 uit mijn eerdere verhaal: één van de twee koppelwaarden ontbreekt. Heb je een persoon toegevoegd, kun je er gif op innemen dat er geen nummerplaat is gekoppeld. Je wilt dan dus zoeken uit alle beschikbare nummerplaten. Zit die er bij, dan heb je een match en maak je het record aan. Zit die er niet bij, dan heb je dus ook een nieuw record nodig voor de nummerplaat. Dan treedt wederom de gebeurtenis <Bij niet in lijst> in werking: nummerplaat toevoegen.

Volgens mij heb je op deze manier een snel en waterdicht systeem.
 
Octafish, bedankt voor het opvolgen van mijn probleem maar het lukt mij niet met een combobox met invoervak in het subformulier meer dan cijfers te voorschijn te toveren. Ik had mijn frm_leden gebaseerd op een query maar dat raad jij af... Zal nog eens wat studie moeten verrichten. Heeft iedere beginneling hier problemen mee ? Je zou heel dat relationeel gedoe hiervoor weglaten. Dat maakt het vermoedelijk makkelijker.
 
Databases bouwen is een vak, en dat maakt het inderdaad een beetje lastig als je daar niet goed in zit; dan moet je je daar eerst in verdiepen. Veel mensen nemen daar de tijd niet voor, en dan heb je een probleem. Maar daar is het forum natuurlijk ook nog als achtervang :).

Ik ben al begonnen om jouw db aan te passen zodat je hopelijk kunt zien wat ik eigenlijk bedoel, want volgens mij zie je dat nog niet helemaal voor je. Ik zal morgen proberen een 'proeve van bekwaamheid' te overleggen :D.
 
Oef!! Na lang zwoegen en uitproberen heb ik eindelijk een manier gevonden om vanuit een formulier met subformulier een nummerplaat te KIEZEN die ik dan kan toevoegen.
1)Ik heb gemerkt dat ik in het subformulier van frmLeden door op een record te gaan staan een nummerplaat kan verwijderen. Maar wat ik niet begrijp is dat wanneer ik een nummerplaat bijv. 1lop558 bij vermaelen peter verwijder, dat die als wees achterblijft en de tabel kentekens. Nochtans is in de jointtabel een primairy key aangemaakt op de twee IDs en is er niemand anders die deze nummerplaat "gebruikt". Is dat normaal? Verwijder ik in dit subformulier niet rechtstreeks een record uit de tabel kentekens? Ik krijg immers de melding dat ik op het punt sta een record te verwijderen. Hoe kan ik dat oplossen?
2)Bovendien is er het probleem dat ik wel een nummerplaat kan kiezen maar geen nieuwe kan toevoegen.:eek:
 

Bijlagen

  • Leden2.zip
    89,6 KB · Weergaven: 39
Je kunt om te beginnen volstaan met alleen de tabel [tbl_jointL2Nrplt] te gebruiken, want door een keuzelijst met invoervak te maken voor het veld [Nrplaat_id] zie je toch al de nummerplaten. Het is dus niet nodig om het nummerbord ook nog eens uit de tabel tbl_Nummerplaten te halen. Daarnaast kun je die tekst ook nog eens gewoon uit de keuzelijst lezen, dus nogmaals: die tabel is niet nodig.

Wat betreft het verwijderen: de Verwijderknop maakt alleen het veld leeg (althans: bij mij ook) en verwijdert niet het record. Daarvoor moet je de keuzelijst bij de knop uitvouwen en vervolgens de optie <Record verwijderen> kiezen. Dan zal je zien dat het precies zo werkt als je wilt.
 
Beste OctaFish, bedankt voor je reactie en uw eerste opmerking heb ik begrepen en toegepast. Wat dat verwijderen betreft denk ik dat ik je niet goed begrijp. Je spreekt van een "verwijderknop" en van een "knop uitvouwen".
Wanneer ik het formulier FrmLeden open bij ID_lid 4 = De Roo ga ik op het blokje voor de nummerplaat poy267 staan; Dit krijgt dan een pijltje. Vervolgens druk ik op mijn klaviertoets "delete" (jouw verwijderknop ? of bedoel je de knop "delete" in de afdeling "records" in het menu ? ) en verschijnt de melding "You are about to delete 1 record ..." Ik bevestig en merk dat het vakje waar poy267 stond inderdaad leeg is maar de cursor knippert er nog. No problem -> ik klik ergens anders. Dan open ik de tabel tbl_nummerplaten en merk dat poy267 nog steeds bestaat. En klik ik dan op de uitvouwknop (is dat deze die jij ook bedoelt ?) dan zie ik dat de nummerplaat poy267 verweesd is achtergebleven. Ik weet dat sommige gegevens in tabellen en forms eerst moeten gerefresht worden maar dat dat niet nodig is wanneer je ze eerst sluit en dan weer opnieuw opent. Dat heb ik ook gedaan en het resultaat blijft hetzelfde.
 

Bijlagen

  • Leden3.zip
    86,4 KB · Weergaven: 41
Jouw db werkt bij mij prima, zonder enig probleem. Je kunt prima records toevoegen en weggooien in de tabel [tbl_jointL2Nrplt], (ook al gebruik je nog steeds een overbodige query ;) ). Maar volgens mij haal je nu een paar zaken door elkaar. De tabel [tbl_jointL2Nrplt] is een koppeltabel. Hier koppel je leden (uit de tabel [tbl_Leden] aan nummerplaten uit de tabel [tbl_nummerplaten]. Als je een record weggooit, is dat dus in de tabel [tbl_jointL2Nrplt]. Zowel het lid, als de nummerplaat, blijven gewoon staan in de onderliggende brontabellen. Gelukkig maar, voeg ik daar gelijk aan toe! Want zo hoort dat ook. Ik dacht dat het de bedoeling was dat je nummerplaten aan andere personen kon toewijzen, en dat kan natuurlijk niet als je ze gelijk weggooit. Wél kan ik mij voorstellen dat je ze archiveert. Maar dat vereist een aanpassing in de tabel [tbl_jointL2Nrplt] en de tabel [tbl_nummerplaten].
 
Beste OctaFish. Als ik het goed begrijp vernietig je dus enkel de koppeling tussen de verschillende tabellen (indien many-to-many). M.a.w. moet je om een nummerplaat te verwijderen een ander formulier maken waarin je dan weer gegevens (rechtstreeks) uit de tabel verwijdert.
De nummerplaten kunnen ook verkeerd ingegeven zijn (herinner je het feit dat ik de meeste gegevens aangegeven krijg via een excelbestand, aangemaakt door iemand anders. Soms staan daar nummerplaten in die niet kunnen bv 123@bk). Die moeten eruit. En het is weliswaar praktisch dat een nummerplaat opnieuw aan iemand naders kan toegekend worden maar dit gebeurt toch niet heel frequent en eigenlijk is dat logischerwijze te vermijden. Bedankt voor je hulp !
 
Eén van de belangrijkste, en moeilijkste, zaken bij het maken van een database is het juist inrichten van de database. Daarbij is het Functioneel Ontwerp een essentieel onderdeel: hierin beschrijf je wat er precies moet gebeuren. Feitelijk beschrijf je de processen die je wilt digitaliseren. Hoe belangrijk dat is, blijkt wel als ik een oud berichtje er bij haal (en in het achterhoofd de vorige draad).
3.De uiteindelijke bedoeling is om een applicatie te maken die buitenstaanders aan de ingang van een parking toelaat te noteren welk voertuig (nrplaat) met welke chauffeur (naam,voornaam) op welk moment (dag en uur) de parking opgereden is.
Wellicht niet helemaal duidelijk nog, maar daarvoor heb je de voorkennis nodig, waarin ik de vraag specifieker heb gesteld. Waar het om ging was jouw probleem dat verschillende chauffeurs met verschillende auto's geregistreerd moesten worden. Daaruit volgde m.i. dus de noodzaak van een koppeltabel, waarin je de verschillende combinaties vastlegt.
In je laatste bericht schrijf je:
En het is weliswaar praktisch dat een nummerplaat opnieuw aan iemand naders kan toegekend worden maar dit gebeurt toch niet heel frequent en eigenlijk is dat logischerwijze te vermijden.
Kijk, daar kan je dus in een database niet zoveel mee. Iets mag (en kan) in een tabel, of iets kan niet en mag dan ook niet. Iets gebeurt niet, en dan bouw je het ook niet, of iets gebeurt wél, en dan moet je het inbouwen. Of het dan vaak gebeurt, zelden of 1 keer per 20 jaar maakt dan niet zoveel uit. In het FO moet je dat echter wel degelijk aangeven, want op basis van die wetenschap bouw je de db.

'logischerwijze te vermijden' moet je dus omzetten naar: dat mag niet, of dat mag wél. Maar niet: "zou fijn zijn als het niet kan" want daar kun je niks mee in de db.

Terug dus naar je eigenlijke db. Je hebt dus kentekens, die je in ruw format (Excel) aangeleverd krijgt. Die moeten worden geschoond, anders mag je ze niet inlezen in de brontabel. Dat schonen doe je in een losse tabel, lijkt mij. Daarna importeer je de gegevens naar de brontabel. Idem dito met de personen. Ga je nu transacties vastleggen, dan is het dus níet zo dat één persoon meerdere voertuigen mag besturen, en dat één voertuig meerdere bestuurders kan hebben zoals eerder is besproken. Het is simpeler: als je de persoon kiest, kun je een aantal voertuigen selecteren, maar als je het kenteken weet, zit daar altijd maar één persoon aan vast. Is dat de eigenlijke situatie?
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan