Mehrere Ebenen Nachschlagen

[Theofino]

Hallo liebes Forum,

erst einmal sorry für die vermutlich sehr dumme Frage, aber ich bin blutiger Access-Anfänger, daher bitte bitte nicht die Augen rollen und seid nachsichtig... okay?

Also mein Problem bzw. erst einmal was ich gemacht habe anhand eines Kurses.
Ich hab eine tblPersonen mit
IDPersonen (Autowert, Schlüssel)
txtVorname (kurzer Text)
txtNachname (kurzer Text)
Nachname, Vorname (berechnet) [Nachname] & " ," & [Vorname]

erstellt.

Ddas ganze habe ich mit einer 1:1 Verbindung mit einer tblMitarbeitende verknüpft.
lngPersonen (Nachschlagen, Listenfeld; Herkunftstyp: Tabelle/Abfrage; Datensatzherkunft, tblPersonen; Spaltenzahl 4; Spaltenbreite 0;0;0;6). Somit kann ich in der "tblMitarbeitende" einzelne Personen als Mitarbeitende überführen und kann das direkt in der Tabelle indem ich den Nachnamen, Vornamen tippe und mir nicht die Zahl merken muss.

So weit funktioniert es auch. Jetzt wollte ich aber diese "tblMitarbeitende" mit einer weiteren Tabelle verbinden und da scheitert jetzt dieser gelernte Weg über Nachschlagen, Listenfeld, Spaltenbreite etc. Ich bekomme einfach nicht den Namen angezeigt, sondern eben nur die entsprechende ID...

Versteht ihr mich? Könnt ihr mir helfen? Bin ich völlig auf dem Holzweg?

[DF6GL]

Hallo,

Versteht ihr mich? Könnt ihr mir helfen? Bin ich völlig auf dem Holzweg?

teilweise, ja, ja


Zunächst:  Nachschlagefelder (Kombifeld, Listenfeld) in einer Tabelle sind für die weitere Entwicklung einer DB ungeeignet, soll heißen Schrott. Solche Felder sind nur in Formularen, in denen die Datenbearbeitung stattfinden sollte, sinnvoll und brauchbar.

ich mit einer 1:1 Verbindung mit einer tblMitarbeitende verknüpft.

Wenn Du wirklich 1:1 meinst, dann wäre dies (hier) falsch.  Sinnreich wäre eine 1:n-Beziehung.

Weiterhin sind berechnete Felder, deren Ergebnis sich aus anderen Grundfeldern ergibt, nicht abzuspeichern.  Es gibt zwar den "Datentyp" "berechnet", aber ob das hier so sinnvoll eingesetzt ist, ist fraglich.  Solche Berechnungen werden nur dann und dort gemacht, wo man sie braucht. (z. B. bei der Darstellung in einem Bericht).

Zeige mal den Screenshot des Beziehungsfensters. 

[Theofino]

Erst einmal vielen Dank für die Hilfeversuche. Ich hab wirklich Angst, dass ich hier wie der totale Trottel wirke, aber ich komme da irgendwie nicht auf einen grünen Zweig, trotz Online-Tutorial und Udemy.Schulung und es will einfach nicht der Knoten platzen bei mir. 

Zunächst:  Nachschlagefelder (Kombifeld, Listenfeld) in einer Tabelle sind für die weitere Entwicklung einer DB ungeeignet, soll heißen Schrott. Solche Felder sind nur in Formularen, in denen die Datenbearbeitung stattfinden sollte, sinnvoll und brauchbar.

Also sollte ich es besser sein lassen? Onlinekurs hat mir diesen Weg gezeigt.

Wenn Du wirklich 1:1 meinst, dann wäre dies (hier) falsch.  Sinnreich wäre eine 1:n-Beziehung.
 

Okay? Ich hab hier eigentlich gedacht, dass ich genau das hier übernommen habe: https://www.access-tutorial.de/tabellen/1zu1beziehung.htm

Okay also ja folgt (siehe Anhang)

[MzKlMu]

Hallo,
der Sinn der Tabelle tblMitarbeitende erschließt sich mir nicht. Mit der 1:1 Beziehung ist die Tabelle einfach überflüssig.
Die 1:1 Beziehung aus dem Link ist etwas ganz anderes, da macht es Sinn. Hier werden Tabellen mit unterschiedlichen Inhalten 1:1 verknüpft. Das gezeigte Beispiel im Link ist für mich aber mehr als fragwürdig. Das mit dem Gehalt kann nie eine 1:1 sein, denn das Gehalt ändert sich ja.
Das taugt meiner Meinung auch nicht als lehrreiches Beispiel.

Was willst Du eigentlich erreichen ?
Willst Du dokumentieren wer welche Sprache spricht ?

Lasse das mit dem berechneten Feld, das ist genau so überflüssig wie die Nachschlagefelder in den Tabellen.
Berechnungen macht man in Abfragen, dann wenn sie benötigt werden.

Ich bekomme einfach nicht den Namen angezeigt, sondern eben nur die entsprechende ID...

Das ist ja auch richtig, in Tabellen darf nur die ID zu sehen sein.
Wenn man Formaulare verwendet kann man über Abfragen mit den beteiligten Tabellen und den Verknüpfungen alle Klartextfelder anzeigen. Ohne etwas programmieren zu müssen.

Und noch ein Tip:
Die Präfixe (txt, ber, lng) sind eher hinderlich und zu nix nutze. Machen nur mehr Arbeit, sonst nix.
Stelle Dir mal vor, Du änderst einen Datentyp von lng auf int ?
Hast Du Dir mal überlegt was Du alles wo ändern musst ?
Wird auch gern gelehrt, ist aber eher Krampf.
Bei den Tabellen (tbl) und Abfragen (qry) macht es zur Unterscheidung Sinn, da habe ich diese auch. Ansonsten aber nicht.

[Theofino]

Schon einmal tausend Dank euch beiden. Vielleicht kapier ich endlich mal, wie man es denn nun richtig und sinnvoll nutzt. Ich hab seit einem halben Jahr das Gefühl, dass Access eigentlich sehr sinnvoll ist, aber der Knoten bei mir sich nicht lösen will.

der Sinn der Tabelle tblMitarbeitende erschließt sich mir nicht. Mit der 1:1 Beziehung ist die Tabelle einfach überflüssig.
Die 1:1 Beziehung aus dem Link ist etwas ganz anderes, da macht es Sinn. Hier werden Tabellen mit unterschiedlichen Inhalten 1:1 verknüpft.

Naja über kurz oder lang will ich ja es auch ähnlich haben wie in dem Bsp. Also dass Personen mit 1:1 Mitarbeitenden; 1:1 Kunden etc. verbunden werden.

Berechnungen macht man in Abfragen, dann wenn sie benötigt werden.

Ich bekomme einfach nicht den Namen angezeigt, sondern eben nur die entsprechende ID...

Das ist ja auch richtig, in Tabellen darf nur die ID zu sehen sein.
Wenn man Formaulare verwendet kann man über Abfragen mit den beteiligten Tabellen und den Verknüpfungen alle Klartextfelder anzeigen. Ohne etwas programmieren zu müssen.

Wenn ich dich richtig verstehen, dann sind die verknüpften Tabellen wirklich nur zur Strukturierung des Systems dar, wie es vernetzt ist und die Einsicht in den Inhalt erhalte ich über Abfragen und/oder die Formulare?

Und noch ein Tip:
Die Präfixe (txt, ber, lng) sind eher hinderlich und zu nix nutze. Machen nur mehr Arbeit, sonst nix.
Stelle Dir mal vor, Du änderst einen Datentyp von lng auf int ?
Hast Du Dir mal überlegt was Du alles wo ändern musst ?
Wird auch gern gelehrt, ist aber eher Krampf.
Bei den Tabellen (tbl) und Abfragen (qry) macht es zur Unterscheidung Sinn, da habe ich diese auch. Ansonsten aber nicht.

Oooh. Okay, danke für den Tipp. Hab mich halt auch da versucht möglichst ordentlich an Tutorial und co zu halten.


Aber vielen Dank euch. Vielleicht lerne ich es ja auch endlich mal.

[MzKlMu]

Hallo,

Also dass Personen mit 1:1 Mitarbeitenden; 1:1 Kunden etc. verbunden werden.

Ich halte es für völlig ausgeschlossen, dass 1:1 hier einen Sinn macht.
1:1 Beziehungen sind nur in seltenen Fällen wirklich sinnvoll. Bei dem im Link gezeigten Beispiel halte ich wie bereits gesagt die 1:1 Beziehungen auch für fragwürdig.

Du solltest mal Deine Absichten besser beschreiben. Wie hängen die Kunden und die Mitarbeiter des Kunden zusammen ?

[DF6GL]

Hallo,

Naja über kurz oder lang will ich ja es auch ähnlich haben wie in dem Bsp. Also dass Personen mit 1:1 Mitarbeitenden; 1:1 Kunden etc. verbunden werden.

Das willst Du vermutlich und sicherlich nicht haben...
Was Du erreichen willst, hast Du bislang noch nicht beschrieben. (Nicht das Beispiel zitieren!)

sind die verknüpften Tabellen wirklich nur zur Strukturierung des Systems dar, wie es vernetzt ist und die Einsicht in den Inhalt erhalte ich über Abfragen und/oder die Formulare?

Bingo!   Natürlich kann man aber während der Entwicklung zum Testen Daten in Tabellen manipulieren, beim Betrieb der DB aber nicht.

Strukturierung des Systems

würde ich anders betiteln:  "Strukturierung der realen Daten" .  Die Tabellenkonstruktion muss die reale Datenkonstellation abbilden.

[Theofino]

Naja über kurz oder lang will ich ja es auch ähnlich haben wie in dem Bsp. Also dass Personen mit 1:1 Mitarbeitenden; 1:1 Kunden etc. verbunden werden.

Das willst Du vermutlich und sicherlich nicht haben...
Was Du erreichen willst, hast Du bislang noch nicht beschrieben. (Nicht das Beispiel zitieren!)

Ok dann versuch ich mal es kurz zu beschreiben. Was ich machen will, ist eine Datenbank zur Kursplanung. Dazu habe ich Kunden, die bei uns Kurse buchen und (freie)Mitarbeitende, die einzelne Formate in den Kursen anbieten. Da manche unserer Mitarbeitenden –aber nicht alle – selbst bei uns Seminare buchen und ich vermutlich zu viel von Normalformen gelesen habe, war da eben schon die Idee, dass ich eine Liste anlege, bei der alle Personen drinstehen und die dann entsprechend zuordne, ob sie Kunden, Mitarbeitende oder beides sind.
Im weiteren Verlauf würde ich gerne noch unsere Kursangebote mitaufnehmen, bei der ich hinterlege, welche unserer Mitarbeitenden welche Kurse in welchen Sprachen anbieten kann sowie die konkrete Kursvergabe machen. Also dass ich sagen kann, am 12.3.2020 findet Kurs A von Mitarbeitenden b & c in Stadt X statt, gebucht von Kunde Z und für Kurs A gibt es Materialanforderungen 1,2 und 3.
Ich habe die Hoffnung, dass das unter Access toll gehen könnte und mir die Arbeit abnimmt, immer zu schauen ob Bsp. Mitarbeitende b den Kurs überhaupt durchführen kann, in der entsprechenden Sprache, überhaupt an den Tagen verfügbar ist etc.
War das so einigermaßen verständlich?

Entschuldigt bitte, wenn ich so ,,abstrakt" bleibe. Ihr seht ja, wie unwissend ich bereits bin, könnt euch daher vielleicht vorstellen, wie der Modus Operandi aktuell aussieht. Mein Arbeitgeber wäre wohl wenig erfreut, wenn ich online poste, dass unsere gesamte Planungsarbeit meist mit Papier und Bleistift und viel Radiergummi erfolgt.

sind die verknüpften Tabellen wirklich nur zur Strukturierung des Systems dar, wie es vernetzt ist und die Einsicht in den Inhalt erhalte ich über Abfragen und/oder die Formulare?

Bingo!   Natürlich kann man aber während der Entwicklung zum Testen Daten in Tabellen manipulieren, beim Betrieb der DB aber nicht.

Danke. Ich hab das Gefühl das lockert den Knoten bei mir schon einmal massiv. Ich hab in den Tutorials und Co. immer gesehen und gelesen, dass die Leute eben in Tabellen mit berechneten Feldern arbeiten über Nachschlagen und den Spaltenbreiten 0;0;0;3 oder ähnlichem und da kam ich eben nie ordentlich weiter.

Strukturierung des Systems

würde ich anders betiteln:  "Strukturierung der realen Daten" .  Die Tabellenkonstruktion muss die reale Datenkonstellation abbilden.

Okay. Ja, Du hast natürlich völlig recht und trifft es wirklich besser. Hab mich unsauber ausgedrückt.

[MzKlMu]

Hallo,
wie ich vermutet habe, die 1:1 Beziehung mit der Zwischentabelle ist überflüssig.
Die Mitarbeitertabelle erhält einfach nur ein zusätzliches feld mit einer Zahl:
1=Kunden
2=Mitarbeitende
3=Beides

[Theofino]

Hallo,
wie ich vermutet habe, die 1:1 Beziehung mit der Zwischentabelle ist überflüssig.
Die Mitarbeitertabelle erhält einfach nur ein zusätzliches feld mit einer Zahl:
1=Kunden
2=Mitarbeitende
3=Beides

Ohh okay. Danke. Dann versuche ich es wohl besser so. Aber dazu direkt die Rückfrage, würde es das nicht deutlich komplizierter machen, wenn ich statt 2 Variablen 3 hätte? Es ist doch bestimmt nicht: 

1 = Kunde
2 = Mitarbeitende
3 = Autor
4 = Kunde und Mitarbeitende
5 = Kunde und Autor
6 = Mitarbeitende und Autor
7 = alles


€dit: ok, ich glaube, da würde dann eine Verknüpfungstabelle zum Einsatz kommen. OK, versuche mich erstmal von 1:1-Beziehungen fernzuhalten.

[MzKlMu]

Hallo,
das ist nun wieder etwas ganz anderes. Da ist mein Vorschlag wenig sinnvoll.
Hier wäre eine n:m Beziehung angebracht.
Dazu werden 2 weitere Tabellen benötigt.
tblPersonenArt
1  Kunde
2  Mitarbeitende
3  Autor

tblWerIstWas
Diese TAbelle hätte dann folgenden Inhalt:

Code [Auswählen] Erweitern

IDPerson_F       IDPersonenart_F
     1                 1
     1                 3
     2                 1
     2                 2
     2                 3
     3                 2
     3                 3
     4                 1
  Das sind 2 1:n Beziehungen.

Gerade für den Anfänger ist es sinnvoll Primärschlüssel und Fremdschlüssel immer eindeutig unterscheiden zu können. Daher hänge ich an die Fremdschlüsselfeldnamen ein _F an.

[Theofino]

Besten Dank, aber jetzt bin ich tatsächlich 3min früher selbst draufgekommen.
Das freut mich aber für den Lerneffekt, dass ich es dann prompt bestätigt bekomme