Incidentele invoer, middels knop toevoegen in formulier

[frans83]

Goedenavond,

Voor mijn bedrijfje probeer ik een database in elkaar te zetten. Ik kom een aantal uitdagingen tegen en hoopte dat hier een oplossingen voor zijn. Ik wil boekgegevens invoeren middels een formulier. De tabel die achter het formulier zit heeft mogelijkheden om 6 auteurs toe te voegen. Nu is het doorgaands zo dat een boek een enkel autaur bevat maar het komt voor dat er meerdere auteurs zijn. Om het formulier zo compact mogelijk te houden zie ik het liefst één invoerveld voor de auteur. Middels een knop naast het invoerveld wil ik de mogelijkheid bieden om extra auteurs toe te voegen. Dit heb ik geprobeerd door een formulier aan te maken waarin de auteurs ingevoerd kunnen worden. De knop in het hoofdformulier verwijst daarnaar. Werkt opzich prima. Het punt is dat als de knop wordt geactiveerd, hij altijd naar de eerste record gaat. Als ik in record 1000 zit van het hoofdformulier, en ik druk op de knop om een extra auteur toe te voegen zou ik graag ook op record 1000 terecht willen komen voor het toegvoegen van de extra auteurs i.p.v op record 1. Hoe krijg ik dit voor elkaar?

Alvast bedankt.

Mvg Frans

 

[OctaFish]

Allereerst welkom bij HelpMij!

De tabel die achter het formulier zit heeft mogelijkheden om 6 auteurs toe te voegen.

Hier snap ik het eigenlijk al niet meer; in een béétje database kan je honderden auteurs aan een boek toevoegen. Hoe kan het dat die van jou al bij 6 vastloopt? Hoef je geen antwoord op te geven, want dat weet ik natuurlijk al lang: je hebt de database niet goed opgezet, maar in je tabel 6 auteurvelden opgenomen. Dus dat mag je gelijk aanpassen, want je hebt de database niet (goed) genormaliseerd en dat moet je toch echt wel doen. Dat betekent: een aparte tabel voor je auteurgegevens die je aan de tabel Boeken koppelt. En daarmee ben je dus van de beperking van de 6 auteurs af, en je database is gelijk genormaliseerd!
Zal je zien dat je andere probleem ook gelijk opgelost is

 

[frans83]

Beste OctaFish,

Allereerst bedankt voor je reactie. Ik begrijp wat je bedoeld met het normaliseren van je database. Voor mijn probleem met het formulier denk ik dat het verder niets uitmaakt hoe je de database inricht (al blijft het een goed advies). Of ik nou een aparte tabel maak met auteurs of een tabel maak zoals ik heb omschreven, het probleem met invoeren blijft hetzelfde. Ik wil namelijk één invoerveld zien voor één auteur en een link naar de mogelijkheid om 6 of 200 extra auteurs toe te voegen. Dus of die link nou naar een aparte "auteur" tabel gaat of naar het tabel zoals ik heb omschreven. Hij blijft op recordnummer 1 terecht komen. Misschien begrijp ik je niet helemaal, dat kan ook uiteraard.

Ik hoor graag van je.

Mvg Frans

 

[OctaFish]

Voor mijn probleem met het formulier denk ik dat het verder niets uitmaakt hoe je de database inricht

Dat zie je denk ik toch verkeerd; als je de db correct inricht, kun je met een doorlopend subformulier je auteurs toevoegen. En dan heb je helemaal geen last van je probleem. Als je het subformulier te groot vindt, dan gebruik je een tabcontrol om het subformulier op te zetten; dan gebruik je een apart tabje om je auteurs (op de correcte wijze) toe te voegen.

 

[frans83]

Beste OctaFish,

De optie tabcontrol heeft al mijn obstakels verholpen. Dit is precies wat ik zocht Hartelijk dank!

 

[frans83]

Toch heb ik nog wel een vraag over het normaliseren; ik heb een tabel gemaakt voor de stamgegevens (inititalen, geboorteland, etc.) van een auteur. Elke record is één auteur. Vervolgens heb ik een hoofdtabel (boeken) waar 6 (of 200) kolommen gedefineerd zijn als auteur. De tabel stamgegevens heeft een een-op-veel relatie met het hoofdtabel. Hoe zou ik deze opbouw nog kunnen normaliseren?

