multi-relationele structuur database

Status
Niet open voor verdere reacties.
Y

yokiamy

Gebruiker
Lid geworden
19 okt 2009
Berichten
23
beste mensen

Ik heb met veel bewondering het forum bekeken, veel mooie dingen voorbij zien komen,maar nog niet genoeg inspiratie opgedaan tot een oplossing op mijn probleem, hopelijk willen jullie meedenken.

ik ben bezig met de opzet van een database voor een order handling systeem en ik heb een boekje access 2003 doorgewerkt en ik zit er nu wel redelijk in de materie.

Een databaseje maken lukt dan ook best aardig, alleen het enige punt is dat alle voorbeelden/boeken uitgaan van een bepaalde output, dus of een factuur of een order of wat dan ook (zo ook noordenwind/northwind).

Ik heb uren lopen nadenken over hoe je meerdere outputs kunt krijgen, allerlei structuren bedacht en op papier gezet, maar ik kom er nog niet uit.

Ik wil een systeem maken waarmee ik een offerte kan maken, een orderbevestiging, een factuur een paklijst en een delivery note.

Volgende punt, een item kan niet altijd op voorraad zijn, dus als een klant 10 items bestelt en er liggen 5 op de plank, hoe verwerk ik dat in de database? er moet dan een deellevering worden gedaan, dus ook een deelfactuur, een deelpaklijst en een deel-delivery-note?

vooralsnog zie ik geen oplossing dan complete orders te moeten verwerken, dat moet toch anders kunnen?

Alvast bedankt voor jullie inspiratie

mvg. Pieter

Kan iemand mij meer inzicht geven in de manier hoe je dit het beste vorm kunt geven in de relationele-structuur?
 
Laatst bewerkt:
Je bent heel ambitieus.
Dit is behoorlijk complex om te bouwen en niet iets voor beginners. Ik zie mezelf een gemiddeld+ Access gebruiker maar ik zou dit niet willen gaan bouwen.

Voor ieder type output dien je tabellen aan te maken, ook nog tabellen om de geschiedenis bij te houden, tel daarbij nog de koppel tabellen bij en bij multi-user omgeving misschien ook nog wat lokale tabellen.
Ik schat rustig een tabel of 100 waar je aan moet gaan denken maar ga je echt iets leuks met een modulaire basis bouwen reken dan op een veelvoud (in de omgeving hier meer dan 800, geen Access overigens).

Mocht je willen experimenten, neem dan 1 deel eruit (voorraad beheer) en bouw dat eerst, daarna uitbreiden met een verkooplijn (offerte - order factuur). Maar dan kom je al heel wat beren tegen. Maar aan de andere kant, laat nooit iemand vertellen dat iets niet kan!
 
Mij lijkt het aantal van 100+ tabellen een beetje uit de lucht gegrepen... Zelf gebruik ik op het werk een database met zo'n 60 tabellen, maar die wordt dan ook gebruikt voor Bestellingen, CMDB, Personenregistratie, Reserveringen, Onderhoud en Wijzigingsbeheer, om maar eens wat modules te noemen. Voor het bestellingendeel worden ongeveer 5 tabellen gebruikt, daar komen dan nog wat tabellen bij, zoals leveranciers, artikelen etc.
Maar dat het een ambitieuze klus is, kun je inderdaad wel zeggen. Zet in ieder geval op papier wat je wilt doen, en probeer de relaties tussen de verschillende gegevens goed vast te leggen. Bedenk daarbij hoe je de artikelen wilt koppelen. Kan één artikel bijvoorbeeld door verschillende leveranciers worden geleverd? Als je deelfacturen en deelleveringen wilt kunnen maken, dan moet je die tabellen inderdaad splitsen. Op zichzelf zit er een bepaalde logica in een db opzet. Nogmaals: zet alles eerst goed op papier, waarbij je zowel in tekst omschrijft wat er moet kunnen gebeuren, en probeer dat te vertalen in een datamodel.
Als je e.e.a. wilt voorleggen hier, willen we daar uiteraard graag op schieten!
 
Toch is er niks uit de lucht gegrepen. Er zijn verschillende database methodieken wat gevolgen heeft voor het aantal tabellen maar ook voor de schaalbaarheid. Niet iets wat hier relevant is.

