Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 6/2010.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Zusammenfassung

Stellen Sie hierarchische Daten etwa von Mitarbeitern in Berichten dar.

Techniken

Berichte, VBA

Voraussetzungen

Access 2000 und höher

Beispieldateien

HierarchischeBerichte.mdb

Shortlink

www.access-im-unternehmen.de/750

Reflexive Daten in Berichten

André Minhorst, Duisburg

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. Abb. 1), sowie eine Tabelle zur Herstellung der Hierarchie.

pic001.png

Abb. 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. Abb. 2).

pic002.png

Abb. 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 Abb. 3. Hier steht einer der Mitarbeiter der obersten Ebene ganz links oben und rechts darunter folgen die Untergebenen dieses Mitarbeiters.

pic003.png

Abb. 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 Abb. 4 aus.

pic004.png

Abb. 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 Abb. 3 zeigt die Datenblattansicht der Tabelle tblHierarchieBericht aus Abb. 5.

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 Listing 1 aus. Die Prozedur löscht zunächst alle Datensätze aus der Tabelle tblHierarchieBericht, da diese ja anschließend neu gefüllt werden soll. Daraufhin erstellt sie ein neues Recordset-Objekt auf Basis der Abfrage qryHierarchieTop (s. Abb. 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

Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

Sind Sie Abonnent?Jetzt einloggen ...
 

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

© 2003-2015 André Minhorst Alle Rechte vorbehalten.