Waarden van tabelcombinaties kiesbaar maken.

[EGeen]

Dag mensen,

Ik heb 4 tabellen waarin een locatienaam staat opgeslagen, voorbeeld:
Tabel 1: De wagen
Tabel 2: De koffer
Tabel 3: Het vakje
Tabel 4: Opbergmethode

In een andere tabel staat welke combinaties mogelijk zijn tussen de 4 tabellen (zoals bijlage 2 - Accessvraag2)

In de laatste tabel die hiermee werkt (de inventaristabel), moet straks in een formulier worden aangegeven welk product(ProductID (tabel producten) hoeveel er ligt en op welke plaats.
Heb de relaties in het voorbeeld gewist, aangezien ik even draad kwijt ben. (De relaties van Tabel 1 t/m 4 hebben mijn inziens geen waarde).

Hoop dat iemand mij hiermee kan helpen. Heb het idee dat het inzicht in Access als ik dit snap aardig wordt vergroot.

Bij voorbaat dank,

Erwin

 

[EGeen]

Hiervoor had ik trouwens relaties tussen de verschillende tabellen. Waarbij de combinatietabel(multi) gekoppeld was door één lijn met de inventaris. De tabel inventaris had eerst één ID voor de combinatietabel (de combinatie is dan toch duidelijk).

Alle tabellen werken met autonummering als primairy key. Het verwijzen met een keuzevak met invoervak met twee kolommen waarvan de eerste kolombreedte op 0 wordt gezet snap ik. Echter hij wordt dan opgeslagen als nummer in de tabel. Dit is goed voor de relatie, echter als een andere tabel hier weer mee verder gaat werken in een formulier krijg ik alleen de cijfers ervoor aangezien die zijn opgeslagen.

 

[OctaFish]

En toch moet je het zo doen. Overigens vind ik in ieder geval de naamgeving van je tabellen Plaats1 t/m4 niet logisch, en de constructie an sich al helemaal niet. Eén tabel met alle mogelijkheden zou voldoende moeten zijn, gekoppeld aan een tussentabel die je koppelt met Inventaris. Voor elke combinatie krijg je dan in wat jij MultiPlaats noemt dan een record, i.p.v. alle opties er op deze manier al inzetten. Nu is de structuur totaal niet genormaliseerd, en dat kan dus heel simpel wél.

 

[EGeen]

Klinkt een stuk beter. Ik neem aan dat u het bedoeld zoals in de huidige bijlage toegevoegd. Echter hoe zorg ik er dan voor dat als ik een naam van bijvoorbeeld een auto of koffer verander, de tabel met combinaties ook alles wijzigt?

Daarnaast houd ik het probleem dat ik in een formulier bij het invoeren van de inventaris werk met het een cijfer (ID van combinatietabel). En er moet dus niet steeds een nieuwe record worden aanmaakt bij een querry van meerdere tabellen. Ditzelfde kom ik ook tegen in andere tabellen.

Heb een database (of eigenlijk vele bestanden, tabbladen en rijen informatie) in Excel. En dit wil ik dus op deze manier straks inzichtelijk kunnen hebben. Merkt al, begin afgezien veel leeswerk met weinig kennis van Access. Wil het graag leren, want zie zeker de voordelen.

 

[OctaFish]

Het is al beter, maar om te kunnen zeggen of je de goede kant op gaat, weet ik nog te weinig van de db. Zo heb je 4 velden (Voertuig, Koffer etc) die ik nog niet begrijp. Ik zou de relatie ook de andere kant op leggen, want tblInventaris zou in mijn ogen de één kant moeten zijn. Dus leg eens uit wat je eigenlijk aan het maken bent?
Overigens is je hoofdvraag (geen cijfers zien, maar waarden) simpel op te lossen als de structuur eenmaal goed is. Je gebruikt dan namelijk een query als basis voor je formulier waarin je met Keuzelijsten de Plaatsobjecten kiest (één veld, één keuzelijst, op een doorlopend formulier zodat je voor elk item een eigen record maakt) en die keuzelijst slaat dan het getal op, maar laat de tekst zien. Nogmaals: als de structuur klopt .

 

[EGeen]

Alleereerst bedankt dat er zo wordt meegedacht. Heb nog even een stukje van de database in de bijlage gestopt. Groot gedeelte eerst weggelaten. Moet eerst dit maar eens goed snappen en doorkrijgen. Het lijkt nu al een groot zooitje waarschijnlijk .

Het is simpel gezegd gewoon een opsomming van alle producten die in de verschillende wagens ligt van de stichting waarvoor ik werk. Dit wordt nu in excel gedaan, maar kan mijn inziens makkelijker. In de wagens staan o.a. koffers met een bepaalde indeling. Daarnaast komen producten natuurlijk vaker voor. Een verbandrolletje van een bepaalde maat hebben we natuurlijk niet één keer mee tijdens een dienst. Vandaar een aparte tabel inventaris die uitgaat van de alreeds gemaakte producten.

Waarom had ik (de plaatsen, - en nu nog steeds de categorie, merk etc in aparte tabel): Ik wil ervoor kunnen zorgen dat de tekst in deze tabellen automatisch ook in andere cellen wordt aangepast als deze is uitgekozen. Op deze wijze zoals dat nu is kan dat volgens mij niet. (dus bijvoorbeeld de naam "spoedkoffer" veranderen in iets anders)

Heb een bijlage erin gedaan van een voorbeeld uit Excel. Dit is één tabblad in één voertuig. Hebben dus meerdere voertuigen (en een magazijn die ik hier voor het gemak ook onder schaar). Bij producten die hetzelfde zijn is er verschil tussen merk, houdbaarheidsdatum etc, heb voor het overzicht en duidelijkheid sommige dingen even wat veranderd in het screenshot.

Veel plaatsen zijn verschillend, dus om het duidelijk te kunnen aangeven wou ik per plaats aangeven waar wat precies ligt. Als er een combinatietabel is, dan zijn de plaatsen in ieder geval goed duidelijk waaruit kan worden gekozen. Het is logisch dat in een bepaalde vak van een koffer meerdere materialen liggen. Vandaar dacht ik de één-op-veel relatie richting de inventaris.

De categorie etc zoals dat is bepaald naar de productlijst is gedaan omdat als er een product is, er altijd één categorie is waaronder het product valt. Dit product kan dan één of meer types hebben. Maar om ervoor te zorgen dat er geen type wordt uitgekozen dat niet bij het product past heb ik dat zo in elkaar gezet.

Merk en maat is zoals ik eerst de plaatsen ook had. Om de reden dat de wagen/koffernaam altijd kan worden aangepast waardoor ook de inventaris etc die deze wagen bevat automatisch wordt aangepast.

In het voorbeeld van de plaatscombinatietabel slaat hij dan ook alleen nummers op. Echter deze gegevens zou het formulier dan weer moeten gebruiken om de plaats te kunnen ingeven. (in gegevensblad of iets dergelijks). Echter hij moet dan natuurlijk geen nieuwe records aanmaken maar de alreeds gemaakte combinaties nemen. Daarnaast natuurlijk de namen zichtbaar ipv de cijfers. Echter denk dat het mij nu niet lukt door de structuur.

Hele rits tekst. Excuus

 

[EGeen]

Ik heb nog even zitten proberen, maar kom er nog niet helemaal uit om alles netjes automatisch te laten veranderen bij wijziging en goed te koppelen. Heeft iemand een simpele opzet hoe dit volgens de regels van normalisering zou moeten worden uitgevoerd? Met eventueel enkele voor mij te nemen vervolgstappen? Wil graag zelf proberen, lezen en leren, maar in dit geval kom ik er niet uit wat nou de officiële manier is.

Wil het graag zelf snappen zodat ik het het vervolg en andere databases kan maken voor onze stichting.

Bij voorbaat dank.

 

[OctaFish]

Het helpt als je een database kunt meeposten met wat relevante data. Voor Persoonsgegevens moet je dan natuurlijk wat dummy data invoeren; het gaat er om dat we kunnen zien welke (soorten) gegevens je nu echt gebruikt, zodat we op basis daarvan kunnen aangeven hoe je gegevens nu bij elkaar zet in tabellen. Want ik zie eigenlijk bij jou nog steeds velden waarvan ik denk: dat is geen veld, dat is een waarde. Maar dat kan ik nu gewoon niet goed zien. Dus graag een databaseje!

 

[EGeen]

Mijn excusses, wist niet dat ik onduidelijk was. Hierbij even een opzetje van de database. Er staat nu weinig in aangezien alles nu natuurlijk in de excelbestanden staat.

Enkele kanttekeningen:

- het formulier is later aangepast en werkt dus nu niet goed meer.
- Ieder product heeft wel een categorie, productnaam, maat en merk, maar niet altijd een Type of Soort.
- Bij 'plaats' is er altijd een auto, echter soms een koffer, of alleen een opbergmethode. Dus het kan voorkomen: Auto1, Spoedkoffer, niets, Hechtset.
- Tblcontroledatums gaat altijd over een koffer of auto, niet over bepaalde subplaatsen of opbergmethoden. Ook in de plaats kan het dus zijn dan maar een gedeelte is ingevuld.
- TblStreeflijst is een lijst die aangeeft wat er in bijvoorbeeld een spoedkoffer moet zitten. Zodat de huidige inhoud van een spoedkoffer kan worden vergeleken en er bijvoorbeeld een gemist product wordt aangegeven.
- Tlb Geschiedenis is een lijst die mijn wijzigingen in de materialen zal noteren.
- Complience etc is een gedeelte die zal worden bijgehouden voor certificering.

Natuurlijk verwacht ik niet dat dit meteen wordt opgelost, maar ongeveer is dat mijn doelstelling. Denk dat het er misschien nog niet helemaal duidelijk wordt, maar het gaat me in eerste instantie alleen om het gedeelte wat voorgaand is uitgelegd. Dus het gedeelte plaatsbepaling, inventaris, productlijst(en aanverwant).

Ik wil deze database gebruiken om snel materialen aan te passen in de database. Wat nu lastig is met Excel is, als ik iets uit een auto haal, dit aantal aan moet passen en dit weer in een ander bestand moet gaan toevoegen. Hierdoor duurt het erg lang.

Hele tekst, maar zie het als achtergrondinformatie(Net als het voorgaandescreenshot van Excel)

 

[OctaFish]

ik snap nog steeds weinig van je database, als ik eerlijk moet zijn. Zo heb je het in je tekst over Producten, maar je hebt geen tabel Producten. Wel zie ik een tabel [TblProductlijst], die wellicht als zodanig zou kunnen dienen, maar die mist velden als [Productnaam]. Daar heb je een aparte tabel voor?? Snap ik helemaal niks van; één product heeft toch maar één productnaam? Dus niet logisch zo. Kijk ik verder, dan zie ik een tabel [Type] met een één-op-veel relatie met [TblProductnaam]. Logisch, want één type kan bij meerdere producten horen. Ware het niet dat je hem niet koppelt aan producten maar [TblProductlijst], maar aan [tblProductNaam]. Weg verband! Sowieso kan één product aan meerdere types worden gekoppeld, wat eventueel nog wel zou kunnen. Maar dan is de naam van de tabel niet goed, die zou dan iets als [Product_Type] moeten heten om aan te geven dat het hier om combinaties van producten en types gaat. Nu heb je nog een tabel [Soort], die in mijn ogen verkeerd om is gekoppeld aan [Product_Type], maar dat komt omdat je het verkeerde veld gebruikt voor de koppeling. Een veld dat nog niet in [Product_Type] zit overigens.

De tabel [TblPlaatsen] bevat in mijn ogen de verkeerde velden. Ik zou zo'n tabel maken met de velden [PlaatsID] (Autonummer), [Plaats], [Soort] en [Opbergmethode]. Deze tabel gebruik je dan in een één-op-veel tabel met je voertuigen.
En dan de controletabellen; die zitten volgens mij ook veel te ingewikkeld in elkaar. Ik zou je functioneel ontwerp wel eens willen zien, want ik denk dat er wat ontwerpfoutjes in zitten. En dan kun je beter de basis opnieuw bekijken, zodat je beter kunt zien wat er zou moeten gebeuren.

 

[EGeen]

Haha, ik snap het gedeelte relaties steeds beter, maar mis waarschijnlijk nog een paar beetjes cruciale info blijkbaar haha.

Ik heb een tabel met 'tblproductlijst' gemaakt waarin het geheel van alle producten zou moeten komen te staan naar mijn idee. Het klopt dat een product meer één naam kan hebben. Echter omdat een product zoals bijvoorbeeld een infuusnaald/pleister/zwachtel veel verscheidenheid heeft in types en maten komt de naam vaker de lijst te staan. En volgens mij staat in de cursus van normalisatie dat een productnaam dan in andere tabel moet worden opgeslagen(bij mij Tblproductnaam) zodat hij niet vaker in de lijst voorkomt en zodat de naam later eventueel kan worden aangepast. Voorbeeld:

Categorie: Wondbehandeling
Productnaam: Zwachtel
Type kan zijn: Hydrofiel, cambric, ideaal
Maat is in alle soorten: 4 cm x 4 mtr, 6 cm x 4 mtr etc.

De naamgeving van Product-Type is een goede, hierover had ik niet zo nagedacht. Ik had hem gekoppeld aan productnaam omdat hij afhankelijk is van die naam. Wist alleen niet of ik hem ook dan nog moest koppelen met de hoofdtabel. Dacht om het invullen van de producten te vergemakkelijken en het type afhankelijk is van de productnaam die je invult deze alleen aan deze moet worden gekoppeld. De koppeling tussen type en soort is op dezelfde wijze gemaakt. Het verschil snap ik dus niet.

Functioneel ontwerp is er niet, waarschijnlijk door mijn gebrek aan kennis. Ik heb in ieder geval mede door jou laatste post weer een paar ideeën waarmee ik even verder kan. Het gedeelte van controle moet nog verder worden uitgedacht. Echter ik mis nog de kennis. Ik zit steeds te worstelen met de nummers van de autonummering die in twee tabellen verder weer moeten worden gebruikt.

In ieder geval zal ik morgen wat verder gaan sleutelen. Ben in ieder geval zeer dankbaar voor alle gegeven hulp.

 

[OctaFish]

Zoals je het nu uitlegt is 'Productnaam' nog steeds geen productnaam, maar een categorie (zwachtels). Niks mis mee, maar noem het dan ook zo . Een productnaam zou zijn: 'Hydrofiele zwachtel 4x4'. En een ander: 'Hydrofiele zwachtel 6x4'. Daar zitten herhalende woorden in, maar dat mag echt wel, dat ga je er niet uitnormaliseren. Je gebruikt toch ook geen aparte tabel voor Tussenvoegsels? Een goed ontwerp bevat ook (zie ook eerder bericht) de juiste tabel- en veldnamen. Als je alles wél uitsplitst, heb je doorgaans toch een identificerend veld nodig, wat dan vaak het (unieke) artikelnummer is.

't Is jammer dat je niet eerst een functioneel ontwerp hebt gemaakt, want dan had je een overzicht voor de input en output in je hoofd. Als je gelijk gaat bouwen, dan mis je dat, met als gevolg dat het moeilijk te zien is wat het grote verband is tussen de verschillende gegevensblokken. Eigenlijk ga je eerst kijken wat de informatiebehoefte is, en die ga je vertalen naar een database ontwerp.

 

[EGeen]

Volgende poging, zal proberen het beter uit te leggen en te beperken tot dit kleine gedeelte van de database.

In de bijlage wederom een screenshot. Wederom lijkt het meer op mijn eerste post. Dit gedaan mede omdat ik in een reactie van OctaFish in een andere vraag las zo veel mogelijk met tekstwaarden te werken ipv nummeriek zodat de uiteindelijke waarden in de tabel komen te staan zodat duidelijk is wat het is. Maar hier en verder gaat het bij mij fout.

Toelichting tabellen
Alle velden zijn tekst, afgezien van de PlaatsID en de TestID.

De linker vier tabellen bevatten puur de namen van de voertuigen of plaatsen. (TblVoertuig, Koffer, Vak, Opbergmethode)
De middelste tabel geeft aan welke combinaties er mogelijk zijn van de 4 plaatsnamentabellen. Hij heeft eventueel een ID, echter hier wil ik denk ik niet mee werken.
De rechter tabel geeft de inventaris aan. Hierin staan de verschillende producten(vanuit andere tabel met een ID) met de aantallen van het product op deze desbetreffende plaats.

Wat wil ik bereiken
Ik wil bereiken dat er nooit een plaats kan worden ingevuld in de inventarislijst die niet bestaat. Vandaar de combinatietabel.
Ik wil bereiken dat als ik een naam van een voertuig verander in de eerste linker tabel het wordt veranderd in alle andere tabellen (dus een relatie)
Ik wil voor het gemak de waarden van de plaats (dus de vier velden allemaal in de rechter tabel(inventaris) opslaan. (mag ook anders als iemand dit goed kan uitleggen)

Mogelijke oplossingen
Ik heb het geprobeerd zonder een relatie met een opzoektabel waarbij hij de combinatietabel gebruikt. (Vier relaties uit de combinatietabel naar de inventaris lukt niet blijkbaar). Hierbij met behulp van vier keuzelijst met invoervak (Select Distinct) de waarden kiezen. De tweede keuzelijst heeft dan een voorwaarde dat hij alleen de waarden kiest waarbij in de eerste kolom "Quad" is gekozen.
- Nadeel hiervan is, hij werkt niet de waarden bij. Als ik bijvoorbeeld de naam Quad aanpas, wordt deze niet veranderd in de inventaristabel.

Ik heb het geprobeerd met een relatie tussen de Combinatietabel.PlaatsID(één) naar Inventaristabel.PlaatsID(veel). Echter wanneer ik hiervan een query maak krijg ik geen waarden (want inventaris is nog niet gemaakt) en een foutmelding. Tevens maakt hij als ik iets invul in deze query een nieuwe record aan in de combinatietabel. Dit moet dus niet, want er moet gekozen worden tussen deze plaatsen.

Ik hoop dat ik mijn doel etc goed heb beschreven. Vind het nog lastig werken met query's etc.

 

[EGeen]

*** Achtergrondinfo ***
Als uitkomst van de database wil ik proberen het geheel snel werkbaar te maken. Hierbij bedoel ik dat als ik een lijst met producten voor mij heb van een bepaalde koffer in een auto, deze snel kan aanpassen. Het aanpassen is:

- Het snel verplaatsen van het product (of een aantal van dat product) naar een andere locatie (bijvoorbeeld van de Koffer A in de Quad, naar Koffer A in de Caravan).
- Het aanpassen van het aantal van een product omdat deze is bijvoorbeeld is gebruikt.

Verderop in de database afgezien de eerdere controletabellen:
- Het bijhouden van het aanpassingen:
Bij vermindering van het aantal: waarbij o.a. de reden (houdbaarheid of gebruikt), het product, wijzigingsdatum etc. wordt bijgehouden
Bij vermeerdering: Het product en de aanschafdatum bijvoorbeeld.
- Het vergelijken van bijv. Koffer A met een "streeflijst met" waaraan deze moet voldoen.

Als ik dit heb en snap, dan volgt later nog een uitbreiding waarschijnlijk, maar dat is nu eerst niet het belangrijkste gedeelte. Heb eerst nog genoeg te leren.

 

[OctaFish]

Dit gedaan mede omdat ik in een reactie van OctaFish in een andere vraag las zo veel mogelijk met tekstwaarden te werken ipv nummeriek zodat de uiteindelijke waarden in de tabel komen te staan zodat duidelijk is wat het is.

Dat kan ik nooit gezegd hebben, want ik beweer altijd het tegendeel: sla de numerieke waarden op, en niet de gegevens! Verder snap ik ondertussen niet meer wat je allemaal aan het maken bent. Ik denk nog steeds dat je veel te veel tabellen hebt met gegevens die gewoon in één tabel thuis horen, die je dan koppelt aan de koppeltabel.

 

[EGeen]

Blijkbaar ben ik dus nog niet duidelijk genoeg. Of het is natuurlijk iets wat niet kan

Ik wil dus waarden 1 x hoeven in te typen en dat het overal wordt aangepast.
Deze waarden worden gebruikt in een combinatietabel zodat alleen die combinaties van gegevens mogelijk zijn.
De laatste tabel werkt met dezelfde waarden maar mag alleen werken met de combinaties die mogelijk zijn.

Sowieso ging het om keuzelijsten toen u dat ergens zei. Of ik heb het verkeerd begrepen.

 

[EGeen]

Iets soortgelijks in cursus 1 van Access.

"Bij het maken van een keuzelijst kun je kiezen tussen een keuzelijst die is gebaseerd op een Tabel, of een keuzelijst die is gebaseerd op waarden die worden ingetypt. Aangezien ik van mening ben dat in een tabel altijd de werkelijke waarden te zien moeten zijn, gebruik ik de eerste optie nooit. Een lijst maken met vaste teksten vind ik daarentegen wel een zinvolle optie. In dit voorbeeld maken we een keuzelijst voor het veld [Geslacht], waar, zoals bekend, maar een aantal opties te verzinnen zijn."

 

[OctaFish]

Keuzelijsten (met invoervak) vind ik vooral nuttig op formulieren. Dus niet in tabellen. Met één uitzondering: velden waarin een beperkt aantal waarden te kiezen zijn. Dan denk ik dus aan aanspreektitel, geslacht etc. Heb je die gegevens in meerdere tabellen nodig, dan zou je nog kunnen overwegen om daar wél een tabel voor te maken, die dan bijvoorbeeld een ID nummer opslaat. Scheelt weer in de opslagruimte. Want een getalveld neemt altijd minder plek in dan een tekstveld. Heb je één personentabel, dan heb je dus ook maar één keer behoefte aan een veld Geslacht met maximaal 3 waarden, en dan is een tabel een beetje onzinnig. Dus dat wordt dan een tekstveld met de waarden. Zelfs dan kun je nog een numeriek veld opslaan overigens, maar daar zal ik je niet mee lastig vallen

 

[EGeen]

Weer even zitten knutselen.

Dit is mijn uitkomst, en het doet wat ik in gedachten had. Moet het nog even verder verwerken in het formulier. Alle waarden zijn van het soort 'tekst'.

In het formulier voor het de inventarislijst is een keuzelijst met invoervak afhankelijk van één van de kolommen in de combinatielijst. Echter de waarde hiervan wordt ook aangepast als de brontabel wordt aangepast. Weet niet of dit de manier is om het te doen. Maar volgens mij werkt het voor mij.

In ieder geval super bedankt voor het meedenken. :thumb:

 

[OctaFish]

Je hebt in tblPlaatsCombi dezelfde veldencombinatie staan als in tblInventaris. Mij lijkt dat erg dubbelop. Eén van de twee kan sowieso weg, want alle combinaties heb je al in de andere. Ik zou zeggen: gooi tblPlaatsCombi weg.