Ontstaan van dubbele waarde

[NoellaG]

T_Echt_bedrijf lijkt me eerder een één op veel relatie: in het echt zullen er wel meer exemplaren van het treinmodel hebben rondgereden? Ik zou daar dus een 1 op veel relatie van maken. Als er maar één record is, geen probleem. Als er geen record is, dan maak je dat record niet. Zeker geen lege records aanmaken. Voor je queries: gewoon een outer join leggen.

De select distinct [Kleur]... moet in de RowSource (sorry, ik heb een Engelse versie van Access) eigenschap van de keuzelijst staan, waar nu T_Kleur staat.
Als je de kleuren alfabetisch wil ordenen komt daar nog order by Kleur by:
select distinct [Kleur] from [T_materieel] order by [Kleur]

In het relatievenster kan je één tabel meerdere keren in het venster slepen en gebruiken om te linken. Om een duidelijk plaatje te houden maakt het programma dan een tweede, derde kopie van de tabel met de _1, _2 aanduiding. Dat is steeds dezelfde tabel, maar er wordt in de tekening een kopie getoond.

 

[OctaFish]

Over het afdwingen via referentiële integriteit denk ik alleen aan de drie hoofdtabellen. Echter de tabel T_Echt_bedrijf zal niet voor alle records gelden, ik heb deze nu wel 1 op 1 gemaakt maar dat zou niet hoeven daar staan dan veel ongebruikte records in of zou ik dit zo laten?

Een slecht idee; sowieso moet je nooit (je hebt ze echt maar zelden nodig) één-op'-één relaties leggen, de meeste relaties zijn op basis van Hoofdtabel met tabel met meervoudige gegevens. Leg op alle tabellen dus de juiste relaties, dit om te voorkomen dat je onzin in tabellen kan opslaan. Dat wil je echt niet.

Keuzelijsten kun je maken op basis van Waarden (zelf ingetypt), of een tabel. In dat geval heb je dus een aparte tabel nodig om (in dit geval) de kleuren op te slaan.

Gebruik (bij voorkeur) géén keuzelijsten in tabellen; gebruik daar dus alleen tekstvelden of keuzelijsten op basis van waarden. Iedereen die je vertelt dat je in een tabel best een keuzelijst mag gebruiken op basis van een tabel moet je wantrouwen . Waarom? Omdat je in een tabel te allen tijde de opgeslagen waarden wilt zien. Bij een keuzelijst is die verborgen, en zie je de omschrijving. Maar daarmee kom je dus geheid in de problemen. Gebruik Keuzelijsten (met invoervak) dus alleen op formulieren.

De hoeveeldheid gegevens die je in tabellen opslaat doet verder niet zoveel ter zake. Neem het voorbeeld van een postcodetabel met het hele land erin opgeslagen. In de tabel Klanten gebruik je die tabel om het juiste adres te vinden voor een klant. Dan heb je in de tabel Postcode dus duizenden records, terwijl je er maar een paar honderd (als je een paar honderd klanten hebt) gebruikt. Idem voor een tabel Artikelen: daarin zet je alle artikelen die je hebt, maar in de tabel Verkoopregels zet je alleen maar de verkochte artikelen. Je brontabellen bevatten dus altijd alle records, terwijl de datatabellen de (gerelateerde) verwijzingen naar die brontabellen bevatten.

Dus als jij een tabel hebt met alle treinmerken, en je begint je tabel Materieel met het eerste record, dan staat daar maar één verwijzing naar het treinmerk. Ook al heb je er dus veel meer.

Als je meer wilt weten van het hoe, wat en waarom van databases (en dat lijkt me, gezien je vragen niet overbodig) lees dan ook de Access cursus in de Handleidingen sectie. Dan krijg je wellicht wat meer inzicht in waarom we bepaalde zaken doen in een database.

En wat noella zegt over Outer joins: niet doen; ik zie geen enkele noodzaak op dit moment om die te gebruiken. Jij wel?

 

[OctaFish]

... kan je dat met een gewone relatie doen zonder verdere controles

Dit moet je toch eens uitleggen. Dit soort relaties heeft TS nu dus in zijn database gelegd, en die zijn, zoals ik al heb aangetoond volkomen waardeloos. Relaties in Access zijn bijzonder belangrijk om te voorkomen dat je onzinnige en onbruikbare gegevens opslaat in je datatabellen. Dat moet je echt (willen) voorkomen. Dus in mijn optiek: leg waar mogelijk de juiste relaties, zorg ervoor dat de tabellen dus de juiste gegevens bevatten met de juiste gegevenstypes, en je database werkt een stuk veiliger en beter. En gebruik Outer joins als je je nodig hebt. Bij voorkeur dus in een query, niet in de tabellen relaties.

 

[Auke van Wieren]

Ik heb tussen T_Materieel en T_Echt_bedrijf een referentiële integriteit kunnen leggen. Tussen T_Materieel en T_Verzekering_Financieel nog niet. Aan deze tabel hangt alleen de verkoper deze krijgt geen referentiële integriteit want ik weet niet alle verkopers.
Aan T_Materieel heb ik Keuzelijsten met invoervak hangen: T_Materieel_Type, T_Materieel_codering, T_Maatschappij, T_Fabrikanten, T_Assen, T_Afbeeldingen_model. Moeten voor deze tabellen ook relaties gelegd worden? Hebben deze ook te maken met een referentiële integriteit?

 

[xps351]

Aan deze tabel hangt alleen de verkoper deze krijgt geen referentiële integriteit want ik weet niet alle verkopers.

Dat is geen reden. Als je de verkoper wel invult, dan moet die voorkomen in de tabel verkopers. Als de verkoper leeg blijft overtreedt je de referentiële integriteit niet.

Zie verder eerdere opmerkingen (o.a. #29) over het nut van T_Verzekering_Financieel als tabel met een 1-op-1 relatie. Ook de relatie met T_Echt_bedrijf is dubieus.

Moeten voor deze tabellen ook relaties gelegd worden? Hebben deze ook te maken met een referentiële integriteit?

Ja. Overal waar je een keuze maakt uit een andere tabel moet je een relatie leggen met afgedwongen referentiële integriteit. Zoals @OctaFish herhaaldelijk heeft uitgelegd heeft zo'n "opzoektabel" anders geen nut. Zonder relatie met referentiële integriteit zou je in kunnen vullen wat je wilt. Met een relatie met referentiële integriteit mag je alleen waardes uit de gerelateerde tabel kiezen (of het veld leeg laten dus).

 

[OctaFish]

Aan deze tabel hangt alleen de verkoper deze krijgt geen referentiële integriteit want ik weet niet alle verkopers.

Je snapt het concept zo te zien nog steeds niet. Dus nog maar een keer uitleggen dan .
RI zorgt ervoor dat je in een tabel geen niet-bestaande gegevens mag invoeren. Oftewel: in t_Materieel mag je géén verkoper gegevens invullen die niet bestaan in t_Verzekering. That’s it. Dát is de regel. RI zegt niets over of je een verkoper moet invullen of niet. Daarvoor heb je in de tabel t_Materieel de eigenschap <Verplicht>. Maar dat heeft dus niets met RI te maken.

Nogmaals: leg zoveel mogelijk relaties met RI, daarmee voorkom je lelijke fouten. Als je géén RI kunt afdwingen, dan zitten er fouten in je tabel. Dan heb je dus al een record ingevoerd in t_Materieel dat níet bestaat in t_Verzekering.

 

[Auke van Wieren]

Bedankt voor jullie geduld, soms moet mij het kwartje even vallen. Ik denk af en toe ook te moeilijk.

Ik ga eraan werken.

Groet Auke

 

[Auke van Wieren]

Ik heb nu tussen alle tabellen RI staan. Dat was wel een dingetje. Heb dus nu alle fouten tussen de tabellen eruit gehaald c.q. verbeterd. En alle hebben een Inner Join type 1.,

Ik wil nu de methode om naar afbeeldingen toe te voegen bekijken. Zie #38

xps351: #29 De tabel Verzekering_financieel is bedoeld om de totale waarden van mijn verzameling te krijgen zodat ik die kan verzekeren. Ook daarin wil ik de aankoop gegevens bijhouden. Ik zou deze velden bij de tabel Materieel kunnen toevoegen, ik had er nu een aparte tabel van gemaakt om dit in de formulier zo te krijgen.
Voor het Echte bedrijf zie onder.
xps351: #30 Het komt voor dat van een model er meer kleuren uitvoeringen zijn maar de technische gegevens zijn van de echte loc dan het zelfde. Ik heb bv drie loc's die het zelfde zijn in drie verschillende kleuren en coderingen deze drie verwijst ik dan naar het zelfde record in de tabel T_Echt _bedrijf.

NoellaG: #41. Voor ieder model is er maar 1 echt exemplaar waarvan ik dan het beeldmateriaal en de technische gegevens gebruik.

Octafish: #42 Ik heb alle <Keuzelijsten met invulvak> uit de tabellen gehaald.

​

 

[xps351]

Ik zou deze velden bij de tabel Materieel kunnen toevoegen, ik had er nu een aparte tabel van gemaakt om dit in de formulier zo te krijgen.

Dat is geen geen (valide) reden. Er is een verschil tussen vastlegging (tabellen) en presentatie (formulieren en rapporten). Als de gegevens logisch gezien bij elkaar horen zet je ze in één tabel; je kan ze dan op een formulier nog steeds op verschillende tabbladen presenteren.

deze drie verwijst ik dan naar het zelfde record in de tabel T_Echt _bedrijf.

Klinkt goed. Het betekent wel dat je in de materieel tabel het sleutelveld van de tabel echt bedrijf moet opnemen. De materieel ID hoort dan niet in echt bedrijf. In de database was dat niet zo.

 

[xps351]

Nog even wat nabranders.

Ik zat nog even te filosoferen over het financiële verhaal en vroeg me af wat je doet als je zoiets koopt. Je hebt dan één aankoop (en 1 prijs, datum en verkoper) en 4 stuks materieel. Dat zou pleiten voor een tabel "aankoop" met een 1-op-veel relatie naar materieel.
Het verzekeringsdeel snap ik sowieso nog niet helemaal. Verzekerd tot zou in deze vorm alleen van toepassing zijn als je alles apart verzekert
Ik weet nog steeds niet of dat zo is.

Kleur is ook nog wel een dingetje. Er is denk ik heel wat materieel dat niet één bepaalde kleur heeft. Bij het Nederlandse materieel zie je bijvoorbeeld vaak de combinatie geel en blauw. Bij sprinters komt daar ook wit bij.
Hoe je dat oplost is mede afhankelijk van van de reden dat je de kleur(en) vast wilt leggen. Je kunt elke kleurcombinatie in de kleurentabel opnemen. Of je legt daar alleen enkelvoudige kleuren vast en maakt een koppeltabel tussen kleur en materieel. De relatie tussen kleur en materieel is nu immers veel-op-veel.

 

[NoellaG]

zoals ik reeds aangaf, als er op kleur niet gezocht wordt (zoals geef me alle rode locomotieven), dan is dat louter een informatieve tekstwaarde en is een zoektabel hiervoor onzin. Als je zonodig een combobox wil hebben om het typwerk te verminderen, maak dan een afrollijstje in een formulier op basis van de reeds bestaande waarden in het kleurenveld (select distinct ... als rijbron).

 

[Auke van Wieren]

Als de gegevens logisch gezien bij elkaar horen zet je ze in één tabel; je kan ze dan op een formulier nog steeds op verschillende tabbladen presenteren.

Ik heb nu dus tabellen met gegevens erin, die informatie wil ik behouden. Misschien kan ik nu deze wel samenvoegen.

Nog even wat nabranders.

Ik zat nog even te filosoferen over het financiële verhaal en vroeg me af wat je doet als je zoiets koopt. Je hebt dan één aankoop (en 1 prijs, datum en verkoper) en 4 stuks materieel. Dat zou pleiten voor een tabel "aankoop" met een 1-op-veel relatie naar materieel.

Elk stuk materieel heeft zijn eigen waarde. Zo koop ik ook tweedehands materieel op beurzen etc. daarvan is de verzamelwaarde van belang. Bij nieuwe aankoop is de catalogusprijs van belang en de datum van de toen gelden catalogus. Dus elk stuk materieel heeft zijn eigen record in T_Verzekering_financieel.

Het verzekeringsdeel snap ik sowieso nog niet helemaal. Verzekerd tot zou in deze vorm alleen van toepassing zijn als je alles apart verzekert

Ik wil de waarde van mijn complete verzameling weten, dit voor de inboedelverzekering.

Kleur is ook nog wel een dingetje. Er is denk ik heel wat materieel dat niet één bepaalde kleur heeft.

Bij maatschappijen hebben meestal standaard kleuren of een kleuren combinatie die veelvuldig voorkomen er zijn natuurlijk uitzonderingen.

Als je zo nodig een combobox wil hebben om het typewerk te verminderen, maak dan een afrollijstje in een formulier op basis van de reeds bestaande waarden in het kleurenveld (select distinct ... als rijbron).

Ik zou op mijn formulier liever een keuzelijst met invul vak willen hebben en de tabel kunnen uitbreiden. Dat is toch ook een goede oplossing?

 

[NoellaG]

Ik zou op mijn formulier liever een keuzelijst met invul vak willen hebben en de tabel kunnen uitbreiden. Dat is toch ook een goede oplossing?

Voor het gebruik van de keuzelijst in het formulier maakt het geen verschil als de gegevens uit dezelfde tabel komen, en in dat geval typ je gewoon een nieuwe waarde in het vak van de keuzelijst, en na een refresh of bij het volgende record is die nieuwe keuze gewoon toegevoegd. Eenvoudiger bij gebruik in het formulier en in de queries. Maar als je liever met een aparte tabel werkt geen probleem. Alleen moet je dan een PK veld aan de kleurentabel toevoegen (meestal een autonumber) en dit nummer dan in je materialentabel gebruiken in plaats van de kleur zelf.

 

[xps351]

elk stuk materieel heeft zijn eigen record in T_Verzekering_financieel.

Dan is het een 1-op-1 relatie en kan je de velden dus net zo goed in de materieeltabel opnemen. De vraag hoe je omgaat met de aankoop van een set materieel is daarmee nog niet beantwoord.

Ik wil de waarde van mijn complete verzameling weten, dit voor de inboedelverzekering.

Dat kan je nu inderdaad berekenen. Verzekerd tot hoort dan niet in de tabel. Het is een kenmerk van je inboedelverzekering. Als de datum verandert wil je die maar op één plek wijzigen. Je kunt je ook afvragen of je het überhaupt wilt vastleggen.

maatschappijen hebben meestal standaard kleuren of een kleuren combinatie die veelvuldig voorkomen er zijn natuurlijk uitzonderingen.

Dus???
Uitzonderingen moet je ook aankunnen.

 

[Auke van Wieren]

Ik heb de tabellen samengevoegd.

De vraag hoe je omgaat met de aankoop van een set materieel is daarmee nog niet beantwoord.

Als je een set koopt dan is dit ook 1 item in mijn database.

Dat kan je nu inderdaad berekenen. Verzekerd tot hoort dan niet in de tabel. Het is een kenmerk van je inboedelverzekering.

Je kunt dit toch berekenen met een query? En de uitkomst ergens inzetten. Mijn bedoeling is ook om een hoordformulier of een aanstuurformulier te maken waar je vanuit straks ook verschillende rapporten kunt afdrukken.

 

[xps351]

Als je een set koopt dan is dit ook 1 item in mijn database.

Benieuwd wat type materieel en assen dan wordt in het geval van het voorbeeldje dat ik gaf in post #50

Je kunt dit toch berekenen met een query?

Dat heb ik nooit ontkend

 

[Auke van Wieren]

Benieuwd wat type materieel en assen dan wordt in het geval van het voorbeeld je dat ik gaf in post #50

Je kunt een startset kopen waarin een loc en verschillende wagons en rails etc. bij zit. Dit omschrijf je dan bij opmerkingen wat erin zit. Verder vul ik dan geen assen of andere specificaties in. Nu heb ik in mijn verzameling geen startset. Ik heb wel enkel sets van rijtuigen die ook als zodanig zijn gemaakt mijn bezit die bij elkaar horen. Komt niet veel voor. Dus daar gaan we niet moeilijk mee doen.

 

[OctaFish]

Je kunt dit toch berekenen met een query? En de uitkomst ergens inzetten. Mijn bedoeling is ook om een hoordformulier of een aanstuurformulier te maken waar je vanuit straks ook verschillende rapporten kunt afdrukken.

Oef… Ik volg dit draadje regelmatig met licht gekromde tenen, maar dit is wel erg. Ja, berekeningen maak je in queries. Nee, die sla je niet op. Waarom zou je? Je hebt ze toch al berekend?
En rapporten zijn zelfstandige objecten die je baseert op tabellen en/of queries. Niet op formulieren. Wel is het zo dat je een formulier kunt gebruiken om een rapport te openen, af te drukken of te mailen. Wellicht bedoel je dat?

Wat betreft je database: ik wil deze week wel kijken of ik er een fatsoenlijke database van kan maken, gebaseerd op wat er zoal in dit draadje voorbij is gekomen. Maar ik raad je (nog steeds) sterk aan om je eerst eens te verdiepen in het ontwerpproces van een database, want ik mis nog noodzakelijke (en basale) inzichten. En dat werkt ook voor de helpers niet geweldig.

 

[Auke van Wieren]

Wel is het zo dat je een formulier kunt gebruiken om een rapport te openen, af te drukken of te mailen. Wellicht bedoel je dat?

Dat bedoel ik.

want ik mis nog noodzakelijke (en basale) inzichten

Ongetwijfeld zal ik bepaalde inzichten niet begrijpen, maar ik wil alleen zaken weten die mijn database werkbaar maakt.

Wat betreft je database: ik wil deze week wel kijken of ik er een fatsoenlijke database van kan maken, gebaseerd op wat er zoal in dit draadje voorbij is gekomen.

Als je dit wilt doen graag, ik zal de laatste uitgave toevoegen.

Treincollectie-AvW Versie 6.0 29-07.accdb

1 file sent via WeTransfer, the simplest way to send your files around the world

we.tl

 

[OctaFish]

Ongetwijfeld zal ik bepaalde inzichten niet begrijpen, maar ik wil alleen zaken weten die mijn database werkbaar maakt.

Was het maar zo simpel. Ik hoop dat je ooit een vak heb geleerd, en dat de opleiders nóóit tegen je hebben gezegd: “stop hier maar met leren, want meer heb je niet nodig.” Op zijn minst heb je de basiskennis nodig, en dat mis ik nog steeds . Op zijn minst zou je je moeten verdiepen in de eerste drie Normaal vormen. Zodat je weet welke gegevens in welke tabellen thuis horen.

Ik kijk vandaag uitgebreid naar de database!