Rooster database

[ACollijn]

Ik wil een database maken om de roosters van mijn werknemers in te zetten. Met 1 druk op de knop moet dan duidelijk zijn wie wanneer werkt. Om dat te bereiken wil ik de weekroosters van iedereen invoeren en eventuele vrije dagen toevoegen. Ook moet er een minimum aantal werknemers zijn op elke dag (een basisbezetting), zodat de database een melding geeft bij het invoeren van de vrije dagen (ja het kan of nee het kan niet).
Nu ben ik bezig in Excel, en voor twee vestigingen is dat prima aangezien er maar 3 medewerkers per vestiging zijn. Voor 1 vestiging ben ik zelfs als uitprobeersel in de agenda van outlook begonnen. Voor een andere vestiging gaat het echter om 25-30 medewerkers, en dat begint een beetje veel te worden.

Heeft iemand een voorbeeld van een soortgelijke database die ik kan gebruiken?
Er is tot nu toe geen budget om een databaseprogramma kant en klaar aan te schaffen, vandaar dat ik zelf aan de slag ga met Access.

Groeten,
Annemarie

 

[migthy84]

beste annemarie.

Acces is een goede basis om mee te beginnen. Je weet dat Microsoft 2 goede voorbeelden in het office pakket zit. Een combinatie tussen taken(task) en contactpersonen( contacts) .

Een hele andere vragen(indexer wat het database moet kunnen).

Wat wil je uit de database halen.
1. De totale contact persoon(medewerker gegevens) of een naam alleen voldoende.
2. Werken mensen op verschillende locaties
3. Heeft iedereen zelfde aantal uren.

Je kan het zo groot maken als je wilt. In principe kan je klaar zijn met 2 tabellen (niet dat ik je dit aanraad).
Kan je een voorbeeld je sturen vanuit je excel met dummy(nepgegevens)

 

[ACollijn]

In principe is het voldoende als alleen de naam van de medewerker tevoorschijn komt. Misschien met functienaam er bij. Voor adressen hebben we al een database, al wordt die geloof ik niet meer gebruikt (heb ik op zitten zweten maar dat maakt niet uit). Die was gecombineerd met een word-document waar het rooster van de betreffende medewerker in stond.

Wat wil je uit de database halen.
1. De totale contact persoon(medewerker gegevens) of een naam alleen voldoende.
2. Werken mensen op verschillende locaties
3. Heeft iedereen zelfde aantal uren.

1. Alleen naam is voldoende
2. Mensen werken op verschillende locaties, we hebben totaal 10 vestigingen waar de medewerkers van de vestiging in kwestie ook vaak invallen bij ziekte e.d.
3. Iedereen heeft een ander contract. Dus dit moet ook worden meegenomen. Het kleinste contract is meen ik 13 uur, het grootste contract 36 uur.

Ik zou idd wat dingen kunnen combineren uit een contactpersonen database en een taken database. Hiermee zou ik eens kunnen beginnen.

Ik wil namelijk er uit kunnen afdrukken hoe het weekrooster er elke week uit ziet, ook met de aanpassingen van vrije dagen ed.

Annemarie

 

[migthy84]

Andere vraag:

1.Wil je de geschiedenis in kunnen zien
1a. Zoja hoelang.(wil je werken van 1-jan-2010 t/m 31-dec-2010)

2. Mag iemand ook overwerk zoja hoeveel
3. Werkt iemand 1 dag op 1 locatie
4. Werkt iemand in blokken minimaal 2 of 3 uur of is hier geen afspraak over.
5. Werk iemand op feestdagen
6. Hoe is het met de uren afronding (bijvoorbeeld is 50 min 1 uur of 0,88)


tips: --------------------------------------------------------------------------------------------------------------
als je verschillende contract heb zou ik dit zo i zo in een andere tabel stoppen.
bijvoorbeeld :

contracten
ContractID number(integer)
Naam - varchar(50)
Omschrijving -varchar (255)
Uren - double (2,1)

Schrijf alle tabel namen in meervoud.
Schrijf alle tabel met enkel dubbele betekenis (een tabel naam mag geen dubbel betekenis hebben (bijvoorbeeld straten 1. is het nu een postcode in Nederland of 2. of is het soort straten steen , hout)

Probeer zo min mogelijk werkwoord vervorming in straat namen te gebruiken.

Probeer zo veel mogelijk not null(deze waarde waarden dienen ingevuld te worden) te gebruiken.
Probeer niet alles uit te delen in delen.

 

[OctaFish]

Even aanvullen op de vorige post:
Je moet tabelnamen nemen die voor jou duidelijk zijn. Of dat enkelvoud of meervoud is, maakt echt niet uit. Probeer wel in je tabelnamen aan te geven dat het om een tabel gaat, bijvoorbeeld tPersoneel, of tblPersoneel. Als je later queries gaat maken, dan is een querynaam qPersoneel dan een herkenbare aanduiding dat de query is gebaseerd op de tabel tPersoneel.
Vermijd, als dat geen probleem is, spaties in (tabel)namen en veldnamen. Het mag overigens wel in Access, maar je komt straks misschien in de problemen als je uitgebreidere acties gaat doen. Namen met spaties zijn dan beruchte instinkers.
Wat bedoeld wordt met:

Probeer zo min mogelijk werkwoord vervorming in straat namen te gebruiken.

is mij licht onduidelijk...
Ik moet nog kijken of ik nog een voorbeeldje voor je heb... Doe ik vanavond!

 

[migthy84]

Probeer zo min mogelijk werkwoord vervorming in straat namen te gebruiken.
met andere worden maak tabelnaam met bijvoorbeeld lopen urengewerkt, etc. Probeer zelfstandige naamworden te gebruiken.

een prefix is handig, maar alleen als je meer als 10 tabellen heb.
Zelf gebruik in prefix alleen als je database voor meerder applactie / modules gebruikt gaat worden zo is rel_contractpersoom. Dan weet je dat het gaat om een tabel in relatie module. maar zo ga ik er te diep in voor anniemarie.

 

[OctaFish]

Beter goed aangeleerd, dan verkeerd, lijkt mij... Een enkele letter t, of tbl voor een tabelnaam lijkt mij alleen maar overzichtelijk, en dat is dus precies wat ik altijd doe. dan hou je het simpel genoeg.... En dat verhaal over de werkwoordvormen in straatnamen snap ik nog steeds niet...