Fachregeln
Status: Entwurf · Spec-Kandidat: ja (jede Regel muss in technische Durchsetzung übersetzt werden)
Diese Regeln sind verbindlich. Sie müssen entweder in der Datenbank, im Service-Layer oder kombiniert durchgesetzt werden – siehe Validierungskonzept.
| # | Regel | Primäre Durchsetzung |
|---|---|---|
| BR-01 | Jede Entität gehört genau einem Entitätstyp. | DB (DDM_ENTITY.entity_type_id NOT NULL + FK) |
| BR-02 | Jeder Entitätstyp kann beliebig viele Attributdefinitionen besitzen. | DB (n:1 zu DDM_ENTITY_TYPE via DDM_ENTITY_TYPE_ATTRIBUTE.entity_type_id) |
| BR-03 | Attribute werden grundsätzlich über Metadaten beschrieben. | DB-Modell + Service (kein Schemawandel pro Attribut) |
| BR-04 | Flexible Attributwerte werden in JSONB gespeichert. | DB (DDM_ENTITY.attributes jsonb) |
| BR-05 | Echte Beziehungen zwischen Entitäten werden relational gespeichert. | DB (DDM_ENTITY_RELATION-Tabelle, FKs) |
| BR-06 | Eine Entität darf bei bestehenden kritischen Abhängigkeiten nicht unkontrolliert gelöscht werden. | Service + DB (DDM_RELATION_TYPE.delete_policy) |
| BR-07 | Hard Delete ist nur administrativ zulässig. | Service (Rolle Administrator) |
| BR-08 | Änderungen an Entitäten und Metadaten sind zu protokollieren. | Service (Audit-Log-Schreibung in Transaktion) |
| BR-09 | Fachliche Codes müssen je Entitätstyp eindeutig sein. | DB (partial unique index uq_entity_code_active) |
| BR-10 | Such- und Reporting-relevante Felder müssen indexierbar bzw. per View bereitstellbar sein. | DB (Indexstrategie, Views) |
| BR-11 | Jeder schreibende und lesende API-Aufruf wird gegen die effektiven Permissions des Aufrufers geprüft. | Service (RBAC + ACL via mdm.v_effective_permission) |
| BR-12 | deny schlägt allow; spezifischerer Scope schlägt allgemeineren; Default ist deny. | Service (deterministische Auflösung), DB (Scope-Constraints) |
| BR-13 | System-Rollen und System-Permissions sind unveränderlich (is_system=true). | Service (Schreibverbot), DB (per Permission-Layer) |