Planning

[Pepino]

Hallo,
Ik probeer een database op te zetten die onze dienstplanning in kaart moet brengen. De bedoeling is dat er uiteindelijk een rapport kan uitgedraaid worden die per dag de dienstplanning in kaart brengt.
Ik loop vast op een paar dingen : zowel de begintijd als de eindtijd moeten op deze planning komen (vaste tijden die in de tabel Rooster staan) , de datum zou uiteraard ook op deze planning moeten komen (liefst nog gegroupeerd per weeknummer) én als kers op de taart wil ik het geheel ook nog grafisch weergeven. Zeg maar vakjes die inkleuren in functie van het werkrooster ...
In bijgevoegde database zitten nog geen forms, maar dat lijkt me niet essentieel, dat kan allemaal achteraf wel.
Ik weet het, ik vraag bijzonder veel, maar ik loop vast. Elke hulp wordt enorm gewaardeerd.

 

[gast0224]

Om een Access-database te bouwen en nog belangrijker om hem te onderhouden heb je wel access kennis voor nodig. Wellicht een idee om eerst wat kennis op te doen van access. Op onderstaande link vindt je een hele uitgebreide cursus met heel veel voorbeelden. Die zal je heel goed kunnen gebruiken als ik zo naar je voorbeelddatabase kijk.

http://handleiding.helpmij.nl/

 

[OctaFish]

Laten we eens met iets simpels beginnen: de tabel [Planning]. Die bevat de velden [RoosterID] en [Rooster]. Je zou zeggen: [RoosterID] is gekoppeld aan [Id] in de tabel [Rooster]. Maar dat is dus niet zo: je hebt [ID] gekoppeld aan het veld [Rooster]. Dit is, net als [RoosterID] een numeriek veld. Dus: één van de 2 kan weg.
Tweede opmerking: je gebruikt in Planning opzoeklijsten op basis van tabellen. In de cursus geef ik regelmatig aan dat je dat niet moet doen, tenzij de keuzelijst is gebaseerd op een <Lijst met waarden>. In een tabel moet je, vind ik, altijd kunnen zien welke echte waarde er in staat. Met die keuzelijsten is dat onmogelijk. Bovendien is het helemaal niet nodig, want gebruikers komen (als het goed is) nooit in tabellen, dus waarom zou je die tabel mooi maken? Bewaar dat voor je formulieren, waar keuzelijsten wél thuis horen. Dus het eerste wat ik gedaan heb in jouw db is alle keuzelijsten terugzetten naar tekstvelden. En dat raad ik jou ook aan!

 

[Pepino]

Ik heb een en ander aangepast in de tabellen. De roostertabel heb ik idd gewoon weggelaten en geprobeerd alles in één tabel (zoals Octafish me aanraadde) inzichtelijk te maken. Wellicht is dit een betere start dan voordien ...

 

[OctaFish]

Ik heb niet gezegd dat je alles in één tabel moest gooien; alleen dat je in een tabel geen keuzelijsten moet gebruiken die op een tabel zijn gebaseerd. Da's iets heel anders . Verder heb je een tabel Datum die volgens mij totaal niet nodig is, want een datum kun je gewoon met een datepicker in de tabel Planning zetten. En wat doet dat veld Weeknummer überhaupt in die tabel? Weeknummers kun je heel simpel in een query berekenen. Sowieso is één van de hoofdregels van goed database ontwerpen dat je geen gegevens in een tabel opslaat die af te leiden zijn van één van de andere velden in die tabel. En een weeknummer is dus rechtstreeks afhankelijk van de gekozen datum, en derhalve altijd uit te rekenen. En daarom sla je een weeknummer nooit apart op.
Wat je nodig hebt om een kalenderview te maken, is een (al dan niet virtuele) tabel met daarin alle werkdagen. En dat is het lastigste in de database, want je slaat alleen de feitelijke roosterdagen op. Dus als je in week 31 2 dagen inroostert (zeg dinsdag en donderdag) dan zie je in je rapport maar 2 dagen terug: dinsdag en donderdag. De overige dagen staan er niet in. Want daar heb je geen data van. Om dat op te lossen moet je dus een dagentabel gebruiken waarin alle gewenste (werk)dagen staan, die je dan in een cartesisch product query koppelt aan de planningstabel. Op die manier krijg je wél de complete werkweek in beeld. Dus ook de niet-geroosterde dagen.Maar dan ben je al bezig met hogeschool ontwerpen; voor een beginner is dat lastige materie . Maar staat ook in de cursus .