Database met personeelsdata ... Functies en Rollen

Status
Niet open voor verdere reacties.

RadboudAKF

Gebruiker
Lid geworden
3 nov 2010
Berichten
219
Hallo,

Een personeelsdatabase die bij ons op de afdeling wordt gebruikt behoeft aanpassing. Vroeger hadden we alleen FUNCTIES (in een tabel Tbl-Functies). Nu hebben we Functies, Rollen, Kwalificaties, Eisen en nog veel meer.
Ik zit een beetje met die Functies en Rollen (en daarbij op de achtergrond met de Kwalificatie-eisen die daarbij horen). Wellicht kan iemand op dit forum mij een zetje geven zodat ik hiermee wat verder kom.
Een personeelslid heeft één Functie, maar kan meerdere rollen spelen (binnen die functie). Ik kom er nu niet goed uit hoe ik dit in tabellen ga ‘vangen’.
Heb ik nou een tabel FUNCTIES nodig én een tabel ROLLEN of een combinatietabel waarin alle functies en daarbij horende rollen staan.

Voorbeeld:

Functies:

1.Operationeel Manager
2.Farmaceutisch Medewerker
Rollen:
1.1. Operationeel Manager Magazijn
1.2. OperationeelManager Laboratorium
1.3. OperationeelManager Secretariaat
2.1.FarmaceutischMedewerker Magazijn
2.2. FarmaceutischMedewerker Laboratorium
2.3. FarmaceutischMedewerker Transport

Mijn concrete vraag is: Kan ik dit in één tabel ‘vangen’ of is het slimmer om beide ‘grootheden’ apart in een tabel te zetten en dan in een combinatietabel een ID te creëren die de combinatie dekt.
Ik merk dat ik hier een beetje in ‘cirkeltjes’ draai en niet goed kan beredeneren welke keuze ik hier moet maken om de Database-structuur vanaf de basis goed op te bouwen.

Heeft iemand ervaring met een dergelijke Access-Database of is er iemand met een paar goed tips?

Groet,

Jan
 
Het is een algemene vraag in database design en in principe niet specifiek voor access.

Wat je niet aangeeft is de noodzaak om te zoeken / gebruik te maken van beide grootheden. Wanneer moet er een "rol" gekoppeld worden aan een functie? Hoe wil je meerdere rollen koppelen aan een enkel persoon?

Zoals je zelf aangeeft heeft een persoon altijd slechts 1 functie. Zolang functie en rollen echter een vaste relatie hebben, kun je beter meerdere rollen toevoegen aan een persoon en dan de functie opzoeken. Een relatietabel is dan niet nodig. Als de functie "persooneels manager" echter gelinkt is aan meerdere "sub-rollen, bijv.de rol "leider HR", "leider IT", etc dan heb je weer een andere situatie
 
Een personeelslid heeft één Functie, maar kan meerdere rollen spelen (binnen die functie).
Je geeft zelf eigenlijk al het antwoord. Functie is overduidelijk een eigenschap van een personeelslid. Elke werknemer heeft altijd maar één functie, en dus zet je die functie in de personeelstabel. Het heeft geen nut daar een aparte tabel voor te maken. De rollen daarentegen moeten dus in een eigen tabel (want aan rol hangen rechten) en die koppel je dus aan de tabel Personeel_Rollen. Waarin dus ook de koppeling zit met PersoneelsID. Zodat elk personeelslid die rollen kan krijgen die bij die functie horen. Omdat je alleen de rollen wilt kunnen kiezen die bij een functie horen, zou ik op het formulier waarin je de rollen koppelt die keuzelijst filteren op basis van de functie. Dan heb je de minste problemen.
 
Ik ga met de reacties aan de slag ... altijd fijn om erover te 'sparren', dan kom ik weer op andere -vaak betere- gedachtes.

Voor nu ... dank.

Misschien kom ik er nog op terug als ik er niet uitkom ... dus de vraag laat ik even staan.

Jan
 
Goedemorgen (Octafish),

Ik weet niet precies waarom maar ik kom hier toch niet helemaal uit. Als het mag zou ik een klein voorbeeld willen sturen. Het gaat me (voorlopig) alleen om de koppeling tussen de drie tabellen: Tbl-Medewerkers, Tbl-Functies en de tabel waarin de functies worden gekoppeld aan de Rol. Eén medewerker heeft dus één functie, maar kan meerdere rollen hebben. De samenhang tussen functies en rollen heb ik ook in een tabel genoemd. (In een later stadium worden daar ook nog eisen aangekoppeld, zowel voor de functies als de rollen).

Waar ik vastloop (vreemd genoeg) is de onderlinge samenhang. Ik begrijp niet goed hoe ik middels een formulier medewerkers kan 'hangen' aan de hun toegewezen rol, of rollen? Op één of andere manier vergeet ik een cruciaal onderdeel ... ofwel het 'kwartje' wil maar niet vallen.

Zou je een blik willen werpen en mij een duw in de rug kunnen geven?
 

Bijlagen

  • Test-Medewerkers.zip
    45,7 KB · Weergaven: 66
Ik snap je tabellenstructuur niet; je hebt een tabel FunctieRol met daarin een veld FunctieID waarin waarden staan als APO en ZAPO. in de tabel Tbl-Functies verwacht ik die waarden dan terug als sleutelveld, maar daar gebruik je een ID nummering. Het helpt ook niet dat je in veel tabellen opzoeklijsten gebruikt i.p.v. tekstvelden (mijn cursus niet gelezen? :D ).
 
Octafish heeft vast een betere access gerichte uitleg, maar wat je zoekt is volgens mij het volgende:

tabel - rollen:
user-ID 1 Roll-ID 1
user-ID 1 Roll-ID 2
user-ID 2 Roll-ID 1
user-ID 2 Roll-ID 3

Ik begrijp niet goed hoe ik middels een formulier medewerkers kan 'hangen' aan de hun toegewezen rol, of rollen?

Dit is in database termen ook de "verkeerde" gedachte ;) De beelspraak is hier dat een user een ondergeschikte is aan de rol, maar in database termen is de user de prime ID waar je meerdere andere ID's (rollen) aan koppelt.: hoe koppel ik meerdere rollen aan een user.
 
Octafish, Jouw cursus heb ik inderdaad nog niet helemaal af. Bovenstaande antwoorden brengen mij nog meer in verwarring dan ik al was. Ik heb database nu 'uitgekleed' tot drie tabellen (die andere tabellen daar ben ik eigenlijk nog helemaal niet aan toe ...) Wellicht krijg ik nu wel over het voetlicht wat ik bedoel.

Ik ga uit van de tabel tbl-Medewerkers. Daar kan ik een medewerker een functie toekennen. Een rol toekennen kan daar niet ... een Medewerker komt immers maar één keer voor in die tabel. (dus één functie). Wat ik nog steeds niet begrijp is hoe ik middels een formulier medewerkers kan 'hangen' aan de hun toegewezen rol, of rollen? Voordat ik aan de slag ga met de Rol-eisen, Scholing, en andere kwalificaties moet ik dit eerst begrijpen. In het antwoord van Wampier worden de rollen aan de medewerkers 'gehangen' maar ik zie dan geen koppeling met de functie die daarbij hoort.

Ik ben verward ... ik stort me maar weer op de cursus ... misschien dat ik daar mijn probleem herken. Ik stuur de uitgeklede (met slechts 3 tabellen) dB nog eens op ... wellicht dat je me er nog eens op kunt wijzen wat daar nu fout aan is....

Bekijk bijlage Test-Medewerkers1.zip
 
Ik begrijp de verwarring wel een beetje, maar dat komt omdat jezelf rollen en functie niet koppeld. OctaFish had in zijn eerdere antwoord ook dezelfde opmerking:

Functie is overduidelijk een eigenschap van een personeelslid. Elke werknemer heeft altijd maar één functie, en dus zet je die functie in de personeelstabel. Het heeft geen nut daar een aparte tabel voor te maken. De rollen daarentegen moeten dus in een eigen tabel

Rollen en functies hebben in je beschrijving geen "relatie" en dus nergens een "koppeling". de "koppeling" tussen 'gebruikers' en 'rollen' is een "1-op-veel" "relatie". Er is dus ergens een tabel die het gebruikers-ID "koppelt" aan meerdere rol-ID's (zoals in mijn vorige post).

In het antwoord van Wampier worden de rollen aan de medewerkers 'gehangen' maar ik zie dan geen koppeling met de functie die daarbij hoort.

Klopt (zie boven). Indien je de keuze's voor een bepaalde rol wil beperken aan de hand van de functie is dat mogelijk via een andere tabel, maar in principe niet relevant voor de rollentabel van rollen toegewezen aan de gebruiker.

[gebruikers]
{id} {naam} {functies-id}

[rollen]
{id} {naam}

[functies]
{id} {naam}

[rol-koppeling]
{gebruikers-id} {rollen-id}

[functie-koppeling]
{functie-id} {rollen-id}

Dat is volgens mij wat je zoekt. Waarbij de laatste tabel voornamelijk gebruikt wordt voor de userinterface om de 4de tabel te vullen.
 
Ik zou het zo niet doen, maar ik heb momenteel geen tijd om aan te geven hoe het m.i. wél moet. Zul je tot vanavond moeten wachten...
 
Octafish,

Maak graag van jouw inzichten ... bovendien ben ik geduldig, dus.

Ik baal van mijn eigen ongemak bij deze dB ... ik heb dit vaker gebruikt, maar om één of andere reden maak ik hier kennelijk een grove denkfout.

Groet,

J.
 
Voor de duidelijkheid: mijn voorstel is een uitwerken van wat er wordt gevraagd en de informatie beschikbaar, gebaseerd op de standaard database design template (heb even simpele aannames gedaan over extensibility etc. waar aantal functies en rollen en relaties later groeien)

De uitkomst geeft niet altijd het beste antwoord voor elke situatie en specifieke database, maar het is een goed uitgangspunt om je gedachten op een rij te zetten. Ik ben geen meester in access (qua front-end) mogelijk is er een elegantere oplossing
 
Wampier,

Ik ben juist met jouw voorstel aan het werk. Dank hiervoor ... ik ben blij met elke inbreng ... want ik kwam er zelf gewoon niet meer uit ("running round in circles").

Groet,

J.
 
Ik neem bescheiden afstand dan. Tot je er achter komt dat het toch eigenlijk niet zo goed werkt :)
 
Octafish, dat werkt inderdaad niet zoals ik dat zou willen. Zou je nog een tip kunnen geven svp.
 
Dat is snel :). Ik zal er een werkende oplossing tegenaan gooien.
 
Dag Octafish,

Ik vroeg mij even af ... in het laatste bericht (3-10) sprak je over een 'werkende oplossing'. Daarna bleef het stil....

Schoorvoetend doorbreek ik de stilte met de vraag: "heb je er al naar kunnen kijken ?".

Groet,

Jan
 
Ook helpers zijn wel eens druk met wat anders... Zo was mijn laptop gesneuveld, en had ik dus wat minder resources tot mijn beschikking. Inmiddels heb ik (vandaag namelijk) weer een nieuwe laptop, dus ik kan er weer wat tijd in steken. Maar het blijft liefdewerk-oud-papier natuurlijk, het heeft niet de hoogste prio in mijn leven :).
 
Ik hoopte er ook niet op dat het bij jou de hoogste prio heeft .. ik zou niet durven. Niet voor niks gebruikte ik het woord 'schoorvoetend'. En ... jouw 'liefdewerk-oud papier' wordt altijd zéér op prijs gesteld.

Bij voorbaat dank ... ik zie het wel ... ben wel benieuwd ... dat dan weer wel.

Fijn weekend,

Jan
 
Ik heb er vandaag even naar gekeken, maar volgens mij ontbreken er nogal wat tabellen; Kwalificatie zit er niet tussen, Rollen niet... Je gebruikt ook heel veel opzoeklijsten in je tabellen, en dat moet ik je toch echt ten zeerste afraden. Gebruik tabellen alleen om gegevens op te slaan, en bewaar keuzelijsten voor formulieren.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan