Hoe begin je eraan

Status
Niet open voor verdere reacties.
1

15JanE

Gebruiker
Lid geworden
14 jan 2015
Berichten
17
Ik ben nieuw in het database gebeuren. Ik ging aan de slag met de cursus access 2010 en nam reeds enkele hoofdstukken door. Enkele basis handelingen zijn me ondertussen wel duidelijk. Dat er nog ontzettend veel te leren valt is ook wel duidelijk.

Waarom mijn interesse omdat ik een goede tool zou willen hebben om aan mijn eigen verzuchtingen te voldoen.
Mijn moeilijkheid is nu dat ik een gebrek aan inzicht heb om een start te maken. Hoe organiseer ik mijn tabellen, wat moet erin, wat staat best in een aparte tabel om gedaan te krijgen wat ik voor ogen heb.

Even schetsen.
In een rusthuis hebben we materiaal dat gebruikt wordt bij bewoners.
bv
We hebben matrassen ( 3 types van matrassen), van elk type hebben we verschillende merken in huis. Sommige matrassen hebben een pomp die de matras bediend.
We hebben patiënten liften om bewoners te verplaatsen, die liften hebben batterijen. Er zijn vier soorten liften van verschillende merken.
Ik maak een tabel voor al de patiëntenliften en geef ze een nr. L001 enz
Ik maak een tabel voor de batterijen en geef die een nr. B001 enz. (Een batterij hoort normaal wel bij een lift maar kan stuk gaan en vervangen worden. Liften gaan langer mee.)
Ik maak een tabel voor de matrassen met een nr. M001 enz
en nog een tabel voor de pompen P001 enz
Ik heb een tabel van de leverantiers en van hun vertegenwoordigers.
Ik heb een tabel van de mogelijke lokaties.

En vanaf hier loop ik vast.
Ik wil voor elk materiaalitem een historiek aanmaken om te weten waar het zich nu bevind en waar het zich vroeger bevond. Er zijn een 150 tal kamers.
Soms gaat er iets stuk en moet het in onderhoud. Daar heb ik ook graag een historiek van; wanneer in herstelling, wat was er stuk enz.

Maak ik beter 1 tabel van al dat materiaal (ipv 4 tabellen). Hoe kan ik er zeker van zijn dat elk item slechts kan genoteerd staan op 1 lokatie vermits het kan verhuizen van kamer naar kamer, naar een opbergruimte of naar de dienst onderhoud.

Elke tip om mij op weg te helpen is welkom.
 
15JanE zei:
Maak ik beter 1 tabel van al dat materiaal (ipv 4 tabellen). Hoe kan ik er zeker van zijn dat elk item slechts kan genoteerd staan op 1 lokatie
Klik om te vergroten...
Je geeft zelf het antwoord op je vraag. Ja, de materialen zou ik in één tabel zetten. En de reden is heel simpel. Als je tabellen gaat bedenken, moet je niet in losse apparaten zoals een lift of een batterij denken, maar in objecten. Zo is een patiënt 'een object' van het type mens, maar een verpleger is dat (doorgaans) ook. En objecten van hetzelfde type zet je altijd (als dat tenminste kan) bij elkaar in één tabel. Met daarbij uiteraard de mogelijkheid om per object aan te geven wat het precies is en doet. Dus in de tabel [Personen] maak je dan een keuzelijst waarin je kunt kiezen tussen Patiënt of Verpleger. Ik noem maar wat.

