ik houd er als instructeur wel van om per seizoen wat af te wisselen met casussen, oefeningen en dus ook competenties. Ik merk dat de cursisten dat overigens ook prettig vinden, vandaar dat mijn lijst na een jaar of 15 wel langer is dan een stuk of 20 lessen
Dat is geen probleem. Zoals ik al aangaf kan je cursussen op basis van het "onderwerp" relatief eenvoudig opzoeken (zonder bladeren) als je er sessies en deelnemers aan wilt koppelen.
Misschien moeten we "onderwerp" maar omdopen naar "titel"?
Merk wel op dat het onderwerp/de titel uniek moet zijn; er zit een unieke index op het betreffende veld in de tabel.
EHBO basis; verplichte onderdelen zijn ALLE competentiegroepen, met uitzondering van EHBO voor gevorderden en Evenementenzorg.
Ik blijf
Reanimatie dan een lastig geval vinden. Zoals je het hier beschrijft moet je de competenties uit de groep
Reanimatie beheersen om voor het diploma
EHBO basis in aanmerking te komen (en dat klinkt me logisch in de oren). Over het diploma
Reanimeren schreef je eerder echter dat dit 12 maanden geldig is, terwijl
EHBO basis 24 maanden geldig is.
In je reactie van vandaag noem je het diploma
Reanimeren niet meer expliciet.
Ik kan me voorstellen dat iemand alleen een cursus reanimeren doet (ik deed dat zelf ook diverse malen) en dan een diploma met een geldigheid van een jaar krijgt.
Het klinkt dan niet helemaal logisch dat een EHBO-diploma na een jaar nog geldig is als de de reanimatiecursus niet met voldoende resultaat herhaald is.
EHBO gevorderden is een toevoeging voor de EHBO, dus kan als "los" diploma gezien worden met de competenties van EHBO voor gevorderden.
Datzelfde geldt voor Evenementenzorg. Ik weet dat deze diploma's NIET zonder een geldig EHBO diploma geldig zijn.
Ik stel voor dat we hier op de volgende manier mee omgaan.
Het toekennen van een diploma is een handmatig proces. Op basis van de gegevens die je ziet beslis je dat een lid in aanmerking komt voor een bepaald diploma en per wanneer. Dat proces is lastig te automatiseren omdat er veel factoren bij komen kijken en er meestal meerdere cursussen (op verschillende data) gevolgd (moeten) zijn en er ook onderlinge afhankelijkheden zijn tussen diploma's.
Zoals je al vroeg moeten er signaleringen komen op aflopende diploma's (komt nog). Ik stel me zo voor dat als je bijvoorbeeld naar aanleiding van zo'n signalering gaat kijken of een lid in aanmerking komt voor een nieuw (verlengd) diploma
EHBO basis en je constateert dat dat niet het geval is én je ziet dat er een nog doorlopend diploma
Evenementenzorg is, je dat laatste intrekt.
Dat intrekken zouden we kunnen implementeren door de einddatum van het diploma te wijzigen. Dan moeten we dat veld (einddatum) wel toevoegen aan de tabel. Mijn voorstel is dat we de einddatum bij het toevoegen van een diploma automatisch vullen op basis van de begindatum en de geldigheid volgens de diplomatabel. De einddatum is dan in tegenstelling tot nu wel wijzigbaar.
Het zou wel prettig zijn als de competenties vrij "eenvoudig" aan te passen zijn, mochten er nieuwe richtlijnen komen vanuit de NRR of het Oranje Kruis...
Alles is aanpasbaar. In de uiteindelijke versie komen ook formulieren voor het toevoegen en wijzigen van competenties en competentiegroepen. Ik heb daar geen prioriteit aan gegeven omdat er al gevulde tabellen waren.
Ik zit er even mee dat als de "competentie-eisen" wijzigen van een diploma (daar heb ik geen invloed op), moet ik wel een competentie óf kunnen wijzigen, of een nieuwe aanmaken en mogelijk een "oude" niet meer "verplicht" maken (of liever, helemaal niet meer zien)...
Is dat mogelijk?
Ja. Zoals ik al schreef kan je nieuwe competenties toevoegen en koppelen aan een bestaande (of nieuw toegevoegde) competentiegroep.
Bij een diploma kan je altijd wijzigen welke competentiegroepen vereist zijn.
De (nog te bouwen) functies waarmee je kan zien of een lid in aanmerking komt voor een diploma gaan altijd uit van de actuele samenstelling van de vereiste competentiegroepen.
k zit even te kijken naar de tabellen, ik zie daar best veel nummers staan (Bijvoorbeeld de tabelDiplomaVereiste, tabel DeelnameSessie.
Stel dat ik (voordat ik wanneer de database gereed is) alles goed ga zetten, en de tabellen op de juiste wijze ga vullen (of aanpassingen in benamingen van competentie(groepen)) wil maken, kan dat dan nog en zo ja kan ik dat dan in de tabellen doen en wat voor invloed heeft dat op de database?
Daar hoef je je geen zorgen om te maken. Even een stukje databse-theorie.
Elke tabel heeft een (uniek) sleutelveld (ook wel key genoemd), bijvoorbeeld LesID in tblLes. Dat maakt dat elke regel (of record) uit de tabel uniek. De sleutelvelden zijn van het type autonummering; Access kent als er een nieuw record wordt aangemaakt automatisch een (unieke) waarde toe aan zo'n veld.
Tussen tabellen liggen relaties. De relaties zijn van het soort één-op-veel. Bijvoorbeeld tussen de tblLes en tblSessie ligt een één-op-veel relatie; bij één les horen één of meer sessies.
In het tabelontwerp van tblSessie zie je de relatie terug doordat er een veld LesID is opgenomen. Zo'n veld noemen we in goed Nederlands een foreign key. Access kan zo aan de hand van de waarde van het veld LesID terugvinden bij welke les een sessie hoort. Andersom is bekend welke sessies er zijn bij een bepaalde les; dat zijn alle sessies waarbij LesID gelijk is aan de LesID van de betreffende les.
Omdat we de sessies via een subformulier (frmSessie) op het hoofdformulier frmLes invoeren én er een relatie ligt op de beide velden LesID, vult Access de LesID in de tblSessie automatisch in.
Dit alles gebeurt dus automatisch op de achtergrond zonder dat de gebruiker er iets van ziet of merkt. De gebruiker ziet alleen formulieren zonder al die nummertjes.
Sommige tabellen bevatten meer dan één foreign key. In bijvoorbeeld tblBeoordelingCompetentie zie je als foreign keys LidID, CompetentieID en SessieID. Van een beoordeling moet je immers weten wie (Lid), wat (Competentie) en wanneer (datum van de Sessie).
Logisch gezien zou je misschien ook veel-op-veel relaties verwachten. Bijvoorbeeld tussen les en competentie: in een les behandel je meerdere competenties, maar een competentie kan ook in meer dan één les aan de orde komen. Het relationele databasemodel kent echter alleen één-op-veel relaties. Dat lossen we op met een zogenaamde koppeltabel: in dit geval de tabel tblLesCompetentie waarin als foreign keys zowel LesID als CompetentieID voorkomen. Voor elke Les-Competentie combinatie is er in de tabel een record aanwezig.
Ik begin redelijk vers. Ik heb een namenlijst en probeer vanaf de papieren lijsten tot ongeveer een jaar terug te gaan in de tijd van wie er wanneer is geweest.
Het is van belang dat we zo snel mogelijk de structuur van de database afhameren. Ik heb daar nu wel al een goed gevoel bij. Zodra we redelijk zeker zijn dat de structuur klopt gaan we de database splitsen in een back-end (BE) en een front-end (FE). In de BE staan alleen de tabellen en in de FE de rest (formulieren, query's, rapporten). De BE is als het goed is stabiel qua structuur. In de FE kunnen nog allerlei zaken toegevoegd en gewijzigd worden, hopelijk zonder dat we de databasestructuur (BE) aan hoeven te passen.
Dit heeft als voordeel dat we onafhankelijk kunnen werken. Jij kunt alvast beginnen met het invoeren van gegevens en ik voeg nieuwe functies toe aan de FE. Als ik wat af heb stuur ik de nieuwe FE die jij dan koppelt aan jouw BE. Ik werk met een eigen (test) BE. Bijkomend voordeel is dat we ook geen privacygevoelige persoonsgegevens heen en weer hoeven te sturen. Die staan alleen in jouw BE.
Mocht er toch nog iets in de BE (structuur) aangepast moeten worden, dan kan dat natuurlijk altijd. Daar spreken we in voorkomende gevallen dan iets over af.
Het is weer een heel verhaal geworden. Daardoor heb ik ook nog niets nieuws om te laten zien. Ik heb wel wat stappen gezet maar nog niets voldoende afgerond.
