Coaching en hulp opstart databank

  • Onderwerp starter Onderwerp starter KVI
  • Startdatum Startdatum
Status
Niet open voor verdere reacties.
K

KVI

Gebruiker
Lid geworden
25 jun 2009
Berichten
36
Besten

Op basis van de opleiding via Helpmij.nl (door OctaFish) wil ik graag een database opstarten in Access 2010. Doel: registratie en opvolging van meldingen, vragen en/of opmerkingen waaruit een actie noodzakelijk blijkt (bv. onderzoek, terreinbezoek, advisering,…). Hieronder heb ik een structuur neergeschreven om te duiden hoe de databank moet werken. De databank zou gedeeld moeten gebruikt worden door 5 mensen waarvan 1 supervisor en 1 algemeen beheerder van de databank. Ik vraag of iemand mij zou willen coachen bij de opmaak van deze databank. Iemand waarop ik kan terugvallen en mij op weg helpt. Ik zal alles zelf doen maar ik heb nood aan iemand die me kan helpen met kennis van zaken. Ik wil er echt iets van maken? Wie gaat de uitdaging met me aan?

Nu al erg bedankt om het te overwegen!
Fijne groet

STAP 1: er wordt een melding gemaakt
a) een klant meldt iets aan het team
b) het team registreert op getrapte wijze deze melding
c) de geregistreerde melding wacht op beoordeling door de supervisor

STAP 2: de melding wordt beoordeeld
a) de supervisor beoordeelt de melding
b) b.1) bij weigering wordt de klant terug gecontacteerd en wordt de weigering gemotiveerd (1e en laatste communicatie) b. 2) bij aanvaarding wordt een dossierbeheerder en nummer toegekend
c) de dossierbeheerder behandelt binnen een afgesproken termijn de melding

STAP 3: de melding werd onderzocht
a) de dossierbeheerder registreert op getrapte wijze het onderzoek
b) het geregistreerde onderzoek wacht op beoordeling door de supervisor

STAP 4: de melding wordt al dan niet een dossier
a) de supervisor beslist op basis van het onderzoek a.1) het onderzoek uit te werken a.2) het onderzoek niet uit te werken
b) de klant ontvangt een 1e of laatste communicatie

STAP 5: het uitgewerkte dossier krijgt een administratief/beleidsmatig vervolgtraject
a) het uitgewerkte dossier wordt in het gepaste orgaan behandeld
b) b.1) het uitgewerkte dossier gaat niet naar realisatie (laatste communicatie) b.2) het uitgewerkte dossier wordt opgenomen voor realisatie (2e communicatie)

STAP 6: het behandelde dossier krijgt realisatie
a) de dossierbeheerder volgt op getrapte wijze de realisatie
b) de klant ontvangt een finale communicatie
c) de dossierbeheerder sluit het dossier
d) de supervisor ontvangt melding van het gesloten dossier
 
Je verhaal lijkt een beetje op de opzet voor een Meldingen registratie systeem. Met hooguit wat andere terminologie. Zou praat je dan over Behandelaars, i.p.v. Dossierbeheerders. Maar de opzet zou redelijk simpel kunnen zijn, want je hebt het maar over een paar tabellen. Om te beginnen natuurlijk de tabel Meldingen zelf, die het hart zal zijn. Die tabel wordt gevoedt vanuit een tabel Klanten/Aanvragers (geen idee hoe je de meldingen binnenhaalt), en een tabel Behandelaars. Ik zou aan Meldingen nog een tabel MeldingDetails hangen, en eventueel een tabel Bijlagen, en wellicht nog andere tabellen afhankelijk van je behoeften.
Alle stappen die je aangeeft zijn eigenlijk in mijn ogen niet meer dan Statusveranderingen in de tabel Meldingen. Als je eenmaal een melding hebt ingevoerd, krijgt die een bepaalde status, waar dan een bepaalde behandelaar(sgroep) voor verantwoordelijk is. Bij doorzetten naar Stap 2 verander je de Status, en krijgt de melding automatisch een andere behandelaar. Die verandering zou ik dus vastleggen in die detailtabel.
Je tabel Behandelaars krijgt dus, behalve de namen, ook velden waarin je aangeeft in welke behandelaarsgroep een behandelaar zit. In de formulieren filter je op Behandelaarsgroep, zodat elke groep zijn eigen meldingen ziet.
Maar het lijkt mij eerlijk gezegd niet zo heel moeilijk te maken. Zeker niet als je mijn cursus hebt gelezen. (Opleiding is wel èrg veel eer) :)
 
