Normaliseren van mijn database

[PFL]

A. De relatie tussen de tabellen Product en ProductPrice is nog niet goed.
B. Bij de Companies kun je nu slechts 1 adres invoeren.
C. Voor de Shipping Lines kun je een aparte tabel maken.
D. Voor het veld ContainerSize in tblFreight kun je een keuzelijstje maken.
E. Het veld 'CountryId' in Companies moet numeriek zijn. Daarna kun je referentiële integriteit inschakelen.
F. Moet je de Companies niet linken met ProductOffer i.p.v. Offers? Je kunt nu niet zien in ProductOffer voor welke klant het is.
G. De eigenschap 'Geïndexeerd' van het veld ProductCode in tblProduct staat op 'Ja, duplicaten OK'. Hebben jullie dubbele artikelnummers?
Ik heb trouwens nog wel meer velden gezien waar dubbele waarden ingevoerd kunnen voeren terwijl je dat waarschijnlijk niet wilt, zoals bijv. Country in tblCountry.

 

[LodewijkG]

Ik heb wat fictieve data ingevult.

Bekijk bijlage LodewijkDB V01.2.zip

Waar ik mijn hoofd tegen stootte was:

1. Voor transport naar haven toe. Dit kan per leverancier verschillen dus ik dacht een subtabel te maken voor deze kosten. (tblProductOrder)
2. Echter kom ik dan ook weer in de klink met onderliggen voortransport dus als er gezamelijk word geladen wat ook nog wel eens gebeurd. In het tweede geval, aangezien de kosten vaak per pallet worden berekend en over het algemeen bij.v €50,- is zou ik deze ook kunnen toevoegen dmv het totaal aantal pallets dat nog eens onderling getransporteerd moet worden. Mij leek het handiger dit ook als subtabel (bij tblProductOrder) te doen.
3. Ik had de producten nog geen leverancier gegeven. Nu [CompanyId] toegevoegd aand tblProduct.
4. Ook was ik benieuwd of [FreightId] uberhaupt wel logisch aan de rest gelinked stond?

Bij voorbaad dank!
L

 

[LodewijkG]

A. De relatie tussen de tabellen Product en ProductPrice is nog niet goed.
B. Bij de Companies kun je nu slechts 1 adres invoeren.
C. Voor de Shipping Lines kun je een aparte tabel maken.
D. Voor het veld ContainerSize in tblFreight kun je een keuzelijstje maken.
E. Het veld 'CountryId' in Companies moet numeriek zijn. Daarna kun je referentiële integriteit inschakelen.
F. Moet je de Companies niet linken met ProductOffer i.p.v. Offers? Je kunt nu niet zien in ProductOffer voor welke klant het is.
G. De eigenschap 'Geïndexeerd' van het veld ProductCode in tblProduct staat op 'Ja, duplicaten OK'. Hebben jullie dubbele artikelnummers?
Ik heb trouwens nog wel meer velden gezien waar dubbele waarden ingevoerd kunnen voeren terwijl je dat waarschijnlijk niet wilt, zoals bijv. Country in tblCountry.

A. Heb ik nu aangepast.
B. Ik dacht dat wanneer een bedrijf meerdere adressen heeft, dit als bedrijfsnaam (land/stad tussen haakjes erachter) aan te houden
C. De FreightId heeft betrekking op maar 1 shipping line, andere shipping lines zullen andere tarieven hebben dus leek mij dit onhandig
D. Ga ik zeker doen
E. Aangepast
F. Aangepast
G. Aangepast naar Nee, de overige ga ik ook nog even langs.

Thanks!

 

[OctaFish]

A. De relatie tussen de tabellen Product en ProductPrice is nog niet goed.

Huh? Die is perfect!

Bij de Companies kun je nu slechts 1 adres invoeren.

Lijkt mij meer dan genoeg; we hebben het hier over het vestigingsadres. Eventueel kun je er nog velden bijzetten voor een postpus, maar meer adressen is niet nodig.

Moet je de Companies niet linken met ProductOffer i.p.v. Offers? Je kunt nu niet zien in ProductOffer voor welke klant het is.

Nee; een Offer/Order is gekoppeld aan één klant. Niet aan de losse producten.

 

[OctaFish]

@Lodewijk: PFL is, zoals je wellicht gemerkt hebt, zelf ook nog een (enigszins) gevorderde amateur. De stelligheid waarmee hij af en toe dingen beweert, vind ik nogal gevaarlijk (als dat hier van toepassing is) omdat het af en toe gewoon niet klopt wat hij beweert. Er blindelings op bouwen en vertrouwen zou ik dan ook zeker niet doen.

@PFL: De stelligheid waarmee je af en toe dingen beweert, vind ik nogal gevaarlijk (als dat hier van toepassing is). Het is prachtig dat je zo enthousiast bent, maar ga geen dingen beweren waarvan je niet 100% zeker bent dat ze kloppen. Lees in dat kader vooral je berichten #36 en #40 er nog eens op na....

We hebben het er (in een ander draadje) wel eens vaker over gehad, met als voorbeeld van jou dat je autorijden toch ook moet leren door het te doen? Dat is zo, maar je doet dat dan wel onder deskundige leiding; niemand geeft jou bij je eerste rijles de sleutels met de opmerking: 'ik zie straks wel hoe het gegaan is'. Idem dito met zaken als auto's bouwen: dat moet je ook leren. Jij koopt (tenzij je in een autofabriek werkt, dat weet ik uiteraard ook niet) ook niet de losse onderdelen die je denkt nodig te hebben en bouwt daar dan een auto mee. Wellicht dat je een vehikel gebouwd krijgt, maar of dat gelijk veilig genoeg is en goed rijdt? Dat moet je ook leren (en meestal van iemand anders). Voor databases geldt hetzelfde. Dat jij denkt dat je alleen maar door het te doen een database kunt leren bouwen, vind ik een schromelijke belediging van het vak 'databaseontwerper'. Alsof dat vak helemaal niets voorstelt: gewoon een paar databases bouwen, en je kunt het!
En nee, ik ben zelf ook geen database ontwikkelaar; ik buig ook mijn hoofd diep voor mensen die echt weten waar ze het over hebben. Maar in het land der blinden (en HelpMij is dat toch wel een beetje) kom ik een heel eind...

 

[LodewijkG]

Dag Octafish,

Ik begrijp je standpunt. Om bij jou referenties te blijven, zie ik mijzelf momenteel als zoekende naar wat een auto überhaupt is.

Ik zie en begrijp de complexiteit van de database maar beperkt. Ook merk ik dat na lang turen het overzicht en de logica verlies. Enfin, ben van mening dat de aanhouder wint zolang ik ook het idee heb dat ik ervan leer en begrijp waarom dingen moeten zoals ze moeten.

Ik zal zelf ook zeker scherp proberen te blijven op de feedback die ik krijg. Desalniettemin ben ik enorm dankbaar voor jullie beide input.

Mvgr, L

 

[PFL]

Huh? Die is perfect!

Dan ben je mij nu kwijt want het is nog steeds hetzelfde als in het plaatje in #1 en ik dacht dat we het er al over eens waren dat dat niet goed was.

Lijkt mij meer dan genoeg; we hebben het hier over het vestigingsadres. Eventueel kun je er nog velden bijzetten voor een postpus, maar meer adressen is niet nodig.

Nee? En de afleveradressen dan? Daar zie ik geen tabel voor.

Nee; een Offer/Order is gekoppeld aan één klant. Niet aan de losse producten.

Akkoord. Alhoewel ik in de laatste versie van Lodewijk de tblOrder en tblProductOrderId nogal verwarrend vind...

 

[PFL]

C. De FreightId heeft betrekking op maar 1 shipping line, andere shipping lines zullen andere tarieven hebben dus leek mij dit onhandig

Het is toch handig als je die ene Shipping Line dan kan selecteren uit een keuzelijst die je hebt gebaseerd op een tabel met Shipping Lines?

G. Aangepast naar Nee, de overige ga ik ook nog even langs.

Dus jullie hebben dubbele artikelnummers? D.w.z. hetzelfde nummer kan betrekking hebben op verschillende artikelen?

 

[OctaFish]

Het zal je niet verbazen dat de meeste opdrachtgevers geen benul hebben van databases. Dat hoeft gelukkig ook niet, daar is de ontwerper voor (beetje kort door de bocht trouwens).

Bij het opzetten van een systeem is het bouwen van de database niet alleen de laatste stap, het is ook de snelste. Veruit de meeste tijd gaat zitten in het inventariseren en beschrijven van de bedrijfsprocessen die je wilt automatiseren. Dat vertaal je allemaal naar een Functioneel Ontwerp, en dan pas ga je kijken hoe je die processen gaat automatiseren.
Je gaat dus pas zoeken naar een programma als je weet wat je wilt. Hoe kun je al een programma hebben gepakt als je niet volledig weet wat je allemaal wilt? Misschien moet je uiteindelijk wel aan SQL Server gaan denken. Kun je nog steeds in Access beginnen, maar je moet daar al wel rekening mee houden.

Vergeet niet dat je het over een (wellicht kritisch) bedrijfsproces hebt! En zeg eens eerlijk: hoeveel tijd heb je in het voortraject gestoeken, en hoe lang ben je al aan het bouwen?

 

[LodewijkG]

Ik had nog wat aanpassingen gemaakt en de huidige opzet is:

Bekijk bijlage LodewijkDB V01.3.zip

1. [ProductId] in tblProductPrice omdat de prijzen van de producten steeds verlopen.
2. [SupplierCode] toegevoegd aan aan tblProduct zodat deze ook goed gerefereerd worden.
3. [LabelColour] toegevoegd omdat sommige van onze klanten een specifieke label kleur willen hebben voor herkenbaarheid. (buiten de kleurafdruk die al in de omschrijving staat)
4. Ik ben nog opzoek naar de plekken voor de voortransporten, ik zit te denken om deze in tblOrder te plaatsen of om de voortransporten in een apparte tabel te doen en dan via een quary de voortransporten voor bijladingen, de container naar de haven & de kosten uit tblFreightId met elkaar op te tellen.:shocked:

 

[PFL]

@PFL: De stelligheid waarmee je af en toe dingen beweert, vind ik nogal gevaarlijk (als dat hier van toepassing is). Het is prachtig dat je zo enthousiast bent, maar ga geen dingen beweren waarvan je niet 100% zeker bent dat ze kloppen. Lees in dat kader vooral je berichten #36 en #40 er nog eens op na....

Stelligheid is een slechte eigenschap van mij ja, dat klopt. Eén van de vele... Ik zal me van nu af en aan inhouden als ik niet 100% zeker van m'n zaak ben.

(tenzij je in een autofabriek werkt, dat weet ik uiteraard ook niet)

Ik ben momenteel helaas werkloos...

Dat jij denkt dat je alleen maar door het te doen een database kunt leren bouwen, vind ik een schromelijke belediging van het vak 'databaseontwerper'. Alsof dat vak helemaal niets voorstelt: gewoon een paar databases bouwen, en je kunt het!

Dat heb ik volgens mij nooit beweerd. Ik vind alleen dat je het mede leert door het gewoon te doen en dingen uit te proberen.

 

[PFL]

Hi Lodewijk, nog een vraagje. In tblProduct hebben de producten een UnitId. Bij het eerste product is dat bijvoorbeeld 1. In de tabel ProductUnit zie ik dat dat 25 kilograms is. Wat betekent dat? Dat het verpakt is in zakken van 25 kg? Er staat echter geen 'bag' in de omschrijving en er staat ook geen prijs bij.

In tblProductPackagingSize, die gekoppeld is aan het veld PackagingId in tblProductOrderId (moet dat niet tblProductOffer zijn trouwens?), staat echter ook een zak van 25 kg met als omschrijving 'Bag (per Mt)' en een prijs van € 20,-. (per Mt = per Metric ton?)

Omdat je de packaging aan de offerte koppelt, dacht ik eigenlijk dat jullie de producten in bulk produceren en opslaan in silo's of wat dan ook en pas in zakken verpakken als je orders hebt. Maar als dat zo is waarom staat er dan een unit in de tblProduct, in dit voorbeeld 25 kg?

En waar is dan de prijs in tblProductPrice op gebaseerd? Op zakken van 25 kg?

 

[OctaFish]

In de tabel ProductUnit zie ik dat dat 25 kilograms is. Wat betekent dat? Dat het verpakt is in zakken van 25 kg? Er staat echter geen 'bag' in de omschrijving en er staat ook geen prijs bij.

Daar hoort natuurlijk ook geen prijs bij, daar is een aparte tabel voor.

In tblProductPackagingSize, die gekoppeld is aan het veld PackagingId in tblProductOrderId (moet dat niet tblProductOffer zijn trouwens?), staat echter ook een zak van 25 kg met als omschrijving 'Bag (per Mt)' en een prijs van € 20,-. (per Mt = per Metric ton?)

Ik ga er maar even van uit dat Lodewijk nog wel een paar meer records heeft; de verkoopeenheid heeft niet zoveel te maken met de vervoerseenheid. In een zak van 25 kg kunnen best 5 verkochte 5-kilozakken zitten. Gesteld dat hij straks 5 kilo verpakkingen verkoopt. Moet je dus niet door elkaar halen.

En waar is dan de prijs in tblProductPrice op gebaseerd? Op zakken van 25 kg?

Dat volgt nogal expliciet uit de tabelopzet: een artikel heeft een prijs en een eenheid. Onlosmakelijk verbonden.

 

[PFL]

Daar hoort natuurlijk ook geen prijs bij, daar is een aparte tabel voor.

Daar zeg je wat. De packaging kan in de huidige constructie maar 1 prijs hebben en als die wijzigt, wijzigt de historie ook.
Wellicht kan de packaging beter in de tblProduct ondergebracht worden, zodat ze een prijs met een geldigheidsperiode kunnen krijgen in de tblProductPrice.

Verder wacht ik even het antwoord van Lodewijk af op mijn vragen in #52.

 

[OctaFish]

Er zijn verschillende manieren om met prijzen om te gaan; welke weg je gaat hangt af van je FO. Weg 1: je vindt het belangrijk om de historie van de prijzen te hebben. Dat kan alleen als je een aparte tabel hebt waarin je elke prijsmutatie opslaat. Bij de transacties laat je dan de juiste prijs ophalen op basis van de datum waarop de prijs geldig is. Weg 2: de historie is niet interessant en hoeft dus niet bewaard te worden. Je hoeft dan geen prijsmutaties op te slaan, maar kunt gewoon de prijs aanpassen in de Producten tabel. Omdat die tabel wél gekoppeld is aan je transacties moet je de actuele prijs opslaan in de mutatietabellen. Je hebt dus in je verkooptabellen een extra prijsveld nodig. Beide opties zijn legitiem, en het hangt dus van de bedrijfsvoering af welke methode wordt gekozen. Staat er in het FO beschreven dat de manager aan het eind van het jaar een grafiek wil zien met de prijsontwikkelingen (denk aan brandstoffen), dan moet je wel met methode 1 werken.

Ik heb het vaker gezegd, en ik blijf het benadrukken: je moet van tevoren beschrijven wat er allemaal uit de database gehaald moet kunnen worden! Wat je er niet in stopt, kun je er ook niet uithalen! Na 2 jaar bedenken dat het toch wel nuttig is om de prijshistorie te kunnen bekijken, betekent: enorme aanpassingen aan je database, en inconsistente data (je mist een paar jaar). Een deugdelijk FO dus!

 

[LodewijkG]

Hi Lodewijk, nog een vraagje. In tblProduct hebben de producten een UnitId. Bij het eerste product is dat bijvoorbeeld 1. In de tabel ProductUnit zie ik dat dat 25 kilograms is. Wat betekent dat? Dat het verpakt is in zakken van 25 kg? Er staat echter geen 'bag' in de omschrijving en er staat ook geen prijs bij.

In tblProductPackagingSize, die gekoppeld is aan het veld PackagingId in tblProductOrderId (moet dat niet tblProductOffer zijn trouwens?), staat echter ook een zak van 25 kg met als omschrijving 'Bag (per Mt)' en een prijs van € 20,-. (per Mt = per Metric ton?)

Omdat je de packaging aan de offerte koppelt, dacht ik eigenlijk dat jullie de producten in bulk produceren en opslaan in silo's of wat dan ook en pas in zakken verpakken als je orders hebt. Maar als dat zo is waarom staat er dan een unit in de tblProduct, in dit voorbeeld 25 kg?

En waar is dan de prijs in tblProductPrice op gebaseerd? Op zakken van 25 kg?

Goedemorgen! Spijtig te horen van je werk.

1. De [UnitId] in tblProduct geeft inderdaad de grootte van het product weer. De [PackagingId] in tblProductOrderId geeft de verpakkingskosten per 1000kg/Metric ton weer (wij begroten onze prijzen standaard perMt). Dit lijkt mij in dit opzicht inderdaad dubbel op. Echter kan hetzelfde product in verschillend verpakking & labels verscheept worden naar klanten. In deze lijkt me het dan logischer om dit in de tblProductPackagingSize onder tblProductOrderId te houden. Please correct me if I'm wrong.

Ik ga er maar even van uit dat Lodewijk nog wel een paar meer records heeft; de verkoopeenheid heeft niet zoveel te maken met de vervoerseenheid. In een zak van 25 kg kunnen best 5 verkochte 5-kilozakken zitten. Gesteld dat hij straks 5 kilo verpakkingen verkoopt. Moet je dus niet door elkaar halen.

2. Ik denk dat ik je punt snap, dit is voor mij niet zozeer het geval denk ik. Wij verkopen in principe geen producten met een aantal units in een verpakking. Dus de Unit en PackagingSize zijn eigenlijk aan elkaar verbonden.

3. Aangaande de voortransport had ik het volgende bedacht, het zijn hoofdzakelijk drie verschillende typen tarieven voor vracht die ik binnen krijg, (1)voortransport voor combineren van containers, (2)transport van productielocatie naar haven & (3)de vracht van de haven naar de klant. Dus dacht ik het veld [FreightType] toe te voegen in tblFreight als een dropdown lijst. Zo houd ik toch alle info bij elkaar en voorkom ik onnodige tabbelen. Nu nog even kijken waar in het proces de kosten moeten worden toegevoegd.
3.1 Ik zat te denken voor transport voor bijladingen dit bij tblProductOrderId in te voegen omdat dit betrekking heeft op een specifiek product.
3.2 De voortransporten naar de haven en naar klant hebben betrekking op de gehele container.

Dat volgt nogal expliciet uit de tabelopzet: een artikel heeft een prijs en een eenheid. Onlosmakelijk verbonden.

Dit begreep ik niet helemaal, heb je wellicht een voorbeeld?

 

[LodewijkG]

Er zijn verschillende manieren om met prijzen om te gaan; welke weg je gaat hangt af van je FO. Weg 1: je vindt het belangrijk om de historie van de prijzen te hebben. Dat kan alleen als je een aparte tabel hebt waarin je elke prijsmutatie opslaat. Bij de transacties laat je dan de juiste prijs ophalen op basis van de datum waarop de prijs geldig is. Weg 2: de historie is niet interessant en hoeft dus niet bewaard te worden. Je hoeft dan geen prijsmutaties op te slaan, maar kunt gewoon de prijs aanpassen in de Producten tabel. Omdat die tabel wél gekoppeld is aan je transacties moet je de actuele prijs opslaan in de mutatietabellen. Je hebt dus in je verkooptabellen een extra prijsveld nodig. Beide opties zijn legitiem, en het hangt dus van de bedrijfsvoering af welke methode wordt gekozen. Staat er in het FO beschreven dat de manager aan het eind van het jaar een grafiek wil zien met de prijsontwikkelingen (denk aan brandstoffen), dan moet je wel met methode 1 werken.

Ik heb het vaker gezegd, en ik blijf het benadrukken: je moet van tevoren beschrijven wat er allemaal uit de database gehaald moet kunnen worden! Wat je er niet in stopt, kun je er ook niet uithalen! Na 2 jaar bedenken dat het toch wel nuttig is om de prijshistorie te kunnen bekijken, betekent: enorme aanpassingen aan je database, en inconsistente data (je mist een paar jaar). Een deugdelijk FO dus!

Ik heb de proces omschrijvingen redelijk in mijn hoofd zitten, maar zal de komende dagen aandacht besteden deze in kaart te brengen. Zal wellicht een stuk makkelijker praten merk ik aan je feedback.

Ik kom erop terug!

 

[PFL]

1. De [UnitId] in tblProduct geeft inderdaad de grootte van het product weer. De [PackagingId] in tblProductOrderId geeft de verpakkingskosten per 1000kg/Metric ton weer (wij begroten onze prijzen standaard perMt). Dit lijkt mij in dit opzicht inderdaad dubbel op. Echter kan hetzelfde product in verschillend verpakking & labels verscheept worden naar klanten. In deze lijkt me het dan logischer om dit in de tblProductPackagingSize onder tblProductOrderId te houden. Please correct me if I'm wrong.

2. Ik denk dat ik je punt snap, dit is voor mij niet zozeer het geval denk ik. Wij verkopen in principe geen producten met een aantal units in een verpakking. Dus de Unit en PackagingSize zijn eigenlijk aan elkaar verbonden.

OK, dus bijvoorbeeld het product 'Minmix 25 kg' wordt naar een klant in Ivoorkust in een zak met Franse opdruk en een 'Paper label (Black/White)' gestuurd en hetzelfde product wordt naar een klant in België in een zak met Nederlandse & Franse opdruk en een 'Paper label (Colour)' gestuurd.
Moet ik het zo zien?
En de prijzen van zowel de zakken als de labels kunnen verschillen, ook als ze hetzelfde formaat hebben?
En krijgen de producten nadat ze verpakt en gelabeld zijn nog een ander artikelnummer om ze van elkaar te kunnen onderscheiden?

PS: of zijn de zakken generiek en zijn alleen de labels verschillend?

 

[OctaFish]

Wij verkopen in principe geen producten met een aantal units in een verpakking. Dus de Unit en PackagingSize zijn eigenlijk aan elkaar verbonden.

Dit is voor een databaseontwerper een rilzin: hier kun je namelijk als ontwerper niet zoveel mee. Ofwel het komt nooit voor, ofwel het kan voorkomen maar nu nog niet. In het eerste geval kun je de db er probleemloos op bouwen; je gaat geen eventualiteiten inbouwen die toch nooit voorkomen. Zo zal De Graafschap geen noodplan hebben klaarliggen voor het vieren van het landskampioenschap (voetbal, voor het geval je dat niet snapte ). (Rotterdam wel trouwens, tegen beter weten in de laatste jaren ...) Maar je snapt hopelijk het punt: als iets nooit voorkomt of voor gaat komen, bouw je het niet in. Bestaat de kans dat het wél voorkomt, dan moet je daar rekening mee houden in het ontwerp (daar is-tie weer: het FO!).

 

[PFL]

Zo zal De Graafschap geen noodplan hebben klaarliggen voor het vieren van het landskampioenschap

Dat hoeft ook niet. Het 'noodplan' is altijd: op naar het café en høken! :d