Exemples de traçabilité des données : 6 scénarios réels avec SQL et diagrammes

UN exemple de lignée de données Pour un exemple concret de requête SQL, cela montre quelles tables et colonnes sources alimentent quelles colonnes de sortie, et quelles transformations les données subissent. Les six exemples détaillés ci-dessous couvrent les situations que rencontrent réellement les ingénieurs de données : une requête SQL simple INSERTION-SÉLECTIONChaque exemple présente une transformation multi-CTE, une chaîne de vues, une procédure stockée avec SQL dynamique, une chaîne de modèles dbt et un flux ETL inter-bases de données. Il fournit ensuite le code SQL correspondant, puis décrit précisément le graphe de traçabilité associé.

Comment lire ces exemples

Chaque graphe de lignage contient deux types d'arêtes. A direct Un « edge » signifie que les données circulent physiquement d'une colonne source vers une colonne cible, éventuellement par le biais d'une fonction ou d'une agrégation. indirect bord signifie qu'une colonne façonne le résultat sans y entrer : colonnes utilisées dans OÙ, REJOINDRE, et GROUPER PAR clauses. Négliger les liens indirects est une erreur fréquente dans l'analyse d'impact, car la suppression d'une colonne de filtre invalide un rapport tout autant que la suppression d'une colonne sélectionnée. Si ces termes vous sont nouveaux, commencez par Qu'est-ce que la traçabilité des données ? et Comment fonctionne la lignée au niveau des colonnes, puis revenez.

Exemple 1 : un exemple simple de traçabilité des données INSERT-SELECT

Le point de départ de toute discussion sur la lignée : une déclaration répertoriant les données agrégées dans un tableau récapitulatif.

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;

Le graphique de lignage comporte trois tableaux (ordres, clients, résumé des ventes) et ces bords au niveau des colonnes :

Colonne cible	Colonne source	Type de bord	Via
résumé_des_ventes.région	clients.région	Direct	copie simple
résumé_des_ventes.montant_total	commandes.montant	Direct	SOMME()
résumé_des_ventes.*	statut des commandes	Indirect	OÙ filtre
résumé_des_ventes.*	commandes.identifiant_client, clients.id	Indirect	REJOINDRE condition

Notez ce que le graphique vous indique déjà et qu'une vue au niveau du tableau ne permettrait pas de savoir : clients.email et toutes les autres colonnes non touchées ne jouent aucun rôle ici, et statut des commandes Même si cela n'apparaît jamais dans le résultat, c'est important. De nombreux outils de traçabilité ignorent complètement cette dernière étape ; SQLFlow modélise la traçabilité directe et indirecte comme des types de relations distincts et activables.

Exemple 2 : transformation multi-CTE

CTE sont le point de départ des diagrammes de lignage dessinés à la main, car chaque CTE représente une relation temporaire que le graphe doit traverser sans perdre la trace des sources originales.

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

Le graphique de lignée s'affiche tous les jours et classé comme nœuds intermédiaires, le chemin complet de la colonne intéressante se lit donc comme suit : commandes.montant → SOMME() → total quotidien.jour → classé.jour_total → meilleur_jour_revenuLa fonction de fenêtre crée une chaîne plus subtile : rn est calculé à partir de identifiant_client (partition) et total_jour (commande), puis OÙ rn = 1 fait rn une entrée indirecte pour chaque colonne de sortie. commandes.montant influences meilleur_jour_revenu Deux fois : directement par la somme, et indirectement par le classement qui détermine quelle ligne est conservée. Un résolveur qui effectue uniquement une correspondance de motifs sur les noms de colonnes ne peut pas voir ce second chemin.

Exemple 3 : une chaîne de vues

Les vues s'empilent. Dans un entrepôt de données mature, un rapport se trouve souvent à trois ou quatre définitions de vues des tables physiques, et la question « d'où vient réellement ce chiffre ? » nécessite de parcourir toute la chaîne.

CRÉER UNE VUE v_active_customers COMME SÉLECTIONNER id, nom, email DE customers WHERE status = 'active'; CRÉER UNE VUE v_customer_revenue COMME SÉLECTIONNER a.id, a.name, SUM(o.amount) COMME revenu DE v_active_customers a JOIN orders o SUR o.customer_id = a.id GROUPER PAR a.id, a.name;