Erg bedankt voor de input Octafish. Jammer genoeg ben ikzelf minder onderbouwd in de materie. Ik heb nu jouw structuur uitgezet in tabellen en op relaties maar het loopt zo fout. Om de moed ervan te verliezen.
 
Ik zou zeggen: post de db eens, dan kunnen we naar je structuur kijken. Krijg je ongetwijfeld betere tips dan nu mogelijk is.
 
Beste OctaFish

Hieronder het database bestand. Bevat enkel tabellen. Relaties leggen zoals in de opleiding van jou lukt niet. Hij geeft altijd de foutmelding dat de velden niet overeenkomen met elkaar. Kan jij me helpen en vertellen wat ik fout doe aub? Ik kan me de relaties niet inzichtelijk maken.

Bedankt!

Bekijk bijlage Database2.zip
 
Zal er vanavond een blik op werpen!
 
Ik kan je gelukkig prima uitleggen wat je fout doet: je tabellen missen nogal wat velden! Om te beginnen: als je een hoofdtabel zoals Medewerkers wilt koppelen aan een tabel Meldingen, dan moet je eerst stilstaan bij de gegevensstroom die er in die tabellen plaatsvindt. En die is behoorlijk eenzijdig. Wat gebeurt er in het proces meldingen vastleggen?

Laten we medewerker Jan eens tegen het licht houden. Jan heeft een printer die het niet meer doet, dus Jan maakt op Maandag een melding. Die wordt uiteraard in behandeling genomen. Op Woensdag heeft Jan een probleem (hij is type kluns) met zijn computer, hij kan niet op de netwerkschijf komen. En op Donderdag ('t is niet zijn week) gaat ook de telefoon kapot. En alles wordt keurig gemeld door Jan. Wat kun je opmaken uit dit trieste verhaal? Dat er deze week in de tabel [Meldingen] 3 meldingen moeten worden gemaakt voor Jan. Dus de tabel Meldingen bevat in ieder geval 3 meldingen. En om die meldingen te kunnen verwerken moeten we in die meldingen nogal wat gegevens opslaan. Als eerste: om te weten wie de melding heeft gedaan, hebben we op zijn minst herleidbare gegevens nodig waaraan we de melder kunnen herkennen. Alleen een veldje Voornaam is uiteraard niet genoeg, want dan zou je alleen weten dat de melding is gedaan door 'Jan'. En bij een beetje bedrijf heb je meer dan één Jan. Dus sla je in de tabel [Meldingen] het Personeelsnummer op, want dat is uniek. Bovendien krijgt de tabel [Meldingen] ook een uniek nummer, want als je aan behandelaar Tina vraagt om melding 123 af te handelen, dan is het wel prettig als Tina weet wèlke melding daarmee wordt bedoeld. Als je in de tabel [Meldingen] 6 meldingen hebt met nummer 123, wordt het voor Tina lastig om uit te zoeken welke melding voor haar is.
Wat weten we van de tabel [Medewerkers]? Daar is helemaal niets aan veranderd. In de tabel heb je als het goed is alle relevante persoonsgegevens van de medewerker, waaronder het unieke Personeelsnummer. Zou dit nummer niet uniek zijn, dan kun je meerdere personen met hetzelfde personeelsnummer hebben, en dan krijg je in ieder geval problemen met Financiën die dubbel gaan uitbetalen. Het enige dat je doet met de tabel [Medewerkers], is in de tabel Meldingen dat personeelsnummer opzoeken. En wel bij elk van de 3 meldingen. En dat doe je natuurlijk ook bij Dirk, die een kapotte graafmachine heeft. Kortom: er is een verband tussen de tabel [Personeel] en de tabel [Meldingen], en wel deze: elke werknemer kan een onbeperkt aantal meldingen maken. (1 voor Dirk, 3 voor Jan)
Wat weten we nog meer? Als je in de tabel [Meldingen] kijkt, dan kun je op basis van het ingevulde Personeelsnummer altijd in de tabel [Personeel] opzoeken wie de melding gemaakt heeft. Het personeelsnummer is immers uniek. Dus als je het personeelsnummer weet, weet je wie het probleem heeft gemeld. Wat kun je dus nog meer zeggen? Elke melding in de tabel [Meldingen] hoort onlosmakelijk bij precies één werknemer. De conclusie moet dus zijn: er is een één-op-veel relatie tussen de tabel [Medewerkers] en de tabel [Meldingen].

Wat heb je nodig om die koppeling te maken? In de tabel [Medewerkers] moet het veld Personeelsnummer uniek zijn. We hebben net gezien dat dit best wenselijk is. En in de tabel [Meldingen] heb je ook een veld Personeelsnummer, maar dit veld is niet uniek. Zou dat wel uniek zijn, dan kan elke medewerker maar één keer een melding maken. En hoewel dat soms wel eens handig kan zijn (trekkingen voor een loterij bijvoorbeeld) is dat voor meldingen geen optie.

Kijken we nu naar jouw tabellen [Medewerkers] en [Meldingen], dan heb je in de tabel [Medewerkers] alle juiste velden staan ([Rijksregisternummer] als sleutelveld; prima!) maar in de Meldingen heb je alleen een veld MeldingenID en een veld Meldingomschrijving. Ik mis daar dus het veld Personeelsnummer. En dat brengt ons weer bij de tabel Medewerkers, want wat staat daar (een beetje tot mijn verbazing)? een veld MeldingID! En dat heb je ook nog eens van het type Autonummering gemaakt! Ik hoop dat je nu snapt dat dit veld daar niet thuis hoort. Bovendien zou je dit veld willen kunnen koppelen aan MeldingenID in Meldingen, maar (hoewel je daar een sleutelveld van hebt gemaakt) dat is een Tekstveld! En een tekstveld kun je never nooit koppelen aan een numeriek veld.
Dus dat probleem kun je nu hopelijk zelf repareren.
Gaan we naar het volgende probleem: de tabel Meldingen zou volgens mij veel meer velden moeten hebben. Om te beginnen mis ik een veld Behandelaar, een veld Aanmelddatum, een veld Afmelddatum, een veld Categorie etc. Kortom: alle velden waarmee je de melding kunt vastleggen. De tabel MeldingDetails kent hetzelfde probleem (kun je nu hopelijk zelf deduceren). Die tabel is overigens niet noodzakelijk; ik heb 'm voorgesteld omdat er bij een melding vaak allerlei bijlagen worden toegevoegd, zoals emails en bestanden, en daarvoor geldt de relatie: één melding kan meerdere detailrecords hebben, maar één detailrecord hoort altijd bij één melding. Ook weer een één-op-veel relatie dus.
Zoals gezegd: nog niet gelijk nodig, maar straks wel handig.
 
bedankt OctaFish, erg inzichtelijk gemaakt. Op basis daarvan werk ik nu verder uit, ik zal dan online zetten
 
Hallo OctaFish

Zoals beloofd heb ik mij na jouw toelichting opnieuw aan m'n structuur van m'n database gezet. Als je die bekijkt ga je schrikken want eigenlijk lijkt het wel simpel maar dat is het niet. De structuur is nog niet af, maar hoe langer hoe meer ik eraan werk, hoe moeilijker het wordt. Kan jij eens checken of ik op goede weg ben. En nu al excuses voor de blunders die je er zal in zien....

Om je wegwijs te maken:
1 een 'melder' = burger; hij meldt een probleem aan een overheidsdienst
2 gegevens van de melder worden geregistreerd in tabel 'melder'
3 in de tabel 'meldingen' wordt de melding zelf geregistreerd
4 een dossierbehandelaar wordt aan de melding gekoppeld
5 de dossierbehandelaar moet een plaatsbezoek uitvoeren om de melding in de praktijk te controleren, de informatie wordt hier opgeslagen in de tabal plaatsbezoek
6 na het plaatsbezoek moet de dossierbehandelaar een advies schrijven waarin hij zijn advies formuleert
7 maar dit is nog niet opgenomen in de structuur: van melding tot afhandeling van de melding moet ook een tabel communicatie de tussentijdse communicatie met de melder plus de definitieve communicatie (als brief wordt geschreven wat er uiteindelijk met de melding gaat gebeuren, of niet gebeuren) in de tabel communicatie opgenomen worden

Alle handelingen hebben betrekking op de verschillende tabellen en zijn met elkaar verbonden; bv. een melding is gekoppeld aan een plaatsbezoek en een plaatsbezoek zal tot een advisering leiden, finaal zal daar dan ook over gecommuniceerd worden tussen overheidsdienst en melder

Bedoeling van de database is dus alles van melding tot afhandeling van melding vast te leggen in de databank; de databank moet werken met front- en back en moet via een netwerkschijf.

Klinkt al niet meer zo eenvoudig, niet?

Superbedankt voor de hulp.Bekijk bijlage aangepaste databasestructuur.zip
 
Je hebt een aantal tabellen die niet te koppelen zijn, en dat komt doordat je het verkeerde veldtype gebruikt voor het koppelveld (tekst i.p.v. numeriek) en je in de brontabel het verkeerde veld als sleutelveld gebruikt. Bovendien (en ik heb daar, wat je zou kunnen weten als je de cursus hebt gelezen) gebruik je keuzelijsten in tabellen, en dat zou je dus niet moeten doen. Nu weet je nooit wat je precies opslaat in de tabel. Gebruik keuzelijsten in tabellen alleen voor keuzelijsten op basis van waarden, en verder alleen in formulieren, waarvoor ze bedoeld zijn.
 
Pakken we de db er zelf bij, dan vallen een paar dingen op:
KVI zei:
5 de dossierbehandelaar moet een plaatsbezoek uitvoeren om de melding in de praktijk te controleren, de informatie wordt hier opgeslagen in de tabel plaatsbezoek
Klik om te vergroten...
Waarom een aparte tabel? Als de behandelaar één bezoek uitvoert, dan hoort dat bezoek in de tabel Meldingen thuis. Doe je meerdere bezoeken, dan gebruik je daarvoor een extra tabel zoals je gemaakt hebt. Maar in de uitleg maak je dat niet duidelijk.
KVI zei:
van melding tot afhandeling van de melding moet ook een tabel communicatie de tussentijdse communicatie met de melder plus de definitieve communicatie
Klik om te vergroten...
Die tabel zie ik niet; wel communicatie gerelateerde tabellen die je aan Meldingen koppelt. Die zouden dus aan Communicatie gekoppeld moeten zijn.
 
Bedankt voor je reactie OctaFish.

Waarom een aparte tabel? Als de behandelaar één bezoek uitvoert, dan hoort dat bezoek in de tabel Meldingen thuis. Doe je meerdere bezoeken, dan gebruik je daarvoor een extra tabel zoals je gemaakt hebt. Maar in de uitleg maak je dat niet duidelijk.
Klik om te vergroten...

Een plaatsbezoek is niet altijd strikt noodzakelijk maar het gebeurt wel. In meer dan de helft wordt een plaatsbezoek uitgevoerd. Omdat het niet altijd wordt uitgevoerd dacht ik dit op te lossen in een aparte tabel, maar logisch geredeneerd hoort het in de tabel meldingen thuis. De suggestie om de aparte tabel te gebruiken bij meerdere plaatsbezoeken (want dat kan ook gebeuren) vind ik goed.

Die tabel zie ik niet; wel communicatie gerelateerde tabellen die je aan Meldingen koppelt. Die zouden dus aan Communicatie gekoppeld moeten zijn.
Klik om te vergroten...

Klopt. Er is wel een verschil: zo wil ik een onderscheid maken tussen een melding die binnenkomt op onze dienst zelf (1) en (2) een melding die via een andere dienst of een andere persoon die aan onze organisatie is gelinkt, onze dienst bereikt. Maar dat moet verder uitgewerkt worden, maar ik begrijp dat alles vanaf 1 brontabel moet beginnen, voor wat betreft communcatie.

Er zitten toch een aantal fouten in en ik zie het niet:

1) als ik in de tabel 'melder' gegevens wil ingeven, geeft hij foutmeldingen als ik door m'n velden ga
2) omdat tabellen melder en meldingen gelinkt zijn, zie ik in de tabel 'melder' een plusje met daaronder gegevens over de meldingen maar omgekeerd is dit niet het geval: in de tabel meldingen zie ik geen plusje naar melder (hoe maar ik deze relatie?)
 
Je zult moeten kiezen voor één van de twee methodes voor huisbezoek. Is er meer dan één huisbezoek mogelijk, en wil je die verschillende bezoeken apart registreren, hou dan de constructie die je hebt. Is er nooit meer dan één huisbezoek, dan zou ik de tabellen aanpassen.
KVI zei:
Er is wel een verschil: zo wil ik een onderscheid maken tussen een melding die binnenkomt op onze dienst zelf (1) en (2) een melding die via een andere dienst of een andere persoon die aan onze organisatie is gelinkt, onze dienst bereikt. Maar dat moet verder uitgewerkt worden, maar ik begrijp dat alles vanaf 1 brontabel moet beginnen, voor wat betreft communcatie.
Klik om te vergroten...
Je denkt verkeerd; je moet denken vanuit de Entiteiten, in dit geval de entiteit Melding. Wat zijn de specifieke kenmerken van een melding? Die leg je vast in één tabel. Hóe een melding binnenkomt, is daarbij eigenlijk niet relevant. Althans niet voor de melding. Zou ik dus met een keuzelijst oplossen.
KVI zei:
2) omdat tabellen melder en meldingen gelinkt zijn, zie ik in de tabel 'melder' een plusje met daaronder gegevens over de meldingen maar omgekeerd is dit niet het geval: in de tabel meldingen zie ik geen plusje naar melder (hoe maar ik deze relatie?)
Klik om te vergroten...
En die ga je ook nooit zien.... Als je dat niet gelijk snapt, dan moet je nog eens goed nadenken over de relatie tussen de twee tabellen. Hint: je hebt het hier over een één-op-veel relatie...
 
probleem is dat ik denk dat ik het verkeerd doe, en daarom dat ik twijfel...
 
Twijfel kun je wegnemen door logica. In jouw laatste probleem is dat heel simpel: één melder kan meerdere meldingen maken. Daarom zie je bij de melder een plusje: hij heeft dan meerdere meldingen. Omgekeerd geldt echter: één melding is altijd, nooit meer en nooit minder, door één melder gedaan. Wat moet je dan met een plusje? Je ziet in de melding de ID van de melder, en op je formulier zie je dus altijd wie de melding gedaan heeft. Logisch dus.
 
Beste OctaFish

Nu de relaties logischerwijze zijn gelegd was ik bezig met het in mekaar steken van m'n formulier meldingen. Alles verliep goed tot wanneer ik een veld 'bijlagen' uit de tabel 'meldingen details' aan het formulier toegevoegd had. Sindsdien werkt m'n formulier niet meer. Zie ik nog maar 1 record. Als ik bv. op een 'ja/nee' object klik, dan geeft hij de volgende melding in de statusbalk: "De waarde kan niet worden toegevoegd aan deze rij totdat de rij is toegewezen. Wijs de rij eerst toe en probeer de waarde daarna toe te voegen".

Weet jij wat gedaan om dit probleem op te lossen?

Superbedankt.
 
Dan moet ik de db erbij hebben; deze foutmelding zegt mij niks.
 
dacht ik al, heb het geprobeerd maar ze is te groot...
ik probeer iets anders..
 
Met WinRar kun je een archief maken in brokken van 100kb. Of op MijnBestand.nl zetten, dan hoef je verder niks te doen.
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan