2 QVDs verknüpfen mit Join - aber ich muss einen Bereich einlesen

[Claus_B_VS]

Hallo zusammen! Ich habe folgendes Problem. Ich habe eine führende QVD zu der ich eine weitere QVD einlesen muss - dort können mehrere Sätze zu den gleichen Parameter stehen - ich will nur die Anzahl der Sätze und die Anzahl der Menge speichern. Prinzipiell funktioniert es - nur habe ich festgestellt, dass zumindest ein Datenfeld in einem Bereich vorliegt (Beispiel: kann zwischen 1 und 5 liegen - alle anderen dürfen nicht eingelesen werden) und nun würde ich diese gerne im Bereich abfragen. Den Load wie ein SQL zu verknüpfen geht leider nicht, da ich dort die groupy by nicht einbauen kann. Könnte mir jemand kurzfristig weiterhelfen? Vielen Dank im voraus und ein schönes Wochenende. Viele Grüße vom Bodensee.

[marcus_sommer]

Die Problemstellung ist nicht ganz klar. Verhindert der erforderliche Key die Aggregierung und/oder benötigt es nur Filterungen gegen die zweite QVD und/oder dem Ergebnis der Aggregierung?

Für etwaige Filterungen benötigt man vielleicht noch ein/zwei extra Loads, die die Daten entsprechend aufbereiten bzw. extrahieren. Ein group by Granularitätskonflikt mit dem Key ist schon schwieriger beizukommen, ist aber häufig mit n anderen Loads + Keys lösbar.

Falls das nicht praktikabel genug ist, könnte man auch die zweite QVD mit Interrekord-Funktionen in einem entsprechend sortiertem resident-load die Datensätze + Mengen akkumulieren und joined dann gegen den jeweiligen max-Wert.

[Claus_B_VS]

Ich würde gerne etwas genauer versuchen zu erklären, was ich genau brauche: ich bekomme von unseren Maschinen einen Datensatz zurück - versehen mit Datum, gefertigte Menge, Fertigungsauftrag. Die Maschinen melden parallel die Daten an das ERP. Dort werden Lagerbuchungen durchgeführt. Das Problem ist zum einen die Uhrzeit (die sind logischer weise nicht gleich sondern im Extremfall 1 Minute unterschiedlich. Auch die Materialbuchungen sind leider nicht gleich (den Fehler versuche ich gerade hauszufinden) - diese weichen teilweise bis zu 10% ab und können je nach LotNr auf bis zu 3 Buchungen aufteilt werden. Nun möchte ich diese Maschinendaten mit den ERP-Lagerbuchungen vergleichen, da es immer wieder vorkommt, dass die Lagerbuchungen im ERP nicht ausgeführt werden. Meine Idee ist, dass ich über das Datum/Uhrzeit (+/- 60 Sekunden) und mit der Menge (+/- 5%) ein Vergleich fahre. Mit dem Join habe ich es nicht hinbekommen. Das wäre die Anforderung.

[marcus_sommer]

Mit klassischen Join-Logiken kann man das in Qlik nicht lösen, da immer nur 100%-ige Schlüsselwerte zu einem Match führen. Bedeutet jedoch weitergedacht, man kann auch abweichende Schlüsselwerte zueinander matchen, wenn man die Schlüsselwerte entsprechend anpasst und dann n Mal abfragt.

Hierfür würde ich mich aber von Joins lösen und verschachtelte Mappings verwenden. Hier mal ein Beispiel für eine entsprechende Mapping-Tabelle und deren Aufruf:

m:
mapping load Zeit, Return from X;
mapping load timestamp(floor(Zeit, 1/24/60)) as Zeit, Return from X;
mapping load timestamp(floor(Zeit, 1/24/60) - maketime(0,1)) as Zeit, Return from X;
mapping load timestamp(floor(Zeit, 1/24/60) + maketime(0,1)) as Zeit, Return from X;

t: load *,
   applymap('m', Zeit,
   applymap('m', timestamp(floor(Zeit, 1/24/60)),
   applymap('m', timestamp(floor(Zeit, 1/24/60) - maketime(0,1)),
   applymap('m', timestamp(floor(Zeit, 1/24/60) + maketime(0,1)),
   'no Match')))) as Return
from Y;

Prinzipiell kann man die Mapping-Tabelle auch auf n Tabellen aufteilen, sofern man diese aber direkt hintereinander in der richtigen Reihenfolge lädt, geht es trotzdem so. Und in der gleichen Reihenfolge fragt man dann auch ab - hier dann zuerst den sekunden-genauen Wert, dann den mit der identischen Minute und dann eine Minute drüber/drunter (ein Mapping nimmt immer den ersten Treffer).

Auch tiefere Verschachtelungen gegen kombinierte Lookup- und/oder Return-Werte sind möglich, z.B. indem der Return-Wert nicht nur ein Einzelwert ist, sondern vielleicht (bezogen auf obiges Beispiel):

Return & '|' & 1
Return & '|' & 2
...

und applymap() wird dann in ein subfield() eingebettet, wodurch man nicht nur einen Wert erhält, sondern auch angeben kann, welcher der Matches war erfolgreich - also eine Art Qualitäts-Score.

[Claus_B_VS]

wow, das geht über meine Logik glaube ich hinaus. Aber den Grundsatz habe ich glaube ich verstanden: den ersten QVD-Ladevorgang mit dem 2. QVD-Ladevorgang vergleichen. Bin mir aber nicht sicher. Nun eine Frage: Wenn ich die 2. QVD zur ersten QVD dazulade mit einem eindeutigen Schlüssel (Satzzähler aus dem QVD-1) könnte das gehen. Aber es scheint so zusein, dass 2 QVDs nicht wie bei einem Select mit einander eingelesen werden können - oder gibt es da einen Trick? Dann könnte ich es wie beim SQL machen - hätte mehrere Datensätze im Speicher und könnte mit denen alles machen und über den eindeutigen Schlüssel wieder dem Hauptsatz zuordnen?!?!

[marcus_sommer]

Ich bin mir nicht ganz sicher, wie das gemeint ist, denke aber, die Antwort ist nein. Qlik joined fix über alle gleichnamigen Felder gegen eineindeutige Werte und ohne das hier, das jeweilige Gegenüber in einer Transformation oder Bedingung angesprochen werden kann.

All das kann man dann erst in der zusammengeführten Tabelle machen. Beim oben gezeigten Mapping ist das anders - hier kann man gleich mit den Werten arbeiten. Im übrigen ist Mapping sehr performant, deutlich flexibler und ohne jedes Risiko in irgendeiner Weise die Anzahl der Datensätze zu verändern.

[Claus_B_VS]

Also - ich hab zwischenzeitlich mal versucht die Daten als CSV zu speichern und über ODBC einzulesen - würde klappen - ist aber wahrscheinlich extrem umständlich. Daher würde ich tatsächlich die Lösung von Markus - auch wenn ich es noch nicht sicher verstanden habe - priorisieren. 

@Markus: wenn ich Dir die Feldnamen schicke, könntest Du mir ein Beispiel machen, wie das aussieht?

[marcus_sommer · Accepted solution]

Ich habe sowas vor fast 20 Jahren als Anfänger auch so gemacht, würde heute aber nicht mehr dazu tendieren, obwohl es von einem pragmatischen Standpunkt aus, nicht unbedingt eine schlechte Lösung sein muss. Der oben skizzierte Weg benötigt ja auch ein paar extra Schritte.

Insofern hängt es von verschiedenen weiteren Faktoren ab (Datenmengen, Storage/Network Performance, inkrementelle Ladeprozesse, Laufzeiten, Verfügbarkeit ODBC-Treiber, Zeichensätze, ...), welcher Ansatz am besten geeignet ist.

Wenn genügend zeitliche Ressourcen vorhanden sind, dann mache einfach beide und anschließend könnte man dann wählen. Hilfreich ist es auf jeden Fall, sowas nicht mit den Originaldaten in der Zielanwendung zu entwickeln, sondern Daten- und Komplexität-reduziert in einer Test-Anwendung (nur ein paar Datensätze mit den essentiellen Feldern). Anschließend bohrt man das dann etwas auf und wenn das geht, adaptiert man es ins Ziel.

[Claus_B_VS]

Das hört sich glaube ich vernünftig an: Ich werde mal prüfen ob das geht: Ich habe auf jeden Fall folgende Felder in der Quelldatei: lfdNr (ist eindeutig in der Quelldatei), Artikel, Lagernummer, Menge, Termin. In der Zieldatei sind Artikel (gleich), Lagernummer (gleich), Menge (+/- 50), Termin (Timestamp +/- 120 Sekunden). Ich muss eigentlich nur die Anzahl der Sätze, die über die Quelldatei in dem Rage der Zieldatei liegen, wissen. Das Laden über die CSV quasi als Datenbank würde funktionieren und wäre daher mein Notnagel.