Normaliseren van mijn database

OctaFish zei:

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!).

Klik om te vergroten...

Heb je misschien ook tips voor het in kaart brengen van een FO?

Gewoon beschrijven wat je wilt; daar kom je al een heel eind mee. Wij zijn momenteel een telefoon app aan het ontwikkelen op basis van storyboards. Die bevatten een vast patroon:
1. een vraag
2. een actie
3. een resultaat
Voorbeeldje van zo'n storyboard: "Wanneer een marktkoopman de toezichthouder op op de markt vraagt hoe vaak hij het afgelopen kwartaal aanwezig is geweest, dan moet ik dat op kunnen zoeken en hem het antwoord kunnen geven".
Dat klinkt logisch en simpel, maar is het toch niet: dat betekent namelijk dat je vanuit je app op de telefoon een connectie moet kunnen maken met de tabel waarin de registraties worden opgeslagen en de backend database moet die informatie vervolgens terug sturen. Deze activiteit heb je natuurlijk nooit standaard in een database zitten, en die moet dus gebouwd worden.

Een vergelijkbare vraag heb ik hierboven al geschetst: "Mijn manager wil aan het eind van het jaar een overzicht hebben van de prijsmutaties van alle artikelen over het aflopende jaar".
Zo'n storyboard vertelt mij dan dat ik a) de prijsmutaties moet vastleggen en b) een rapport moet hebben dat de gegevens op jaarbasis groepeert.
Was de vraag: "Mijn manager wil aan gedurende het jaar een overzicht hebben van de prijsmutaties van alle artikelen over een selecteerbare periode (jaar/kwartal/maand)", dan zou ik de tabel nog steeds hetzelfde inrichten, maar dan ofwel losse rapporten maken, ofwel een variabel rapport maken. Waarschijnlijk het laatste trouwens .

Maar waar het om gaat: de verschillende vragen leiden tot verschillende acties en die leiden tot verschillende oplossingen. Hoe meer vragen je verzamelt, hoe meer inzicht je hebt in de werkstromen die je nodig hebt. En op basis daarvan maak je dan het ER diagram. Dat ER diagram bevat de noodzakelijke Entiteiten (=Records) en op basis daarvan maak je de tabellen.
Aan de hand van dat FO weet je ook precies welke formulieren, queries en rapporten je nodig hebt.

Alright,

Ik probeer een formulier te bouwen die mij gaat helpen met het calculeren van een offerte.

Deze offerte/order dient rekening te houden met:
1.Voor welk bedrijf & contactpersoon deze offerte/order bestemd is

2.De valuta waarin er geoffreerd word (euro of dollar)

3.De datum van de offerte/order
3.1 De vervaldatum van de offerte/order

4.De betalingscondities
4.1 Rente die in rekening moet worden gebracht voor het aantal dagen krediet
4.2 Ook de kosten voor bijvoorbeeld een letter of credit
4.3 Er kan ook sprake zijn van beide dus het openen van een L/C met betaling op 90 dagen
4.4 Ook verzekering wij ons transport, dus ook deze kosten moeten in rekening gebracht worden.
4.5 We hebben ook tussenhandelaars die op commissiebasis werken (percentage of vast bedrag)

5.De transportkosten.
5.1 Transport op verschillende stadia in het afhandelingsproces
5.1.1 Transport om goederen van verschillende leveranciers naar één plek te brengen om deze te kunnen combineren in 1 container
5.1.2 Transport om de container van de leverancier waar deze in geheel geladen wordt naar de haven te transporteren
5.1.3 Transport om de container van de haven waar deze geladen wordt naar de afgesproken eindbestemming te brengen
5.2 Deze prijzen zijn tijdelijk geldig maar willen we wel bewaren zodat we, mogen we dat nodig vinden, een historie rapport kunnen uitdraaien

6.De producten die worden aangeboden
6.1 De producten hebben een eigen code, omschrijving, commentaar(klant specifiek), IMO classificatie(wel/niet), leverancier & leverancierscode
6.1.1 De producten kunnen in verschillende landen worden verkocht
6.1.2 De prijzen liggen tijdelijk vast, zijn namelijk grondstofprijzen
6.2 Hebben een minimum productiehoeveelheid
6.3 Hebben hun eigen specifieke label, kleur, kwaliteit(omschrijving), kosten
6.4 Hoeveelheid
6.5 Verpakking, deze heeft gelijk betrekking op de grootte van het product, omschrijving en prijs.

7.De persoon die de offerte heeft berekend
7.1 Welke medewerker de offerte heeft berekend
7.2 Welke datum dit is berekend

De kostprijs berekenen we nu als volgt:
Inkoopprijs per Mt (1000kg)+ vrachtkosten (gebaseerd opLCL of de FCL kosten gedeeld per hoeveelheid dat in de container gaat) + voortransportkosten + verpakkingskosten + label kosten + verzekeringspremie + kredietkosten + commissiekosten. Maar een order kan ook meerdere containers bevatten.

De verkoopprijs kostprijs + een bedrag of %

Voor de rapportage, dit kunnen er velen zijn maar bijvoorbeeld.
Verkochte producten per klant per tijdseenheid (maand/jaar)
Verkochte producten per land per tijdseenheid (maand/jaar)
Klantenlijst per land
Gemiddelde marge per klant/land
etc.

Mvgr,

L

Je eeste zin geeft eigenlijk je probleem al aan:

LodewijkG zei:

Ik probeer een formulier te bouwen die mij gaat helpen met het calculeren van een offerte.

Klik om te vergroten...

Ik probeer al een tijdje duidelijk te maken dat het bouwen van formulieren de laatste stap is, niet de eerste .
Maar volgens mij heb je al meer dan genoeg tips gekregen die je oorspronkelijke vraag hebben beantwoord, dus wat mij betreft sluit je deze vraag af. Persoonlijk vind ik elke vraag die meer dan 30 berichten bevat al veel te lang, en deze zit al ruim boven de 60. Dat reduceert de leesbaarheid tot diep onder het vriespunt, en het draadje alleen nog maar interessant voor, ja, voor wie eigenlijk?
Dus ik zou zo zeggen: kijk op je gemakje naar het ontwerp van je db (gaat echt de goede kant op), en als je nieuwe vragen hebt (gaat geheid komen) maak dan een nieuwe topic aan. En gooi deze dus op slot .

OctaFish zei:

Je eeste zin geeft eigenlijk je probleem al aan:

Ik probeer al een tijdje duidelijk te maken dat het bouwen van formulieren de laatste stap is, niet de eerste .

Klik om te vergroten...

Nee, het probleem is niet dat hij formulieren bouwt, het probleem is dat hij nog niet de ervaring en het inzicht heeft dat jij na jarenlang werken met Access en het bouwen van vele databases hebt verworven. Jij kan aan een verzameling tabellen en de gelegde koppelingen heel snel zien of een database gaat werken of niet. Dat kunnen amateurs zoals Lodewijk en ik en vele andere forumleden (nog) niet. Dus wij moeten nog dingen uitproberen om te zien of het werkt zoals we in gedachten hadden. En daar leer je veel van, het helpt juist om inzicht te krijgen. Inzicht dat je door eigen ervaringen verkrijgt, blijft ook beter hangen dan wanneer je het aangereikt krijgt.
En natuurlijk moet je dan niet meteen 'mooie' formulieren gaan maken met een uitgebreide opmaak. Vaak is een simpel gegevensblad al voldoende. En soms is alleen een query maken al voldoende.

Met excuus dat dit draadje nu nóg langer is geworden maar ik ben (net als jij) nou eenmaal overtuigd van bepaalde zaken.