Seit Jahren ist der Parent-Child-Editor Bestandteil von DeltaMaster. Mit ihm können Parent-Child-Strukturen (wie beispielsweise Konten oder Stücklisten) einfach manuell bearbeitet werden, wenn diese unpassend aus dem Quellsystem geliefert werden oder eigene Strukturen aufgebaut werden sollen. Jetzt hat der Parent-Child-Editor auch einen Platz in DeltaMaster ETL gefunden und kann leicht über die Anwendung „DeltaMaster ETL.das“ konfiguriert werden. Dieser Beitrag gibt einen Überblick über die Oberfläche und den Einsatz des Parent-Child-Editors am Beispiel einer Organisationsstruktur von Mitarbeitern.

Anwendungsbereiche

Der Parent-Child-Editor wird immer dann verwendet, wenn Strukturen abgebildet werden sollen, die so nicht im Vorsystem existieren und deren Inhalte häufig angepasst oder ergänzt werden müssen. Mögliche Anwendungsbereiche sind neben dem Abbilden von Organisationsstrukturen und Mitarbeitern auch das Zusammenfassen von Konten in veränderbaren Hierarchien sowie das Planen von Projekten und Projektschritten. Einfach installiert und sorgfältig konfiguriert, verkleinert sich der Wartungsaufwand durch den Einsatz des Parent-Child-Editors. Der große Vorteil: DeltaMaster-Anwender sind jederzeit ohne Datenbankkenntnisse in der Lage, bestehende Parent-Child-Strukturen eigenständig anzupassen.

Installation der ETL Solution

Um den Parent-Child-Editor mit der Anwendung „DeltaMaster ETL.das“ (kurz „ETL.das“) verwenden zu können, muss die Installation einmalig über die Anwendung „DeltaMaster.ETL.exe“ (kurz „ETL.exe“) ausgeführt werden. Die Solution „DeltaMaster Parent-Child-Editor“ erfordert keine zusätzliche Lizenz und wird standardmäßig im DeltaMaster-ETL-Installationspaket mitgeliefert. Für die Verwendung des Parent-Child-Editors ist eine Planungslizenz erforderlich.

Zur Installation über die „ETL.exe“ müssen wie gewohnt Server und Datenbank ausgewählt werden.

Abbildung 1: Ausschnitt „ETL.exe“

 
Im nächsten Schritt wird im Menü der Befehl „Install Solution“ aufgerufen, wo für die Installation die Datei „DeltaMaster Parent-Child-Editor.etlsln“ ausgewählt wird.

Abbildung 2: File-Menü in „ETL.exe“

 
Diese Datei findet sich im Installationsverzeichnis von DeltaMaster ETL im Ordner „Solutions“, Unterordner „DeltaMaster Parent-Child-Editor“.

Abbildung 3: Speicherort des Parent-Child-Editors im Ordner „Solution“

 
Die erfolgreiche Installation wird im Log-Fenster angezeigt.

Abbildung 4: Log nach erfolgreicher Installation

Konfiguration einer Parent-Child-Hierarchie

Nach Installation der Solution kann in der Anwendung „ETL.das“ die Konfiguration einer Parent-Child-Hierarchie vorgenommen werden. Im Ordner „Manage Solutions & Content“ unter „DeltaMaster Parent-Child-Editor“ sind alle Konfigurationsberichte enthalten, die hierfür nötig sind.

Für unser Beispiel nehmen wir an, wir wollen eine klassische Mitarbeiterhierarchie abbilden, in der jeder Mitarbeiter seinem Vorgesetzten gemäß Organigramm zugeordnet wird.

Bericht „Model“

Im Bericht „Model“ definieren wir zunächst allgemeine Parameter und vergeben eine ID sowie einen Namen für das Modell. Dann tragen wir die Datenbank ein, in der die Tabellen für die Definition der Dimension erstellt werden sollen. Das gewünschte Schema kann ebenfalls mitgegeben werden, der hinterlegte Standardwert ist „dbo“. Das Modell dient der Strukturierung, vor allem falls mehrere Dimensionen angelegt werden oder mehrere Datenbanken als Ziel definiert werden sollen.

Abbildung 5: Beispiel für den Bericht „Model“

Bericht „Dimensions“

Im Bericht „Dimensions“ werden für unser definiertes Model die zugehörigen Dimensionen mit ID und Name eingetragen. In unserem Beispiel brauchen wir nur die Dimension „Mitarbeiter“.

Abbildung 6: Beispiel für den Bericht „Dimensions“

Bericht „Dimension Attributes“

Im Bericht „Dimension Attributes“ können Attribute definiert werden, die später für jedes Element erfasst werden sollen, unabhängig davon, auf welcher Ebene es sich befindet. Für unser Beispiel, bei dem wir Mitarbeiter ihren Vorgesetzten zuordnen wollen, könnten wir bspw. Geburtsdatum, Geschlecht und Eintrittsdatum jedes Mitarbeiters hinterlegen. Hier definieren wir neben ID und Name des Attributs auch noch den gewünschten Datentyp und können entscheiden, ob ein eingegebener Wert entsprechend auch für alle darunterliegenden Elemente gelten soll. In unserem Beispiel sollen Einträge nicht vererbt werden, da beispielsweise das Geschlecht des Vorgesetzten nicht auch zwangsläufig dem Geschlecht der zugeordneten Mitarbeiter entspricht. Optional könnten wir auch einen Default-Eintrag vorgeben, auf den wir hier allerdings verzichten können.

Abbildung 7: Beispiel für Bericht „Dimension Attributes“

Bericht „Element Types“

Im Bericht „Element Types“ tragen wir nun die verschiedenen Ebenen ein, die wir für unsere Hierarchie verwenden wollen. Grundsätzlich sind in unserem Fall alle Vorgesetzten auch „Mitarbeiter“. Die Unterscheidung der Ebenen ergibt jedoch Sinn, wenn wir zusätzliche Attribute erfassen wollen, die sich je nach Ebene unterscheiden (siehe auch Abschnitt Bericht „Element Type Attributes“). Neben ID und Name des Elementtyps entscheiden wir uns hier auch für einen Elementtypen als Top-Element unserer Hierarchie und legen die Sortierung der Elemente unterhalb dieses Elementtyps fest. Über die manuelle Sortierung können wir Elemente später per Drag-and-drop selbst sortieren, die alphabetische Sortierung erfolgt automatisch. Die Spalten „Definition Table“ sowie „Reference Column“ werden zur besseren Orientierung in der relationalen Datenbank angezeigt. Über die Spalte „Icon“ kann das Icon zur Visualisierung der Ebene festgelegt werden. In unserem Beispiel tragen wir nichts ein und verwenden den Default („Level1” entspricht einem 1-Punkt-Icon, „Level2” einem 2-Punkt-Icon usw., zusätzlich steht noch „Level 0” zur Verfügung mit Darstellung in Form eines Ordner-Icons).

Abbildung 8: Beispiel für den Bericht „Element Types“

Bericht „Element Type Attributes“

Im Bericht „Element Type Attributes“ können wir analog zu den „Dimension Attributes“ Eigenschaften hinterlegen, die nur für bestimmte Ebenen gelten sollen. So entscheiden wir uns im Beispiel hierfür, dass für den Geschäftsführer sein Zuständigkeitsbereich interessant ist, für den Mitarbeiter mit Leitungsfunktion die von ihm geleitete Organisationseinheit und beim Mitarbeiter ohne Leitungsfunktion die Position dieses Mitarbeiters. Auch hier gilt es, neben ID und Name noch den Datentyp sowie optional einen Default zu definieren.

Abbildung 9: Beispiel für den Bericht „Element Type Attributes“

Bericht „Relationships“

Im Bericht „Relationships“ wird definiert, welche Elementtypen unter welchen anderen Elementtypen erlaubt sind. Unter dem Geschäftsführer erlauben wir Mitarbeiter mit Leitungsfunktion, aber auch Mitarbeiter ohne Leitungsfunktion (z. B. seine persönliche Assistenz). Mitarbeiter mit Leitungsfunktion können ebenfalls hierarchisch sowohl über anderen Mitarbeitern mit Leitungsfunktion stehen als auch über Mitarbeitern ohne Leitungsfunktion. Unterhalb eines Mitarbeiters ohne Leitungsfunktion ist keine weitere Ebene erlaubt, daher erfolgt hier auch kein Eintrag.

Abbildung 10: Beispiel für den Bericht „Relationships“

Bericht „Create Structure“

Ist die Definition des Modells abgeschlossen, kann im Bericht „Create Structure“ der Aufbau der relationalen Objekte einer ausgewählten Dimension gestartet werden. Wenn eine neue Struktur aufgebaut wird oder eine leere existierende Struktur geändert wird, muss für „Delete Existing Data“ kein Eintrag vorgenommen werden. Wenn in der Struktur bereits Elemente angelegt worden sind, muss der Haken für „Delete Existing Data“ explizit gesetzt werden. Eine Änderung der Struktur hat immer ein Löschen sämtlicher Inhalte zur Folge. Sollen die Inhalte erhalten bleiben, ist vorab ein manuelles Backup der entsprechenden relationalen Objekte anzulegen, mit dem die Daten im Anschluss auch manuell wiederhergestellt werden können. Nach erfolgreicher Ausführung ist im Bericht „Create Structure“ kein Eintrag mehr zu sehen.

Abbildung 11: Beispiel für den Bericht „Create Structure“

Bearbeiten der Dimensionselemente

Nachdem wir unsere Dimension erfolgreich konfiguriert haben, können die Elemente in DeltaMaster gepflegt werden. Dafür können wir eine relationale Anwendung verwenden oder eine multidimensionale Anwendung an das relationale Modell binden.

Voraussetzungen und Einstellungen

In der Anwendung muss die Planungsfunktion für die „Dateneingabe“ in den Optionen aktiviert sein.

Abbildung 12: Aktivierung der Planungsfunktion

 
Um die vorgenommenen Einträge direkt nach Eingabe zu sehen, muss in den Optionen unter „System“ die Verwendung des Caches deaktiviert sein. Anderenfalls werden Einträge erst sichtbar, wenn der Bericht mittels F9 neu berechnet wird.

Abbildung 13: DeltaMaster-Optionen

 
Jetzt können wir über das Editiermenü einen neuen Bericht vom Typ „Parent-Child-Editor“ anlegen.

Abbildung 14: DeltaMaster-Menü „Editieren“

 
Ebenfalls über das Editiermenü wechseln wir dann in die „Einstellungen“ und wählen die für unsere Dimension benötigten Tabellen bzw. Views aus. Die relationalen Objekte werden immer in einem vorgegebenen Namensraum erstellt und sind so leicht zu finden:

• Eintrag für Parent-Child-Tabelle:
  V_S_PC_<Dimensionsname>
  (im Beispiel: V_S_PC_Mitarbeiter)
• Eintrag für Elementdefinitionstabelle:
  T_S_PC_<Dimensionsname>_ElementTypes
  (im Beispiel: T_S_PC_Mitarbeiter_ElementTypes)
• Eintrag für Elementsubtyp-Tabelle:
  T_S_PC_<Dimensionsname>_SubTypes
  (im Beispiel: T_S_PC_Mitarbeiter_SubTypes)

Nachdem diese Einträge vorgenommen sind, zeigt DeltaMaster im Einstellungsmenü automatisch die Views an, die für die einzelnen Elementtypen angelegt wurden. In den Views wird neben den technischen IDs auch automatisch ein Feld für den Elementnamen und die Elementbeschreibung angelegt, sowie die von uns definierten Dimensionsattribute (Geburtsdatum, Geschlecht, Eintrittsdatum) und die je Elementtyp unterschiedlichen Elementattribute (Bereich, Organisationseinheit, Position). Welche Spalten für den Nutzer sichtbar sein sollen, wählen wir hier genauso wie beim regulären SQL-Durchgriff aus. Auch können wir per SQL-Anweisung Vorgaben für Drop-Down-Boxen implementieren und weitere Anzeigeparameter, bspw. die Sortierung, verändern.

Abbildung 15: Einstellung Parent-Child-Editor

Eingabe von Elementen

Haben wir alle Einstellungen getroffen, können wir den Bericht zwischenspeichern und in den Präsentationsmodus wechseln. Der Berichtstyp „Parent-Child-Editor“ ist zweigeteilt. Auf der linken Seite werden die Elemente angelegt, auf der rechten Seite die Eigenschaften des jeweils ausgewählten Elements verändert.

Per Rechtsklick auf den leeren Bereich auf der linken Seite können wir ein erstes Element anlegen. Zur Auswahl werden hier nur Elementtypen angezeigt, die als Top-Element definiert sind.

Abbildung 16: Element hinzufügen

 
Ist das erste Element angelegt, können wir es entsprechend bearbeiten. Sobald das Element ausgewählt ist, erscheinen im rechten Teil des Fensters alle zugehörigen Eigenschaften, die wir in den Einstellungen als sichtbar ausgewählt haben und mit der Reihenfolge und Bezeichnung, die wir in den Einstellungen vergeben haben.

Abbildung 17: Erster Eintrag im Parent-Child-Editor

 
Im rechten Bereich (unter „Eingabe starten“) können wir nun alle Einträge direkt vornehmen. Änderungen des Namens werden automatisch für die Anzeige im linken Bereich übernommen.

Abbildung 18: Bearbeiten eines Eintrags im Parent-Child-Editor

 
Neue Geschäftsführer können durch Rechtsklick auf den leeren Bereich im linken Teil des Berichts hinzugefügt werden.

Sollen einem Geschäftsführer Mitarbeiter zugeordnet werden, ist dies per Rechtsklick auf den entsprechenden Geschäftsführer möglich. Es werden alle Elementtypen angeboten, die im Bericht „Relationships“ dafür vorgesehen wurden (vgl. Abschnitt Bericht „Relationships“ ).

Abbildung 19: Hinzufügen eines Eintrags im Parent-Child-Editor

 
Durch das Hinzufügen von Mitarbeitern unterhalb des Geschäftsführers wird das Auf- und Zuklappen über das „Plus“-Symbol möglich. Nach Anlegen einiger Elemente könnte sich also folgendes Bild ergeben.

Abbildung 20: Beispielhafte Parent-Child-Struktur

 
Anhand der Punkte, die vor dem Elementnamen sichtbar sind, können wir erkennen, auf welcher Ebene wir uns befinden. Ein Punkt markiert die Ebene Geschäftsführer, zwei Punkte kennzeichnen Mitarbeiter mit Leitungsfunktion und drei Punkte Mitarbeiter ohne Leitungsfunktion. Dies wird durch die Standardeinstellung im Bericht „Element Types“ in der Spalte „Icon“ erreicht (vgl. Abschnitt Bericht „Element Types“). Außerdem erkennen wir, dass die Ebene unterhalb des Elementtyps „Mitarbeiter mit Leitungsfunktion“ gemäß unserer Einstellung alphabetisch sortiert ist (Mitarbeitende unter Luise Müller). Per Drag-and-drop lassen sich auch ganze Knoten umsortieren: wenn also bspw. Luise Müller samt Mitarbeitenden in den Bereich von Marie Maier wechselt. Per Rechtsklick lassen sich zudem Elemente kopieren, löschen oder umbenennen.

Einbinden der Dimension in ein Analysemodell

In der Regel soll die mit dem Parent-Child-Editor definierte und gepflegte Dimension auch in ein Analysemodell eingebunden werden. Über die Anwendung „ETL.das“ kann die angelegte Parent-Child-Dimension wie jede andere Parent-Child-Dimension erstellt werden. Die entsprechende Quelltabelle, die neben der Hierarchie auch alle Attribute der einzelnen Elemente enthält, wird immer im Namensraum „V_PCDIM_“ (hier: V_PCDIM_Mitarbeiter) erstellt.

Abbildung 21: Erzeugte View V_PCDIM_Mitarbeiter

 
Zusätzlich zu den Spalten zu ID, Name und den Attributen wird hier auch noch die „ElementTypeID“ und die „LevelID“ angezeigt, falls diese (optional) als Attribute in das mehrdimensionale Modell aufgenommen werden sollen. Die Spalte „PrevID” enthält die Sortierungs-ID des Elements innerhalb der Ebene und kann für die Sortierung der Elemente in der Dimension verwendet werden.

Die vollständige Auflistung aller erzeugten relationalen Objekte ist im Handbuch zum Parent-Child-Editor zu finden. Das Handbuch befindet sich in der DeltaMaster-Hilfe im Bereich Handbücher unter „Erweiterung und Zusatzprodukte“.