Stamboom query/rapport maken

Status
Niet open voor verdere reacties.
D

DinoMuis

Gebruiker
Lid geworden
21 jan 2014
Berichten
17
Hoe maak ik een stamboom in access?

Ik heb voor mijn mousery (muizen fokkerij) een bestand met allerlei info die ik nodig heb voor de administratie, maar een cruciaal deel ontbreekt, namelijk een stamboom (ja dit is ook belangrijk bij muizen :P ). Nu ben ik er al wel achter dat dit voor de gevorderde access gebruiker is, maar het is best vervelend dat ik een apart programma moet hebben om de stambomen te maken, aangezien ik dan alle info van mijn database opnieuw moet ingeven in het andere programma. En elke keer manueel de stamboom opmaken is ook vermoeiend omdat ik dan steeds in aparte tabellen moet gaan zoeken.

Momenteel heb ik een rapport met de ouders per muis; tabel muis bevat de naam van de muis (primaire sleutel) en zijn nestnummer (met een hoop andere info) en tabel koppels bevat het nestnummer (primaire sleutel) en de naam van het mannetje (vader) en vrouwtje (moeder) (samen met de verwachte resultaten van het nest en de koppeldatum enzo). Dit werkt prima, 2 tabellen koppelen via nestnummer en ik zie per muis wie zijn vader en moeder is.
Er is hier echter al probleem nr 1; zodra een muis niet meer in mijn bezit is word die verwijderd uit de tabel muis en toegevoegd aan de tabel exmuizen (die extra info bevat zoals de datum dat het dier uit mijn bezit ging en waarom). Dit doe ik om de muizen die niet meer in mijn bezit zijn niet in de tabel muis weer te geven, anders word het te onoverzichtelijk voor mij. Ik ben er zeker van dat er een betere manier bestaat, maar die ken ik dan nog niet.
Dus mijn rapport met ouders per muis is niet compleet als ik wil weten wie de ouders waren van een muis die niet meer in mijn bezit is.....
Hiervoor zou ik gewoon een 2de rapport kunnen maken, maar als ik uiteindelijk een query/rapport wil met een volledige stamboom, dus inclusief de muizen die ik niet meer heb, gaat dit niet lukken denk ik.

Mijn uiteindelijke doel is dus een rapport te hebben dat eigenlijk gewoon een stamboom weergeeft met ouders-gootouders-overgrootouders per muis.
Maar probleem nr 2 is dat ik niet weet hoe ik de tabellen onderling moet linken en dan nog eens zo dat de query het juist weergeeft. Een simpele query met enkele tabellen via de 'query wizard' lukt mij nog, maar ik heb het 'QBE grid' nog niet onder de knie en meerdere levels 'self-joins' word zeker een probleem.
 
DinoMuis zei:
Ik ben er zeker van dat er een betere manier bestaat, maar die ken ik dan nog niet.
Klik om te vergroten...
Ik zou de ex-muizen zeker niet overbrengen naar een andere tabel, maar een extra veldje gebruiken met een keuzelijst en de waarden <Actief> en <Vertrokken> of zoiets. Dan blijft alles werken. In je onderhoudstabellen filter je dan op actieve muizen, zodat je de vertrokken exemplaren wel hebt, maar niet meer ziet. En in je rapportages staan ze dan wel.
 
Dat ik daar zelf niet aan dacht :P Ik heb een aanvinkvakje toegevoegd en kan daar nu dus inderdaad op filteren :) Thx!

Tips voor een stamboom query? :)
 
Dan moet je een kopietje (uiteraard zonder privé gegevens van de muizen :) ) posten, dan kan ik zien hoe je hem gemaakt hebt.
 
Het grapje kwam niet helemaal over; normaal gesproken zal het een muis een worst weten als we zijn/haar leeftijd weten :). Er moeten natuurlijk wel gegevens in de db zitten, maar dat zouden dan best dummy gegevens mogen zijn. Het gaat er maar om dat de essentie van de db te bekijken is, zodat we ook een stukje stamboom kunnnen reproduceren.
 
Ah zo :P

Ik krijg het bestand niet geüpload, het is te groot... (gekopieerd als gecomprimeerde map)
 
Je kunt de db altijd posten op een site als www.mijnbestand.nl waar we hem dan vanaf kunnen halen.
 
Hij is prima te lezen, maar helemaal snappen doe ik de db nog niet. Je hebt een tabel Koppels met [Nestnaam] als sleutelveld. Dat zou ik al niet doen, een tekstveld als sleutel, maar alla, dat kan nog. Die tabel heb je echter gekoppeld aan de tabel [Nesten] met hetzelfde sleutelveld! Dat de relaties die je gelegd hebt geen <Referentiële Integriteit> hebben komt wellicht doordat het een snel gemaakte kopie is, maar in jouw db is die ook niet af te dwingen, omdat de gegevens al niet kloppen. Zou dat wél het geval zijn, dan had je een één-op-één koppeling gehad, en in dit geval zouden beide tabellen dus gewoon samengevoegd kunnen worden in 1 tabel. Dus waarom de splitsing?
Dan de tabel [Muizen] met ook een tekstveld als sleutel. (Nogmaals: beter om een nummer te gebruiken). Deze tabel is gekoppeld aan de tabel [Koppels] op basis van het veld [Nestnaam]. Dat snap ik ook niet: één muis kan nooit in meerdere koppels zitten en dus meerdere vaders en moeders hebben. Of werkt dat bij muizen anders?
In de tabel [Nesten] heb je een veld [#Jongen] wat een tekstveld is. Lijkt mij niet handig, want het aantal nakomelingen is toch altijd een getal? Nu heb je er +20 in staan, maar dat lijkt mij de integriteit van je gegevens onderuit halen. Waarom niet het exacte aantal?
In de tabel [Gewichten] heb je een veld [Datum]. Lijkt mij prima, want ik vermoed dat dit de meetdatum is. Maar waarom staat er dan een veld Leeftijd bij? Je meet muizen waarvan je de geboortedatum weet (neem ik aan) en dan weet je dus ook op de seconde nauwkeurig als het moet hoe oud ze waren op het moment van wegen. Hoef je dus niet op te slaan. En al helemaal niet op de manier waarop je het doet, die niet genormaliseerd is. Maar nogmaals: dat veld kan weg.
Verder mis ik in de tabel [Muizen] twee velden die verwijzen naar de Ouder. Dat is namelijk de makkelijkste manier om per muis vast te leggen wie de ouders zijn. Elke muis heeft namelijk precies één vader en één moeder. En sla je dat in Muizen op, dan kun je ook je stamboom maken.
 
Ok klinkt logisch allemaal (als ik het juist snap).

Even wat uitleg dan;

Om te beginnen krijgt elke muis een naam en die naam mag geen 2de keer meer voorkomen in de tabel [Muizen], dus dacht ik dat het ok was om dat het sleutelveld te maken, aangezien ik dan ook een foutmelding krijg als ik toch per ongeluk een naam een 2de keer zou gebruiken (ik herinner me echt niet alle namen die ik al ooit gebruikt heb).

Voor elke muis staat er een veld [Nestnaam] bij om weer te geven uit welk nest hij/zij komt. Ik kan begrijpen dat het voor andere makkelijker lijkt om gewoon vader en moeder te gebruiken, maar voor mij is dit handiger. Maar als het belangrijk is voor de stamboom te kunnen maken dan zal ik dat zeker veranderen. Maar dit is een hele aanpassing zeker, aangezien ik veel dingen aan elkaar gekoppeld heb via nestnaam?
Verder snap ik deze opmerking niet;
Deze tabel is gekoppeld aan de tabel [Koppels] op basis van het veld [Nestnaam]. Dat snap ik ook niet: één muis kan nooit in meerdere koppels zitten en dus meerdere vaders en moeders hebben. Of werkt dat bij muizen anders?
Klik om te vergroten...

Ook elk nestnaam is uniek en mag geen 2de keer voorkomen en heb dit dus om dezelfde reden als bij de naam van de muizen als sleutelveld gemaakt. Het is inderdaad niet handig meer om de tabel [Koppels] en [Nesten] niet als 1 te hebben, dit is nog van toen ik nog geen queries en rapporten kon maken en het mij anders een te grote tabel werd :P Dit zal ik dan ook meteen veranderen :)

Het veld [# jongen] is om aan te geven van hoeveel jongen de muis bevallen is. Dit is niet altijd gelijk aan het aantal dat over blijft aangezien het vaak bij muizen voorkomt dat ze door stress ofzo een deel van hun eigen jongen opeten. Ik weet dus ook niet altijd zeker of dat aantal heel juist is aangezien ik de eerste dagen niet aan het nest mag komen en het is dan ook vaak een gok wanneer ik snel even gekeken heb. Zoals in het geval van die +20 was het dus niet juist te zeggen hoeveel het er waren, alleen dat het er zeker meer waren dan 20. Het is wel belangrijk om dit bij te houden, ook al kunnen de gegevens niet altijd exact weergegeven worden. Toch veranderen naar getal voor dat veld dan?

Het veld [Leeftijd] in de tabel [Gewichten] is voor mij gewoon handig om een snel overzicht te hebben aangezien ik de geboortedatum van elke muis niet van buiten ken (ik ben sowieso een persoon die niets kan onthouden...). Het was ook de bedoeling dat Access dat veld zelf voor me zou gaan berekenen. Wat bedoel je met 'niet genormaliseerd'?

Bedankt alvast voor die uitleg OctaFish, ik heb toch nog heel wat bij te leren (maar dat wist ik al wel :P ). Het bestand is ook nog in volle ontwikkeling, lang niet af. Ik ben nog maar net aan het leren hoe ik queries enzo maak, ik ben over het algemeen niet zo'n kei in deze dingen. Ik had eerst al mijn info in Excel staan, maar dat werd mij te onoverzichtelijk met al die tabbladen.

Nog een kleine vraag; was wat aan het experimenteren om bij te leren, maar het lukt niet. Wat is er mis met deze formule in mijn query voor een nieuw te berekenen veld?
3M: IIf([3maanden]<=date(),"Y","N")
Ik krijg namelijk deze foutmelding;
You omitted an operand or operator, you entered an invalid character or comma, or you entered text without surrounding it with quotation marks.
Klik om te vergroten...
 
Laatst bewerkt:
Als je de formule rechtstreeks uit je queryveld hebt gehaald, dan kan het zijn dat je de puntkomma moet gebruiken; dat is doorgaans standaard en niet de komma.
Als je de tabel Nesten wilt blijven gebruiken, kun je nog steeds wel een stamboom maken, denk ik, maar ik zou toch numerieke velden als sleutel gaan gebruiken. Als een naam maar één keer voor mag komen, maak er dan een unieke index van in je tabel. Dan ben je er ook. Geldt uiteraard voor alle velden. Met name dus voor velden die je gebruikt om te koppelen met andere tabellen: hou die numeriek. Scheelt enorm in de opslagruimte.
Als je verder niet rekent met het aantal jongen, dan kun je wel een tekstveld blijven gebruiken. Gebruiksnut staat natuurlijk boven tabelinrichting, die moet het doel ondersteunen en niet andersom.
Maar leeftijd moet echt weg, want dat bereken je heel simpel in een query :). Niet genormaliseerd zei ik, omdat je de leeftijd vrij willekeurig kan intypen; er is geen controle op syntax. Nog een reden dus om het zo niet te doen.
 
Je database die je hebt gepost heeft nog een stevig probleem: de tabel Muizen bevat muizen met een niet-bestaande of ontbrekende Nestnaam. Ik zou als buitenstaander zeggen: dat zou niet moeten mogen.
 
Hoe los ik dit op? Muizen die ik kocht van een andere fokker hebben geen nestnaam bij mij en ik heb ook geen gegevens (of weinig) over hun (voor)ouders.

Ben al eens begonnen met aan een query te werken voor een stamboom en ik denk dat hij gelukt is :D Nu moet ik nog de juiste layout goed krijgen bij het rapport en dan heb ik het ^^
 
Het gaat juist om muizen die wél een nestnaam hebben, zoals Chekesha die nestnaam AA101 heeft, die dus niet in jouw tabel [Koppels en nesten] staat. Je kunt de relatie tussen de twee tabellen zodanig instellen dat hij in [Koppels en nesten] lege records toestaat, maar je mag nooit in Muizen een nestnummer opslaan dat niet bestaat in [Koppels en nesten]. Dat is <Referentiële Integriteit>, en dat is onmisbaar in relaties tussen tabellen. Als dat niet mogelijk is, kun je net zo goed het veld [#Jongen] koppelen aan het veld [Kleur]. Net zo onzinnig en fout, maar net zo makkelijk te koppelen.
 
Zo, ik heb nog wat aan mijn database gesleuteld (en een hoop bijgeleerd), want er zitten inderdaad wat fouten in. Ze zijn er nog niet helemaal uit, maar ben er nog druk mee bezig :)
Wel goed nieuws; ik heb mijn eerste goede kladversie van de stamboomquery af :D Ik heb hiervoor wel in de tabel [Muizen] 2 velden bijgemaakt, namelijk [Vader] en [Moeder], anders werd het mij toch wel te ingewikkeld :P Het lukt mij nog niet om met de wizard een rapport te maken, ik denk dat ik te veel velden heb?

http://www.mijnbestand.nl/Bestand-6L3LLLXGMV6S.accdb
 
Ik zou in dit geval de wizard ook niet gebruiken, omdat die niet overweg kan met de layout die je nodig hebt. Maar volgens mij heb je zelf al een rapport gemaakt dat een aardig eind in de buurt komt (Stamboom Achterkant).
Maar je query ziet er verder goed uit, al zou ik de aliassen van de tabellen veel korter maken. Dus vvv voor [Vaders vader vader] en mvm voor [Moeders vader moeder]. Scheelt ook enorm in het verwijzen naar de tabellen.
 
Inderdaad, de wizard raakte maar halverwege, maar ik heb er een eerste werkende versie van kunnen maken door er erna zelf de ontbrekende velden aan toe te voegen. Ik zat wel even vast toen ik velden moest bijvoegen en ik het label niet onafhankelijk van het tekstvak kon bewegen :P Ik los dat nu maar op door knippen en plakken...
Tot nu toe is het mij nog niet gelukt zonder de wizard, maar ik snap steeds meer en meer, dus ik denk dat ik het binnenkort wel onder de knie krijg om van scratch te beginnen :D

Bedankt OctaFish voor al je hulp! Fijn dat er eens iemand met kennis naar mijn bestand heeft kunnen kijken en mij op mijn fouten kan wijzen :thumb:
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan