Reflexive Daten in Berichten

Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.

Reflexive Daten kommen immer mal wieder vor – bei der Abbildung der Mitarbeiterhierarchie, in Stücklisten oder auch in Aufgabenlisten. Dass das TreeView-Steuerelement das geeignete Mittel zur Abbildung dieser Strukturen in Formularen ist, hat sich mittlerweile herumgesprochen. Aber wie bringt man diese Daten in Berichten unter Dieser Beitrag zeigt, wie Sie Daten aus reflexiv verknüpften Tabellen für die Anzeige in Berichten vorbereiten.

Vorbereitungen

Nehmen wir doch einfach das am meisten zitierte Beispiel: Die Hierarchie von Mitarbeitern. Dabei verwenden wir eine so einfach wie möglich gestaltete Mitarbeitertabelle namens tblMitarbeiter, die lediglich die beiden Felder MitarbeiterID und Mitarbeiter enthält (s. Bild 1), sowie eine Tabelle zur Herstellung der Hierarchie.

pic001.png

Bild 1: Die Mitarbeitertabelle …

Diese heißt tblHierarchie und enthält neben dem Primärschlüsselfeld HierarchieID zwei Fremdschlüsselfelder mit Verweisen auf die Tabelle tblMitarbeiter. Diese heißen VorgesetzterID und UntergebenerID und bringen jeweils ein Paar zweier hierarchisch verbundener Mitarbeiter zusammen (s. Bild 2).

pic002.png

Bild 2: … und die Tabelle zum Herstellen der Hierarchie

Wir gehen an dieser Stelle davon aus, dass es eine Prüfung gibt, die dafür sorgt, dass beim Zuweisen von Vorgesetzten und Untergebenen keine Zirkelbezüge entstehen. Im Falle der Beispieldatenbanken sorgte dafür eine kleine Routine, welche die Mitarbeiter nach dem Zufallsprinzip jeweils einem anderen, bereits in der Hierarchie verankerten Mitarbeiter unterordnete (s. Beispieldatenbank, Modul mdlHierarchie, Prozedur HierarchieSchreiben).

Wie aber sollen wir die hierarchisch aufgebaute Mitarbeiterstruktur in einem Bericht abbilden Grundsätzlich sollte dies in einem dem TreeView-Steuerelement ähnlichen Aufbau geschehen. Das heißt, dass die obersten Elemente der Hierarchie ganz links stehen und die untergeordneten Elemente jeweils rechts unterhalb angeordnet werden.

Ein Beispiel für das gewünschte Ergebnis zeigt der Bericht in Bild 3. Hier steht einer der Mitarbeiter der obersten Ebene ganz links oben und rechts darunter folgen die Untergebenen dieses Mitarbeiters.

pic003.png

Bild 3: Beispiel für die hierarchische Darstellung von Mitarbeitern im Bericht

Berichte und Rekursion

Berichte und Rekursion – das schließt sich grundsätzlich aus. Berichte werden linear aus der zugrunde liegenden Datenherkunft gefüllt, wobei es gegebenenfalls noch Gruppierungsebenen gibt. Das Füllen eines Berichts durch rekursives Durchlaufen der Datenherkunft ist nicht vorgesehen – zumindest nicht, wenn Sie eine herkömmliche Datenherkunft verwenden möchten. Eine Alternative hierzu schauen wir uns später an. Zunächst jedoch bleiben wir bei der klassischen Datenherkunft.

Datenherkunft vorbereiten

Eine Datenherkunft, die den Bericht wie in der Abbildung füllen soll, muss mindestens zwei Informationen liefern: den Namen des jeweiligen Mitarbeiters und die Hierarchieebene, der dieser angehört, beziehungsweise einen Hinweis auf die Anordnung. Wenn man sich die Abbildung genau ansieht, scheint es zu reichen, wenn man die Mitarbeiter in der richtigen Reihenfolge und mit entsprechender Einrückung darstellt.

