{"id":55000750,"date":"2010-12-01T00:00:00","date_gmt":"2020-05-22T22:08:31","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=750"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Reflexive_Daten_in_Berichten","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Reflexive_Daten_in_Berichten\/","title":{"rendered":"Reflexive Daten in Berichten"},"content":{"rendered":"

\"\"<\/p>\n

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.<\/b><\/p>\n

Vorbereitungen<\/b><\/p>\n

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<\/b>, die lediglich die beiden Felder MitarbeiterID <\/b>und Mitarbeiter <\/b>enthält (s. Bild 1), sowie eine Tabelle zur Herstellung der Hierarchie.<\/p>\n

\"pic001.png\"<\/p>\n

Bild 1: Die Mitarbeitertabelle …<\/span><\/b><\/p>\n

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

\"pic002.png\"<\/p>\n

Bild 2: … und die Tabelle zum Herstellen der Hierarchie<\/span><\/b><\/p>\n

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<\/b>, Prozedur HierarchieSchreiben<\/b>).<\/p>\n

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.<\/p>\n

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.<\/p>\n

\"pic003.png\"<\/p>\n

Bild 3: Beispiel für die hierarchische Darstellung von Mitarbeitern im Bericht<\/span><\/b><\/p>\n

Berichte und Rekursion<\/b><\/p>\n

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.<\/p>\n

Datenherkunft vorbereiten<\/b><\/p>\n

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.<\/p>\n

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.<\/p>\n

\"pic004.png\"<\/p>\n

Bild 4: Entwurfsansicht der Tabelle zum Speichern der Informationen zur hierarchischen Darstellung im Bericht<\/span><\/b><\/p>\n

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

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

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<\/a>.<\/p>\n

\"pic005.png\"<\/p>\n

Bild 5: Diese Daten stellt der Bericht hierarchisch geordnet dar.<\/span><\/b><\/p>\n

Hierarchiedaten schreiben<\/b><\/p>\n

Das Schreiben der Mitarbeiter in die Tabelle tblHierarchieBericht <\/b>übernehmen zwei Routinen, von denen die eine sich rekursiv selbst aufruft. Die erste Routine heißt HierarchieErmitteln <\/b>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.<\/p>\n

Listing 1: Diese Prozedur startet die rekursive Zusammenstellung der Datenherkunft.<\/p>\n

Public Sub HierarchieErmitteln()\r\n    Dim db As DAO.Database\r\n    Dim rst As DAO.Recordset\r\n    Dim intEbene As Integer\r\n    Set db = CurrentDb\r\n    db.Execute "DELETE FROM tblHierarchieBericht", dbFailOnError\r\n    Set rst = db.OpenRecordset("qryHierarchie_Top")\r\n    intEbene = 0\r\n    Do While Not rst.EOF\r\n         db.Execute "INSERT INTO tblHierarchieBericht(MitarbeiterID, Ebene) VALUES(" _\r\n            & rst!MitarbeiterID & ", " & intEbene & ")"\r\n        HierarchieErmittelnRekursiv db, rst!MitarbeiterID, intEbene + 1\r\n        rst.MoveNext\r\n    Loop\r\nEnd Sub<\/pre>\n
\"pic006.png\"<\/p>\n
Bild 6: Diese Abfrage liefert alle Mitarbeiter der obersten Ebene.<\/span><\/b><\/p>\n
<\/p>\n
Das Zusammenstellen einer solchen Abfrage ist nicht gerade trivial: Sie soll alle Mitarbeiter liefern, für die es in der Tabelle tblHierarchie <\/b>keinen Eintrag im Feld UntergebenerID <\/b>gibt. Natürlich ist es kein Problem, Mitarbeiter mit einem bestimmten Vorgesetzten zu ermitteln – dafür brauchen wir einfach nur die MitarbeiterID <\/b>des entsprechenden Vorgesetzten als Kriterium für das Feld VorgesetzterID <\/b>zu einer Abfrage über die beiden Tabellen tblMitarbeiter <\/b>und tblHierarchie <\/b>hinzuzufügen.<\/p>\n
Die Tabelle tblHierarchie <\/b>enthält aber nur Datensätze mit vollständigen Paaren aus Vorgesetztem und Untergebenem. Um aus allen Datensätzen der Tabelle tblMitarbeiter <\/b>alle Einträge zu ermitteln, die keinen Vorgesetzten haben, müssen wir also alle Mitarbeiter finden, die nicht als Untergebener in der Tabelle tblHierarchie <\/b>auftauchen.<\/p>\n
Die Abfrage führt die beiden Tabellen tblMitarbeiter <\/b>und tblHierarchie <\/b>über eine Verknüpfung zusammen, die das Primärschlüsselfeld MitarbeiterID <\/b>mit dem Fremdschlüsselfeld UntergebenerID <\/b>verknüpft, aber zusätzlich alle Datensätze der Tabelle tblMitarbeiter <\/b>berücksichtigt, die nicht über UntergebenerID <\/b>mit einem der Datensätze der Tabelle tblHierarchie <\/b>verknüpft sind. Und genau diese zeigt die Abfrage an, wenn Sie als Kriterium für UntergebenerID <\/b>den Ausdruck Ist Null <\/b>angeben.<\/p>\n
Der Rest der Routine HierarchieErmitteln <\/b>ist schnell erklärt: Sie durchläuft alle Datensätze dieser Abfrage und legt für jeden einen neuen Datensatz in der Tabelle tblHierarchieBericht <\/b>an. Der Wert des Feldes Ebene <\/b>wird dabei auf 0 <\/b>eingestellt. Außerdem ruft die Routine die rekursive Prozedur HierarchieErmittelnRekursiv <\/b>auf und übergibt den Verweis auf die aktuelle Datenbank, die MitarbeiterID <\/b>des soeben eingetragenen Mitarbeiters sowie den um eins erhöhten Wert der Variablen intEbene<\/b>.<\/p>\n
Die Routine HierarchieErmittelnRekursiv <\/b>funktioniert prinzipiell genau so, nur dass sie eine andere Datenherkunft verwendet und sich selbst aufruft (s. Listing 2<\/span>).<\/p>\n
Listing 2: Der rekursive Teil des Codes zum Ermitteln der Hierarchie<\/p>\n
Public Sub HierarchieErmittelnRekursiv(db As DAO.Database, lngMitarbeiterID As Long, intEbene As Integer)\r\n    Dim rst As DAO.Recordset\r\n    Set rst = db.OpenRecordset("SELECT * FROM tblHierarchie WHERE VorgesetzterID = " & lngMitarbeiterID, dbOpenDynaset)\r\n    Do While Not rst.EOF\r\n         db.Execute "INSERT INTO tblHierarchieBericht(MitarbeiterID, Ebene) VALUES(" _\r\n            & rst!UntergebenerID & ", " & intEbene & ")"\r\n        HierarchieErmittelnRekursiv db, rst!UntergebenerID, intEbene + 1\r\n        rst.MoveNext\r\n    Loop\r\nEnd Sub<\/pre>\n
Die Datenherkunft besteht hier schlicht aus allen Datensätzen der Tabelle tblHierarchie<\/b>, deren Feld VorgesetzterID <\/b>den Wert der übergebenen Variablen MitarbeiterID <\/b>enthält – also alle Hierarchiebeziehungen zwischen Vorgesetztem und Untergebenem, für welche die aufrufende Prozedur soeben einen Datensatz in die Tabelle tblHierarchieBericht <\/b>geschrieben hat.<\/p>\n
Der folgende Aufruf erfolgt dann wiederum mit dem Untergebenen des aktuellen Datensatzes der Tabelle tblHierarchie<\/b>. Auf diese Weise landen schließlich alle Mitarbeiter in Form eines Verweises im Feld MitarbeiterID <\/b>der Tabelle tblHierarchieBericht<\/b>.<\/p>\n
Bericht mit rekursiven Daten füllen<\/b><\/p>\n
Der Bericht schließlich verwendet die Tabelle tblHierarchieBericht <\/b>als Datenherkunft. Am besten rufen Sie die Prozedur HierarchieErmitteln<\/b> beim Öffnen des Berichts auf, also beispielsweise in der Ereignisprozedur Beim Laden<\/b>. Die Prozedur sieht dann schlicht so aus:<\/p>\n
Private Sub Report_Load()\r\n    HierarchieErmitteln\r\nEnd Sub<\/pre>\n
Auch der Aufbau des Berichts ist schnell erledigt. Sie brauchen lediglich die beiden Felder Mitarbeiter <\/b>und Ebene <\/b>der Datenherkunft zum Detailbereich des Entwurfs hinzuzufügen (s. Bild 7). Dabei können Sie das Feld Ebene <\/b>sogar noch unsichtbar machen (Eigenschaft Sichtbar <\/b>auf Nein <\/b>einstellen), da es nur zur Berechnung des Abstands des Mitarbeiternamens vom linken Spaltenrand dient und nicht angezeigt werden soll.<\/p>\n
\"pic007.png\"<\/p>\n
Bild 7: Entwurfsansicht des Berichts zur Anzeige der Mitarbeiterhierarchie<\/span><\/b><\/p>\n
Nun fehlen nur noch zwei Schritte zur hierarchischen Mitarbeiter-Darstellung:<\/p>\n