Le graphique montre v_revenu_client.revenu en suivant la limite de la vue jusqu'à commandes.montant, avec statut des clients attachée comme une arête indirecte héritée du filtre de la première vue. Elle révèle également quelque chose d'utile dans l'autre sens : v_clients_actifs.email est sélectionnée par la première vue mais n'est utilisée par aucune autre vue en aval. Les colonnes mortes comme celle-ci sont précisément celles que vous devez identifier avant un nettoyage ou une migration, car elles sont invisibles au niveau de la table. Lorsque les définitions de vues utilisent SÉLECTIONNER *SQLFlow étend l'étoile par rapport au schéma afin que chaque colonne héritée soit toujours résolue vers sa source physique.

Exemple 4 : procédure stockée avec SQL dynamique

Voici un exemple qui distingue les outils de traçabilité, car le nom de la table cible n'apparaît même pas littéralement dans le code. Voici une procédure SQL Server qui crée un instantané mensuel à l'aide d'une table temporaire et d'une structure assemblée dynamiquement. INSÉRER:

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

Le graphe de lignage correct franchit les deux obstacles : commandes.montant → SOMME() → #mensuel.total_mois → instantané_mensuel.total_du_mois, avec commandes.date_de_commande comme un bord indirect à travers le OÙ clause et la @mois Le paramètre est suivi comme entrée de ce filtre. Pour y parvenir, il faut un véritable analyseur procédural T-SQL (et non un séparateur d'instructions), le suivi des tables temporaires entre les instructions et la résolution de la chaîne SQL transmise à sp_executesqlSQLFlow dispose d'analyseurs syntaxiques dédiés au T-SQL de SQL Server et au PL/SQL d'Oracle, résout le SQL dynamique au sein des procédures et génère un graphe d'appels montrant quelles procédures en appellent d'autres, permettant ainsi de visualiser la traçabilité des procédures. Le SQL dynamique représente le principal point faible des outils de traçabilité ; lors de l'évaluation d'un outil, il est essentiel de le tester en priorité avec ce type d'analyse.

Exemple 5 : chaîne de modèles dbt

dbt vous offre une traçabilité au niveau du modèle prête à l'emploi via ref()Mais la question intéressante se pose au niveau des colonnes : quel champ source alimente quelle colonne du magasin, et par quels renommages intermédiaires ?

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

Importez le manifeste dbt du projet dans SQLFlow et le graphe résout les références modélisées en une chaîne de colonnes concrète : montant.de.commandes.brutes → stg_orders.montant → SOMME() → fct_revenu_client.revenu_vie, avec le nouveau nom identifiant → id_de_commande préservé dans le houblon de mise en scène et statut Ce flux est indirect et provient du filtre du magasin. Le manifeste reliant les modèles aux objets de l'entrepôt qu'ils créent, le même graphe assure la cohérence entre la traçabilité gérée par dbt et tous les autres éléments externes à dbt qui interagissent avec ces tables.

Exemple 6 : ETL inter-bases de données

Les moteurs de traitement des données immobilières sont omniprésents. Voici un flux typique : une base de données SQL Server opérationnelle est extraite vers un stockage cloud, chargée dans l’environnement de test Snowflake, puis transformée en un schéma analytique. Le processus de chargement et de transformation se présente comme suit :

-- Snowflake COPIE DANS staging.orders_raw DE @s3_extract/orders/; INSÉRER DANS analytics.fct_orders (order_id, customer_id, amount_usd) SÉLECTIONNER r.order_id, r.customer_id, r.amount * fx.rate DE staging.orders_raw r JOIN staging.fx_rates fx SUR fx.currency = r.currency;

Du côté de Snowflake, le graphique montre montant_USD en tant que colonne calculée avec deux parents directs, commandes_brutes.montant et taux_de_change.taux, reliés par l'expression arithmétique, plus devise Il s'agit d'une arête indirecte issue de la condition de jointure. Pour couvrir l'intégralité du pipeline, SQLFlow est alimenté de part et d'autre dans leurs dialectes respectifs : la logique d'extraction T-SQL est analysée par l'analyseur SQL Server et les scripts Snowflake par l'analyseur Snowflake, parmi 39 analyseurs spécifiques à chaque dialecte. Dans les déploiements en entreprise, les résultats sont stockés dans un référentiel de lignage persistant qui analyse par lots des environnements de plus de 100 bases de données et plus d'un million de colonnes. Ainsi, la vue d'ensemble complète du pipeline SQL Server vers Snowflake est représentée dans un seul graphique et peut être exportée vers DataHub, Microsoft Purview ou OpenMetadata.

Qu'ont en commun ces six exemples ?

Chaque graphique ci-dessus a été entièrement dérivé du texte SQL et des métadonnées de schéma. C'est la méthode de base. Traçabilité des données basée sur SQLComme la logique de transformation réside déjà dans SQL, l'analyse statique de ce SQL reconstruit la lignée sans agent, sans accès au journal des requêtes et sans jamais lire une seule ligne de vos données. Les différences entre les exemples résident uniquement dans la complexité de l'analyse syntaxique, à partir d'une seule requête. INSERTION-SÉLECTION pour utiliser du SQL dynamique à l'intérieur d'une procédure.

Exemple	Ce que cela exerce	Partie difficile
1. INSERTION-SÉLECTION	bords directs vs indirects	Modélisation OÙ/REJOINDRE colonnes comme lignée
2. Multi-CTE	Relations intermédiaires	Entrées de la fonction de fenêtre ; chemin de filtrage sur le rang
3. Voir la chaîne	Définitions imbriquées	Expansion stellaire ; découverte de colonnes mortes
4. Procédure stockée	Code de procédure	Tables temporaires et résolution SQL dynamique
5. Chaîne DBT	SQL à modèles	Résolution ref()/source() aux objets réels
6. ETL inter-bases de données	Plusieurs dialectes	Fusion des graphiques par moteur dans un seul référentiel

Foire aux questions

Qu'est-ce qu'un diagramme de traçabilité des données ?

Un diagramme de lignage des données est un graphe orienté dont les nœuds représentent des tables, des vues ou des colonnes, et les arêtes illustrent le flux de données entre ces éléments via des transformations SQL. Les diagrammes au niveau des colonnes, comme ceux décrits sur cette page, tracent une arête par relation entre une colonne source et une colonne cible, annotée avec la fonction ou la clause qui l'a créée.

Puis-je reproduire ces exemples moi-même ?

Oui. Collez l'un des extraits SQL ci-dessus dans le Visualiseur SQLFlow gratuitChoisissez le dialecte correspondant, et le diagramme interactif s'affiche en quelques secondes. L'édition cloud propose une version gratuite.

Quelle est la différence entre la lignée directe et la lignée indirecte ?

La lignée directe signifie que les données circulent d'une colonne source vers une colonne cible, par exemple. SOMME(commandes.montant) alimentation montant totalLa filiation indirecte signifie qu'une colonne influence le résultat sans y apparaître explicitement, comme par exemple une OÙ filtre ou REJOINDRE Point clé. SQLFlow suit les deux comme des types de flux distincts et activables ; la plupart des outils ne capturent que le flux direct.

Est-il possible d'extraire la lignée des procédures stockées et du SQL dynamique ?

Oui, mais il lui faut un analyseur syntaxique procédural, et non un simple analyseur de requêtes. SQLFlow dispose d'analyseurs dédiés pour Oracle PL/SQL et SQL Server T-SQL, assure le suivi de la lignée à travers les paramètres et les tables temporaires, résout les chaînes SQL construites au sein des procédures et dessine le graphe d'appels de procédure à procédure.

Les outils open source gèrent-ils ces exemples ?

En partie. Les bibliothèques comme SQL Lineage et sqlglot Ces outils sont vraiment performants pour analyser les requêtes individuelles et gèrent bien les exemples 1 et 2. Avant de valider vos modifications, il est conseillé de tester les exemples 4 à 6 : code procédural avec SQL dynamique, lignée indirecte en tant que type d'arête distinct et intégration d'un ensemble multidialectique dans un graphe interactif. Testez votre procédure stockée la plus complexe avec n'importe quel outil que vous évaluez et comparez les résultats.

Avec quels dialectes SQL ces exemples fonctionnent-ils ?

SQLFlow intègre 39 analyseurs syntaxiques spécifiques à chaque dialecte, notamment Snowflake, BigQuery, Redshift, Databricks, Oracle, SQL Server, PostgreSQL, MySQL, Teradata, Hive, Spark SQL et Trino. Les exemples ci-dessus utilisent la syntaxe SQL générique, T-SQL, SQL avec modèles dbt et Snowflake ; chaque syntaxe est analysée par sa propre grammaire plutôt que par une grammaire ANSI générique.