DDM_ENTITY

Status: Entwurf · Spec-Kandidat: ja

Zweck

Konkreter Stammdatensatz. Strukturelle Felder (code, name, status) sind relational, fachlich freie Felder liegen in attributes jsonb. Volltextindex (search_vector), Soft Delete (deleted_at), Archivierung (status='archived' und archived_at) und Versionsnummer sind direkt am Datensatz verankert.

Felder

Feld	Typ	Pflicht	Hinweise
`id`	uuid	ja	PK
`tenant_id`	uuid	ja	FK → `AA_TENANT`, muss zum Tenant des `DDM_ENTITY_TYPE` passen
`entity_type_id`	uuid	ja	FK → `DDM_ENTITY_TYPE`
`code`	text	ja	fachlicher Schlüssel, eindeutig je Tenant + Typ unter aktiven Datensätzen
`name`	text	ja	Anzeigename
`status`	`mdm.entity_status`	ja	`draft` / `active` / `inactive` / `archived`
`attributes`	jsonb	ja	default `'{}'`, JSON-Objekt-Constraint
`search_vector`	tsvector	–	trigger-gepflegt (nicht aus dem Service schreiben)
`version`	integer	ja	default `1`, trigger-erhöht bei UPDATE
`metadata`	jsonb	ja	default `'{}'`
`created_at`, `created_by`	–	–	bei INSERT gesetzt
`updated_at`, `updated_by`	–	–	trigger-gepflegt
`archived_at`, `archived_by`	timestamptz/text	nein	Archivierung
`deleted_at`, `deleted_by`	timestamptz/text	nein	Soft Delete

Constraints

entity_attributes_is_object_chk, entity_metadata_is_object_chk
Partial Unique: uq_entity_code_active auf (tenant_id, entity_type_id, code) WHERE deleted_at IS NULL

Trigger

trg_entity_before_write (BEFORE INSERT OR UPDATE OF code, name, attributes, status, metadata):
- setzt updated_at
- bei UPDATE: erhöht version um 1
- berechnet search_vector aus code, name, einer entzerrten Form von attributes

Indizes

ix_entity_entity_type_status (partial, aktiv)
ix_entity_deleted_at
ix_entity_attributes_gin GIN auf attributes
ix_entity_search_vector_gin GIN auf search_vector
gezielte Expression-Indizes je nachgefragtem Attribut (siehe Indizes)

Lebenszyklus

Status	Bedeutung
`draft`	in Anlage, noch nicht freigegeben
`active`	fachlich aktiv
`inactive`	fachlich pausiert, weiterhin sichtbar/referenzierbar
`archived`	nicht mehr operativ, aber referenz- und auswertbar
Soft Delete	über `deleted_at`, in der Regel nur durch Admin

Verhalten

Service-Layer validiert attributes gegen Definitionen aus DDM_ENTITY_TYPE_ATTRIBUTE (Pflicht, Datentyp, Enum, Referenz, Regex, Min/Max, validation_rule).
Beim Schreiben muss in der gleichen Transaktion ein AA_AUDIT_LOG-Eintrag erzeugt werden. Optional ein DDM_ENTITY_VERSION-Snapshot (siehe Audit).

Offen

Wann genau wird ein Versionssnapshot erstellt: bei jedem UPDATE oder nur bei freigegebenen Übergängen?
Verhalten bei code-Änderung: erlaubt oder gesperrt?
Cascade- und Detach-Logik bei Soft Delete einer referenzierten Entität.