Hallo,
in einer Kostenstelle-Tabelle sind für jede Kostenstelle 3 Mitarbeiter (MA) eingetragen, jeder für eine unterschiedliche Hierarchiestufe.
Genauer gesagt sind die Fremdschlüssel der MA eingetragen, deren jeweilige Daten in einer gemeinsamen MA-Tabelle enthalten sind (1:n Relation).
Mit einem (oder mehreren?) Select sollen die MA-Namen, Email etc. aus der MA-Tabelle in einer einzigen "erweiterten" Zieltabelle erscheinen.
Ich komme nur drauf, dass man das in 3 Schritten mit je einem "Insert" machen muss, um eine gemeinsame Tabelle zu erhalten.
Oder kennt jemand eine einfachere / elegantere Lösung, evtl. sogar in einem Schritt/Select?
VG HPS
Hallo,
Zitatin einer Kostenstelle-Tabelle sind für jede Kostenstelle 3 Mitarbeiter (MA) eingetragen, jeder für eine unterschiedliche Hierarchiestufe.
Das halte ich schon mal für den falschen Ansatz.
Das ist eine klassische n:m Beziehung mit 3 Tabellen und zwei 1:n Relationen. Die zugeordneten Hierarchiestufen werden dann in Datensätzen (je Stufe ein DS) erfasst.
Zeige bitte mal ein Bild des Beziehungsfensters.
Hi,
das ist ja gerade das Vertrackte: Es ist keine m:n Relation, sondern es sind 3 1:n Relationen.
Wenn man das mit der Beziehungsfunktion in Access eingibt, erzeugt Access selbst 2 zusätzliche Einzeltabellen der MA, siehe Bild anbei.
Das läuft dann auch wieder auf 3 Select... hinaus.
Ich vermute, es ist über klassische Beziehungen (und entsprechende Joins) nicht zu lösen, sondern man muss es "ausprogrammieren", z.B. indem man 3 mal hintereinander ein "Insert...into Erweiterte_Tabelle...from MA_Tabelle" macht. Dort sind dann die expandierten Namen, Emails etc. wie gewünscht enthalten.
Schön wäre es, wenn es eleganter ginge !?!
Gruss H.P.Screenshot 2025-12-14 111257.png
Hallo HPS,
Zitatdas ist ja gerade das Vertrackte: Es ist keine m:n Relation, sondern es sind 3 1:n Relationen.
Das meinte Klaus damit, daß das so nicht i.O. ist. Richtig normalisiert ist das eine m:n Relation und das solltest du dann auch ändern. Dann gibt es auch keine Problem mehr mit solchen Auswertungen.
Knobbi38
Hallo,
ZitatEs ist keine m:n Relation, sondern es sind 3 1:n Relationen.
Eben und das solltest Du umbauen in eine n:m Beziehung. Und dazu fehlt dann die 3. Tabelle zur Zuordung der Hierarchiestufe.
Der Aufbau der Tabelle Kost_Erw ist komplett falsch.
Auch Feldnamen wie Mark5b, Mark5c deuten auf einen falschen Aufbau hin. Ebenso Stand1 (gibt es da auch Stand2?).
Wenn der Aufbau der DB vollständig normalisert wird, kannst Du Dein Problem mit einer einfachen Abfrage lösen.
Und in einer korrekt aufgebauten DB sollte für alle Beziehungen referentielle Integrität eingestellt werden, sonst hast Du keine Datenbank, sondern einen Datenhaufen. Nach meiner Auffassung ist ein Umbau der DB unerlässlich.
Zeige mal ein Bild es Beziehungsfenster mit vollständig sichtbaren Feldern.
Jetzt glaube ich, habe ich es verstanden.
Es gibt eine Zuordnungstabelle (m:n), welche die Kostenstellen den MA zuordnet und die als zusätzliches Attribut (!) die Hierarchieebene enthält.
Werde es später mal ausprobieren, muss aber gerade weg...
VG HPS
Hallo,
hat etwas gedauert...Ich habe die Formulare umgebaut, genauer gesagt spezielle Unterformulare eingebaut
(man bekommt ja 3 Ergebnisse aus der m:n Beziehung für eine Kostenstelle; Darstellung deshalb als Tabelle im Formular).
Die Versorgung mit "Comboboxen" zur Änderung oder Neueingabe war auch nicht ganz einfach (man muss
erst mal rausbekommen, wann das mit den "automatischen Updates" der Tabellen und Formularfelder klappt...)
Die m:n Tabelle habe ich erst mit Excel "grob vorbesetzt"(Spalten "Kostenstelle" und "Ebene"), diese importiert und dann die Personenzuordnung in Access gemacht (immerhin 2100 Datensätze).
Da bei referentieller Integrität keine "Leereinträge" in der m:n Tabelle akzeptiert werden, musste ich einen "Dummy-Benutzer" anlegen.
Dies ist nötig, da eine Kostenstelle zunächst von der Buchhaltung angelegt wird und die tatsächliche Mitarbeiter-Zuordnung erst später von den Fachabteilungen gemacht wird.
Auf jeden Fall vielen Dank für eure Tipps !!!
Um es mit Lothar Matthäus zu sagen: "Again what learned..."
VG HPS
Hallo HPS,
kannst du bitte nochmal das aktuelle Beziehungsbild der Tabellen, insbesondere deiner neuen m:n Beziehung, hier hochladen?
Knobbi38
Hallo,
ZitatDa bei referentieller Integrität keine "Leereinträge" in der m:n Tabelle akzeptiert werden, musste ich einen "Dummy-Benutzer" anlegen.
Da würde ich behaupten wollen, dass da entweder mit den Beziehungen etwas (noch) nicht
stimmt, oder der Formularaufbau.
Du solltest ein HFo "Kostenstellen" haben. Das UFo für die Zuordnung der MA muss dann
als Datenquelle die n:m-Tabelle haben, und über die KostenstellenID verknüpft sein.
Der MA-FK in der n:m muss auf "Eingabe erforderlich" = Nein eingestellt sein.
Beim Anlegen einer neuen KS bleibt das UFo zunächst leer bis du aus einem Kombi,
das die MA anzeigt einen MA auswählst. Durch die Verknüpfung wird dabei der KS-FK
automatisch geschrieben.
Der Dummy-MA ist überflüssig.
gruss ekkehard
@Knobbi38 Das mache ich gerne, Bezieh.Tabelle ist ZUST (Zuständigkeiten).
Bild anbei.
@Beaker: Das muss ich mir erst noch genau anschauen.
Wie viele vermuten, handelt es sich bei dem Projekt um die Überführung einer "großen" Excel-Datei in eine Access-Datenbank.
Deshalb gibt es auch etliche Markierfelder "Mark", bei denen noch Ergänzungen in der DB zu machen sind, und natürlich auch noch andere "Ungereimtheiten, wo noch etwas zu machen ist.Screenshot 2025-12-18 125625.png
Gruß HPS
Zitat von: Hpseel am Dezember 18, 2025, 00:01:18Da bei referentieller Integrität keine "Leereinträge" in der m:n Tabelle akzeptiert werden, musste ich einen "Dummy-Benutzer" anlegen.
Da stimmen möglicherweise die Eigenschaften nicht. Normalerweise wird ein NULL-Wert immer akzeptiert.
Knobbi38
Hallo,
wie bereits gesagt, ist es problemlos möglich in der Zust Tabelle Datensätze anzulegen die keinen Eintrrag (=Null) in den FS Feldern haben. Der häufigste Fehler in diesem Zusammenhang ist der Standartwert in den FS Feldern. Der wird von Acccess automatisch mit 0 (der Zahl) vorbelegt. Und der muss gelöscht werden.
Zitatist der Standartwert in den FS Feldern
Jau, an den hatte ich nicht gedacht. Ist bei mir immer das Erste, das
beim Tabellendesign rausfliegt.
Ich habe jetzt mal in der ZUST Tabelle für eine Kostenstelle den FS für PERS (= P_ID) gelöscht.
Die ref. Integrität meckert dabei nicht.
Aber wenn ich das Select... join... (mit der m:n Beziehung) wie bisher mache, bekomme ich für diese Kostenstelle keine Ergebnisse,
wogegen ich schon welche bekomme, wenn die Felder mit "1" (für den Dummy-MA) belegt sind.
Also ist der "Dummy-MA" doch nützlich?
Oder habe ich etwas nicht richtig "eingestellt"?
Welcher Select Join?
@Hpseel Die Frage stelle ich mir auch. Du brauchst dafür doch keinen JOIN, -
der ergibt sich in diesem Fall durch die Verknüpfung von UFo zu HFo
über die KostenstellenID (HFO) und den FK darauf im UFo.
Also HFo = Tabelle "Kostenstellen"; - was willst du da dazu "joinen"?
Das UFo bekommt die n:m-Tabelle als Datenherkunft, und auch hier wird
kein Join benötigt. Ein Kombi darin, das die MA-Tabelle als DS-Herkunft
hat und an den MA-FK gebunden ist.
gruss ekkehard
Noch zur Ergänzung.
Durch die Verknüpfung wird bei Zuordnung eines MA (neuer DS im UFo) i.Ü.
der FK auf die Kostenstelle automatisch aus dem HFo übernommen.
Hi,
für die Darstellung in den Formularen gibt es keinen Select .. JOIN... HF hat seine Datenherkunft und das Ufo hat die m:n-Tabelle als Datenherkunft.
Synchronisiert wird über "Verknüpfen von/nach" über HF/UF.
Insofern werden die Kostenstellen im HF angezeigt, und das UFO bleibt zunächst mal leer. Baust du da einen INNER-JOIN mit ein, werden natürlich nur vorhandene Kombinationen angezeigt. Je nachdem wo das (SELECT.. JOIN) einsetzt, kann man das auch über einen OUTER-JOIN beheben. Wie schon geschrieben, der Dummy ist überflüssig.
Edit: Gerade entdeckt, das wurde bereits gesagt.