Bewahrt Dataset v3 die vom Report benötigten Spalten, Typen, Granularität und Source-Bedeutung – oder soll Report v5 an Dataset v2 gebunden bleiben, bis der analytische Vertrag neu gestaltet ist?
Operativer Leitfaden · Versionsentwicklung
Entwickeln Sie Dataset und Report weiter, ohne ihre Historie umzuschreiben.
Nutzen Sie diesen Workflow, wenn sich Dataset-eigenes SQL, Source-Lineage, Schema, Spalten oder Spaltenmetadaten ändern und ein bestehender Report entscheiden muss, ob er den neuen Vertrag akzeptiert.
Dataset, DatasetVersion und DatasetColumn tragen den grundlegenden Datenvertrag. ReportVersion trägt die analytische Absicht und exakte DatasetVersion-Bindings. AnalyticsRun erfasst eine Ausführung unter aktueller Governance.
Eine neue DatasetVersion verschiebt niemals eigenständig eine bestehende ReportVersion.
Eine abgelehnte Kandidatin lässt die bisherige produktionsnahe Reportversion und ihre historischen Run-Bindings unverändert.
Versionsvergleich, akzeptierte DatasetVersion-Identität, unveränderliches ReportVersion-Binding, Kompilierungs-/Konfigurations-/Filter-/RLS-Hashes und späterer AnalyticsRun bilden die erfasste Kette für die unterstützte Änderung.
Entscheidungsfrage
Bewahrt Dataset v3 die vom Report benötigten Spalten, Typen, Granularität und Source-Bedeutung – oder soll Report v5 an Dataset v2 gebunden bleiben, bis der analytische Vertrag neu gestaltet ist?
Verwendete Objekte und Kontrollen
Dataset, DatasetVersion und DatasetColumn tragen den grundlegenden Datenvertrag. ReportVersion trägt die analytische Absicht und exakte DatasetVersion-Bindings. AnalyticsRun erfasst eine Ausführung unter aktueller Governance.
Dataset-Lifecycle und unveränderliche DatasetVersion-Identität
Normalisiertes SQL, Source-Lineage, Spalten, Typen und bekannte Profilmetadaten
Report-Dimensionen, Metriken, Diagramm, persistente Filter und exakte Bindings
Serverseitige Kompilierung sowie Berechtigungs-, RLS- und Preview-Kontext
Abnahmeablauf
Eine neue DatasetVersion verschiebt niemals eigenständig eine bestehende ReportVersion.
-
Neue DatasetVersion erstellen
Speichern Sie den geänderten Dataset-eigenen SQL-/Schema-/Spaltenvertrag unter Bewahrung der stabilen Dataset-Identität und aller früheren Versionen.
-
Exakte Versionen vergleichen
Prüfen Sie normalisierten SQL-Diff, Source-Lineage, hinzugefügte, entfernte oder geänderte Spalten, Typen, Nullable-Status und nicht verfügbare historische Metadaten.
-
Analytische Kompatibilität bewerten
Bestätigen Sie beabsichtigte Granularität, Dimensionen und die von jeder Metrik benötigten Source-Felder; leiten Sie Kompatibilität nicht allein aus übereinstimmenden Namen ab.
-
Neuen Reportentwurf öffnen
Bewahren Sie die vorherige ReportVersion unveränderlich und binden Sie den Entwurf an die DatasetVersion-Kandidatin.
-
Validieren und kompilieren
Lösen Sie Metadaten auf, validieren Sie Query Context und kompilieren Sie serverseitiges schreibgeschütztes SQL für den aktuell unterstützten Dialektpfad.
-
Preview unter Governance
Führen Sie eine begrenzte Preview mit aktuellem Berechtigungs- und RLS-Scope aus und prüfen Sie Diagnosen, statt nur die Schemavalidierung zu akzeptieren.
-
Akzeptierte ReportVersion speichern
Persistieren Sie das neue Binding erst nach der Abnahme; nachfolgende AnalyticsRuns verweisen auf genau dieses ReportVersion-/DatasetVersion-Paar.
Fehler- und partielle Pfade
Eine abgelehnte Kandidatin lässt die bisherige produktionsnahe Reportversion und ihre historischen Run-Bindings unverändert.
Entferntes oder geändertes Feld
Kompilierung oder semantische Validierung blockiert den Entwurf; gestalten Sie Dimension oder Metrik neu, statt die alte ReportVersion zu ändern.
Preview weicht unerwartet ab
Behandeln Sie Drift aktueller Zeilen, Source-Änderung, Filter-/RLS-Scope und Vertragsänderung als getrennte Hypothesen; eine virtuelle DatasetVersion ist kein Zeilen-Snapshot.
Multi-Binding ist partiell
Prüfen Sie jede Binding-Diagnose und bewahren Sie den partiellen Status; bestätigen Sie den Report nicht allein anhand des erfolgreichen Bindings.
Erzeugte Nachweise
Versionsvergleich, akzeptierte DatasetVersion-Identität, unveränderliches ReportVersion-Binding, Kompilierungs-/Konfigurations-/Filter-/RLS-Hashes und späterer AnalyticsRun bilden die erfasste Kette für die unterstützte Änderung.
Report v4 → Dataset v2 · Report v5 → Dataset v2 · Report v6 → Dataset v3
Aktuelle Grenze
Der Vergleich umfasst erfasstes SQL, Schema, Spalten, Metadaten und Lineage; er erfindet keine universelle geschäftliche Downstream-Auswirkung. Analytics-Metriken, RLS und Reportberechtigungen bleiben außerhalb des grundlegenden Dataset-Aggregats, und exakte historische Zeilen erfordern ein Artefakt oder einen expliziten materialisierten Snapshot-Vertrag.
Nächster Schritt
Prüfen Sie die Versionsgrenzen im Produktmodell.
Dataset verantwortet den Datenvertrag; Analytics verantwortet Reportabsicht, Metriken, RLS und Ausführung.
Kontrollierte Datasets erkunden