Integrierte Datenqualität
Architektur, Mechanismen und Konfiguration

In der omniSuite ist Datenqualität ein strukturell integrierter Bestandteil aller Lösungsbausteine. Qualitätsregeln greifen bereits beim Entwurf und bei der Verarbeitung von Daten durch Validierungen, Steuerungslogiken und Regelmechanismen. Daten bleiben über ihren gesamten Lebenszyklus hinweg konsistent, plausibel und nachvollziehbar. Der entscheidende Unterschied: Qualität wird nicht gemessen und dann korrigiert, sondern architektonisch erzwungen.

Das CST-Prinzip beschreibt die drei Koordinaten Context, State (Zustand) und Time (Zeit), in denen jede Regel geprüft wird. Datenqualität ist somit kein statisches Momentfoto, sondern ein stetig aktualisiertes Urteil: Ein Wert kann im Status „Entwurf“ gültig sein, im Status „Freigabe“ jedoch aufgrund zeitlicher Fristen oder des Benutzerkontextes als unzureichend blockiert werden. Jede Validierung bezieht den aktuellen Zustand des Objekts, den fachlichen Kontext und den Zeitpunkt mit ein — was statische Regelwerke prinzipbedingt nicht leisten.

Klassische Systeme arbeiten oft mit isolierten Wenn-Dann-Regeln. omniSuite hingegen nutzt adaptive, zustands- und kontextbasierte Logik, die vollständig in die Systemarchitektur eingebettet ist. Entscheidungen werden situativ aus dem konkreten Datenkontext abgeleitet, wobei interne und externe Datenquellen einbezogen werden. Die Regeln sind nicht in einer separaten Engine gekapselt, sondern wirken direkt in Masken, Prozessen und Schnittstellen.

Pre-Gates sind systemische Kontrollpunkte, die vor dem Speichern, einem Statuswechsel oder der Persistenz von Importen greifen. Sie prüfen Pflichtfelder, Formate, Wertebereiche und referenzielle Integritäten.

Erfüllt ein Datensatz die Kriterien nicht, wird die Aktion aktiv blockiert und das System liefert eine verständliche Begründung (Trace) für den Nutzer. Pre-Gates sind keine optionalen Validierungen — sie sind architektonische Kontrollpunkte, die im gesamten System einheitlich wirken: in der Oberfläche, beim Import und bei API-Zugriffen.

Die ACE dient der kontext- und beziehungsabhängigen Ableitung und Kaskadierung von Zuständen und Werten über Objektgrenzen hinweg. Ändert sich ein führendes Objekt, bewertet die Engine automatisch die Auswirkungen auf alle verknüpften Strukturen und stellt sicher, dass die gesamte Datenstruktur über komplexe Abhängigkeiten hinweg integer bleibt.

Die ACE bietet vier Steuerungsoptionen für Entwickler:

• Automatische Ableitung: Die Ableitung wird standardmäßig bei jeder Änderung eines verknüpften Objekts neu berechnet. Konsistenz bleibt ohne manuellen Eingriff gewährleistet.
• Selektive Steuerung: Bestimmte Änderungen verknüpfter Objekte können von der automatischen Ableitung ausgeschlossen werden. Trigger für einzelne abhängige Objekte lassen sich gezielt deaktivieren — relevant bei komplexen Strukturen mit häufigen Aktualisierungen.
• Bedingungsabhängige Steuerung: Über eine SQL-API können Entwickler spezifische Regeln erstellen, die festlegen, wann eine Ableitung durchgeführt werden darf — abhängig von Benutzerrolle, Kontext oder Nutzeraktionen.
• Skriptbasierte Steuerung: Die automatische Ausführung wird komplett deaktiviert. Stattdessen werden Ableitungen explizit über SQL-Skripte mit definierten Korrelationswerten ausgelöst. Dies ermöglicht maximale Kontrolle über den Zeitpunkt und die Bedingungen der Ableitung.

Die Konfiguration erfolgt über einen geführten Assistenten, der einfache und mehrschichtige Abhängigkeiten unterstützt. Ableitungsregeln werden automatisch als gespeicherte Prozeduren generiert, Trigger für abhängige Objekte automatisch erstellt, und die gesamte Konfiguration ist sofort testbar und als HTML oder CSV exportierbar.

Die omniSuite verwaltet Fremdschlüsselbeziehungen (1:n, 1:1) und stellt automatisch sicher, dass nur auf gültige übergeordnete Einträge referenziert wird. Besonders leistungsfähig sind Multifremdschlüssel, die flexibel auf verschiedene Zieltabellen (z.

B. Mitarbeiter oder Abteilungen) verweisen können und dennoch systemisch auf ihre Gültigkeit validiert werden. Die Integritätsprüfung greift konsistent über alle Zugangswege — Oberfläche, Import und API.

