[Rel DB] Probleem met Normalisatie

[mr_obb]

Ik wil als oefening een klein kassaprogramma maken met behulp van Visual c++ en mySQL. Ik ben nu aan het nadenken over het relationele model en zit met het volgende probleem.

In dit kassaprogramma moet een bon gemaakt worden. Om een bon te kunnen maken heb je minimaal 3 tabellen nodig:

Bongegevens, met daarin het bonnummer, datum, tijd, verkopernummer, klantnummer enz.
Artikelen, met daarin het artikelnummer, prijs en andere gegevens
Bonnen, met daarin bonnummer en artikelnummer

Als ik het op deze manier in een database zou zetten, zou dat prima gaan, ik kan bonnen maken, met daarop allerlei mooie artikelen. Maar dan gebeurt het volgende: Ik verkoop aan Jantje een appel voor 3 euro. Een uur later verlaag ik de prijs naar 2 euro. Als ik nu aan het einde van de dag mijn omzet opvraag, dan blijk ik 2 euro omgezet te hebben, terwijl ik 3 euro in kas heb.

Ik kan nu natuurlijk in de tabel bonnen ook de prijs gaan bijhouden, maar ik kan me voorstellen dat ook een ander deel van de artikelbeschrijving aangepast gaat worden en dan moet ik dus alle kolommen van de artikeltabel gaan bijhouden in de bonnentabel en dat lijkt me niet de bedoeling.

Alle boeken die ik bekijk gaan over normalisatie, maar nergens zie ik een vergelijkbaar probleem besproken. Weet iemand een boek dat hier wel op in gaat? Of kan iemand uitleggen hoe dit het best op te lossen is?

[StevenK]

En daarom kun je dus niet de prijs uit de artikelen tabel gebruiken, maar moet je de prijs in de bon opslaan.

Alternatief, maar veel omslachtiger, is een aparte prijstabel bijhouden, met daarin datetime velden, zodat je aan de hand van de datetime van de bon kunt zien welke prijs bij welk artikel hoort.

Overigens, boekhoudkundig gezien, moet je zowieso alle informatie die op de bon staat opslaan; aangezien de prijsinformatie per artikel verkoop info is en niet administratief, is het daarom niet verstandig die gegevens te gebruiken, net zo min als het verstandig is een faktuur alleen maar te linken aan adres gegevens: wanneer je achteraf in het relatiebestand een adres wijzigt, wil je toch achteraf nog steeds weten aan welk adres die faktuur gestuurd is.

[Verwijderd]

Ik neem bij kassa achtige zaken meestal de volgende zaken mee naar de 'verkoop regels':
(onder voorbehoud, ik noem ff die zaken die in m'n hoofd opkomen)

- artikel nr
- artikel omschrijving
- artikel btw perc.
- artikel prijs inkoop (optioneel)
- artikel prijs verkoop
- artikel kortings percentage

en natuurlijk aantal, ordernr, volgnr etc. etc.

In principe moet je aan de hand van je 'verkoop regel' tabel, de bon weer kunnen herconstrueren (is mij principe althans).

En idd een prijstabel is een optie, echter de gegevens van een verkocht artikel zijn in principe bij een verkoop 'statisch' geworden. Bij prijstabellen willen nogal eens 'schoonmaak' acties voorkomen, zodat b.v. alle prijzen van ouder dan een jaar worden opgeruimd.
Prijstabellen gebruik ik wel voor het bepalen v/d huidige prijs van een artikel, evenals btw etc.

[ Voor 58% gewijzigd door Verwijderd op 29-11-2004 21:55 ]

[Blizard]

StevenK schreef op maandag 29 november 2004 @ 21:44:
Overigens, boekhoudkundig gezien, moet je zowieso alle informatie die op de bon staat opslaan; aangezien de prijsinformatie per artikel verkoop info is en niet administratief, is het daarom niet verstandig die gegevens te gebruiken, net zo min als het verstandig is een faktuur alleen maar te linken aan adres gegevens: wanneer je achteraf in het relatiebestand een adres wijzigt, wil je toch achteraf nog steeds weten aan welk adres die faktuur gestuurd is.

Klopt als een bus. Wanneer jantje naar de belastingsaangifte gaat moet jij exact dezelfde factuur (bon) uit je systeem kunnen tevoorschijn halen. Dit kan enkel als je de gegevens van je producten gaat overpompen in de factuur. Je krijgt inderdaad redundante gegevens ... maar zit niks anders op.
Als je de factuur niet meer wil hebben maar wel een omzet kan je makkelijk een appart tabelletje maken waar je iedere keer "omzet += prijs_verkocht_artikel" doet. Je kan alle kanten op, moet alleen ff denken wat je juist wil

[mr_obb]

Ok, jullie zeggen dus allebei: laat die normalisatie vallen en neem alle informatie gewoon mee. Ik zat zelf ook na te denken over de methode die StevenK geeft, om in de tabel met artikelen (en de tabel met klantgegevens zoals hij terecht opmerkt) een timestamp te gebruiken. Dit is een wat complexere manier en volgens mij ook niet echt handig.

Blizard schreef op maandag 29 november 2004 @ 21:54:
[...]

Klopt als een bus. Wanneer jantje naar de belastingsaangifte gaat moet jij exact dezelfde factuur (bon) uit je systeem kunnen tevoorschijn halen. Dit kan enkel als je de gegevens van je producten gaat overpompen in de factuur. Je krijgt inderdaad redundante gegevens ... maar zit niks anders op.
Als je de factuur niet meer wil hebben maar wel een omzet kan je makkelijk een appart tabelletje maken waar je iedere keer "omzet += prijs_verkocht_artikel" doet. Je kan alle kanten op, moet alleen ff denken wat je juist wil

Ik wil wel een echt bruikbaar systeem krijgen en niet 'zo maar' een oplossing.

[ Voor 52% gewijzigd door mr_obb op 29-11-2004 21:56 ]

[Blizard]

mr_obb schreef op maandag 29 november 2004 @ 21:54:
Ik wil wel een echt bruikbaar systeem krijgen en niet 'zo maar' een oplossing.

Ik zeg ook niet dat je dan een onbruikbaar systeem krijgt of zomaar een oplossing. Maar als je heel veel de omzet gaat opvragen is het mss handig om de omzet iedere keer appart weg te schrijven (join en sum van iedere keer je sub_prijsjes kost tijd).
Maar je moet soms inderdaad het normaliseren op bepaalde vlakken laten vallen. Meestal ga je denormaliseren als je statistische gegevens wil bewaren, wat bij jou hier het geval is. Zelfs je klant zn adres moet je volledig overnemen. Als hij verhuist mag niet het nieuwe adres op je bon komen (zoals StevenK zei).

check ook een oud topic van me
http://gathering.tweakers.net/forum/list_messages/711872

[mr_obb]

Ok, het antwoord is duidelijk en de mogelijkheden heb ik op een rij.

Dan gaan we nu weer verder met denken, blaadjes volschrijven, tekeningetjes maken enz...

De databases gaan nu wel lukken, de volgende grote problemen komen waarschijnlijk bij het uitzoeken van een veilige manier van de applicatie-pc via internet naar een SQL-server te krijgen. Maar dat is nog een paar maanden weg

[ Voor 43% gewijzigd door mr_obb op 29-11-2004 22:10 ]

[StevenK]

mr_obb schreef op maandag 29 november 2004 @ 22:08:
Ok, het antwoord is duidelijk en de mogelijkheden heb ik op een rij.

Dan gaan we nu weer verder met denken, blaadjes volschrijven, tekeningetjes maken enz...

Dat gaat een stuk sneller met een mooie data modelleer tool, of eventueel met een minder mooie, zoals die in de SQL Enterprise manager zit

[dusty]

ten eerste; Je gaat *NOOIT* denormaliseren. Je gaat juist verder normaliseren.
Normaliseren gaat verder dan de 3^e normaal vorm!

[Verwijderd]

Je kan de zaak genormaliseerd houden, dan zit je echter wel vast aan het onderhouden van de volledige prijsgeschiedenis van producten:

code:

Bon (1)--(n) Verkoop (n)--(1) Artikelprijs (n)--(1) Artikel

Als alternatief en nog redelijk genormaliseerd zie ik

code:

Bon (1)--(n) Verkoop (n)--(1) Artikel (1)--(n) Artikelprijs

waarbij in de verkoop de huidige prijs van het artikel gedupliceerd wordt. De prijs komt dan 2x voor maar het voordeel is dat de prijsgeschiedenis opgeschoond kan worden.

Je kan zelfs zo ver gaan als

code:

Bon (1)--(n) Verkoop (n)--(1) Artikel

met prijs dubbel bij artikel en verkoop, maar dat kan problemen geven omdat prijswijzigingen direct zijn.

[Verwijderd]

dusty schreef op maandag 29 november 2004 @ 22:12:
ten eerste; Je gaat *NOOIT* denormaliseren. Je gaat juist verder normaliseren.
Normaliseren gaat verder dan de 3^e normaal vorm!

Je hebt nog de 4e en 5e vorm ja, maar nooit denormaliseren is wel wat erg sterk gezegd. Voor een hoop taken ontkom je gewoon niet aan denormaliseren simpelweg omdat je gewoon de snelheid niet kan halen die je nodig hebt in een genormaliseerde database. Dit kan zowel bij OLAP als OLTP een probleem zijn. Er is dan ook weinig mis met bewust denormaliseren.

In dit geval is er echter IMHO helemaal geen sprake van denormaliseren, je slaat namelijk geen gegevens dubbel op maar gegevens die fundamenteel verschillend zijn. (Historische vs huidige prijzen, historische vs huidige adresgegevens enz) Deze verschillende zaken zul je dan ook apart moeten bewaren. Dat ze in praktijk vaak overeenkomen is een tweede. Soms, en vooral voor adres velden, is het effectiever om bij te houden wanneer een adres gewijzigd is en het adres op die manier terug te zoeken (klant nummer + datum bon geeft adres op bon) maar vaak ook niet.

[dusty]

Je hebt nog de 4e en 5e vorm ja, maar nooit denormaliseren is wel wat erg sterk gezegd. Voor een hoop taken ontkom je gewoon niet aan denormaliseren simpelweg omdat je gewoon de snelheid niet kan halen die je nodig hebt in een genormaliseerde database.

Ga je denormaliseren, dan heb je juist de 4e en 5e normaal vorm niet begrepen.

[ACM]

dusty schreef op dinsdag 30 november 2004 @ 06:09:
Ga je denormaliseren, dan heb je juist de 4e en 5e normaal vorm niet begrepen.

Maar het punt blijft dat een perfect genormaliseerde database bijna nooit beter kan presteren dan een wat minder perfect genormaliseerde database.

[kasper_vk]

dusty schreef op dinsdag 30 november 2004 @ 06:09:
[...]

Ga je denormaliseren, dan heb je juist de 4e en 5e normaal vorm niet begrepen.

Ok, na e.e.a. gelezen te hebben over de 4e en 5e nromaalvorm (o o o , wat kan kennis diep wegzakken ); kun je wellicht even toelichten hoe de 4e en 5e normaalvorm de topicstarter kunnen helpen bij dit probleem?

Want ondanks dat je de TS natuurlijk een zet in de juiste richting geeft, komt bovenstaande (bij mij) ook wel een beetje over als 'ik weet het beter, maar ik zeg lekker niet hoe'. (no offence intended )
Ik denk dat 4e en 5e normaalvorm voor de meeste lezers daarnaast een onderwerp is dat (hooguit) ooit op school behandeld is en in de praktijk wellicht niet vaak (genoeg) wordt toegepast.

[ Voor 3% gewijzigd door kasper_vk op 30-11-2004 09:27 ]

[Verwijderd]

ik denk dat dusty er op doelt dat ipv de gegevens over te halen naar de 'orderregel tabel', je op het moment van verkoop eventueel een tabel vult waarin de relevante gegevens staan voor een artikel van dat moment (4e/5e normaalvorm wordt ook door mij zeer weinig toegepast . moet ze nog eens goed bestuderen denk ik .... )

[kasper_vk]

Het spreek voor zich dat je in ieder geval t/m de 3e normaalvorm normaliseert. Snelheidsverlies is tot dat niveau immers veruit ondergeschikt aan het elimineren van redundantie en dus het elimineren van integriteitsbedreigingen.

Volgens valt wat jij bedoelt nog onder de eerste 3 normaalvormen.

Verder normaliseren betekent over het algemeen dat je overigens nog meer redundantie & integriteitsrisico's weghaalt, alleen vaak worden dan de query's wat ingewikkelder (voor sommigen al gauw té ingewikkeld ) en de executietijd daarvan (dus) langer. Maar besef je iig welke problemen zich kunnen voordoen wanneer je niet verder normaliseert.

@TS: ik (en anderen hier waarschijnlijk ook) neem wel aan dat je de eerste 3 NV kent (zo niet, dan adviseer ik je om je daar absoluut even in te verdiepen)

[ Voor 5% gewijzigd door kasper_vk op 30-11-2004 11:23 ]

[Verwijderd]

kasper_vk schreef op dinsdag 30 november 2004 @ 11:21:

mooi verhaal, en hoe uit zich dat dan in toepassing op het probleem van TS?

Het bijhouden van verkoopregels ? Dat het kan met een historische prijs & btw tabel is duidelijk.

[kasper_vk]

In het geval van de TS houd je per bon (per verkoop dus) per artikel een bonregel bij; die binregel is niets anders dan de N-N koppeltabel tussen een tabel artikel en een tabel bon (/verkoop).
Per bonregel sla je alleen gegevens op die geindentificeerd worden door de bonregel waarin ze staan (3e nv): het verkochte aantal zal een van de weinige zaken zijn die je hierin zet. De rest van de artikelgegevens (naam, merk, gewicht, enz.) sla je alleen op in de tabel artikel en de prijsgegevens haal je weer op uit een tabel artikelprijs.
Het gedoe met de prijzen kun je wel iets vereenvoudigen door in artikel de actuele prijs op te slaan, en oudere prijzen in een tabel 'historische prijzen' op te slaan (pk is dan de pk van het artikel en de vervaldatum van de prijs).
De prijs sla je niet op in de bonregel, wanneer de prijs af te leiden is van (de datum van) de verkoop (in de tabel bon) en het artikel(nummer). Ook dit is nog slechts 3e nv.

Dan heb je nog steeds geen redundantie, maar ook nog steeds al je gegevens.

@mau71: Bedoel je dit?

[Verwijderd]

kasper_vk schreef op dinsdag 30 november 2004 @ 11:54:
In het geval van de TS houd je per bon (per verkoop dus) per artikel een bonregel bij; die binregel is niets anders dan de N-N koppeltabel tussen een tabel artikel en een tabel bon (/verkoop).
Per bonregel sla je alleen gegevens op die geindentificeerd worden door de bonregel waarin ze staan (3e nv): het verkochte aantal zal een van de weinige zaken zijn die je hierin zet. De rest van de artikelgegevens (naam, merk, gewicht, enz.) sla je alleen op in de tabel artikel en de prijsgegevens haal je weer op uit een tabel artikelprijs.
Het gedoe met de prijzen kun je wel iets vereenvoudigen door in artikel de actuele prijs op te slaan, en oudere prijzen in een tabel 'historische prijzen' op te slaan (pk is dan de pk van het artikel en de vervaldatum van de prijs).
De prijs sla je niet op in de bonregel, wanneer de prijs af te leiden is van (de datum van) de verkoop (in de tabel bon) en het artikel(nummer). Ook dit is nog slechts 3e nv.

Dan heb je nog steeds geen redundantie, maar ook nog steeds al je gegevens.

@mau71: Bedoel je dit?

ja, maar ik zie nog steeds de woorden historisch en prijzen te dicht bij elkaar staan
Ook omschrijvingen van artikelen veranderen weleens (niet het artikel of artikelnr) maar echt de omschrijving. Slaan we deze ook op in een historische tabel?

[ Voor 7% gewijzigd door Verwijderd op 30-11-2004 12:07 ]

[mr_obb]

Ik heb ondertussen artikelen gevonden over "temporal databases". Dit is een benaming voor databases waar niet alleen huidige informatie, maar ook historische informatie moet worden bijgehouden. In een aantal van die artikelen worden richtlijnen gegeven over de manier waarop je hier mee om moet gaan. Interessante stof en behoorlijk ingewikkeld

Ik heb met jullie antwoorden en de artikelen een stevige basis om verder te gaan.

[kasper_vk]

Tja, als die idd veranderen en je bent ook echt geinteresseerd in de oude waarden, dan wel.
Het opslaan in iedere bonregel zou nog steeds redundant/niet-genormaliseerd zijn: want de omschrijving van het artikel hangt niet af van de bonregel waar ie op staat.

Los van de implementatie, vraag me over die situatie af: wanneer je de omschrijving van een artikel verandert, om wat voor wijziging gaat het dan? De omschrijving zou wellicht duidelijker worden, aangevuld worden, gecorrigeert worden, enz. Maar echt een andere omschrijving wordt het niet, want het gaat immers nog steeds om hetzelfde artikel.
Zou het om een ander artikel gaan, dan ben je natuurlijk fundamenteel fout bezig wanneer je omschrijving veranderd, want dan zou je gewoon een nieuw artikel moeten invoeren.
Dus wanneer ben je dan echt geinteresseerd in de 'oude' omschrijving?

[mr_obb]

kasper_vk schreef op dinsdag 30 november 2004 @ 13:30:
Los van de implementatie, vraag me over die situatie af: wanneer je de omschrijving van een artikel verandert, om wat voor wijziging gaat het dan? De omschrijving zou wellicht duidelijker worden, aangevuld worden, gecorrigeert worden, enz. Maar echt een andere omschrijving wordt het niet, want het gaat immers nog steeds om hetzelfde artikel.
Zou het om een ander artikel gaan, dan ben je natuurlijk fundamenteel fout bezig wanneer je omschrijving veranderd, want dan zou je gewoon een nieuw artikel moeten invoeren.
Dus wanneer ben je dan echt geinteresseerd in de 'oude' omschrijving?

Ik kan me voorstellen dat ik inderdaad een artikelnaam verduidelijk. Om even terug te stappen naar het appel verhaal: Stel ik heb een prijslijst met daarop het artikel appel met een prijs van 3 euro. Mijn klanten beginnen te klagen dat ze 3 euro wel erg duur vinden. Dit is terecht, want die prijs is per kilo. Ik pas dan de beschrijving aan naar appelen per kilo. Als ik niet heb opgeslagen dat piet 's morgens een appel heeft gekocht met de oude omschrijving, dan kan ik dat niet meer achterhalen na de wijziging. Toch wil ik nog altijd de bon die ik hem 's morgens heb meegegeven exact kunnen repliceren. Daarom zal ik ook van de omschrijving de geschiedenis bij moeten houden. (Zoals eerder gezegd ben ik wettelijk verplicht om die bon te kunnen repliceren.)

[djluc]

Je kan inderdaad de gegevens constant opslaan in de bon-table. Je kan ook de producten tabel historisch maken. Beide hebben voor en nadelen, de 2e methode vereist vaak wat meer werk.

Bij iedere wijziging voer je dus een nieuw record in de productentabel in. Hierdoor kan je heel mooi de historie volgen. Zeker als je UPDATE niet toestaat op de tabel kan je de omschrijving er altijd weer uithalen omdat je ook de datum weet van de bon.

[Verwijderd]

mr_obb schreef op dinsdag 30 november 2004 @ 13:37:
[...]
Ik kan me voorstellen dat ik inderdaad een artikelnaam verduidelijk. Om even terug te stappen naar het appel verhaal: Stel ik heb een prijslijst met daarop het artikel appel met een prijs van 3 euro. Mijn klanten beginnen te klagen dat ze 3 euro wel erg duur vinden. Dit is terecht, want die prijs is per kilo. Ik pas dan de beschrijving aan naar appelen per kilo. Als ik niet heb opgeslagen dat piet 's morgens een appel heeft gekocht met de oude omschrijving, dan kan ik dat niet meer achterhalen na de wijziging. Toch wil ik nog altijd de bon die ik hem 's morgens heb meegegeven exact kunnen repliceren. Daarom zal ik ook van de omschrijving de geschiedenis bij moeten houden. (Zoals eerder gezegd ben ik wettelijk verplicht om die bon te kunnen repliceren.)

precies, en dan kan je wel weer een historische tabel gaan bijhouden per artikel, echter ik vind dat wat ver gaan. Zeker gezien het op het moment dat de verkoop is afgehandeld het puur over statische gegevens gaat.

[Verwijderd]

kasper_vk schreef op dinsdag 30 november 2004 @ 13:30:
Los van de implementatie, vraag me over die situatie af: wanneer je de omschrijving van een artikel verandert, om wat voor wijziging gaat het dan? De omschrijving zou wellicht duidelijker worden, aangevuld worden, gecorrigeert worden, enz. Maar echt een andere omschrijving wordt het niet, want het gaat immers nog steeds om hetzelfde artikel.
Zou het om een ander artikel gaan, dan ben je natuurlijk fundamenteel fout bezig wanneer je omschrijving veranderd, want dan zou je gewoon een nieuw artikel moeten invoeren.
Dus wanneer ben je dan echt geinteresseerd in de 'oude' omschrijving?

Is bv een computer met een 220 volt voeding hetzelfde als een computer met een voeding die 110 en 220 volt aankan? Een fabrikant kan dit soort zaken per serie veranderen maar je wilt het wél graag goed op de bon hebben.

Ook krijg je vaak te maken met meer velden dan enkel een Omschrijving en Prijs. Denk eens aan zaken als gewicht, Keuringsnormen, enz enz. Je kan dus in de situatie terechtkomen dat je een groot aantal historische tabellen moet gaan bijhouden. Je kan je afvragen of dat wel zo zinvol is om te implementeren.

[mr_obb]

Verwijderd schreef op dinsdag 30 november 2004 @ 15:08:
[...]
Ook krijg je vaak te maken met meer velden dan enkel een Omschrijving en Prijs. Denk eens aan zaken als gewicht, Keuringsnormen, enz enz. Je kan dus in de situatie terechtkomen dat je een groot aantal historische tabellen moet gaan bijhouden. Je kan je afvragen of dat wel zo zinvol is om te implementeren.

Zulke eigenschappen komen niet op de bon en hoeven dus ook niet bijgehouden te worden. Puur administratief gezien hoeft alleen bijgehouden te worden wat er exact op de bon stond van meneer X op xx-xx-xxxx.

[Verwijderd]

mr_obb schreef op dinsdag 30 november 2004 @ 15:12:
[...]


Zulke eigenschappen komen niet op de bon en hoeven dus ook niet bijgehouden te worden. Puur administratief gezien hoeft alleen bijgehouden te worden wat er exact op de bon stond van meneer X op xx-xx-xxxx.

Dat hangt sterk af van de branche waar je in werkt.

[Verwijderd]

mr_obb schreef op dinsdag 30 november 2004 @ 15:12:
[...]


Zulke eigenschappen komen niet op de bon en hoeven dus ook niet bijgehouden te worden. Puur administratief gezien hoeft alleen bijgehouden te worden wat er exact op de bon stond van meneer X op xx-xx-xxxx.

Als je toch aan de slag gaat met VC++, maak er dan een MFC app van. De bon bouw je dan als view .

[kasper_vk]

Verwijderd schreef op dinsdag 30 november 2004 @ 15:08:
[...]
Is bv een computer met een 220 volt voeding hetzelfde als een computer met een voeding die 110 en 220 volt aankan? Een fabrikant kan dit soort zaken per serie veranderen maar je wilt het wél graag goed op de bon hebben.
...

Ben ik het gedeeltelijk mee eens.

Gedeelte niet
Ik vraag me zowieso af of je voor dergelijke zaken niet een behoorlijk afwijkend datamodel nodig hebt. Mocht je het toch in het huidge model kwijt kunnen: dan heb je m.i. met 2 verschillende artikelen te maken, niet met een verandering van 1 artikel. Je moet niet proberen in dergelijke invoerfouten op te lossen in je datambasemodel.

Wat wel
Het blijft natuurljik een afweging. Als van artikelen de gegevens zeer frequent veranderen, dan vormt het bijhouden van historische gegevens en daaruit opzoeken wellicht een crime. In dat geval doe je er idd wellicht beter aan de actuele gegevens over te nemen op bonregels. Hoewel je dan nog steeds redundant bezigent en dus integriteitsrisico's loopt.
Al vraag ik me af of je je artikelen dan wel correct hebt ingedeeld (meer een domeinkwestie dus), want dan gaat het al gouw op serie-stuk of stuk-productie lijken en dan heb je idd niet zoveel meer aan artikelen in deze vorm.

[dusty]

kasper_vk schreef op dinsdag 30 november 2004 @ 09:25:
[...]
Ok, na e.e.a. gelezen te hebben over de 4e en 5e nromaalvorm (o o o , wat kan kennis diep wegzakken ); kun je wellicht even toelichten hoe de 4e en 5e normaalvorm de topicstarter kunnen helpen bij dit probleem?

4e en 5e normaal vorm in een notedop is dat je bepaalde aspecten en waarden gaat opslaan die de snelheid verbeteren, zoals bij een sub-forum het totaal aantal posts. Je zou het elke keer kunnen overnieuw berekenen door een SUM over de reactie tabel, maar door het toevoegen van een kolom met een aantal wordt de select-sql operatie een stuk sneller, en aangezien het getal relatief niet vaak veranderd is dat prima verantwoord. Een ander gedeelte van de 4e en 5e normaal vorm is dat je ook weer waarden kan gaan invoeren die 'dubbel' zijn, maar van belang zijn voor de snelheid van de database. Veel mensen gaan hierbij in de fout, omdat ze oog verliezen voor de history en/of snelheid maar weer kolommen gaan toevoegen waardoor het alleen maar makkelijker voor hun wordt, maar in principe niets met snelheid winst heeft te maken.

In dit geval heeft het allemaal te maken met Historie, en niet zoveel met snelheid (eigenlijk helemaal niet, omdat het ophalen van oude bonnen niet als kritisch beshouwd kan worden.) Maar heeft het begrijpen van de 4e en 5e normaal vorm wel het effect dat je begrijpt dat je waarden als je ze veranderd wel eens apart moet opslaan in een 'historie' tabel.

Hier is het in een history tabel opslaan van die artikelen wel van toepassing. ( ie, je slaat het artikel op als je het veranderd met een verander datum erbij. ) hierdoor kan je de prijs van een artikel bepalen op een bepaalde dag/tijd, en kan je achteraf een identieke bon opstellen als je de bon nummer weet. (immers hangt er een datum en artikelen aan een bon. ) en daarmee kan je in de de geschiedenis kijken wat een bepaalde artikel koste.

Want ondanks dat je de TS natuurlijk een zet in de juiste richting geeft, komt bovenstaande (bij mij) ook wel een beetje over als 'ik weet het beter, maar ik zeg lekker niet hoe'. (no offence intended )

Dat was dus niet zo bedoeld. Maar er zijn redelijk veel documenten over normaliseren te vinden. En heb al vaker vertelt wat de 4e en 5e normaal vorm inhoud.

Ik denk dat 4e en 5e normaalvorm voor de meeste lezers daarnaast een onderwerp is dat (hooguit) ooit op school behandeld is en in de praktijk wellicht niet vaak (genoeg) wordt toegepast.

Dat het in de praktijk inderdaad niet genoeg (of correct) wordt toegepast is eigenlijk wel een feit.

[Verwijderd]

4e normaal vorm http://www.cs.jcu.edu.au/...es/normalisation/4nf.html

In fourth normal form, we have a relation that has information about only one entity. If a relation has more than one multivalue attribute, we should decompose it to remove difficulties with multivalued facts.

5e normaal vorm http://www.cs.jcu.edu.au/...es/normalisation/5nf.html

The fifth normal form deals with join-dependencies which is a generalisation of the MVD. The aim of fifth normal form is to have relations that cannot be decomposed further. A relation in 5NF cannot be constructed from several smaller relations.

Dit heeft dus niets te maken met

4e en 5e normaal vorm in een notedop is dat je bepaalde aspecten en waarden gaat opslaan die de snelheid verbeteren, zoals bij een sub-forum het totaal aantal posts.

Het gebruik van snelheidsverbeterende aspecten is een vorm van denormalisatie, nuttig maar dus wel iets anders

En heb al vaker vertelt wat de 4e en 5e normaal vorm inhoud.

Ik hoop toch niet aan al te veel mensen

[ Voor 6% gewijzigd door Verwijderd op 30-11-2004 19:43 ]

[Freee!!]

Even een korte opmerking over de omschrijving en de prijs als onderdeel van de bon:

Voor de klant is belangrijk dat de omschrijving en de prijs begrijpelijk en duidelijk op de bon staan. Omdat die op de bon staan, moeten deze te reproduceren zijn, al is het maar als copie-factuur en/of voor de belastingdienst. Een aspect dat in de discussie tot zover onderbelicht is gebleven, maar waar men in de praktijk helaas te vaak mee te maken krijgt, zijn de omschrijving en prijs van een eenmalig (of kortlopend) artikel, waarbij dus het artikelnummer hergebruikt wordt voor iets totaal anders en de omschrijving en de prijs op het moment van verkoop ingevuld moeten worden. Voor dit soort zaken moet deze info dus in de database bewaard blijven. Dan is het veel eenvoudiger om deze info (inderdaad redundant) ook voor andere artikelen bij de bonregel op te slaan. Deze praktijk bewijst daarna vanzelf ook zijn voordelen bij verkoop vanuit een buitenlandse vestiging met centrale opslag. De omschrijving moet dan dus in een andere taal terwijl het om hetzelfde artikel gaat. Hieruit volgt dus ook dat het soms nuttig kan zijn om niet alleen de prijs, maar ook de munteenheid in de bonregels op te nemen.

[ACM]

dusty schreef op dinsdag 30 november 2004 @ 16:29:
Dat was dus niet zo bedoeld. Maar er zijn redelijk veel documenten over normaliseren te vinden. En heb al vaker vertelt wat de 4e en 5e normaal vorm inhoud.

Lees die documenten dan zelf ook nog even door
Want de 4e en 5e normaalvormen zijn stappen verder in het normaliseren, ipv stappen terug tov de 3e. Jan Klaassen heeft al wat quotes geplaatst.

De 5e normaalvorm is geloof ik tot het extreme, waarbij elke waarde apart in een tabel met primary key wordt opgenomen en alleen via de primary key/foreign key-koppelingen aan andere waardes gekoppeld mag worden.

[djluc]

waarbij dus het artikelnummer hergebruikt

In theorie is dit een bad-practice imo. Het artikelnummer kan je zien als een primary key en zou dus nooit meer mogen veranderen wat je eigenlijk wel doet als je een *ander* artikel het nummer geeft. Oplossing voor dit probleem: het artikelnummer apart opslaan en een extra veld: actief. Je zorgt er vervolgens voor dat er altijd maar 1 product is met hetzelfde artikelnummer wat actief is.

Maargoed: zorg er gewoon voor dat je ze niet hergebruikt, het nut hiervan ontgaat me ook een beetje eerlijk gezegd.

[Verwijderd]

djluc schreef op dinsdag 30 november 2004 @ 23:08:
[...]
Maargoed: zorg er gewoon voor dat je ze niet hergebruikt, het nut hiervan ontgaat me ook een beetje eerlijk gezegd.

Sommige zaken hebben niet alle artikelen in de database staan, dan is het handig als je een artikel met een bepaald artikelnr (b.v. artikel 9999) kan 'hergebruiken' om deze losse artikelen in te voeren in de 'kassa' tijdens de verkoop actie.

Dit heb ik zelf ook al eens toegepast op verzoek v/d winkelier. Verder kan deze leverancier gewoon per orderregel alles 'overriden' wat uit de standaard artikel tabel komt, dus prijzen, kortingen & omschrijvingen (niet artikelnr ).
Standaard kan dit alleen met vooringesteld artikelnr (9999), maar met een druk op de knop is dit in principe voor ieder artikel mogelijk.

Stel ik zou een historische tabel gaan bijhouden van artikel 9999, dat wordt dus een grote zooi, omdat artikel 9999 vanalles kan zijn. Van een complete uitlaat tot een ventieldopje. Dus iedere orderregel heeft netjes z'n eigen gegevens bij zich (prijs, omschr etc.).

[ Voor 38% gewijzigd door Verwijderd op 30-11-2004 23:18 ]

[Delphi32]

djluc schreef op dinsdag 30 november 2004 @ 23:08:
[...]
In theorie is dit een bad-practice imo. Het artikelnummer kan je zien als een primary key en zou dus nooit meer mogen veranderen wat je eigenlijk wel doet als je een *ander* artikel het nummer geeft. [...]
Maargoed: zorg er gewoon voor dat je ze niet hergebruikt, het nut hiervan ontgaat me ook een beetje eerlijk gezegd.

Ik heb een paar bezwaren tegen deze redenering:
1 Primary key is een database-gerelateerd begrip en bestaat niet in de belevingswereld van de gebruikers. Die gebruikers willen gewoon een eenvoudig te onthouden nummertje. Dat je dat nummer eventueel ook zou kunnen gebruiken als primary key is leuk maar voor de gebruiker niet interessant.
2 Ik heb deze constructie (1 nummer voor alle actie-artikelen) al zo vaak voorbij zien komen dat ik liever zou willen stellen dat het nut van iedere keer een ander nummer gebruiken mij ontgaat. Blijkbaar wérkt het hergebruik van het nummer in de ogen van de gebruiker
3 Het feit dat gebruikers betekenis hechten aan een bepaald nummer, betekent mijns inziens juist dat dit veld niet geschikt is om als primary key te dienen.

Om nog wat bij te dragen aan de oplossing voor TS: eigenlijk is het heel simpel. Je wilt de bon later nog kunnen reproduceren (dat ben je ongeveer verplicht). Helaas betekent dit dat je alle informatie die op de bon komt te staan, in je bongegevens zult moeten kopiëren. Elke foreign key die je in die bon zou gebruiken, zou kunnen verwijzen naar een record dat later gewijzigd wordt waardoor de oorspronkelijke bon niet meer reproduceerbaar is.

[Freee!!]

djluc schreef op dinsdag 30 november 2004 @ 23:08:
[...]
In theorie is dit een bad-practice imo.

Niet alleen in jouw opinie, maar dit is dus een typsich verschil tussen theorie en praktijk. Naast de verder aangevoerde argumenten voor een gemakkelijk te onthouden nummer voor een actie-artikel zit je ook nog met het puur praktische probleem van een beperkt aantal posities voor het artikelnummer, zeker als dit met de hand ingegeven moet worden.

[djluc]

Kan iemand me nu vertellen wat nu echt een voordeel is van het hergebruiken van een artikelnummer, behalve dat het voor problemen zorgt?

@delphi32: we zijn volgens mij nog niet op het niveau van de eindgebruiker. De eindgebruiker zal nooit weten hoe wij zin gegevens opslaan. Ik blijf bij mijn standpunt dat je de primary ID, waarmee je dus artikelen aan bonnetjes koppelt in mijn voorbeeld, nooit te nimmer aan mag passen.

Verder vraag ik me af waarom je producten onder 9999 zou willen afboeken aangezien je voorraad e.d. in 1x niet meer klopt.

[Verwijderd]

djluc schreef op woensdag 01 december 2004 @ 13:42:
Kan iemand me nu vertellen wat nu echt een voordeel is van het hergebruiken van een artikelnummer, behalve dat het voor problemen zorgt?

@delphi32: we zijn volgens mij nog niet op het niveau van de eindgebruiker. De eindgebruiker zal nooit weten hoe wij zin gegevens opslaan. Ik blijf bij mijn standpunt dat je de primary ID, waarmee je dus artikelen aan bonnetjes koppelt in mijn voorbeeld, nooit te nimmer aan mag passen.

Verder vraag ik me af waarom je producten onder 9999 zou willen afboeken aangezien je voorraad e.d. in 1x niet meer klopt.

Deze bepaalde 'klant' heeft z'n voorraad beheer niet aan de kassa gekoppeld. Waarom, tsja eigenwijs (heb 'm er meerdere malen opgewezen) ....