Analyseur de lignage et d’impact SQL

Collez du SQL ou importez un projet pour suivre les transformations et leurs effets en aval. Les schémas améliorent la résolution ; le SQL dynamique peut rester incomplet.

Fonctionne localement dans votre navigateur

Voir la catégorie: SQL et bases de données (12)

TRAITEMENT LOCAL Lignage des colonnes Analyse statique

Votre SQL, votre schéma et vos fichiers sélectionnés sont analysés dans ce navigateur. KivTools ne les téléverse pas pour l’analyse de lignage.

INPUT

Espace de travail de saisie

Préparation du moteur SQL local…

Aucun fichier sélectionné Déposez les fichiers SQL, ZIP ou dbt ici

Dialecte

Choisissez le dialecte SQL réel lorsqu'il est connu pour une analyse plus précise.

OUTPUT

Graphique de lignée

En attente d'analyse

Tracer une colonne de la source à la sortie

Chargez l'exemple ou collez SQL, puis analysez-le avec le moteur SQLGlot local.

Direct Transformation Contexte

QUALITY

Couverture de l'analyse

Source	Instruction	Statut	Confiance

Détails

Sélectionnez un nœud dans le graphique

Les détails du nœud, les fragments SQL et les chemins de lignée de texte apparaissent ici.

Impact en aval

Chemins déterministes

Sélectionnez une colonne source pour compter les colonnes, les vues et les résultats finaux concernés.

Source SQL

LIGNAGE SQL

Tracez les dépendances SQL avant de modifier une requête

Le lignage des colonnes suit les colonnes source à travers les expressions, les CTE et les vues de chaque sortie. L’analyse d’impact inverse ces chemins pour montrer ce qu’un changement de source peut affecter.

Ce que cet analyseur résout

SELECT, alias, JOIN, sous-requêtes, CTE, UNION, agrégats, fonctions de fenêtre, QUALIFY, MERGE, CREATE VIEW, CTAS et INSERT SELECT.

Quand les informations de schéma sont utiles

Les définitions CREATE TABLE améliorent l'expansion de SELECT *, la résolution et la qualification des colonnes ambiguës.

Limites de l’analyse statique

Le SQL dynamique et les procédures stockées ne sont analysés que partiellement. Rien n’est exécuté sur une base de données.

Comment lire le lignage de colonnes d’un SQL

Collez le SQL ou chargez des fichiers .sql, choisissez un dialecte et cliquez sur Analyser le lignage. L’analyseur est SQLGlot 30.17.0 sur Pyodide, dans un Web Worker : les fichiers du moteur sont téléchargés une fois — l’indicateur affiche Pyodide, puis SQLGlot — et chaque analyse se fait ensuite dans la page. Rien n’est envoyé à un serveur pour l’analyse et aucune base de données n’est contactée.

Le résultat se compose d’un graphe et d’un inspecteur. Le mode Colonnes suit les valeurs des colonnes source à travers les expressions jusqu’à chaque sortie ; le mode Tables réduit le graphe aux dépendances entre tables et vues ; le mode Jointures ne garde que les relations ON. En dessous, la carte Couverture de l’analyse indique pour chaque instruction si elle est résolue, partielle, non prise en charge ou en erreur, et la carte Avertissements nomme ce qui n’a pas pu être résolu.

Saisissez ou collez les instructions, ou cliquez sur Charger l’exemple. L’onglet Schéma reçoit les définitions CREATE TABLE : ce sont elles qui permettent d’étendre SELECT * et de qualifier les colonnes ambiguës.

Laissez le dialecte sur Détecter automatiquement ou choisissez l’un des 23. La détection lit les marqueurs propres au moteur dans le texte ; s’ils sont trop rares, la page demande de choisir plutôt que de deviner.

Cliquez sur Analyser le lignage. La couverture et le graphe apparaissent ensemble ; Annuler arrête une analyse en cours et le moteur est rechargé pour la fois suivante.

Explorez : recherchez une table, une vue ou une colonne, filtrez le voisinage du nœud sélectionné avec Amont/Aval et activez Contexte pour ajouter les dépendances utilisées mais non transmises, comme les clés de filtre et de regroupement. Cliquez sur un nœud pour voir son fragment SQL et son expression ; la carte Impact en aval compte les colonnes, vues et résultats finaux qu’une modification atteindrait.

Exportez en JSON, CSV, PNG, SVG ou GraphML. Tous les fichiers sont produits localement dans le navigateur ; le CSV contient une ligne par lien avec source, cible, relation, instruction, fichier et expression.

Ce que l’analyseur résout, et ce qu’il laisse de côté

Lire le graphe

Un lien direct signifie que la cible provient telle quelle de la source, par référence simple ou alias. Un nœud de transformation apparaît lorsque la valeur est calculée : agrégée, convertie, concaténée ou enveloppée dans une fonction, et le panneau Détails montre l’expression correspondante. Le nombre de nœuds et de liens de la vue courante est affiché au-dessus du canevas, et le zoom, l’ajustement, la mini-carte et le plein écran agissent sur le graphe dessiné.

Contexte ajoute les dépendances utilisées sans être transmises : colonnes de filtres WHERE, clés de jointure, clés de regroupement. Activé, le graphe s’élargit visiblement ; c’est pourquoi il est séparé des boutons de filtre du lignage.

Dialectes et détection

La liste va d’ANSI / SQL générique à PostgreSQL, MySQL, SQL Server / T-SQL, Oracle, SQLite, Teradata, Snowflake, BigQuery, Amazon Redshift, Databricks SQL, Microsoft Fabric, DuckDB, ClickHouse, Materialize, Apache Doris, Dremio, Spark SQL, Hive, Trino, Presto et Amazon Athena. L’analyseur suit le choix : caractères d’identifiants entre guillemets, LIMIT / TOP / FETCH FIRST ou syntaxe MERGE expliquent le plus souvent qu’un même texte passe dans un dialecte et échoue dans un autre.

La détection s’appuie sur des preuves. Un en-tête de dump MySQL, ENGINE=InnoDB, un backtick ou AUTO_INCREMENT, des conversions ::, COPY … FROM stdin, GO ou [dbo]., VARCHAR2 et TABLESPACE, PRAGMA, TIMESTAMP_NTZ et d’autres marqueurs votent chacun pour un dialecte. Un SELECT sans syntaxe propriétaire n’apporte aucune preuve : la page demande alors de choisir au lieu de deviner, et le bouton Exemple charge un échantillon écrit pour le dialecte retenu, comme QUALIFY pour BigQuery et Snowflake, MERGE pour Databricks ou NVL pour Oracle.

Couverture, avertissements et limites

La couverture est indiquée par instruction — résolue, partielle, non prise en charge ou erreur d’analyse — avec une confiance élevée, moyenne ou faible : un long script montre ainsi ce que le moteur a compris. Les avertissements pointent la cause précise : SELECT * sans schéma correspondant, colonne présente dans deux tables jointes, SQL dynamique ou instruction encore partiellement prise en charge.

Tout ici est de l’analyse statique : le SQL dynamique et les procédures stockées ne sont suivis que dans la limite de leur texte, aucune instruction n’est exécutée, et le détail du résultat dépend du schéma fourni. Les chargements acceptent des fichiers texte .sql, l’import de projet accepte un dossier ou un ZIP / projet dbt jusqu’à 25 Mo compressés et 50 Mo décompressés, et l’entrée totale est limitée à 50 Mo — un avis apparaît au-delà de 5 Mo. Le moteur représente plusieurs mégaoctets de WebAssembly : la première analyse à cache froid est nettement plus longue que les suivantes.