Normaliseren van mijn database

[PFL]

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.

Prima dat je even ingrijpt, ik zat eigenlijk meer vakinhoudelijk te reageren dan 'Access-inhoudelijk'. Maar los daarvan ben ik van mening dat je pas écht een goed ontwerp voor een database kan maken als je al de nodige ervaring hebt met Access (zoals ik recent in een ander draadje reeds aangegeven heb). M.a.w. als je al met vallen en opstaan een aantal min of meer complexe databases hebt gemaakt. Kijk eens naar jezelf: heb jij van het begin af aan het inzicht gehad dat je nu hebt en heb je altijd 100% goede ontwerpen gemaakt?

Hoe meer ik nadenk over Lodewijks database, hoe meer ik m'n twijfels heb of hij wel meteen zo uitgebreid en complex moet beginnen. Vooral omdat hij weinig ervaring heeft met Access én omdat hij voor mijn gevoel een half ERP-systeem wil bouwen . Met name bij het hele kostenverhaal komt nogal wat kijken.

Een paar vragen (@Lodewijk) die bijvoorbeeld zo spontaan bij mij opkomen zijn:
- Ik zie wel packaging staan in je ontwerp maar geen pallets. Betekent dit dat alles los gestapeld wordt in de containers?
- Zo ja, hebben jullie dan ook stuwadoorkosten?
- Zo ja, dan werken jullie waarschijnlijk alleen met FCL's en niet met LCL's (Full Container Load en Less than Container Load voor de niet-ingewijden). Klopt dat?
- In wat voor handel zit je eigenlijk? Je hoeft de naam van het bedrijf niet te noemen natuurlijk, 't is alleen even voor mijn beeldvorming.
- Over hoeveel containers per jaar praten we zo gemiddeld genomen?
- Hebben jullie contracten met bepaalde shipping lines voor bepaalde routes met vaste prijzen? Of zoeken jullie (ook) geregeld naar een goede prijs bij andere shipping lines?
- Werken jullie met veel verschillende containers: 20-voet, 40-voet, reefers, etc.?
- Werken jullie met veel verschillende leveringscondities (FCA, FOB, etc.) of slechts een paar?
- Douane kosten?

Wat ik maar wil aangeven is, dat het best complex is / kan zijn. Te complex wellicht om van tevoren een goed ontwerp te kunnen maken. Je zou er dan voor kunnen kiezen om de hele kostenberekening voorlopig in Excel te blijven doen (wat je nu doet naar ik aanneem) en alleen het eindresultaat daarvan in je database te zetten. Dan kun je de database vooralsnog relatief eenvoudig houden met alleen een overzicht van je offerten en orders. En pas als je meer ervaring hebt met Access bouw je hem verder uit (of je maakt een nieuwe).

Tenzij Octafish nou zegt: "Oh makkie.... bouw maar gelijk een uitgebreide en complexe database! Ik help je wel!"
Maar dan ben je wel erg afhankelijk van hem (en vooral zijn tijd).

 

[OctaFish]

Maar los daarvan ben ik van mening dat je pas écht een goed ontwerp voor een database kan maken als je al de nodige ervaring hebt met Access

Het maken van een goede database heeft niks met Access te maken, nog zo'n (beginners) misverstand. Net zo min als het maken van een schone dieselmotor is voorbehouden aan VW ontwerpers .

Hoe meer ik nadenk over Lodewijks database, hoe meer ik m'n twijfels heb of hij wel meteen zo uitgebreid en complex moet beginnen. Vooral omdat hij weinig ervaring heeft met Access én omdat hij voor mijn gevoel een half ERP-systeem wil bouwen

Het is op zich niet zo'n probleem om niet gelijk alles in te bouwen; het calculatiedeel (dat overigens waarschijnlijk exact dezelfde functies gaat gebruiken als Excel) kun je best later toevoegen. Dat is juist het mooie van een goed concept: als je het van te voren goed uitdenkt is dat allemaal geen probleem. Die problemen komen juist doordat er niet van tevoren is nagedacht over de bedrijfsvoering.

Kijk eens naar jezelf: heb jij van het begin af aan het inzicht gehad dat je nu hebt en heb je altijd 100% goede ontwerpen gemaakt?

Nee, natuurlijk niet! Komt ook doordat ik letterlijk alles zelf heb moeten uitvogelen . Maar net zoals het ontwerpen van software waarmee je de inspectiediensten om de tuin leidt geen klus voor beginnende programmeurs is, is het bedenken van een goede database dat ook niet. En als iemand daar geen sjoege van heeft, moet hij/zij dat dus niet eens zelf willen doen. Heb je de wil/intentie/kunde om het zelf te leren/doen wél, dan is er uiteraard niks op tegen om dat zelf te doen, maar dat neemt niet weg dat je de complete leercurve gewoon moet doorlopen. En dat is het mooie van HelpMij: daar zitten mensen die je daar bij willen helpen! Kost je wel veel meer tijd dan dat je zo'n klus uitbesteed. Maar dat hoort er dan bij...

 

[PFL]

Het is op zich niet zo'n probleem om niet gelijk alles in te bouwen; het calculatiedeel (dat overigens waarschijnlijk exact dezelfde functies gaat gebruiken als Excel) kun je best later toevoegen. Dat is juist het mooie van een goed concept: als je het van te voren goed uitdenkt is dat allemaal geen probleem. Die problemen komen juist doordat er niet van tevoren is nagedacht over de bedrijfsvoering.

Hoe kun je nou van tevoren goed nadenken over de bedrijfsvoering zoals deze in Access plaats moet vinden (let wel!) als je nog weinig of geen ervaring hebt met Access...
Aan de fouten die Lodewijk en ik bijvoorbeeld daarbij maken, kun je al zien dat dat niet helemaal werkt.

 

[PFL]

Nee, natuurlijk niet! Komt ook doordat ik letterlijk alles zelf heb moeten uitvogelen . Maar net zoals het ontwerpen van software waarmee je de inspectiediensten om de tuin leidt geen klus voor beginnende programmeurs is, is het bedenken van een goede database dat ook niet. En als iemand daar geen sjoege van heeft, moet hij/zij dat dus niet eens zelf willen doen. Heb je de wil/intentie/kunde om het zelf te leren/doen wél, dan is er uiteraard niks op tegen om dat zelf te doen, maar dat neemt niet weg dat je de complete leercurve gewoon moet doorlopen. En dat is het mooie van HelpMij: daar zitten mensen die je daar bij willen helpen! Kost je wel veel meer tijd dan dat je zo'n klus uitbesteed. Maar dat hoort er dan bij...

Hier spreek je jezelf dus tegen vind ik. Je zegt dat je het zelf allemaal hebt moeten uitvogelen maar andere mensen moeten dat toch vooral niet doen?
En je komt er pas achter of je ergens sjoege van hebt en gevoel voor hebt als je er daadwerkelijk mee aan de slag gaat.
Om maar even bij de auto's te blijven: je kan niet leren autorijden als je alleen de theorielessen doorloopt.

 

[OctaFish]

Hoe kun je nou van tevoren goed nadenken over de bedrijfsvoering zoals deze in Access plaats moet vinden (let wel!) als je nog weinig of geen ervaring hebt met Access...

Weer een denkfout: je denkt eerst na over de processen, en pas daarna ga je kijken hoe je die gaat vertalen naar de software. Niet andersom... Je gaat dus niet denken: ik heb Access, wat zou ik daar me kunnen?
Dus het zou heel goed kunnen dat op basis van de werkprocessen de uitkomst is dat je dat in Excel kan doen. Niet waarschijnlijk in dit geval, maar het zou dus kunnen.

 

[OctaFish]

Om maar even bij de auto's te blijven: je kan niet leren autorijden als je alleen de theorielessen doorloopt.

Maar je mag pas zelfstandig de weg op als je een rijbewijs hebt! Kortom: je onderschrijft alleen maar mijn stellingen .
En ja, ik had heel wat tijd kunnen besparen als ik had kunnen terugvallen op een forum als HelpMij toen ik begon. En dat had ik ook helemaal niet erg gevonden! Waarom zou iedereen het wiel zelf uit moeten vinden?
Tuurlijk leer je door dingen uit te proberen, maar doe dat vooral niet in een bedrijfskritisch werkproces. En zullen we het draadje nu weer teruggeven aan de TS? Dit heeft allemaal niks meer met de vraag te maken

 

[PFL]

Klopt, je mag pas zelfstandig de weg op als je een rijbewijs hebt, nadat je zowél theorie- áls praktijklessen hebt gevolgd en ook nog eens tegelijkertijd.
Maar laten we er inderdaad maar over ophouden want we overtuigen elkaar toch niet .

Ben het overigens met je eens dat je niet moet oefenen met een bedrijfskritisch werkproces. Nog een reden dat de TS vooral voorzichtig moet beginnen.

 

[LodewijkG]

Beste OctaFish & PFL,

Excuus voor mijn afwezigheid en bedankt voor jullie efforts en discussie, ik ga me er maar niet tussen mengen.

Een paar vragen (@Lodewijk) die bijvoorbeeld zo spontaan bij mij opkomen zijn:
- Ik zie wel packaging staan in je ontwerp maar geen pallets. Betekent dit dat alles los gestapeld wordt in de containers?

Klopt, er zijn geen extra kosten voor pallets.

- Zo ja, hebben jullie dan ook stuwadoorkosten?

Klopt dit zijn dan de THC kosten. Terminal handling charges.

- Zo ja, dan werken jullie waarschijnlijk alleen met FCL's en niet met LCL's (Full Container Load en Less than Container Load voor de niet-ingewijden). Klopt dat?

Klopt ook, maar zeer sporadisch ook met LCL's dus ik zit ook even na te denken hoe ik dit er dan weer in moet werken.

- In wat voor handel zit je eigenlijk? Je hoeft de naam van het bedrijf niet te noemen natuurlijk, 't is alleen even voor mijn beeldvorming.

Zitten in de diervoederindustrie, verhandelen van additieven zoals vitamine/mineraal mengsels.

- Over hoeveel containers per jaar praten we zo gemiddeld genomen?

Tussen de 200-300.

- Hebben jullie contracten met bepaalde shipping lines voor bepaalde routes met vaste prijzen? Of zoeken jullie (ook) geregeld naar een goede prijs bij andere shipping lines?

Dit doen wij via een expeditiebedrijf, daar spreken we dan prijzen me af voor bepaalde termijnen, ligt aan de shipping line & eindbestemming.

- Werken jullie met veel verschillende containers: 20-voet, 40-voet, reefers, etc.?

Ligt aan de volume van het product, eigenlijk alleen 20ft & 40ft containers.

- Werken jullie met veel verschillende leveringscondities (FCA, FOB, etc.) of slechts een paar?

Yes, dat doen we inderdaad. Maar dat dacht ik op te vangen middel de locatie aflever adres fabriek of bijvoorbeeld rotterdam erin te zetten.

- Douane kosten?

Ook, Ik heb hiervoor had ik FreightOther aangemaakt, maar eigenlijk werkt dit niet. Het lijkt mij beter FreightOther weg te laten.

Heb je de wil/intentie/kunde om het zelf te leren/doen wél, dan is er uiteraard niks op tegen om dat zelf te doen, maar dat neemt niet weg dat je de complete leercurve gewoon moet doorlopen. En dat is het mooie van HelpMij: daar zitten mensen die je daar bij willen helpen! Kost je wel veel meer tijd dan dat je zo'n klus uitbesteed. Maar dat hoort er dan bij...

Ik maak hier ook dankbaar gebruik van :thumb: Ik ben van mening dat ik even moet doorbijten maar gelukkig ook dat ik hier meer van leer dan alleen hoe een access database opgebouwd dient te worden.

En je komt er pas achter of je ergens sjoege van hebt en gevoel voor hebt als je er daadwerkelijk mee aan de slag gaat.
Om maar even bij de auto's te blijven: je kan niet leren autorijden als je alleen de theorielessen doorloopt.

Zo sta ik er ook tegenover.

Weer een denkfout: je denkt eerst na over de processen, en pas daarna ga je kijken hoe je die gaat vertalen naar de software. Niet andersom... Je gaat dus niet denken: ik heb Access, wat zou ik daar me kunnen?
Dus het zou heel goed kunnen dat op basis van de werkprocessen de uitkomst is dat je dat in Excel kan doen. Niet waarschijnlijk in dit geval, maar het zou dus kunnen.

Ik heb nu in eerste instantie gekeken of ik de huidige werkprocessen in access kan krijgen, ik ben er gaande weg achter gekomen dat ik beter het proces nog eens goed kan herzien en proberen vooraf verbeteringen aan te brengen. Enfin vandaar mijn vraag om hulp aangezien ik dit blijkbaar dus nog niet goed genoeg doordacht had.

Ik ga er straks nog eens goed voor zitten om het nog eens door te lezen en te kijken of ik met de juiste aanpassingen op de proppen kan komen.

Bedankt!

 

[PFL]

Hoi,
Kun je misschien je database even uploaden hier, dat praat wat makkelijker. Wel even eventuele gevoelige informatie eruit halen of vervangen door iets onschuldigs. Daarna uploaden als ZIP-bestand.

 

[LodewijkG]

Dag PFL,

Excuus voor de vertraging, moest eerst even trainen .

Hierbij het bestand http://www.filedropper.com/pfl heb deze nog niet gevuld, ik wilde eerst de juiste basis hebben

 

[OctaFish]

Ook al is de db duidelijk niet voor derden bestemd, en wacht je dus op de expertise van pfl, toch wat opmerkingen van mijn kant .

1. De tabel Adress zou ik samenvoegen met tblCompanies. Adressen zijn een eigenschap van een bedrijf, niet andersom.
2. De tabel tblCompanyType zou ik verwijderen; gebruik een keuzelijst in tblCompanies. Ik vermoed dat je maar een paar (niet-veranderende) types hebt, dus een tabel is kanon+mus
3. In de tabel tblCountry hoort het veld [ShippingPort] niet thuis.
4. In de tabel tblFreight heb je velden die wellicht in een keuzelijst (met meervoudige selectie?) thuishoren. Het gaat dan om de velden [FreightLand], [FreightSea] etc.
5. Wat doet het veld [FreightTotal] in die tabel? Totalen bereken je in queries, niet in tabellen.
6. De velden [FreightValidFrom] en [FreightValidUntill] suggereren een datum; bij jou zijn ze numeriek. Klopt dat?
7. De tabellen tblOffers en tblOrders moet je in één tabel houden. Dan heb je die onhandige constructie met het veld [OfferAccepted] ook niet nodig. Werkt fouten in de hand!
8. In de tabel tblPeople (waarom niet Contacts? Als je Engels gebruikt, doe het dan goed) heb je naast 3 velden voor een telefoonnummer het veld [TelephoneId]. Vreemd veld dus.
9. De tabel tblProductIMO bevat alleen een sleutelveld...
10. De tabel tblProductOfferId bevat een aantal berekende velden zoals [CreditInterest]. Niet doen; in tabellen sla je alleen gegevens op, berekeningen maak je in queries.
11. Het veld [SubtotalCost] moet natuurlijk sowieso weg; dat is op zeker een berekening in een query.
12. Gebruik (in het algemeen) valutavelden voor velden met valuta, geen numeriek veld. Voorbeeldje: [PackagingPrice] in tblProductPackagingSize.
13. En al helemaal geen tekstveld, zoals [UnitPrice] in de tabel tblProductPrice!
14. In het algemeen: als je een voorbeeldje post, zet er dan ook wat (relevante) data in; nu kunnen we alleen naar de velden kijken en relaties. Ik zie graag ook hoe de data er uit ziet, dat geeft een veel beter idee van wat je aan datastromen wilt gebruiken.

En nu maar afwachten wat de maestro er van vindt .

 

[LodewijkG]

Goedemorgen!

Bedankt voor je feedback OctaFish, fijn dat je de tijd neemt om me vooruit te helpen. Ik hoop nog veel vaker gebruik te mogen maken van de hulp op dit forum. Ik had de file PFL genoemd vanwege zijn vraag voor het uploaden voor de file, heb de naam ook gelijk aangepast.

Ik heb de database weer bijgevoegd.Bekijk bijlage DatabaseV1.zip

Graag loop ik ook de aanbevelingen door:

Octafish 29-9 (23:26)
1. Aangepast, heb ook een PortofDeparture & PortofDestination bij tblFreight toegevoegd. Ik bedacht me dat Currency veld wellicht verwijderd kan worden omdat de Freight- velden op valuta kunnen. Het komt vaak voor dat bijvoorbeeld het FreightLand (inland transport) in bijv. dollars is en FreightSea in euros is.
Is het mogelijk om dan verschil in euros & dollars te maken? Ik heb nu tblCurrency toegevoegd waar ik mee kan rekenen. De berekeningen zelf laat ik nog even voor wat het is maar belangrijk vind ik dat de structuur goed ligt.

Had even wat oude posts opgezocht.
http://www.helpmij.nl/forum/showthr...illende-valuta?highlight=verschillende+valuta
http://www.helpmij.nl/forum/showthread.php/736173-qurey-verloop-wisselkoersen?highlight=wisselkoers

2. Als ik de tblCompanyType verwijderen, zou ik later bij rapportages op companytype kunnen filteren als deze geen Id hebben maar slechts een omschrijving?
3. Verwijderd
4. De Freight- velden zijn velden waar ik kosten graag apart zou vermelden, dan kunnen we ook terugzien hoe deze zijn opgebouwd.
5. Verwijderd.
6. Aangepast
7. Aangepast, maar ik denk nog niet helemaal goed. Ik vraag me namelijk ook af hoe ik een duidelijk onderscheid kan maken tussen wanneer een offer een order is geworden. Dit heb ik nu, in mijn ogen, opgelost door een OrderDate en OrderNumber toe te voegen...
8. TelephoneId verwijderd & tabelnaam aangepast
9. De tblIMO verwijderd omdat ik eigenlijk alleen wil weten of het IMO goederen zijn of niet.
10. Heb deze velden verwijderd, ook nog andere tabellen doorgekeken en aangepast. Ik dacht dat het belangrijk was om totalen ook op te slaan maar als ik de eenheden heb, begrijp ik nu ook dat de totalen ook hebt dmv queries.
11. Verwijderd
12. Aangepast
13. Aangepast
14. Oke, ga ik doen. To be continued.

Dan ook nog even terug te komen op voorgaande posts:
1. Full container load & less container load.
Ik had hier over nagedacht maar zou dit opgelost kunnen worden door dit te scheiden van de volledige container vrachten? Omdat de opbouw van de kosten dan verschilt omdat er dan ipv kosten gedeeld worden over de hoeveelheid vermenigvuldigd moeten worden.
2. Werken met verschillende leveringscondities (FCA/FOB/CIF).
Dit gebeurd inderdaad, dit wordt opgebouwd dmv transportkosten + Vracht verzekering

Vragen die ik zelf graag wil toevoegen:
Wij werken ook op basis van commissie en krediet. Krediet zou ik kunnen plaatsbij bij tblPaymentModality lijkt mij? Maar commisie, dit kan zowel in percentage als vooraf gestelde hoeveelheid zijn, zou ik deze dan bij de tblOffers kunnen opnemen? Omdat het op de hele order van toepassing zou zijn.

Met vriendelijke groet,

L

 

[PFL]

Goh, er is een database naar mij vernoemd. Heb ik toch nog iets bereikt in het leven...

Dit vind de 'maestro' (niet mijn woord, ik zou niet durven ) ervan:

ad 1. De adressen en companies zijn inderdaad verkeerd gelinkt. Bovendien zou ik er een extra veld AddressType aan toevoegen zodat je onderscheid kan maken tussen kantooradres, postadres en afleveradres. Kun je eveneens een keuzelijst voor gebruiken, een tabel is niet nodig.

