{"id":6769,"date":"2026-07-12T02:08:50","date_gmt":"2026-07-12T10:08:50","guid":{"rendered":"https:\/\/www.gudusoft.com\/sap-hana-data-lineage\/"},"modified":"2026-07-12T02:08:50","modified_gmt":"2026-07-12T10:08:50","slug":"sap-hana-data-lineage","status":"publish","type":"page","link":"https:\/\/www.gudusoft.com\/de\/sap-hana-datenherkunft\/","title":{"rendered":"SAP HANA Datenherkunft: Spaltenherkunft f\u00fcr HANA SQL und Views"},"content":{"rendered":"

SAP HANA Datenherkunft<\/strong> ist die Spaltenebene-Abbildung, die darstellt, wie Daten durch Ihre HANA SQL-Abfrage flie\u00dfen: welche Quelltabellen und -spalten die einzelnen SQL-Views, berechneten Spalten und nachgelagerten Berichte speisen und welche Joins, Filter, Casts und Funktionen die Daten dabei transformieren. Gudu SQLFlow<\/strong> Diese Zuordnung wird automatisch erstellt, indem Ihr HANA SQL mit einem speziellen SAP HANA Dialektparser analysiert wird \u2013 einem von 39 dialektspezifischen Parsern, nicht mit einer generischen ANSI-Grammatik \u2013 und ein interaktives, bis auf einzelne Spalten herunterf\u00fchrbares Herkunftsdiagramm gerendert wird.<\/p>\n\n\n\n

\n\n

Probieren Sie es jetzt aus:<\/strong> HANA einf\u00fcgen ANSICHT ERSTELLEN<\/code> Kette in die kostenloser SQLFlow-Lineage-Visualisierer<\/a>W\u00e4hlen Sie den SAP-HANA-Dialekt aus und erhalten Sie das Spaltendiagramm in Sekundenschnelle. Kostenlose Version, keine Installation erforderlich.<\/p>\n\n<\/div><\/div>\n\n\n\n

Warum Abstammungsfragen bei HANA landen<\/h2>\n\n\n\n

HANA existiert selten isoliert. Typischerweise ist es in S\/4HANA- und BW-Umgebungen integriert und umfasst parallele Data Marts sowie Reporting-Ebenen, auf die die Finanz- und Pr\u00fcfungsfunktionen angewiesen sind. Wenn ein Pr\u00fcfer fragt, \u201eWelche Quellfelder speisen diese Zahl?\u201c<\/em> oder ein Controller fragt \u201eWarum hat sich dieser KPI nach der Ver\u00f6ffentlichung im letzten Monat ge\u00e4ndert?\u201c<\/em>Die Antwort liegt in Schichten von SQL verborgen: Ansichten, die auf Ansichten aufbauen, berechnete Spalten, W\u00e4hrungsumrechnungen und Verkn\u00fcpfungen \u00fcber Schemata hinweg.<\/p>\n\n\n\n

Die Beantwortung dieser Fragen durch manuelles Lesen von SQL-Code ist bei wenigen Ansichten nicht praktikabel. Die SQL-basierte Herkunftsanalyse automatisiert diesen Prozess: Jede Ansichtsdefinition und jedes Skript wird einmalig analysiert, und der Abh\u00e4ngigkeitsgraph \u2013 von der Tabelle \u00fcber die Ansicht bis zum Bericht, auf Spaltenebene \u2013 steht bei Bedarf f\u00fcr Wirkungsanalysen, die Ursachenforschung und die Erstellung von Pr\u00fcfdokumenten zur Verf\u00fcgung.<\/p>\n\n\n\n

Wie SQLFlow die Datenherkunft in SAP HANA erstellt<\/h2>\n\n\n\n

SQLFlow basiert auf Allgemeiner SQL-Parser (GSP)<\/a>, ein kommerzielles SQL-Compiler-Frontend, das seit Mitte der 2000er-Jahre entwickelt und anhand von rund 13.600 SQL-Testdateien pro Dialekt validiert wurde. Der SAP-HANA-Parser versteht speziell die SQL-Syntax von HANA \u2013 Zitat "SCHEMA"."OBJEKT"<\/code> Bezeichner, HANA-Funktionen und -Umwandlungen, HANA-Join- und Mengenoperatorformen \u2013 anstatt dies mit einer generischen Grammatik anzun\u00e4hern.<\/p>\n\n\n\n

F\u00fcr jede Anweisung erstellt GSP ein vollst\u00e4ndiges semantisches Modell: Jede Spaltenreferenz wird durch CTEs, Unterabfragen, Sichten und ... aufgel\u00f6st. W\u00c4HLEN *<\/code> Erweiterung. Der Datenflussanalysator extrahiert dann f\u00fcr jede Ausgabespalte genau, welche Quellspalten sie speisen und welche Funktionen und Ausdr\u00fccke verwendet werden. Das Ergebnis ist eine verl\u00e4ssliche Herkunftsnachverfolgung auf Spaltenebene f\u00fcr Schema\u00e4nderungen, keine blo\u00dfe Skizze auf Tabellenebene.<\/p>\n\n\n\n

Sie k\u00f6nnen HANA-SQL auf drei Arten an SQLFlow \u00fcbergeben: durch direktes Einf\u00fcgen von Anweisungen, durch Hochladen von Dateien mit Ansichtsdefinitionen und Skripten oder durch eine JDBC-Verbindung, wobei SQLFlow Objektdefinitionen aus dem Datenbankkatalog abruft. Die Analyse des SQL-Textes erfolgt statisch \u2013 SQLFlow liest niemals die Zeilen Ihrer Tabellen.<\/p>\n\n\n\n

Beispiel: Nachverfolgen einer mehrschichtigen HANA-SQL-View-Kette<\/h2>\n\n\n\n

Geschichtete SQL-Sichten entsprechen dem Standardmuster in HANA: eine Bereinigungssicht \u00fcber den Rohdatentabellen, darauf eine Anreicherungssicht und schlie\u00dflich eine Aggregationssicht f\u00fcr die Berichterstellung. Hier ist eine typische dreischichtige Kette:<\/p>\n\n\n\n

CREATE VIEW "FIN"."V_ORDERS_CLEAN" AS SELECT ORDER_ID, CUSTOMER_ID, TO_DECIMAL(GROSS_AMOUNT, 15, 2) AS GROSS_AMOUNT, IFNULL(CURRENCY, 'EUR') AS CURRENCY, ORDER_DATE FROM "FIN"."ORDERS_RAW" WHERE STATUS <> 'CANCELLED'; CREATE VIEW "FIN"."V_ORDERS_EUR" AS SELECT o.ORDER_ID, o.CUSTOMER_ID, o.GROSS_AMOUNT * r.RATE AS AMOUNT_EUR, o.ORDER_DATE FROM "FIN"."V_ORDERS_CLEAN" o JOIN "FIN"."FX_RATES" r ON r.CURRENCY = o.CURRENCY AND r.RATE_DATE = o.ORDER_DATE; CREATE VIEW "FIN"."V_REVENUE_MONTHLY" AS SELECT CUSTOMER_ID, YEAR(ORDER_DATE) AS FISCAL_YEAR, MONTH(ORDER_DATE) AS FISCAL_MONTH, SUM(AMOUNT_EUR) AS REVENUE_EUR FROM "FIN"."V_ORDERS_EUR" GROUP BY CUSTOMER_ID, YEAR(ORDER_DATE), MONTH(ORDER_DATE);<\/code><\/pre>\n\n\n\n
Fragen Sie SQLFlow, wo V_REVENUE_MONTHLY.REVENUE_EUR<\/code> kommt von dort und durchl\u00e4uft die Kette automatisch: UMSATZ_EUR<\/code> Ist SUMME(BETRAG_EUR)<\/code>, was ist BRUTTOBETRAG * ZINSSATZ<\/code>, Wo BRUTTOBETRAG<\/code> Ist BESTELLUNGEN_RAW.BRUTTOBETRAG<\/code> durchgegangen TO_DECIMAL<\/code>Zwei Quellspalten, drei Ansichten tief, jede Zwischenberechnung benannt. F\u00fchren Sie die Ablaufverfolgung in umgekehrter Richtung aus, um eine Auswirkungsanalyse zu erhalten: erneut eingeben BESTELLUNGEN_RAW.BRUTTOBETRAG<\/code> SQLFlow listet alle nachgelagerten Spalten auf, die die \u00c4nderung \u00fcbernehmen.<\/p>\n\n\n\n
Berechnete Spalten in SQL-Sichten \u2013 die TO_DECIMAL<\/code> Besetzung, die IFNULL<\/code> Standardm\u00e4\u00dfig sind die Multiplikationen im Abstammungsdiagramm erstklassig, daher zeigt das Diagramm nicht nur Das<\/em> Eine S\u00e4ule flie\u00dft hindurch, aber Was geschieht damit?<\/em> in jeder Schicht.<\/p>\n\n\n\n
Direkte Abstammung vs. indirekte Abstammung<\/h2>\n\n\n\n
Schauen Sie sich das Beispiel noch einmal an. ORDERS_RAW.STATUS<\/code> erscheint nie in irgendeiner Ausgabespalte, dennoch WHERE STATUS <> 'CANCELLED'<\/code> Der Filter beeinflusst die Umsatzzahlen ma\u00dfgeblich. Dasselbe gilt f\u00fcr W\u00c4HRUNG<\/code>, RATE_DATE<\/code>, Und BESTELLDATUM<\/code> in den Join-Bedingungen und GRUPPE NACH<\/code>.<\/p>\n\n\n\n
SQLFlow modelliert diese als indirekte (Einfluss-)Abstammungslinie<\/strong>Diese Beziehungsart unterscheidet sich vom direkten Datenfluss und kann im Diagramm separat umgeschaltet werden. Bei Pr\u00fcfungsfragen wie \u201eHat dieses regulierte Feld Einfluss auf diesen Bericht?\u201c liefern die indirekten Verbindungen oft die vollst\u00e4ndige Antwort \u2013 und die meisten konkurrierenden Datenherkunftsanalyse-Tools unterscheiden nicht zwischen direkten und indirekten Verbindungen.<\/p>\n\n\n\n
Wo SQLFlow neben den SAP-nativen Tools seinen Platz findet<\/h2>\n\n\n\n
Die Modellierungs- und Katalogisierungswerkzeuge von SAP sind in ihrem eigentlichen Zweck \u2013 der Nachverfolgung von Artefakten innerhalb der SAP-Modellierungsschicht \u2013 sehr gut. Die L\u00fccke zeigt sich auf der SQL-Ebene. Manuell erstellte SQL-Sichten, Migrationsskripte, DML-Anweisungen in geplanten Jobs und die SQL-Abfragen, die HANA mit dem Nicht-SAP-Teil Ihrer IT-Landschaft verbinden, sind f\u00fcr die modellbasierte Nachverfolgung unsichtbar, da sie nie als modellierte Artefakte registriert wurden.<\/p>\n\n\n\n
Das ist die Ebene, die SQLFlow abdeckt. Es analysiert den SQL-Code selbst, sodass alles, was als SQL-Text ausgedr\u00fcckt wird, nachverfolgt wird \u2013 unabh\u00e4ngig davon, mit welchem Tool er erstellt wurde. Zwei wichtige Grenzen sollten beachtet werden:<\/p>\n\n\n\n