{"id":6748,"date":"2026-07-12T02:05:45","date_gmt":"2026-07-12T10:05:45","guid":{"rendered":"https:\/\/www.gudusoft.com\/data-lineage-examples\/"},"modified":"2026-07-13T19:03:45","modified_gmt":"2026-07-14T03:03:45","slug":"data-lineage-examples","status":"publish","type":"page","link":"https:\/\/www.gudusoft.com\/de\/datenherkunftsbeispiele\/","title":{"rendered":"Beispiele zur Datenherkunft: 6 reale Szenarien mit SQL und Diagrammen"},"content":{"rendered":"

A Beispiel f\u00fcr Datenherkunft<\/strong> Es zeigt anhand eines konkreten SQL-Abschnitts, welche Quelltabellen und -spalten welche Ausgabespalten speisen und welche Transformationen die Daten dabei durchlaufen. Die sechs unten aufgef\u00fchrten Beispiele decken Situationen ab, denen Dateningenieure tats\u00e4chlich begegnen: ein einfacher INSERT-SELECT<\/code>Es handelt sich um eine Multi-CTE-Transformation, eine Kette von Sichten, eine gespeicherte Prozedur mit dynamischem SQL, eine dbt-Modellkette und einen datenbank\u00fcbergreifenden ETL-Workflow. Jedes Beispiel enth\u00e4lt das SQL und beschreibt anschlie\u00dfend detailliert den zugeh\u00f6rigen Datenherkunftsgraphen.<\/p>\n\n\n\n

6<\/b>Durchgerechnete Beispiele, jeweils mit echtem SQL<\/span><\/div>
39<\/b>SQL-Dialekte, jeweils ein eigener Parser<\/span><\/div>
Spaltenebene<\/b>Granularit\u00e4t, nicht nur Tabellenebene<\/span><\/div>
Direkt + indirekt<\/b>Kanten, beide verfolgt<\/span><\/div><\/div>\n\n\n\n
\n\n

Alle Beispiele auf dieser Seite sind reproduzierbar:<\/strong> F\u00fcgen Sie den SQL-Code in die folgende Datei ein: kostenloser SQLFlow-Lineage-Visualisierer<\/a> und Sie erhalten das unten beschriebene interaktive Diagramm.<\/p>\n\n<\/div><\/div>\n\n\n\n

Wie man diese Beispiele liest<\/h2>\n\n\n\n

Jeder Abstammungsgraph enth\u00e4lt zwei Arten von Kanten.<\/strong> A direkt<\/strong> Edge bedeutet, dass Daten physisch von einer Quellspalte in eine Zielspalte flie\u00dfen, m\u00f6glicherweise \u00fcber eine Funktion oder Aggregation. indirekt<\/strong> Kante bedeutet, dass eine Spalte das Ergebnis formt, ohne darin zu landen: Spalten, die verwendet werden in WO<\/code>, VERBINDEN<\/code>, Und GRUPPE NACH<\/code> Klauseln. Das \u00dcbersehen indirekter Auswirkungen ist der Grund, warum Wirkungsanalysen fehlschlagen, denn das Entfernen einer Filterspalte f\u00fchrt genauso sicher zu einem fehlerhaften Bericht wie das Entfernen einer ausgew\u00e4hlten Spalte. Falls Ihnen diese Begriffe neu sind, beginnen Sie mit Was ist Datenherkunft?<\/a> Und wie die Herkunftsanalyse auf Spaltenebene funktioniert<\/a>Dann komm zur\u00fcck.<\/p>\n\n\n\n

Beispiel 1: ein einfaches Beispiel zur Datenherkunft bei einer INSERT-SELECT-Anweisung<\/h2>\n\n\n\n

Ausgangspunkt jeder Abstammungsdiskussion: eine Anweisung, die aggregierte Daten in eine \u00dcbersichtstabelle schreibt.<\/p>\n\n\n\n

INSERT INTO sales_summary (region, total_amount) SELECT c.region, SUM(o.amount) FROM orders o JOIN customers c ON o.customer_id = c.id WHERE o.status = 'completed' GROUP BY c.region;<\/code><\/pre>\n\n\n\n
Der Stammbaum besteht aus drei Tabellen (Bestellungen<\/code>, Kunden<\/code>, Verkaufs\u00fcbersicht<\/code>und diese Kanten auf Spaltenebene:<\/p>\n\n\n\n
\n
Zielspalte<\/th>Quelle Spalte<\/th>Kantentyp<\/th>\u00dcber<\/th><\/tr><\/thead>
Vertriebs\u00fcbersicht Region<\/code><\/td>Kundenregion<\/code><\/td>Direkt<\/td>einfache Kopie<\/td><\/tr>\n
Gesamtbetrag der Verk\u00e4ufe<\/code><\/td>Bestellungen.Betrag<\/code><\/td>Direkt<\/td>SUMME()<\/code><\/td><\/tr>\n
Verkaufs\u00fcbersicht.*<\/code><\/td>Bestellungen.Status<\/code><\/td>Indirekt<\/td>WO<\/code> Filter<\/td><\/tr>\n
Verkaufs\u00fcbersicht.*<\/code><\/td>orders.customer_id<\/code>, Kunden-ID<\/code><\/td>Indirekt<\/td>VERBINDEN<\/code> Zustand<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n
Beachten Sie, was Ihnen das Diagramm bereits zeigt, was eine Tabellenansicht nicht zeigen w\u00fcrde: Kunden-E-Mail<\/code> und alle anderen unber\u00fchrten Spalten spielen hier keine Rolle, Bestellungen.Status<\/code> Es ist relevant, auch wenn es nie in der Ausgabe erscheint. Viele Lineage-Tools \u00fcberspringen diesen letzten Schritt vollst\u00e4ndig; SQLFlow modelliert direkte und indirekte Lineage als separate, umschaltbare Beziehungstypen.<\/p>\n\n\n\n
Beispiel 2: Multi-CTE-Transformation<\/h2>\n\n\n\n
Bei CTEs (Common Table Expressions) beginnt die Geschichte der handgezeichneten Stammbaumdiagramme, denn jede CTE ist eine tempor\u00e4re Relation, die der Graph durchlaufen muss, ohne die urspr\u00fcnglichen Quellen aus den Augen zu verlieren.<\/p>\n\n\n\n
WITH daily AS ( SELECT order_date, customer_id, SUM(amount) AS day_total FROM orders GROUP BY order_date, customer_id ), ranked AS ( SELECT customer_id, day_total, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY day_total DESC) AS rn FROM daily ) SELECT customer_id, day_total AS best_day_revenue FROM ranked WHERE rn = 1;<\/code><\/pre>\n\n\n\n
Der Stammbaum wird dargestellt t\u00e4glich<\/code> Und Rangliste<\/code> als Zwischenknoten, sodass der vollst\u00e4ndige Pfad der relevanten Spalte lautet: Bestellungen.Betrag<\/code> \u2192 SUMME()<\/code> \u2192 t\u00e4glich.Tagesgesamt<\/code> \u2192 Rangliste.Tagesgesamt<\/code> \u2192 bester Tagesumsatz<\/code>Die Fensterfunktion erzeugt eine subtilere Kette: rn<\/code> wird berechnet aus Kunden-ID<\/code> (Partition) und Tagesgesamt<\/code> (Reihenfolge), und dann WHERE rn = 1<\/code> macht rn<\/code> ein indirekter Input f\u00fcr jede Ausgabespalte. Bestellungen.Betrag<\/code> Einfl\u00fcsse bester Tagesumsatz<\/code> Zweimal: direkt \u00fcber die Summe und indirekt \u00fcber die Rangfolge, die entscheidet, welche Zeile erhalten bleibt. Ein Resolver, der nur Spaltennamen nach Mustern abgleicht, kann diesen zweiten Pfad nicht erkennen.<\/p>\n\n\n\n
Beispiel 3: eine Kette von Ansichten<\/h2>\n\n\n\n
Ansichten stapeln sich. In einem ausgereiften Data Warehouse befindet sich ein Bericht oft drei oder vier Ansichtsdefinitionen von den physischen Tabellen entfernt, und die Frage \u201eWoher kommt diese Zahl eigentlich?\u201c erfordert das Durchlaufen der gesamten Kette.<\/p>\n\n\n\n
CREATE VIEW v_active_customers AS SELECT id, name, email FROM customers WHERE status = 'active'; CREATE VIEW v_customer_revenue AS SELECT a.id, a.name, SUM(o.amount) AS revenue FROM v_active_customers a JOIN orders o ON o.customer_id = a.id GROUP BY a.id, a.name;<\/code><\/pre>\n\n\n\n
Die Grafik zeigt v_customer_revenue.revenue<\/code> durch die Sichtgrenze zur\u00fcckverfolgen zu Bestellungen.Betrag<\/code>, mit Kundenstatus<\/code> Es ist als indirekte Kante angeh\u00e4ngt, die vom Filter der ersten Ansicht geerbt wurde. Es offenbart auch etwas N\u00fctzliches in der anderen Richtung: v_active_customers.email<\/code> wird von der ersten Ansicht ausgew\u00e4hlt, aber von keiner nachfolgenden Ansicht verwendet. Solche toten Spalten sind genau das, was Sie vor einer Bereinigung oder Migration finden m\u00f6chten, und sie sind auf Tabellenebene unsichtbar. Wenn Ansichtsdefinitionen verwenden W\u00c4HLEN *<\/code>SQLFlow erweitert den Stern anhand des Schemas, sodass jede geerbte Spalte weiterhin auf ihre physische Quelle aufgel\u00f6st wird.<\/p>\n\n\n\n
\n\n
Beispiel 4: Gespeicherte Prozedur mit dynamischem SQL<\/h2>\n\n\n\n
Dieses Beispiel verdeutlicht die Unterschiede zwischen Lineage-Tools, da der Name der Zieltabelle im Code nicht einmal als Literaltext existiert. Hier ist eine SQL-Server-Prozedur, die mithilfe einer tempor\u00e4ren Tabelle und einer dynamisch zusammengestellten Tabelle einen monatlichen Snapshot erstellt. EINF\u00dcGEN<\/code>:<\/p>\n\n\n\n
CREATE PROCEDURE dbo.load_monthly_snapshot @month VARCHAR(7) AS BEGIN SELECT o.customer_id, SUM(o.amount) AS month_total INTO #monthly FROM dbo.orders o WHERE CONVERT(VARCHAR(7), o.order_date, 126) = @month GROUP BY o.customer_id; DECLARE @sql NVARCHAR(MAX) = N'INSERT INTO dbo.snapshot_monthly (customer_id, month_total) ' + N'SELECT customer_id, month_total FROM #monthly'; EXEC sp_executesql @sql; END<\/code><\/pre>\n\n\n\n
Der korrekte Abstammungsgraph \u00fcberwindet beide Hindernisse: Bestellungen.Betrag<\/code> \u2192 SUMME()<\/code> \u2192 #monthly.month_total<\/code> \u2192 snapshot_monthly.month_total<\/code>, mit orders.order_date<\/code> als indirekte Kante durch die WO<\/code> Klausel und die @Monat<\/code> Der Parameter wird als Eingabe f\u00fcr diesen Filter verfolgt. Um dies zu erreichen, ben\u00f6tigt man einen echten T-SQL-Prozedurparser (keinen Statement-Splitter), die Verfolgung tempor\u00e4rer Tabellen \u00fcber Anweisungen hinweg und die Aufl\u00f6sung der \u00fcbergebenen SQL-Zeichenkette. sp_executesql<\/code>SQLFlow verf\u00fcgt \u00fcber spezielle Prozedurparser f\u00fcr SQL Server T-SQL und Oracle PL\/SQL, l\u00f6st dynamisches SQL innerhalb von Prozeduren auf und erstellt zus\u00e4tzlich einen Aufrufgraphen, der die Aufrufreihenfolge der einzelnen Prozeduren darstellt. Dadurch wird auch die Herkunft der Prozeduren sichtbar. Dynamisches SQL ist die h\u00e4ufigste Schwachstelle von Tools zur Herkunftsanalyse; testen Sie daher jedes Tool zun\u00e4chst anhand dieses Musters.<\/p>\n\n<\/div><\/div>\n\n\n\n
Beispiel 5: dbt-Modellkette<\/h2>\n\n\n\n
dbt bietet Ihnen standardm\u00e4\u00dfig Modell-Lineage \u00fcber ref()<\/code>Die interessante Frage ist jedoch die auf Spaltenebene: Welches Quellfeld speist welche Mart-Spalte, und zwar \u00fcber welche Staging-Umbenennungen?<\/p>\n\n\n\n
-- models\/staging\/stg_orders.sql SELECT id AS order_id, customer_id, amount, status FROM {{ source('raw', 'orders') }} -- models\/marts\/fct_customer_revenue.sql SELECT customer_id, SUM(amount) AS lifetime_revenue FROM {{ ref('stg_orders') }} WHERE status = 'completed' GROUP BY customer_id<\/code><\/pre>\n\n\n\n
Importieren Sie das dbt-Manifest des Projekts in SQLFlow, und der Graph l\u00f6st die Vorlagenreferenzen in eine konkrete Spaltenkette auf: Rohbestellungen<\/code> \u2192 stg_orders.amount<\/code> \u2192 SUMME()<\/code> \u2192 fct_customer_revenue.lifetime_revenue<\/code>, mit der Umbenennung Ausweis<\/code> \u2192 Bestellnummer<\/code> erhalten im Zwischenstopp und Status<\/code> Die Daten werden als indirekte Kante vom Filter des Datenmarktes \u00fcbertragen. Da das Manifest Modelle mit den von ihnen erstellten Warehouse-Objekten verkn\u00fcpft, gleicht derselbe Graph die von dbt verwaltete Datenherkunft mit allen anderen Daten ab, die au\u00dferhalb von dbt auf diese Tabellen zugreifen.<\/p>\n\n\n\n
Beispiel 6: Datenbank\u00fcbergreifendes ETL<\/h2>\n\n\n\n
Immobilien-Engines sind eng miteinander verkn\u00fcpft. Ein typischer Ablauf: Eine operative SQL-Server-Datenbank wird in den Cloud-Speicher extrahiert, in Snowflake Staging geladen und anschlie\u00dfend in ein Analyseschema transformiert. Der Lade- und Transformationsprozess sieht folgenderma\u00dfen aus:<\/p>\n\n\n\n
-- Snowflake COPY INTO staging.orders_raw FROM @s3_extract\/orders\/; INSERT INTO analytics.fct_orders (order_id, customer_id, amount_usd) SELECT r.order_id, r.customer_id, r.amount * fx.rate FROM staging.orders_raw r JOIN staging.fx_rates fx ON fx.currency = r.currency;<\/code><\/pre>\n\n\n\n
Auf der Snowflake-Seite zeigt das Diagramm Folgendes: Betrag_USD<\/code> als berechnete Spalte mit zwei direkten \u00fcbergeordneten Spalten, orders_raw.amount<\/code> Und fx_rates.rate<\/code>, verbunden durch den arithmetischen Ausdruck, plus W\u00e4hrung<\/code> Als indirekte Kante aus der Join-Bedingung. Um die gesamte Pipeline abzudecken, werden beide Seiten mit SQLFlow in ihren jeweiligen Dialekten gespeist: Die T-SQL-Extraktionslogik wird mit dem SQL-Server-Parser und die Snowflake-Skripte mit dem Snowflake-Parser analysiert \u2013 insgesamt stehen 39 dialektspezifische Parser zur Verf\u00fcgung. In Unternehmensumgebungen werden die Ergebnisse in einem persistenten Lineage-Repository gespeichert, das Datenbanken mit \u00fcber 100 Datenbanken und mehr als einer Million Spalten im Batch-Verfahren durchsucht. So wird die gesamte SQL-Server-zu-Snowflake-Pipeline in einem einzigen Graphen abgebildet und kann nach DataHub, Microsoft Purview oder OpenMetadata exportiert werden.<\/p>\n\n\n\n
Was alle sechs Beispiele gemeinsam haben<\/h2>\n\n\n\n
Alle obigen Diagramme wurden ausschlie\u00dflich aus SQL-Text und Schema-Metadaten abgeleitet. Das ist die Kernmethode dahinter. SQL-basierte Datenherkunft<\/a>Da die Transformationslogik bereits in SQL implementiert ist, rekonstruiert die statische Analyse dieses SQL-Codes die Datenherkunft ohne zus\u00e4tzliche Agenten, ohne Zugriff auf das Abfrageprotokoll und ohne jemals eine Zeile Ihrer Daten zu lesen. Die Unterschiede zwischen den Beispielen liegen lediglich im Aufwand der Analyse, ausgehend von einer einzigen Abfrage. INSERT-SELECT<\/code> zu dynamischem SQL innerhalb einer Prozedur.<\/p>\n\n\n\n
\n
Beispiel<\/th>Was es trainiert<\/th>Schwieriger Teil<\/th><\/tr><\/thead>
1. INSERT-SELECT<\/td>Direkte vs. indirekte Kanten<\/td>Modellieren WO<\/code>\/VERBINDEN<\/code> Spalten als Abstammung<\/td><\/tr>\n
2. Multi-CTE<\/td>Zwischenbeziehungen<\/td>Eingaben f\u00fcr Fensterfunktionen; Pfad des Filters auf Rangebene<\/td><\/tr>\n
3. Kette ansehen<\/td>Verschachtelte Definitionen<\/td>Sternenexpansion; Auffinden toter S\u00e4ulen<\/td><\/tr>\n
4. Gespeicherte Prozedur<\/td>Verfahrensordnung<\/td>Tempor\u00e4re Tabellen und dynamische SQL-Aufl\u00f6sung<\/td><\/tr>\n
5. DBT-Kette<\/td>SQL-Vorlage<\/td>L\u00f6sung ref()<\/code>\/Quelle()<\/code> zu realen Objekten<\/td><\/tr>\n
6. Datenbank\u00fcbergreifendes ETL<\/td>Mehrere Dialekte<\/td>Zusammenf\u00fchren von Diagrammen pro Motor in einem Repository<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n
\n\n
Siehe die Herkunft deiner eigenen SQL-Anweisungen<\/h2>\n\n\n
F\u00fcgen Sie eine beliebige Abfrage, Prozedur oder ein Skript ein und erhalten Sie innerhalb von Sekunden ein Diagramm auf Spaltenebene.<\/p>\n\n\n
\n
Testen Sie SQLFlow kostenlos<\/a><\/div>\n\n\n
Siehe das Abstammungstool<\/a><\/div>\n<\/div>\n\n<\/div><\/div>\n\n\n\n
H\u00e4ufig gestellte Fragen<\/h2>\n\n\n\n
Was ist ein Datenherkunftsdiagramm?<\/h3>\n\n\n
Ein Datenherkunftsdiagramm ist ein gerichteter Graph, dessen Knoten Tabellen, Sichten oder Spalten darstellen und dessen Kanten den Datenfluss zwischen ihnen durch SQL-Transformationen zeigen. Spaltendiagramme, wie die auf dieser Seite beschriebenen, zeichnen f\u00fcr jede Quellspalten-Zielspalten-Beziehung eine Kante, die mit der Funktion oder Klausel beschriftet ist, die diese Beziehung erzeugt hat.<\/p>\n\n\n\n
Kann ich diese Beispiele selbst nachstellen?<\/h3>\n\n\n
Ja. F\u00fcgen Sie einen der oben stehenden SQL-Codeausschnitte in die folgende Datei ein: kostenloser SQLFlow-Visualisierer<\/a>W\u00e4hlen Sie den passenden Dialekt aus, und das interaktive Diagramm erscheint in Sekundenschnelle. Die Cloud-Version bietet eine kostenlose Basisversion.<\/p>\n\n\n\n
Worin besteht der Unterschied zwischen direkter und indirekter Abstammung?<\/h3>\n\n\n
Direkte Datenherkunft bedeutet, dass Daten von einer Quellspalte in eine Zielspalte flie\u00dfen, zum Beispiel SUMME(orders.amount)<\/code> F\u00fctterung Gesamtbetrag<\/code>Indirekte Abstammung bedeutet, dass eine Spalte das Ergebnis beeinflusst, ohne selbst darin aufzutreten, wie zum Beispiel eine WO<\/code> Filter oder VERBINDEN<\/code> Wichtig. SQLFlow verfolgt beides als separate, umschaltbare Kantentypen; die meisten Tools erfassen nur den direkten Datenfluss.<\/p>\n\n\n\n
L\u00e4sst sich die Herkunft aus gespeicherten Prozeduren und dynamischem SQL extrahieren?<\/h3>\n\n\n
Ja, aber es ben\u00f6tigt einen Prozedurparser, nicht nur einen Abfrageparser. SQLFlow verf\u00fcgt \u00fcber dedizierte Parser f\u00fcr Oracle PL\/SQL und SQL Server T-SQL, verfolgt die Befehlskette \u00fcber Parameter und tempor\u00e4re Tabellen, l\u00f6st SQL-Zeichenketten innerhalb von Prozeduren auf und erstellt den Aufrufgraphen zwischen den Prozeduren.<\/p>\n\n\n\n
K\u00f6nnen Open-Source-Tools diese Beispiele verarbeiten?<\/h3>\n\n\n
Teilweise. Bibliotheken wie sqllineage<\/code> Und sqlglot<\/code> Sie sind wirklich gut darin, einzelne Abfragen zu analysieren, und sie bew\u00e4ltigen die Beispiele 1 und 2 problemlos. Die Beispiele 4 bis 6 sollten Sie vor dem Commit testen: prozeduraler Code mit dynamischem SQL, indirekte Herkunft als separater Kantentyp und das Zusammenf\u00fchren eines mehrsprachigen Gebiets zu einem interaktiven Graphen. F\u00fchren Sie Ihre komplexeste gespeicherte Prozedur mit einem beliebigen Tool Ihrer Wahl aus und vergleichen Sie die Ausgabe.<\/p>\n\n\n\n
Mit welchen SQL-Dialekten funktionieren diese Beispiele?<\/h3>\n\n\n
SQLFlow enth\u00e4lt 39 dialektspezifische Parser, darunter f\u00fcr Snowflake, BigQuery, Redshift, Databricks, Oracle, SQL Server, PostgreSQL, MySQL, Teradata, Hive, Spark SQL und Trino. Die obigen Beispiele verwenden generisches SQL, T-SQL, dbt-templatisiertes SQL und Snowflake-Syntax. Jede Syntax wird anhand ihrer eigenen Grammatik und nicht anhand einer generischen ANSI-Grammatik analysiert.<\/p>\n\n\n\n
\n\n
Wandeln Sie Ihre eigenen SQL-Abfragen in ein Herkunftsdiagramm um.<\/h2>\n\n\n
F\u00fcgen Sie eine Abfrage, eine Prozedur oder ein komplettes Skript in den kostenlosen Visualisierer ein und erhalten Sie innerhalb von Sekunden ein Diagramm auf Spaltenebene. F\u00fcr gr\u00f6\u00dfere Datenbanklandschaften sprechen Sie uns bitte auf das Enterprise-Repository an.<\/p>\n\n\n
\n
Testen Sie SQLFlow kostenlos<\/a><\/div>\n\n\n
Fordern Sie eine Enterprise-Demo an<\/a><\/div>\n<\/div>\n\n<\/div><\/div>\n\n\n\n