ad 3. De ShippingPorts zou ik onderbrengen in een aparte tabel met daarin een veld PortID, een veld Port en een veld CountryID. De PortID koppel je vervolgens met de tabel Freight zodat je daar in één keer de Port en de Country kan selecteren.

ad 8. Ook EmailID hoort daar niet bij denk ik.

ad 14. Ja, helemaal mee eens! Zo is het een beetje droogzwemmen.

Zal zo nog even kijken of ik meer dingen kan vinden. Maar je bent wel goed bezig in ieder geval

@Octafish: je hebt nog niet gezegd dat je gekoppelde ID-velden beter niet precies dezelfde namen kan geven. Vond dat wel een goede tip want naast de door jouw genoemde bezwaren levert het ook nogal eens problemen op in hoofd- en subformulieren als Access opeens het verschil niet meer 'ziet' tussen het parent en child veld.

 

[PFL]

Ik had de file PFL genoemd vanwege zijn vraag voor het uploaden voor de file, heb de naam ook gelijk aangepast.

Ach, wat jammer nou... de roem was van korte duur...

 

[OctaFish]

Ik had de file PFL genoemd vanwege zijn vraag voor het uploaden voor de file, heb de naam ook gelijk aangepast.L

Was natuurlijk maar een geintje mijnerzijds; de naam van de db maakt mij echt niet uit . Al is het handiger als die je eigen naam heeft, want ik bewaar bijlagen best lang. En als ik dan een oude van jou zou zoeken, gaat 'm dat niet worden . Overigens heten de meeste bijlagen 'database1' o.i.d. dus het systeem werkt sowieso al heel slecht .

Nu je nieuwe opmerkingen:

Als ik de tblCompanyType verwijderen, zou ik later bij rapportages op companytype kunnen filteren als deze geen Id hebben maar slechts een omschrijving?

Als je er een keuzelijst met waarden van maakt, dan is het gewoon tekst wat je ziet, en daar kun je prima op filteren. Beter zelfs als op een tabel (zie ander draadje dat nu loopt waar juist dat fout gaat)

Uit de tabel tblOffers/Orders moet het veld [ProductOfferId] weg; je hebt de relatie ook precies andersom liggen. Eén Order kan meerdere producten bevatten, niet andersom. De tabel tblProductOrder ligt dus tussen Product en Order in.
Ik zou ook, in tblProductOrder (ik zou de tabel zo noemen, en niet ProductOffer) een unieke index maken op de velden [OrderID] en [ProductId] want je wilt niet dat een product dubbel in één order/offer wordt opgenomen. Althans: lijkt mij niet goed.

Ik vraag me namelijk ook af hoe ik een duidelijk onderscheid kan maken tussen wanneer een offer een order is geworden. Dit heb ik nu, in mijn ogen, opgelost door een OrderDate en OrderNumber toe te voegen...

Ik zou het veld [Status] toevoegen; een keuzelijst met waarden met de volgende opties: "Offer";"Order";"Canceled". Wellicht dat je nog meer kan bedenken.

 

[PFL]

1. Aangepast, heb ook een PortofDeparture & PortofDestination bij tblFreight toegevoegd.

Dat gaat alleen werken als je twee aparte tabellen maakt voor de ports, dus 1 tabel met de vertrekhavens en 1 met de aankomsthavens. Maar hoeveel vertrekhavens heb je nou helemaal? Rotterdam en Antwerpen?

 

[OctaFish]

Dat gaat alleen werken als je twee aparte tabellen maakt voor de ports, dus 1 tabel met de vertrekhavens en 1 met de aankomsthavens.

Waarom? Een haven is één entiteit; één tabel dus.

 

[PFL]

Ja, maar hij kan dan toch niet 2 verschillende records uit de tabel Ports selecteren in de tabel Freight?

 

[OctaFish]

Waarom niet?

 

[PFL]

Excuus, het werkt wel! Ik had dat lang geleden een keer bij de hand en toen werkte het niet. Maar heb toen kennelijk iets fout gedaan. Wist toen nog minder van Access dan nu