Diesen Ansatz wollen wir verfolgen und erstellen zunächst eine Tabelle, welche die benötigten Informationen enthält. Diese sieht wie in Bild 4 aus.

pic004.png

Bild 4: Entwurfsansicht der Tabelle zum Speichern der Informationen zur hierarchischen Darstellung im Bericht

Das Feld MitarbeiterHierarchieID dient als Primärschlüssel und als Sortierkriterium. Wir müssen die Hierarchie-Informationen also gleich in der richtigen Reihenfolge speichern. Das Feld MitarbeiterID speichert schlicht einen Verweis auf das Primärschlüsselfeld der Tabelle tblMitarbeiter. Ebene schließlich enthält einen Zahlenwert, der die fehlende Information liefert.

Die Informationen aus den Tabellen tblMitarbeiter und tblHierarchie müssen nun so in der Tabelle tblHierarchieBericht gespeichert werden, dass die Mitarbeiter ohne Vorgesetzten im Feld Ebene den Wert 0 erhalten. Ein Mitarbeiter, der einem solchen Mitarbeiter der obersten Hierarchiestufe direkt untergeben ist, erhält im Feld Ebene den Wert 1 und wird in der Reihenfolge der Datensätze direkt unterhalb des Vorgesetzten einsortiert.

Wenn dieser wiederum Untergebene hat, folgen diese als Nächstes und so weiter. Wichtig ist, dass jeder Zweig zuerst bis zur untersten Ebene abgearbeitet wird, bevor der nächste Zweig der gleichen Ebene in der Tabelle erscheint. Die Werte für die ersten Einträge des Berichts aus Bild 5.

pic005.png

Bild 5: Diese Daten stellt der Bericht hierarchisch geordnet dar.

Hierarchiedaten schreiben

Das Schreiben der Mitarbeiter in die Tabelle tblHierarchieBericht übernehmen zwei Routinen, von denen die eine sich rekursiv selbst aufruft. Die erste Routine heißt HierarchieErmitteln und sieht wie in Bild 6). Diese Abfrage liefert alle Mitarbeiter, die keinen übergeordneten Mitarbeiter besitzen und somit in der obersten Ebene der Hierarchie stehen.

Listing 1: Diese Prozedur startet die rekursive Zusammenstellung der Datenherkunft.

Public Sub HierarchieErmitteln()
    Dim db As DAO.Database
    Dim rst As DAO.Recordset
    Dim intEbene As Integer
    Set db = CurrentDb
    db.Execute "DELETE FROM tblHierarchieBericht", dbFailOnError
    Set rst = db.OpenRecordset("qryHierarchie_Top")
    intEbene = 0
    Do While Not rst.EOF
         db.Execute "INSERT INTO tblHierarchieBericht(MitarbeiterID, Ebene) VALUES(" _
            & rst!MitarbeiterID & ", " & intEbene & ")"
        HierarchieErmittelnRekursiv db, rst!MitarbeiterID, intEbene + 1
        rst.MoveNext
    Loop
End Sub

pic006.png

Bild 6: Diese Abfrage liefert alle Mitarbeiter der obersten Ebene.

Das Zusammenstellen einer solchen Abfrage ist nicht gerade trivial: Sie soll alle Mitarbeiter liefern, für die es in der Tabelle tblHierarchie keinen Eintrag im Feld UntergebenerID gibt. Natürlich ist es kein Problem, Mitarbeiter mit einem bestimmten Vorgesetzten zu ermitteln – dafür brauchen wir einfach nur die MitarbeiterID des entsprechenden Vorgesetzten als Kriterium für das Feld VorgesetzterID zu einer Abfrage über die beiden Tabellen tblMitarbeiter und tblHierarchie hinzuzufügen.

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

Testzugang

eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel

diesen und alle anderen Artikel mit dem Jahresabo

Schreibe einen Kommentar