Traçabilité des données SAP HANA : Traçabilité des colonnes pour HANA SQL et les vues

Traçabilité des données SAP HANA Il s'agit de la carte au niveau des colonnes de la façon dont les données circulent dans votre HANA SQL : quelles tables et colonnes sources alimentent chaque vue SQL, colonne calculée et rapport en aval, et quelles jointures, filtres, conversions et fonctions transforment les données en cours de route. Gudu SQLFlow il construit automatiquement cette carte en analysant votre SQL HANA avec un analyseur de dialecte SAP HANA dédié — l'un des 39 analyseurs spécifiques à un dialecte, et non une grammaire ANSI générique — et en générant un diagramme de lignage interactif et explorable jusqu'aux colonnes individuelles.

Pourquoi les questions de traçabilité atterrissent sur HANA

HANA fonctionne rarement de manière isolée. Elle est généralement intégrée aux environnements S/4HANA et BW, aux data marts et aux couches de reporting dont dépendent les fonctions finance et audit. Lorsqu'un auditeur pose une question « Quelles sont les sources de données qui alimentent ce chiffre ? » ou un contrôleur demande « Pourquoi cet indicateur de performance clé a-t-il changé après la publication du mois dernier ? »La réponse est enfouie sous des couches de SQL : vues construites sur des vues, colonnes calculées, conversions de devises et jointures entre schémas.

Répondre à ces questions en lisant manuellement le code SQL ne s'applique pas à un grand nombre de vues. L'analyse de la lignée au niveau SQL automatise ce processus : chaque définition de vue et chaque script sont analysés une seule fois, et le graphe de dépendances (table → vue → vue → rapport, au niveau des colonnes) est disponible à la demande pour l'analyse d'impact, le débogage des causes profondes et la constitution de preuves d'audit.

Comment SQLFlow construit la traçabilité des données SAP HANA

SQLFlow est construit sur le Analyseur SQL général (GSP), un compilateur SQL commercial frontal développé depuis le milieu des années 2000 et validé à l'aide d'environ 13 600 jeux de tests SQL par dialecte. L'analyseur syntaxique SAP HANA comprend spécifiquement la syntaxe SQL de HANA — citation "SCHÉMA"."OBJET" identificateurs, fonctions et conversions HANA, formes de jointure et d'opérateurs d'ensembles HANA — plutôt que de l'approximer avec une grammaire générique.

Pour chaque instruction, GSP construit un modèle sémantique complet : chaque référence de colonne est résolue via des CTE, des sous-requêtes, des vues, et SÉLECTIONNER * L'analyseur de flux de données extrait ensuite, pour chaque colonne de sortie, les colonnes sources exactes qui l'alimentent, ainsi que les fonctions et expressions utilisées. On obtient ainsi une traçabilité détaillée au niveau des colonnes, fiable pour toute modification de schéma, et non un simple schéma au niveau des tables.

Vous pouvez alimenter SQLFlow avec du SQL HANA de trois manières : en collant directement les instructions, en important des fichiers de définitions de vues et de scripts, ou en vous connectant via JDBC et en laissant SQLFlow extraire les définitions d'objets du catalogue de la base de données. Il s'agit d'une analyse statique du texte SQL ; SQLFlow ne lit jamais les lignes de vos tables.

Exemple : traçage d’une chaîne de vues SQL HANA multicouche

Les vues SQL en couches constituent le modèle standard de HANA : une vue de nettoyage au-dessus des tables brutes, une vue d’enrichissement par-dessus, et une vue agrégée pour la génération de rapports. Voici une chaîne typique à trois couches :

CRÉER LA VUE "FIN"."V_ORDERS_CLEAN" COMME SÉLECTIONNER ORDER_ID, CUSTOMER_ID, TO_DECIMAL(GROSS_AMOUNT, 15, 2) AS GROSS_AMOUNT, IFNULL(CURRENCY, 'EUR') AS CURRENCY, ORDER_DATE DE "FIN"."ORDERS_RAW" OÙ STATUS <> 'CANCELLED'; CRÉER LA VUE "FIN"."V_ORDERS_EUR" COMME SÉLECTIONNER o.ORDER_ID, o.CUSTOMER_ID, o.GROSS_AMOUNT * r.RATE AS AMOUNT_EUR, o.ORDER_DATE DE "FIN"."V_ORDERS_CLEAN" o JOINTURE "FIN"."FX_RATES" r SUR r.CURRENCY = o.CURRENCY ET r.RATE_DATE = o.ORDER_DATE; CRÉER LA VUE "FIN"."V_REVENUE_MONTHLY" COMME SÉLECTIONNER CUSTOMER_ID, YEAR(ORDER_DATE) AS FISCAL_YEAR, MONTH(ORDER_DATE) AS FISCAL_MONTH, SUM(AMOUNT_EUR) AS REVENUE_EUR DE "FIN"."V_ORDERS_EUR" GROUPER PAR CUSTOMER_ID, YEAR(ORDER_DATE), MONTH(ORDER_DATE);

Demandez à SQLFlow où V_REVENU_MENSUEL.REVENU_EUR provient de et parcourt la chaîne automatiquement : REVENU_EUR est SOMME(MONTANT_EUR), qui est MONTANT_BRUT * TAUX, où MONTANT_BRUT est COMMANDES_BRUTE.MONTANT_BRUT passé par TO_DECIMALDeux colonnes sources, trois niveaux de vues, chaque calcul intermédiaire nommé. Exécutez la trace dans l'autre sens et vous obtenez une analyse d'impact : retype COMMANDES_BRUTE.MONTANT_BRUT et SQLFlow liste toutes les colonnes en aval qui héritent de la modification.

Colonnes calculées dans les vues SQL — TO_DECIMAL distribution, le IFNULL Par défaut, la multiplication est de première classe dans le graphe de lignage, donc le diagramme ne montre pas seulement que une colonne s'écoule à travers mais qu'advient-il de à chaque couche.

Lignée directe vs. lignée indirecte

Regardez à nouveau l'exemple. ORDERS_RAW.STATUT n'apparaît jamais dans aucune colonne de sortie, pourtant le OÙ LE STATUT N'EST PAS « ANNULÉ » Le filtre influence absolument le chiffre d'affaires. Il en va de même pour DEVISE, DATE_TARIF, et DATE_DE_COMMANDE dans les conditions de jonction et GROUPER PAR.

