Opzetten verhuring in acces

Status
Niet open voor verdere reacties.
M

ManuelBeauson

Gebruiker
Lid geworden
11 dec 2014
Berichten
146
Voor de verhuring van gebouwen wil ik een datebase opzetten. Nu heb ik alles eens op papier gezet en stel ik vast dat de tabel met vermelding van het gebouw 118 records zou bevatten , samengevat gaat dit van adres tot onderhoud , lening en bijhorende aflossingen, renovatie kost en verzekeringen.
Wat zou de gemakkelijkste manier van werken zijn, alle records in één tabel zou niet overzichtelijk worden in een formulier denk ik , andere oplossing is per gebouw meerdere tabellen te maken die dan gekoppeld zijn, maar hoe krijg ik dit dan allemaal verwerkt in een formulier
 
Je denkt verkeerd. Eerst moet je de gegevens goed analyseren en onderbrengen in groepen met unieke gegevens. Die groepen worden dan je tabellen. Een tabel met gebouwgegevens bevat dus alle gebouwen met hun unieke details, zoals adres etc. Vervolgens heb je gegevens met bijvoorbeeld onderhoud. Dat vindt, als het goed is, vaker plaats per gebouw. Maar elke onderhoudsactie zelf is ook weer uniek (datum waarop bijvoorbeeld). De tabel Onderhoud bevat dus alle unieke gegevens van het specifieke onderhoud, en daarin leg je ook het GebouwID vast dat je in de tabel Gebouw hebt vastgelegd. Tussen Gebouw en Onderhoud leg je dan een één-op-veel relatie op basis van GebouwID. Vermoedelijk heb je voor het onderhoud verschillende onderhoudsbedrijven, en die leg je dus ook vast. Elk bedrijf krijgt dus een eigen record in de tabel Leveranciers. En om te bepalen welke leverancier een specifiek onderhoud heeft gedaan, leg je in Onderhoud ook een LevID vast, wat weer correspondeert met LevID uit Leveranciers. Ook dit is weer een één-op-veel relatie. En zo loop je dus door alle gegevens heen: je kijkt welke gegevens herhalend voorkomen in je brontabel, en daar maak je dan een aparte tabel van die je koppelt op basis van een sleutelveld.

Heb je de structuur in orde, dan ga je pas naar formulieren kijken. Daarbij kijk je naar de tabellen die je brongegevens bevatten, zoals Gebouw en Leverancier. Deze formulieren gebruik je voor het onderhoud van deze tabellen. En voor je dataonderhoud zoals de tabel Onderhoud maak je een formulier waarin je met keuzelijsten met invoervak een gebouw selecteert, een leverancier etc. Op dat formulier kun je dan ook aanvullende leveranciersgegevens en gebouwgegevens laten zien. Die informatie haal je dan bij voorkeur uit de keuzelijsten.
 
Het opzetten van de tabellen is op zich geen probleem , tabel gebouw , huurder , VerhuurEntiteiten , leveranciers, leveranciersDiensten. De verhuring gebeurt per academiejaar, daar zit hem het probleem. Academiejaar 2013- 2014 heeft huurder Jan (huurder) in gebouw Poorthuys (Gebouw) kamer 0101 gehuurt, maar in academiejaar 2014- 2015 wordt deze kamer nu verhuurt aan Jef.
Hoe kan ik dit best verwerken
 
Ik zie het probleem niet. Of je academiejaren gebruikt, of echte jaren, in beide gevallen heb je een ingangsdatum, een einddatum (als het contract is beëindigd) of een lege einddatum als de huur actief is.
 
Gebouw x is verbonden met zijn verhuur entiteiten , de verhuur entiteiten zijn verbonden aan de huurder. Als ik volgend jaar nieuwe huurders heb is het niet de bedoeling heel de db aan te moeten passen.
 
Dat lijkt mij ook niet handig of nodig. Sterker nog: dat moet ik te allen tijde van harte afraden! Ik zie nog steeds het probleem niet... Je stelt ook geen vraag in het begin, dus wat vraag je nu eigenlijk?
 
De vraag is , hoe kan ik de tabellen best opzetten zodat elk jaar bij wijzen van spreken een andere huurder de entiteit kan huren van gebouw x
 
Dat heeft hoegenaamd niets met de opzet van je tabellen te maken. Als je elk jaar een andere huurder wil, moet je elk contract een einddatum geven. Dan weet je wanneer een locatie vrij is voor een nieuw contract.
 
