ich möchte einen Drilldown erzeugen, der zwei Dateninputs (bspw. AnlageDatum von Rechnungseingang(RE) und Rechnungsausgang(RA)) abbildet. Sinn und Zweck ist es über mehrere Dimensionen (Artikel, Artikelarten, etc.) zu kalkulieren (bspw. Netto Rechnungsausgang - Netto Rechnungseingang = Rohertrag)
Ich denke, dass kann so nicht funktionieren. Die erforderlichen Daten-Assoziationen müssen bereits im Datenmodell erstellt werden. Das Handling von multiplen Datumswerten kann ziemlich komplex werden und vergleichsweise häufig wird hierfür ein Canonical Calendar benutzt, der über eine Link-Tabelle mit dem Datenmodell verbunden ist, siehe u.a. Canonical Date - Qlik Community - 1463578.
Das ist bereits im gezeigten Beispiel mit zwei direkt-verbundenen Fakten-Tabellen, wie ORDER und ORDERLINES nicht ganz trivial, falls es jedoch noch weitere Fakten-Tabellen gibt, wie z.B. in Fällen, wo man über ORDER und INVOICE und SHIPMENT Ereignisketten darstellen möchte, steigt der Aufwand mit so einen Ansatz und die Komplexität eher exponentiell als linear.
Deutlich einfacher wird es, wenn man sich an die offizielle Empfehlung von Qlik hält und das Datenmodell als Star-Scheme aufbaut, was bedeutet, alle Fakten-Tabellen werden per join/mapping sowie concatenate in eine einzelnen Fakten-Tabelle überführt, wobei man die Datenstrukturen weitestgehend harmonisiert.
Bezogen auf die Datumsfelder einer Ereigniskette bedeutet das, man hat nur noch ein einzelnes Datumsfeld und zumindest ein weiteres Feld, welches die Quell- und/oder Datums-Type-Information enthält. Sehr hilfreich sind zudem weitere Flag-Felder mit den Ergebnissen von Daten-Prüfungen der Fakten-Bereiche gegeneinander, um z.B. bereits dem Datensatz der ORDER mitzugeben, ob bereits ein INVOICE und/oder SHIPMENT stattgefunden hat oder nicht und/oder der zeitliche Offset bzw. die Dauer zwischen den Ereignissen wird dort mit angegeben ...
Wie bereits angedeutet, ist das nicht simpel und verursacht Aufwand. Der Ansatz, sowas in der Oberfläche über synthetische Dimensionen und Berechnungen lösen zu wollen, wird aber in jedem Fall ungleich schwieriger.
Ich denke, dass kann so nicht funktionieren. Die erforderlichen Daten-Assoziationen müssen bereits im Datenmodell erstellt werden. Das Handling von multiplen Datumswerten kann ziemlich komplex werden und vergleichsweise häufig wird hierfür ein Canonical Calendar benutzt, der über eine Link-Tabelle mit dem Datenmodell verbunden ist, siehe u.a. Canonical Date - Qlik Community - 1463578.
Das ist bereits im gezeigten Beispiel mit zwei direkt-verbundenen Fakten-Tabellen, wie ORDER und ORDERLINES nicht ganz trivial, falls es jedoch noch weitere Fakten-Tabellen gibt, wie z.B. in Fällen, wo man über ORDER und INVOICE und SHIPMENT Ereignisketten darstellen möchte, steigt der Aufwand mit so einen Ansatz und die Komplexität eher exponentiell als linear.
Deutlich einfacher wird es, wenn man sich an die offizielle Empfehlung von Qlik hält und das Datenmodell als Star-Scheme aufbaut, was bedeutet, alle Fakten-Tabellen werden per join/mapping sowie concatenate in eine einzelnen Fakten-Tabelle überführt, wobei man die Datenstrukturen weitestgehend harmonisiert.
Bezogen auf die Datumsfelder einer Ereigniskette bedeutet das, man hat nur noch ein einzelnes Datumsfeld und zumindest ein weiteres Feld, welches die Quell- und/oder Datums-Type-Information enthält. Sehr hilfreich sind zudem weitere Flag-Felder mit den Ergebnissen von Daten-Prüfungen der Fakten-Bereiche gegeneinander, um z.B. bereits dem Datensatz der ORDER mitzugeben, ob bereits ein INVOICE und/oder SHIPMENT stattgefunden hat oder nicht und/oder der zeitliche Offset bzw. die Dauer zwischen den Ereignissen wird dort mit angegeben ...
Wie bereits angedeutet, ist das nicht simpel und verursacht Aufwand. Der Ansatz, sowas in der Oberfläche über synthetische Dimensionen und Berechnungen lösen zu wollen, wird aber in jedem Fall ungleich schwieriger.
Vielen Dank für die Hinweise. Ich versuche mich mit den genannten Ansätzen. Wir haben tatsächlich riesige Datenmengen von 1998 bis heute in den Bereichen, die sehr komplex geführt werden. Es gibt auch keine designte Datenarchitektur, so dass in den Jahrzehnten viel organisch gewachsen ist und die Kontinuität ist dementsprechend nicht gegeben und muss künstlich erzeugt werden.
