[MS Access] DB ontwerp aanpassen aan nieuwe situatie *

[Niek_]

Dit is de huidige situatie:

Invulling recepten haalt z'n gegevens netjes uit de tabel ingrediënten.Tot zover gaat alles goed.

Ik kom nu het probleem tegen dat er ook recepten zijn die niet gewoon uit een aantal ingrediënten bestaan maar bestaan uit: een recept + een aantal ingrediënten.
_{vb: eiersalade bestaat uit het recept Gekookte eieren + een aantal ingrediënten. Het recept Gekookte eieren bestaat weer uit een aantal ingrediënten...}

Heb geen idee hoe ik dit nu zo oplos dat er in de tabel Recepten gewoon Eiersalade staat en dat de ingrediënten nog kloppen... Moet ik een extra tabel maken die er 'boven' staat of zo?

[Verwijderd]

Recepten zit nu gekoppeld aan Ingrediënten met de koppeltabel InvullingRecepten.

Een recept kan dus ook aan een ander recept gekoppeld worden. Dus nog een extra (koppel)tabel.

ReceptKoppel ofzo met als attributen: ReceptCode1, ReceptCode2. Zo kun je het recept Eiersalade koppelen aan het recept gekookte eieren. Die zit natuurlijk weer gekoppeld aan één of meer ingrediënten.

Bij die invullingRecepten zou ik overigens ReceptCode en Ingrediëntcode beide Primary maken. Als ze het allebei zijn, betekend het dat ze vaker mogen voorkomen, maar dat de combinatie tussen een recept en een ingrediënt maar één keer mag voorkomen (of is dat niet wenselijk?)
Het houdt dus in dat:
receptA IngrediëntA
en
receptA ingrediëntB
en
receptB ingrediëntA

wel allemaal mag, maar dat er bijvoorbeeld niet twee keer
ReceptA ingrediëntA
mag komen te staan (dat vang je dus af door beide attributen primary te maken).
En dat moet je dan natuurlijk ook bij je nieuwe koppeltabel doen, want ik neem aan dat je ook daar niet twee keer de eiersalade aan gekookte eieren gekoppeld wilt zien (één keer lijkt me genoeg).

[ Voor 27% gewijzigd door Verwijderd op 01-03-2004 16:19 ]

[Reptile209]

Zo voor de vuist weg zou ik ook zeggen: maak een tabel Gerechten aan. Ieder gerecht bestaat uit 1 of meer recepten. En dan kan je boodschappenlijstjes maken door de ingredienten per recept van een gerecht te sommeren.
Dat geeft misschien ook nog wat leuke speling erbij: je kan bijvoorbeeld mayo kopen en maken. Afhankelijk van de drukte van de kok kan je je DB misschien laten selecteren dat een bepaald recept door 1 ingredient te vervangen is.

[Niek_]

Toppie, top. Goede duidelijke reactie en een heel goed punt om ze allebei primaire sleutel te maken. Ga ik gelijk doen. Bedankt voor je reactie.

[SPee]

Een zelfrelatie.
Kan dat met Acces??

Dus dat een Recept een relatie kan hebben met een recept?

Dus misschien er een tabelletje bij met 2 velden: receptid en receptid.

De ene is uniek en geeft het hoofd recept aan. (dus de eiersalade)
De andere is niet uniek en kan andere recepten hebben. (dus eieren en salade)

[Verwijderd]

SPee schreef op 01 maart 2004 @ 16:20:
Een zelfrelatie.
Kan dat met Acces??

Dus dat een Recept een relatie kan hebben met een recept?

Dus misschien er een tabelletje bij met 2 velden: receptid en receptid.

De ene is uniek en geeft het hoofd recept aan. (dus de eiersalade)
De andere is niet uniek en kan andere recepten hebben. (dus eieren en salade)

Zoals je al zegt, dat kan met Acces. Met een koppeltabel, hulptabel, tweede tabel, zoals je het wil noemen. Alleen als de ene uniek is, kan iets maar aan één recept gekoppeld worden. Het is heel goed mogelijk dat je een recept aan meerdere recepten wilt koppelen. Daarom zou ik persoonlijk de combinatie uniek maken zoals ik al eerder uitlegde (beide primair dus).