En op dezelfde manier is een batterij een object, en een lift ook. Wat zijn de kenmerken van een object? Het heeft een leverancier, want het wordt aangeschaft, het heeft een aanschafdatum, een aankoopprijs, eventueel een afschrijftermijn, een soort (batterij, lift, telefoon etc), een type en ga zo maar door. Deze eigenschappen zijn bij de meeste objecten wel bekend. Daarnaast heb je nog objecten die afhankelijk zijn van een ander object. Een batterij bijvoorbeeld is als zodanig geplaatst in een lift. Eén enkel object kan echter nooit in meer dan één ander object zitten, en dat maakt je probleem redelijk simpel. Je zet in je tabel Objecten namelijk een veld ParentID, en daarin vul je het ID in van het apparaat waar het apparaat in zit. Dus in het record voor batterij B001 zet je in het veld ParentID de waarde L001, en hiermee heb je de koppeling tussen de apparaten gelegd. Een zelfde soort koppeling leg je bijvoorbeeld ook tussen een mobiele telefoon en een simkaart. De telefoon zelf heeft geen telefoonnummer of abonnement, maar de simkaart wel. Dus daar maak je aparte objecten van die je vervolgens koppelt door bij de Simkaart het ID van de telefoon in te voeren.
Door op deze manier te werken, kun je ook oneindig doorkoppelen, want als er in de lift een zelfstandig apparaat zit dat óók weer onderdelen heeft die geregistreerd worden, dan koppel je die op dezelfde manier.

Apparaten die vast in een ruimte staan, kun je koppelen aan een ruimte d.m.v. een aparte koppeltabel. Hiervoor geldt ook weer dat een apparaat dan in elke beschikbare ruimte kan staan, maar je wilt vermoedelijk voorkomen dat je één apparaat in meerdere ruimtes tegelijk laat bestaan. Maar dat is simpel te regelen op het formulier waarin je de koppelingen maakt. Overigens kun je ook aparte velden opnemen in de tabel Objecten waarin je dan aangeeft hoe een apparaat is gekoppeld (persoon; denk mobieltje of ruimte; denk lift) en op basis waarvan je dan op je formulier ofwel een ruimte ofwel een persoon kunt kiezen.

Kun je hier weer verder mee?
 
Kan ik hier mee verder

Inderdaad ik heb even de tijd genomen om 1 en ander te overdenken. Ik heb ook geen vrije avonden meer gehad om me er verder rustig aan te zetten.
Dank voor de reactie en de raad. Langs de andere kant komen er dan natuurlijk weer andere vragen boven.

Ik ben wat aan het uitproberen en zal dan men ontwerp met eventuele vraagstelling eens doorsturen als dat ok is.

Groetjes Jan
 
Prima natuurlijk dat je er rustig de tijd voor neemt; het fundament is behoorlijk belangrijk in een database, dus daar moet je echt de tijd voor nemen! Ik ben benieuwd naar je eerste ontwerp, en kijk er uiteraard graag even naar :).
 
Plaats van mijn objecten

Ik heb een aantal objecten in een materiaallijst gezet.
De bedoeling in de toekomst is te weten waar elk object zich bevind.

Ik probeer een opzet van locatietabel te verzinnen. Uit voorbeelden kan je soms veel leren en ik ben dan ook niet te lui om wat op te zoeken in dit forum. Als ik een bepaald forumonderwerp gevonden heb dat misschien een gelijkaardig probleem behandeld kan ik dat dan op 1 of andere manier taggen om dit snel terug te vinden later?

Ik las bv. jouw reactie op een vraag van kruimeltje op 4 feb 2014 "Velden combineren tot 1 veld m.b.v. query....."
Hij heeft boxen op schabben in kasten in kamers ....

Ik heb kamers op een afdeling (daar ligt een matras) maar ook de gang op een afdeling is een locatie (daar staat mijn patiënten lift bv). Locatie kan ook zijn "dienst onderhoud van de instelling" of op "onderhoud buiten de instelling".
Dus een tabel "Afdeling" en dan een tabel met alle mogelijke plaatsen op die afdeling (kamers, badkamers, gang)
Onderhoud locaties komen dan op het niveau van "afdeling" en worden op het volgende niveau gewoon herhaald.

Is dit logisch, ik probeer even uit te werken

Groetjes
 
Elke locatie is een eigen object, en wellicht dat een locatie zich kan bevinden binnen een andere locatie, dat is aan jou. In dat geval zou ik in de tabel een ParentID opnemen, waarin je de grotere locatie opneemt. Zo kan een afdeling meerdere kamers bevatten, maar elke kamer kan fysiek maar op één afdeling zitten, dus al die kamers krijgen dan dezelfde LocatieID (van de betreffende afdeling). Een afdeling is wellicht onderdeel van een gebouw, net als andere afdelingen, dus daar doe je hetzelfde mee. En op die manier kun je dus overzichten maken op elk gewenst niveau: een overzicht van afdelingen per gebouw, een overzicht van alle kamers per afdeling: geen probleem, allemaal met dezelfde techniek mogelijk.
 
Alle begin is moeilijk

Misschien wat idioot maar ik kan mijn database niet oploaden om even te laten bekijken.

In access gebruikte ik reeds de optie database comprimeren. Daarna heb ik winrar gebruikt om het bestand te verkleinen en toch zit ik nog op een 140 kb dus wil het forum mijn bestand niet uploaden.
Doe ik iets verkeerd of enige andere suggestie?
 
Als hij niet kleiner kan, dan is dat 't :). Je kunt met Winrar een rar maken met deelbestanden, die je dan 100kb groot maakt. In jouw geval krijg je dan 2 bestanden die je wel kunt uploaden. Of je zet 'm op een fileshare als WikiSend.
 
Dan toch nog

Bekijk bijlage 15JanE.part01.rarBekijk bijlage 15JanE.part02.rar

Opgesplitst in twee delen. Kan het zijn dat een database al zo groot is zonder dat er veel gegevens instaan. Ik heb nog niet de moeite gedaan om alle velden zo klein mogelijk in te stellen. Mijn tekst velden staan bijna allemaal nog op de standaardwaarde 255 tekens. Geeft dit iets aan de grote van je database?
 
Hartelijk dank. Ik bekijk het maar dat zal waarschijnlijk pas morgen zijn. Hopelijk kan ik dan van een goed fundament verder.
 
Het probleem van de grootte ligt niet in de data, want je tabellen zijn daar niet groot genoeg voor. En ook niet eens zozeer in de grootte van de tekstvelden. Een database slaat alleen het aantal tekens op dat in het veld staat, Dus als een tekstveld is ingesteld op 255 tekens, en je vult er 23 in, dan worden er geen 255 gebruikt, maar 23. Maar je gebruikt een beetje ongelukkige velden voor je koppelingen. Een tekstveld als sleutel gebruiken betekent dat je dat tekstveld ook in je koppeltabel zo moet instellen. En dán gaat het hard met de dataopslag! Veel beter kun je een numeriek sleutelveld gebruiken, dat neemt veel minder plek in.

Daarnaast vind ik de naamgeving van je velden erg onlogisch. Als je naar deze 2 veldnamen kijkt: LocatieID en LeverantierNaam, en je vraagt aan alle gebruikers van dit forum wat het veldtype is van deze velden, dan krijg je geheid het volgende antwoord: LocatieID is numeriek, en LeverantierNaam is een tekstveld. Nee dus: bij jou is het precies andersom! Zou ik echt veranderen.
 
Ik heb wat aanpassingen gemaakt, zoals het verwijderen van alle keuzelijsten in tabellen (behalve degene die je op basis van <Lijst met waarden> hebt gemaakt, want ik vermoed dat mijn laatste opmerking daardoor werd veroorzaakt. In tabellen wil je (althans: zou je moeten willen) de échte gegevens zien die in de tabel zijn opgeslagen. In jouw tabel sloeg je in LeverantierNaam wel degelijk een getal op (vandaar het numerieke veld) maar omdat je er een keuzelijst van had gemaakt, zag je de naam van de leverancier. En niet de feitelijk opgeslagen waarde. Ik vind dat een hele slechte zaak, want je komt daardoor vroeg of laat in de problemen. Denk maar aan een export naar Excel o.i.d. In tabellen zorg je er dus voor dat je altijd kunt zien wat er in staat.
Keuzelijsten (al dan niet met invoervak) zijn bedoeld voor formulieren, en daar gebruik je ze dus wél. Bovendien: welke gebruiker heeft er iets te zoeken in een tabel? Niemand! Alleen de beheerder hoort in de tabel te kijken, en als die dat doet, wil hij/zij toch echt kunnen zien wat er letterlijk staat!
Kortom: kijk maar eens in de nieuwe db, waarvoor ik overigens een nieuwe db heb gemaakt, en de tabellen etc. in heb geïmporteerd. Werd hij gelijk een stuk kleiner van. Sommige dingen snap ik ook niet, en wil ik ook niet snappen :).
 