Daar had ik nog niet aan gedacht :thumb:, is dit dan gewoon een record aanmaken met datum veld , hierin zet ik de einddatum van het contract of academiejaar, maar hoe krijg ik dit dan te zien wanneer de datum nadert.
Wanneer op basis van de einddatum de kamer terug vrij komt is mijn volgend probleem ook opgelost, ik,was aan het twijfelen of ik in de tabel van de huurder een record kon aanmaken met de entiteit die werd gehuurd, maar dan zat ik met het probleem dat wanneer deze het volgende jaar aan iemand anders werd verhuurd .
 
Ik krijg de indruk dat je het FO niet echt helder op papier hebt staan; dit soort vragen had je al lang en breed beantwoord moeten hebben voordat je überhaupt maar één veld in een tabel had aangemaakt :).
 
Het is met het maken van de tabellen en daarna een formulier dat ik zaken tegenkom waaruit dan de vragen rijzen, ik werk nu eenmaal op deze manier.Ik moet er ook rekening mee houden dat andere personen er ook me kunnen werken.
Je kan een duidelijk ontwerp op papier zetten maar dan blijkt wanneer je bezig bent dat niet alles klopt of dat het formulier zo groot wordt dat het niet meer overzichtelijk wordt.
 
Ik heb nog nooit een Functioneel Ontwerp gezien dat op één A4-tje paste :). Meestal zijn dat toch al gauw een pagina of 30.
ManuelBeauson zei:
Ik moet er ook rekening mee houden dat andere personen er ook me kunnen werken.
Klik om te vergroten...
Des te meer reden om éérst het plan te maken, en dan te kijken hoe je dat gaat realiseren. Als een huizenbouwer ook gelijk begint met metselen voordat er een tekening is, kun je er gif op innemen dat het huis niet best wordt.
ManuelBeauson zei:
ik werk nu eenmaal op deze manier.
Klik om te vergroten...
Dan moet je niet gek staan te kijken als je al snel in de problemen komt :D.
 
Michel , ik begrijp dat jij als volleerd acces gebruiker niet zo werkt, maar mijn kennis van acces was tot over 2 maanden nul. Was al ontzettend blij dat het facturatie gedeelte mij was gelukt. Ook bij het facturatie gedeelte heb ik diverse tabellen en formulier gemaakt en terug verwijderd en opnieuw begonnen tot dat ik een tabel en formulier had dat mij beviel.
Idem voor deze database, ik maak tabellen en formulieren zoals ik het in gedachte had, wanneer deze niet het resultaat geven zoals ik het wou dan verwijder ik deze en begin opnieuw, al doende leert men.
In eerste instantie kan je veel op papier zetten maar uiteindelijk als je eraan start zie je dat het niet lukt , dit komt ook door de weinige kennis van acces.
 
Ik moet toegeven dat ik ook met prutsen ben begonnen, en maar niet snapte hoe ik een database nu in elkaar moest steken. En die periode heeft ook heel wat langer geduurd dan 2 maanden :). Maar vroeger (als iemand je op je fouten wijst) of later (als dat niet gebeurt) kom je er achter dat het zo allemaal niet werkt. Een database is geen Excel spreadsheet waar je gelijk aan kan gaan werken, laat staan een Word document waar je gelijk met je eindproduct bezig bent.

Voordat je een database gaat maken, moet je toch echt weten wat een database nu eigenlijk behelst, en waaraan hij moet voldoen. Dat Microsoft het nodig vindt om alle programma's zo laagdrempelig mogelijk te maken, is in het geval van Access dus een hele foute aanpak. Het is een programma voor mensen die weten wat ze doen. Ik snij prima plakken van mijn salamiworsten af, maar dat maakt mij niet geschikt voor open hart operaties! OK, een been amputeren zal nog wel lukken. Maar voor het fijnzinniger snijwerk volg ik toch liever eerst een cursus :).

Bij een database moet je voor jezelf een beeld hebben van de informatiestromen die je wilt beheren. Je moet dus weten wat er uit moet komen, en wat je nodig hebt om het er in te stoppen. Als je daar niet eerst over nadenkt, krijg je broddelwerk.

ManuelBeauson zei:
Idem voor deze database, ik maak tabellen en formulieren zoals ik het in gedachte had, wanneer deze niet het resultaat geven zoals ik het wou dan verwijder ik deze en begin opnieuw, al doende leert men.
Klik om te vergroten...
En dat kost dus uiteindelijk veel meer tijd dan dat je eerst voor jezelf op papier zet wat je nu wilt. Bovendien begin je dan, als je gaat bouwen, gelijk goed. Alles steeds maar weggooien en aanpassen zorgt ervoor dat je uiteindelijk met een spaghetti database blijft zitten, die dan wellicht (tijdelijk) goed werkt, maar waar je uiteindelijk toch tegen problemen aan gaat lopen. Als érgens in de computerij de spreuk "Bezint eer gij begint" geldt, dan is het bij databases ontwerpen!
 
Ik begrijp volkomen uw stelling , maar als beginner is het op papier zetten meestal geen probleem omdat je eigenlijk niet weet wat wel en niet mogelijk is. Op papier heb ik de perfecte database, maar eens je eraan start kom je zaken tegen die niet haalbaar zijn, daarin is een doorgewinterde database gebruiker in voordeel want hij wist dat het niet mogelijk is.

Ik heb uw raad opgevolgd en alles eens op papier gezet, maar deze keer heel duidelijk. In dit punt had je al gelijk het zijn 10 pagina's geworden.

Mijn tabellen zijn al veel uitgebreider dan in eerste opzet, meerdere tabellen .

Hiermee ga ik aan de slag, voor vragen weet ik jullie te vinden ;-)
 
ManuelBeauson zei:
Ik begrijp volkomen uw stelling , maar als beginner is het op papier zetten meestal geen probleem omdat je eigenlijk niet weet wat wel en niet mogelijk is.
Klik om te vergroten...
Dat is juist de grap: dat wíl je ook als ontwerper :). Wat mij betreft hoeft een klant namelijk helemaal niets van databases en programmeren te weten, of wat er allemaal wel of niet mogelijk is. Je hebt als klant een aantal wensen, en je haalt er iemand bij die dat kan vertalen naar een database ontwerp. Het wordt pas vervelend als de nietsvermoedende klant na het doen van zijn verhaal naar de andere kant van de tafel loopt en dan de pet op zet van (jammer genoeg ook net zo weinig vermoedende) ontwerper!
Maar je bent op de goede weg, want je hebt de problemen nu voor jezelf op papier gezet en als het goed is heb je nu dus ook een beter idee van de processen die je nodig hebt, en de tabellen.
Mocht je het leuk vinden dat we meedenken, dan zou ik zeggen: post het FO er eens bij. Werp ik er in ieder geval graag een blik op!
 
Ik heb volgende tabellen
- Gebouwen : Gebouw ID - Naam Gebouw - adres gegevens - aantal entiteiten (enkel getal)
- Entiteiten : iD - Naam Gebouw (opzoeken in tblGebouwen) - entiteit (kamer - appartement - studio - ... ) - koelkast - diepvries - tv / dvd
- Huurders : HuurderID - naam + voornaam - adres + postcode - telefoonnummer - gsm nummer - email - algemene info
- Betalingen : betalingID - Naam Gebouw (opzoeken tblGebouwen) - Huurder (opzoeken tblhuurders) - bedrag - datum van ontvangen betaling
- Aangetekend schrijven : ID - Huurder (opzoeken tbl huurders) - datum verzonden - bijlagen (kopie van schrijven)
- Telefonische Oproepen : ID - Huurder (opzoeken tblhuurders) - datum oproep - reden van oproep.
- Academiejaren : ID - academiejaren (zijnde 2014-2015 - 2015-2016- enzo verder )
- Verhuur Details : ID - Naam gebouw (opzoeken tbl Gebouwen) - Huurder (opzoeken tbl huurders) Datum huurcontract - einde huurcontract - datum plaatsbeschrijving - bedag waarborg - ontvangen op datum - Afgegeven sleutels - datum van afgifte - sleutels extra (benaming van de sleutels) - Huurbedrag - Terugbetaling Waarborg - Datum terugbetaling waarborg.

Van 3 tabellen ben ik dan naar dit aantal tabellen gegaan. Nu zit ik nog met de vraag hoe ik best te werk ga om ervoor te zorgen dat na een academiejaar de entiteit terug vrij komt. Zou ik het academiejaar opnemen in de tbl Entiteiten of bij de huurder
 
Graag had ik een formulier gemaakt waar ik kan zien welke entiteiten vallen onder het gebouw , met subformulier lukt me dit perfect maar zou het graag in één formulier willen zetten. Het subformulier wil ik dan gebruiken voor de betalingen.
 
Entiteiten hebben een één-op-veel relatie met Gebouwen. Dus hoe hoog je ook springt: dat krijg je nooit in één formulier. Maar waarom zou je dat ook willen? Je geeft al aan dat het met een subformulier perfect lukt, en dat klopt: dat is 100% de juiste weg. En het zit een tweede subformulier met betalingen ook totaal niet in de weg.
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan