Database maken, wie?

Hallo Allen,

Ik heb in het verleden een keer een database opgezet, die achteraf niet meer nodig was.
Maar nu weet ik niet hoe ik een goede database kan maken.

Ik heb dan de vraag wie kan mij helpen?
in privé bericht wil ik meer over deze database vertellen en vragen.

Ik lees graag een bericht van.

Alvast bedankt.
gr
Hans

Het hoe van een database kun je lezen in de Access cursus. Bij dit soort vragen bekruipt me altijd wel het gevoel: hoe groot gaat die database worden? Want het opzetten van een beetje database kost aardig wat tijd. En kennis van de materie. Het is, kortom, echt wel een vak. Dus iemand helpen om een database te maken is meestal geen probleem, maar (ik hoop toch niet onbetaald?) een complete database voor iemand bouwen? En HelpMij is niet opgezet als IkMaakHetWelVoorJou.

Hoi OctaFish,

Nee het is niet de bedoeling dat iemand hem helemaal gaat maken maar wel mij kan begeleiden.
Begin stuk weet ik wel maar hoe verder.

Ik noem even een voorbeeld:
ik wil dus een database maken als Vakbondsconsulent.
hierin moet komen:
* naam, wel/niet lid van bond
* probleem,
* wie te benaderen
* actie die genomen is
* afsluiting

Als overzicht zou ik 1 keer per half jaar willen zien hoevaak ik benadert ben met welk probleem
Dit om verantwoording af te dragen aan bestuurder.

Voor het opzetten van een database maak je eerst een FD (Fuctional Design) Hierin bepaal je welke tabellen je nodig hebt, welke velden je belangrijk vindt en welke relaties er nodig zijn tussen de diverse tabellen.
Met jouw summiere opsomming is niet op te maken hoe je het geheel in elkaar wil steken.

ik wil dus als ik elke gesprek/probleem heb gehad
2x per jaar zien hoevaak deze zijn voorgekomen
Misschien als ik het formulier hier plaats wordt het duidelijker

zie bijlage

In Nederland maken we niet eerst een FD (dat doen ze maar in Engeland) maar een FO, een Functioneel Ontwerp. Daarin staat niet welke tabellen en relaties je nodig hebt; dat staat in het TO (Technisch Ontwerp). In een FO beschrijf je de processen die je vast wilt leggen in je database, en wat daar uit wilt halen. Jouw rapport bijvoorbeeld zou dus op deze manier uit de database moeten komen? Maar dit type rapport is totaal ongeschikt om te laten zien hoe vaak je een gesprek/probleem hebt gehad .
Je rapport dient eerder als uitgangspunt om aan te geven wat je wilt opslaan in de database. Zodra je een weet wat je op wilt slaan, kan je aan het werk om te kijken welke tabellen je daarvoor nodig hebt.
Mocht je het huidige document als rapport uit de database willen halen, dan haal je jezelf flink wat werk op de hals, want dit is geen makkelijk rapport om te maken. Zelfs niet als de database perfect is ingericht .

Wat je dus in ieder geval als eerste moet doen, is het beschrijven van je processen. Wat is de werkwijze van de organisatie? Welke mensen worden geïnterviewd? Je hebt het over Vakbondsmensen. Heb je daar gegevens van, die je ook wilt vastleggen in de database? Of werk je voor bedrijven, waarvan je met de NAW gegevens werkt? Vergelijk deze vraag met een winkel: hier verkoop je artikelen aan klanten, maar je slaat doorgaans de klantgegevens niet op (tenzij ze online bestellen). De gegevens van je leveranciers leg je daarentegen wél vast, omdat je daar meerdere keren mee te maken krijgt.

Je stelt blijkbaar een aantal vaste vragen, die in categorieën vallen. Je werkt dus wellicht met een script. Dat script kan uit de database komen, maar dan moet alles uiteraard ook in de database staan. Dus hoe ga je dien gesprekken in? Leg je alles gelijk vast in de database, of schrijf je eerst alles op?

Kortom: zonder inzicht in de processen, heeft het geen enkele zin om na te denken over tabellen. Laat staan over rapporten.

Hoi,

als je snel en doelgericht wil werken kan je ook werken via de agile methode. Momenteel schakelen de meeste bedrijven over van het vroegere concept: eerst alle analyses en dan beginnen werken, naar de agile methode: je maakt een grove schets van wat je wil doen. In jou geval: ik wil een overzicht van wie me wanneer benadert met welk probleem. Dan omschrijf je de doelen in user stories voor de onderdelen. Dit zijn verhalen die steeds vanuit het oogpunt van de gebruiker worden opgesteld.
Voorbeeld:

Als vakbondsafgevaardigde wens ik te kunnen zien :
- hoeveel vragen er van vakbondsleden en hoeveel van niet leden komen
- wat het type van de vraag is: informatief/advies/bemiddeling/anders . De types moeten later kunnen uitgebreid worden.
- wat het onderwerp van de vraag is. De onderwerpen liggen vast in een lijst die eventueel wel/niet moeten uitgebreid worden
Deze story is afgewerkt wanneer ik
- op een gemakkelijke manier via een zoekformulier de gegevens op een combinatie van de voorgaande criteria kan opvragen
- …

Aan de hand van de vorige vraag kan je al een werkende basis maken met bv. 2 lijst tabellen voor de vraagtypes en onderwerpen, en een tabel voor de vragen: wie;wanneer;type;onderwerp;lid ja/nee; omschrijving vraag
Daarop maak je de nodige formulieren en een rapport, en je hebt al een werkende basis waarmee je kan aan de slag gaan.

Daarna ga je dan in een volgend stadium (of in de agile taal: de volgende sprint) één of meerdere volgende user stories gaan toevoegen, bV. ik wil voor elke vraag de verdere opvolging kunnen monitoren

En zo bouw je stap voor stap een applicatie op, terwijl je al heel snel een eerste resultaat hebt.
Je kan op het internet heel veel info vinden over agile project management en hier vind je alvast de basis: het agile manifest: https://agilemanifesto.org/

Zodra ik 'agile' en 'databases' in één zin lees, breekt het angstzweet mij uit. Ik heb de afgelopen jaren nu een aantal trajecten meegemaakt op het werk waarin met scrum, agile, userstories, sprints en weet ik wat al niet meer applicaties (met onderliggende database) zijn gebouwd, en ik kom maar tot één conclusie: niet doen.... Maakt niet uit welk fantastisch professioneel bedrijf ze maakt, het resultaat is bagger. Aan de andere kant: ik heb nog járen werk om de puinhopen op te ruimen die de scrumteams hebben achtergelaten .
Database agile ontwikkelen is een doodlopende weg. Userstories? Als je een goed Functioneel Ontwerp hebt gemaakt, staan alle functie-eisen daarin gewoon beschreven. Niks grove schets: van te voren bedenken wat je nu wilt hebben, en welke uitbouwmogelijkheden er in de toekomst eventueel nog bij moeten komen. Op basis van het complete plan kun je prima inschatten wat je nodig hebt qua tijd en kunde. En dan kun je gaan bouwen.

Werken met sprints lijkt aardig, maar mijn ervaring is dat je óók met sprints nooit uitkomt met de tijd, en dat projecten dus net zo goed qua planning en kosten uit de hand gieren. Is ook logisch, want je werkt in beginsel met dezelfde personen, alleen heb je ze nu een andere pet op gezet. Daarnaast dwalen agile projecten dus heel makkelijk af van het oorspronkelijke plan, en is er veel te weinig tijd ingepland om de plannen en ontwerpen góed door te denken. Met als resultaat dat er draken van databases worden gebouwd waar vervolgens met allerlei spaghetti en houtje-touwtje oplossingen dan weer noodverbandjes voor worden gemaakt. Maar goed, er zullen vást wel mensen zijn die goede ervaringen hebben met agile. Alleen zou ik er als beginnende ontwikkelaar met een grote boog omheen lopen .

Falende scrum projecten hebben meestal autoritaire stake holders of slechte scrum masters. Een goed scrum team bestaat best niet uit precies dezelfde mensen die op de oude manier werken, je hebt daar ook wel mensen met andere vaardigheden voor nodig, zeker voor de scrum master en product owner. Als je een project wil doen is agile momenteel de meeste gebruikte manier en een goede manier om een werkend resultaat binnen de gestelde periode en budget te krijgen. Je loopt ook niet het gevaar dat de functionele beschrijving tegen het einde van het project al verouderd is. Daarom schakelen de meeste bedrijven in Engeland en België er ook naar over (ik ken de situatie in Nederland niet zo goed, maar bij de Nederlandse bedrijven waarmee ik samenwerk is men ook overgeschakeld). Ook als je alleen ontwikkelt en met een klein project als alleen een database maken, kan je de methodiek gebruiken. Je zal dan al zeker geen communicatieproblemen met jezelf hebben . Het vergt alleen wat meer zelf discipline dan puntje per puntje volgen wat een omschrijving zegt. Het is maar hoe je graag werkt. Maar ik zou het zeker eens uitproberen.

We wachten nog op reactie van TS .

Ach, waarschijnlijk moest dat muurtje er toch uit

PFFFF, heb er inderdaad hoofdpijn van gekregen.
denk als nuchtere burger en die een beetje van access afweet hier een vraag te stellen.
Denk meteen is het hier om mij te stangen of helmpij antwoord te geven.
Jammer, ik zoek wel verder
S6

Deze topic mag van mij gesloten worden.

Lijkt mij een goed plan. En het was ook zeker niet de bedoeling om Hans op welke manier dan ook te stangen . Integendeel, wat mij betreft!

oke 2e kans.

Helaas door ander werkzaamheden heb ik lang niets meer aan Access gedaan maar zou een uitkomst zijn voor een overzicht.
deze moet ik 1x per 6 maanden aan Personeelszaken en aan de vakbond tonen.

Nu probeer ik mijn kennis weer op te pakken om tabellen te maken, maar voor de volgende vragen/uitkomst heb ik geen kaas van gegeten en vraag dan hulp aan jullie.
Graag heb ik dan uitkomst om de volgende vragen:
1. hoe vaak komen de volgende vragen voor ( Informatie/Advies/Bemiddeling/Anders) ?
2. dit ook bij de onderwerpen (CAO algemeen/ arbeidsovereenkomst/ontslag ect)?

Ik maak nu eerst een tabel met de vragen:
Type vraag:
onderwerp:
eerste contactlegging van collega via?
Lid? ja of nee of andere vakbaond
Bijgewoonde bijeenkomsten?
contactmomenten (servicebalie/Belangenbehartiger/OR/P&O/Raad van Bestuur)
Profiliering: Tekst vak
Scholing: tekst vak
samenwerking: tekstvak
tips en tools: tekst vak
overige opmerkingen

Graag jullie tips

Alvast bedankt

Velden in je tabel zou ik zo maken:


Ik heb nog wel een paar opmerkingen aangaande velden 7 en 8: dit riekt naar een aparte tabel; zodra je per vraag meerdere bijeenkomsten kan registreren, zou je die bijeenkomsten in een aparte tabel moeten vastleggen met een één-op-veel relatie met de tabel Vragen. Hetzelfde geldt voor vraag 8. Als een contactmoment bij een bijeenkomst hoort, kunnen ze uiteraard in dezelfde tabel.
Verder Mis ik een personen tabel, maar daar heb je in een eerder bericht al melding van gemaakt, dus die zal er wel zijn .

Dank je wel voor je reactie.

Het gaat hier niet om de persoon zelf, ivm AVG en heeft nader geen belang.

ondertussen had ik al iets gemaakt (zie bijlage)