Maar neem als voorbeeld orders met deelleveringen: ga je die per deellevering factureren of juist per volledig afgeleverde order? Dit kan per klant per project verschillen, afhankelijk van de aard en looptijd van het project. Het aantal tabelletjes loopt dan al snel op. Overigens is het aantal tabellen geen probleem, de beheerbaarheid daar en tegen wel.
Voorraad beheer, in welke mate ga je die doorvoeren, evenals artikelbeheer. Een goed genormaliseerd artikel-product-systeem beslaat alleen al uit exact 20 tabellen waar vervolgens de klantkortingen nog niet zijn meegenomen. Klantkortingen, per klantgroep/productgroep, staffels, individuele prijsafspraken en boni zijn algauw weer een tabel of 10.
Bij een doordacht schaalbaar systeem zit je al snel aan 100+ tabellen maar e.e.a zal zeker ook inherent zijn aan de branche (dagprijzen t.o.v. prijzen die eens per periode veranderen is al weer zo'n verschil, vooral bij offertes en langlopende projecten).
 
Laatst bewerkt:
Ben ik toch blij dat ik 't met veel minder tabellen kan maken ;) En hoe kom je hierbij?
Een goed genormaliseerd artikel-product-systeem beslaat alleen al uit exact 20 tabellen
Klik om te vergroten...
 
Geen ontwerp van mij maar een standaard in de branche waarin ik zit.
Wel zeer goed doordacht en er is rekening gehouden met de enorme aantallen records (ettelijke miljoenen zijn geen uitzondering). Bij dit soort aantallen kan je grote velden beter in een aparte tabel te plaatsen wanneer de gegevens minder frequent worden aangeroepen. Verder zijn er aparte tabellen voor de diverse eenheden (verpakkingen, tijden, specificaties enz, in totaal 8). En zo is gaat het verder. Het zijn geen zaken die je op een avondje uitwerkt, laat ik het zo stellen.
 
Laatst bewerkt:
We weten nog helemaal niet wat TS allemaal van plan is, en hoe groot het allemaal moet (kunnen) worden. Het lijkt mij daarom niet zo zinvol om 'm dan maar gelijk zodanig schrik aan te jagen dat-ie het project gelijk aan de wilgen hangt. Ik dacht dat we hier met z'n allen proberen mensen te helpen, niet om ze weg te jagen...
 
Verwachtte ik eigenlijk ook niet ;)
Ben ondertussen wel benieuwd naar uitgebreidere info van de TS!
 
Beste Mensen

Bedankt voor alle informatie tot nu toe

Ik begrijp dat het dus niet in een paar dagen klaar is, beetje afhankelijk van de grootte en de toepassing.

Het zou mooi zijn om miljoenen records te hebben met orders en klanten en facturen maar zover zijn we nog niet.

Wij hebben slechts enkele toeleveranciers en geen duizenden producten, waardoor het voorraadbeheer al wat makkelijker beheerbaar is, dit is makkelijk zelf in te voeren.

Het voornaamste punt is dat er gewoon een duidelijk en overzichtelijk systeem moet komen zodat we niet meer alle documenten zelf hoeven te typen en we af zijn van de hele stapel lijstjes in excel. (niet lachen)

Belangrijkste is traceerbaarheid en dat je met weinig moeite de status van een bepaalde order moet kunnen bekijken, dus als een klant akkoord gaat met de (in access gegenereerde) offerte wil ik naar die offerte kunnen refereren in de bevestiging, eveneens hetzelfde met de verzendlijst/paklijst en uiteraard een factuur.
en ik wil deze gegevens graag ook opslaan in tabellen en niet alleen laten genereren in een rapport, zodat je alle gegevens exact bijhoudt via een mooi systeem, dat voorkomt dat als je een factuur opnieuw moet uitdraaien dat er opnieuw een berekening wordt gedaan met een gewijzigde prijs waardoor het factuurbedrag niet meer correspondeert met het originele bedrag.

Met het bedenken van deze structuur heb ik eerst al even genoeg, maar dan wordt het helemaal mooi, zoals Floor E al zegt

"Maar neem als voorbeeld orders met deelleveringen: ga je die per deellevering factureren of juist per volledig afgeleverde order? Dit kan per klant per project verschillen, afhankelijk van de aard en looptijd van het project. Het aantal tabelletjes loopt dan al snel op. Overigens is het aantal tabellen geen probleem, de beheerbaarheid daar en tegen wel."

Moet ik daar nu al over nadenken of mag dat ook later? of heeft dat dan effect op het reeds bedachte? Mijn angst is dat ik iets over het hoofd zie en ik dan vast kom te zitten in de eerder bedachte structuur met als gevolg dat ik dan alles vrolijk opnieuw mag gaan maken

ik denk trouwens dat ik beide zou willen qua factureren, afhankelijk van mijn gemoedstoestand en de relatie tot de klant ;)

Overigens had ik gehoopt geen 100-den tabellen nodig te hebben, eerder een voortborduursel op een Noordenwind...
 
Zoals ik al aangaf: het aantal tabellen dat Floor aangaf is hogelijk overdreven. Blijkbaar hebben ze in zijn werkomgeving zo'n constructie nodig; daar kan ik uiteraard niet over oordelen. In mijn (toch ook een paar jaar omspannende) ervaring ben ik dit aantal gelukkig nog niet tegengekomen. En het is ook niet zo dat een db met meer tabellen beter is als een db met minder. Het hangt er helemaal vanaf wat je wilt. Je kunt bestellingen/facturen opsplitsen in deeltabellen als je dat nodig hebt. Maar als dat niet nodig is: niet doen! Je kunt in je facturentabel namelijk ook je deelfacturen verwerken, zolang je maar aangeeft dat het een deelfactuur betreft van een andere factuur. Maar daar zou ik mij op dit moment niet eens mee bezighouden; zet eerst je wensen op papier, en wat de db moet doen, en wat je er uit wilt kunnen halen; de noodzakelijke tabellen(structuur) kun je daar vervolgens wel uit afleiden.
 
Octafish

dank voor je antwoord, dat geeft weer hoop! Ik ga eerst weer vrolijk verder nadenken, updates komen t.z.t.

bedacht: rel1.JPG

Ik heb uren lopen nadenken en het meest logische dat ik tot nu toe heb kunnen verzinnen is dit, ik ga ervan uit dat de offerte de 'hoofd'tabel vormt welke een referentienummer aanmaakt. Op het moment dat de offerte is goedgekeurd, of de klant direct bestelt zonder offerte (nog evenuitzoeken hoe dit makkelijk kan)kan de status wijzigen van open naar goedgekeurd en kan er een orderbevestiging worden gemaakt, op zijn beurt weer een packinglist op basis van de voorraadstatus worden gemaakt en dan weer een factuur/invoice (ik weet het engels + nederlands door elkaar, nog even consistent maken)

Momenteel zie ik al genoeg beren op de weg, zoals, gaat bovenstaande goed?
kan ik hiermee straks wel deelfacturene.d. maken?
kan ik straks via een query makkelijk eerst de categorie selecteren (compleet apparaat, losse onderdelen, of slijtagedelen (welke dus het meest besteld zullen worden))
kan ik via deze structuur dmv berekeningen automatisch de voorraadstatus bijwerken e.d.?

Als jullie willen schieten, graag!
(tips zijn zeer welkom, aangezien ik de hele dag al door het bos lijk te lopen, door de bomen het bos niet meer zie en ondertussen wel allemaal beren tegenkom... ;) )
 
Laatst bewerkt:
update

Ik ben eerst begonnen met het opzetten van de eerste stap, het maken van een offerte, dit heeft idd al genoeg voeten in de aarde. (soms kun je uren zoeken naar 1 dingetje)
Dit begint er al behoorlijk op te lijken dus kan ik straks naar stap 2, offerte omzetten in order.

Al doende begin ik access steeds beter te begrijpen, later zal ik de opgezette structuur proberen te gebruiken voor het verder verwerken van de hele 'order handling', mocht dat niet lukken dan zal ik wijzigingen doorvoeren, mocht ik daar niet uit komen zal ik wederom vragen om tips.
in ieder geval bedankt voor de info tot nu toe, al veel nuttige tips gevonden op helpmij.nl
 
afhankelijke keuzelijst

vraagje waar ik tegenaan loop en hoop dat jullie inspiratie kunnen geven;

ik heb n.a.v. o.a. tips op helpmij een afhankelijke keuzelijst met invoervak gemaakt, zodat ik eerst de categorie producten kan selecteren en later uit deze categorie het juiste product. (eenzelfde structuur wil ik ook gebruiken voor klanten, met verzendadres en factuuradres e.d.)

Nu werkt dit op zich wel, maar nog niet optimaal

het is een subform op een hoofdform, (subform in gegevensbladweergave) waarin eerder gemaakte offertes staan.
Als ik de eerste keuzelijst afhankelijk maak (via besturingselement bron) laat hij netjes bij de reeds gemaakte offertes zien welke categorie het product valt, maar kan ik vervolgens in de tweede keuzelijst met invoervak enkel scrollen en NIET selecteren.

als ik de 1e (categorie) niet afhankelijk maak laat hij voor alle eerder ingevoerde offertes geen categorie zien, maar kan ik in de tweede lijst wel selecteren, nadat ik eerst een categorie heb gekozen, alleen maakt hij dan alle categorienummers hetzelfde (dus bij eerder ingevoerde records)
Waar kan dit aan liggen?

b.v.d.
gr. Pieter
 
Precies aan wat je al aangaf: de manier waarop je werkt met een keuzelijst. Objecten op een formulier, zoals tekstvelden en keuzelijsten, kun je afhankelijk maken, of niet-afhankelijk. In het eerste geval koppel je ze aan een veld in je tabel, in het tweede geval uiteraard niet. Zijn ze gekoppeld, dan zie je de opgeslagen waarden terug in de keuzelijst, bij een niet-gebonden uiteraard niet.

Een 'hoofdkeuzelijst' kun je op zich nog wel koppelen aan een tabelveld, al probeer ik dat zelf eigenlijk niet te doen. Ik maak de keuzelijsten bij voorkeur onafhankelijk, en laat de gekozen waarde opslaan in een tekstveld, dat wel is gekoppeld aan een tabelveld.
Een vervolgkeuzelijst moet uiteraard een rijbron krijgen die afhankelijk is van de eerste keuzelijst. Dat kun je met VBA doen, waarbij je dan het Besturingselementbron van de tweede keuzelijst vrijhoudt om al dan niet naar eigen inzicht aan een tabelveld te koppelen. En zo door voor de overige keuzelijsten.
 
keuzelijst #2

OctaFish

Dank voor je antwoord, het is dus afhankelijk van HOE je het gebruikt.

Nu zit ik echter met een ander puntje
Een klant heeft meerdere adressen (factuuradres, verzendadres e.d.) hoe selecteer ik naast het klantnummer ook het goede adres?
ik heb o.a. een tabel met klanten en een tabel met klantadressen waardoor je in principe moet kunnen kiezen via 2 keuzelijsten met invoervak, het verhaal met 2 keuzelijsten is me duidelijk en lukt inmiddels aardig, echter dit wil je natuurlijk ook opslaan en dus in een query plaatsen.
als ik de query die ik gebruik voor mijn form aanpas en daar de tabel met klantadressen aan toe voeg krijg ik pardoes 24 records ipv de nu 8 ingevoerde records...

indien ik probeer om dit (ondanks de dubbele records) werkend te krijgen kan ik de klant niet meer wijzigen, tabel met klantadressen weer uit query halen, alles werkt weer ok (behalve klantadres uiteraard)
 
Laatst bewerkt:
dit wil je natuurlijk ook opslaan en dus in een query plaatsen
Klik om te vergroten...

Dat is nog maar te bezien... Een query laat records zien, en eventueel kun je m.b.v. een query ook wel records bewerken/toevoegen, maar daar moet je toch mee oppassen. Je moet bij het ontwerpen van je formulier uitgaan van één tabel waarin je gegevens opslaat. In die tabel kun je gegevens opslaan die je ophaalt met keuzelijsten, maar in beginsel wil je maar één record tegelijk opslaan/bewerken.

