3 tabellen, 2 relaties en toch krijg ik het niet voor elkaar! HELP

Status
Niet open voor verdere reacties.
D

dirkdrent

Gebruiker
Lid geworden
3 jan 2006
Berichten
382
Na nogmaals vele uren bezig te zijn geweest en het voorbeeld dat ik van iemand heb gekregen aangepast aan mijn eigen velden krijg ik de relaties niet goed voor elkaar.

Het gaat in mijn db maar om 3 tabellen klanten, orders en producten. Er zijn 2 (1 op veel) relaties gelegd namelijk

1. Klant-ID met het veld bestelling in de tabel orders
2. Productnummer (is sleutelveld met autonummering) met het veld Productnummer in tabel orders

Het resultaat is teleurstellend en ik krijg het niet voor elkaar de gegevens goed te tonen en te onthouden in het formulier Orders Subformulier en Orders invoeren.

Het zal een kleinigheid zijn maar ik wordt er helemaal gestoord van.... Veel tijd om uit te zoeken hoe access werkt en nog steeds loop ik tegen dezelfde dingen aan RELATIES, RELATIES en RELATIES. btw thuis heb ik wel een goede relatie :)

In de bijlage een voorbeeld van mijn database Bekijk bijlage test orders.zip en een schermafbeelding
 

Bijlagen

  • Relaties.png
    Relaties.png
    55,4 KB · Weergaven: 74
Wat is precies het probleem? Op basis van je tabellen zie ik wel een stevige bok op de weg liggen; in je tabel orders kun je namelijk per order maar één product bestellen. Dat lijkt mij niet handig, want nu moet je voor elk product een nieuwe bestelling maken. Mij lijkt het logisch om er een extra tabel bij te maken voor de OrderRegels. Die tabel koppel je dan aan Orders, en daar koppel je dan de producten aan.
 
Ik zou eerst eens kijken naar de huidige relaties die je hebt gemaakt alvorens te overwegen er een tabel bij te maken. Je relatie tussen de tabel klanten en orders klopt van geen meter. Bij mij komt eerder het advies boven drijven om je eerst de basiskennis van access eigen te maken alvorens je begint aan het maken van een tabelstructuur.

Op deze site is bij de handleidingen een hele goede cursus te vinden waarmee je je de basiskennis eigen kunt maken. Zie onderstaande link.

http://handleiding.helpmij.nl/

Als je die hebt doorgenomen, zul je zien dat er niet veel klopt van waarmee je nu bezig bent. Zo zet ik ook heel veel vraagtekens bij de inhoud van je tabel klanten. Veel velden in deze tabel horen daar volgens mij niet.

Als je iets meer wilt weten over relaties, kun je ook kijken op onderstaande link. Daar vind je een cursus Access 2010 en in de lessen 17, 18 en 19 staat heel veel over relaties.

http://www.gratiscursus.be/access_2010/index.html
 
Laatst bewerkt:
Bedankt, heb wel verschillende cursussen gedaan via internet maar deze kon ik nog niet. Loop voornamelijk tegen de relaties aan expressies en dergelijk daar red ik mij prima mee en aanmaken rapportjes en dergelijke. Ik ben afhankelijk van de gegevens die ik binnen krijg gezien ik een webshop heb krijg ik (wanneer er een bestelling is geplaatst) de volgende 2 bestandjes als bijlage in mijn mail box vandaar dat ik niet alle mogelijkheden heb om zelf de input van de gegevens te regelen.

Op basis hiervan heb ik geprobeerd een database te maken. De bestanden heb ik nu even voor het gemak in een excel bestand gezet maar officieel komen deze als txt bestand binnen die ik vervolgens koppel aan access en vanuit hier met een query de gegevens er uithaal die ik denk nodig te hebben.

Dit zijn de 2 bestanden bestaande uit "customer" en "order_details"
 

Bijlagen

In de cursus op HelpMij wordt het principe van bestellingen als voorbeeld gebruikt en uitgelegd, dus daar zou ik inderdaad eerst eens induiken. Wat gast0224 zegt over de tabel Klanten is natuurlijk volkomen terecht; daar horen geen bestelgegevens in thuis. Eerlijk gezegd had ik daar niet eens goed naar gekeken, en zag ik gelijk dat je tabel Orders niet deugt. Vandaar mijn advies om daar een tabel bij te maken. Die is overigens noodzakelijk, ook al zegt gast0224:
gast0224 zei:
Ik zou eerst eens kijken naar de huidige relaties die je hebt gemaakt alvorens te overwegen er een tabel bij te maken.
Klik om te vergroten...
Dat moet dus echt wel. Maar de relatie tussen Klanten en Orders is op zich perfect; daar hoef je niks aan te doen. Maar Bestelgegevens opslaan in de tabel Klanten? Hoe kom je op dat idee? In de cursus leg ik uit dat je tabellen moet maken op basis van gegevens die bij elkaar horen. En Bestelgegevens horen niet bij een klant, maar bij een bestelling. De afhankelijkheid kan dus alleen geregeld worden als je een tabel Orderregels maakt. Het had zelfs al beter geweest (nog steeds fout overigens) als je in Orders een aantal blokken voor Artikel1, Artikel2 etc. had opgenomen. Dan hadden we ook gezegd dat de tabel fout was, en dat je die moest opsplitsen.
 
Laatst bewerkt:
Octafish jullie hebben gelijk maar ik heb me laten leiden door de gegevens of wel bijlagen zoals ik deze via de mail binnen krijg. Vanuit hier dacht ik elke klant is een nieuwe klant die elke keer1bestelling plaats waarbij elke bestelling weer bestaat uit de te bestellen producten (productnummers). Voor deze methode heb ik gekozen omdat elke klant zijn gegevens weer opnieuw moet invullen en de kans op fouten hierdoor groot is. De ene keer besteld iemand met zijn voornaam en de keer daarop met zijn achternaam vanuit hier is het lastig om een klanten tabel bij te houden. Vandaar dat ik had gekozen voor bestelling en bestellinbestellingdetails. Is op basis hiervan de database wel te maken?
 
Ik weet niet hoe de input gegevens er verder uit zien; ik vermoed dat je de gegevens vanuit Excel krijgt aangeleverd? Zo ja: wordt dat dan wel vanuit een basis sjabloon gemaakt? In Excel is het een stuk makkelijker om alles in één rij te zetten, dus de klantgegevens en bestelgegevens. Zo'n bestand moet je op de juiste manier vertalen naar eigen tabellen, iets wat je dus niet optimaal hebt gedaan. Als je een goede db hebt, zullen de externe gegevens met de bestellingsgegevens importeerbaar moeten zijn. Dat betekent, dat er in iedere rij in ieder geval gegevens moeten zitten die je kunt koppelen. Dus in plaats van de klantgegevens moet er een KlantID gebruikt worden. Op basis van die KlantID kun je dan een order maken voor een klant.
Krijg je steeds nieuwe klanten, dan wordt het al een stuk lastiger, want dan heb je een heel traject nodig:
1. Klant importeren in je Klantentabel
2. Producten importeren in je Productentabel (als het product tenminste nog niet bestaat)
3. Ordergegevens importeren in Orders, en de KlantID daaraan koppelen
4. Orderregel records aanmaken op basis van OrderID en ProductID

En dat is nog maar de basis van het verhaal. Wil je dit goed geregeld hebben, dan moeten de klanten die hun orders mailen dat doen omdat ze van jou de gegevens krijgen die zij gebruiken om bestellingen aan te maken op basis waarvan jij de import kan uitvoeren.
 
In mijn vorige post heb ik in de bijlage de 2 bestanden die ik krijg aangeleverd vanuit de website. De opmaak en de gegevens zijn altijd identiek omdat bij het plaatsen van een bestelling een aantal Velden ingevuld moeten worden. Dit bestelformulier is voor mij niet aan te passen. Kan ik met de 2 bestanden die ik krijg aangeleverd zie bijlage datgene doen wat u aangeeft muv stap 2 ALLE bestelde producten staan in de tabel wat stap 2 overbodig maakt.
 
Als ik de 2 txt bestanden koppel met access kan ik wel de tabellen aanmaken in acces en deze daarna via toevoegen query gegevens in de tabellen krijgen. Daar ligt niet het probleem het probleem ligt welke Velden zet ik in welke tabel?
 
OctaFish zei:
In de cursus op HelpMij wordt het principe van bestellingen als voorbeeld gebruikt en uitgelegd, dus daar zou ik inderdaad eerst eens induiken. Wat gast0224 zegt over de tabel Klanten is natuurlijk volkomen terecht; daar horen geen bestelgegevens in thuis. Eerlijk gezegd had ik daar niet eens goed naar gekeken, en zag ik gelijk dat je tabel Orders niet deugt. Vandaar mijn advies om daar een tabel bij te maken. Die is overigens noodzakelijk, ook al zegt gast0224:
Dat moet dus echt wel. Maar de relatie tussen Klanten en Orders is op zich perfect; daar hoef je niks aan te doen. Maar Bestelgegevens opslaan in de tabel Klanten? Hoe kom je op dat idee? In de cursus leg ik uit dat je tabellen moet maken op basis van gegevens die bij elkaar horen. En Bestelgegevens horen niet bij een klant, maar bij een bestelling. De afhankelijkheid kan dus alleen geregeld worden als je een tabel Orderregels maakt. Het had zelfs al beter geweest (nog steeds fout overigens) als je in Orders een aantal blokken voor Artikel1, Artikel2 etc. had opgenomen. Dan hadden we ook gezegd dat de tabel fout was, en dat je die moest opsplitsen.
Klik om te vergroten...
Heb je mij horen zeggen dat het niet moet dan? Er staat dacht ik Alvorens.... Of heb je daar ook al niet goed naar gekeken.

Een relatie die gelegd is tussen de tabel Klanten en Orders met het veld KlantID koppelen aan het veld Bestellingen moet je mij eens uitleggen. Deze manier van een relatie leggen ken ik nog niet.
 
Laatst bewerkt:
@gast0224: beetje gepikeerde reactie; lijkt mij nu ook weer niet nodig. En dan het hele berichtje quooten? ook een beetje overdreven...
In beginsel is de koppeling tussen Klanten en Orders perfect. Dat het veld KlantID in Orders [Bestellingen] is genoemd, maakt voor Access niet uit, al heet het veld [ik heb vandaag geen zin om op te staan], de relatie zal blijven werken. Kortom: de relatie deugt. En daar gaat het om, lijkt mij.
 
Laatst bewerkt:
Als ik verkeerd geciteerd wordt, vind ik dat inderdaad vervelend. Heb je overigens naar de inhoud van het veld bestellingen gekeken? Volgens mij heeft dat geen enkele relatie tot het KlantID veld en is het een op zichzelf staand bestelnummer.

Wat maakt het uit dat ik je hele bericht Quoot? Zo lang was je bericht tocht niet.
 
Laatst bewerkt:
Klant-ID heeft in deze geen functie omdat dit gewoon een nummer is die (enigzins) verplicht wordt gesteld vanuit access dus elke keer als ik een nieuwe bestelling toevoeg aan de tabel klant dan vult de klant-id dit aan.

Het veld bestelling komt zowel in de tabel klant naar voren als in de tabel orders en dit wordt aangeleverd vanuit de webshop. Dit is volgens mij de unieke code waarmee je de bestelling kunt koppelen aan de productnummers die horen bij de bestelling. Vandaar dat ik dit veld (bestellingen) als relatie heb aangemaakt. Evenals het productnummer dat in de aangeleverde tabel order staat, deze staat immers ook in de tabel producten die ik vast in mijn database heb staan.
 
Relaties.png

Even je plaatje van de 1e posting bijgevoegd. Volgens dit plaatje leg je een relatie tussen Klanten.KlantID en Orders.Bestelling en dat heeft geen enkele zin, omdat dat 2 los van elkaar staande velden zijn. Als je een relatie legt tussen Klanten.Bestelling en Orders.Bestelling, dan leg je wel een relatie tussen 2 velden die iets gemeen hebben. Maar dat kan dan weer niet, omdat het nu geen unieke velden zijn. Maak je er wel unieke velden van, dan pakt de relatie alsnog verkeerd uit. Dan krijg je hetzelfde probleem, wat je nu hebt met je tabellen Orders en Product Catalogus GKD nl. een verkeerde 1 op veel relatie.

Mijn keuze zou zijn om in de tabel Orders een veld Klanten (numeriek), of hoe je het veld ook wilt noemen, toevoegen en deze koppelen aan het veld KlantID van de tabel Klanten. Maar wellicht zegt OctaFish dat je het moet laten zoals het nu is, want de huidige relatie is volgens hem prima.
 
