gegevens van de ene tabel aan een andere tabel

allen,

graag had ik geweten of er een oplossing bestaat voor volgend probleem :

ik heb in access meerdere enkelvoudige tabellen laten maken door mijn zoon (die heeft meer basiskennis van access dan ik )

• ‘moleculen’
• ‘klasse’
• ‘type’
• ‘indicaties’

= gewoon telkenmale slechts een kolom ‘Id’ en een kolom ‘tekstvelden’ (zie eerste 4 werkbladen van bijlage)

daarna een samengestelde tabel ‘PRODUCTEN’ met producten en hun eigenschappen (zie werkblad 5)
waarbij

• besteld : aanvinken of niet (geeft waarde ‘waar’ of ‘onwaar’ weer bij export naar excel)
• product : productnaam (tekst invullen)
• molecule : vanuit de gegevens van de enkelvoudige tabel ‘moleculen’ = dropdown : meerdere kunnen aangeduid worden
• klasse : vanuit de gegevens van de enkelvoudige tabel ‘klasse’ = dropdown : slechts één keuze mogelijk
• type : vanuit de gegevens van de enkelvoudige tabel ‘type’ = dropdown : meerdere kunnen aangeduid worden
• opmerkingen : gewone tekst

vervolgens een tweede samengestelde tabel “ISP” : (indicaties-species-product) zie werkblad 6
waarbij

• indicatie : vanuit de gegevens van de enkelvoudige tabel ‘indicaties’
• SU1, SU2, … : aanvinken of niet (geeft waarde ‘waar’ of ‘onwaar’ weer bij export naar excel)
• product ; vanuit de gegevens van de tabel ‘PRODUCTEN’ : een dropdown : meerdere kunnen aangeduid worden

wat wil ik nu bekomen :
een derde finale samengestelde tabel ‘COMPENDIUM’ van de tabel ‘ISP’ en de tabel ‘PRODUCTEN’ ,
waarbij de rijen van de tabel ‘ISP’ eerst ontdubbeld worden (via [Product(en)].Value) zodat er maar 1 product per rij staat in de kolom ‘PRODUCT(EN)
en dan de eigenschappen (besteld, moleculen, klasse, type, …) van die producten (die de andere tabel ‘PRODUCTEN’ bevat) toegevoegd bij hun respectievelijke rijen en hier knelt het schoentje : hoe doe je dit laatste ?

resultaat zou dus werkblad 7 moeten zijn
en deze tabel zou ik dan willen exporteren naar excel alwaar ik dan kan rangschikken naar waar of onwaar, rijen & kolommen verwijderen etc
vb enkel de bestelde producten voor SU1 = werkblad 8

is dit mogelijk in access ?

met vriendelijke groeten,
Stefaan

Ik snap eerlijk gezegd niet waarom je niet de database meestuurt; nu hebben wij een extra half uur nodig om eerst je tabellen in Acces te zetten en te fatsoeneren. Verspilde tijd, want je moet ze vast al in de database hebben staan.

Hallo,
als ik je tabblad 5(producten) bekijk, neem ik aan dat je in Access een veld met multipele waarden gebruikt. Dat is misschien gemakkelijk in gebruik, maar maakt de dingen achteraf ingewikkelder om queries en rapporten te maken. Dus ik zou zeggen: als je verder wil werken in Access, pas dan de tabellenstructuur aan zodat deze meer genormaliseerd is en gebruik een koppeltabel daar waar je meervoudige keuzes wil. Dan kan je de gegevens naar hartelust bijeenbrengen met zoveel of zo weinig kolommen als je wil in queries, ze daar rangschikken en filtreren zonder naar excel te moeten gaan, maar je zal wel een kleine investering moeten doen om de database principes aan te leren.
Of je kan natuurlijk ook volledig in Excel werken. Daar kan je ook heel wat in bereiken en het werkt voor de meeste mensen veel intuïtiever. het is maar hoe je het liefst werkt.

nu met de database

Hallo,

het was inderdaad niet de bedoeling dat jullie de database gingen opstellen ;
ik dacht dat er voor het geschetste probleem een bepaalde bestaande oplossing of truc voorgesteld ging worden

in bijlage de geanonimiseerde database ;
die is gebaseerd op een 200 tal producten en een 60tal indicaties
alsook nog wat extra gegevens

hoe zit ze in elkaar : 7 enkelvoudige en 2 samengestelde tabellen
mijn zoon heeft 2 query's gemaakt ( ' 2 ISP query ' en ' 2 producten query ' )
die ik beide exporteer als excel (zie de bijlages)

en die ik dan combineer in een nieuwe excel ' 3 compendium ' (zie laatste bijlage) door copy/paste ,
in die excel verwijder ik dan de niet bestelde producten
en kan dan ook nog eens voor een bepaalde doelgroep enkel deze overhouden

het enige wat ik vooraf moet aanpassen per klant is in de tabel '1 producten' besteld of niet aanvinken

hopelijk maakt dit het duidelijker : kunnen wij die die stap die ik zelf doe door copy/paste in excel als een query instellen ?

Hallo Stefaan,

Het blijft, voor mij althans, een moeilijk te volgen verhaal.
Je vraagt aanvankelijk hoe je uit een aantal tabellen een andere kan samenstellen. Dat is op zich al geen goed idee. Als het goed is heb je alle informatie, dus waarom zou je die nog een keer vast willen leggen?
Later is de vraag of je een "stap" (wat die inhoudt is mij niet duidelijk) die je nu doet met "copy/paste in excel" ook met een query zou kunnen doen. Mijn eerste reactie is dan "vast wel" maar op grond van de gegeven informatie valt dat (voor mij) niet te beoordelen.

Ik denk dat het goed is terug te gaan naar het begin. Wat is de gegevensstructuur (welke tabellen, velden, relaties)? Zoals in een andere reactie al staat en ik eerder ook al opmerkte, is het gebruik van multiselect op z'n minst omstreden. Het kan, maar als je het doet, doe het dan consequent. Het vorige ontwerp met een productentabel met multiselect velden voor (onder andere indicaties en moleculen) kon ik in ieder geval nog begrijpen. Het huidige snap ik niet goed. Ik zie ook alleen maar een formulier om producten vast te leggen, maar niets over indicaties.

Minstens zo belangrijk is dat je in klare taal uitlegt welke informatie je aan de gegevensstructuur wilt onttrekken. Wij zien nu wat query's en de resultaten daarvan, maar dan ben je al een stap verder. Als je vertelt wat je wilt weten kunnen we wellicht een query voorstellen die dat beantwoordt.

Even een technische uitleg: Access kent geen verschil tussen "enkelvoudige" en "samengestelde" tabellen. Er bestaan alleen tabellen. Dus zet die rare termen zo snel mogelijk uit je hoofd . Hooguit praat je over stamtabellen en gegevenstabellen, al zijn die termen ook discutabel. Een stamtabel bevat dan de brongegevens die waarmee je de gegevenstabellen gaat vullen. Zoals bij verkoopacties, waarbij je klantgegevens koppelt aan bestelde artikelen. De KlantID's komen dan uit een brontabel, en een ProductID ook.

Terug naar de database . Ik snap die twee queries niet helemaal; dat zijn gewoon kopieën van de brontabellen. Dus wat is daar het nut van? Verder vind ik de tabel Producten niet deugen; die mag je m.i. niet voor bestellingen gebruiken. Daarvoor heb je toch echt een aparte tabel Bestellingen nodig. Die zie ik niet. Maar goed, op basis van je huidige tabel kun je uiteraard heel makkelijk in je query een criterium zetten voor de bestelde producten:


Leg eens uit wat de bedoeling is, want vooralsnog heb ik nog geen hoge pet op van het ontwerp .

Bedoeling : ik wil aan mijn klanten een lijst bezorgen van

• in welke omstandigheden ( = indicaties)
• ze welke producten

moeten gebruiken

PRODUCTEN
Er zijn een 200 tal producten die bepaalde eigenschappen hebben waardoor je ze kunt catalogeren

• klasse
• moleculen
• producent/verdeler
• toedieningswijze
• type behandeling

Alsook wat specifieke informatie zoals

• artikelnummer
• artikelnaam
• dosis
• duur
• interval
• wachttijd
• opmerkingen

Vandaar de tabel ‘1 producten’
Ik heb hier ook de kolom ‘BESTELD’ laten bijsteken ; van die 200tal producten gebruikt elke klant een 10 à 40tal producten die dus verschillend zijn per klant
Om het overzichtelijk te houden wil ik die lijst bezorgen met enkel die producten die hij effectief staan heeft, zoniet wordt het een onoverzichtelijke lijst.
Door ‘BESTELD’ aan te vinken bij die producten die hij gebruikt kan ik de rijen 'onwaar' bij export verwijderen en heeft hij enkel een lijst van zijn producten met hun eigenschappen

INDICATIES
Er zijn een 60tal indicaties.
Voor elke indicatie is er minstens één product geschikt. Meestal een 3tal producten gemiddeld maar er zijn ook enkele producten waarvoor er wel tot 40 producten in aanmerking komen.
En de klanten zelf hebben elk 1 à 4 doelgroepen (SU1 tem SU4) ; niet alle indicaties komen bij alle doelgroepen voor ; daarom vink ik ook aan welke indicatie bij welke doelgroep kan voorkomen.
Vandaar de tabel ‘1 ISP’ : Indicatie-Species-Product
Ik duid in deze tabel per indicatie aan

• bij welke doelgroep(en) ze kunnen voorkomen
• welk(e) product(en) er hiervoor geschikt zijn

Ik kan die dus ook exporteren : ik krijg een excel met evenveel rijen als er indicaties zijn maar in de cel “producten” kunnen er dus tot 40 producten in staan.
Daarom de query die de rijen ontdubbelt per indicatie in evenveel rijen als er producten aan die indicatie hangen.
Maar dan staan de eigenschappen en specifieke informatie die ik aan elk product toegewezen heb in mijn tabel ‘1 producten’ er nog niet bij.
En dat is nu net mijn finaal doel.
Misschien zit mijn insteek om tot die finale lijst te komen verkeerd ; hoe zouden jullie het aanpakken ; welke stappen zouden jullie nemen ?

NB om de achtergrond wat duidelijker te maken :
ik ben dierenarts en mijn klanten zijn varkensboeren
zij hebben 1 à 4 diercategorieën (niet gespeende biggen – gespeende biggen – vleesvarkens – fokvarkens)
een indicatie is vb griep, koorts, …
voor de griep komt zowel het product “griepvaccin” in aanmerking als “koortsremmer”
voor koorts komt enkel het product “koortsremmer” in aanmerking
door de griepvaccin “preventief” als ‘type behandeling’ in te de delen
en de koortsremmer “curatief” als ‘type behandeling’ in te delen
kun je voor de indicatie griep duidelijk maken ; de volgende producten komen in aanmerking :

• “griepvaccin” : dit is een preventief type behandeling en moet je zus en zo toepassen
• “koortsremmer” : dit is een curatief type behandeling en moet je zus en zo toepassen

maakt deze uitleg het duidelijker ?

met vriendelijke groeten Stefaan

Hallo Stefaan,

Dit maakt meer duidelijk, maar er blijven bij mij nog wel wat vraagjes over.

In het begin zeg je dat je je klanten een lijst wil bezorgen van welke producten ze waarvoor kunnen gebruiken. Even later zeg je dat op de lijst alleen de producten mogen komen die de klant besteld heeft. "Bestellen" klinkt voor mij alsof de klant zelf bepaalt welke producten hij wil hebben. Met de voorgestelde lijst vindt hij dus geen producten die hij niet eerder besteld heeft. Hoeft geen probleem te zijn, maar is wel een punt van aandacht.

