Discussion:
Keuzelijst afhankelijk van voorgaande keuzelijst
(te oud om op te antwoorden)
jeremy
2007-08-14 18:42:01 UTC
Permalink
-- Ik heb de verschillende threads over dit onderwerp reeds grondig gelezen
en geprobeerd maar ik kom er niet uit. Waar zit ik fout?
Ik wil de mogelijkheid hebben om met de database te werken zowel via het
formulier als via de tabel. (misschien ligt daar al een probleem: nl is het
gebruikelijk om met dit type van database, nl flat file, ook in tabelvorm te
gebruiken? Graag uw mening)
Mijn formulier telt oa 5 velden waarvan de tweede afhankelijk moet zijn van
de keuze van veld 1, de 3de van de 2de,enz.
Ik snap de redenering in de vorige threads maar ik bots al op 1 probleem: nl
in kolom 1 heb je heel veel dubbele gegevens, in kolom 2 een beetje minder,
etc en tenslotte kolom 5 bevat unieke gegevens.
De dubbele gegevens verdwijnen via de component "Group By" in een query maar
dan verdwijnt ook de ID. ( Doe ik hier al iets fout?) Hetzelfde doe je dan
met de 4 andere kolommen. In de basistabel maak je 5 velden met als
gegevenstype een Combo via de wizzard. Je voegt de 5 velden in je formulier
en dan pas je de gebeurtenisprocedure aan. Klopt dit tot zover een beetje?
(als het tenminste duidelijk genoeg is)
Wie kan mij bijsturen? Of verduidelijken. Ik snap niet hoe je de uitkomst
van elk veld kan linken aan het volgende en dit zonder een ID. Hoe gaat dit
in zijn werk?
Jeremy
XPS35
2007-08-14 20:09:54 UTC
Permalink
Post by jeremy
-- Ik heb de verschillende threads over dit onderwerp reeds grondig gelezen
en geprobeerd maar ik kom er niet uit. Waar zit ik fout?
Ik wil de mogelijkheid hebben om met de database te werken zowel via het
formulier als via de tabel. (misschien ligt daar al een probleem: nl is het
gebruikelijk om met dit type van database, nl flat file, ook in tabelvorm te
gebruiken? Graag uw mening)
Mijn formulier telt oa 5 velden waarvan de tweede afhankelijk moet zijn van
de keuze van veld 1, de 3de van de 2de,enz.
Ik snap de redenering in de vorige threads maar ik bots al op 1 probleem: nl
in kolom 1 heb je heel veel dubbele gegevens, in kolom 2 een beetje minder,
etc en tenslotte kolom 5 bevat unieke gegevens.
De dubbele gegevens verdwijnen via de component "Group By" in een query maar
dan verdwijnt ook de ID. ( Doe ik hier al iets fout?) Hetzelfde doe je dan
met de 4 andere kolommen. In de basistabel maak je 5 velden met als
gegevenstype een Combo via de wizzard. Je voegt de 5 velden in je formulier
en dan pas je de gebeurtenisprocedure aan. Klopt dit tot zover een beetje?
(als het tenminste duidelijk genoeg is)
Wie kan mij bijsturen? Of verduidelijken. Ik snap niet hoe je de uitkomst
van elk veld kan linken aan het volgende en dit zonder een ID. Hoe gaat dit
in zijn werk?
Jeremy
Je kan dit sowieso alleen via ee formulier doen omdat de oplossing
gebaseerd is op het werken met gebeurtenissen en die kan je alleen aan
formuliervelden koppelen.

Verder snap ik je uitleg niet goed. Bijvoorbeeld:
- Wat bedoel je met het type database flat file?
- Een (unieke?) ID die verdwijnt bij een group by?

Geef in ieder geval meer details over welke tabellen je hebt.

Peter
jeremy
2007-08-15 07:56:01 UTC
Permalink
dag Peter,
alvast bedankt voor je reactie, laat ik proberen om wat duidelijker te zijn.

Ik heb 1 basistabel gemaakt met een 20-tal velden, van verschillende types,
die ik in mijn 1 formulier nodig heb ( flat file: alle gegevens staan in 1
tabel).
Van deze velden zijn er die via een keuzelijst gegevens uit andere tabellen
oproept (vb Landen, Gemeenten) om gemakkelijker nieuwe gegevens toe te
voegen.
5 Velden nl Rijk, Stam, Orde, Klasse en Geslacht wil ik aan elkaar linken
(Er is nog een 6de veld nl Soort maar die laat ik buiten beschouwing)
De gegevens van deze 5 velden worden via een keuzelijst uit de tabel
tblRijkCompleet gehaald.

Het veld Rijk in het formulier bied mij 3 mogelijkheden, Plantae, Animalia
en Protista. De keuze "Plantae" moet mij in het veld Stam enkel de planten
geven, hetzelfde principe voor de andere 4 velden.

Ik maak 1 query van de tblRijkCompleet, met daarin ID, Rijk, Stam, Klasse,
Orde en Geslacht, zonder criteria, naam vb QueryRijkCompleet.
Maar wat nu? Aangezien de tabel RijkCompleet al zo'n 600 records bevat
tellen de kolommen Rijk, Stam, enz veel dubbele gegevens. Met welke opdracht,
haal ik de dubbele gegevens eruit? Group By?
Je kan dit sowieso alleen via ee formulier doen omdat de oplossing
gebaseerd is op het werken met gebeurtenissen en die kan je alleen aan
formuliervelden koppelen.
Ok, dit snap ik. Is het dan zo dat alle velden in een formulier waar ik een
gebeurtenisprocedure op toepas, deze wijzigingen niet gaat overnemen in mijn
basistabel? Of hangt dit af van het type van procedure? (Ik heb nl al een
gebeurtenisprocedure geprobeerd en de tabel neemt dit over.)
Dus als ik het goed snap kan het zijn dat mijn basistabel niet alle gegevens
zal weergeven zoals deze in de formulieren weergegeven worden en kan ik de
basistabel best niet gebruiken voor nieuwe records toe te voegen?
Groetjes
XPS35
2007-08-15 11:42:11 UTC
Permalink
Post by jeremy
dag Peter,
alvast bedankt voor je reactie, laat ik proberen om wat duidelijker te zijn.
Ik heb 1 basistabel gemaakt met een 20-tal velden, van verschillende types,
die ik in mijn 1 formulier nodig heb ( flat file: alle gegevens staan in 1
tabel).
Van deze velden zijn er die via een keuzelijst gegevens uit andere tabellen
oproept (vb Landen, Gemeenten) om gemakkelijker nieuwe gegevens toe te
voegen.
5 Velden nl Rijk, Stam, Orde, Klasse en Geslacht wil ik aan elkaar linken
(Er is nog een 6de veld nl Soort maar die laat ik buiten beschouwing)
De gegevens van deze 5 velden worden via een keuzelijst uit de tabel
tblRijkCompleet gehaald.
Het veld Rijk in het formulier bied mij 3 mogelijkheden, Plantae, Animalia
en Protista. De keuze "Plantae" moet mij in het veld Stam enkel de planten
geven, hetzelfde principe voor de andere 4 velden.
Ik maak 1 query van de tblRijkCompleet, met daarin ID, Rijk, Stam, Klasse,
Orde en Geslacht, zonder criteria, naam vb QueryRijkCompleet.
Maar wat nu? Aangezien de tabel RijkCompleet al zo'n 600 records bevat
tellen de kolommen Rijk, Stam, enz veel dubbele gegevens. Met welke opdracht,
haal ik de dubbele gegevens eruit? Group By?
Je kan dit sowieso alleen via ee formulier doen omdat de oplossing
gebaseerd is op het werken met gebeurtenissen en die kan je alleen aan
formuliervelden koppelen.
Ok, dit snap ik. Is het dan zo dat alle velden in een formulier waar ik een
gebeurtenisprocedure op toepas, deze wijzigingen niet gaat overnemen in mijn
basistabel? Of hangt dit af van het type van procedure? (Ik heb nl al een
gebeurtenisprocedure geprobeerd en de tabel neemt dit over.)
Dus als ik het goed snap kan het zijn dat mijn basistabel niet alle gegevens
zal weergeven zoals deze in de formulieren weergegeven worden en kan ik de
basistabel best niet gebruiken voor nieuwe records toe te voegen?
Groetjes
De situatie is helder, de uitleg lastig(er). Mede omdat ik vermoed dat
er eerst nog wat aan de structuur van de database moet veranderen.

Om te beginnen zou je in de basis tabel voor de 5 (of 6) genoemde
gegevens maar EEN veld op mogen nemen. Immers door het vastleggen van
een ID die verwijst naar tblRijkCompleet heb je de gegevens Rijk, Stam,
Klasse, Orde, Geslacht (en Soort) automatisch te pakken. Ik vermoed dat
je nu voor elk gegeven een apart vel;d hebt in je basistabel. Dat
betekent dus ook dat je een van de gegevens kunt veranderen zonder dat
de overigen te veranderen en dat betekent weer dat je combinaties kan
maken die helemaal niet voor komen in tblRijkCompleet. En dan heb ik het
nog niet over het wijzigen van de tblRijkCompleet.

Verder vraag ik me af of je niet beter 5 (of 6) gerelateerde tabellen
kunt maken in plaats van tblRijkCompleet. Je legt nu redundant
informatie vast, met het gavaar op inconsistenties. Concreet bedoel ik
dat er bijvoorbeeld bij een Stam een heleboel Klasse/Orde/Geslachten
horen. Omdat dat iedere keer een nieuw record in dezelfde tabel
betekent, houdt dat ook in dat je in feite ook telkens vastlegt tot welk
Rijk de Stam behoort. Omdat je het steeds opnieuw vastlegt betekent dat
ook dat er fouten in kunnen sluipen en dat je de ene keer vastlegt dat
de Stam behoort tot het Rijk Plantae en de andere keer tot het Rijk
Protista en dat zou natuurlijk niet moeten mogen.
Door aparte tabellen voor Rijk, Stam, Klasse, Orde, Geslacht (en Soort)
te maken en die aan elkaar te koppelen voorkom je redundante
vastlegging. Je legt dan nog maar 1 keer vast dat Stam X behoort tot het
Rijk der Animalia

Dat neem niet weg dat je ter ondersteuning van het invullen wel met
gekoppelde keuzelijst wilt kunnen werken en dat kan ook. Een goede
database staat of valt echter met een goede structuur en wellicht moet
daar eerst nog wat aan gebeuren.

Ik weet niet of je een kopie van de database naar me kunt en wilt
sturen. Zo ja, dan kan ik denk ik wel wat aanpassingen doen om te laten
zien hoe een en ander in de praktijk uit zou kunnen werken.
--
Groeten,

Peter
Jeremy
2007-08-17 01:11:50 UTC
Permalink
Dag Peter,

Je hebt al wel begrepen dat ik geen databasebeheerder ben:-)
Laat ik eerst meer uitleg geven over Taxonomie en Paleontologie.(waarin ik
ook maar beginner ben)
Voor de 5 gegevens Rijk tm Geslacht heb ik keuzelijsten gemaakt, voor het
veld Soort een gewoon tekstvak om de volgende redenen.
- In veel gevallen is een fossiel niet of heel moeilijk determineerbaar tot
op het niveau Soort. In dat geval plaatst men de afkorting sp. (species)
- Heel wat geslachten tellen honderden soorten.
- Niet alle geslachten, ordes, klasses en stammen zijn opgenomen in de
tblRijkCompleet.
- Regelmatig wijzigt de naam of indeling van een fossiel
- Op het ogenblik van het ingeven van nieuwe records (fossielen) kent men
dikswijls niet de volledige benaming. Dit gebeurt later via opzoekingswerk.
- Hieruit volgt dat het mogelijk moet zijn om in de piramidestructuur het
onderliggende veld leeg te laten of de keuzelijst te gebruiken.
-Het moet mogelijk zijn om op een eenvoudige manier nieuwe gegevens aan de
tblRijkCompleet toe te voegen, in mindere mate te wijzigen.
- Als ik in mij formulier 1 veld zou opnemen ipv 5 zou ik de tblRijkCompleet
moeten uitbreiden met enorm veel records om het probleem van de lege velden
op te lossen( ttz soort, geslacht is nog niet gekend)
- Dan nog is de kans zeer groot dat ik elk nieuw fossiel eerst volledig zal
moeten ingeven in de tblRijkCompleet en dan heeft het geen zin om met
keuzelijsten te werken.

1 tabel of 5?
Je legt de vinger op de wonde. Ik denk dat deze keuze zeer belangrijk en
bepalend is. In een eerste fase heb ik gewerkt met 5 tabellen, dus elk veld 1
tabel. Daar was ik van afgestapt en heb voor 1 tabel gekozen. Mijn grootste
zorg was het ingeven op een eenvoudige manier van nieuwe gegevens in de
tblRijkCompleet. Als dit kan opgevangen worden, graag.
Nog een punt waar ik nog geen melding van gemaakt heb, omdat ik hiervoor al
de oplossing gevonden heb op deze site, is het volgende:
Op mijn formulier heb ik naast het veld Stam (Klasse) nog een veld
toegevoegd dat de Nederlandse benaming weergeeft. Alle namen zijn nl in het
Latijn.
Ik apprecieer het ten zeerste dat je de database eens onderhanden wil nemen.
Hoe kan ik je de file doorsturen?
Ik heb wel een paar beginnersfoutjes gemaakt vb in de benaming van de
velden, maar dat kan gerust zo blijven.
Toch ook een belangrijk punt om te melden. Daar ik tot hiertoe al veel
energie en tijd gestoken heb in dit project wil ik de database delen met de
andere leden van de vereniging. Omdat ik vertrokken ben vanuit het idee dat
de database toegankelijk moet zijn voor zoveel mogelijk mensen is de invoer
van een bestaand bestand naar Access toe heel belangrijk. Vandaar ook mijn
keuze om alle gegevens in 1 file te steken omdat je zo gemakkelijker een
Excell-file kunt invoeren en fouten verbeteren.

Vele groetjes

Jeremy
Post by XPS35
Post by jeremy
dag Peter,
alvast bedankt voor je reactie, laat ik proberen om wat duidelijker te zijn.
Ik heb 1 basistabel gemaakt met een 20-tal velden, van verschillende types,
die ik in mijn 1 formulier nodig heb ( flat file: alle gegevens staan in 1
tabel).
Van deze velden zijn er die via een keuzelijst gegevens uit andere tabellen
oproept (vb Landen, Gemeenten) om gemakkelijker nieuwe gegevens toe te
voegen.
5 Velden nl Rijk, Stam, Orde, Klasse en Geslacht wil ik aan elkaar linken
(Er is nog een 6de veld nl Soort maar die laat ik buiten beschouwing)
De gegevens van deze 5 velden worden via een keuzelijst uit de tabel
tblRijkCompleet gehaald.
Het veld Rijk in het formulier bied mij 3 mogelijkheden, Plantae, Animalia
en Protista. De keuze "Plantae" moet mij in het veld Stam enkel de planten
geven, hetzelfde principe voor de andere 4 velden.
Ik maak 1 query van de tblRijkCompleet, met daarin ID, Rijk, Stam, Klasse,
Orde en Geslacht, zonder criteria, naam vb QueryRijkCompleet.
Maar wat nu? Aangezien de tabel RijkCompleet al zo'n 600 records bevat
tellen de kolommen Rijk, Stam, enz veel dubbele gegevens. Met welke opdracht,
haal ik de dubbele gegevens eruit? Group By?
Je kan dit sowieso alleen via ee formulier doen omdat de oplossing
gebaseerd is op het werken met gebeurtenissen en die kan je alleen aan
formuliervelden koppelen.
Ok, dit snap ik. Is het dan zo dat alle velden in een formulier waar ik een
gebeurtenisprocedure op toepas, deze wijzigingen niet gaat overnemen in mijn
basistabel? Of hangt dit af van het type van procedure? (Ik heb nl al een
gebeurtenisprocedure geprobeerd en de tabel neemt dit over.)
Dus als ik het goed snap kan het zijn dat mijn basistabel niet alle gegevens
zal weergeven zoals deze in de formulieren weergegeven worden en kan ik de
basistabel best niet gebruiken voor nieuwe records toe te voegen?
Groetjes
De situatie is helder, de uitleg lastig(er). Mede omdat ik vermoed dat
er eerst nog wat aan de structuur van de database moet veranderen.
Om te beginnen zou je in de basis tabel voor de 5 (of 6) genoemde
gegevens maar EEN veld op mogen nemen. Immers door het vastleggen van
een ID die verwijst naar tblRijkCompleet heb je de gegevens Rijk, Stam,
Klasse, Orde, Geslacht (en Soort) automatisch te pakken. Ik vermoed dat
je nu voor elk gegeven een apart vel;d hebt in je basistabel. Dat
betekent dus ook dat je een van de gegevens kunt veranderen zonder dat
de overigen te veranderen en dat betekent weer dat je combinaties kan
maken die helemaal niet voor komen in tblRijkCompleet. En dan heb ik het
nog niet over het wijzigen van de tblRijkCompleet.
Verder vraag ik me af of je niet beter 5 (of 6) gerelateerde tabellen
kunt maken in plaats van tblRijkCompleet. Je legt nu redundant
informatie vast, met het gavaar op inconsistenties. Concreet bedoel ik
dat er bijvoorbeeld bij een Stam een heleboel Klasse/Orde/Geslachten
horen. Omdat dat iedere keer een nieuw record in dezelfde tabel
betekent, houdt dat ook in dat je in feite ook telkens vastlegt tot welk
Rijk de Stam behoort. Omdat je het steeds opnieuw vastlegt betekent dat
ook dat er fouten in kunnen sluipen en dat je de ene keer vastlegt dat
de Stam behoort tot het Rijk Plantae en de andere keer tot het Rijk
Protista en dat zou natuurlijk niet moeten mogen.
Door aparte tabellen voor Rijk, Stam, Klasse, Orde, Geslacht (en Soort)
te maken en die aan elkaar te koppelen voorkom je redundante
vastlegging. Je legt dan nog maar 1 keer vast dat Stam X behoort tot het
Rijk der Animalia
Dat neem niet weg dat je ter ondersteuning van het invullen wel met
gekoppelde keuzelijst wilt kunnen werken en dat kan ook. Een goede
database staat of valt echter met een goede structuur en wellicht moet
daar eerst nog wat aan gebeuren.
Ik weet niet of je een kopie van de database naar me kunt en wilt
sturen. Zo ja, dan kan ik denk ik wel wat aanpassingen doen om te laten
zien hoe een en ander in de praktijk uit zou kunnen werken.
--
Groeten,
Peter
XPS35
2007-08-17 07:06:30 UTC
Permalink
Post by Jeremy
Dag Peter,
Je hebt al wel begrepen dat ik geen databasebeheerder ben:-)
Laat ik eerst meer uitleg geven over Taxonomie en Paleontologie.(waarin ik
ook maar beginner ben)
Voor de 5 gegevens Rijk tm Geslacht heb ik keuzelijsten gemaakt, voor het
veld Soort een gewoon tekstvak om de volgende redenen.
- In veel gevallen is een fossiel niet of heel moeilijk determineerbaar tot
op het niveau Soort. In dat geval plaatst men de afkorting sp. (species)
- Heel wat geslachten tellen honderden soorten.
- Niet alle geslachten, ordes, klasses en stammen zijn opgenomen in de
tblRijkCompleet.
- Regelmatig wijzigt de naam of indeling van een fossiel
- Op het ogenblik van het ingeven van nieuwe records (fossielen) kent men
dikswijls niet de volledige benaming. Dit gebeurt later via opzoekingswerk.
- Hieruit volgt dat het mogelijk moet zijn om in de piramidestructuur het
onderliggende veld leeg te laten of de keuzelijst te gebruiken.
-Het moet mogelijk zijn om op een eenvoudige manier nieuwe gegevens aan de
tblRijkCompleet toe te voegen, in mindere mate te wijzigen.
- Als ik in mij formulier 1 veld zou opnemen ipv 5 zou ik de tblRijkCompleet
moeten uitbreiden met enorm veel records om het probleem van de lege velden
op te lossen( ttz soort, geslacht is nog niet gekend)
- Dan nog is de kans zeer groot dat ik elk nieuw fossiel eerst volledig zal
moeten ingeven in de tblRijkCompleet en dan heeft het geen zin om met
keuzelijsten te werken.
1 tabel of 5?
Je legt de vinger op de wonde. Ik denk dat deze keuze zeer belangrijk en
bepalend is. In een eerste fase heb ik gewerkt met 5 tabellen, dus elk veld 1
tabel. Daar was ik van afgestapt en heb voor 1 tabel gekozen. Mijn grootste
zorg was het ingeven op een eenvoudige manier van nieuwe gegevens in de
tblRijkCompleet. Als dit kan opgevangen worden, graag.
Nog een punt waar ik nog geen melding van gemaakt heb, omdat ik hiervoor al
Op mijn formulier heb ik naast het veld Stam (Klasse) nog een veld
toegevoegd dat de Nederlandse benaming weergeeft. Alle namen zijn nl in het
Latijn.
Ik apprecieer het ten zeerste dat je de database eens onderhanden wil nemen.
Hoe kan ik je de file doorsturen?
Ik heb wel een paar beginnersfoutjes gemaakt vb in de benaming van de
velden, maar dat kan gerust zo blijven.
Toch ook een belangrijk punt om te melden. Daar ik tot hiertoe al veel
energie en tijd gestoken heb in dit project wil ik de database delen met de
andere leden van de vereniging. Omdat ik vertrokken ben vanuit het idee dat
de database toegankelijk moet zijn voor zoveel mogelijk mensen is de invoer
van een bestaand bestand naar Access toe heel belangrijk. Vandaar ook mijn
keuze om alle gegevens in 1 file te steken omdat je zo gemakkelijker een
Excell-file kunt invoeren en fouten verbeteren.
Vele groetjes
Jeremy
Hallo Jeremy,

Wat je zegt over het kunnen muteren van de tblRijkCompleet bevestigt
alleen de noodzaak van het werken met 5 tabellen. Als je in de situatie
met 1 tabel bijvoorbeeld een geslacht wilt toevoegen, moet je de hele
bovenliggende reeks ook invullen. Met andere woorden: je moet
bijvoorbeeld ook de relaties tussen ordes, klassen en stammen
vastleggen, terwijl die misschien al eerder vastgelegd is. Je kan immers
te maken hebben met een Geslacht dat behoort tot dezelfde
orde/klasse/stam als een reeds ingevoerd geslacht.
In een opzet met 5 tabellen hoef je alleen bij het nieuwe geslacht de
bovenliggende familie (?) op te geven en daarmee ligt de rest van de
relaties vast.
Ook vastleggen van Nederlandse namen kan je alleen in een structuur met
5 tabellen goed doen. Je wilt immers niet dat als een bepaalde stam 20
keer voorkomt 20 keer de Nederlandse benaming in moeten vullen.

Uitwisselen met Excel kan mijns inziens altijd, mits de structuur van
het te gebruiken werkblad afgestemd is op dat van de structuur in
Access.
Een punt van aandacht hierbij is voor mij nog wel de vraag of de
benamingen namen van alle gegevens over de hele keten van rijk t/m
geslacht uniek zijn. Met andere woorden: kan het al dan niet voorkomen
dat bijvoorbeeld een bepaalde stam-naam in meer dan 1 rijk voorkomt? Als
dan niet het geval is zou dat het leven een stuk eenvoudiger maken en
kan je de namen gebruiken als sleutel, hetgeen de uitwisseling met Excel
sterk vereenvoudigt.
Als de namen niet uniek zijn zal je immers met betekenisloze nummers als
sleutel moeten werken en die zou je in Excel niet willen zien denk ik.

Ik vind het altijd leuk om op deze manier met voor mij nieuwe materie
(want dat is taxonomie voor mij) in aanraking te komen. Om me te
oriënteren heb ik al een beetje op internet rondgesnuffeld. Op basis van
wat ik vond (met name op
http://www.nederlandsesoorten.nl/nlsr/nlsr/i000241.html) heb ik al wat
in elkaar gedraaid, alleen toen kwam ik op 6 gegevens van rijk t/m
geslacht en daar is mijn opzetje dan ook op gebaseerd. Dat doet aan het
principe echter niets af.

Wat mij betreft kunnen we bestanden uitwisselen per mail. Het adres in
mijn berichten in de ng is echt. Via dat adres kan je me ook jouw
emailadres laten weten zodat ik desgewenst mijn voorbeeldje kan
opsturen.
--
Groeten,

Peter
Jeremy
2007-08-17 19:08:02 UTC
Permalink
Dag Peter,
wat je in de eerste opmerking (muteren) zegt is correct en was de reden
waarom ik eerst voor afzonderlijke kolommen gekozen heb (en getest) nl enkel
informatie invoegen wat nieuw is. Toen ik met 1 kolom probeerde heb ik het
probleem dat je aanhaalt opgelost door knippen en plakken van een
gelijkaardige record in de tblRijkCompleet om dan het veld dat nieuw was te
selecteren en er de nieuwe naam in te geven. Dit werkte ook. Als je
natuurlijk een veiligheid zou inbouwen om dubbele records te vermijden kan
dit misschien niet meer gaan, ik weet dat niet. Maar bon, we zitten op
dezelfde golflengte.
Unieke benamingen: door de pioniers als Linnaeus en Lamarck is voorzien dat
inderdaad elk fossiel (en levend wezen) een unieke naam en indeling heeft.
Een stam, geslacht,...kan maar tot 1 rijk behoren. Maar anderzijds kan het
wel voorkomen dat een fossiel 2 benamingen heeft( per ongeluk) en ten tweede,
is het zo dat voor het plantenrijk geen algemeen aanvaardde indeling bestaat.
Maar hiermee kan je en mag je geen rekening houden.
Om misschien een misverstand te vermijden, ben ik niet volledig geweest met
mijn uitleg vandaar nog het volgende: in bijna elke fossielenverzameling
wordt elk stuk fysiek voorzien van een nummer + label. En er bestaan talrijke
systemen die echter nog dateren van de kaartenbak en niet inspelen op de
mogelijkheden die de computer en internet bieden. Ik heb gekozen voor het
meest simpele en eenvoudige nl oplopende getallen vanaf 1. In mijn formulier
heb ik naast het veld "autonummering" een tweede tekstvak gemaakt waar men
een andere classificatie kan inbrengen. Dit om te vermijden dat je alle
fossielen van een nieuw nummer moet voorzien. Dit autonummeringveld heb ik
ingesteld als sleutel in de basistabel.
Een ander belangrijke reden hiertoe is : een specifiek fossiel kan over de
hele wereld gevonden worden en het kan ook over een grote tijdspanne
voorkomen. Dit betekent dat identieke stukken maar gevonden op een andere
locatie of van een andere periode of etage strikt gescheiden blijven in de
verzameling en dus ook een andere nummer krijgen. Ter verduidelijking: de
tijd wordt in grote blokken verdeeld genaamd Periodes ( vb Krijt, Devoon) die
ook telkens in kleinere eenheden verdeeld worden genaamd Etages ( vb
Maastrichtiaan) Ook tussen deze 2 tabellen wil ik een link leggen. Deze
gegevens dienen niet permanent uitgebreid te worden maar zijn ongeveer vast.
Ben ten zeerste benieuwd naar jouw voorbeeld. Als ik er aan uit kan wil ik
graag eerst zelf proberen om het in de database in te passen en het resultaat
jou doorsturen.
Groeten
Jeremy
--
Jeremy
Post by XPS35
Post by Jeremy
Dag Peter,
Je hebt al wel begrepen dat ik geen databasebeheerder ben:-)
Laat ik eerst meer uitleg geven over Taxonomie en Paleontologie.(waarin ik
ook maar beginner ben)
Voor de 5 gegevens Rijk tm Geslacht heb ik keuzelijsten gemaakt, voor het
veld Soort een gewoon tekstvak om de volgende redenen.
- In veel gevallen is een fossiel niet of heel moeilijk determineerbaar tot
op het niveau Soort. In dat geval plaatst men de afkorting sp. (species)
- Heel wat geslachten tellen honderden soorten.
- Niet alle geslachten, ordes, klasses en stammen zijn opgenomen in de
tblRijkCompleet.
- Regelmatig wijzigt de naam of indeling van een fossiel
- Op het ogenblik van het ingeven van nieuwe records (fossielen) kent men
dikswijls niet de volledige benaming. Dit gebeurt later via opzoekingswerk.
- Hieruit volgt dat het mogelijk moet zijn om in de piramidestructuur het
onderliggende veld leeg te laten of de keuzelijst te gebruiken.
-Het moet mogelijk zijn om op een eenvoudige manier nieuwe gegevens aan de
tblRijkCompleet toe te voegen, in mindere mate te wijzigen.
- Als ik in mij formulier 1 veld zou opnemen ipv 5 zou ik de tblRijkCompleet
moeten uitbreiden met enorm veel records om het probleem van de lege velden
op te lossen( ttz soort, geslacht is nog niet gekend)
- Dan nog is de kans zeer groot dat ik elk nieuw fossiel eerst volledig zal
moeten ingeven in de tblRijkCompleet en dan heeft het geen zin om met
keuzelijsten te werken.
1 tabel of 5?
Je legt de vinger op de wonde. Ik denk dat deze keuze zeer belangrijk en
bepalend is. In een eerste fase heb ik gewerkt met 5 tabellen, dus elk veld 1
tabel. Daar was ik van afgestapt en heb voor 1 tabel gekozen. Mijn grootste
zorg was het ingeven op een eenvoudige manier van nieuwe gegevens in de
tblRijkCompleet. Als dit kan opgevangen worden, graag.
Nog een punt waar ik nog geen melding van gemaakt heb, omdat ik hiervoor al
Op mijn formulier heb ik naast het veld Stam (Klasse) nog een veld
toegevoegd dat de Nederlandse benaming weergeeft. Alle namen zijn nl in het
Latijn.
Ik apprecieer het ten zeerste dat je de database eens onderhanden wil nemen.
Hoe kan ik je de file doorsturen?
Ik heb wel een paar beginnersfoutjes gemaakt vb in de benaming van de
velden, maar dat kan gerust zo blijven.
Toch ook een belangrijk punt om te melden. Daar ik tot hiertoe al veel
energie en tijd gestoken heb in dit project wil ik de database delen met de
andere leden van de vereniging. Omdat ik vertrokken ben vanuit het idee dat
de database toegankelijk moet zijn voor zoveel mogelijk mensen is de invoer
van een bestaand bestand naar Access toe heel belangrijk. Vandaar ook mijn
keuze om alle gegevens in 1 file te steken omdat je zo gemakkelijker een
Excell-file kunt invoeren en fouten verbeteren.
Vele groetjes
Jeremy
Hallo Jeremy,
Wat je zegt over het kunnen muteren van de tblRijkCompleet bevestigt
alleen de noodzaak van het werken met 5 tabellen. Als je in de situatie
met 1 tabel bijvoorbeeld een geslacht wilt toevoegen, moet je de hele
bovenliggende reeks ook invullen. Met andere woorden: je moet
bijvoorbeeld ook de relaties tussen ordes, klassen en stammen
vastleggen, terwijl die misschien al eerder vastgelegd is. Je kan immers
te maken hebben met een Geslacht dat behoort tot dezelfde
orde/klasse/stam als een reeds ingevoerd geslacht.
In een opzet met 5 tabellen hoef je alleen bij het nieuwe geslacht de
bovenliggende familie (?) op te geven en daarmee ligt de rest van de
relaties vast.
Ook vastleggen van Nederlandse namen kan je alleen in een structuur met
5 tabellen goed doen. Je wilt immers niet dat als een bepaalde stam 20
keer voorkomt 20 keer de Nederlandse benaming in moeten vullen.
Uitwisselen met Excel kan mijns inziens altijd, mits de structuur van
het te gebruiken werkblad afgestemd is op dat van de structuur in
Access.
Een punt van aandacht hierbij is voor mij nog wel de vraag of de
benamingen namen van alle gegevens over de hele keten van rijk t/m
geslacht uniek zijn. Met andere woorden: kan het al dan niet voorkomen
dat bijvoorbeeld een bepaalde stam-naam in meer dan 1 rijk voorkomt? Als
dan niet het geval is zou dat het leven een stuk eenvoudiger maken en
kan je de namen gebruiken als sleutel, hetgeen de uitwisseling met Excel
sterk vereenvoudigt.
Als de namen niet uniek zijn zal je immers met betekenisloze nummers als
sleutel moeten werken en die zou je in Excel niet willen zien denk ik.
Ik vind het altijd leuk om op deze manier met voor mij nieuwe materie
(want dat is taxonomie voor mij) in aanraking te komen. Om me te
oriënteren heb ik al een beetje op internet rondgesnuffeld. Op basis van
wat ik vond (met name op
http://www.nederlandsesoorten.nl/nlsr/nlsr/i000241.html) heb ik al wat
in elkaar gedraaid, alleen toen kwam ik op 6 gegevens van rijk t/m
geslacht en daar is mijn opzetje dan ook op gebaseerd. Dat doet aan het
principe echter niets af.
Wat mij betreft kunnen we bestanden uitwisselen per mail. Het adres in
mijn berichten in de ng is echt. Via dat adres kan je me ook jouw
emailadres laten weten zodat ik desgewenst mijn voorbeeldje kan
opsturen.
--
Groeten,
Peter
Lees verder op narkive:
Loading...