Normaliseren van mijn database

Status
Niet open voor verdere reacties.

LodewijkG

Gebruiker
Lid geworden
6 dec 2012
Berichten
98
Beste allen,

Zou jullie hulp kunnen waarderen voor het kijken of mijn indeling voor de data logisch genormaliseerd is. Ik zie namelijk door de bomen het bos niet, en weet ook niet goed of ik het gemakkelijker voor mijzelf maak.

Wat is mijn doel:
1. Het hoofddoel van mijn database is om Offerten en Orders te kunnen opmaken en bewaren waar meerdere gebruikers tegelijk in kunnen werken.
2. Een handige bijkomstigheid voor de toekomst zou zijn om bepaalde analysen te kunnen maken met de verzamelde cijfers.

Lijkt mij in deze nog vrij standaard voor Access. Nu heb ik het volgende beginnetje gemaakt aangezien OctaFish mij had geadviseerd om hier toch nog eens goed naar te kijken (waarvoor mijn dank).

Ik werk hier voornamelijk met één op veel relaties, wat in mijn ogen betekend (voor wat betrefd tblProducts) één ProductId dus meerdere prijzen kan hebben ofwel ProductPriceId.

Knipsel.jpg

Ik ben benieuwd of ik zo goed op weg ben.

Bij voorbaad dank!
 
Je zegt het zelf eigenlijk al: 'één ProductId kan dus meerdere prijzen hebben.' De ProductId zit dus aan de 1-kant van de relatie en de prijzen zitten aan de veel-kant van de relatie.
Wat je dus moet doen is de ProductId opnemen in de tblProductPrice en de ProductPriceId uit de tblProducts verwijderen. Het moet dus net andersom :)

Overigens heb je zo te zien de referentiële integriteit niet aangevinkt in de relaties.
 
Laatst bewerkt:
En er zitten meer foute verbindingen in, bijvoorbeeld Company met People. Eén bedrijf kan meer personen hebben, niet andersom. Tenzij je met contactpersonen werkt die voor meer bedrijven werken, freelancers bijvoorbeeld.
 
Laatst bewerkt:
Hetzelfde geldt trouwens voor de tblCompanies en de tblPeople. Je moet de CompanyId opnemen in de tblPeople i.p.v. de CustomerNameId. Zoals je het nu hebt gedaan, kun je namelijk maar één customer koppelen aan een company. Probeer het maar eens uit door een hoofd- en subformulier te maken op basis van deze twee tabellen.

Overigens zou ik het Contact Persons noemen i.p.v. Customers. Dat laatste is wat verwarrend omdat je ook al een tabel Companies hebt.
Maar misschien heb je er een goed reden voor.

PS: ik zie nu dat Octafish me net voor was :)
 
Nog een vraag: een Country kan meerdere Shipping Ports hebben dus wellicht kun je daar beter een aparte tabel voor maken. Ook als jullie op dit moment slechts gebruik maken van één Port per Country want je weet niet of dat altijd zo zal blijven. En eventuele nieuwe klanten kunnen aflevering in een andere Port verlangen.

Bovendien lijkt mij dat je de Shipping Port onder moet brengen in de tblCompanies want dat is het afleveradres van de klant. Al hangt het definitieve afleveradres uiteraard ook af van de leveringscondities, bijvoorbeeld: pikt de klant het zelf op in de aankomsthaven of lever je tot aan de deur.
Dientengevolge zal dan de Freight afhankelijk zijn van de Port en niet van de Country.
Hetzelfde geldt voor de ShippingLine, die kan ook verschillen per Port.
En de TransitTime hangt weer af van de combinatie ShippingLine en Port.

Verder zou ik voor de Shipping Lines en Currencies aparte tabellen maken.
 
Dag PFL & OctaFish,

Bedankt voor de feedback! Ik ben dit gelijk aan het aanpassen, heb de telefoonnummers & email ook losgetrokken en hier een ContactId aangegeven.

Knipsel2.jpg

Het klinkt allemaal zo logisch als je er eenmaal op gewezen wordt, wederom bedankt! Ik ga het van de shipping ports zo ook oppakken.

Ik zit inderdaad te denken aan bijvoorbeeld het verschil tussen afhalen (FCA), of in de haven van verscheping (FOB) etc. Mijn idee was om dit los als eindbestemmingen in de vrachtkosten te zetten, dan zit ik in Nederland bijv. al met verschillende locaties dus houdt mijn huidige indeling al op. Ik ga er zo inderdaad even goed voor zitten om het ook te begrijpen. In de toekomst wil ik misschien ook met voor(Container naar haven)- en tussentransport(voor bijladingen) gaan werken. dus misschien dat het dan nog anders moet of dat ik in de calculatie per product gewoon een input als overige gaan toewijzen. Hebben jullie hier misschien een zinvolle suggestie voor?

Bedankt!
 
Overigens zou ik het Contact Persons noemen i.p.v. Customers.
Dat doet geen enkele Engelsman noch Amerikaan; een Contact is namelijk een persoon. De tabel zou ik dus dan tblContacts noemen. Of (@ pfl) noem jij je contactpersonen MensPersonen? :)
 
Dat doet geen enkele Engelsman noch Amerikaan; een Contact is namelijk een persoon. De tabel zou ik dus dan tblContacts noemen. Of (@ pfl) noem jij je contactpersonen MensPersonen? :)
Jij wil niet weten hoe ik mijn contactpersonen (soms) noem! :D
 
Ik zie dat je van Offers en Orders een-op-veel relatie hebt gemaakt; tenzij je van één Offer meerdere Orders maakt, is dat fout. Sowieso zou ik, op basis van de inhoud van de tabellen, dat allemaal gewoon in één tabel houden met een keuzelijst waarmee je een Offer omzet naar een Order. Meer is het meestal namelijk niet. Ik snap nog even niet wat City doet in de tabel Country; lijkt mij niet logisch.
 
Ik ben weliswaar 6 jaar supply planner geweest en ik weet wat FCA, FOB, EXW etc etc in hoofdlijnen inhoudt maar daar houdt het dan ook wel mee op :confused:. Ik zou het vooralsnog zo eenvoudig mogelijk houden en eerst even afwachten waar je straks in de praktijk allemaal tegenaan loopt als je je database gaat gebruiken (of testen).

Om het je nog wat 'makkelijker' te maken :p: een klant kan meerdere afleveradressen hebben, of in de toekomst krijgen. Of een afleveradres kan wijzigen terwijl je het oude adres niet wilt overschrijven (vanwege je historie!). Dus ook daar zou ik een aparte tabel voor maken.
En dan denk ik dat je het AfleveradresId in de tblOrders moet opnemen. Eventueel ook in de tblOffers maar waarschijnlijk stuur je de offertes naar het kantooradres van de Company. En het kantooradres staat in de tblCompanies en niet bij de afleveradressen. Dus de CompanyId in de tblOffers lijkt mij goed.

Wat is trouwens het verschil tussen het veld Company en CompanyName in de tblCompanies?

Nog meer velden waar je aparte tabellen voor kunt maken:
IMOGoods en Unit in de tblProducts
City in de tblCountry
 
Ik zie dat je van Offers en Orders een-op-veel relatie hebt gemaakt; tenzij je van één Offer meerdere Orders maakt, is dat fout. Sowieso zou ik, op basis van de inhoud van de tabellen, dat allemaal gewoon in één tabel houden met een keuzelijst waarmee je een Offer omzet naar een Order. Meer is het meestal namelijk niet.

Op zich kan één offerte natuurlijk meerdere orders tot gevolg hebben, verspreid over een bepaalde periode. Alhoewel vaak een contract opgemaakt cq. vernieuwd zal worden zodra een offerte is geaccepteerd door de klant. En in de orders wordt dan verwezen naar het contract.
 
Je zou trouwens ook het hele Shipping verhaal (Company, Freight en Port) kunnen loskoppelen van de klant en het afleveradres en het kunnen koppelen aan de tblProductOfferId. Dan kun je daar elke keuze maken die je maar wilt (zolang die keuze in de realiteit mogelijk is natuurlijk) en heb je het hele kostenplaatje bij elkaar.
 
Heb ik aangepast, leek mij achteraf ook logischer, de kans dat mensen het zelfde mobiele nr oid hebben leek mij klein.

Nou... Thailand heeft bijvoorbeeld ook 06-nummers die uit 10 cijfers bestaan en hetzelfde kunnen zijn als Nederlandse 06-nummers....
Maar als je altijd de landcode ervoor zet, moet het goed gaan.
 
Ik zou het vooralsnog zo eenvoudig mogelijk houden en eerst even afwachten waar je straks in de praktijk allemaal tegenaan loopt als je je database gaat gebruiken (of testen).

Om het je nog wat 'makkelijker' te maken :p: een klant kan meerdere afleveradressen hebben, of in de toekomst krijgen. Of een afleveradres kan wijzigen terwijl je het oude adres niet wilt overschrijven (vanwege je historie!). Dus ook daar zou ik een aparte tabel voor maken.

En dan denk ik dat je het AfleveradresId in de tblOrders moet opnemen. Eventueel ook in de tblOffers maar waarschijnlijk stuur je de offertes naar het kantooradres van de Company. En het kantooradres staat in de tblCompanies en niet bij de afleveradressen. Dus de CompanyId in de tblOffers lijkt mij goed.

Wat is trouwens het verschil tussen het veld Company en CompanyName in de tblCompanies?

Nog meer velden waar je aparte tabellen voor kunt maken:
IMOGoods en Unit in de tblProducts
City in de tblCountry

Ga ik mee aan de slag, klinkt logisch :thumb:
 
Je zou trouwens ook het hele Shipping verhaal (Company, Freight en Port) kunnen loskoppelen van de klant en het afleveradres en het kunnen koppelen aan de tblProductOfferId. Dan kun je daar elke keuze maken die je maar wilt (zolang die keuze in de realiteit mogelijk is natuurlijk) en heb je het hele kostenplaatje bij elkaar.

Dit snap ik niet helemaal. De eerste instantie was mijn gedachten om dit los te koppelen van de productofferId omdat er bijvoorbeeld 20 verschillende producten in een container gaan en ik deze kosten doormiddel van een formule wilde verdelen per hoeveelheid in de productofferId. (de container hoeft niet per se vol te zitten dus daarom wilde ik het totaal verdelen) of maak ik het mij hier onnodig moeilijk mee?
 
Ga ik mee aan de slag, klinkt logisch :thumb:
Hier moet ik toch even ingrijpen, want pfl maakt een (typische) amateur denkfout, en ik wil toch proberen je daarvoor te behoeden.... Databases continue aanpassen omdat je er in het begin niet goed over nagedacht hebt waardoor er (achteraf belangrijke) zaken ontbreken betekent doorgaans enorme hoeveelheden werk waar je (zeker op dat moment) niet op zit te wachten. Een goede database bouwen betekent dat je van tevoren goed bedenkt wat er allemaal nu en in de toekomst mee zou moeten kunnen. Anders gezegd: als je een woning bouwt waarvan je van tevoren weet dat er nog wel eens een etage op moet komen dan zet je daar zelf geen puntdak op. (kijk naar landen als Griekenland waar ze dat regelmatig doen). Je houdt, kortom, rekening met te verwachten uitbreidingen.
 
De eerste instantie was mijn gedachten om dit los te koppelen van de productofferId omdat er bijvoorbeeld 20 verschillende producten in een container gaan en ik deze kosten doormiddel van een formule wilde verdelen per hoeveelheid in de productofferId. (de container hoeft niet per se vol te zitten dus daarom wilde ik het totaal verdelen)
Dat is dus zo'n aspect waar je echt rekening mee moet houden: als je zelf de container vult, en dat met orders doet van verschillende klanten (weet niet of dat zo is) dan heb je daar een aparte koppeltabel voor nodig: een tabel zelf voor de Freigt, en een tussentabel voor de producten die je gaat onderbrengen. Nogmaals: bedenk van tevoren welke werkprocessen je gaat onderbrengen in de database en ga pas bouwen aan je db (doe je nu volgens mij al niet) als je alles in kaart hebt gebracht!
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan