Access 2010 - Naturwissenschaftliche Datenbank
Es handelt sich um eine umfangreiche naturwissenschaftliche Datenbank, in der etwa 6000 Pflanzenarten und 40'000 Funde gespeichert sind. Die Datenbank hat sich über 30 jahre bewährt, doch jetzt kommt ein Abfrageproblem hinzu.
TABELLE ART: Hier sind u.a. 14 Optionsfelder Ja/Nein untergebracht. Sie beschreiben die Höhenstufen, d.h. den Lebensraum einer Art, ausgedrückt in Begriffen wie planar, kollin usw. Bei der Erfassung einer neuen Art werden die Optionsfelder angeklickt. Eine einzige Art kann auf bis zu 8 Höhenstufen vorkommen.
TABELLE HÖHENSTUFEN: Hier sind in 14 Datensätzen neben dem Primärschlüssel 8 Textspalten untergebracht, die Details über Höhenstufen beschreiben. Es geht hier um den textlichen Ausdruck der oben genannten Optionsfelder.
Damit die Datentypen der Schlüssel auf beiden Seiten Zahlen sind, sind neben den oben genannten Optionsfeldern auch die Schlüsselzahlen aus der TABELLE HÖHENSUFEN in einem Zahlenfeld der TABELLE ART ergänzt. Dieses Zahlfeld enthält den Primärschlüssel der TABELLE HÖHENSTUFEN.
Es soll nun eine Abfrage über sämtliche Arten mit den entsprechenden Höhenstufen und den textlichen Ergänzungen aus der TABELLE HÖHENSTUFEN erstellt werden. In dieser Abfrage scheitert sowohl die Entwurfsansicht als auch die SQL-Ansicht. Offensichtlich sind zu viele Felder vorhanden, denn es erscheint die Meldung: "Für Beziehung ist dieselbe Anzahl an Feldern und dieselben Datentypen erforderlich."
Mit einer n:m-Beziehung komme ich auch nicht weiter. Auch nicht mit einer UNION-Abfrage. Wir haben hier die Sondersituation, dass in einer 1:n-Beziehung die 1-Tabelle in der Abfrage 14 mal Informationen an die Abfrage liefern soll. Das heißt, dass in der Entwurfsansicht die TABELLE HÖHENSTUFEN ARTEN 14 mal geöffnet werden muss. Nach 8 Verbindungen stürzt die Fuhre ab.
Weiß jemand einen anderen Lösungsansatz?
TABELLE ART: Hier sind u.a. 14 Optionsfelder Ja/Nein untergebracht. Sie beschreiben die Höhenstufen, d.h. den Lebensraum einer Art, ausgedrückt in Begriffen wie planar, kollin usw. Bei der Erfassung einer neuen Art werden die Optionsfelder angeklickt. Eine einzige Art kann auf bis zu 8 Höhenstufen vorkommen.
TABELLE HÖHENSTUFEN: Hier sind in 14 Datensätzen neben dem Primärschlüssel 8 Textspalten untergebracht, die Details über Höhenstufen beschreiben. Es geht hier um den textlichen Ausdruck der oben genannten Optionsfelder.
Damit die Datentypen der Schlüssel auf beiden Seiten Zahlen sind, sind neben den oben genannten Optionsfeldern auch die Schlüsselzahlen aus der TABELLE HÖHENSUFEN in einem Zahlenfeld der TABELLE ART ergänzt. Dieses Zahlfeld enthält den Primärschlüssel der TABELLE HÖHENSTUFEN.
Es soll nun eine Abfrage über sämtliche Arten mit den entsprechenden Höhenstufen und den textlichen Ergänzungen aus der TABELLE HÖHENSTUFEN erstellt werden. In dieser Abfrage scheitert sowohl die Entwurfsansicht als auch die SQL-Ansicht. Offensichtlich sind zu viele Felder vorhanden, denn es erscheint die Meldung: "Für Beziehung ist dieselbe Anzahl an Feldern und dieselben Datentypen erforderlich."
Mit einer n:m-Beziehung komme ich auch nicht weiter. Auch nicht mit einer UNION-Abfrage. Wir haben hier die Sondersituation, dass in einer 1:n-Beziehung die 1-Tabelle in der Abfrage 14 mal Informationen an die Abfrage liefern soll. Das heißt, dass in der Entwurfsansicht die TABELLE HÖHENSTUFEN ARTEN 14 mal geöffnet werden muss. Nach 8 Verbindungen stürzt die Fuhre ab.
Weiß jemand einen anderen Lösungsansatz?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 203079
Url: https://administrator.de/contentid/203079
Ausgedruckt am: 21.11.2024 um 22:11 Uhr
13 Kommentare
Neuester Kommentar
Hi!
mach bitte eine Skizze der Tabellen. Kann leicht sein, dass die GUI damit überfordert ist, aber mit einer SQL-Query sollte das kein Problem sein.
und wie soll die Ausgabe aussehen:
oder eher so?
sg Dirm
mach bitte eine Skizze der Tabellen. Kann leicht sein, dass die GUI damit überfordert ist, aber mit einer SQL-Query sollte das kein Problem sein.
und wie soll die Ausgabe aussehen:
Blume1, planar, blablabla
Blume1, kollin, dadada
Blume2, planar, blablabla
Blume3, kollin, dadada
oder eher so?
Blume1, [(planar, blablabla), (kollin, dadada)]
Blume2, [(planar, blablabla)]
Blume3, [(kollin, dadada)]
sg Dirm
Hi!
hmmm in welcher Tabelle steht bei dir jetzt Blume1? fehlt die noch?
mach bitte mal ein ordentliches Beispiel, vor allem wie die Spalten heißen.
(verwend keine umlaute und sonderzeichen in den Tabllen-, Spalten-Namen!)
ich glaub du hast das Tabellen layout bissl verbaut.
dann kannst du deine Daten wie folgt abfragen (nur grobes Beispiel):
SELECT * FROM hoehenstufen JOIN blumen_auf_hoehenstufen JOIN blumen
Diese Tabelle musst du dann gruppieren, aber GROUP_CONCAT gibt es anscheinend in Access nicht direkt - aber ConcatVar hilft ev. weiter. Musst aber noch googeln.
gibts da nicht die mehrfach Kombifelder? sonst mach Checkboxen - musst zur Not per VBA verarbeiten.
sg Dirm
hmmm in welcher Tabelle steht bei dir jetzt Blume1? fehlt die noch?
mach bitte mal ein ordentliches Beispiel, vor allem wie die Spalten heißen.
(verwend keine umlaute und sonderzeichen in den Tabllen-, Spalten-Namen!)
ich glaub du hast das Tabellen layout bissl verbaut.
BLUMEN
ID | Name
---+-------
1 | Blume1
2 | Blume2
3 | Blume3
BLUMEN_AUF_HOEHENSTUFEN
ID | _ID-Blume | _ID-Hoehe
---+-----------+---------
1 | 1 | 1
2 | 1 | 2
3 | 2 | 3
4 | 3 | 2
Diese Tabelle bildet die n:m Beziehung ab - die IDs sind Fremdschlüssel auf die andern beiden Tabellen. (Die Spalte ID ist egal, Access erzwingt nur einen Primärschlüssel)
HOEHENSTUFEN
ID | Namehoehe | Lage | Beschr
---+-----------+-------+-------
1 | pallin | oben | blavbla
2 | kollin | unten | hjk kj
3 | submon | innen | ghj gh j
dann kannst du deine Daten wie folgt abfragen (nur grobes Beispiel):
SELECT * FROM hoehenstufen JOIN blumen_auf_hoehenstufen JOIN blumen
Diese Tabelle musst du dann gruppieren, aber GROUP_CONCAT gibt es anscheinend in Access nicht direkt - aber ConcatVar hilft ev. weiter. Musst aber noch googeln.
Mein Grundproblem: Normalerweise wählt man in einem Kombinationsfeld einen Begriff, und der Schlüsselwert wird gespeichert. Hier aber habe ich mehrere Begriffe einzugeben (bis zu 14), und es sollten bis zu 14 Schlüsselwerte in die Tabelle eingegeben werden. Deshalb bin ich auf dem Erfassungsformular auf 14 Ja/Nein-Felder ausgewichen und habe zu diesen 14 Ja/Nein-Werten zusätzlich 14 ID Felder geschaffen. In diesen ID Feldern erscheint der entsprechende Schlüsselwert aus der Tabelle HÖHENSTUFEN ARTEN.
gibts da nicht die mehrfach Kombifelder? sonst mach Checkboxen - musst zur Not per VBA verarbeiten.
sg Dirm
Moin wilkau,
willkommen im Forum.
Du kennst doch diese gelben Telefonapparate alle 5 Autobahn-Kilometer hinter der Leitplanke?
Wenn du da anhältst, um deiner Mutti telefonisch mitzuteilen, dass es 20 Minuten später wird... klappt das?
--> Ich denke, Dirm hat deine Nachricht (noch) nicht erhalten und wird es in diesem Leben vermutlich auch nicht mehr.
--> Deshalb bitte neu schreiben oder noch guter: Diskutiert doch bitte im Forum weiter.
Es spricht doch nichts dagegen, eine Zuordnungs-Tabelle zusammenzuschrubbeln wie von Dirm angeregt.
Okay, die Anzahl der Tabellen in deinem Datenmodell veranderthalbfacht sich auf einen Schlag.
Aber der Nutzen ist ja nicht von der Hand zu weisen.
Denn selbst Access 2010 (ein Produkt des 21. Jahrhunderts!!) kann laut M$-Produktblatt maximal 16 "Beziehungen" in einer Query handeln.
*schenkelklopf*
Da bist du mit deinen Heute-schon-14-Joins definitiv an der Das-kann-ich-so-nicht-dauerhaft-einsetzen-Grenze.
Grüße
Biber
willkommen im Forum.
Zitat von @wilkau:
Hallo Dirm,
aller Anfang ist schwer. Ich habe eben eine Antwort an Dich geschrieben und "Melden" gedrückt. Das war wohl ein
Fehler, denn alles ist weg. Hast du die Nachricht erhalten?
Gruß Wilfried
Na ja, Datenbanken sind ja nicht so mein Hobby, aber das mit dem Meldebutton könnte ich dir erklären.Hallo Dirm,
aller Anfang ist schwer. Ich habe eben eine Antwort an Dich geschrieben und "Melden" gedrückt. Das war wohl ein
Fehler, denn alles ist weg. Hast du die Nachricht erhalten?
Gruß Wilfried
Du kennst doch diese gelben Telefonapparate alle 5 Autobahn-Kilometer hinter der Leitplanke?
Wenn du da anhältst, um deiner Mutti telefonisch mitzuteilen, dass es 20 Minuten später wird... klappt das?
--> Ich denke, Dirm hat deine Nachricht (noch) nicht erhalten und wird es in diesem Leben vermutlich auch nicht mehr.
--> Deshalb bitte neu schreiben oder noch guter: Diskutiert doch bitte im Forum weiter.
Es spricht doch nichts dagegen, eine Zuordnungs-Tabelle zusammenzuschrubbeln wie von Dirm angeregt.
Okay, die Anzahl der Tabellen in deinem Datenmodell veranderthalbfacht sich auf einen Schlag.
Aber der Nutzen ist ja nicht von der Hand zu weisen.
Denn selbst Access 2010 (ein Produkt des 21. Jahrhunderts!!) kann laut M$-Produktblatt maximal 16 "Beziehungen" in einer Query handeln.
*schenkelklopf*
Da bist du mit deinen Heute-schon-14-Joins definitiv an der Das-kann-ich-so-nicht-dauerhaft-einsetzen-Grenze.
Grüße
Biber
Hi!
Tut's doch nicht immer alle verschrecken Ist ja der aller erste Beitrag.
OT:
Das Problem an Access ist, dass es eher für kleine Projekte gedacht ist - aber oft für alles eingesetzt wird oder mit der Zeit wächst und nie ersetzt wird.
Ein großes Wirtschaftsinstitut in Ö hat über Jahre eine Access DB mit ihren Kundendaten "gepflegt". Am Ende hatte das Hauptformular 5 Reiter mit je 50 Formularelementen. Eines Tages kam das Ding nicht mehr hoch und dann war plötzlich Budget für das neues da...
und noch ein "Nachteil" an Access - es werden dadurch MAs ohne DB Know-How zur DB Entwicklung "gezwungen" - "is ja eh Office"
Andererseits unsere Sekretärin verwaltet sich ihre Adressen in Access, da kann sie sich alles zusammenklicken wie sie will und die IT hat kein Problem damit
sg Dirm
Tut's doch nicht immer alle verschrecken Ist ja der aller erste Beitrag.
OT:
Das Problem an Access ist, dass es eher für kleine Projekte gedacht ist - aber oft für alles eingesetzt wird oder mit der Zeit wächst und nie ersetzt wird.
Ein großes Wirtschaftsinstitut in Ö hat über Jahre eine Access DB mit ihren Kundendaten "gepflegt". Am Ende hatte das Hauptformular 5 Reiter mit je 50 Formularelementen. Eines Tages kam das Ding nicht mehr hoch und dann war plötzlich Budget für das neues da...
und noch ein "Nachteil" an Access - es werden dadurch MAs ohne DB Know-How zur DB Entwicklung "gezwungen" - "is ja eh Office"
Andererseits unsere Sekretärin verwaltet sich ihre Adressen in Access, da kann sie sich alles zusammenklicken wie sie will und die IT hat kein Problem damit
sg Dirm