Hierarchische Daten in Berichten

Hierarchische Daten Brrr … das ist doch das, was man sonst im TreeView-Steuerelement anzeigt, oder Schon richtig, nur: Mit hierarchischen Daten arbeiten Sie vermutlich tagtäglich, denn sobald eine oder mehrere 1:n-Beziehungen im Spiel sind, ergibt sich eine gewisse Hierarchie zwischen den in den Tabellen enthaltenen Daten. Und die sollen nun im Bericht angezeigt werden Nichts leichter als das: Sie brauchen nur eine oder mehrere Gruppierungen.

„Hierarchische Daten“ sind eigentlich nichts weiter als die Daten verknüpfter Tabellen: Zwischen Kunden und Projekten ergibt sich beispielsweise eine Hierarchie, an deren Spitze der Kunde steht, der ein oder mehrere Projekte unter sich vereint.

Damit die nachfolgenden Beispiele nicht allzu simpel ausfallen, greifen wir uns direkt eine Konstellation heraus, die mehr als eine Hierarchie-Ebene beherbergt: nämlich eine in der Projektzeiterfassung übliche Hierarchie mit dem Projekt an der Spitze.

Jedes Projekt enthält ein oder mehrere Aufgaben, die wiederum durch eine oder mehrere Tätigkeiten abgearbeitet werden.

Das Datenmodell der Beispieldatenbank finden Sie in Abb. 1.

abb001.tif

Abb. 1: Datenmodell einer Projektzeiterfassung

Ein passendes Frontend für diese Daten ist beispielsweise Outlook – weitere Informationen finden Sie im Beitrag Projektzeiterfassung mit Outlook 2007.

Davon abgesehen wollen wir an dieser Stelle auf die Beschreibung der Formulare zur Eingabe der Daten verzichten und den Schwerpunkt auf die Ausgabe der Daten per Bericht lenken.

Projekte, Aufgaben und Tätigkeiten im
Bericht

Voraussetzung für einen gelungenen Bericht ist immer die passende Datenherkunft: Sie muss alle Daten liefern, die der Bericht anzeigen soll. In diesem Fall umfasst die verwendete Abfrage alle Tabellen der Datenbank, nämlich tblProjekte, tblAufgaben und tblTaetigkeiten, und sieht wie in Abb. 2 aus.

abb002.tif

Abb. 2: Datenherkunft eines hierarchischen Berichts

Beachten Sie, dass Sie in eine Abfrage, die als Datenherkunft eines Berichts vorgesehen ist, erst gar keine Sortierungen einzubringen brauchen – der Bericht schert sich nicht darum, die Sortierungen und Gruppierungen legen Sie komplett im Bericht fest.

Der Bericht soll die Daten der Projekte, Aufgaben und Tätigkeiten ähnlich wie in einem TreeView-Steuerelement anzeigen. Das heißt, dass die jeweils untergeordneten Elemente etwas eingerückt dargestellt werden sollen.

Doch so weit ist es noch nicht: Zunächst müssen Sie überhaupt einmal einen Bericht erstellen und die neu erstellte Abfrage für die Eigenschaft Datenherkunft des Berichts angeben.

Wenn Sie dann den Menüeintrag Ansicht|Feldliste aufrufen, können Sie die in der Abfrage enthaltenen Felder in Form passender Steuerelemente in den Bericht ziehen (s. Abb. 3).

abb003.tif

Abb. 3: Der Bericht ist zum Hinzufügen der gebundenen Steuerelemente bereit.

Zuvor müssen Sie allerdings noch die benötigten Gruppierungen hinzufügen – und darüber sollten Sie sich im Vorfeld ein paar Gedanken machen. Klar ist, dass die Einträge der Tabelle tblTaetigkeiten als unterstes Element der Hierarchie im Detailbereich angezeigt werden. Die gewünschten Einträge können Sie daher schon in den Detailbereich ziehen.

Die Frage ist nur: Wohin mit den Beschriftungsfeldern Irgendwie soll man ja auch erkennen können, welches Feld welche Information enthält, und das ist zumindest für Außenstehende ohne Beschriftungen möglicherweise nur eingeschränkt möglich. Es gibt mindestens drei Möglichkeiten:

  • Die Beschriftung landet im Detailbereich, und zwar über dem jeweiligen Feld.
  • Die Beschriftung wird jeweils links vom Feld untergebracht.
  • Die Beschriftung soll nur einmal über dem ersten Element erscheinen.

Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!
Hier geht es zur Bestellung des Jahresabonnements des Magazins Access im Unternehmen:
Zur Bestellung ...
Danach greifen Sie sofort auf alle rund 1.000 Artikel unseres Angebots zu - auch auf diesen hier!
Oder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:

Schreibe einen Kommentar