SAP HANA Data Lineage: Column Lineage for HANA SQL and Views

SAP HANA data lineage is the column-level map of how data moves through your HANA SQL: which source tables and columns feed each SQL view, calculated column, and downstream report, and which joins, filters, casts, and functions transform the data along the way. Gudu SQLFlow builds that map automatically by parsing your HANA SQL with a dedicated SAP HANA dialect parser — one of 39 dialect-specific parsers, not a generic ANSI grammar — and rendering an interactive, drillable lineage diagram down to individual columns.

Why lineage questions land on HANA

HANA rarely lives alone. It typically sits underneath S/4HANA and BW estates, side-by-side data marts, and reporting layers that the finance and audit functions depend on. When an auditor asks “which source fields feed this figure?” or a controller asks “why did this KPI change after last month’s release?”, the answer is buried in layers of SQL: views built on views, calculated columns, currency conversions, and joins across schemas.

Answering those questions by reading SQL manually does not scale past a handful of views. SQL-level lineage automates it: parse every view definition and script once, and the dependency graph — table to view to view to report, at column granularity — is available on demand for impact analysis, root-cause debugging, and audit evidence.

How SQLFlow builds SAP HANA data lineage

SQLFlow is built on the General SQL Parser (GSP), a commercial SQL compiler front-end developed since the mid-2000s and validated against roughly 13,600 per-dialect SQL test fixtures. The SAP HANA parser understands HANA’s SQL syntax specifically — quoted "SCHEMA"."OBJECT" identifiers, HANA functions and casts, HANA join and set-operator forms — rather than approximating it with a generic grammar.

For each statement, GSP builds a full semantic model: every column reference is resolved through CTEs, subqueries, views, and SELECT * expansion. The data-flow analyzer then extracts, for every output column, exactly which source columns feed it and through which functions and expressions. The result is column-level lineage you can trust for a schema change, not a table-level sketch.

You can feed HANA SQL to SQLFlow three ways: paste statements directly, upload files of view definitions and scripts, or connect over JDBC and let SQLFlow pull object definitions from the database catalog. Everything is static analysis of SQL text — SQLFlow never reads the rows in your tables.

Example: tracing a layered HANA SQL view chain

Layered SQL views are the standard HANA pattern: a cleansing view on top of raw tables, an enrichment view on top of that, an aggregate view for reporting. Here is a typical three-layer chain:

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);

Ask SQLFlow where V_REVENUE_MONTHLY.REVENUE_EUR comes from and it walks the chain automatically: REVENUE_EUR is SUM(AMOUNT_EUR), which is GROSS_AMOUNT * RATE, where GROSS_AMOUNT is ORDERS_RAW.GROSS_AMOUNT passed through TO_DECIMAL. Two source columns, three views deep, every intermediate calculation named. Run the trace the other way and you get impact analysis: retype ORDERS_RAW.GROSS_AMOUNT and SQLFlow lists every downstream column that inherits the change.

Calculated columns in SQL views — the TO_DECIMAL cast, the IFNULL default, the multiplication — are first-class in the lineage graph, so the diagram shows not just that a column flows through but what happens to it at each layer.

Direct lineage vs. indirect lineage

Look again at the example. ORDERS_RAW.STATUS never appears in any output column, yet the WHERE STATUS <> 'CANCELLED' filter absolutely shapes the revenue figure. The same goes for CURRENCY, RATE_DATE, and ORDER_DATE in the join conditions and GROUP BY.

SQLFlow models these as indirect (impact) lineage, a relationship type distinct from direct dataflow and separately toggleable in the diagram. For an audit question like “does this regulated field influence this report?”, the indirect edges are often the whole answer — and most competing lineage tools do not make the direct/indirect distinction.

Where SQLFlow fits next to SAP-native tooling

SAP’s own modeling and catalog tools are good at what they were built for: tracking artifacts created inside the SAP-modeled layer. The gap appears at the SQL level. Hand-written SQL views, migration scripts, DML in scheduled jobs, and the SQL that connects HANA to the non-SAP half of your estate are invisible to model-based lineage, because they were never registered as modeled artifacts.

That is the layer SQLFlow covers. It parses the SQL itself, so anything expressed as SQL text is traced — regardless of which tool created it. Two honest boundaries to know:

• Graphical calculation views are stored as XML models, not SQL, so they are outside the scope of SQL parsing. The SQL views layered around them, and any SQL that queries them, are fully traced.
• SQLScript procedures: SQLFlow’s dedicated procedural grammars currently cover Oracle PL/SQL and SQL Server T-SQL. For HANA, the practical approach is to analyze the SQL statements inside SQLScript bodies — the SELECT, INSERT, and view definitions where the lineage actually lives are standard HANA SQL.

Used together, the two approaches complement each other: SAP-native tooling for the modeled layer, SQL-level lineage for everything written in SQL. And because SQLFlow speaks 39 dialects, the same lineage graph extends past HANA into the Oracle, DB2, or Snowflake systems that feed it — see the Oracle data lineage and DB2 data lineage pages for those dialects. Enterprise deployments can also push results into DataHub, Microsoft Purview, or OpenMetadata through built-in export adapters.

Deployment options for SAP estates

Edition	Best for	Notes
SQLFlow Cloud	Evaluating, ad-hoc view tracing	Free tier; premium $49.99/month; paste or upload HANA SQL in the browser
SQLFlow On-Premise	Production SAP estates in regulated industries	Docker/Kubernetes inside your network, air-gap capable; $500/month or $4,800 one-time per database type
REST API / Java library	Automating lineage in CI or a data platform	Same analysis engine, callable from pipelines and JVM applications

For most HANA shops the privacy posture matters as much as the features: SQLFlow performs static analysis of SQL code and schema metadata only, and with On-Premise even the SQL text never leaves your network. Batch scanning handles estates of 100+ databases and over a million columns, with incremental rescans and a persistent lineage repository. Full details are on the pricing page, and the SQL data lineage tool overview covers the complete feature set.

Frequently asked questions

Does SQLFlow support SAP HANA?

Yes. SAP HANA is one of 39 databases with its own dialect-specific parser in SQLFlow, covering HANA SQL syntax including quoted schema-qualified identifiers, HANA functions such as IFNULL and TO_DECIMAL, and view definitions.

Can SQLFlow trace lineage through layered HANA SQL views?

Yes. Column references are resolved through views, CTEs, subqueries, and SELECT * expansion, so a column in a top-level reporting view is traced through every intermediate view down to the physical source columns, with each calculation shown along the path.

Does SQLFlow handle HANA calculation views?

Graphical calculation views are XML models rather than SQL, so they are outside the scope of SQL parsing. SQLFlow traces everything expressed as SQL: the SQL views layered around calculation views, and any SQL statements that query them.

Does SQLFlow need access to the data in my HANA tables?

No. SQLFlow performs static analysis of SQL code and optionally reads schema metadata over JDBC. It never reads table row data, and the On-Premise edition keeps even the SQL text inside your network.

How do I get my HANA SQL into SQLFlow?

Three ways: paste SQL directly into the browser, upload files of view definitions and scripts, or connect to HANA over JDBC so SQLFlow pulls object definitions from the catalog. Results export as JSON, CSV, or PNG, or through the REST API.

How much does SQLFlow cost?

SQLFlow Cloud starts free; premium accounts are $49.99/month. SQLFlow On-Premise is $500/month or $4,800 one-time per selected database type, installable on two servers, with additional database types at $100/month or $1,000 one-time each.