{"id":6756,"date":"2026-07-12T02:06:52","date_gmt":"2026-07-12T10:06:52","guid":{"rendered":"https:\/\/www.gudusoft.com\/postgresql-data-lineage\/"},"modified":"2026-07-12T02:06:52","modified_gmt":"2026-07-12T10:06:52","slug":"postgresql-data-lineage","status":"publish","type":"page","link":"https:\/\/www.gudusoft.com\/de\/postgresql-data-lineage\/","title":{"rendered":"PostgreSQL-Datenherkunft: Spaltenebene Herkunft aus Views und SQL"},"content":{"rendered":"

PostgreSQL-Datenherkunft<\/strong> Es handelt sich um die Spalten\u00fcbersicht, die zeigt, wie Daten durch Ihre PostgreSQL-Views, CTEs und DML-Anweisungen flie\u00dfen: welche Basistabellenspalten die einzelnen View- oder Berichtspalten speisen und welche Joins, Filter, Casts und Aggregationen die Daten dabei transformieren. Der PostgreSQL-Katalog selbst zeigt Ihnen, dass Objekte voneinander abh\u00e4ngen. pg_depend<\/code> Es wird zwar protokolliert, dass eine Ansicht auf eine Tabelle verweist \u2013 aber es wird nichts dar\u00fcber ausgesagt, wie Spalten transformiert werden. Um die tats\u00e4chliche Datenherkunft nachzuverfolgen, muss der SQL-Code selbst analysiert werden, und genau das ist es, was Gudu SQLFlow<\/strong> tut dies mit einem dedizierten PostgreSQL-Dialektparser anstelle einer generischen ANSI-Grammatik.<\/p>\n\n\n\n

\n\n

Probieren Sie es in 30 Sekunden:<\/strong> F\u00fcgen Sie eine beliebige PostgreSQL-Abfrage oder Ansichtsdefinition in die folgende ein: kostenloser SQLFlow-Lineage-Visualisierer<\/a> und erhalten Sie ein interaktives Stammbaumdiagramm auf Spaltenebene. Die Cloud-Edition bietet eine kostenlose Basisversion.<\/p>\n\n<\/div><\/div>\n\n\n\n

Warum pg_depend keine Abstammungsfragen beantworten kann<\/h2>\n\n\n\n

PostgreSQL f\u00fchrt akribische Abh\u00e4ngigkeitsaufzeichnungen. pg_depend<\/code> Und pg_rewrite<\/code> wissen, dass v_region_revenue<\/code> kann nicht fallen gelassen werden, solange es sich darauf bezieht. v_orders_enriched<\/code>, Und Informationsschema<\/code> Ansichten zeigen an, auf welche Tabellen eine Ansicht zugreift. Das ist Abh\u00e4ngigkeitsverfolgung auf Objektebene, die f\u00fcr Folgendes entwickelt wurde: DROP ... CASCADE<\/code> Sicherheit \u2013 nicht Abstammung.<\/p>\n\n\n\n

Was der Katalog Ihnen nicht verraten kann: welche spezifischen Spalten speisen Einnahmen<\/code>, ob Menge<\/code> wurde auf dem Weg geworfen oder angesammelt, ob Status<\/code> Die Filterung des Ergebnisses, ohne darin aufzutauchen, und die Darstellung des vollst\u00e4ndigen Pfades bei drei oder vier Ebenen tief gestapelten Ansichten. Um Fragen wie \u201eWoher kommt diese Zahl?\u201c oder \u201eWas passiert, wenn ich diese Spalte entferne?\u201c zu beantworten, muss die Transformationslogik aus dem in den Ansichtsdefinitionen gespeicherten SQL-Text rekonstruiert werden \u2013 ein Parsing-Problem, keine Katalogabfrage.<\/p>\n\n\n\n

Wie SQLFlow die Datenherkunft von PostgreSQL erstellt<\/h2>\n\n\n\n
  1. SQL-Daten erfassen.<\/strong> Einf\u00fcgen von Abfragen, Hochladen von Skriptdateien, Verbinden mit PostgreSQL \u00fcber JDBC, um DDL abzurufen und Definitionen direkt anzuzeigen, oder Importieren eines dbt-Manifests f\u00fcr dbt-on-Postgres-Projekte.<\/li>\n
  2. Parsen mit einer PostgreSQL-spezifischen Grammatik.<\/strong> SQLFlow basiert auf Allgemeiner SQL-Parser (GSP)<\/a>, a commercial SQL compiler front-end developed since the mid-2000s and validated against roughly 13,600 per-dialect test fixtures. Its PostgreSQL parser handles the dialect’s own constructs \u2014 writable CTEs, EINF\u00dcGEN ... BEI KONFLIKTEN<\/code>, Die ::<\/code> Cast-Operator, Vererbung und Partitionierung in DDL \u2013 und der zugeh\u00f6rige semantische Resolver werden erweitert W\u00c4HLEN *<\/code>, l\u00f6st Spaltenreferenzen \u00fcber CTEs, Unterabfragen und Sichtdefinitionen auf und extrahiert dann Quell-Ziel-Beziehungen auf Spaltenebene.<\/li>\n
  3. Visualisieren und exportieren.<\/strong> Das Ergebnis ist ein interaktives Diagramm, mit dem Sie die Datenstr\u00f6me von jeder Spalte aus vor- und nachgelagert verfolgen k\u00f6nnen. Es l\u00e4sst sich als JSON, CSV oder PNG exportieren oder \u00fcber eine REST-API abfragen.<\/li><\/ol>\n\n\n\n

    PostgreSQL ist einer von 39 Dialekten, f\u00fcr die SQLFlow Parser bereitstellt \u2013 darunter die PostgreSQL-basierten Engines Greenplum, Amazon Redshift und EDB Postgres. Jede dieser Engines verf\u00fcgt \u00fcber einen eigenen Parser, da sie sich in f\u00fcr die Lineage-Engine relevanten Aspekten vom PostgreSQL-Kern unterscheiden. Die vollst\u00e4ndige Methodik wird im [Dokument\/der Dokumentation einf\u00fcgen] beschrieben. \u00dcberblick \u00fcber SQL-Datenherkunftstools<\/a>.<\/p>\n\n\n\n

    Eine verschachtelte Ansichtskette bis zu den Basistabellen zur\u00fcckverfolgen<\/h2>\n\n\n\n

    View-on-View-Stacks sind die Standardmethode, mit der Logik in PostgreSQL akkumuliert wird, und hier st\u00f6\u00dft die manuelle Nachverfolgung an ihre Grenzen. Betrachten wir eine zweistufige Kette:<\/p>\n\n\n\n

    CREATE VIEW v_orders_enriched AS SELECT o.order_id, o.customer_id, o.amount::numeric(12,2) AS amount, c.region FROM orders o JOIN customers c ON c.customer_id = o.customer_id WHERE o.status = 'shipped'; CREATE VIEW v_region_revenue AS SELECT region, SUM(amount) AS revenue FROM v_orders_enriched GROUP BY region;<\/code><\/pre>\n\n\n\n
    Fragen Sie SQLFlow, wo v_region_revenue.revenue<\/code> kommt von und l\u00f6st die gesamte Kette auf: Einnahmen<\/code> Ist SUMME()<\/code> \u00fcber v_orders_enriched.amount<\/code>, was ein numeric(12,2)<\/code> Besetzung Bestellungen.Betrag<\/code>Das Diagramm zeigt jeden Schritt \u2013 Basistabelle, Zwischenansicht, Aggregat \u2013 als einen detailliert erfassbaren Pfad, nicht als eine vereinfachte Annahme. Es verdeutlicht auch, was bei einer oberfl\u00e4chlichen Betrachtung \u00fcbersehen wird: Bestellungen.Status<\/code> Sie erscheint nie in den Ergebnissen, dennoch h\u00e4ngt jede Umsatzzahl davon ab. WHERE o.status = 'shipped'<\/code> Filter. SQLFlow protokolliert dies als indirekte Herkunft (mehr dazu weiter unten).<\/p>\n\n\n\n
    Dieselbe Aufl\u00f6sung funktioniert in jeder Tiefe. In einem realen Schema, in dem Ansichten f\u00fcnf Ebenen tief gestapelt sind und die H\u00e4lfte davon verwendet wird W\u00c4HLEN *<\/code>SQLFlow erweitert die Sterne anhand der tats\u00e4chlichen Tabellendefinitionen, die \u00fcber JDBC abgerufen werden, sodass die Herkunft spaltengenau bleibt, selbst wenn der SQL-Text die Spalten nicht benennt.<\/p>\n\n\n\n
    PostgreSQL-Konstrukte, die generische Parser beeintr\u00e4chtigen<\/h2>\n\n\n\n
    Tools, die PostgreSQL als \u201eungef\u00e4hr ANSI SQL\u201c behandeln, versagen genau bei den Anweisungen, die den gr\u00f6\u00dften Datenfluss aufweisen. Diese werden alle vom PostgreSQL-Dialektparser von SQLFlow verarbeitet:<\/p>\n\n\n\n
    \n
    Konstrukt<\/th>Warum es f\u00fcr die Abstammung wichtig ist<\/th><\/tr><\/thead>
    Beschreibbare CTEs (MIT ... EINF\u00dcGEN\/AKTUALISIEREN\/L\u00d6SCHEN ... ZUR\u00dcCKGEBEN<\/code>)<\/td>Eine einzelne Anweisung liest und schreibt gleichzeitig: Die DML-Ausgabe der CTE speist die \u00e4u\u00dfere Abfrage. Die Datenherkunft muss die ge\u00e4nderte Tabelle mit der R\u00dcCKKEHR<\/code> Spalten und das Endergebnis in einem Diagramm.<\/td><\/tr>\n
    EINF\u00dcGEN ... BEI KONFLIKT AKTUALISIEREN<\/code><\/td>Upserts leiten Daten \u00fcber zwei Pfade \u2013 den Einf\u00fcgepfad und den Aktualisierungspfad. AUSGESCHLOSSEN<\/code> Pseudotabelle. Beides sind reale Spaltenfl\u00fcsse in die Zieltabelle.<\/td><\/tr>\n
    Tabellenvererbung und deklarative Partitionierung<\/td>Abfragen einer \u00fcbergeordneten Tabelle lesen implizit deren untergeordnete Tabellen. SQLFlow analysiert das Vererbungs- und Partitionierungs-DDL, sodass die Herkunft korrekt auf Ebene der \u00fcbergeordneten Tabelle verkn\u00fcpft wird, anstatt pro Partition fragmentiert zu werden.<\/td><\/tr>\n
    Verkettete CTEs und verschachtelte Ansichten<\/td>Spaltenreferenzen m\u00fcssen \u00fcber jede Zwischenschicht hinweg aufgel\u00f6st werden, einschlie\u00dflich CTEs, die auf fr\u00fchere CTEs verweisen, bis hin zu den physischen Basistabellen.<\/td><\/tr>\n
    ::<\/code> Casts und Ausdrucksspalten<\/td>Jede Ausgabespalte wird mithilfe der angewendeten Funktionen und Typumwandlungen ihren Quellen zugeordnet, sodass Sie nicht nur sehen k\u00f6nnen Wo<\/em> ein Wert entstand aus, aber Was ist damit geschehen?<\/em>.<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n
    Direkte vs. indirekte Abstammung: Die Filterspalten, die Sie sonst \u00fcbersehen w\u00fcrden<\/h2>\n\n\n\n
    SQLFlow unterscheidet direkte Abstammung<\/strong> \u2014 Spaltenwerte, die physisch in eine Ausgabe flie\u00dfen \u2014 von indirekte (Einfluss-)Abstammungslinie<\/strong> \u2014 Spalten verwendet in WO<\/code> Klauseln, VERBINDEN<\/code> Bedingungen und GRUPPE NACH<\/code> Schl\u00fcssel, die das Ergebnis beeinflussen, ohne darin zu landen. Im obigen Beispiel: Bestellungen.Betrag<\/code> ist direkte Abstammung f\u00fcr Einnahmen<\/code>; Bestellungen.Status<\/code> und beide Kunden-ID<\/code> Join-Schl\u00fcssel sind indirekt.<\/p>\n\n\n\n
    Die Unterscheidung l\u00e4sst sich im Diagramm umschalten und hat Auswirkungen auf reale Entscheidungen. Wenn Sie planen, den Definitionsbereich zu \u00e4ndern, Bestellungen.Status<\/code>Die direkte Herkunftsanalyse besagt, dass keine Abh\u00e4ngigkeiten bestehen; die indirekte Herkunftsanalyse zeigt jeden Umsatzbericht an, der im Hintergrund gefiltert wird. Die meisten Herkunftsanalyse-Tools bilden diese Beziehungsart \u00fcberhaupt nicht ab.<\/p>\n\n\n\n
    Von einer einzelnen Abfrage bis hin zu einem kompletten PostgreSQL-System<\/h2>\n\n\n\n
    F\u00fcr eine einzelne, komplexe View-Kette reicht der kostenlose Tarif von SQLFlow Cloud aus: einf\u00fcgen, analysieren, detailliert aufschl\u00fcsseln. Dar\u00fcber hinaus:<\/p>\n\n\n\n