Der Parent-Child-Editor ermöglicht es, mit DeltaMaster hierarchische Strukturen zu definieren und nach der Definition auch mit Leben zu füllen. Es ist ein sehr nützliches Add-On, welches die relationalen Möglichkeiten von DeltaMaster erweitert. Zu dessen Nutzung sind aber auch einige Vorüberlegungen notwendig.
Wir möchten diesen Blogbeitrag nutzen, um zu veranschaulichen, was der Parent-Child-Editor kann und wir er zu benutzen ist. Der Blogbeitrag soll nicht die Dokumentation des Parent-Child-Editor ersetzen. Für offene Fragen sollte dann diese als weiterführende Lektüre genutzt werden.
Häufig kommt es vor, dass in Vorsystemen zwar die Rohdaten wie z.B. Kontobewegungen oder Verkäufe detailliert vorliegen, jedoch keine Information darüber, wie diese Daten vorteilhaft strukturiert werden können. Um solche Strukturen erstellen zu können, ist der PC-Editor das ideale Werkzeug. So ist es möglich, Konten hierarchisch zusammenzufassen (z.B. für Berechnungen wie ROI), Verkaufs- oder Projektstrukturen zu erstellen.
Dabei besteht die Arbeit mit dem Parent-Child-Editor immer aus zwei Stufen: Struktur definieren und Struktur mit Daten füllen.
In Stufe 1 wird eine Hierarchie definiert. Hier wird festgelegt, welche Arten von Einzelelementen es geben soll und welche Beziehungen diese zueinander haben. Für eine Projektstruktur könnte zum Beispiel folgendes festgelegt werden: In der Struktur gibt es Projektgruppen, Projekte, Projektschritte und Arbeitspakete. Dabei ist eine Projektgruppe immer die oberste Stufe unter der Projekte zusammengefasst werden. Unter einem Projekt können Arbeitspakete liegen (bei kleineren Projekten) oder Projektschritte. Projektschritte wiederum können in sehr großen Projekten auch untergliedert werden in weitere Projektschritte. Irgendwann sollten unter diesen Projektschritten aber auch Arbeitspakete liegen. Außerdem werden Eigenschaften der einzelnen Elementtypen festgelegt. Ein Projekt hat sicher einen Projektleiter, ein Projektschritt muss vielleicht zu einem bestimmten Zeitpunkt erledigt sein, es hat einen Meilenstein. Oder ein Arbeitspaket hat einen bestimmten Ausführenden.
Dies alles kann in einem Parent-Child-Editor festgelegt werden. Nach der Festlegung einer solchen Struktur in einem Meta-Modell werden alle erforderlichen Tabellen, Prozeduren und Sichten automatisch angelegt und die Dateneingabe als Stufe 2 kann beginnen. Dabei kann im Parent-Child-Editor die vordefinierte Struktur gefüllt werden und für jedes Element können Eigenschaften, die auch vorher im Meta-Modell definiert worden sind, gepflegt werden. Solche Strukturen können dann in einer multidimensionalen Umgebung als Hierarchien oder Dimensionen eingebunden werden.
Zuerst stellen wir das Befüllen einer Parent-Child-Datenstruktur vor. Danach kommen wir zum Erstellen einer Struktur um diesem Thema damit ein wenig den Geschmack von ‚Grauer Theorie’ zu nehmen.
Der Parent-Child-Editor erscheint in DeltaMaster als zusätzliches Basisverfahren des Analysesets:
Der Parent-Child-Editor besteht aus zwei Fensterteilen. Im linken Fensterteil ist die Hierarchie angezeigt und im rechten sind die Eigenschaften des jeweils angeklickten Hierarchieelementes zu sehen. Mit Rechtsklick auf ein Hierarchieelement erscheint ein Kontext-Menü mit Befehlen für dieses Element: kopieren, löschen, umbenennen und Element hinzufügen. Hinter ‚Element hinzufügen’ erweitert sich das Menü und es werden die vordefinierten Kindelementtypen des Hierarchieelementes angezeigt. So können neue Kindelemente angelegt werden. Neue oberste Elemente können erstellt werden, indem Sie in einen elementfreien Bereich im Hierarchie-Fensterteil klicken. Bei Klick auf ein Element in der Hierarchie werden im rechten Fenster die Eigenschaften des Elements angezeigt und können editiert werden. Eingegebene Werte werden sofort in der Datenbank gespeichert. Wie man sieht, ist das Füllen einer Hierarchie im Grunde ein Kinderspiel. Jetzt geht es als nächstes darum, wie solch eine Hierarchie kreiert wird.
Definition einer Hierarchie
Nachdem die grundlegenden Elemente des Parent-Child-Editors veranschaulicht sind, wird es sicher auch einfacher sein, die Schritte der Hierarchie-Definition nachzuvollziehen. Alle Eingaben werden in einer DAS-Datei ParentChildEditor.das gemacht. Über diese Datei können die Tabellen mit den Meta-Daten des Parent-Child-Editors gefüllt werden.
Die erste Eingabetabelle heißt ‚Modelle’. Ein Modell ist ein theoretisches Konstrukt, das für ein OLAP-Modell steht. Unter diesem können verschiedene Hierarchien zusammengefasst werden. Theoretisch deswegen, weil hier natürlich nicht festgelegt wird, wie die Hierarchien später verwendet werden.
Nach Eingabe eines Models mit Datenbank-Zuordnung, können die Namen der Hierarchien eingegeben werden.
Dafür ist die Eingabetabelle ‚Dimensionen’ zuständig. Der Name Dimension ist dabei als Synonym für ‚Hierarchie’ verwendet. Eingegeben werden eine Modell-Zuordnung, eine eindeutige DimensionID und der Name der Hierarchie/Dimension.
In der nächsten Eingabemaske werden die Elementtypen angelegt.
In diesem Beispiel gibt es vier Elementtypen. Diese sind Projektgruppen, Projekte, Projektschritte und Aufträge. Elementtypen unterscheiden sich in der Definition der möglichen Beziehungen zwischen den Elementen und den Elementeigenschaften. Wenn z.B. Personen hierarchisch geordnet werden sollen und diese Personen alle die gleichen Eigenschaften besitzen, wird sicher nur ein Elementtyp angelegt: Person. In unserem Fall brauchen wir mehrere Elementtypen. Zusätzlich wird hier noch das TopElement festgelegt. Es kann also nur ein Element vom Typ Projektgruppe TopElement sein. Nachdem alle Elementtypen angelegt sind, müssen noch die Beziehungen zwischen den Elementen und die Eigenschaften der Elemente definiert werden. Dazu dienen die letzten drei Tabellen des Ordners ‚ParentChild Meta Modell’. Zunächst also die Beziehungen der Elementtypen:
In der Eingabe ‘Beziehungen der Elementtypen’ werden für jeden Elementtyp die Typen festgelegt, welche Kinder des Elementtypes sein können. Dabei kann natürlich auch der Elementtyp selbst angegeben werden (z.B. Person bei einer Personenhierarchie). Auf diese Art und Weise entstehen Hierarchien, die später als Parent-Child-Dimension in ein OLAP-Modell eingebunden werden können. Im Grunde legt diese Eingabe nur fest, welche Elementtypen auswählbar sind, wenn mit der rechten Maustaste später auf ein Element eines bestimmten Typs geklickt wird und ein Kindelement hinzugefügt werden soll.
Nachdem die Beziehungen zwischen den Elementen definiert sind, werden noch die erforderlichen Elementeigenschaften festgelegt. Es gibt 2 Arten von Elementeigenschaften: Eigenschaften, die jedem Elementtyp zugeordnet werden sollen, sogenannte allgemeine Eigenschaften und Eigenschaften, die speziell für einen Elementtyp bestimmt werden: Elementtypeigenschaften. In der Maske ‚allgemeine Eigenschaften’ werden die allgemeinen Eigenschaften festgelegt.
…und in der letzten Maske zur Erstellung des Metamodells werden die Elementtypeigenschaften festgelegt.
Nach Eingabe der Elementeigenschaften/Attribute ist das Metamodell komplett und die SQL-Strukturen (Tabellen, Abfragen, Prozeduren) für die Nutzung des Parent-Child-Modells können erstellt werden. Dies geschieht in der nächsten Tabelle ‚ParentChild-Struktur erstellen’.
Diese Tabelle enthält nie Einträge. Ein Tabellen-Trigger, der beim Klick auf den ‚übernehmen’-Link aktiviert wird, übergibt die eingegebenen Parameter (Modell und Dimension) einer SQL-Prozedur und diese erzeugt das entsprechende Parent-Child-Modell. Die Eingabe selbst wird anschließend sofort wieder gelöscht. Nachdem das PC-Modell erstellt ist, können noch zusätzliche Konfigurationen zu den Elementtypen vorgenommen werden.