Alvast bedankt voor je tijd!

 

[OctaFish]

Je tabel Boeken is dus totaal niet genormaliseerd, zoals je het nu brengt. In beginsel heb je een aparte (sub)tabel nodig die bijv. Boeken_Auteurs heet. Hierin zet je een BoekID dat verwijst naar de tabel Boeken, en een AuteurID dat verwijst naar de tabel Auteurs. En dan kun je gaan vullen . Je kunt deze tabel zowel op het formulier fBoeken zetten (dan zie je welke auteurs bij welk boek horen) en op het formulier fAuteurs. In het laatste geval zie je in één oogopslag welke boeken een auteur (mede) heeft geschreven. Het mes snijdt dus aan 2 kanten!

 

[frans83]

Zoiets?

 

[OctaFish]

Niet helemaal goed. Je tabel [tblAuteur] zou bij mij dus [tblBoeken_Auteur] heten, en de tabel [tblAuteurStam] had ik dan [tblAuteur] genoemd. Maar dat is naamgeving, dat is niet het probleem. Dat zit 'm in de tabel [tblAuteur] waar nu 2 velden in staan die er uit moeten en één van de velden au_auteur# zou je moeten koppelen aan de tabel [tblAuteurStam]. Precies andersom dus als je nu hebt gekoppeld. Het gaat er namelijk om dat je een één-op-veel maakt tussen auteurs en boeken! Dus één auteur mag veel boeken schrijven, en één boek mag door veel auteurs worden geschreven.

 

[frans83]

Volgens mij begin ik het te snappen. Is het nu beter?

 

[OctaFish]

Yep :thumb: De tabel Specificaties gebruik je dan om de in- en verkoop van de boeken bij te houden? In welk geval een boek meerdere keren ingekocht en verkocht kan worden. Dus dat is dan goed ingericht. De tabel Foto gebruik je dan om de staat van het boek bij inboeken of zo vast te leggen, dus daar is een één-op-veel relatie ook goed. Ik heb dan alleen mijn vraagtekens bij de koppeling Specificaties (zou ik eerder Transacties o.i.d. hebben genoemd, maar ach, het is maar een naam) met Artikelgroep. Die koppeling heb je namelijk ook al met Boeken. Daar vind ik hem ook thuishoren, niet (ook nog eens) bij Specificaties.

 

[frans83]

Ik heb het specificaties genoemd omdat de staat, de foto's, en de prijzen in de tabel komen te staan. De andere gegevens zijn bron gegevens en kunnen inderdaad of meermaals of in andere staat terugkomen. Tevens heb ik meerdere artikelgroepen. Al deze artikelen komen samen in de specificatiestabel. Is de koppeling dan echt overbodig, ook na het zien van het volgende?

Over specificaties gesproken; bijgaand kan je ook zien dat ik brontabellen heb aangemaakt voor de verschillende staten van een artikelgroep. Een boek kan geen afspeelproblemen hebben dus heb dat om die rede aangemaakt. Ook bij het invoeren zodra ik artikelgroep "boek" heb gekozen, ik geen staten van dvd kan kiezen. Deze wil ik het het liefst aan specificaties koppelen. Is dat verstandig en hoe kan ik dat het beste doen?

Ik je alvast erg bedanken voor je hulp. Je hebt me met je reacties erg op weg geholpen!!! Eveneens met de cursus die je hebt gemaakt :thumb:

 

[OctaFish]

Is de koppeling dan echt overbodig, ook na het zien van het volgende?

Je zal het wel niet leuk vinden om te horen, maar de helft van je tabellen kan weg . Het is prima om artikelgroep aan Specificaties te hangen, zeker als je alle objecttabellen vervangt door één tabel (en dat kan echt). Daarbij moet je in het achterhoofd houden dat je alle gemeenschappelijke gegevens in één tabel opneemt (en als je naar je velden kijkt, zie je dat er nogal wat zijn) en de productspecifieke koppel je dan via de Artikelgroep. Elke eigenschap die je wilt beschrijven zet je dan weg in een apart detailrecord, waarbij de specificatie dan uit de SpecDetails wordt gehaald.
Maar breng in ieder geval de objecten onder in één tabel, want dat zal je leven een stuk makkelijker maken...

 

[frans83]

Je zal het wel niet leuk vinden om te horen, maar de helft van je tabellen kan weg

Ik ben op zoek naar een goede basis. Vind het dan niet erg om daar aan te sleutelen :thumb:

als je alle objecttabellen vervangt door één tabel (en dat kan echt)

Hoe richt ik de objecttabel dan in met bijvoorbeeld acteur-auteur-artiest, 3 verschillende eigenschappen van 3 verschillende objecten? Auteur heb ik ingericht zoals je eerder heb geadviseerd. Hoe zou ik acteur daarbij in kunnen voegen?

Als ik dat snap kunnen de 4 "staat" tabellen dan ook worden vervangen door 1 tabel?

 

[OctaFish]

Jij ziet onderscheid tussen acteur-auteur-artiest? Ik niet, voor mij zijn dat 3 dezelfde entiteiten: persoon namelijk. En net zoals een boek door één persoon (auteur) kan zijn gemaakt maar ook door meerdere, kan een cd ook door één persoon (artiest) zijn gemaakt of door meerdere. Kijk voor de grap ook eens naar je (nog niet gekoppelde) tabellen Staat_Boek, Staat_Cd etc: allemaal dezelfde velden! Hoort dus ook in één tabel thuis.
Dat je bij een boek niet de speelduur vast wilt leggen, en bij een cd niet het aantal bladzijden, snap ik uiteraard wel. Maar dat hoeft ook niet, als je de db goed opzet. Met dus een aparte tabel waarin je alle kenmerken beschrijft en daar een typeID bijzet. Die tabel bevat dus records met daarin een ID, een TypeID (CD, Boek etc), en een Omschrijving (Speelduur, Bladzijden, gewicht etc). Op je formulier breng je de hele handel dan samen. Dus daar voeg je een artikel in (CD, Boek, DVD) en in de detailrecords in het subformulier heb je dan voor de specifieke details een keuze uit de bij het geselecteerde type behorende detailopties. Dus kies je in het hoofdformulier voor boeken, dan zie je in het subformulier alleen de details voor boeken. En zo verder. Die details zijn dus verder hetzelfde: je vult een record met een verwijzing naar het objectID (Boek, cd etc), een verwijzing naar het detailobject (Speelduur, dikte), eventueel een eenheid (die je op dezelfde manier opbouwt) en de feitelijke waarde. Als dat verder geen rekenkundige functies behoeft kun je daar en tekstveld van maken, zijn dat altijd getallen, dan is een getalveld beter.
Maar je moet dus (nogmaals: in mjn ogen; je kunt het best op jouw manier doen, als je dat echt wilt; je zou niet de enige zijn) alles bekijken op atomair niveau. Oftewel: wat is het kleinste deel dat overeenkomstige waarden bevat. Daarbij is een boek een object, één ding; net als een dvd of een boek. Met een inkoopprijs, een inkoopdatum, een verkoopprijs, een verkoopdatum etc. Met hooguit een paar wisselende eigenschappen die je dus apart wegschrijft. Met de door mij geschetste onderverdeling moet je dan een heel eind kunnen komen. Maar denk dus klein

 

[frans83]

Wederom bedankt voor je (uitgebreide) reactie. Ik heb flink zitten prutsen maar kom er niet helemaal uit. Ik begrijp wel wat je bedoeld.

Die details zijn dus verder hetzelfde: je vult een record met een verwijzing naar het objectID (Boek, cd etc), een verwijzing naar het detailobject (Speelduur, dikte)

[tblArtikelgroep] bevat typeID (objectID); 1 boek, 2 dvd, 3 vinyl, 4 cd
[tblArtikelInvoer] komen de ingevoerde records in te staan
[tblAtrikelBron] staan de bron gegevens; typeID 1 - pagina's, dikte, gewicht / typeID 2 - speelduur, type dvd, type hoes / TypeID 3 etc.

Hoe koppel ik ze dan aan elkaar? Ik begrijp niet hoe het formulier aangestuurd moet worden. Bij welke trigger weet het formulier dat bij het kiezen van een dvd hij de brongegevens moet pakken van [tblArtikelBron] type id 2?



Als ik dit begrijp kan ik inderdaad flink vooruit. Hopelijk kan je me uit de brand helpen. Alvast bedankt!

 

[frans83]

Beste OctaFish,

Heb je hier misschien nog antwoord op? Ben het al een paar dagen aan het knutselen, met al je vorige tips kom ik er prima uit. De laatste tip houd me alleen erg bezig (misschien had je die tip nooit moeten geven )

Zou het mogelijk zijn een simpel voorbeeld te maken van de structuur? Daar zal je me echt onwijs mee helpen! Ik hoor graag van je.

 

[OctaFish]

Ik heb niet echt een voorbeeldje liggen, want ik heb zelf niet zo'n multi-disciplinaire db nodig, dus ik heb 'm nooit gemaakt. Voor mij dus ook onbekend gebied . Wel eens een muziek db gemaakt, en een Film collectie, maar dan heb je het dus over dedicated databases (voor één product). Omdat ik niet al te veel tijd vrij heb, sta ik ook niet te popelen om hem zelf te bouwen, al was het maar omdat data kloppen al helemaal geen hobby van mij is . Maar als je een db meepost, dan kan ik daar uiteraard wel naar kijken.
In essentie komt mijn idee hier op neer, en je zult zien dat je het dan best goed begrepen hebt! De tabel [ArtikelBron] koppel je aan de tabel [ArtikelGroep], want de details daarin zijn afhankelijk van de groepen die je maakt.

[tblAtrikelBron] staan de bron gegevens; typeID 1 - pagina's, dikte, gewicht / typeID 2 - speelduur, type dvd, type hoes / TypeID 3

Levert dus de volgende records op:

1 - typeID 1 - pagina's
2 - typeID 1 - dikte
3 - typeID 1 - gewicht
4 - typeID 2 - speelduur
5 - typeID 2 - type dvd
6 - typeID 2 - type hoes
7 - TypeID 3 - etc

Daarnaast heb je dus nog een tabel nodig waarin je de details vastlegt van de verschillende artikelen. Die zet je dan als doorlopend formulier op je hoofdformulier.
Ga je een artikel invoeren op je formulier, dan kies je dus eerst een Artikelgroep. Deze keuzelijst dient dan de keuzelijst cboArtikelBron die op het subformulier staat te filteren zodat je in die keuzelijst alleen de opties ziet die bij de gekozen artikelgroep horen. En dan is het een kwestie van invullen wat je weet. Voor het mooie zou je de keuzelijst cboArtikelBron nog kunnen filteren op opties die nog niet gebruikt zijn. Hiermee voorkom je dat je een detail 2 keer toevoegt.
En om het af te maken kun je de gebeurtenis <Bij niet in lijst> gebruiken om nieuwe waarden toe te voegen aan de tabel ArtikelBron.

 

[frans83]

Hallo OctaFish,

Ik heb hem even snel opgezet. Ik wil simpelweg de structuur weten, de rest kan ik verder uitbouwen. Het frustreert me dat ik het niet snap .

https://www.wetransfer.com/downloads/1da2e4a03ca2ac5be2e2b5ec742dfc6220151104200348/9bc91d3f3b72e51334a05098e419757a20151104200348/418e94

 

[OctaFish]

Ik heb de namen van wat tabellen aangepast (niet logisch, vond ik) en er een nieuwe tabel ArtikelDetails aan toegevoegd. Die dient als basis voor het subformulier. De keuzelijst op dat subformulier is afhankelijk van de keuze op het hoofdformulier. Overigens heb ik ook de keuzelijsten in tabellen verwijderd. Lees mijn berichtjes er maar op na waarom je die dus niet moet gebruiken .