In feite gebruik je voor de relatie tussen recepten en ingrediënten net zo goed een hulptabel. Het is dan ook heel gebruikelijk.

Als je een zelfrelatie "niet netjes" vindt, dan kun je inderdaad spelen met iets als gerechten of iets dergelijks.

Mayonaise zoals genoemd werd is inderdaad een appart punt (wat denk ik nog vaker voor komt dan je denkt, kijk maar naar kruiden). Je kunt het kopen als ingrediënt, of maken uit meerdere ingrediënten. Je zou het misschien met een extra attribuut aan kunnen geven bij het recept en bij het ingrediënt. Het is dan aan de softwarelaag om daar een duidelijke melding van te maken. (of je laat het gewoon achterwege ).

De ene is uniek en geeft het hoofd recept aan. (dus de eiersalade)
De andere is niet uniek en kan andere recepten hebben. (dus eieren en salade)

O, wacht, bij nog een keer lezen zie ik dat je er een andere interpretatie van hebt. Ik zag het meer van, de eiersalade is een uitbreiding op gekookte eieren, en jij ziet het meer als de eiersalade is een samenvoeging van gekookte eieren en salade.
Daar valt idd nog over na te denken

[ Voor 14% gewijzigd door Verwijderd op 01-03-2004 16:30 ]

[Niek_]

.....hoe krijg ik het voor elkaar om in 1 tabel 2 primaire sleutels te maken? Het is me een tijdje terug gelukt maar dat was meer geluk dan wijsheid....

Als ik nu 1 primaire sleutel ingesteld heb en de 2e aanklik en primaire maak dan vervalt de eerste en andersom geld precies hetzelfde....

[Verwijderd]

Niek_ schreef op 01 maart 2004 @ 16:29:
.....hoe krijg ik het voor elkaar om in 1 tabel 2 primaire sleutels te maken? Het is me een tijdje terug gelukt maar dat was meer geluk dan wijsheid....

Als ik nu 1 primaire sleutel ingesteld heb en de 2e aanklik en primaire maak dan vervalt de eerste en andersom geld precies hetzelfde....

Beide selecteren in de ontwikkelomgeving en dan op het sleuteltje klikken

[Max|Burn]

uhm, een ingredient kan nu maar van 1 leverancier komen..?...
Pak er eens een ER/D boekje bij en maak eerst ff een ER/D lijkt me..werkt een stuk beter.

[Niek_]

_{Tis dat er geen smilie is dat door de grond zakt maar anders.....}

[Niek_]

MaxBurn schreef op 01 maart 2004 @ 16:32:
uhm, een ingredient kan nu maar van 1 leverancier komen..?...
Pak er eens een ER/D boekje bij en maak eerst ff een ER/D lijkt me..werkt een stuk beter.

Een ingrediënt kan inderdaad maar bij een leverancier vandaan komen. In ruil voor vast prijzen (kortingen) nemen we vb alle vleesproucten bij de ene leverancier af en alle zuivel producten bij de ander.

[Max|Burn]

Niek_ schreef op 01 maart 2004 @ 16:33:
_{Tis dat er geen smilie is dat door de grond zakt maar anders.....}

no comment dan maar

Anyway , het is de vraag of je wel wil dat een recept een ander recept kan bevatten. m.a.w je recept bevat eieren..dat die gekookt moeten worden weet de kok wel of staat in de omschrijving..?

Of gekookte eieren is een ingredient..kan ook..
Dat er nu zo gewerkt wordt (een recept gekookte eieren) wil niet zeggen dat jij er klakkeloos mee verder moet.

[ Voor 64% gewijzigd door Max|Burn op 01-03-2004 16:39 ]

[Niek_]

MaxBurn schreef op 01 maart 2004 @ 16:34:
[...]


Doe het dan zelf. er staat niet in de openeningspost wat je zelf gedaan heb e.d. Alleen een probleem.
Anyway wat ik al eerder zei, het is de vraag of je wel wil dat een recept een ander recept kan bevatten. m.a.w je recept bevat eieren..dat die gekookt moeten worden weet de kok wel of staat in de omschrijving..?

??
Heb zelf hard zitten nadenken, "meer ook niet", wat wilde je nog meer doen dan?? Zou niet weten hoe ik m'n probleem moet formuleren voor de search....

edit:
De kok weet wel dat die eieren gekookt moeten worden. Gaat er alleen om dat alle, maar dan ook alle ingrediënten die nodig zijn voor een recept terug te leiden zijn. Deze worden dan namelijk per week besteld bij de leveranciers.
Zie ook dit topic.

[ Voor 48% gewijzigd door Niek_ op 01-03-2004 16:39 ]

[Verwijderd]

MaxBurn schreef op 01 maart 2004 @ 16:32:
uhm, een ingredient kan nu maar van 1 leverancier komen..?...
Pak er eens een ER/D boekje bij en maak eerst ff een ER/D lijkt me..werkt een stuk beter.

Weer een koppeltabel
IngrLevKoppel met daarin de leverancierscode en de ingrediëntcode beide primair

MS Access is veradelijk . Dit zit er altijd al zo mooi uit dat het ERD zo overdreven lijjkt, maar een ERD is zeker niet verkeerd om van te voren te maken, want juist dan zie je dit soort dingen veel beter. Reken er maar op dat als ingrediënten idd van meerdere leveranciers kunnen komen je een flink probleem had gehad als dit al verkeerd zat ingebouwd en in gebruik genomen was.
(edit: ik doe te lang over het tikken van mijn post)

Niek_ schreef op 01 maart 2004 @ 16:33:
_{Tis dat er geen smilie is dat door de grond zakt maar anders.....}

[ Voor 3% gewijzigd door Verwijderd op 01-03-2004 16:40 ]

[Max|Burn]

nu ik er over nadenk..gekookte eieren MOET gewoon een ingredient zijn..

[Niek_]

Gekookte eieren bestaan uit:
- eieren
- zout
- energie(kosten)
(dit is zo uitgesplitst omdat alles gefactureerd moet worden)

[Max|Burn]

Niek_ schreef op 01 maart 2004 @ 16:45:
Gekookte eieren bestaan uit:
- eieren
- zout
- energie(kosten)
(dit is zo uitgesplitst omdat alles gefactureerd moet worden)

Ja ik blijf van mening dat je die 2 of 3 ingredienten gewoon zo noteer in dat recept..OF je maak van gekookte eieren een ingredient en de kosten daarvan is de optelling van die 3 ingredienten. Ik ben zelf nooit een fan van ERD/DB verkrachting om je aan te passen aan de oude situatie..(je moet er wel rekening mee houden maar in overleg met de opdrachtgever tot betere oplossingen komen kan nooit kwaad)

[ Voor 21% gewijzigd door Max|Burn op 01-03-2004 17:38 ]

[Niek_]

Dit is wat ik nu heb:


Heb toch nog m'n twijfels of ik nu precies heb gedaan wat The_Tzar in zijn 1e post heeft neer gezet. Zou iemand me kunnen controleren?

[Verwijderd]

Niet helemaal.

Receptkoppel zit gekoppeld aan de koppeltabel tussen recepten en ingrediënten.
Dat is een beetje raar. Je zegt dus dat als je een recept koppelt aan ingrediënten, dat je dan één zo'n koppeling aan een recept kunt koppelen. Dan zou je dus eiersalade koppen aan zout, en die koppeling aan zout zou je koppelen aan..

Nee, dat wil je niet. Je wil eiersalade koppelen aan salade (ingrediënt) en aan gekookte eieren (recept). Gekookte eieren zit op zijn beurt weer gekoppeld aan eieren(ingrediënt) en zout (ingrediënt).

Receptcode2 moet dus ook aan recepten gekoppeld worden. Net als receptcode1. Zo kun je receptA(eiersalade) koppelen aan receptB(gekookte eieren).
Daarnaast zit eiersalade gekoppeld aan salade (waarschijnlijk iets meer).

Om te zien wat je nog meer voor eiersalade nodig hebt, moet je dan nog even opvragen wat de ingrediënten zijn van het recept waar eiersalade aan gekoppeld zit, namelijk gekookte eieren. Die zitten dan weer gekoppeld aan zout en eieren.

Dan de primaire sleutel. Eiersalade mag aan meerdere recepten gekoppeld worden dan alleen gekookte eieren (neem ik aan). Hij mag dan meerdere malen op receptcode1 voor komen. Ik zou dan ook de combinatie uniek maken.

[Verwijderd]

Ik dacht aan zoiets:

Recepten en Recepten_1 is dezelfde tabel. Om het voor MS Acces begrijpelijk te maken moet je de tabel twee keer invoegen. (in relaties hè, niet twee keer dezelfde tabel maken natuurlijk )

Je kunt nu nog wel eiersalade aan eiersalade koppelen.
Daarnaast kun je, ondanks de combinatie uniek is nog wel een keer eiersalade aan gekookte eieren koppelen en een keer gekookte eieren aan eiersalade (andere volgorde).

Wellicht dat je met een bepaalde constraint binnen access nog kunt voorkomen dat je eiersalade niet aan eiersalade kunt koppelen, maar ik zou niet weten hoe.

Misschien dat er overigens nog een mooiere oplossing is dan een zogenaamde "zelfrelatie"

[ Voor 8% gewijzigd door Verwijderd op 02-03-2004 16:00 ]

[Niek_]

Denk dat ik het nu zo ongeveer wel goed heb:


Bedankt voor jullie reacties, mochten er nog aanmerkingen zijn, ik hou me aanbevolen....

_{(voor de geintresserden wil ik ook wel het hele relatieoverizht plaatsen, is van een bestelsysteem + een CRM-systeem, maar dan hoor ik het wel)}

[Verwijderd]

Denk nog even na over de primary key van een invullingbon. Eigenlijk heeft elke tabel wel een primary key, of twee.

En ook even naar Factuur.
Het zijn beide tabellen die recepten koppelen met bon. Een Bon wordt gekoppeld aan Recept middels een factuur of een invullingsbon (is invullingsbon eigenlijk niet overbodig? wordt hij niet sowieso altijd al gekoppeld via factuur, of worden facturen niet altijd uitgeschreven? Of heb je dat gedaan i.v.m. het verwijderen van data, terwijl de facturen nooit verwijderd mogen worden?).

Denk voor invullingbon goed na, wat is uniek in die tabel. Is A (Boncode) uniek? Is B (Receptcode) uniek? Of zijn ze geen van beide uniek maar is de combinatie van de twee (of meer, maar dat kan in dit geval niet) uniek? Maak dan invullingBon gelijk even af.

[Niek_]

Verwijderd schreef op 02 maart 2004 @ 18:39:
Denk nog even na over de primary key van een invullingbon. Eigenlijk heeft elke tabel wel een primary key, of twee.

En ook even naar Factuur.
Het zijn beide tabellen die recepten koppelen met bon. Een Bon wordt gekoppeld aan Recept middels een factuur of een invullingsbon (is invullingsbon eigenlijk niet overbodig? wordt hij niet sowieso altijd al gekoppeld via factuur, of worden facturen niet altijd uitgeschreven? Of heb je dat gedaan i.v.m. het verwijderen van data, terwijl de facturen nooit verwijderd mogen worden?).

Denk voor invullingbon goed na, wat is uniek in die tabel. Is A (Boncode) uniek? Is B (Receptcode) uniek? Of zijn ze geen van beide uniek maar is de combinatie van de twee (of meer, maar dat kan in dit geval niet) uniek? Maak dan invullingBon gelijk even af.

Factuur heb ik geschrapt. Dit is eigenlijk niet relevant. Bij de bon zit altijd een kostenoverzicht wat bestaat uit veel meer dan alleen maar de gerechten (personeel-, locatie-, aankledings-, glaswerk/servies-kosten)

Invulling bon heb ik nog eens goed bekeken. Per Bon kunnen soms dezefde recepten voorkomen. Ik kan dus niet én Boncode én Receptcode een primary key geven. Ik denk dat de eneige mogelijkheid eigenlijk Boncode is. Die komt maar 1x voor, met daarbij meerdere recepten.

_{(Ik ga nu lopen pielen met screenshots, zal hem zo posten....)}

[ Voor 89% gewijzigd door Niek_ op 03-03-2004 09:26 ]

[Niek_]

(Klikbaar natuurlijk )


<sub>Ff korte index...:
- Bon: Alle info over een party die er is + bestandslocatie van de bon in word
- Btw: btw percentages
- Contacten: contactmomenten met klant, geregistreerd en bijgehouden
- Contactsoort: telefoon, e-mail, fax, brief, enz.
- Ingredienten: ingredienten
- InvullingBon: Invulling van de bon qua recepten
- InvullingRecepten: Invulling recepten qua ingredienten
- Klant: Alle info over een klant
- Leveranciers: Leveranciers van ingredienten
- Locatie: Locaties waar partijen kunnen plaats vinden
- Medewerkers: Onze eigen medewerkers (zodat ze aan een klant gekoppeld kunnen worden)
- Recepten: De recepten
- Receptkoppel: Zie paar post hierboven
- Taakcategorie: Soort taak voor medewerker (nakijken bon, nabellen klant, enz)
- Taken: Taken die er per medewerker staan.</sub>

Shoot me! Eventuele op/aanmerkingen zijn natuurlijk altijd van harte welkom. Moet er wel even bij vermelden dat mijn eerste prioriteit bij het stuk db t/m InvullingBon ligt. Wil eerst dat dit goed werkt (het door de computer laten berekenen van de benodigde ingredienten voor een week) Hierna volgt het 'CRM' (ok, groot woord, ik weet het... ) systeem.

[Lustucru]

ben niet helemaal overtuigd van de gekozen oplossing. Ik vind het een beetje tweeslachtig. Als je snel voorraden en bestellingen wilt kunnen berekenen zou ik er toch voor kiezen om van ieder 'hoofdrecept' alle ingredienten tot in detail op te slaan. Je brengt dan de recursie terug tot een invoerprobleem, maar dat is met een beetje code wel op te lossen. M.a.w. je voert een composiet in (gekookte eieren bv in de salade) en het systeem rekent on the fly dat uit in eieren, zout, water en gas. Moet trouwens in die koppeltabel recepten ook niet een hoeveelheid? Nu neemt ie de standaardhoeveelheid van het onderliggende recept over en dat lijkt em niet altijd de bedoeling. (In een portie eiersalade zitten meer gekookte eieren dan in een portie hollands gemengd).

Helemaal aan de andere kant zou je ervoor kunnen kiezen om alles (dus ook de ingredienten) als een recept te zien. Een ingredient is dan niets anders dan een recept wat buiten de deur wordt ingekocht.
De tabellen koppelrecepten en invullingrecepten worden dan samengevoegd en in de tabel recepten komt dan een veld inkoopinfo dat verwijst naar de tabel ingredienten, waar dan trouwens naam & omschrijving uit kunnen verdwijnen.

[Niek_]

Niesje schreef op 03 maart 2004 @ 13:00:
Helemaal aan de andere kant zou je ervoor kunnen kiezen om alles (dus ook de ingredienten) als een recept te zien. Een ingredient is dan niets anders dan een recept wat buiten de deur wordt ingekocht.
De tabellen koppelrecepten en invullingrecepten worden dan samengevoegd en in de tabel recepten komt dan een veld inkoopinfo dat verwijst naar de tabel ingredienten, waar dan trouwens naam & omschrijving uit kunnen verdwijnen.

De eerste optie valt voor mij een beetje af. Dat komt eigenlijk omdat ik niet helemaal snap wat je bedoelt. Van ieder 'hoofdrecept' zijn alle ingrediënten tot in detail terug te vinden in de tabel 'InvullingRecepten'. Zou je misschien kunnen uitleggen wat je precies bedoelt?

De tweede optie snap ik wel maar is denk ik niet helemaal uitvoerbaar.

Het doel van deze db is het volgende: De secretaresses vullen de bonnen in in het systeem. De kok hoeft nu alleen maar 1 keer per week op print te drukken (bij wijze van spreken natuurlijk) en er rolt per leverancier een fax uit met daarop de bestelling voor de week daarop.

Op dit moment leest hij alle bonnen door, schrijft de recepten op. Pakt die blaadjes weer als hij alles gehad heeft, leest ze weer door en schrijft alle ingredienten op en dan als laatste zoekt hij alle ingredienten bij elkaar en schrijft ze op een fax voor de leverancier. Dit kost enorm veel tijd (hoogseizoen 3 wekdagen per week...) en die tijd is er niet.

Met behulp van de db moet dit in no-time gebeurd zijn. Het systeem doet het volgende:
- kijk per bon welke recepten er zijn en voor hoeveel personen de bon is.
- berekend hoeveel van elk recept nodig is per bon
- berekend hoeveel van elk ingredient nodig is voor de recepten
- telt dit alles van 1 week (of langer of korte, wat je zelf wil) bij elkaar op
- zorgt ervoor dat er een mooi faxje uit de printer komt voor de leveranciers

Bijkomend voordeel is dat alle gegevens van de bonnen nu ook in het systeem staat (personen, datum, tijd, enz, enz, enz.) en dus snel toegankelijk is (vergeleken met archiefkast) voor de secretaresses.

Hoop dat ik een beetje uiteen heb kunnen zetten wat ik wil bereiken...?

[Lustucru]

In de huidige opzet moet je, om alle ingredienten te vinden voor een serie bonnen, alle recepten recursief nalopen op gekoppelde recepten. Dat pleit ervoor om de opslag van je recepten en ingredienten simpel te houden: alle recepten worden volledig gedetailleerd opgeslagen in ingredienten. Een relatief simpele query volstaat dan.
Nadeel is dat er een invoerporbleem ontstaat: je wilt niet als je eiersalade aanmaakt de gekookte eieren opnieuw invoeren. dat kun je oplossen door de secretarresse de mogelijkheid te bieden gekookte eieren in te voeren en het systeem dat meteen uit te laten splitsen in detailingredienten. (optie 1).
wat ook meespeelt is dat je je moet afvragen of een basisrecept kan veranderen terwijl in een afgeleid recept het origineel gehandhaafd moet blijven. Als dat kan gebeuren is de huidige opzet niet correct. Als dat nooit gebeurd is mijn optie 1 weer niet zo geschikt.

[Niek_]

Niesje schreef op 03 maart 2004 @ 14:11:
In de huidige opzet moet je, om alle ingredienten te vinden voor een serie bonnen, alle recepten recursief nalopen op gekoppelde recepten. Dat pleit ervoor om de opslag van je recepten en ingredienten simpel te houden: alle recepten worden volledig gedetailleerd opgeslagen in ingredienten. Een relatief simpele query volstaat dan.
Nadeel is dat er een invoerporbleem ontstaat: je wilt niet als je eiersalade aanmaakt de gekookte eieren opnieuw invoeren. dat kun je oplossen door de secretarresse de mogelijkheid te bieden gekookte eieren in te voeren en het systeem dat meteen uit te laten splitsen in detailingredienten. (optie 1).
wat ook meespeelt is dat je je moet afvragen of een basisrecept kan veranderen terwijl in een afgeleid recept het origineel gehandhaafd moet blijven. Als dat kan gebeuren is de huidige opzet niet correct. Als dat nooit gebeurd is mijn optie 1 weer niet zo geschikt.

Denk dat ik nu aardig door heb wat je bedoelt. Denk toch dat ik het zo laat omdat de computer toch de gene is die alles na loopt en er geen personeel voor nodig is. Ff kwestie van klikken en de computer doet de rest. Dat hij dan misschien iets langer nodig is neem ik voor lief, hoeft maar 1 keer per week te gebeuren en het bedrijf groeit ook nooit zo hard dat het ooit te lang zal gaan duren.