SQLFlow modélise ces éléments comme lignée indirecte (d'impact)Il s'agit d'un type de relation distinct du flux de données direct et activable/désactivable séparément dans le diagramme. Pour une question d'audit telle que « ce champ réglementé influence-t-il ce rapport ? », les liens indirects constituent souvent la seule réponse ; or, la plupart des outils de traçabilité concurrents ne font pas la distinction entre relations directes et indirectes.

Où SQLFlow se situe par rapport aux outils natifs SAP

Les outils de modélisation et de catalogage SAP sont performants pour leur fonction première : le suivi des artefacts créés au sein de la couche modélisée SAP. Le problème se situe au niveau SQL. Les vues SQL écrites manuellement, les scripts de migration, les instructions DML dans les tâches planifiées et le code SQL reliant HANA à la partie non-SAP de votre infrastructure sont invisibles pour la traçabilité basée sur les modèles, car ils n'ont jamais été enregistrés comme artefacts modélisés.

C’est la couche que couvre SQLFlow. Il analyse le SQL lui-même, de sorte que tout ce qui est exprimé sous forme de texte SQL est tracé, quel que soit l’outil qui l’a créé. Deux limites importantes à connaître :

• Vues de calcul graphique Ces données sont stockées sous forme de modèles XML, et non de SQL ; elles sont donc hors du champ d’application de l’analyse SQL. Les vues SQL qui les entourent, ainsi que toutes les requêtes SQL qui les interrogent, sont entièrement traçables.
• Procédures SQLScript : Les grammaires procédurales dédiées de SQLFlow couvrent actuellement Oracle PL/SQL et SQL Server T-SQL. Pour HANA, l'approche pratique consiste à analyser les instructions SQL à l'intérieur des corps SQLScript. SÉLECTIONNER, INSÉRER, et les définitions de vues où réside réellement la lignée sont des SQL HANA standard.

Utilisées conjointement, les deux approches se complètent : les outils natifs SAP pour la couche modélisée et la traçabilité au niveau SQL pour tout ce qui est écrit en SQL. Et comme SQLFlow prend en charge 39 dialectes, ce même graphe de traçabilité s’étend au-delà de HANA jusqu’aux systèmes Oracle, DB2 ou Snowflake qui l’alimentent (voir la section correspondante). Traçabilité des données Oracle et Traçabilité des données DB2 Des pages sont disponibles pour ces dialectes. Les déploiements en entreprise peuvent également exporter les résultats vers DataHub, Microsoft Purview ou OpenMetadata grâce à des adaptateurs d'exportation intégrés.

Options de déploiement pour les environnements SAP

Édition	Idéal pour	Notes
SQLFlow Cloud	Évaluation, suivi ad hoc des vues	Niveau gratuit ; niveau premium $49,99 €/mois ; collez ou importez votre requête SQL HANA dans le navigateur
SQLFlow sur site	Environnements SAP de production dans les secteurs réglementés	Docker/Kubernetes au sein de votre réseau, compatible avec l'isolation physique ; 1 TP3T500/mois ou 1 TP3T4 800 en une seule fois par type de base de données
API REST / Bibliothèque Java	Automatisation du traçage dans l'intégration continue ou une plateforme de données	Même moteur d'analyse, utilisable depuis les pipelines et les applications JVM

Pour la plupart des entreprises utilisant HANA, la protection de la vie privée est aussi importante que les fonctionnalités : SQLFlow effectue une analyse statique du code SQL et des métadonnées de schéma uniquement, et avec l’option On-Premise, le texte SQL ne quitte jamais votre réseau. L’analyse par lots gère des environnements de plus de 100 bases de données et plus d’un million de colonnes, avec des analyses incrémentielles et un référentiel de traçabilité persistant. Plus de détails sont disponibles sur le site web. page de tarificationet le Présentation de l'outil de traçabilité des données SQL couvre l'ensemble des fonctionnalités.

Foire aux questions

SQLFlow prend-il en charge SAP HANA ?

Oui. SAP HANA fait partie des 39 bases de données disposant de son propre analyseur syntaxique spécifique au dialecte dans SQLFlow, prenant en charge la syntaxe SQL HANA, y compris les identificateurs qualifiés de schéma entre guillemets, et les fonctions HANA telles que : IFNULL et TO_DECIMAL, et consulter les définitions.

SQLFlow peut-il retracer la lignée à travers des vues SQL HANA superposées ?

Oui. Les références de colonnes sont résolues via des vues, des CTE, des sous-requêtes, et SÉLECTIONNER * expansion, de sorte qu'une colonne dans une vue de rapport de niveau supérieur est suivie à travers chaque vue intermédiaire jusqu'aux colonnes sources physiques, chaque calcul étant affiché le long du chemin.

SQLFlow prend-il en charge les vues de calcul HANA ?

Les vues de calcul graphiques sont des modèles XML et non du SQL ; elles ne sont donc pas incluses dans le champ d’analyse SQL. SQLFlow trace tout ce qui est exprimé en SQL : les vues SQL qui entourent les vues de calcul, ainsi que toutes les instructions SQL qui les interrogent.

SQLFlow a-t-il besoin d'accéder aux données de mes tables HANA ?

Non. SQLFlow effectue une analyse statique du code SQL et peut lire les métadonnées du schéma via JDBC. Il ne lit jamais les données des lignes de table, et l'édition sur site conserve même le texte SQL au sein de votre réseau.

Comment puis-je importer mon SQL HANA dans SQLFlow ?

Trois méthodes : coller le code SQL directement dans le navigateur, importer les fichiers de définitions de vues et de scripts, ou se connecter à HANA via JDBC pour que SQLFlow récupère les définitions d’objets depuis le catalogue. Les résultats sont exportés aux formats JSON, CSV ou PNG, ou via l’API REST.

Combien coûte SQLFlow ?

SQLFlow Cloud est gratuit au départ ; les comptes premium coûtent 49,99 £/mois. SQLFlow On-Premise coûte 500 £/mois ou 4 800 £ (paiement unique) par type de base de données sélectionné, installable sur deux serveurs, avec des types de bases de données supplémentaires à 100 £/mois ou 1 000 £ (paiement unique) chacun.