1
Überblick
Die Versionierung ermöglicht es, Änderungen an bestimmten Feldern eines Datenobjekts zeitlich nachzuverfolgen. Jede Änderung wird mit einem Gültigkeitszeitraum (Gültig ab / Gültig bis) in einer separaten History-Tabelle gespeichert. Die Haupttabelle zeigt über ein TemporalValue-Enrichment immer den aktuell gültigen Wert an.
Typische Einsatzgebiete: Preisänderungen, Tarifumstellungen, Gehaltsanpassungen, Vertragslaufzeiten, Stundensatz-Historien — überall dort, wo Werte sich über die Zeit ändern und die Historie wichtig ist.
2
Architektur
Die Versionierung arbeitet mit zwei Tabellen:
| Tabelle | Inhalt | Beispiel |
|---|---|---|
| Haupttabelle | Das bestehende Datenobjekt. Die versionierten Felder werden als virtuell markiert und lesen ihren Wert aus der History-Tabelle. | Teile (Id, Bezeichnung, Anzahl*, EK*, Gewicht*) |
| History-Tabelle | Automatisch erstellt. Enthält die versionierten Feldwerte mit Gültigkeitszeitraum. | Teile_Historie (Id, Teile_Id, Anzahl, EK, Gewicht, GültigAb, GültigBis) |
* = virtuelles Feld — liest den Wert aus der History-Tabelle statt aus der eigenen DB-Spalte.
3
Versionierungs-Assistent (Wizard)
Der Versionierungs-Assistent führt Sie in 4 Schritten durch die Einrichtung:
Schritt 1 — Datenobjekt & Felder wählen
- Wählen Sie das Datenobjekt, für das die Versionierung eingerichtet werden soll.
- Wählen Sie die Felder, die versioniert werden sollen (z. B. Preis, Stundensatz, Menge).
- Legen Sie die Namen für die Zeitfelder fest (Standard: „GültigAb“ / „GültigBis“).
Schritt 2 — Optionen
- Name der History-Tabelle (Standard: {Entity}_Historie)
- Stichtag für Altdaten-Übernahme — Dieses Datum wird als GültigAb für die initialen History-Datensätze verwendet (Standard: heute).
- Berechnete Felder erstellen — Automatisch TemporalValue-Enrichments für alle versionierten Felder einrichten.
Schritt 3 — Zusammenfassung & Prüfung
- Automatische RawSQL-Prüfung: Der Assistent durchsucht alle Datenquellen, die die versionierten Felder referenzieren, und warnt bei möglichen Kompatibilitätsproblemen.
- Übersicht aller geplanten Aktionen (Entity erstellen, Daten migrieren, Enrichments konfigurieren, Felder umstellen).
Schritt 4 — Ausführung
Die Einrichtung erfolgt automatisch in zwei Phasen:
| Phase | Aktionen |
|---|---|
| Phase A History aufbauen |
1. History-Entity mit allen Feldern erstellen 2. Bestehende Daten als initiale History-Einträge migrieren 3. TemporalValue-Enrichments auf allen Datenquellen konfigurieren |
| Phase B Quell-Felder umstellen |
4. Versionierte Felder auf virtuell umstellen 5. Metadaten aktualisieren |
Sicherheit: Bei einem Fehler in Phase A oder B wird alles rückgängig gemacht (kompletter Rollback). Es gehen keine Daten verloren.
UserClient → Versionsverlauf einer Entitaet
| Gueltig ab | Gueltig bis | Autor | Aktion | Status |
|---|---|---|---|---|
| 01.01.2026 | — | Mueller | Tarif erhoeht (+3%) | aktiv |
| 01.07.2025 | 31.12.2025 | Schmidt | Anpassung Sonderzulage | historisch |
| 01.01.2025 | 30.06.2025 | Mueller | Tariferstellung | historisch |
| 15.04.2024 | 31.12.2024 | Weber | Initialwert | archiviert |
4
TemporalValue-Aggregationstyp
Der TemporalValue-Aggregationstyp ist ein spezielles berechnetes Feld, das automatisch den zum Stichtag gültigen Wert aus der Versionshistorie ermittelt.
So funktioniert es
- Das System sucht in der History-Tabelle den Eintrag, dessen Gültigkeitszeitraum den aktuellen Stichtag einschließt.
- Bei mehreren gültigen Einträgen wird der aktuellste verwendet (nach GültigAb absteigend).
- Die Abfrage ist optimiert (ROW_NUMBER-basiert) und wird in Batches von 500 Keys ausgeführt.
Konfiguration
TemporalValue-Enrichments werden automatisch durch den Versionierungs-Assistenten erstellt. Sie können aber auch manuell konfiguriert werden:
| Feld | Beschreibung |
|---|---|
| Aggregationstyp | TemporalValue |
| Quell-Entity | Die History-Tabelle (z. B. Teile_Historie) |
| Wert-Feld | Das Feld, dessen Wert abgerufen wird (z. B. Preis) |
| Verknüpfungsfeld | Das FK-Feld, das auf die Haupttabelle zeigt (z. B. Teile_Id) |
| ValidFrom-Feld | Das GültigAb-Feld in der History-Tabelle |
| ValidTo-Feld | Das GültigBis-Feld in der History-Tabelle |
AdminClient → TemporalValue-Aggregationsfeld konfigurieren
Berechnetes Feld „Preis_zum_Stichtag“
Aggregationstyp
TemporalValue
Quell-Entity
Teile_Historie
Wert-Feld
Preis
FK-Verknüpfung
Teile_Id → Teile.Id
Gueltig-Ab
GueltigAb
Gueltig-Bis
GueltigBis
Stichtagsparameter
@Stichtag (Default: heute)
5
Nach der Einrichtung
Nach erfolgreicher Versionierung können Sie optional:
- History-Datensätze bearbeiten — Über die History-Tabelle können Einträge manuell angepasst, neue Versionen angelegt oder bestehende Einträge mit einem GültigBis-Datum versehen werden.
- Originale DB-Spalten leeren — Die versionierten Spalten in der Haupttabelle können gelöscht werden (die Werte kommen jetzt aus der History).
- Versionierung rückgängig machen — Enrichments deaktivieren und virtuelle Felder zurücksetzen.
6
Häufige Fragen
| Frage | Antwort |
|---|---|
| Was passiert mit bestehenden Daten? | Alle bestehenden Datensätze werden automatisch als initiale History-Einträge übernommen. Der Stichtag für die Übernahme wird im Wizard festgelegt. |
| Kann ich Felder nachträglich zur Versionierung hinzufügen? | Ja, indem Sie die History-Tabelle um das neue Feld erweitern und ein zusätzliches TemporalValue-Enrichment konfigurieren. |
| Wie erstelle ich neue Versionen? | Erstellen Sie einen neuen Datensatz in der History-Tabelle mit dem gewünschten GültigAb-Datum. Der vorherige Eintrag sollte ein GültigBis-Datum erhalten. |
| Funktioniert die Versionierung mit RawSQL-Datenquellen? | Der Wizard prüft automatisch, ob RawSQL-Datenquellen betroffen sind, und warnt bei Kompatibilitätsproblemen. RawSQL-Abfragen müssen ggf. manuell angepasst werden. |
| Kann ich historische Werte abfragen? | Ja — über die History-Tabelle können alle früheren Versionen eingesehen werden. Das TemporalValue-Enrichment zeigt immer den zum Stichtag gültigen Wert. |