[ACCESS] Problemen met opdracht database ontwikkeling

[Verwijderd]

Ik zal even de opdracht erbij posten, om het op die manier iets makkelijker te maken. Ik ben een totale kneus hierin, maar moet het echt halen! Ik ben zelf de hele dag al bezig geweest, maar wil graag de mening van jullie horen. Zeg aub niet dat ik nog eens goed in mijn boeken moet kijken, maar neem even de moeite (als je tijd hebt) om te kijken en je mening te geven. Voor dit bedrijf moet ik een geautomatiseerd systeem maken.

In 1994 werd de makelaardij "De BOUWVAL" opgericht. Het bedrijf bestaat nu uit een administratieve afdeling, de boekhoudafdeling en de afdeling onroerend goed.
De administratie bestaat uit drie medewerkers, met een hoofd administrateur. Een van deze medewerkers is ook belast met personeelsadministratie. De boekhoudafdeling bestaat uit 2 financieel experts. De afdeling onroerend goed wordt bemand door 4 medewerkers. De administratie is verantwoording verschuldigd aan de boekhoudafdeling. De rest van de afdelingen is verantwoording verschuldigd aan de directeur (tevens eigenaar). Alle opdrachten van klanten komen binnen op administratie. Deze afdeling houdt sterk vast aan handmatige verwerking. Deze noteert handmatig op een klantenformulier de gegevens van de klant. De hoofdadministrateur controleert vervolgens het klantenformulier. Is het formulier niet juist ingevuld dan gaat het formulier terug naar de administratieve medewerkster ter correctie. Deze moet dan de klant bellen voor aanvullende informatie. Na goedkeuring gaat het formulier naar de afdeling onroerend goed en komt willekeurig terecht bij een van de medewerkers. Deze medewerker van de afdeling onroerend goed belt vervolgens de klant voor een afspraak. Door deze gang van zaken gaat er veel tijd verloren. Veel klanten laten het hierdoor afweten en gaan naar een andere makelaardij.
De gegevens van de onroerende goederen worden bijgehouden op afzonderlijke lijsten door de medewerkers van de afdeling onroerende goederen. Deze gaan 1 maal per maand naar de afdeling administratie en worden daar bijgewerkt. Alle medewerkers van de afdelingen krijgen een kopie van deze lijsten. Vaak blijken in de loop van de maand gegevens op de lijsten niet meer te kloppen. Soms zijn huizen al verkocht door een andere medewerker. Hierdoor ontstaan veel klachten en ontevreden klanten.
De administratie besteedt een groot deel van de werkdag aan het uitzoeken van klantgegevens voor de vervaardiging van koopcontracten. Veel koopcontracten worden hierdoor te laat verzonden met als gevolg dat de klanten alsnog afhaken. Een totaaloverzicht van klantgegevens ontbreekt eveneens. Het versturen van mailingen neemt veel tijd in beslag. Het vervaardigen van overzichten voor het management vergt erg veel werk. De directeur van het bedrijf besluit voor het gehele bedrijf een goed geautomatiseerd informatiesysteem op te laten zetten.

Ik ben een beetje aan het kloten geweest en zal proberen op papier te zetten wat ik tot nu toe heb.

ORDERS
Order ID
Klant ID
Werknemer ID
Orderdatum

ORDERINFORMATIE
Order ID
Huis ID
Prijs

HUIZEN
Huis ID
Verkoper ID
Gegevens van het huis

VERKOPER ID
Verkoper ID
Gegevens van de Verkoper

KLANTEN
Klant ID
Gegevens van de klant

WERKNEMERS
Werknemer ID
Gegevens van de werknemer

Zouden jullie me misschien kunnen zeggen of dit ergens op lijkt of totaal niet? Natuurlijk staat er bij klanten veel meer informatie, maar het zijn allemaal standaard dingen zoals adres en naam. Ik wil op deze manier zorgen dat een medewerker op de administratie snel kan invoeren dat een klant een woning heeft gekocht en dat het hele bedrijf dat in de database zal zien. Klopt de indeling van de tabellen een beetje of zou er een andere indeling voor moeten komen? Zou iemand me een beetje op weg kunnen helpen?

Hartstikke bedankt voor de moeite!

Robbie

PS Ik hoop niet te horen dat ik boeken moet open slaan, maar iemand even de moeite neemt.... bedankt!

[farlane]

Als je zorgt dat je op het eind nog kunt opvragen welke mensen allemaal met een bepaalde opdracht bezig zijn geweest, lijkt het mij ok.

Dus, zorg dat je het traject dat een opdracht door de firma maakt goed kunt volgen.

Een aantal vraagtekens :

Waarom heb je zo'n wazige opdeling in orders en orderinformatie ?

Waarom maak je een verkoper en een werknemer tabel ? Zijn verkopers geen werknemers ?

Kan aan een order maar een werknemer werken ? Of kunnen er meerdere werknemers aan werken ? ( Misschien kan er op de helft van het traject een andere verkoper op die order gaan werken? )

Verder zou ik geen "huizen" tabel maken maar een "onroerend_goed" tabel, of verkoopt die firma alleen huizen ?

[ Voor 49% gewijzigd door farlane op 04-12-2003 00:31 ]

[Bud_s]

farlane schreef op 04 december 2003 @ 00:25:
Als je zorgt dat je op het eind nog kunt opvragen welke mensen allemaal met een bepaalde opdracht bezig zijn geweest, lijkt het mij ok.

Dus, zorg dat je het traject dat een opdracht door de firma maakt goed kunt volgen.

Een aantal vraagtekens :

Waarom heb je zo'n wazige opdeling in orders en orderinformatie ?

Die opdeling kan alleen gerechtvaardigd worden door meerdere huizen in een order te verkopen, ik denk niet dat dit aan de orde zal zijn. Als het wel zo is, wat doe je dan op het moment dat een van de huizen (orderregel) niet doorgaat (vervalt) ?
In mijn ogen heb je per object een order (maar wie ben ik)

farlane schreef op 04 december 2003 @ 00:25:

Waarom maak je een verkoper en een werknemer tabel ? Zijn verkopers geen werknemers ?

Kan aan een order maar een werknemer werken ? Of kunnen er meerdere werknemers aan werken ? ( Misschien kan er op de helft van het traject een andere verkoper op die order gaan werken? )

Verder zou ik geen "huizen" tabel maken maar een "onroerend_goed" tabel, of verkoopt die firma alleen huizen ?

Iets wat ik in het geheel mis, is een status. Ik neem aan dat het voor de verkopers en zeker voor het management interesant is om te zien wat nog onderhande werk is , wat afgewerkt is, of waar nog evt. acties openstaan.

Als een een order in afwachting van een actie (bv. extra informatie vraag van klant) zal dit waarschijnlijk handig zijn dit terug te zien in een actie lijst.
Op een actie lijst verwacht je dus vanf wanneer een actie openstaat, wanneer een actie gedaan moet zijn en zeker niet te vergeten : door wie de actie genomen moet worden. Zo kan je dus per medewerker / verkoper zien wat openstaande acties zijn. Ook aan de acties een datum hangen wanneer de actie gedaan is.

Met die info kan je snel achterhalen waar evt. de doorloop van een verkoop stagneerd en kan het management actie ondernemen om dit te versnellen

Zonder status heb je geen overzicht maar een lijst !

Een lijst is een opsomming waar je regel voor regel moet lezen (en nadenken) en overzicht is .... het woord zegt het al

Nog een tip : Begin aan de achterkant !

De achterkant is de informatie behoefte !

Ga bij de verantwoordelijke personen na wat voor informatie ze echt nodig hebben, en probeer hier niet te veel te denken in de huidige informatie voorziening.

Voor dat je de vraag krijgt om allerlei gelikte, nette, grafische rapporten te generen neem het volgende in acht :

Er zijn eigenlijk maar 2 typen overzichten :
- Need to have.
- Nice to have.

Ga vervolgens aan de hand van de inventarisatie bepalen wat er te realiseren is, en hoeveel tijd het kost. Als je problemen voorziet in een Need-to-have rapport, ga terug naar die persoon en probeer evt. een alternatief te creeeren.

Een Nice-to-have kan eigenlijk nooit de project voortgang verstoren, dit kan later nog gerealiseerd worden. (houd er natuurlijk wel rekening mee)

Maak een projectplan met mijlpalen en een tijdpad. Doe de Nice-to-have stuff in een tweede fase , maar laat dit niet je hoofdproject verstoren ! Vaak lopen projecten onnodig lang (of lopen totaal mis) door dit soort hebbedingetjes.

Nog een keer : vergeet niet een status mee te nemen op verschillende nivo's, je kan dan alles lekker traceren en filteren !
Dus op kop nivo voor bv. de orders , en op regelnivo voor o.a. de actie's

Ik hoop dat je hier wat mee kan

PS: je topic zegt [ACCESS] .... maar vergeet niet dat access een tool is, een technisch hulpmiddel om in de informartie vraag te voorzien. Je probleem is dus de informatie vraag, en hoe dit te fixen met de voorhande zijnde informatie.

[ Voor 8% gewijzigd door Bud_s op 04-12-2003 01:35 ]

[Verwijderd]

Heel erg bedankt voor de antwoorden. Ik heb het allemaal een beetje veranderd en ik heb een paar vragen aan jullie. Het ziet er nu zo uit:

ORDERS
Order ID
Klant ID
Werknemer ID
Onroerend Goed ID
Order Datum

KLANTEN
Klant ID
Gegevens Klant

WERKNEMERS
Werknemer ID
Gegevens Werknemer

ONROEREND GOED
Onroerend Goed ID
Gegevens Onroerend Goed
Oude Eigenaar ID
Status

OUDE EIGENAAR
Oude Eigenaar ID
Gegevens Oude Eigenaar

Op die manier lijkt het me mogelijk dat meerdere werknemers aan een order werken. Moeten er meer dingen bij om dit te realiseren?

Bij de nieuwe versie kan bij oroerend goed een status worden ingevoerd. Verkocht of vrij etc....

Ik las dat er bij deze database meerdere huizen in een order konden, maar dat is niet de bedoeling! Hoe krijg ik het voor elkaar om een order met een huis te koppelen en niet twee huizen?

Ziet het er nu wel goed uit en zou het kunnen werken? Zo nee, wat moet er nog meer veranderd worden?

Robbie

[MMUilwijk]

Verwijderd schreef op 04 december 2003 @ 16:20:
Heel erg bedankt voor de antwoorden. Ik heb het allemaal een beetje veranderd en ik heb een paar vragen aan jullie. Het ziet er nu zo uit:

ORDERS
Order ID
Klant ID
Werknemer ID
Onroerend Goed ID
Order Datum

KLANTEN
Klant ID
Gegevens Klant

WERKNEMERS
Werknemer ID
Gegevens Werknemer

ONROEREND GOED
Onroerend Goed ID
Gegevens Onroerend Goed
Oude Eigenaar ID
Status

OUDE EIGENAAR
Oude Eigenaar ID
Gegevens Oude Eigenaar

Op die manier lijkt het me mogelijk dat meerdere werknemers aan een order werken. Moeten er meer dingen bij om dit te realiseren?

Bij de nieuwe versie kan bij oroerend goed een status worden ingevoerd. Verkocht of vrij etc....

Ik las dat er bij deze database meerdere huizen in een order konden, maar dat is niet de bedoeling! Hoe krijg ik het voor elkaar om een order met een huis te koppelen en niet twee huizen?

Ziet het er nu wel goed uit en zou het kunnen werken? Zo nee, wat moet er nog meer veranderd worden?

Robbie

offtopic:
Je wil graag een database maar wilt geen moeite doen om te leren hoe je tot een bepaalde structuur komt ? Sorry hoor, maar ga eens wat zoeken over normaliseren e.d. ?

Met deze opzet kan er maximaal 1 huis per order voorkomen, precies wat jij wil hebben. Verder is het lastig tips te geven over wat er veranderd moet worden, JIJ hebt immers de informatieanalyse gedaan! Afhankelijk van wat de klant wil zal JIJ een gegevensmodel moeten maken !

[farlane]

TIP: Je zou dus een veel op veel relatie kunnen maken tussen orders en wernemers als je meerdere werknemers met een order wilt associeren

[Verwijderd]

Wat is een veel op veel relatie? Het moet mogelijk zijn dat er meerdere werknemers aan werken, ja

[Verwijderd]

En even over dat normaliseren. Ik heb dat vorig jaar gehad en begreep er niks van. Normaliseren probeer ik juist tot het einde te bewaren, want daar ga ik juist mee de fout in! Een bestaande database normaliseren is toch een stuk makkelijker?

[whoami]

Verwijderd schreef op 05 december 2003 @ 08:52:
Wat is een veel op veel relatie? Het moet mogelijk zijn dat er meerdere werknemers aan werken, ja

Dat kan je verwezenlijken door gebruik te maken van een 'koppeltabel'. In die tabel ga je dus de relatie tussen werknemer en opdracht gaan vastleggen:

code:

werknemer (werknemerid, werknemernaam, ....)
opdracht (opdrachtid, opdrachtnaam, ....)
werknemer_opdracht(werknemerid, opdrachtid)

Maar, zoals hier reeds geopperd is: lees eens iets over normalisatie

[Sherlock]

Deze link kreeg ik laatst van whoami, lijkt me erg handig om eens door te lezen! (En nee, dat duurt niet zo lang als je denkt)

edit:
spuit 11 enzo

[ Voor 7% gewijzigd door Sherlock op 05-12-2003 09:01 ]

[P_de_B]

Verwijderd schreef op 05 december 2003 @ 08:54:
En even over dat normaliseren. Ik heb dat vorig jaar gehad en begreep er niks van.

Dan zou ik maar zorgen dat ik er verstand van kreeg, normaliseren is wel een aardig belangrijk gegeven bij het ontwerpen van een database.

Verder, maar dat is persoonlijk, vind ik dit een beetje "Doen jullie mijn huiswerk even". Je wilt geen boek openslaan zeg je in je eerste post, je wilt gewoon antwoorden. Ik denk dat je zonder een redelijk goede kennis van normaliseren en het ontwerpen van een relationele database nooit zo'n opdracht goed kan uitvoeren.

Dus, normaliseren leren, een ontwerp maken en eventueel over de lastige dingen hier een discussie starten lijkt mij een mooie route. Succes!

[whoami]

Verwijderd schreef op 05 december 2003 @ 08:54:
En even over dat normaliseren. Ik heb dat vorig jaar gehad en begreep er niks van. Normaliseren probeer ik juist tot het einde te bewaren, want daar ga ik juist mee de fout in! Een bestaande database normaliseren is toch een stuk makkelijker?

Een bestaande database is -als het goed is- al genormaliseerd.
En normalisatie moet je net niet tot op het laatste houden. Bij het normaliseren van je databank ga je de structuur van je DB gaan bepalen. Een project staat of valt met een goeie database-structuur. Dat is nu eenmaal iets dat je niet tot op het laatste kunt houden.
Je moet eerst de structuur van je gegevens gaan bepalen eer je er iets zinvols mee kunt doen. Als je achteraf je db-structuur gaat gaan vastleggen, dan moet je alles veranderen: queries, data-laag, etc....
Ik zou dus nog maar eens de moeite doen, en dat normaliseren heroppikken en proberen te begrijpen; als je dat nl. niet begrijpt, dan moet je geen databases gaan ontwikkelen.

[Verwijderd]

Ik heb nu de 0e normaalvorm gemaakt. Bij de 1e normaalvorm moet ik de repeterende groepen eruit halen, toch? En lijkt dit ergens op?

0NV
( Ordernummer, Datum, RG ( Kopervoornaam, Kopertussenvoegsel, Koperachternaam, Koperstraat, Koperhuisnummer, Kopertoevoegsel, Koperpostcode, Koperwoonplaats, Koperprovincie, Koperland, Kopertelefoonnummer, Kopermobieltelefoonnummer, Koperfaxnummer, Koperemail, Koperbanknummer, Kopergebeld, Koperafspraak ), RG ( OGStraat, OGHuisnummer, OGToevoeging, OGPostcode, OGPlaats, OGProvincie, OGLand, OGPrijs, OGStatus ), RG ( Verkopervoornaam, Verkopertussenvoegsel, Verkoperachternaam, Verkoperstraat, Verkoperhuisnummer, Verkopertoevoegsel, Verkoperpostcode, Verkoperwoonplaats, Verkoperprovincie, Verkoperland, Verkopertelefoonnummer, Verkopermobieltelefoonnummer, Verkoperfaxnummer, Verkoperemail, Verkoperbanknummer ), RG ( Werknemervoornaam, Werknemertussenvoegsel, Werknemerachternaam, Werknemerstraat, Werknemertoevoegsel, Werknemerpostcode, Werknemerplaats, Werknemerprovincie, Werknemerland, Werknemerafdeling, Werknemertelefoonnummer, Werknemermobieltelefoonnummer, Werknemerfaxnummer, Werknemeremail, Werknemerbanknummer ))

[Verwijderd]

Ik ben dus maar even gewoon door gegaan, maar ik heb nu geen idee of dit ergens op lijkt. Zouden jullie even kunnen kijken en oordelen?

0NV
( Ordernummer, Datum, RG ( Kopervoornaam, Kopertussenvoegsel, Koperachternaam, Koperstraat, Koperhuisnummer, Kopertoevoegsel, Koperpostcode, Koperwoonplaats, Koperprovincie, Koperland, Kopertelefoonnummer, Kopermobieltelefoonnummer, Koperfaxnummer, Koperemail, Koperbanknummer, Kopergebeld, Koperafspraak ), RG ( OGStraat, OGHuisnummer, OGToevoeging, OGPostcode, OGPlaats, OGProvincie, OGLand, OGPrijs, OGStatus ), RG ( Verkopervoornaam, Verkopertussenvoegsel, Verkoperachternaam, Verkoperstraat, Verkoperhuisnummer, Verkopertoevoegsel, Verkoperpostcode, Verkoperwoonplaats, Verkoperprovincie, Verkoperland, Verkopertelefoonnummer, Verkopermobieltelefoonnummer, Verkoperfaxnummer, Verkoperemail, Verkoperbanknummer ), RG ( Werknemervoornaam, Werknemertussenvoegsel, Werknemerachternaam, Werknemerstraat, Werknemertoevoegsel, Werknemerpostcode, Werknemerplaats, Werknemerprovincie, Werknemerland, Werknemerafdeling, Werknemertelefoonnummer, Werknemermobieltelefoonnummer, Werknemerfaxnummer, Werknemeremail, Werknemerbanknummer ))

1NV
( Ordernummer, KoperID, Kopervoornaam, Kopertussenvoegsel, Koperachternaam, Koperstraat, Koperhuisnummer, Kopertoevoegsel, Koperpostcode, Koperwoonplaats, Koperprovincie, Koperland, Kopertelefoonnummer, Kopermobieltelefoonnummer, Koperfaxnummer, Koperemail, Koperbanknummer, Kopergebeld, Koperafspraak )
( Ordernummer, OGID, OGStraat, OGHuisnummer, OGToevoeging, OGPostcode, OGPlaats, OGProvincie, OGLand, OGPrijs, OGStatus )
( Ordernummer, VerkoperID, Verkopervoornaam, Verkopertussenvoegsel, Verkoperachternaam, Verkoperstraat, Verkoperhuisnummer, Verkopertoevoegsel, Verkoperpostcode, Verkoperwoonplaats, Verkoperprovincie, Verkoperland, Verkopertelefoonnummer, Verkopermobieltelefoonnummer, Verkoperfaxnummer, Verkoperemail, Verkoperbanknummer )
( Ordernummer, WerknemerID, Werknemervoornaam, Werknemertussenvoegsel, Werknemerachternaam, Werknemerstraat, Werknemertoevoegsel, Werknemerpostcode, Werknemerplaats, Werknemerprovincie, Werknemerland, Werknemerafdeling, Werknemertelefoonnummer, Werknemermobieltelefoonnummer, Werknemerfaxnummer, Werknemeremail, Werknemerbanknummer )
( Ordernummer, Datum )

2NV
( Ordernummer, KoperID )
( KoperID, Kopervoornaam, Kopertussenvoegsel, Koperachternaam, Koperstraat, Koperhuisnummer, Kopertoevoegsel, Koperpostcode, Koperwoonplaats, Koperprovincie, Koperland, Kopertelefoonnummer, Kopermobieltelefoonnummer, Koperfaxnummer, Koperemail, Koperbanknummer, Kopergebeld, Koperafspraak )
( Ordernummer, OGID )
( OGID, OGStraat, OGHuisnummer, OGToevoeging, OGPostcode, OGPlaats, OGProvincie, OGLand, OGPrijs, OGStatus )
( Ordernummer, VerkoperID )
(VerkoperID, Verkopervoornaam, Verkopertussenvoegsel, Verkoperachternaam, Verkoperstraat, Verkoperhuisnummer, Verkopertoevoegsel, Verkoperpostcode, Verkoperwoonplaats, Verkoperprovincie, Verkoperland, Verkopertelefoonnummer, Verkopermobieltelefoonnummer, Verkoperfaxnummer, Verkoperemail, Verkoperbanknummer )
( Ordernummer, WerknemerID )
(WerknemerID, Werknemervoornaam, Werknemertussenvoegsel, Werknemerachternaam, Werknemerstraat, Werknemertoevoegsel, Werknemerpostcode, Werknemerplaats, Werknemerprovincie, Werknemerland, Werknemerafdeling, Werknemertelefoonnummer, Werknemermobieltelefoonnummer, Werknemerfaxnummer, Werknemeremail, Werknemerbanknummer )
( Ordernummer, Datum )

[farlane]

Ik hoop niet dat je verwacht dat we ( ik ) die brei ga napluizen of wel ?

Als je het duidelijk wil maken post dan een grafisch overzicht.

[Sherlock]

Haal eerst eens de helft van je informatie weg. Om het principe te snappen hoef je ook niet te weten hoevel 65732465239876 * 348750922 is. Als je 3 * 2 = 6 snapt dan kun je de eerste som ook.

[Verwijderd]

Het is toch redelijk duidelijk zo???

[whoami]

Verwijderd schreef op 09 december 2003 @ 14:55:
Het is toch redelijk duidelijk zo???

Nee, het is niet duidelijk zo.
Het is een brij, en ik heb ook geen zin (niemand denk ik) om die brij te gaan bekijken en ontcijferen.
Maak een grafisch model van jouw tabellen met de tussenliggende relaties (dat kan je makkelijk doen in access), en post dit hier.