Laatst bewerkt:
Als ik in de huidige situatie datgene zoals ik dat bovenstaand heb beschreven de klanten.bestelling koppel aan de order.bestelling dan betekend dit dat in ieder geval de bestelling wordt weergegeven in order en dat hij dit koppelt met de gegevens in klanten? Maar wat is deze relatie dan een 1 op 1 of een 1 op meerdere want 1 op meerdere wordt niet geaccepteerd of wel de referentiële integriteit.
 
Laatst bewerkt:
@gast0224: 'hele bericht' was een lichte overdrijving van mij, maar dat je met de quoot voor de prijs van 'langste quoot van de dag' meestrijd lijkt mij duidelijk, en zo'n quoot is in mijn ogen niet er zinvol. Bovendien zeg je letterlijk:
gast0224 zei:
Je relatie tussen de tabel klanten en orders klopt van geen meter.
Klik om te vergroten...
En dat is dus niet helemaal terecht. Tenminste: als TS de tabel Klanten ook gebruikt waarvoor hij bedoeld is (klantinformatie bijhouden) dan is er niks mis met de relatie. Al zou ik het veld [Bestellingen] in Orders dan KlantID noemen. TS geeft nu aan dat KlantID geen KlantID is, en eigenlijk helemaal niks voorstelt. Dan moet dat veld natuurlijk helemaal weg. Eigenlijk is de tabel Klanten een tabel Bestellingen, meer precies BestelRegels als er in elke record één product zou zitten. wat dan ook weer niet het geval is. Kortom: één grote chaos eigenlijk.... En daardoor kijken we met z'n allen dus nèt even anders naar de tabellen en naar de functie ervan. Wat dan toch een paar misverstandjes oproept :)
 
Ja en daar blijf ik bij. De relatie zoals die nu is aangemaakt deugd van geen kant. Het veld Bestelling in de tabel orders is een Bestelnummer en geen klantID. Heb je de database wel bekeken en dan bedoel ik de inhoud van wat er in de tabellen staat. Er is nu in de database 1 KlantID nl nummer 2. De beide bestelnummers in de tabel Orders is 1 nummer nl 140031635411. Hoe leg jij de relatie tussen deze 2 nummers?

Overigens de opmerkingen van TS over het klantID die geen functie zouden hebben, geeft al aan hoe het met zijn basiskennis is. Daar heb ik het in mijn 1e posting al over gehad. Dat de tabel Klanten bedoeld zou zijn, zoals jij aangeeft, een tabel voor bestelregels dat betwijfel ik.
 
Laatst bewerkt:
@gast0224:Ik heb gewoon een hekel aan al dat nodeloze qequoot; hou teksten kort en simpel. Doe je iedereen een plezier mee. We zagen gewoon verschillende dingen: jij ziet een tabel Bestellingen met daarin klantgegevens die daar niet horen, ik zag een tabel Klanten waar dan geen bestelgegevens in horen.
On topic: De tabel Orders is eigenlijk de tabel OrderDetails, en de tabel Klanten kun je makkelijk ombouwen naar een tabel Orders, of een tabel Klanten. Zelf denk ik: als iemand een tabel Klanten noemt, en daarin een veld KlantID opneemt, dan lijkt mij de bedoeling van die tabel reteduidelijk: hij wil die tabel voor Klanten gaan gebruiken. Een tabel Orders zou dan de ordergegevens moeten bevatten. In die tabel moet Bestelnummer dan een sleutelveld zijn, en die tabel mag geen artikelen bevatten. In mijn eerste post gaf ik dat dan ook aan: er moet een tabel OrderRegels bijkomen die is gekoppeld aan Orders en Producten. Eigenlijk moet TS dus een nieuwe tabel Orders maken, en de huidige tabel hernoemen, dan komt-ie al een heel eind. Is allemaal bepaald geen rocket science. Dat de huidige gegevens op de verkeerde plaats staan in de tabel Klanten, vind ik niet eens zo interessant; kwestie van overzetten naar de juiste tabel. Als die er eenmaal is.
 
Waar haal je de onzin vandaan, dat ik een tabel Bestellingen zie met klantgegevens? Ik heb alleen gezegd dat er geen relatie mogelijk is tussen een KlantID (Tabel Klanten) en een Besteling (Bestelnummer in tabel Orders). Zie mijn posting van 17:03 uur met mijn advies hoe ik de relatie zou leggen tussen de klantentabel en de ordertabel. Hoezo tabel Bestellingen?
 
Laatst bewerkt:
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan