Next Level Analytics, Teil 7
Im 6.Teil der Serie haben wir einen Calculation View zur Berechnung von Beständen zu einem gewünschten Stichtag erstellt. Früher hatten wir bereits andere Views zur Berechnung verschiedener EK- und VK-Preise definiert. Jetzt wollen wir die einzelnen Komponenten der Lösung zusammenbringen und einen Calculation View zur Berechnung von bewerteten Materialbeständen erstellen!
Auch für diesen neuen View benötigen wir wieder einen Input Parameter und auch dieser soll wieder den Vortag als Vorschlagswert berechnen:
Wir erstellen eine neue Projektion und verwenden diesmal aber keine Datenbanktabelle aus einem aDSO, wie wir es bei den Preisen und Beständen immer getan haben. Diesmal verwenden wir in unserem neuen View einen bereits vorhandenen, anderen Calculation View!
Wir erinnern uns an unsere bisherigen Views: Jeder von ihnen stellt seine Daten am Ende in Form einer Tabelle bereit, die wir uns ja bereits über die Datenvorschau angesehen hatten. Wie die einzelnen Spalten berechnet werden, bleibt uns verborgen, aber wir nutzen das Endergebnis für unsere weiteren Berechnungen.
Wir sehen also: Calculation Views lassen sich schachteln, so dass sich komplexe Berechnungen in mehrere Views aufteilen lassen. Diese Vorgehensweise verbessert nicht nur die Wartbarkeit der Lösung, sie erhöht auch die Verarbeitungsgeschwindigkeit, weil typischerweise viele einzelne Komponenten parallel verarbeitet werden können.
Wir übernehmen die meisten Spalten aus dem View für die Bestände in die Ausgabe unserer Projektion, aber obwohl wir einen neuen Input Parameter definiert haben, verwenden wir ihn an dieser Stelle noch nicht.
Wir erstellen jetzt eine zweite Projektion, in der wir wiederum einen bereits vorhanden Calculation View verwenden, diesmal den für die Berechnung der Einkaufspreise. Wie und auf Basis welcher Daten diese Preise berechnet werden, braucht uns an dieser Stelle nicht zu interessieren. Die Funktionalität ist in dem View gekapselt.
Wir übernehmen die für uns relevanten Spalten in die Projektion …
…und erzeugen damit die Ausgabe dieser zweiten Projektion.
Wir haben bis jetzt zwei Projektionen in unserem View eingefügt, aber wir wollen ja die Bestände des einen mit den EK-Preisen des anderen ausmultiplizieren, um zu unseren bewerteten Beständen zu kommen. Dazu brauchen einen neuen Knoten, der uns die Spalten mit EK-Preisen an die Datensätze mit den Beständen anfügt. Wir erreichen dies mit einem JOIN Knoten und verhindern eine willkürliche Zuordnung der Datensätze über die Definition der Join-Bedingung.
In der Abbildung sehen wir, dass beide Projektionen, also Tabellen, über die Spalten Material, Lieferant, Währung und Mengeneinheit verknüpft wurden. Dabei spielen die unterschiedlichen technischen Namen der Spalten keine Rolle, wichtig sind nur die inhaltliche Übereinstimmung (Semantik: MATERIAL = MATNR) und gleiche bzw. kompatible Datentypen.
Die Symbolik der Verbindungslinien steht für einen LEFT OUTER JOIN. Das bedeutet, dass zu jedem Datensatz aus der linken Tabelle versucht wird, einen oder mehrere Datensätze aus der rechten Tabelle zu finden und dadurch die Zeilen und Spalten der Ergebnismenge zu ergänzen. In der Modellierung können wir dem System bereits mitgeben, wie viele Datensätze wir jeweils zu einem Satz erwarten: die Kardinalität des Joins. In unserem Fall handelt es sich eine N:1 Beziehung: Zu jedem Bestand erwarten wir einen EK-Preis, aber ein EK-Preis kann für viele Bestände (z.B. in verschiedenen Werken für das gleiche Material) verwendet werden.
Bei einem LEFT OUTER JOIN rechnen wir bereits damit, dass möglicherweise nicht zu jedem Datensatz der linken Tabelle auch tatsächlich ein passender Satz aus der rechten Tabelle gefunden werden kann. In solchen Fällen sind die Werte dieser Spalten im Ergebnisdatensatz NULL, also undefiniert.
Der präzisen Definition von Join-Bedingungen und deren Kardinalitäten sollten wir immer sehr große Bedeutung beimessen: durch falsche oder ungenaue Definitionen können wir entweder zu viele oder aber auch zu wenige Datensätze in unserer Ergebnismenge erhalten. Dadurch bekommen wir dann natürlich falsche Ergebnisse.
Nach diesem kurzen Abstecher in die Welt der Join Definitionen widmen wir uns jetzt wieder unserer Bestandsbewertung: in der Ausgabe unseres Join Knotens stehen uns jetzt sowohl die Bestandsmengen als auch die EK-Preise zur Verfügung.
Aus den Komponenten Menge und Preis können wir jetzt einen Wert berechnen. Dazu definieren wir auf dem Join Knoten Calculated Columns mit dem passenden Datentyp.
Da wir drei unterschiedliche Bestandsmengen und auch drei verschiedene EK-Preise haben, erstellen wir insgesamt neun Calculated Columns.
Jetzt haben wir unsere Bestände immerhin schon mit EK-Preisen bewertet, wollen diese aber noch um Verkaufspreise erweitern. Dazu erstellen wir wieder einen neuen Projektions-Knoten und benutzen den bereits vorhandenen Calculation View für die Berechnung der VK-Preise.
Aus den verfügbaren Spalten wählen wir wieder die für uns relevanten aus und definieren damit den Ausgabebereich für diesen Knoten.
Jetzt stehen wir wieder vor der Frage, wie wir unsere bisher verfügbaren Datensätze um die VK-Preisinformationen ergänzen können. Die Lösung ist auch hier wieder ein LEFT OUTER JOIN, denn wir können nicht ausschließen, dass uns evtl. einige VK-Preise fehlen. Wie schon gesagt, wenn es keinen passenden Datensatz in der rechten Tabelle vom Join gibt, erhalten diese Spalten in der Ergebnismenge den Wert NULL.
In diesem Join Knoten haben wir zwar eine etwas andere Liste von verknüpften Merkmalen, aber wir definieren auch hier wieder eine Kardinalität von N:1.
Im Ausgabebereich stehen uns jetzt also die Mengen, die EK- und VK-Preise zur Verfügung, …
… so dass wir jetzt wieder über Calculated Columns einen zum VK-Preis bewerten Bestand ausrechnen können. Da wir unsere drei verschiedenen Mengen mit vier verschiedenen VK-Preisen bewerten können, erhalten wir also insgesamt zwölf VK-Preis bewerte Bestände.
Zu guter Letzt wiederholen wir diese Schritte noch einmal für die werkspezifischen VK-Preise: Neue Projektion mit dem vorhanden Calculation View für diese VK-Preise, …
… Ausgabebereich mit den für uns relevanten Spalten, …
… ein neuer LEFT OUTER JOIN ergänzt die zusätzlichen Preise an unsere bisher verfügbaren Daten …
… wir erhalten einen um diese VK-Preise erweiterten Ausgabebereich …
… und können mit weiteren Calculated Columns wiederum neue bewerte Bestände berechnen
Diesen letzten Join Knoten können wir jetzt mit der Aggregation verbinden und erhalten eine sehr lange Liste an verfügbaren Spalten, die wir alle in die Aggregation übernehmen.
In der folgenden Abbildung sehen wir noch einmal das gesamte Szenario: zu den Datensätzen aus dem View für die Berechnung der Bestandsmengen verknüpfen wir nacheinander die EK- und VK-Preise. Durch jeden JOIN Knoten verbreitern wir unseren ursprünglichen Datensatz zunächst um die Preise und dann noch einmal um die berechneten Bestandswerte.
Wir hatten uns jedes Mal für einen LEFT OUTER JOIN entschieden, weil wir damit rechnen, auch einmal keinen Preis zu finden. Was würde eigentlich passieren, wenn wir statt dessen einen INNER JOIN modellieren würden? Wie verändert sich unsere Ergebnismenge?
Wir riskieren damit, dass wir weniger Datensätze im Ergebnis vorfinden! Ein INNER JOIN liefert immer dann einen Ergebnisdatensatz, wenn sowohl in der linken als auch in der rechten Tabelle ein passender Datensatz vorhanden ist. Fehlt auf einer Seite das Gegenstück, gibt es keinen Ergebnisdatensatz!
Zum Schluss kommen wir noch einmal auf die Input Parameter zurück. Eine grundlegende Anforderung an unseren Calculation View besteht ja darin, die bewerteten Bestände zu einem Stichtag zu berechnen. Daraus folgt, dass wir sowohl die Bestandsmengen als auch die Preise zu diesem Stichtag berechnen müssen. Sie erinnern sich aber, dass wir in diesem View zwar mehrere Projektionen eingebaut, diese aber noch nicht auf unseren Stichtag eingeschränkt haben.
Als Anwender dieses Views möchte ich den Stichtag natürlich nur ein einziges Mal eingeben müssen. Nicht für jede beteiligte Komponente!
Wir erreichen dies, indem wir den Input Parameter an die beteiligten Views („nach unten“) weiterleiten. Dabei ist dann der technische Name des Parameters nicht weiter relevant, nur die verwendeten Datentypen unserer Parameter müssen kompatibel zueinander sein.
Nun ist unser Calculation View zur Berechnung bewerteter Bestände zu einem Stichtag fertig! Schauen wir uns noch die Daten für einen Artikel an, wobei wir zunächst die spezifischen Calculation Views zur Berechnung der Preise benutzen. Jede Datenvorschau sollten wir natürlich mit dem gleichen Stichtag aufrufen.
Übersicht EK-Preise
Übersicht VK-Preise
Übersicht werkspezifische VK-Preise
EK-Preis bewertete Bestände
Wir erkennen den ZNNE und ZRKP-Preis für das Material bei diesem Lieferanten aus Abbildung 22 wieder, so dass die Mengen in den verschiedenen Werken bewertet werden können.
VK-Preis bewertete Bestände
Hier erkennen wir den ZVKP-Preis für das Material in diesem Vertriebsweg aus Abbildung 23 wieder, so wiederum alle Mengen in den Werken bewertet werden können.
An diesen Daten erkennen wir sehr schön die Arbeitsweise von einem LEFT OUTER JOIN: Während für das Material in einigen Werken (z.B.: 3060) ein Preis gepflegt ist, gibt es andere Werke ohne Preiszuordnung (z.B.: 3066). Dennoch sehen wir einen Datensatz in der Ergebnismenge für genau diese Kombination! Bei der Verwendung eines INNER JOIN würden diese Daten fehlen!
Als Wert für die Preise und Werte sehen wir bei den fehlenden Zuordnungen NULL. Außerdem sehen wir das Ergebnis einer Multiplikation mit NULL: es ist NULL.
Für die letzte Ansicht beschränken wir uns auf eine kleine Liste von Werken.
Wenn wir jetzt das Werk aus der Anzeige entfernen, die Daten also verdichten, erhalten wir die Summe der Bestände über die Werke.
