Uitleendatabase

[JacobCats]

Goede morgen,
Ik ben al geruime tijd bezig met het opzetten van een uitleendatabase voor onze collectie schilderijen en beelden.
Na verwoede pogingen, zoeken naar voorbeelden, grotendeels doornemen van de cursus kom ik er niet uit om het goedwerkend te krijgen. Na zoeken op het forum diverse voorbeelden gevonden waarvan ik het voorbeeld van sticky Stef21 d.d. 15.3.2021 als basis gebruikt heb om een nieuwe database te maken. Het voorbeeldbestand genaamd Bibliotheek sluit ik bij. Mijn aangemaakte database genaamd Uitleenregister sluit ik eveneens bij.
Ik zou toch als ik de qry Uitleenbare Collectie aanroep mijn collectie moeten zien. Ik heb nog geen item uitgeleend.
Ik krijg echter niets te zien. Ra.ra hoe kan dit.
Wie zou voor mij mijn database onder de loep willen nemen om te zien of en zo ja waar de fouten/vergissingen zitten en hoe deze aan te passen. En waar het verbeterd kan worden.

 

[xps351]

Ik zou toch als ik de qry Uitleenbare Collectie aanroep mijn collectie moeten zien. Ik heb nog geen item uitgeleend.
Ik krijg echter niets te zien. Ra.ra hoe kan dit.

Dat is niet zo verwonderlijk. In de query gebruik je een "INNER JOIN". Dat betekent dat je alleen records selecteert waarbij de CollectieID aan beide kanten gelijk is:

Omdat er geen records zijn in tblCollectie_stock, krijg je dus niets te zien. Als je kiest voor optie 2, dan krijg je:


Overigens snap ik je structuur niet zo goed.

• Wat betekent tblCollectie_stock? Ik zie alleen nut voor zoiets als je van elk schilderij meerdere exemplaren zou kunnen hebben (bij boeken is dat (wel) een gebruikelijke situatie).
• Waarom het uitlenen in twee tabellen vastleggen? Volgens mij heb je maar één tabel nodig tussen (exemplaar van) schilderij en klant waarin je de uitleen en retour gegevens vastlegt.
• Ik hoop dat "Uitleenbaar" geen afgeleid gegeven is. Als je bepaalde (exemplaren van) schilderijen niet wilt uitlenen, dan heeft zo'n veld zin. Als het betekent dat het op dit moment is uitgeleend, is het een overbodig gegeven, want afleidbaar uit de uitleengegevens.

 

[OctaFish]

Ik ben het gedeeltelijk met Peter eens: kunstwerken zijn uniek, dus of een werk uitleenbaar is of niet, is in dit geval een eigenschap van het kunstwerk. En dat kun je dus bijhouden in de tabel Collectie, niet in een aparte tabel.

Die tabel heb je dan bijvoorbeeld wél weer nodig als je ook Foto's als kunstwerk uitleent, en van die foto's meerdere exemplaren hebt. Dus of die tabel nodig is, hangt helemaal van jullie collectie(vorm) af. Aangezien wij die niet kennen (al schijnt Peter helderziende te zijn, gezien de stelligheid van zijn antwoord ) kan voorlopig alleen jij beantwoorden.

Maar hou dit soort zaken dus wél goed in de gaten: in één tabel leg je alle attributen (eigenschappen) van een tupel (object) bij die onlosmakelijk aan dat object zijn verbonden. Uitleenbaar of niet, is in mijn optiek een beetje beperkt verhaal; een kunstwerk dat je voor een bepaalde periode hebt uitgeleend bekijk je doorgaans anders dan een kunstwerk dat in restauratie is. Van de eerste weet je wanneer die terugkomt (zodat anderen hem kunnen reserveren bijvoorbeeld), van de tweede weet je dat niet.

Dus ik zou eerder voor een keuzelijst kiezen met meerdere mogelijkheden, waarvan Uitgeleend in Aanwezig er uiteraard bij horen, maar dus In Restauratie in mijn ogen ook. En wellicht wel meer.

 

[JacobCats]

Zoals door Peter en Octafish opgemerkt heb ik de database sterk vereenvoudigd.
Ik wil alvorens verder te gaan vragen of de opzet die ik nu gemaakt hebt een juiste is.
het uitleenformulier maak ik nog

 

[OctaFish]

Ik snap de opzet van je tabel tblCollectieUitleen niet helemaal; ik zie verschillende uitleenperiodes voor de kunstwerken. Je hebt een standaardwaarde op het veld [Terug_voor] (date()+30) en een Ja/Nee veld Teruggebracht. Geen valutaveld met het te betalen bedrag (als dat van toepassing is) en totaal geen controle over te laat teruggebrachte werken.

In de tabel gebruik dus je ook nog een in mijn ogen zinloos veld ([Teruggebracht]) omdat dat helemaal niets zegt. Vele malen beter is het om dat veld om te zetten naar een datumveld, waarop je de feitelijke terugbrengdatum invult. (Simpele knop die Date() invult.) Op die manier heb je altijd de terugbrengdatum voorhanden, en op basis van die datum weet je automatisch of een werk is teruggebracht of niet. Immers: geen datum, niet teruggebracht. Wél datum: op tijd (binnen 30 dagen) of te laat (langer dan 30 dagen).

Daarnaast zou ik dus, als je met meerdere vaste periodes (en bijbehorende tarieven) werkt, geen terugbrengdatum invoeren, maar die periode. Met een keuzelijst op je toekomstige formulier is dat makkelijk in te vullen. Dus 30 dagen, 60 dagen, 90 dagen etc. En daar hangt dan ook de prijs vanaf.

Maar wellicht heb je dit allemaal niet nodig, dan hoef je dat uiteraard zo niet te doen. Desalniettemin zou ik dat nietszeggende Ja/Nee veld vervangen door een datumveld.

 

[JacobCats]

dank voor je reactie. Ik kan weer met een gerust gevoel de database verder uitbouwen

 

[xps351]

Zoals door Peter en Octafish opgemerkt heb ik de database sterk vereenvoudigd.

Volgens mij kan hij nog eenvoudiger. Zoals ik al schreef, twijfel ik aan het nut van twee tabellen. In essentie (zonder rekening te houden met termijnen en prijzen) zou dit kunnen volstaan:


En zelfs dat is nog een "luxe" variant, waarin je de uitleenhistorie kan bijhouden (hoe vaak is een schilderij uitgeleend, hoe vaak heeft een klant een schilderij geleend, wat is de gemiddelde uitleenduur). Als je alleen wilt weten of een schilderij nu is uitgeleend en aan wie, dan heb je zelfs de tabel tblUitgeleendeCollectie niet nodig. In dat geval hoef je alleen twee velden in tblCollectie toe te voegen (klantID en uitgiftedatum).

 

[OctaFish]

Dat laatste idee van Peter moet je vooral niet serieus nemen en vooral niet onthouden, want dat is echt een héél slecht advies. Natúúrlijk wil je de historie van je bibliotheek bewaren! Niks ‘luxe’ variant, bittere noodzaak lijkt mij.

 

[OctaFish]

dank voor je reactie. Ik kan weer met een gerust gevoel de database verder uitbouwen

Leg, zeker als de meegeleverde database niet representatief is, ook vooral uit wat de bedoeling is van het geheel, want als we dat niet weten, blijven wij maar gokken (met dus hele slechte voorstellen als resultaat). We kunnen veel gerichter en beter helpen als we weten wat de uiteindelijke doelstelling is.

 

[JacobCats]

Uitleenregister.
Of de opgezette database representatief is vind ik lastig te beoordelen. Laat ik zoals door OctaFish terecht is opgemerkt eerst maar de doelstelling van de database duidelijk maken.
De doelstelling is:
Een uitleen-database te creëren met minimaal de volgende mogelijkheden.

Het bijhouden van de schilderij-collectie
- toevoegen nieuwe
- verwijderen van
-aanbrengen wijzigingen
“van alles is er maar één exemplaar “

Het bijhouden van de het uitleenregister
- welke klant heeft welk schilderij geleend
- voor hoelang (3,6,9 of 12 maanden)
- opzoeken is het schilderij ingeleverd, zo ja op tijd of te laat

Het bijhouden en kunnen opzoeken van
-hoe vaak heeft een klant geleend
- hoe vaak is een schilderij uitgeleend
“dit is i.v.m. opschonen van het klanten en schilderijbestand “

Maken van selecties t.b.v. te organiseren exposities.

Maken van etiketten met gegevens van o.a. de maker, naam en nummer
van het schilderij.

En wellicht zijn er nog handige opties waarvan ik het bestaan niet weet.
In hoeverre ik op de goede weg ben met mijn bestandje (zie bijlage) weet ik niet maar dit is de doelstelling.

Ik hoop dat jullie mij hierbij bij de hand willen nemen om tot een goed uitleenregister te komen.

 

[OctaFish]

Ik zal snel naar je db kijken, maar een aantal doelstellingen is in je vorige db in ieder geval niet mogelijk. Met de door mij voorgestelde wijzigingen ([Datum retour] i.p.v. selectie vakje retour) kom je al een heel eind. En dus een extra keuzelijst in je verhuur formulier met daarin de uitleentermijnen, op basis waarvan je in de query en/of op het formulier heel makkelijk de uiterlijke retourdatum kan uitrekenen. En wellicht geautomatiseerd aan de lener een berichtje sturen dat de leentermijn bijna is afgelopen.

Je hebt het (nog) niet over kosten gehad; lijkt mij een wezenlijk onderdeel van een kunstuitleen . Maar die lijken mij dan gerelateerd aan de leentermijnen .

Alle wensen die je hebt, kunnen overigens met de voorgestelde wijzigingen prima met queries worden gehaald.

 

[xps351]

Je databasestructuur kan een groot deel van de functionaliteit aan.

• Ik zou er bij het uitlenen voor kiezen de uitleentermijn vast te leggen. Dat is simpeler invoeren en Access kan de datum waarop het terug moet zijn prima voor je uitrekenen.
• Zoals @OctaFish al aangaf kan het handig zijn handig zijn een e-mail te sturen aan klanten die te laat zijn met inleveren (en/of een reminder te versturen tegen het einde van de uitleenperiode). Daar heb je dan wel het e-mailadres van de klant voor nodig. Ook moet je vast kunnen leggen dat een bepaalde mail (reminder, te-laat-melding) verzonden is. Een andere optie is dat je belt als het schilderij niet op tijd terug is gebracht. Dan is het telefoonnummer handig en moet je de mogelijkheid hebben vast te leggen dat de klant gebeld is.
• Over exposities vind ik niets terug. Dat is op zich wel iets dat nog wat haken en ogen aan kunnen zitten. Immers een schilderij dat gepland staat voor een tentoonstelling kan in die periode niet uitlenen. Andersom kan je een schilderij niet opnemen in een tentoonstelling als je weet dat het bij de start nog uitgeleend is. Ik heb in ieder geval in mijn model de basisgegevens alvast opgenomen.
• Tot slot stel ik nog wat naamswijzigingen voor; als we het over schilderijen hebben, waarom heet de tabel dan collectie?

Mijn voorstel zou zijn (exclusief mailen):

 

[OctaFish]

Of een schilderij uitgeleend is, of in een expositie hangt maakt natuurlijk voor het proces niets uit; hooguit zou je dat als status mee kunnen geven in de uitleen tabel; ik zou daar in ieder geval geen aparte tabel aan wijden.

Als je de exposities zelf organiseert, is een tabel met Expositie details zoals Peter die voorstelt bruikbaar. In dat geval heb je dus twee opties: uitlenen aan een klant, met een KlantID als lener, of ‘uitlenen’ aan een expositie, en dan vul je een ExpositieID in. Wél dus een extra veld nodig met Uitleentype, en een andere naam voor het veld KlantID, want je vult dan. Dit alleen personen in, maar ook exposities.

Nogmaals: voor het proces maakt het niet uit of een schilderij aan een persoon is uitgeleend of aan een expositie. In beide gevallen heb je een uitleenperiode en één contact. En als je de exposities niet zelf organiseert, dan heb je de expositie tabel niet eens nodig, want dan is de exposant gewoon een klant.

Kortom: met een simpelere opzet ben je flexibeler . Ik zal deze opzet morgen wel even in je database inbouwen.

 

[JacobCats]

Hij jij nog de mogelijkheid om naar mijn database te kijken/aan te passen?

 

[OctaFish]

Absoluut; sterker nog: hij is bijna klaar . ik heb het e.e.a. aangepast naar zoals ik het zou doen, zoals beschreven in #13. Daarbij ben ik ervan uitgegaan dat er eigenlijk drie soorten activiteiten zijn: verhuur van objecten, uitleen aan exposities en (daar heb je het nog niet over gehad) reserveringen. Dus dat iemand een werk zou willen lenen dat op dat moment niet beschikbaar is.

Ik gebruik nu een structuur met twee 'klanttabellen', de originele klanten tabel en een tabel met Exposities. Afhankelijk van de soort (expositie/verhuur+reservering) krijg je dan de ingevoerde klanten te zien, of de ingevoerde exposities. Daar hangen dan weer aparte prijzen aan.

De structuur als zodanig werkt al wel, maar ik ben nog even bezig met het elimineren van uitgeleende werken in de uitleentabel. Immers: een werk dat al is uitgeleend, wil je wél kunnen reserveren, maar niet verhuren. Of in een expositie zetten. Al kun je daar nog wel een boom over opzetten .

Als ik de laatste plooien er uit heb, zet ik hem vanmiddag hier neer. Kun je kijken of je er wat aan hebt. Het meldingen systeem (mail, telefoon) heb ik er nog niet ingemaakt; kijk eerst maar eens of je dat übehaupt wel wil.

 

[JacobCats]

Dank voor je vele werk. De database base mag wat mij betreft eenvoudiger.
ik denk dat wij met één activiteit kunnen volstaan. En wel hierom.
Voor de exposities (niet veel per jaar ca 3 stuks) kan ik volstaan de exposities de naam te geven van de expo en deze in het klantbestand op te nemen.
Reserveren is niet nodig. Er wordt gekozen op basis van de in huis aanwezige collectie.
Bij gelegenheid zal ik zelf aan de slag gaan met het maken van een prijstabel. (uiteraard op een kopie van de dbase.) Uiteraard ben ik benieuwd wat jij gemaakt heb.
Ik hoop niet dat ik met onnodig werk heb opgezadeld .

Mijn volgende stap is e.e.a. onderbrengen in formulieren

 

[OctaFish]

Ik denk dat ik je voor een beginnersfout moet behoeden door nogmaals te benadrukken dat een expositie iets wezenlijk anders is als een klant, en dat je die twee dus moet scheiden. Al was het maar omdat een database foolproof moet zijn, en toekomstbestendig. De beginnersfout is dus dat je teveel kijkt naar de huidige situatie, en niet naar de toekomst. En dat je verschillende entiteiten in één tabel wilt onderbrengen. Die fout is nog een stukje groter .

Ik zou het sneu voor je vinden als je volgend jaar tot de (onvermijdelijke) conclusie gaat komen dat het tóch niet werkt, en dat het dus alsnog anders moet. Kortom: denk vooruit, en hou nu al rekening met mogelijke aanpassingen/uitbreidingen die je later misschien wilt. Die moet je kunnen maken zonder dat je het systeem helemaal overhoop moet gooien. Reserveren mag nu nog niet nodig zijn (je bedoelt waarschijnlijk: komt nu nog niet voor) maar als die vraag (meestal vanuit de gebruiker of klant) een keer gaat komen, dan moet je daar op voorbereid zijn. En in een flexibel, goed gebouwd systeem kan je dat zo implementeren.

 

[JacobCats]

Duidelijke reactie. Laten wij gaan voor de toekomst.

 

[OctaFish]

Wacht maar tot je 'm ziet

 

[JacobCats]

Ik ben ontzettend benieuwd wat je ervan gemaakt heb. Hou mij niet langer in spanning aub