Database structuur samenvoegen

[BladeSlayer1000]

Hallo alle,

Ten eerste laat ik beginnen met te zeggen, dat ik twijfel of dit de goede plaats is. Indien dit niet het geval is sorry daarvoor.

Ik ben momenteel bezig om een systeem te maken om de bestellingen van mijn werk makkelijk te overzien. Ik doe dit met behulp van Microsoft Access. Nou loop ik bij het volgende probleem aan.

Ik heb 4 tabbelen bestaande uit:


De tabel namen zijn opzich redelijk duidelijk. Met EmployeeStatus houd ik bij of de medewerker met pension is of niet.

In de tabel CustomersT komen de gegevens van de klant te staan, bij ProductOrderT de producten die de klant besteld. EmployeeT staan de gegevens van de medewerker in die de bestelling plaatst. En ik zat te denken om OrderT te gebruiken als een tabel om de 3 andere tabellen samen te voegen.

Nou zit ik met het probleem, dat als een klant meerdere producten bestelt, er meerdere records komen in OrderT van dezelfde klant, terwijl ik dit graag op het eind in 1 report wil hebben.

Daarnaast moet het voor de klant ook mogelijk zijn om meerdere producten te bestellen, op diverse tijden, en dezelfde dagen.

Nou is mijn vraag, hoe kan ik dit het beste aanpakken? En hoe zit het met relaties. Ik heb diverse tutorials bekeken, webpagina's opgezocht etc. maar het blijft mij onduidelijk hoe de relaties in Microsoft Access nou werken. Kan iemand dit uitleggen?


Edit: Ik heb een veld OrderDate en OrderTime toegevoegd aan de tabel OrderT.

[Miks]

Ik heb weinig kaas van access gegeten, maar toch even een paar tips.

Ten eerste zou ik de tabellen een andere naam geven. Gewoon meervoud van wat erin komt, dus Customers, Employees, Orders en OrderProducts.

Als je in OrderProducts een veld OrderID ingeeft, dan zijn deze gekoppeld. Dan kan je dus per Order meerdere OrderProducts hebben. Dan kan je met een query alle OrderProducts weergeven die een OrderID delen, oftewel in mensentaal, zo krijg je alle producten die in een order zijn opgenomen.

Wil je niet ook een tabel met Products? Dan kan je zorgen dat je alleen producten in een order krijgt die al bekend zijn. Op die manier kan je dan later weer kijken hoeveel van een bepaald product zijn verkocht (namelijk alle OrderProducts die een bepaald ProductID hebben).

[NMe]

Laat dit exacte probleem nou het schoolvoorbeeld zijn van een many to many-relatie in zo'n beetje elk lesboek over databases. http://www.tomjewett.com/...ign.php?page=manymany.php

[ Voor 20% gewijzigd door NMe op 01-02-2015 15:57 ]

[BladeSlayer1000]

Ik heb het advies van Miks opgevolgd. Ik heb de link van NMe doorgelezen, en heb daarbij het volgende gedaan:



Is dit correct?

[DukeBox]

Ik snap de toegevoegde warde van OrderID niet in OrderProducts. Deze is al uniek in Orders en daarmee gekoppeld via ProductOrderID in OrderProducts. Je ziet het al terug in je plaatje, een dubbele koppeling met 2 tabellen is overbodig wanneer er een key aanwezig is.

[NMe]

Maak je even geen zorgen over de velden, kijk voor nu alleen naar de tabellen. Je hebt producten, klanten en medewerkers. Een medewerker kan voor een klant een order opnemen. Een order kan meerdere regels bevatten die elk een product bevatten, inclusief een vermelding van hoeveel van dat product je klant wil bestellen.

Om dat te bereiken heb je dus nodig: een ordertabel die verwijst naar de klant die de order plaatste en naar de medewerker die de order verwerkte. Verder een tabel met orderregels die verwijst naar de producttabel. Teken dat eerst eens uit, mag je je daarna zorgen gaan maken over welke velden je nu eigenlijk in welke tabel kwijt moet. Als je eenmaal dat raamwerk hebt gaat dat namelijk véél makkelijker.

[P_Tingen]

