Velden combineren tot 1 veld mbv query; opbouw tabellen?

[kruimeltjes]

Beste allemaal,

Ik zie door de bomen even het bos niet meer.

In de database die ik aan het schrijven ben moet ik oa de storage location opschrijven. Nu kan zijn dit best veel mogelijkeden, daarom had ik gehoopt dat dit met een query te kunnen combineren en in mijn tabellen deze gecombineerde locaties als lookup te kunnen gebruiken, maar ik loop al tegen het allereerste struikelblok aan, mijn tabellen en de opbouw.

In het kort omschreven;
Er zijn 6 mogelijk kamers waarin ik wat kan opslaan
In die kamers staan vriezers, koelkasten of veiigheidskasten, alle deze apparaten hebben een zogenaamd storageID nummer.
Een -20 vriezer kan 3 to 5 lades hebben
Terwijl een 4 graden koelkast 3 tot 4 planken kan hebben.
De -80 vriezer heeft rekken (Rack; max aantal per vriezer = 12x), ieder Rack kan maximaal 5 boxen (Box) bevatten en een Box heeft maximaal 81 posities
De veiligheids kast heeft dan weer planken (max 5)

Ik heb even een print screen van mijn database (Access 2010) gemaakt omdat ik hier geen winzip heb om de db up te loaden

 

[OctaFish]

Ik snap niks van je plaatje, er zit voor mijn gevoel geen logica in. Wat je in ieder geval zou moeten hebben, is een structuur met een rechttoe-rechtaan Top-down benadering. Daarbij kijk je naar het kleinste object en vervolgens ga je steeds een stapje hoger. Elk object dat je tegenkomt, krijgt een eigen tabel. Dus je hebt een tabel Kamers (Location?), daar zou een tabel Units onder vallen (Location --> Units), een tabel Rack (Unit --> Rack), een tabel Boxes (Rack --> Boxes) en een tabel Positions (Box --> Position). Eén unit kan maar in één kamer staan, één rack kan maar in één unit zitten, één box kan maar op één rack staan en één specifieke positie zit altijd in één box. En dan heb je een goede structuur. Daarbij heb je dan enigszins het voordeel dat je vaste data hebt, want je weet hoeveel posities er in een box zitten, hoeveel boxen er op een specifiek rack passen etc. Dus dat kun je allemaal alvast inrichten. Door de betreffende records aan te maken. Tenzij je ad hoc records wilt vullen, en een historie op wilt bouwen. Dan wordt de structuur een beetje anders.

 

[kruimeltjes]

Dank je voor je snelle reactie, ik ga dit even uitwerken!

 

[kruimeltjes]

Ik heb de tabellen voor elkaar gekregen, dank je daarvoor. Ik ben nu bezig om de query te maken, hierin loop ik tegen het probleem aan dat ik helemaal geen gegevens zie.

De bedoeling is dat ik alle mogelijke combinaties krijg uiteindelijk zodat ik deze query kan gebruiken om in tbl_reagents de storage location mee in te vullen (keuzelijst), heb ik gewoon weg de verkeerde query genomen of zit er nog mer fout?

Bekijk bijlage Antibodies EDD.part02.rar
Bekijk bijlage Antibodies EDD.part01.rar

 

[OctaFish]

Ik snap je tabellen nog niet helemaal. Als ik je oorspronkelijke verklaring er nog eens bij haal, kom ik tot deze constructie: kamers --> kasten --> lades/planken/rekken --> boxen --> posities. De tabel [tblRoom] is in je voorbeeld de tabel met Kamers. Dus dat is je hoofdniveau. in [Tbl_Storage] staan je kasten, vriezers, koelkasten, whatever you want. Gekoppeld aan tblRoom, zodat je weet welke kast in welke kamer staat. Vervolgens ga je die Storage objecten verder ontleden. En dan constateer je dat daar verschillende objecten in kunnen zitten, afhankelijk van het type. Dus dat zou een extra tabel zijn (Vriezer, Koelkast, Veiligheidskast). Maar of je nu een koelkast pakt of een vriezer, er zitten compartimenten in, hetzij laden, hetzij planken. Dus die benoem je apart (in tblRack). Met eventueel een extra tabel om de types te omschrijven. Die compartimenten gebruik je om boxen in/op te zetten. Dus die boxen koppel je dan aan de tabel tblRack, zodat je weet welke box waar staat.
Wil je het echt netjes doen, dan geef je ook nog per entiteit op hoeveel exemplaren er van de deelobjecten zijn. Dus in een Room geef je op hoeveel kasten er in kunnen, in een Storage hoeveel Racks, in Racks hoeveel Boxen en in een Box hoeveel Positions. Die waarden gebruik je dan om ofwel te checken of je niet teveel subrecords aanmaakt (als er 3 planken in een koelkast zitten mag je geen 4 planken toevoegen) ofwel maak je alle objecten in één keer aan, en gebruik je de tabellen om zowel lege als volle plekken te registreren.

 

[kruimeltjes]

