DiveLogix360 – Datenbankschema v6 (historisch)¶

Stand: 09.08.2026 14:01 Branch: main Status: Historisch; nicht als aktuelles Zielmodell verwenden

Datum, Uhrzeit	Version	Änderung	Autor
09.08.2026 14:01	1.1	Dokument gemäss ADR-009 als historischen, teilweise widersprüchlichen Schemaentwurf gekennzeichnet	Codex
01.08.2026 14:55	1.0	Kopfbereich vereinheitlicht	David Mittig

Historischer Stand: Dieses Dokument enthält einen früheren v6-/v3-Schemaentwurf und ist nicht vollständig mit der aktuellen Prisma-Ausgangsbasis oder den akzeptierten UC00-Fachregeln konsistent. Insbesondere wird InvitationToken.tokenType im Changelog als ergänzt genannt, obwohl das Feld im aktuellen Prisma-Schema fehlt. Die Datei bleibt als nachvollziehbarer Entwurfsstand erhalten und wird erst nach Freigabe des UC00-Zielschemas ersetzt.

Quelle der technischen Wahrheit: ADR-009 und backend/prisma/schema.prisma

Zweck¶

Dieses Dokument beschreibt den historischen Schemaentwurf nach einer früheren Bereinigungsphase.

Es ersetzt den früheren Dokumentationsstand mit 18 Tabellen und 8 Enums. Der frühere Stand war nicht mehr konsistent mit dem aktuellen Prisma-Schema.

Grundsatz¶

ADR-009 legt backend/prisma/schema.prisma als führende technische Definition der durch Prisma verwalteten Anwendungsmodelle fest.

Dokumentation, Roadmap, SQL-Scripte und GEM-Reviews müssen sich an diesem Schema orientieren oder Abweichungen ausdrücklich begründen.

1. Schema-Umfang¶

Der historisch als „Prisma v3“ bezeichnete Entwurf ordnete folgende fachliche Bereiche zu:

Bereich	Tabellen / Models
Mandanten und Benutzer	`Tenant`, `User`
Kunden	`Customer`
Equipment-Core	`Equipment`, `CylinderDetails`, `RegulatorDetails`, `EquipmentNote`, `EquipmentIdentifier`
Workflows	`UsecaseWorkflow`, `WorkflowHistory`
UC03 Füll-Abo / Füllkarten	`FillSubscription`, `FillCard`, `FillCardTransaction`
Benachrichtigungen	`NotificationRule`, `NotificationLog`, `NotificationTemplate`
Einladungen und Auth	`InvitationToken`, `RefreshToken`, `RecoveryCode`
Sync	`SyncQueue`
Logs und Nachweise	`AuditLog`, `AuthLog`, `DeletionLog`, `AccessLog`, `SystemLog`, `CustomerActivityLog`

2. Enums¶

Das Ziel-Schema enthält folgende Enums:

Enum	Zweck
`CountryCode`	Markt / Land: DE, CH, AT
`PlanType`	Abo / Plan: test, starter, professional, enterprise
`TenantStatus`	Status eines Tenants
`UserStatus`	Status eines Benutzers
`UserRole`	Rollenmodell: superadmin, tenant_admin, mitarbeiter, kunde
`EquipmentType`	Equipment-Katalog für UC01 und spätere Erweiterungen
`EquipmentStatus`	technischer / fachlicher Equipment-Status
`EquipmentDataQualityStatus`	Datenqualität je Equipment
`EquipmentAssignmentType`	Zuordnung: intern, Kunde, unzugeordnet
`EquipmentIdentifierType`	QR-Code, Barcode, RFID, manuelles Label, externe ID
`CylinderMaterial`	Material der Tauchflasche
`WorkflowStatus`	Status eines Usecase-Workflows
`UsecaseType`	Workflow-Typen wie TÜV und Inhouse-Service
`InvitationTokenType`	Art des Einladungstokens
`FillSubscriptionStatus`	Status eines Füll-Abos
`FillCardStatus`	Status einer Füllkarte
`FillCardTransactionType`	Vorgangsart einer Füllkartenbuchung

3. UC-Abdeckung¶

UC	Schema-Abdeckung
UC00 Tenant-Onboarding & Schulverwaltung	`Tenant`, `User`, `InvitationToken`, `RefreshToken`, `RecoveryCode`, `NotificationTemplate`, `AuthLog`, `AuditLog`, `SystemLog`
UC01 Equipment erfassen	`Equipment`, `CylinderDetails`, `RegulatorDetails`, `EquipmentNote`, `EquipmentIdentifier`, `Customer`
UC02 TÜV-Inspektion einreichen	`Equipment`, `CylinderDetails`, `UsecaseWorkflow`, `WorkflowHistory`
UC03 Füll-Abo & Füllkarten-Verwaltung	`FillSubscription`, `FillCard`, `FillCardTransaction`
UC04 Inhouse-Service erfassen	`RegulatorDetails`, `UsecaseWorkflow`, `WorkflowHistory`, `UsecaseType`
UC05 Fristen-Dashboard	`CylinderDetails`, `RegulatorDetails`, `NotificationRule`, `NotificationLog`
UC06 Kunden einladen & Portal	`Customer`, `User`, `InvitationToken`, `CustomerActivityLog`, `AuthLog`
UC07 Benachrichtigungen	`NotificationRule`, `NotificationLog`, `NotificationTemplate`, `SystemLog`
UC08 Benutzerverwaltung	`User`, `InvitationToken`, `RefreshToken`, `AuthLog`
UC09 Berichte & Export	vorhandene Fach-, Workflow- und Logtabellen; kein separates Report-Model in V1
UC-SA Superadmin-Panel	`Tenant`, `User`, `AuthLog`, `AuditLog`, `SystemLog`
UC18 Equipment-Verleih	bleibt V2; V1 blockiert spätere Tabellen nicht

4. Bewusste V2-Objekte¶

Folgende Objekte bleiben bewusst V2 und sind nicht Teil des V1-Prisma-Schemas:

customer_tenant_map
documents
change_requests
push_tokens
registration_requests
organizations
rental_transactions
rental_items
rental_condition_logs

UC18 bleibt damit im Scope, wird aber nicht als V1-Pflicht implementiert.

5. Wichtige Schemaentscheidungen¶

5.1 Recovery-Codes¶

RecoveryCode ist Bestandteil des Zielschemas.

Grund:

UC00 fordert Recovery-Codes.
AuthService enthielt bereits Recovery-Code-Logik.
Security-Review behandelte Recovery-Codes als sicherheitsrelevant.

Speicherung erfolgt über codeHash, nicht im Klartext.

5.2 Notification-Templates¶

NotificationTemplate ist Bestandteil des Zielschemas.

Templates sind in V1 systemweit und deutschsprachig. Tenant-spezifische Templates bleiben V2.

5.3 InvitationToken-Typ¶

InvitationToken enthält tokenType mit InvitationTokenType.

Damit können Admin-Einladungen, Benutzer-Einladungen, Kunden-Einladungen und 2FA-Reset fachlich unterschieden werden.

5.4 Globale E-Mail-Eindeutigkeit¶

User.email bleibt global eindeutig.

Konsequenz:

Backend-Prüfungen müssen global prüfen.
Eine E-Mail-Adresse kann in V1 nur einen Login-Benutzer repräsentieren.
Mehrmandantenfähigkeit für Taucher bleibt V2.

5.5 Customer-User-Verknüpfung¶

Customer.userId verbindet einen Kundendatensatz optional mit einem Portal-Benutzer.

5.6 UC18¶

UC18 wird nicht direkt in Equipment modelliert.

Falsch wäre:

Equipment.currentRentedTo
Equipment.rentalStart
Equipment.expectedReturn

Stattdessen bleibt UC18 V2 und erhält später eigene Historientabellen.

6. Nacharbeit¶

Nach dieser Synchronisierung müssen folgende Artefakte noch nachgezogen oder geprüft werden:

database/README.md
database/schema-final.sql
database/schema-migrate.sql
database/schema-analysis.sql
docs/developer/uc00/uc00-spezifikation.md
docs/developer/uc01/uc01-spezifikation.md
docs/developer/uc-vorentscheide/uc-kunden-vorentscheide.md
GEM 01, GEM 12, GEM 13 und GEM 14 Reviews
Backend-Code, insbesondere AuthService, InvitationService und E-Mail-Eindeutigkeit

7. Changelog v5 → v6¶

Änderung	Grund
Prisma-Schema v3 als technische Wahrheit gesetzt	Konsistenz zwischen Code, Schema und Doku
`refresh_tokens` als V1-Tabelle anerkannt	AuthService nutzt RefreshToken aktiv
`recovery_codes` ergänzt	UC00 / 2FA / Security
`notification_templates` ergänzt	UC00 / UC07 / E-Mail-Versand
`InvitationToken.tokenType` ergänzt	eindeutige Token-Arten
Equipment-Core erweitert	UC01-Anforderungen und UC18-Kompatibilität
`equipment_notes` ergänzt	strukturierte Notizhistorie
`equipment_identifiers` ergänzt	QR-Code / Identifier
UC03-Tabellen ergänzt	Füll-Abo und Füllkarten sind V1
UC18 als V2-Kompatibilität dokumentiert	Scope bleibt erhalten, V1 wird nicht aufgebläht