SDLP (SQL-Datenherkunftsplattform) ist das unternehmensweite Stammbaum-System von Gudu Software. Es berechnet Datenherkunft auf Spaltenebene für eine gesamte SQL-Umgebung durch Parsen des tatsächlichen Codes der Umgebung – gespeicherte Prozeduren, Sichten, Funktionen, Trigger, Jobs – und Speichern jeder abgeleiteten Herkunftskante als revisionsfähige Tatsache in einem verwalteten Datenspeicher, zusammen mit einem vollständigen Register von allem, was es könnte nicht Das Ergebnis ist eine nachvollziehbare Abstammung, die Sie vor einer Aufsichtsbehörde verteidigen können: Fakten und Ablehnungen decken stets 100% des Nachlasses ab, nichts wird stillschweigend fallen gelassen und nichts wird erfunden.
Möchten Sie es sich ansehen, bevor Sie etwas installieren? Erkunden Sie ein Live-SDLP-Repository direkt in Ihrem Browser – den Herkunftskatalog, hash-verifizierte SQL-Beweise, Batch-Qualitätsbewertungen und das Ablehnungs-Ledger – ohne Download und ohne Anmeldung.
Wo SDLP innerhalb der SQLFlow-Familie einzuordnen ist: Es basiert auf demselben General SQL Parser-Kern wie Gudu SQLFlowSQLFlow löst jedoch ein anderes Problem. SQLFlow zeigt die Herkunft der übergebenen SQL-Anweisungen an; SDLP hingegen verwaltet die lückenlose Herkunft aller Elemente Ihres Systems. Der folgende Vergleich verdeutlicht die Unterscheidung.
SQLFlow oder SDLP – welches System benötigen Sie?
Gudu SQLFlow ist eine interaktive Abstammungslinie Analyse- und Visualisierungs-EngineSie geben SQL-Code ein – eingefügt, hochgeladen, aus einer Datenbank, einem dbt-Projekt oder dem Abfrageverlauf abgerufen, in einem von 39 Dialekten – und es erstellt innerhalb von Sekunden ein interaktives Datenherkunftsdiagramm auf Spaltenebene. Es ist das ideale Werkzeug für Dateningenieure und -analysten, die Datenflüsse verstehen, debuggen und dokumentieren müssen, und wird als Standardsoftware ausgeliefert. SQLFlow Cloud, SQLFlow vor Ort, eine REST-API und eine Java-Bibliothek.
SDLP ist eine Unternehmenslinie Plattform – ein System zur Datenerfassung. Es analysiert nicht einzelne Skripte, sondern exportiert die gesamte Datenbank (Metadaten plus SQL-Quellcode aller Module), scannt sie als nachverfolgbaren Batch und führt die Ergebnisse in einem zentralen Repository mit Herkunftsinformationen, Nachweisen, Qualitätsbewertungen, Governance-Strukturen, Zugriffskontrolle und einem manipulationssicheren Prüfpfad zusammen. Es ist das ideale Werkzeug für Data-Governance-Teams in Banken, Versicherungen und anderen regulierten Unternehmen, die … beweisen woher die Daten stammen – kontinuierlich, im gesamten Immobilienbereich, wobei etwaige Lücken berücksichtigt werden.
| Gudu SQLFlow | SDLP | |
|---|---|---|
| Was es ist | Interaktive Engine zur Abstammungsanalyse und -visualisierung | Unternehmensweites Herkunftsnachweissystem mit Governance |
| Du gibst es | SQL-Skripte, eine Datenbankverbindung, dbt-Artefakte, Abfrageverlauf | Ein komplettes SQL-System, exportiert als Metadaten- und Quellcodepaket |
| Du bekommst | Ein interaktives Stammbaumdiagramm auf Spaltenebene, exportierbar als JSON/CSV/PNG | Ein kontrolliertes Repository mit nachvollziehbaren Herkunftsdaten, ein Ausschussregister, qualitätsbewertete Scan-Batches und für Aufsichtsbehörden geeignete Exporte |
| Nicht aufgelöste SQL-Anweisungen | Bestmögliche schematische Darstellung des analysierten Dateninhalts | Im Ablehnungsbuch mit Grundcode und Beweismitteln erfasst – Fakten + Ablehnungen = 100% des Nachlasses |
| Dialektabdeckung | 39 SQL-Dialekte | Microsoft SQL Server-Umgebungen werden heute vollständig unterstützt; weitere Umgebungstypen sind in Planung und basieren auf derselben Parserfamilie. |
| Typischer Benutzer | Dateningenieure, Analysten, Architekten | Daten-Governance-Teams, Scan-Operatoren, Stewards, Auditoren |
| Governance | — | PII-Klassifizierung, Analyse der Auswirkungen sensibler Datenflüsse, Baselines, rollenbasierter Zugriff, Hash-basierter Prüfpfad |
| Am besten geeignet für | Datenflüsse während der Entwicklung verstehen und dokumentieren | Regulatorische Herkunftsnachweise (nach BCBS 239), Unternehmenskataloge, Prüfungsnachweise |
Die beiden Produkte ergänzen sich: Teams verwenden SQLFlow typischerweise während der Entwicklung, um Datenflüsse zu verstehen und zu korrigieren, und SDLP in der Produktion, um den bestätigten Herkunftsdatensatz zu pflegen, auf den sich die Organisation bei ihren Berichten bezieht.
Ehrliche Abstammung: ablehnen, nicht raten.
Die meisten Lineage-Tools scheitern bei Audits bei stille LückenWas das Werkzeug nicht verstanden hat, ist einfach nicht vorhanden, und niemand kann sagen, wie viel fehlt. Die Gründungsdoktrin der SDLP ist anders. Ablehnen, nicht raten und 100% berücksichtigenJede Aussage oder Referenz, die der Scanner nicht eindeutig auflösen kann, wird in der Fehlerliste als Zeile mit einem maschinenlesbaren Fehlercode, einer Schweregradangabe und dem zugehörigen SQL-Quellcode erfasst. Mehrdeutigkeiten werden niemals in plausibel erscheinende Ergebnisse umgewandelt, und Referenzen außerhalb des Bestands werden als extern klassifiziert, anstatt sie zu erraten. „Fakten plus Fehler gleich Gesamtbestand“ ist eine überprüfbare Gleichung, kein Slogan.
Das Datenmodell basiert auf derselben Ehrlichkeit. Jede Herkunftsangabe enthält eine Rolle das besagt Wie Die Quellspalte beeinflusst das Ziel: Werttragende Rollen (DIREKT, TRANSFORM, AGGREGIEREN, ABGELEGT) bedeuten, dass die Quelldaten tatsächlich im Ziel landen; nur beeinflussende Rollen (FILTER, VERBINDEN, BEDINGUNG) bedeuten, dass die Quellspalte das Ergebnis geformt hat, ohne dass ihr Wert jemals ankommt. Dieser Unterschied ist der Unterschied zwischen „diesem Bericht enthält Kundendaten“ und „Dieser Bericht war lediglich gefiltert nach eine PII-Spalte“ – genau das, was ein Datenschutzbeauftragter oder eine Aufsichtsbehörde benötigt, und SDLP übertreibt niemals Ersteres, wenn nur Letzteres zutrifft.
So funktioniert es
- Export. Ein einzelner, in sich geschlossener Exporter verbindet sich mit dem Quellserver über einen Lesezugriff und streamt den gesamten Bestand – Katalogmetadaten und den SQL-Text jedes Moduls – in ein Sharded Bundle. Er liest Nur Metadaten, speichert niemals Tabellendaten und läuft innerhalb Ihrer Netzwerkzone; das Bundle ist das Einzige, was diese verlässt.
- Scan. Der Scanner analysiert jedes Modul mithilfe des allgemeinen SQL-Parsers, normalisiert die Ergebnisse und fügt sie als nachverfolgbaren, fortsetzbaren Batch in das kanonische Repository ein. Ein unterbrochener Scan wird vom gespeicherten Prüfpunkt fortgesetzt, anstatt von vorn zu beginnen.
- Bestätigen. Ein unabhängiger Validator – eine bewusst separate Implementierung – berechnet den Identitätshash jeder gespeicherten Zeile neu und führt einen Regelkatalog aus, der pro Batch zu einer Qualitätswertung von 0 bis 100 verdichtet: eine Zahl, anhand derer jeder Scan beurteilt wird.
- Verbrauchen. Ein Webkatalog dient der Suche, interaktiven Herkunftsdiagrammen und Governance-Workflows; das Export Center liefert CSV-, JSONL- oder Parquet-Dateien an nachgelagerte Systeme, einschließlich einer Microsoft Purview-fähigen Herkunfts-CSV-Datei.
Jeder Schritt funktioniert über die Kommandozeile, den Browser oder eine Kombination aus beidem – alle drei Wege lesen und schreiben auf dasselbe Repository unter demselben Identitätsvertrag, sodass die Wahl einer Schnittstelle die Daten nicht verändert. Scan-Teams führen in der Regel geplante Scans über die Kommandozeile durch, Analysten und Stewards arbeiten mit der Web-Oberfläche, und Downstream-Feeds werden über die Export-API verarbeitet.
Nachweise, die Sie einem Prüfer aushändigen können
Jeder Fakt im Repository lässt sich über eine manipulationssichere Kette bis zu seinem Ursprung zurückverfolgen: Fakt → Vorkommen → bytegenauer Locator im exportierten Quellcode-Bundle, der bei jedem Lesevorgang anhand eines SHA-256-Inhaltshashs erneut verifiziert wird. SQL-Text wird nicht im Repository dupliziert; das Bundle ist das einzige Referenzsystem, sodass bearbeiteter oder abweichender Quellcode erkannt und nicht stillschweigend ausgeliefert wird. Im Webkatalog öffnet „SQL-Nachweis anzeigen“ den exakten Anweisungsabschnitt, der im ursprünglichen Modulquellcode hervorgehoben und live hash-verifiziert wird.
- Hashverketteter Prüfpfad: Jede Klassifizierung, jeder Export und jede Neuberechnung landet in einem Ereignisprotokoll, das nur angehängt werden kann und über eine Hash-Kette verfügt, sodass eine Manipulation des Protokolls selbst erkennbar ist.
- Unabhängige Überprüfung: Die Prüfer können den eigenständigen Validator gegen das Repository ausführen, ohne dem Scanner, der ihn geschrieben hat, vertrauen zu müssen – einschließlich der Neuberechnung der Identität jeder einzelnen Zeile.
- Ausgangswerte: Die Datenherkunft wird „wie am Datum X akzeptiert“ eingefroren und bestätigt. Eine Aufsichtsbehörde fragt nach der Datenherkunft des Berichts für das vierte Quartal, nicht nach dem Ergebnis des gestrigen Scans; Referenzdaten machen dies zu einem vorrangigen Prüfgegenstand.
- 100%-Buchhaltung angezeigt: Das Ablehnungsprotokoll ist ein Exportgut wie jedes andere – die vollständige Liste dessen, was nicht gelöst wurde und warum, ist Teil des Liefergegenstands, kein Geheimnis.
integrierte Governance
Datenverantwortliche klassifizieren Endpunkte – Tabellen, Ansichten, Spalten – anhand von Sensibilitätsklassen wie z. B. personenbezogenen Daten. Die Weiterleitungs-Engine berechnet dann, wohin die klassifizierten Daten nachgelagert fließen und, was entscheidend ist, Wie: Jeder Befund birgt eine ehrliche Auswirkungsart (ENTHÄLT DATEN, GEFILTERT VON, MITGEBUNDEN, BEEINFLUSST VONDie Funde werden aus den Rollen entlang der Abstammungslinie abgeleitet, wobei Eigentümer und Verwalter zugeordnet werden, sodass ein Fund auf dem Schreibtisch einer bestimmten Person landet. Jede Handlung eines Verwalters wird zugeordnet und geprüft.
Die Zugriffskontrolle basiert auf zwei unabhängigen Achsen: Sieben Rollen definieren die Benutzerrechte (Katalog lesen, Klassifizierungen verwalten, Scans durchführen, Quellen administrieren), während die Workspace-Mitgliedschaften den Zugriffsbereich festlegen. Workspaces bilden strikte Isolationsgrenzen – Daten, Exporte, Governance-Datensätze und Audit-Ereignisse werden niemals überschritten. Produktionsumgebungen verfügen über eine zusätzliche serverseitige Barriere, die die Scanberechtigungen für Produktionsumgebungen von denen für andere Umgebungen trennt. Die Identitätsprüfung kann über OIDC durch Ihren Identitätsanbieter (IdP) erfolgen.
Bereitstellung und Skalierung
SDLP lässt sich lokal unter Linux und Windows gleichermaßen bereitstellen und benötigt als einzige Softwarevoraussetzung Java. Das Lineage-Repository bietet zwei gleichwertige Backends, die über einen Konfigurationsblock ausgewählt werden: eine SQL-Server-Datenbank für gemeinsam genutzte Produktionsumgebungen oder einen integrierten Speicher ohne Installation – ein lokales Verzeichnis, kein Datenbankserver, keine Passwörter –, dessen erster Scan vom Download bis zur Lineage etwa 15 Minuten dauert. Die gesamte Infrastruktur läuft vollständig isoliert: keine Cloud-Abhängigkeit, keine ausgehende Verbindung und die Anmeldung auf Quellseite benötigt niemals Lesezugriff auf Tabellendaten.
Die Plattform ist für große Datenbankbestände ausgelegt: Ein vollständiger Scan eines Bestands von 122 Datenbanken – etwa 29.000 Analyseeinheiten, die rund 450.000 Datenherkunftsdaten auf Spaltenebene erzeugen – ist auf einem parallel betriebenen 4-Kern-Server in weniger als zwei Stunden abgeschlossen. Wiederholte Scans werden im selben kanonischen Datenspeicher zusammengeführt, sodass erneut erfasste Daten als einzelne Daten mit ihrer gesamten Historie erhalten bleiben. Inkrementelle Delta-Exporte beantworten die Frage „Was hat sich seit dem letzten Scan geändert?“, ohne dass die Dateien manuell verglichen werden müssen.
Datenübertragung an Microsoft Purview und andere nachgelagerte Systeme
Das Export Center liefert acht Exporttypen über das Repository – Herkunft auf Feldebene mit Nachweisen, Transformationslogik, Auswirkungen von Verfahren, Abdeckungslücken, inkrementelle Änderungen, Ablehnungen, Chargenqualität und eine Purview-fähige Herkunfts-CSV-Datei Die Exporte erfolgen jeweils im CSV-, JSONL- oder Parquet-Format. Purview exportiert Daten versioniert und ist für die Verarbeitung optimiert: eine Zeile pro aktivem Fakt, qualifizierte Namen mit Punktnotation und separaten Namensbestandteilen, die Herkunftsrolle, ein garantierter einzeiliger Transformationsausdruck und eine stabile Fakt-GUID für idempotente Upserts mit der Purview Atlas API. Große Exporte werden als asynchrone Jobs ausgeführt, die auch bei geschlossenem Browser aktiv bleiben.
Abstammungslinien, die Sie in einem Audit verteidigen können
Scannen Sie Ihre gesamte SQL-Server-Umgebung und erstellen Sie revisionssichere, hash-verifizierte Fakten mit 100%-Accounting. Der erste Scan dauert etwa 15 Minuten; ein Datenbankserver ist nicht erforderlich.
Häufig gestellte Fragen
Worin unterscheidet sich SDLP von Gudu SQLFlow?
SQLFlow ist ein interaktives Analysetool: Sie geben SQL-Anweisungen ein, und es erstellt das Datenherkunftsdiagramm auf Spaltenebene in 39 verschiedenen Dialekten. SDLP ist eine Unternehmensplattform, die auf demselben Parser basiert: Sie durchsucht regelmäßig ganze Datenbankbestände, speichert jeden Datenherkunftsabschnitt als revisionssichere Information in einem verwalteten Repository, protokolliert alle nicht auflösbaren Fälle in einem Fehlerprotokoll und ergänzt diese um Klassifizierung, Analyse sensibler Datenflüsse, rollenbasierte Zugriffskontrolle, Baselines und einen Hash-basierten Audit-Trail. Nutzen Sie SQLFlow, um Datenflüsse zu verstehen; nutzen Sie SDLP, um die Datenherkunft zu pflegen, die Ihr Unternehmen dokumentiert.
Welche Datenbanken werden von SDLP unterstützt?
SDLP unterstützt Microsoft SQL Server-Umgebungen bereits vollständig – vom Export über den Scanner bis hin zum Repository. Weitere Umgebungstypen sind in Planung und übernehmen die Dialektunterstützung derselben allgemeinen SQL-Parser-Familie, die auch die 39 Dialekte von SQLFlow unterstützt. Zudem kann SDLP Verzeichnisse mit SQL-Dateien direkt scannen.
Kann SDLP meine Daten lesen?
Nein. SDLP arbeitet mit statischer SQL-Codeanalyse. Der Exporter liest Katalogmetadaten und Modulquelltext mit einem schreibgeschützten Login, der keinen Zugriff auf Tabellenzeilen benötigt. Der Scanner arbeitet ausschließlich mit diesem exportierten Paket. Es gibt keinen Codepfad, der Geschäftsdaten liest.
Kann SDLP in einer abgeschotteten Umgebung ausgeführt werden?
Ja. SDLP ist eine On-Premise-Software ohne Cloud-Abhängigkeit und ohne ausgehende Verbindungen. Dank des integrierten Repository-Backends benötigt sie lediglich Java und ein lokales Verzeichnis, wodurch sie sich auch für Jump-Hosts und isolierte Scan-Maschinen eignet.
Was macht die Herkunftsnachverfolgung von SDLP prüfungsfähig?
Drei Funktionen arbeiten zusammen: 100%-Buchhaltung (Fakten plus ein begründetes Ablehnungsregister decken den gesamten Bestand ab), eine manipulationssichere Beweiskette (jeder Fakt lässt sich auf einen hash-verifizierten Abschnitt der ursprünglichen SQL-Anweisung zurückführen) und unabhängige Verifizierung (ein separates Validierungstool berechnet die Identität jeder gespeicherten Zeile neu, ohne dem Scanner zu vertrauen). Ein Prüfer kann von jeder Zahl in einem Bericht bis zur exakten SQL-Anweisung zurückverfolgen, die sie erzeugt hat – live.
Siehe SDLP auf Ihrem eigenen Grundstück
Ein sofort einsatzbereites Evaluierungspaket mit einem 15-minütigen Schnellstart – für den ersten Scan ist kein Datenbankserver erforderlich.