Die keuzelijsten zijn, als je de gekozen waarden wilt opslaan, gekoppeld aan een veld in je onderliggende tabel. Gebruik je keuzelijsten om selecties 'uit te dunnen', dan koppel je ze meestal niet aan een tabel, behalve dan (logischerwijze) de laatste in de lijn. Het vullen van keuzelijsten doe ik dus meestal via VBA, om daarmee alle acties binnen het formulier te houden, en geen overtollige queries te hebben.

En dat principe gebruik je doorgaans ook voor je klantgegevens: als je die wilt opslaan in je tabel, dan heb je daar velden voor nodig. Die kun je vullen vanuit één keuzelijst, door de gewenste velden op te nemen in de keuzelijst, en de velden te vullen via de gebeurtenis <Na bijwerken>. De opdracht die je dan maakt is iets als:

Code: 
Me.txtStraat=Me.cboAdres.Column(2)
Me.txtPostCode=Me.cboAdres.Column(3)
Me.txtPlaats=Me.cboAdres.Column(4)

Nogmaals: deze code is een willekeurig voorbeeld; het gaat even om de te gebruiken techniek. Zoals gezegd, doordat de tekstvakken gevuld worden vanuit een vba gebeurtenis op de keuzelijst, kun je de Besturingselementbron van de tekstvakken koppelen aan de velden in je tabel, zodat je de gegevens wel opslaat.
 
Dank voor de input, ik begrijp inmiddels meer de onderlinge afhankelijkheden, dat formulieren afhankelijk zijn van bepaalde relaties en de tabel waarop het form gebaseerd is, door zo maar wat velden aan een form toe te voegen en het gewenste veld aan te geven heb je niet automatisch alle info die via de referentie via verschillende tabellen aan elkaar gelinked zijn, zeker met forms gebaseerd op query's gaan dingen soms anders dan je verwacht.

Zo probeer ik nu na goedkeuring van een offerte (ja ik weet dat het vaker behandeld is) via een lijst met waarden een soort van trigger te maken welke zorgt dat het Referentienummer (is primary key van tabel) indien de offerte is goedgekeurd doorgegeven wordt naar andere tabel; tblOrders , waarbij orders wel autonummer is omdat niet elke offer een order wordt, alleen krijg ik dit nog niet voor elkaar, indien ik in de Qry waarop het form is gebaseerd de tabel orders toevoeg, werkt het geheel niet meer goed... (offertes worden niet meer getoond)
Heeft iemand een goede tip om zoiets voor elkaar te krijgen?

bvd
 
Ik snap niet helemaal wat je aan het doen bent, maar als je het Autonummerveld uit de tabel Orders probeert te koppelen aan een veld uit een andere tabel dat daar niet aan gekoppeld is, dan heb je inderdaad een probleem. Je kunt ook niet zelf een waarde toevoegen aan autonummerveld, dus als je dat probeert gaat het ook niet lukken.
 
ecxuus voor de onduidelijkheden

Wat ik graag wil is, de offerte die ik nu kan maken heeft een uniek Referentienummer
Op het moment dat de klant goedkeuring geeft aan de uitgebrachte offerte wil ik dat dit referentienummer wordt opgenomen in de tabel Orders, zodat een uniek ordernummer wordt aangemaakt, dat weer gelinked is aan het Referentienummer van de offerte.
Dit zou ik graag doen door bijvoorbeeld een druk op de knop (bv maak order confirmation) of een keuzelijst met waarden (status, is open goedgekeurd of afgekeurd)
Zodat van alle acties elke bewerking te achterhalen is.

Verder wil ik e.e.a. graag zo uitbreiden zodat ik bijvoorbeeld op basis van de voorraad na de order confirmation een paklijst gemaakt kan worden (die op zijn beurt weer gelinked is naar order no en offer no) gebaseerd op de actuele voorraadhoeveelheid, zodat er dus meerdere paklijsten gemaakt kunnen worden welke allemaal refereren naar het offerte/ordernummer

Voor nu gaat het er dus om om refNo van tbl Offers (= mainform) te koppelen aan tblOrders
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan