Hallo zusammen!
Ich bin neu in diesem Forum und komme mit einer Frage, in der Hoffnung, dass Ihr mir helfen könnt.
Meine DB stellt eine Gruppe mit mehreren Untergruppen dar. Jede Untergruppe hat einen Gruppenleiter. Dabei kann ein Mitglied zu mehreren Untergruppen gehören und ein Gruppenleiter mehrere Gruppen betreuen.
In meiner DB sieht es so aus:
tblPerson: PersonID, LastName, FirstName
tblGroups: GroupID, GroupName
tbl_Person_Group: ID, PersonID, GroupID, PersonID_as_GroupLeader,
hier ist PersonID_as_GroupLeader=PersonID
Wie kann ich eine Query formulieren, die folgende Ausgabe hat:
LastName, FirstName, GroupName, LastName(GroupLeader), FirstName(GroupLeader)
Könnte mir hier eine::r bitte helfen?
Vielen Dank und schöne Grüße,
Verena
Hallo Verena,
aus meiner Sicht passen die Tabellen-Definitionen nicht ganz.
-> Jede Gruppe hat einen Gruppenleiter.
Daher muss der Gruppenleiter in die Tabelle tblGroups und bei tbl_Person_Group muss er natürlich raus.
Die Ausgabe ist ein simpler Join aller Tabellen.
Wenn der Aufbau passt ist auch die korrekte Ausgabe kein Problem.
Edit:
Außerdem sollte bei Untergruppen, in tblGroups auch die Parent_Group existieren.
Das brauchst du dann auch für die korrekte Darstellung der Hierarchie.
Hallo Markus,
vielen Dank für deine Antwort! Ich habe mich vertan, sorry!
-> Jede Gruppe hat einen Gruppenleiter ––– das ist nicht richtig
In unserem Fall ist es so, dass jede Gruppe mehrere Gruppenleiter haben kann und jedes Mitglied zu mehreren Gruppen gehören kann. Deswegen wollte ich eine Tabelle mit allen Gruppenmitgliedern machen (wo jeder nur einmal vorkommt tblPerson) und eine, die PesonID, GruppenID und PersonID (für den Gruppenleiter) beinhaltet. Und da dachte ich an SelfJoin. Nur dass ich in diesem Fall sogar zwei SelfJoin brauche. Ist es richtig gelöst? Oder geht es einfacher?
Ich habe ein Bild angehängt.
Danke für deine Hilfe!
Verena
Hallo,
Die 1:1 Beziehung über die beiden Primärschlüssel kann nicht richtig sein. Wenn das 2 Autowerte sind geht das auch nicht.
Hi,
ja, das hat nur beim Run einmal funktioniert (mit einer richtigen Ausgabe), sonst beklagt sich Access. Aber wie löst man das auf? Es sind drei Tabellen, die ich nicht zusammenbekomme :-/
Danke euch,
Verena
Hallo,
ich sehe die Beziehungen eher so:
Zitat von: VerenaM am Oktober 29, 2021, 09:50:02In unserem Fall ist es so, dass jede Gruppe mehrere Gruppenleiter haben kann und jedes Mitglied zu mehreren Gruppen gehören kann.
Hallo Verena, bin schon am Weg ins Wochenende. So wie Klaus es zeigt würde ich es auch machen.
Wenn die Gruppen völlig unabhängig voneinander sind gibt es natürlich auch keine übergeordnete Gruppe.
Hallo Klaus, hallo Markus!
Danke Euch!
Heißt es, dass ihr auch prinzipiell davon abraten würdet, solche Konstrukte zu benutzen? Und lieber eine Tabelle dazwischen anzulegen, bevor die Beziehungen zu kompliziert werden?
Viele Grüße und schönes WE,
Verena
Hallo,
Zitat von: undefineddass ihr auch prinzipiell davon abraten würdet,
nein, nicht prinzipiell, sondern nur dann, wenn man es nicht braucht.
Als
einfaches Beispiel für einen SelfJoin wäre z.B. die Zuweisung eines Chefs einer Person, wenn die Chefs ebenfalls aus der Personentabelle kommen.
PS:
In Deinem Bild in #2 ist übrigens kein SelfJoin.
Alles klar! Dann werde ich es so 'bauen'.
Danke Euch noch mal!
Verena
Hallo,
Ich will ja nicht den Besserwisser rauskehren, aber zwei n:m-Tabellen
zwischen den gleichen Stammtabellen kann man auch in einer zusammen-
führen. Für den Leiter braucht es dann nur ein Flag.
gruss ekkehard
Hallo,
es kann aber mehrere Leiter geben, nicht nur einer.
ZitatIn unserem Fall ist es so, dass jede Gruppe mehrere Gruppenleiter haben kann und jedes Mitglied zu mehreren Gruppen gehören kann.
Hallo Klaus,
Also, wie gesagt, ich lasse mich immer gerne eines Besseren belehren,
aber das ist für mich kein Argument. Das Flag muss ja im Zusammenhang
mit einer Gruppe nicht eindeutig sein. Und selbst wenn eine Person
Leiter in mehreren Gruppen sein sollte, ist auch das mit einer einzigen
n:m abbildbar.
Oder habe ich da wirklich einen Knoten im Kopf?
gruss ekkehard
Hallo,
@Ekkehard
Zitatist auch das mit einer einzigen
n:m abbildbar.
kann ich nachvollziehen, jedoch braucht es eine weitere Tabelle "tblPersonenStatus" (oder Optiongruppe) und nicht nur ein Ja/Nein-Flag, wenn man alle Gegebenheiten berücksichten will.
tblPersonendaten
1: nur Mitglied
2: nur Teamleiter
3: Mitglied und gleichzeitig Teamleiter
Hallo Franz,
Danke, dass du mir im Prinzip zustimmst.
IMO spielt es dann auch keine Rolle ob der Status per Ja/Nein-Feld
oder mit einem FK bestimmt wird. Wobei eine Status-Tabelle nie ver-
kehrt sein sollte; im ursprünglichen Modell wäre das eine dritte n:m.
Welche Status nötig sind muss der TS entscheiden. Die von dir aufge-
zeigten braucht es m.E. nur, wenn es Teamleiter von ausserhalb einer
Gruppe gibt (Status 2).
gruss ekkehard
Hallo,
überedet, aber ich sehe da auch die einfachere Lösung von ekkehard.
Eine Tabelle für die Personen, eine Tabelle für die Gruppe und eine Tabelle für die Zuordnung Person zur Gruppe. In die 3 Tabelle ein Zahlenfeld (1=Gruppenmitlied, 2=Gruppenleiter). Das Zahlenfeld wird in einem Formular an eine Optionsgruppe gebunden. Under der Voraussetzung, dass der Gruppenleiter immer auch ein Mitglied der Gruppe ist.
Hallo,
die "einfachere Lösung" unterscheidet sich doch nur darin, dass 2 Status anstelle von 3 Verwendung finden... , dafür aber einer Einschränkung unterliegen. 8) ;)
aber wir diskutieren hier wirklich nur um ein Haar aus des Kaiser's Bart. ;D
Zitat von: MzKlMu am November 01, 2021, 12:03:54Hallo,
überedet, aber ich sehe da auch die einfachere Lösung von ekkehard.
Eine Tabelle für die Personen, eine Tabelle für die Gruppe und eine Tabelle für die Zuordnung Person zur Gruppe. In die 3 Tabelle ein Zahlenfeld (1=Gruppenmitlied, 2=Gruppenleiter). Das Zahlenfeld wird in einem Formular an eine Optionsgruppe gebunden. Under der Voraussetzung, dass der Gruppenleiter immer auch ein Mitglied der Gruppe ist.
Hallo Klaus,
das habe ich auch früher versucht (mit einem Ja/Nein Feld für die Gruppenleiter in der dritten Tabelle), aber habe dann Probleme bei den Formularen/Abfragen, wenn ich z. Bsp. alle Namen der Mitglieder und die zugehörigen Namen der Gruppenleiter sehen wollte. D
Sorry, habe aus Versehen Send gedrückt....
Eine Frage zu den Beziehungen-Bild (in #5). Brauche ich da nicht eine zweite Person Tabelle(alias), wenn ich die Namen der Gruppenmitglieder und die Namen der Gruppenleiter ausgegeben haben möchte?
Danke!
Verena
Hallo,
Ja,
aber warum änderst Du es nicht in die 3-Tabellen-Konstruktion (die von Ekkehard) ?
Dann wird es doch gleich einfacher.
Zitat von: VerenaM am November 02, 2021, 08:32:55aber habe dann Probleme bei den Formularen/Abfragen, wenn ich z. Bsp. alle Namen der Mitglieder und die zugehörigen Namen der Gruppenleiter sehen wollte. D
Hallo Verena,
die Frage ist wie du versuchst die Werte auszugeben.
Ob du jetzt zwei M:N Tabellen, oder die "einfachere" Version mit einer Tabelle verwendest ist dahingehend irrelevant. Ebenso ob zusätzliche Tabelle mit der Rolle spielt dafür keine Rolle - ich würde es aber trotzdem machen.
Vielleicht zeigst du hier mal ein einfaches Beispiel mit 2 Leitern und 2 Gruppen Mitgliedern und der Ausgabe wie du sie dir vorstellst.
Hallo zusammen!
Danke euch, dass ihr euch Zeit nehmt!
Hier ist eine Mini-DB BeispielDB.accdb.zip (nach Ekkehards Vorschlag) und die Query.
Am einem Mini-Eingabeformular habe ich mich auch versucht :-)
Hoffentlich, ist es richtig so.
Danke!
Verena
Hallo,
wenn Du jetzt auch noch eine Beziehung mit ref. Int. zwischen tblMembertype und tbl_Person_Group herstellst, ist das soweit ok...
Und das Formular als Formularansicht einstellen...
Hallo Verena,
Schau dir die Anlage an.
gruss ekkehard
Danke euch!
Es sind gute Anmerkungen, die ich gleich umsetzen kann!
Die Vorschläge von dir, Ekkehard, werde ich sicher miteinbauen, danke!
Dieses Projekt ist etwas größer, als nur die Gruppen und ihre Mitglieder, deswegen bin ich mir sicher, dass ich noch mal bei euch 'anklopfen' werde :-)
Vielen Dank und schöne Grüße,
Verena
ZitatDieses Projekt ist etwas größer, als nur die Gruppen und ihre Mitglieder,
Schon klar. Wenn du anhand des kleinen Beispiels aber das Prinzip der
Schlüsselfelder verstehst, wird alles einfacher.