Ein Dataset verbindet Quelle und Herkunft der Abfrage mit SQL, Spaltenbeschreibungen, fachlicher Bedeutung, Bearbeitungsstatus und unveränderlichen Versionen. Eine gespeicherte Abfrage bleibt bearbeitbarer SQL-Text. Der Bericht beschreibt dagegen, welche Auswertung aus dieser Grundlage entstehen soll.
Kontrollierte Datasets
Bereiten Sie einen Datensatz einmal vor. Steuern Sie seine Definitionsänderungen.
Erstellen Sie einen wiederverwendbaren Datensatz für Analysen und Berichte. Vergleichen Sie Versionen von Abfrage und Spalten, behalten Sie den Quellenbezug und bestimmen Sie, wann ein Bericht eine geänderte Definition übernimmt.
Ä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.
Eine wiederverwendbare Datengrundlage statt nur eines gespeicherten Ergebnisses.
Ein Dataset verbindet Quelle und Herkunft der Abfrage mit SQL, Spaltenbeschreibungen, fachlicher Bedeutung, Bearbeitungsstatus und unveränderlichen Versionen. Eine gespeicherte Abfrage bleibt bearbeitbarer SQL-Text. Der Bericht beschreibt dagegen, welche Auswertung aus dieser Grundlage entstehen soll.
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.
-
Die Versionen 2 und 3 des Datasets vergleichen.
-
Geändertes SQL, Spalten und Typen bestätigen.
-
Einen Berichtsentwurf öffnen, der Dataset-Version 3 verwendet.
-
Metadaten validieren und schreibgeschütztes SQL kompilieren.
-
Preview im aktuellen Berechtigungs- und RLS-Kontext ausführen.
-
Nach der Abnahme Berichtsversion 6 mit Verknüpfung zu Dataset-Version 3 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 besprechenKurz erklärt
Was leistet dieser Teil von advanexus?
Erstellen Sie einen wiederverwendbaren Datensatz für Analysen und Berichte. Vergleichen Sie Versionen von Abfrage und Spalten, behalten Sie den Quellenbezug und bestimmen Sie, wann ein Bericht eine geänderte Definition übernimmt.
Was sollte ich vor der Nutzung prüfen?
Exakte historische Zeilen erfordern ein aufbewahrtes Ergebnisartefakt oder einen expliziten materialisierten Snapshot-Vertrag.