Bijlagen

Dat je keuzetabellen in tabellen een slecht idee vindt dat las ik reeds meerdere malen in je antwoorden op andere vragen. En toch deed ik dat waarschijnlijk omdat ik van het db gebeuren nog helemaal geen kaas gegeten heb.
Waar ik niet uit kwam was dat; als ik in een tabel een gegeven uit een andere tabel moet invoegen het niet praktisch vond dat ik daarvoor die andere tabel moet raadplegen.
bv. Ik heb Firma's en Vertegenwoordigers. Als ik in de gegevens van de vertegenwoordiger een firma moet invullen dan zou ik het ID van die firma van buiten moeten kennen of de tabel firma open doen om te weten welk ID bij de firma hoort. Daarom dacht ik aan een keuzelijst gebaseerd op de firmanaam want die ken ik wel.

Ik begin nu te begrijpen dat je dit moet mogelijk maken via een formulier en niet via de tabel. Misschien klaar als een klontje voor de meeste onder ons maar voor mij was dat dus niet.

Inderdaad een totale beginner die nog het juiste denkpatroon mist en totaal niet weet wat allemaal kan en via welke weg.
In ieder geval dank om mijn tabellen te bekijken en aan te passen . Nu ben ik toch al zeker van een goede basis. Ik begin terug van voor af aan met je cursus.
 
15JanE zei:
Waar ik niet uit kwam was dat; als ik in een tabel een gegeven uit een andere tabel moet invoegen het niet praktisch vond dat ik daarvoor die andere tabel moet raadplegen.
Klik om te vergroten...
Daar heb je ook formulieren voor; daar maak ik uiteraard wél keuzelijsten. En dan kun je er ook veel meer mee, want dan kun je er acties achter hangen. Eigenlijk is een database ontwerpen niet zo moeilijk: eerst denk je na over de gegevens die je op wilt slaan, en daar rollen tabellen uit. Met relaties, want dat volgt uiteraard ook uit het denkproces. Als de tabellenstructuur klaar is, en je wat dummygegevens hebt ingevoerd om te kijken of de koppelingen kloppen, ga je nadenken over de formulieren: welke acties ga je aan welke objecten koppelen etc. En daar zitten de keuzelijsten dus ook in.

15JanE zei:
Misschien klaar als een klontje voor de meeste onder ons maar voor mij was dat dus niet.
Klik om te vergroten...
Geloof me, iedereen die met Access begint loopt tegen dezelfde problemen aan :). Daarbij hebben degenen die met de oudere versies hebben leren werken het eigenlijk nog gemakkelijker gehad, want Microsof heeft de laatste jaren zoveel bagger in het programma gebouwd, en dat bij de nietsvermoedende beginner door de strot geduwd (bijvoorbeeld die keuzelijsten in tabellen :) ) dat het nu veel lastiger is om te kunnen onderscheiden wat je nu wél moet gebruiken, en wat vooral niet!
 
Zo zou ik het ook doen :thumb:
 
Nog eens over een parentID.
bv Mijn kamers en andere mogelijke locaties zijn steeds gelegen binnen een Afdeling. Er zijn N afdelingen.
In mijn tblLocaties zet ik dan gewoon een veld AfdelingID en dat is dan ook de parentID. Of moet ik een parentID op een bepaalde manier inbrengen?

Andere vraag
Kan ik in mijn frmMateriaalDenOlm bekomen dat ik eerst een "Soort" selecteer waarna de volgende keuzelijst "Type" hierdoor beperkt word tot de mogelijkheden voor die soort, waarna de volgende keuzelijst "Naam" dan ook weer beperkt wordt tot die namen die hiervoor in aanmerking komen.
En analoog hieraan kan ik door eerst "afdeling " te kiezen bekomen dat enkel de locaties voor deze afdeling in een keuzelijst komen? Nu heb ik een lijst van 200 mogelijke locaties
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan