Zum Inhalt springen
ad hoc AI Workbench

Validierung

Status: Entwurf · Spec-Kandidat: ja

Drei-Ebenen-Modell

Validierung erfolgt mehrstufig (vgl. AP-05). Eine Verletzung soll möglichst früh entdeckt, aber nie nur in einer Ebene durchgesetzt werden.

EbeneVerantwortung
UI / APIPflichtfeldprüfung, Datentypprüfung, verständliche Fehlermeldungen
Service-LayerTypkonformität, Plausibilitätsregeln, Löschregeln, Beziehungsregeln, Defaultwertlogik, Dublettenprüfung
DatenbankForeign Keys, Unique Constraints, Check Constraints, Trigger für kritische Prüfungen

Autorisierung als Vor-Bedingung

Vor jeder Validierung steht die Berechtigungsprüfung. Der Service-Layer ruft mdm.v_effective_permission (siehe Autorisierung) für (principal, action, target) auf und bricht bei deny/Default mit dem passenden HTTP-Status ab — 404 wenn der Aufrufer die Ressource nicht einmal sehen darf, 403 wenn read erlaubt ist aber die konkrete Aktion nicht. Validierungsfehler dürfen niemals Existenz/Inhalt eines Datensatzes preisgeben, für den der Aufrufer keine read-Permission hat. Detail: Autorisierung – Durchsetzung.

Was im Service-Layer geprüft wird

Pflichten:

  • Pflichtattribute auf Basis von DDM_ENTITY_TYPE_ATTRIBUTE und (für Beziehungen) DDM_RELATION_TYPE_ATTRIBUTE
  • Datentypkonvertierung (z. B. JSONB-Werte zu Zieltypen wie numeric, date, boolean)
  • Unique-Regeln für frei definierte Attribute (unique_per_type)
  • Defaultwertlogik (Anwenden von default_value, falls Wert fehlt). Beim Setzen eines Attributs auf required=true ist default_value Pflicht und ein atomarer Backfill aller existierenden Datensätze ist Bestandteil derselben Transaktion (Detail: DDM_ENTITY_TYPE_ATTRIBUTE – Required + Backfill-Pflicht).
  • Dublettenprüfung (FR-105)
  • Löschregeln auf Basis von DDM_RELATION_TYPE.delete_policy
  • Tenant-Konsistenz: DDM_ENTITY.tenant_id muss zum DDM_ENTITY_TYPE.tenant_id passen, DDM_ENTITY_RELATION.tenant_id muss zu beiden Endpunkten passen (DB-Trigger ist Sicherheitsnetz, Service liefert verständliche Fehler).
  • Audit-Log-Schreiben (in derselben Transaktion)
  • Outbox-Event-Schreiben (in derselben Transaktion, siehe Events / Webhooks)
  • Version-Snapshots in DDM_ENTITY_VERSION

Zusätzlich:

  • Konsistenz zwischen data_type und mitgegebenen Konfigurationsfeldern (Enum-Set existiert, Relation-Type-Endpunkte passen).
  • validation_rule-Auswertung (JSON-basierte Regelausdrücke, Definition offen).

money-spezifische Service-Layer-Prüfungen

Für Attribute mit data_type='money' validiert der Service vor jedem Schreibvorgang:

  1. Struktur: Wert ist JSON-Objekt mit exakt den Keys value und currency. Zusätzliche Keys → Fehler MONEY_UNKNOWN_FIELDS. Fehlt einer → MONEY_MISSING_FIELD.
  2. value: Typ string, matcht ^-?\d+(\.\d+)?$. Verstoß → MONEY_VALUE_FORMAT. Parsing auf BigDecimal/numeric darf nicht throwen.
  3. currency: Typ string, matcht ^[A-Z]{3}$. Verstoß → MONEY_CURRENCY_FORMAT.
  4. Skala: Anzahl Nachkommastellen ≤ Soll-Skala der Währung (Default: ISO-4217-Standardskala, override via validation_rule.scale). Verstoß → MONEY_VALUE_SCALE.
  5. min_value / max_value auf DDM_ENTITY_TYPE_ATTRIBUTE: nur anwendbar, wenn der gespeicherte Datensatz die gleiche currency führt wie das Vergleichs-Limit deklariert (Limit-Currency liegt in metadata.currency oder validation_rule.currency). Cross-Currency-Vergleich → MONEY_CURRENCY_MISMATCH, kein automatisches FX-Rounding (V1).
  6. Sortierung / Filterung: sortable=true und filterable=true sind erlaubt, aber Service-Layer-Sortierung gilt nur innerhalb gleicher currency. API-Responses exponieren value und currency als getrennte Felder; der Query-Layer projiziert sie als Spalten (OP-16).

Was in der Datenbank durchgesetzt wird

Pflichten:

  • Foreign Keys
  • Unique Constraints (auch partial: uq_entity_code_active, uq_entity_relation_active)
  • Check Constraints (Key-Format, JSONB-Objekt-Form, Min/Max, Enum-/Reference-Konsistenz)
  • Such- und Filterindizes (s. Indizes)
  • Relationstypprüfung per Trigger (trg_validate_entity_relation_types)
  • Volltextvektor-Pflege (trg_entity_before_write)

Fehlerbehandlung

  • Service-Layer-Validierung liefert strukturierte Fehler mit Feldzuordnung ({ field: 'attributes.industry', code: 'NOT_IN_ENUM_SET', message: ... }).
  • DB-Constraint-Verletzungen werden vom Service-Layer in fachliche Fehler übersetzt, wo möglich; rohe SQL-Fehlermeldungen gehören nicht ins API-Antwortmodell.
  • Trigger-Exceptions sind Teil derselben Transaktion und führen zu Rollback.

Offen

  • Spezifikation des validation_rule-Ausdruckschemas (Operatoren, Schemarelationen, Sichtbarkeit zwischen Attributen).
  • Internationalisierung der Fehlermeldungen.
  • Behandlung historischer Datensätze bei Schemaänderung von DDM_ENTITY_TYPE_ATTRIBUTE (z. B. neuer Pflichtflag mit fehlendem Wert in Bestand).

Verwandte Dokumente