Als je de tabel OrderProducts hernoemt naar "OrderLines" wordt het wellicht wat duidelijker. Je moet dan nog wel een tabel toevoegen met productinformatie, dus tabel "Product". De tabel "Orders" heeft een 1:n relatie met "OrderLines" (dus 1 order kan meerdere orderlines hebben). De tabel "OrderLines" heeft een n:1 relatie met "Products" (dus 1 orderline kan maar aan 1 product gekoppeld zijn, maar datzelfde product kan wel in meerdere orderlines voorkomen).

Zoiets:

[ Voor 7% gewijzigd door P_Tingen op 01-02-2015 18:41 ]

[BladeSlayer1000]

Hallo alle,

Dit is eigenlijk de eerste keer dat ik zelf een database (in dit geval met ms access tables) ga maken (ik heb altijd databases gebruikt die kwamen van den bestaande tutorial, of cms ). Sorry als ik nogal beginners vragen stel.

@NMe, ik begrijp uw verhaal over een raamwerk niet. Wat ik eruit haal, is dat ik eerst voor mijzelf moet afvragen en kijken wat ik wil gaan opslaan en daarop de tabellen inrichten (in dit geval klantgegevens, bestellingen, gegevens van de medewerker, en producten die we hebben). Daarna moet ik nadenken wat er voor velden moeten komen (product naam, product bestelnummer, klant telefoonnummer, klant naam etc).
Als ik dat allemaal heb bepaald moet ik de relaties gaan leggen met de tabellen waarna ik over kan gaan naar de volgende stap.

@P_Tingen, wat bedoelt u met 1:n? Dat er 1 relatie bestaat met tabel A en tabel B?

[NMe]

Jordy.T schreef op zondag 01 februari 2015 @ 19:53:
Als ik dat allemaal heb bepaald moet ik de relaties gaan leggen met de tabellen waarna ik over kan gaan naar de volgende stap.

Klinkt alsof je het wel begrepen hebt. Eerst kijken welke entiteiten je hebt. Die verwerk je vervolgens in een datamodel. Daarna ga je je velden toevoegen aan die entiteiten. En daarna kun je gaan normaliseren om te zorgen dat je niet onnodig redundante informatie opslaat.

@P_Tingen, wat bedoelt u met 1:n? Dat er 1 relatie bestaat met tabel A en tabel B?

Een op meer, een bepaald type relatie. Een product kan op meerdere orderregels staan, maar elke orderregel kan maar één product hebben.

Het blijkt dat het je ontbreekt aan een stukje basiskennis. Dat is niet erg, maar in dat geval heb je veel meer baat bij een goed boek voor beginners over databases dan wanneer je op basis van wat reacties hier en een handvol bij elkaar gegraaide tutorials gaat aankloten tot het werkt. Ik kan je alleen maar aanraden zo'n boek op te zoeken en er je voordeel mee te doen.

[technorabilia]

En gebruik enkelvoud. Order, orderid etc.

[BladeSlayer1000]

NMe schreef op zondag 01 februari 2015 @ 20:47:
[...]

Klinkt alsof je het wel begrepen hebt. Eerst kijken welke entiteiten je hebt. Die verwerk je vervolgens in een datamodel. Daarna ga je je velden toevoegen aan die entiteiten. En daarna kun je gaan normaliseren om te zorgen dat je niet onnodig redundante informatie opslaat.


[...]

Een op meer, een bepaald type relatie. Een product kan op meerdere orderregels staan, maar elke orderregel kan maar één product hebben.

Het blijkt dat het je ontbreekt aan een stukje basiskennis. Dat is niet erg, maar in dat geval heb je veel meer baat bij een goed boek voor beginners over databases dan wanneer je op basis van wat reacties hier en een handvol bij elkaar gegraaide tutorials gaat aankloten tot het werkt. Ik kan je alleen maar aanraden zo'n boek op te zoeken en er je voordeel mee te doen.

Bedankt voor de tip, ikzelf merkte het ookal . Vandaar dat ik erbij vermelde dat dit de eerste keer is dat ik echt een database zelf maak ipv dat ik er een gebruik van een bestaand iets. Ik ga dit advies zeker opvolgen en eens kijken naar een boek.

[Caelorum]

Orderlines koppelen aan product is wellicht niet zo'n geweldig idee. Dat zorgt er namelijk voor dat je nooit producten kan verwijderen uit je database of later aanpassen zonder dat je nog lopende orders aanpast. Daarnaast vernaggel je op die manier ook de hele historie. Beter is het IMO om alle info van de order gewoon apart op te slaan en compleet los te koppelen van je huidige assortiment.
Dat geld ook voor de gegevens van de klant. Je wilt niet dat je ordergeschiedenis verandert als de klant bijv. een adreswijziging doorgeeft.

[ Voor 15% gewijzigd door Caelorum op 01-02-2015 22:28 ]

[Miks]

kraades schreef op zondag 01 februari 2015 @ 21:11:
En gebruik enkelvoud. Order, orderid etc.

Enkelvoud of meervoud is meer een mening dan een conventie in mijn ogen. Beter ook niet de discussie hierover beginnen, maar Jordy mag alvast weten dat het één niet te prefereren is boven het ander.

Caelorum schreef op zondag 01 februari 2015 @ 22:27:
Orderlines koppelen aan product is wellicht niet zo'n geweldig idee. Dat zorgt er namelijk voor dat je nooit producten kan verwijderen uit je database of later aanpassen zonder dat je nog lopende orders aanpast. Daarnaast vernaggel je op die manier ook de hele historie. Beter is het IMO om alle info van de order gewoon apart op te slaan en compleet los te koppelen van je huidige assortiment.
Dat geld ook voor de gegevens van de klant. Je wilt niet dat je ordergeschiedenis verandert als de klant bijv. een adreswijziging doorgeeft.

alvast rekening houden met de toekomst is ook niet verkeerd inderdaad.

[Tom-my]

Caelorum schreef op zondag 01 februari 2015 @ 22:27:
Orderlines koppelen aan product is wellicht niet zo'n geweldig idee. Dat zorgt er namelijk voor dat je nooit producten kan verwijderen uit je database of later aanpassen zonder dat je nog lopende orders aanpast. Daarnaast vernaggel je op die manier ook de hele historie. Beter is het IMO om alle info van de order gewoon apart op te slaan en compleet los te koppelen van je huidige assortiment.
Dat geld ook voor de gegevens van de klant. Je wilt niet dat je ordergeschiedenis verandert als de klant bijv. een adreswijziging doorgeeft.

Je kan je producten hoogstwaarschijnlijk nooit meer verwijderen als ze verkocht zijn, je zit dan immers historische data weg te gooien, maar over het algemeen is daar niets mis mee. Een database kan normaliter aardig wat info hebben (eh ja access, geen idee waar daar de bottleneck zit). Er zijn genoeg manieren om dit soort producten uit te filteren.

Ik zou zelf je orders los houden, idem je orderregels, en eigenlijk zodra een order echt verkocht is, hier een extra tabel voor in het leven roepen dat eigenlijk een copy kan zijn van je order informatie. Laten we het factuur noemen. Zodat je informatie voor een eventuele history nooit hoeft te wijzigen. Kan je -desnoods- ook je producten en orders weggooien, maar nogmaals, waarom zou je.

Overigens, ander dingetje, als je tabel al producten heet, noem dan niet expliciet alles in je tabel dan ook met prefix producten 9 van de 10 keer zit je daardoor veel te veel informatie in te typen (op de id velden na, die zijn erg handig met een naam als ProductId).

[Caelorum]

@tom-my, zelfs als je nooit iets wilt verwijderen wil je het hoogstwaarschijnlijk wel ooit eens aanpassen. Kopiëren naar een factuurtabel is wellicht nog beter dan order loskoppelen, maar dat ligt maar een beetje aan je definitie. Voor mij is een order een order en geen winkelmandje. Daar is dus gewoon al een overeenkomst over tussen partijen en een factuur is iets dat dan al dan niet al bestaat. Dan wil je niets veranderen aan de order als je het huidige assortiment aanpast.

Overigens ben ik voorstander van het schoonhouden van de database. Zelfs als het weinig impact heeft op de performance is het onderhoudtechnisch gewoon een ramp om veel vervuilde data te hebben. Probleem is dat je daar in het begin geen last van hebt, maar het pas na een paar jaar merkt en dan begint de lol hoor

[P_Tingen]

De discussie over het bewust niet koppelen van producten aan orderregels is volgens mij op dit moment alleen maar verwarrend voor TS. Het klopt dat je factuurinformatie niet-genormaliseerd wil opslaan maar dat is een uitzondering en kun je beter later proberen te bevatten, nadat je de basisregels snapt. Dan snap je namelijk ook precies waarom je er soms van moet afwijken.

Normaal gesproken wil je juist dat er een link ligt tussen producten en OrderRegels. Het argument dat je daarna nooit producten kan verwijderen omdat ze nog voorkomen in de tabel OrderRegel is juist de kracht van een relationeel model. Het heet "referentiële integriteit". Want hoe zie je het voor je als je zonder problemen een product kan verwijderen dat nog voorkomt in de tabel OrderRegel? Omdat je in OrderRegel alleen een verwijzing opneemt naar product heb je een verwijzing die niet meer geldig is. Op dat moment heb je dus een data-corruptie. En een probleem, want je kunt dan niet meer achterhalen wat het product überhaupt was.

De voor de hand liggende oplossing hiervoor is om dan de complete informatie van een product (dus omschrijving en producent bijvoorbeeld) op te nemen in de tabel OrderRegel. Klinkt leuk, totdat de naam van het product een beetje verandert. Je moet dan niet alleen de product-tabel aanpassen, maar ook alle records in de OrderRegel tabel waarin dit product vermeld staat. Als je dan ook werkelijk alles aanpast is er geen vuiltje aan de lucht, maar als je er nou een paar vergeet heb je een en hetzelfde product met verschillende omschrijvingen in je systeem. Dit wil je niet en het is ook precies de reden waarom je alleen het ID van product opneemt in OrderRegel.

Op de site helpmij.nl staat een handig artikel dat het normaliseren op een Access database uitlegt. (deel 1 is hier en de hele cursus hier). Omdat jij ook op een Access database werkt is dit wellicht handig leesvoer.

[ Voor 3% gewijzigd door P_Tingen op 02-02-2015 20:02 ]

[Caelorum]

P_Tingen schreef op maandag 02 februari 2015 @ 20:00:
[...] De voor de hand liggende oplossing hiervoor is om dan de complete informatie van een product (dus omschrijving en producent bijvoorbeeld) op te nemen in de tabel OrderRegel. Klinkt leuk, totdat de naam van het product een beetje verandert. Je moet dan niet alleen de product-tabel aanpassen, maar ook alle records in de OrderRegel tabel waarin dit product vermeld staat.[...]

Nee, dat wil je juist niet. Je wilt hooguit voor elk product de historie van het product opslaan en dan verwijzen naar een specifiek punt in de tijd (in de historie dus). Je wilt en mag vaak niet een overeenkomst eenzijdig aanpassen. Referentiele integriteit is leuk, maar je mist daar het woordje temporeel voor referentieel.

[...]Dit wil je niet en het is ook precies de reden waarom je alleen het ID van product opneemt in OrderRegel.[...]

Om vervolgens elk aspect van tijd overboord te gooien. Dat is wellicht leuk als het je niet boeit of je een inaccuraat of gewoonweg compleet verkeerd beeld krijgt van wat er in het verleden is gebeurt, maar veelal wil je dat dus niet.
In dit geval vraagt de TS er volgens mij zelfs om:

[...]
Ik ben momenteel bezig om een systeem te maken om de bestellingen van mijn werk makkelijk te overzien.[..]

Dat klinkt alsof hij wel met zekerheid wil weten wat er precies is besteld in het verleden (of zelfs welke bestelling er precies komt in de toekomst).

[ Voor 30% gewijzigd door Caelorum op 02-02-2015 20:38 ]

[NMe]

Ik ben het met je eens, Caelorum, maar laten we die discussie niet voeren in een topic van een beginner die eerst nog moet leren normaliseren voordat hij iets met denormalisatie gaat doen.

[BladeSlayer1000]

Hallo alle,

Wat leuk en intressant om te zien dat er een discussie is gestart in dit topic

Helaas snap ik van de helft nog niets haha

Ik heb eens rondgekeken en kwam bij dit boek uit;https://m.bol.com/nl/p/da...5CFFS4JSMIZMW-47243956653 heeft iemand ervaring met dit boek, en zit er alle informatie in om de basis te leren? Of hebben jullie een ervaring met een ander boek? Het mag tenslotte ook een website, pdf of dergelijke zijn. Ik hoor het graag.

[P_Tingen]

Caelorum schreef op maandag 02 februari 2015 @ 20:33:
[...]
Nee, dat wil je juist niet. Je wilt hooguit voor elk product de historie van het product opslaan en dan verwijzen naar een specifiek punt in de tijd (in de historie dus). Je wilt en mag vaak niet een overeenkomst eenzijdig aanpassen. Referentiele integriteit is leuk, maar je mist daar het woordje temporeel voor referentieel.

[...]

Om vervolgens elk aspect van tijd overboord te gooien. Dat is wellicht leuk als het je niet boeit of je een inaccuraat of gewoonweg compleet verkeerd beeld krijgt van wat er in het verleden is gebeurt, maar veelal wil je dat dus niet.
In dit geval vraagt de TS er volgens mij zelfs om:

[...]

Dat klinkt alsof hij wel met zekerheid wil weten wat er precies is besteld in het verleden (of zelfs welke bestelling er precies komt in de toekomst).

Mind you, als je tijd mee wil modelleren kan dat behoorlijk complex worden. In de meeste administratieve systemen wordt het dan ook daarom maar gewoon grotendeels genegeerd. In een aantal gevallen wil je het wel weten en dan is de aanpak die jij voorstelt prima. Maar ook die is niet 100% dekkend. Je hebt dan namelijk wel vastgelegd wanneer iets ingaat, maar niet wanneer het bekend is in het systeem. Vorig jaar heb ik in een thread onderstaand voorbeeld gebruikt:

Horrorscenario.

1 februari	ik koop bij jou een konijnenhok. Volgens jouw systeem is mijn adres "Brink 14"
10 februari	Ik ontdek dat er iets mis is met het hok en bel met de winkel. En passant geef ik door dat het adres op mijn bon niet klopt, want ik ben op 1 januari verhuisd naar "Dorpsstraat 8". Jij vertelt mij dat je het aanpast.
14 februari	Er is echt iets mis met het hok en ik kom het ruilen.

Welk adres komt er nu op de bon?

Als ik op 10 februari bel, maak jij een adreswijziging voor mij aan en je zet in het systeem dat ik per 1-1 ben verhuisd. Probleem is alleen dat als je op 14-2 een bon van mij uitprint, daar niet hetzelfde adres opstaat als op 1-2.

Ziehier het probleem in een notedop. Je moet - als je het goed wil doen - niet alleen een datum in je systeem opnemen waarop de wijziging ingaat, maar ook een datum waarop het voor het systeem bekend is. Vervolgens heb je dus allerlei mogelijkheden met deze twee datums, want zoals bovenstaand voorbeeld laat zien kan de ingangsdatum zowel voor als na de weet-datum liggen.

Goed, dit wordt veel te ingewikkeld voor TS. Laat hem nou eerst eens inlezen in de normalisatietheorie. Ik heb trouwens het boek van Kroenke gelezen voor mijn opleiding. Ik geloof niet dat ik het erg lekker leesbaar vond.

[technorabilia]

In de basis zijn er eigenlijk maar een paar dingen die je moet weten.

Een Order bestaat uit meerdere Orderregels.
1 op N of 1:N relatie. Dus je neemt de sleutel van Order op in Orderregel.
Een Product kan in meerdere Orderregels voorkomen.
1:N relatie. Dus je neemt de sleutel van Product op in OrderRegel.
Een Customer kan meerdere Orders plaatsen.
1:N relatie. Dus je neemt de sleutel van Customer op in Order.

Daarnaast heb je nog een N:M relatie.
Stel dat je een tabel Leverancier hebt.
Een Leverancier levert Producten en Producten kunnen door meerdere Leveranciers worden geleverd.
Er komt dan een zogenaamde aparte koppeltabel bij waarin je de sleutel van Leverancier en Product opneemt.

Product
A
B
C

Leverancier
1
2
3

Koppel
A 1
A 2
B 1

Product A wordt geleverd door Leverancier 1 en 2.
Product B door Leverancier 1.
Product C wordt door geen enkele Leverancier geleverd.
Leverancier 3 levert geen producten.

[ Voor 5% gewijzigd door technorabilia op 03-02-2015 09:50 ]