Dataset verbindet Source- und Query-Lineage, normalisiertes SQL, Spalten- und semantische Metadaten, Lifecycle-Status und unveränderliche DatasetVersion-Objekte. SavedQuery bleibt editierbares SQL; Report beschreibt die analytische Absicht.
Kontrollierte Datasets
Datendefinitionen werden zu versionierten Assets mit expliziter Lineage.
Dataset trennt exploratives SQL von einem wiederverwendbaren Datenvertrag. Stabile Identität, unveränderliche Versionen und semantische Metadaten schaffen eine kontrollierte Report-Grundlage, ohne die Source-Lineage zu verbergen.
Änderungen an Dataset-eigenem SQL, Joins, Source, Schema, Spalten oder Spaltenmetadaten erzeugen eine neue DatasetVersion. Analytics-Metriken, RLS und Report-Berechtigungen bleiben getrennte Verträge. Bestehende ReportVersions bleiben gebunden, bis ein Nutzer die neue DatasetVersion validiert und eine neue ReportVersion speichert.
Speichert eine DatasetVersion einen Live-SQL-Vertrag, können spätere Runs neuere Source-Zeilen unter derselben Definition lesen. Die exakte historische Ergebnisrekonstruktion benötigt Run Hash und aufbewahrtes Artifact oder einen expliziten materialisierten Snapshot-Vertrag.
Nutzer können normalisiertes SQL, Spalten, Typen und bekannte Lineage-Metadaten vergleichen. Die Plattform behauptet keine universelle geschäftliche Downstream- Auswirkungsanalyse für Beziehungen, die nie erfasst wurden.
Dataset verantwortet das stabile Daten-Asset und seine Versionen. Analytics verantwortet Metriken, RLS, Ressourcenberechtigungen, Query Context und Report-Ausführung. Diese Trennung hält Governance-Grenzen prüfbar.
Ein Dataset ist ein Vertrag, kein umbenanntes Abfrageergebnis.
Dataset verbindet Source- und Query-Lineage, normalisiertes SQL, Spalten- und semantische Metadaten, Lifecycle-Status und unveränderliche DatasetVersion-Objekte. SavedQuery bleibt editierbares SQL; Report beschreibt die analytische Absicht.
Ein Dataset kann aus einer SQL-Console-Ausführung, einer SavedQuery, einer physischen Tabelle oder einer kontrollierten Transformation entstehen.
DatasetColumn erfasst bekannte Schema- und Profilmetadaten für die exakte Version.
Die Promotion aus SQL Console richtet das kanonische Dataset an der semantischen Analytics-Projektion aus, ohne ihre Verantwortungsgrenzen zusammenzuführen.
Version bezeichnet den exakten Vertragszustand.
Änderungen an Dataset-eigenem SQL, Joins, Source, Schema, Spalten oder Spaltenmetadaten erzeugen eine neue DatasetVersion. Analytics-Metriken, RLS und Report-Berechtigungen bleiben getrennte Verträge. Bestehende ReportVersions bleiben gebunden, bis ein Nutzer die neue DatasetVersion validiert und eine neue ReportVersion speichert.
Report v4 → Dataset v2 · Report v5 → Dataset v2 · Report v6 → Dataset v3
Eine virtuelle Version friert Datenzeilen nicht automatisch ein.
Speichert eine DatasetVersion einen Live-SQL-Vertrag, können spätere Runs neuere Source-Zeilen unter derselben Definition lesen. Die exakte historische Ergebnisrekonstruktion benötigt Run Hash und aufbewahrtes Artifact oder einen expliziten materialisierten Snapshot-Vertrag.
Der Vergleich zeigt erfasste Änderungen, keine erfundenen Auswirkungen.
Nutzer können normalisiertes SQL, Spalten, Typen und bekannte Lineage-Metadaten vergleichen. Die Plattform behauptet keine universelle geschäftliche Downstream- Auswirkungsanalyse für Beziehungen, die nie erfasst wurden.
Exakte Identität der linken und rechten Version sowie SHA-256-SQL-Vertrag
Zeilenbewusster SQL-Vergleich mit Einfügungen und Entfernungen
Änderungen an Spalten, Typen, Nullable-Status und bekannten Metadaten
Explizite Zustände für unverändert, geändert, hinzugefügt, entfernt und nicht verfügbar
Dataset und Analytics behalten getrennte Verantwortlichkeiten.
Dataset verantwortet das stabile Daten-Asset und seine Versionen. Analytics verantwortet Metriken, RLS, Ressourcenberechtigungen, Query Context und Report-Ausführung. Diese Trennung hält Governance-Grenzen prüfbar.
Weiterentwicklung ist eine explizite Abnahmeentscheidung.
Eine neue DatasetVersion verschiebt bestehende Reports nicht stillschweigend. Der Nutzer vergleicht den Vertrag, validiert Dimensionen und Metriken, prüft die erzeugte Query in der Preview und speichert anschließend eine neue ReportVersion, die an die akzeptierte DatasetVersion gebunden ist. Ältere ReportVersions und Runs behalten ihre ursprünglichen Bindings.
-
Dataset v2 mit v3 vergleichen.
-
Geändertes SQL, Spalten und Typen bestätigen.
-
Den Report-Entwurf für Dataset v3 öffnen.
-
Metadaten validieren und schreibgeschütztes SQL kompilieren.
-
Preview im aktuellen Berechtigungs- und RLS-Kontext ausführen.
-
Report v6 → Dataset v3 erst nach der Abnahme speichern.
Nächster Schritt
Beginnen Sie mit dem Datenfluss, der keine Unklarheit zulässt.
Bringen Sie die relevanten Systeme, Verantwortlichen, Regeln, Lieferverpflichtungen und Nachweisanforderungen ein.
Kritischen Datenfluss besprechen