Zou je het laatste stukje misschien wat nader willen toelichten? Ik vat hem nog niet helemaal.

Wil je het echt netjes doen, dan geef je ook nog per entiteit op hoeveel exemplaren er van de deelobjecten zijn. Dus in een Room geef je op hoeveel kasten er in kunnen, in een Storage hoeveel Racks, in Racks hoeveel Boxen en in een Box hoeveel Positions. Die waarden gebruik je dan om ofwel te checken of je niet teveel subrecords aanmaakt (als er 3 planken in een koelkast zitten mag je geen 4 planken toevoegen) ofwel maak je alle objecten in één keer aan, en gebruik je de tabellen om zowel lege als volle plekken te registreren.

 

[OctaFish]

Het is eigenlijk niet zo moeilijk. Als ik een kamer 5 kasten kunnen staan, mag je in tblStorage maar 5 records maken voor kasten in die kamer. Geen 6. Jammer genoeg kun je dat in een tabel moeilijk afdwingen, maar op een formulier is dat niet zo moeilijk. Je kijkt dan, als je records toevoegt in tblStorage naar het aantal records voor een bepaalde Room. Die waarde moet dan wel vastliggen in de tabel Rooms. Dus als je daar in een veld zet dat er 5 kasten mogen,en je voegt een record toe in Storage als het aantal Storage records op 3 staat, kun je nog 2 kasten toevoegen. Dat mag. Staat de teller op 5, dan heb je het maximum bereikt.
Hetzelfde principe pas je toe op Racks. Als in een kast 4 laden zijn, mag je maar 4 records maken voor Racks, geen 5. En zo door tot je alle entiteiten hebt gehad.

 

[kruimeltjes]

Ehhhmm sorry zal vast liggen aan het feit dat het zondag is maar ik volg je nog niet, kun je misschien een voorbeeld erbij doen.

Ik snap nu namelijk niet meer of ik het moet doen in de tabellen, zijn die uberhaupt oke, of dat ik het in een formulier moet aangeven. Of moet ik het toch via een query doen?

 

[OctaFish]

Ik zou de tabellen doen zoals in bijgaand plaatje. Daarbij heb je dus een extra numeriek veld waarin je per entiteit aangeeft wat het maximum aantal onderdelen is voor dat onderdeel. De uitwerking van het verhaal kan het beste op subformulieren die je niet bindt aan de tabellen, want als je een gebonden formulier hebt, en kun je bijna altijd wel een nieuw record toevoegen. Al is dat met instellingen nog wel op te lossen door de eigenschap <Toevoegingen toestaan> op <Nee> te zetten. Misschien toch een iets makkelijkere optie voor jou om te gebruiken dus.
Als we daar van uit gaan (<Toevoegingen toestaan> = <Nee>) dan kun je een hoofdformulier maken waar alle objecten met subformulieren op staan. Dus een subformulier voor tblRooms, een subformulier voor tblStorage etc. Kies je een Room, dan krijg je in Storage de beschikbare records te zien. Zijn dat 5 kasten in een kamer van 6, dan mag je er nog één toevoegen. Die check doe je door bij het kiezen van de Room een query te laten uitvoeren (VBA bij voorkeur) die het aantal Rooms telt in Storage. Op basis daarvan zet je dan de (<Toevoegingen toestaan> op <Ja>) en kun je een record toevoegen. En na het toevoegen zet je de eigenschap weer op NEE. En als je daarna de check weer uitvoert, dan krijg je de melding: Maximum apparaten bereikt.
En zo door dus voor de rest van de koppelingen. Is het zo wat duidelijker?

 

[kruimeltjes]

Kijk ik over het plaatje heen of heb je hem niet bijgesloten?

 

[OctaFish]

Zoals je zelf ook al zei: typisch zondag probleempje . Bij deze.

 

[kruimeltjes]

Even voor de duidelijkheid, de descritions die je hebt toegevoegd in de tabellen hebben;
a. welk data type
b. welk doel, zet ik hier mijn daadwerkelijke omschrijving neer van wat wat is, bijv in de tbl_Box heten mijn boxen letterlijk box A1-A5 tot en met K1-K5

 

[OctaFish]

Het veld Description is een omschrijving van de verschillende tupels. Jij hebt alleen een Unieke ID-code, maar dat is niet heel erg gebruiksvriendelijk. Daarom heb ik er die velden bijgezet. Want je gaat straks keuzelijsten gebruiken om de verschillende items te selecteren, en voor jou is wellicht duidelijk wat BOX E5 is maar voor mij natuurlijk niet. Als je een veld niet nodig hebt, dan kan het uiteraard weg . Overigens heb je in je voorbeelden wel gevulde tabellen gezet, maar nergens zitten koppelgegevens in. Voorbeeldje? In de tabel Storage zit een record met ID 30050, maar geen RoomID. Net zo min als voor de andere records. En dat geldt dus voor alle tabellen. Dan kun je ook niet echt testen of er gegevens te vinden zijn als je een room, storage etc. kiest.

 

[kruimeltjes]

Zonder heel erg vervelend te zijn maar voor mijn gevoel bereik ik op deze manier niet mijn doel. Misschien komt het gewoon doordat ik het plaatje nog niet rond heb ik mijn hoofd hoor maar misschien heb ik het ook gewoon echt verkeerd uitgelegd.

Misschien helpt het als ik dat nog een keer doe;

Ik wil mijn oplossingen (reagents, antibodies en primers) opslaan. Deze spullen staan op verschillende plaatsen (meerdere kamers maar ook meerdere koelkasten, vriezers en opslagruimtes).

Om preciezer te zijn heb ik 6 verschillende kamers, waarvan ik in 3 kamers in elk geval vriezers, koelkasten en een veiligheidskast heb staan;

Kamer 1 = 6 verschillende vriezer/koelkasten + veiligheidskast
Kamer 2 = 1 vriezer en 1 koelkast
Kamer 3 = 1 vriezer en 1 koelkast
Kamer 4, 5 en 6 = 1 grote opslagruimte

Al mijn koelkasten en vriezers hebben een uniek nummer.
Alle koelkasten en vriezers hebben meerdere lades/planken.

In 3 vriezers van kamer 1 kunnen we boxen plaatsen (max 5 per la, 12 lades per vriezer). In die boxen zitten weer 81 plaatsen.
In de overige vriezers / koelkasten hebben we max 4 lades/planken.

Nu wil ik op mijn formulier aangeven waar de spullen staan opgeslagen, ik kan namelijk op ruim 50.000 verschillende plaatsen wat verstoppen. Als ik ze dit met de hand laat doen gaat het gegarandeerd verkeerd, daarom wil ik ze via een selectie procedure (selectierondjes zat ik aan te denken op het formulier) dit laten kiezen.

Als ik het op jouw manier uitwerk, eerste stuk in elk geval, subformulieren ben ik nog niet aan begonnen, kom ik er voor mijn gevoel niet.

Mis ik gewoon wat of heb ik echt het plaatje nog niet compleet, wat mis ik.

Misschien handig als ik het bestand nog bijvoeg;

Bekijk bijlage Antibodies EDD.part02.rar
Bekijk bijlage Antibodies EDD.part01.rar

 

[OctaFish]

Ik zie het probleem niet met de huidige tabelopzet, die zou prima moeten voldoen. Tenzij je in kamers geen kasten hebt, wat wellicht het geval is met kamer 3-6? En dat je daar dus een kamer binnenloopt, en de box gelijk op een daar aanwezige plank legt?

 

[kruimeltjes]

Oke dus mijn opzet is in elk geval goed, daar ben ik blij mee. Hoe zou ik kamers 4 tot en 6 kunnen oplossen evt? In principe is het een hele grote kast met alleen maar planken (denk aan een veredeld bezemhok).

En wat is nu de verstandigste aanpak wat betreft creeren van mijn storage location op mijn formulier (frm_Reagent)?

 

[OctaFish]

Eigenlijk is het heel simpel. Om de structuur te handhaven, moet je de complete keten gebruiken. Dus als de ruimte zelf tevens de storage is, maak je één record aan in Storage die dan als 'kast' fungeert. Je hebt dan de Room <13.32>, en de Storage <13.32> en die kan je dan weer aan je tabel Racks koppelen.
Voor je Reagents kun je dan met 4 keuzelijsten aangeven waar ze thuis horen.

 

[kruimeltjes]

Ik heb nu inderdaad 4 keuzelijsten gegenereerd op mijn formulier, probleem nu is dat ik geen combinatie kan maken van lijsten tesamen om zo een storage location te maken (dus room + stoageID + Rack + Box + Position) en die op te slaan.

Verder heb ik nog een vraagje misschien niet helemaal in lijn met dit onderwerp maar wel met dit formulier, mijn product name moet hetzelfde zijn als ik heb staan in mijn tbl_productInformation. Ik kijg dit niet voor elkaar. Idealieter zou ik het eigenlijk zo willen hebben dat als het product er nog niet instaat ik deze dan gelijk kan toevoegen incl de andere velden die hiervoor nodig zijn. Zo'n zelfde constructie kan ik dan ook maken voor mijn suppliers

Bekijk bijlage Reagents, Primers & Antibodies.part01.rar
Bekijk bijlage Reagents, Primers & Antibodies.part02.rar

 

[OctaFish]

Omdat je nog weinig gegevens hebt ingevuld (in Rack bijvoorbeeld zit geen enkele koppeling met Storage) is het lastig testen, maar in beginsel is het nu zo dat de 4 keuzelijsten afhankelijk zijn van elkaar, dus als je een Room kiest, zie je de bijbehorende Storage, en zo verder. Uiteindelijk hoef je alleen het Postition record maar op te slaan, want vanwege de keten leidt die automatisch naar de juiste Room.

 

[kruimeltjes]

wacht even je bedoelt dat ik alle mogelijke combinaties moet gaan invullen in de tabellen?

(in Rack bijvoorbeeld zit geen enkele koppeling met Storage)

? Hoe moet ik die koppeling maken anders?