Mitarbeiter-Hierarchie in 1 Tabelle

[Hpseel]

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

[MzKlMu]

Hallo,

in 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.

[Hpseel]

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.Sie dürfen in diesem Board keine Dateianhänge sehen.

[Knobbi38]

Hallo HPS,

das 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

[MzKlMu]

Hallo,

Es 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.

[Hpseel]

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

[Hpseel]

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

[Knobbi38]

Hallo HPS,

kannst du bitte nochmal das aktuelle Beziehungsbild der Tabellen, insbesondere deiner neuen m:n Beziehung, hier hochladen?

Knobbi38

[Beaker s.a.]

Hallo,

Da 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

[Hpseel]

@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.Sie dürfen in diesem Board keine Dateianhänge sehen.

Gruß HPS

[Knobbi38]

Da 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

[MzKlMu]

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.

[Beaker s.a.]

ist der Standartwert in den FS Feldern

Jau, an den hatte ich nicht gedacht. Ist bei mir immer das Erste, das
beim Tabellendesign rausfliegt.

[Hpseel]

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"?

[Knobbi38]

Welcher Select Join?