Ik vraag me af of het handig is op de voorgestelde manier met "besteld" om te gaan. Op deze manier moet telkens als je een klant een lijst wilt sturen (bijvoorbeeld omdat hij een extra product heeft besteld), alle producten die hij eerder besteld opnieuw aanvinken (en alles wat aangevinkt was eerst weghalen). Een omslachtig en foutgevoelig proces lijkt me. Ik vraag me af of het niet beter is een klantentabel te introduceren plus een waarin je bestellingen (producten) per klant vastlegt. Je kan dan bijvoorbeeld ook een datum laatste bestelling (per klant/product) opnemen. Dat biedt de mogelijkheid (automatisch) een lijst met actuele producten voor een klant te genereren door alleen de klant aan te duiden.

Hoe je de lijst indeelt is denk ik afhankelijk van de vraag hoe de klant die gaat gebruiken. Indicatie/Doelgroep lijkt me een logische keuze. De lijst sorteer je dan daarop.

Ik vraag me af of alle (product)gegevens voor de klanten relevant zijn. Wat heeft de klant aan moleculen of de verdeler van een product? Die wil alleen weten: wat moet ik gebruiken in een bepaalde situatie? Voor jezelf is het wellicht wel van belang, maar je moet je afvragen of het op de lijst moet.

Ik maak zo meteen een schetsje van hoe ik denk dat je de database op zou kunnen zetten. Dat stuur ik na.

Hierbij ook mijn (aanzet tot) een database-schema. Het is uiteraard nog lang niet compleet, maar volgens mij gaat het in de kern hierom. De ontbrekende zaken zijn vooral details van het product.



De essentie is dus welke producten heeft een klant besteld en waar kunnen die voor gebruikt worden (indicaties/doelgroepen). Een lijst voor een klant kan je zo volgens mij eenvoudig met een query aanmaken.

Dag Peter,

Die finale lijst is iets dat we in feite moeten opmaken in opdracht van labels zoals een Bepork of Beter Leven (onder wie de veehouder zijn varkens commercialiseert).
Dit moet op maat van het bedrijf zijn en jaarlijks gereviseerd worden.
Uit ons veterinair softwareprogramma kan ik een lijst trekken met welke producten de klant over het laatste jaar heeft ontvangen. Het is een kleine moeite om die dan aan te vinken in de access database.

Ik wil de lijst zo opstellen dat als hij een probleem heeft (een indicatie), hij gemakkelijk kan vinden welke producten in aanmerking komen en hoe ze dan toe te passen.
En niet omgekeerd ; ik heb een product ; voor wat kan ik het gebruiken.

Niet alle productgegevens zijn inderdaad voor de klant relevant maar sommige hebben toch een goede notie (en dat moet ook) welke eigenschappen van belang zijn.

En de volledige productenlijst gebruiken wij intern ook op om producten te vergelijken ; vb een lijst trekken van
vb alle producten die die bepaalde molecule hebben,
vb alle ontwormingsmidddelen
of de vertegenwoordiger van die ene geneesmiddelenfirma komt langs ; we zullen de lijst met hun producten eens overlopen en updaten waar nodig, Â…

In ieder geval bedankt al voor de aanzet ; het schema zal mijn zoon wel begrijpen : ik steek hem aan het werk dit weekend

Hallo,

één kleine opmerkin:. Als DBA heb ik de voorgestelde opzet al zoveel keer gezien en verkeerd weten gaan dat ik een beetje huiverig sta voor het ontwerp. Als je over professionele software beschikt waar alle gegevens correct worden bijgehouden, zoals SAP of Microsoft Dynamics, ga daar dan geen eigen kleine app tussensteken die ook gegevens bijhoudt en verwerkt, in Access of welk ander programma dan ook. Trek de gegevens uit de database, exporteer deze naar excel en formatteer/bewerk die daar zodat ze leesbaar zijn voor de klant. Als er 40 producten in een cel staan, dan is dat de manier waarop deze opgevraagd worden in de originele software. Geen enkele database gaat meerdere gegevens in één cel bijhouden. Maar je kan die wel op deze manier opvragen. In plaats van ze op deze manier op te vragen en dan een andere app gebruiken om dit recht te zetten is het meestal gemakkelijker om de originele vraag aan te passen zodat de gegevens in een bruikbaar formaat worden opgeleverd.