Die regelbasierte Steuerung auf Datenebene ist ein eigenständiger Plattform-Baustein, der Administratoren und Power-Usern ermöglicht, ohne Programmierkenntnisse zentrale Regeln für Datentabellen festzulegen. Diese Regeln bestimmen, unter welchen Bedingungen Felder bearbeitbar oder speicherbar sind, und werden automatisch aktiviert, sobald eine Maske geladen wird, die mit der betroffenen Tabelle verbunden ist.

Die Steuerung basiert auf drei Kriterientypen:

• Festvorgegebene Werte: Felder werden nur editierbar, wenn ein anderes Feld einen bestimmten Wert enthält. Beispiel: Das Feld „Bestellstatus“ ist nur bearbeitbar, wenn „Genehmigungsstatus“ den Wert „Genehmigt“ trägt.
• Werte von Auswahlfeldern: Die Bearbeitbarkeit wird durch die vom Benutzer getroffene Auswahl in Dropdown-Feldern gesteuert. Beispiel: „Verkaufschance“ wird deaktiviert, wenn „Kundenstatus“ auf „Inaktiv“ steht.
• Ausprägungen angebundener 1:N-Tabellen: Regeln können an konkrete Datensätze in verknüpften Tabellen geknüpft werden. Beispiel: „Dienstwagenmodell“ ist nur editierbar, wenn der Mitarbeiter die Rolle „Außendienst“ hat.

Die Regeln gelten maskenübergreifend: Unabhängig davon, welche Oberfläche genutzt wird, werden die definierten Bedingungen eingehalten. Das verhindert potenzielle Fehler durch manuelle Eingriffe und stellt konsistente Datenqualität sicher.

Data Reconciliation identifiziert, analysiert und behebt systematisch Abweichungen zwischen Ist- und Soll-Datenbeständen, auch in mehrschichtigen Systemlandschaften. Abweichungen werden klassifiziert und können als fachliche Steuergröße genutzt werden, um fehlerhafte Folgeschritte im Prozess automatisch zu blockieren.

Die omniSuite kennt drei Abgleichsarten:

• Einzelabgleich: Isolierter Vergleich eines spezifischen Informationsobjekts zwischen Ist- und Soll-Tabelle. Entwickler definieren Regeln zur Einschränkung der abzugleichenden Daten. Die Synchronisierung erfolgt gezielt über das Ist/Soll-Abgleichcockpit — von Ist nach Soll oder umgekehrt, mit Optionen für einzelne, mehrere oder alle Abweichungen. Konfigurierbare Aktionspunkte legen fest, wie mit Abweichungen umzugehen ist, inklusive regelbasierter PostSQL-Aktionen und dynamischer URL-Verlinkungen.
• Eingebundener Abgleich: Erweitert den Einzelabgleich um verknüpfte Informationsobjekte. Fremdschlüssel- und Many-to-Many-Beziehungen werden automatisch einbezogen. Die Synchronisierung erfolgt kaskadierend und hierarchisch entlang der Parent-Child-Struktur. Bei Many-to-Many-Beziehungen werden Zwischentabellen und Child-Objekte separat geprüft und synchronisiert.
• Gestaffelter Abgleich: Mehrere Einzelabgleiche werden in einer definierten Reihenfolge ausgeführt. Die Steuerung erfolgt über SQL-Skripte mit Rückgabewerten (-1 für „nicht erfolgreich“, -2 für „erfolgreich unabhängig vom Ergebnis“). Unterstützt werden hierarchische, regelbasierte, ereignisbasierte, prozessgesteuerte und genehmigungsbasierte Synchronisierungen sowie deren Kombination.

Alle Abgleichsarten können regelbasiert und ereignisorientiert, aus Anwendungen und Prozessen, über eigene Menüpunkte oder zeitgesteuertaufgerufen werden. Die Ergebnisse werden im Ist/Soll-Abgleichcockpit visualisiert und analysiert.

Der Data Integration Manager nutzt dieselben Pre-Gates und Validierungsregeln wie die Benutzeroberfläche. Er bietet darüber hinaus eine mehrstufige Qualitätssicherung:

PreSQL-Validierung: Vor dem eigentlichen Import werden die Datensätze der Datenquelle geprüft, ob sie definierten Regeln und Standards entsprechen. Bei Fehlern kann der Import gezielt abgebrochen werden — fehlerhafte Datensätze werden in eine Fehlerdatei ausgelagert. Zusätzlich können PreSQL-Ist/Soll-Abgleiche ausgeführt werden, die die Konsistenz der Datenquelle im Vorfeld überprüfen.

Data Cleansing und Konsolidierung: Auf Datenquellenebene stehen drei Filtering-Varianten bereit (je Zeile einfach, je Zeile SQL-Batch, gesamte Datenquelle SQL-Batch). Die Konsolidierung ermöglicht die Bereinigung und Standardisierung von Schreibweisen — etwa die Vereinheitlichung von „München“, „Munchen“ und „Muenchen“ — und die Zusammenführung redundanter Datensätze vor dem Import.

Automatische Integrationstests: Bei der Zusammenführung von Datenquellen und Zieltabellen prüft das System automatisch das Vorhandensein von Identifizierungsspalten, die Konsistenz der Fremdschlüsselbeziehungen und die korrekte Zuordnung der Schlüsselfelder. Der Import wird nur gestartet, wenn alle Tests ohne Fehler bestanden sind.

Transformationsregeln auf Feldebene: Für jede Zieltabelle können Pre-Aktionen (Leerzeichen entfernen, Groß-/Kleinschreibung), Standardwerte, Ignorier-Regeln und SQL-basierte Transformationen definiert werden — universell auf Tabellenebene oder selektiv auf Datensatzebene.

ValidateBeforeInsert und ValidateBeforeUpdate: Validierungsregeln, die vor dem Einfügen oder Aktualisieren greifen und ungültige Datensätze blockieren, bevor sie die Zieltabelle erreichen.

Durch das Zusammenspiel von State-Tracking (Zustandsverlauf) und Historisierungs-Policies (Feldänderungen) wird jede Modifikation lückenlos mit Zeitstempel und Benutzerkontext erfasst. Es wird nicht nur gespeichert, was geändert wurde, sondern auch, auf Basis welcher Regel und in welchem Kontext eine Entscheidung gefallen ist. Alle Anpassungen an Regelwerken, Import-Schemata, Abgleichsdefinitionen und Ableitungsregeln werden zusätzlich in einer Änderungsdokumentation festgehalten, die Versionskontrolle und Rückverfolgbarkeit für das Entwicklerteam sicherstellt.

Der DIDC transformiert das Deployment in einen kontrollierten, validierten Prozess. Vor der Bereitstellung erfolgt eine systemweite Validierung aller Abhängigkeiten: Trigger, Skripte, APIs und Tabellenstrukturen werden auf Konsistenz geprüft, um unkontrollierte Seiteneffekte in produktiven Systemen zu verhindern.

Ergänzt wird der DIDC durch die Systemintegrität on Demand — flexible Echtzeit-Validierungen und kontinuierliche Fehlerprävention während des Betriebs. Gemeinsam stellen beide Komponenten sicher, dass fehlerhafte Änderungen gar nicht erst ins System gelangen und bestehende Prozesse kontinuierlich auf Integrität geprüft werden.

In der omniSuite werden nicht nur Daten, sondern auch die Erweiterungen (Code/Skripte) abgesichert. Dies geschieht durch dezentrale Prüfungen auf Skript- und Objektebene sowie automatisierte Integritätschecks im Hintergrund, die Fehlerquellen frühzeitig erkennen. Die Prüfungen umfassen sowohl die syntaktische Korrektheit als auch die strukturellen Abhängigkeiten zwischen Objekten — ein Regelwerk, das auf eine gelöschte Tabellenspalte verweist, wird erkannt, bevor es produktiv wird.

Die Plattform bietet spezialisierte Wizards, um fehleranfällige manuelle Aufgaben zu automatisieren:

SQL-Abfrage-Wizard: Navigiert dynamisch durch Tabellenbeziehungen, ermöglicht die Integration von Datenbankschema-Modellen über den Visual Database Designer, und generiert korrekte Join-Logiken. Generierte Abfragen können direkt im Wizard getestet und in den SQL-Editor übernommen werden.

Bedingungskonfigurator: Ermöglicht die intuitive Erstellung komplexer Filterbedingungen ohne Syntaxfehler — einsetzbar bei Data Reconciliation, Import-Filterung und Regelwerken.

Beziehungspflege-Wizard: Hilft beim regelbasierten Auflösen oder Umhängen von Beziehungen (z. B. Fremdschlüssel auf 0 setzen oder Löschkaskaden).

Attributzuweisungs-Wizard: Automatisiert das konsistente Setzen von Standardwerten oder Nullwerten.

Beziehungs-Navigator: Ermittelt automatisch direkte und indirekte Verknüpfungen zwischen Informationsobjekten, Views und Materialized Views und stellt den vollständigen Navigationspfad sichtbar dar.

Zusätzlich stehen SQL-Code-Pattern als vorgefertigte Vorlagen bereit, die über den „Assistent“-Button direkt in Skripte integriert werden können. Benutzerdefinierte Funktionen lassen sich erstellen oder aus einem Script-Repository einbinden.