schoolrooster

[JanvanZetten]

Hallo,

Ik ben bezig met het maken van een database om groepen te roosteren.
Op het oog ziet het er redelijk uit maar loop nu tegen een probleem aan.
De tabel lessen heb ik niet goed ingericht omdat ik nu geen draaitabel kan maken.

Hoe kan ik dit het beste aanpakken, als een record is gemaakt moet deze wel makkelijk te kopiëren zijn.

Ik heb een tabel aangemaakt zoals de draaitabel eruit zou moeten zien.


Groet Jan

 

[OctaFish]

Laten we eens beginnen met de structuur, want daar mankeert het e.e.a. aan. Eigenlijk is, wat jij wilt, op deze manier ook nooit te bewerkstelligen. Het gaat dan voornamelijk over de tabellen [Groepen] en [Lessen], die totaal niet genormaliseerd zijn. Die tabl bevat 3 logische velden ([LESID], [Datum] en [Groepscode], maar wat doen de velden D1, V1 t/m V30 daar? Geen idee wat je daar mee wilt. En daar heb je dan ook nog eens geen tekstvakken van gemaakt, maar Keuzelijsten met invoervak. Erg onhandig allemaal. Een tabel [Lessen] dient maar één veld Vak te hebben, en één veld Docent. Meer niet. Tenzij jullie met één klaslokaal werken, met 900 leerlingen en 30 docenten die dan tegelijkertijd 30 verschillende vakken geven. Dan kan het natuurlijk
Waar het op neer komt: je moet elke entiteit (lees: elke groep, elke les) uniek beschrijven. Dus i.p.v. voor een groep in één record 30 combinaties van vak+docent in te voeren, maak je (maximaal) 30 records aan met elk één unieke combinatie van vak+docent. In je huidige voorbeeld heb je ze ook lang niet allemaal gevuld, terwijl je er wél de velden (en ruimte) aan opoffert. En een ander nadeel: het is nogal lastig om het systeem aan te passen, omdat je een vast aantal combi's hebt ingevoerd. Met een genormaliseerde tabel maak je net zo veel combinaties aan als voor een groep nodig is, en heb je geen beperking. Veertig vakken kan ook.

Kortom: pas eerst je db aan, voordat je verder gaat!

 

[JanvanZetten]

Bedankt voor het antwoord ga hier gelijk mee aan de slag.
Ik heb er echt zin in om dit werkend te krijgen en met de tips en aanwijzingen kom ik hoop ik elke keer een stukje verder.

De velden Keuzelijsten met invoervak komen uit een tabel daarvoor had ik gekozen, gebruik dan elke keer de zelfde waarde kan de tabel natuurlijk aanvulleen met meer docenten of vakken.

Ik had eerst wel geprobeerd op elke les apart in een tabel te maken maar kreeg dit dan niet verwerkt in een doorloopformulier.

De 30 velden die ik had aangemaakt zijn de lesuren van de hele dag (standaard uren)
groepen kunnen dus een deel van die lessenuren geroosterd worden.
Er zij dus altijd maximaal 30 lesuren per record (elk lesuur is 30 minuten)

Moet elke tabel ook een primaire sleutel hebben?

Groet Jan

 

[OctaFish]

Ik zat net een heel interessant artikel te lezen (i.v.m. jouw vraag) aangaande het opzetten van een database, en één van de regels is: een tabel bouw je verticaal op, niet horizontaal. En dat is dus wat jij doet met al die dubbele velden . Je hebt er al heel wat tijd ingestoken, gezien ook de behoorlijk ingewikkelde queries die je nu hebt gemaakt. En die dus, bij een correct opgezette database, ook helemaal niet nodig zijn .

 

[OctaFish]

Je moet (ik bedenk me dat ik nog geen antwoord heb gegeven op je vragen ) nooit beginnen aan aparte tabellen maken voor entiteiten (zo noemen we de categorie ‘groep’, ‘les’ etc) die identiek zijn. Daar maak je dus altijd één tabel voor. Met voldoende velden om elke les te categoriseren. Ik snap je tabel ‘groepen’ dus niet. Wat moet je daar mee?

 

[JanvanZetten]

Omdat we betrekkelijk kleine klassen hebben moet ik deze samenvoegen in een Groep (de groep wordt dan in zijn geheel gepland) anders iet ik per klas een rooster maken dat kan soms komen op 7 dezelfde roosters.
tabellen aangepast, hier liep ik vast want nu met per groep de lessen worden toegevoegd.

 

[OctaFish]

Even voor het beeld, want dat is belangrijk voor de juiste werking. Als we van onderen naar boven kijken, dan heb je dus de volgende niveau's:
1. leerling
2. klas (bestaat uit leerlingen)
3. groep (bestaat uit klassen
4. een groep is gebaseerd op een lesuur; elke groep kan verschillende klassen bevatten
5. een docent geeft aan een groep, niet aan een klas
6. een lesuur wordt gegeven aan een groep, niet aan een klas
7. per lesuur wordt aan één groep les gegeven

Zie ik iets over het hoofd, of zit ik ergens verkeerd?

 

[Treud]

Bedankt voor het antwoord ga hier gelijk mee aan de slag.
Ik heb er echt zin in om dit werkend te krijgen en met de tips en aanwijzingen kom ik hoop ik elke keer een stukje verder.

De velden Keuzelijsten met invoervak komen uit een tabel daarvoor had ik gekozen, gebruik dan elke keer de zelfde waarde kan de tabel natuurlijk aanvulleen met meer docenten of vakken.

Ik had eerst wel geprobeerd op elke les apart in een tabel te maken maar kreeg dit dan niet verwerkt in een doorloopformulier.

De 30 velden die ik had aangemaakt zijn de lesuren van de hele dag (standaard uren)
groepen kunnen dus een deel van die lessenuren geroosterd worden.
Er zij dus altijd maximaal 30 lesuren per record (elk lesuur is 30 minuten)

Moet elke tabel ook een primaire sleutel hebben?

Groet Jan

Uit dit bericht merk ik dat je graag meer leert over dit onderwerp. Je zou je kunnen verdiepen in de 'ERD-model' en in de best practices voor 'gestructureerde data'. Ik denk dat je met die kennis ook beter zult begrijpen wat OctaFish probeert uit te leggen

 

[JanvanZetten]

Klopt, hierbij nog wat aanvulling te verduidelijking.


Klas bestaat uit Leerlingen maar de leerlingen komen niet in de database.

1. Groep bestaat uit verschillende klassen

2. Groep heeft op verschillend datums les (jaarrooster)

3. Groep heeft meerdere lesuren op een dag (datum)

4. Er kunnen maximaal 30 lesuren op een dag gepand worden (per groep).

5. Lesuur heeft als kenmerk een docent en een vak.

6. Een docent geeft les aan een groep (niet aan een klas)

7. Op een dag komen er meerder groepen in het rooster



Een docent kan verschillende vakken geven
Niet alle uren wordt door de zelfde docent les gegeven.

 

[OctaFish]

4. Er kunnen maximaal 30 lesuren op een dag gepand worden (per groep).

Is het een goochelschool? In Rotterdam passen er, als we héél goed persen, toch niet meer dan 24 uur in een dag. Ik vermoed dat je problemen gaat krijgen met onderwijsinstellingen als je dan probeert om een groep 30 uur les te geven. En dan mis ik ook nog eens de pauzes . Aan de andere kant: het is natuurlijk een loffelijk streven dat jullie de mogelijkheid willen hebben om ze te kunnen plannen. Dat de praktijk anders uitwijst, doet niks af aan de ambitie om de uren toch maar vast te leggen .

Dan had ik het inderdaad goed gezien. Of je wel of niet leerlingen meeneemt in het systeem, maakt overigens niet zoveel uit. Maar je planning moet je dus baseren op je groepen. En omdat je een één-op-veel relatie hebt met klassen (één klas kan in meerdere groepen zitten) en met groepen (één groep kan in meerdere uren zitten) kun je perfecte overzichten maken.
Je hebt overigens gelijk: alle tabellen moeten een primaire sleutel hebben, en je gebruikt deze vervolgens in de gekoppelde tabellen. Dus KlasID uit Klassen is in Klassen uniek (sleutel) maar in Groepen niet uniek, want komt daar meerdere keren voor. Een klas kan maar één keer in een groep zitten.

Je kunt de principes van databases overigens ook lezen in de Handleidingen sectie van HelpMij, waarvoor ik een cursus Access heb gemaakt.

 

[JanvanZetten]

Ik heb de tabellen aangepast en heb een relatie gemaakt.
zit ik zo op de goede weg.

En hoe moet ik nu het formulier Planner opbouwen.

 

[OctaFish]

Zal er zometeen naar kijken!