DB-Schema-Detailprüfung UC18 – Equipment-Verleih¶

Stand: 01.08.2026 14:55 Branch: docs/einheitliche-kopfbereiche Status: Abgeschlossen; Gegen vorhandene UC18-Spezifikation als V2-Kompatibilität konzeptionell geprüft

Datum, Uhrzeit	Version	Änderung	Autor
01.08.2026 14:55	1.0	Kopfbereich vereinheitlicht	David Mittig
01.08.2026 11:12	1.0	Kopfbereich ergänzt	David Mittig

1. Prüfgrundlage¶

Geprüft wurde gegen:

docs/developer/uc18/uc18-spezifikation.md,
backend/prisma/schema.prisma v3,
docs/developer/uc00/db-schema-zielbild-uc-matrix.md,
docs/developer/db-schema.md v6,
docs/management/roadmap.md.

Korrekturhinweis:

Die frühere Fassung dieser Detailprüfung enthielt die falsche Aussage, dass keine eigene UC18-Spezifikation gefunden wurde. Die Spezifikation existiert und wurde in dieser Nachprüfung berücksichtigt.

2. Fachlicher UC-Zweck aus der Spezifikation¶

UC18 ermöglicht Tauchschulen, Equipment an Kunden, Kursteilnehmer oder interne Mitarbeiter auszugeben, Rückgaben zu dokumentieren und Zustand, Verfügbarkeit sowie Historie nachvollziehbar zu führen.

UC18 setzt auf UC01 Equipment erfassen auf und verändert den Equipment-Core nicht, sondern ergänzt Verleihvorgänge, Verleihpositionen, Zustandsprotokolle und spätere Berichte.

3. V2-Spezifikationsanforderungen gegen Prisma-Zielschema¶

Anforderung UC18	Prisma-Zielschema v3	Bewertung
Equipment-Core aus UC01	`Equipment`	vorhanden
QR-Code-Auswahl	`EquipmentIdentifier` mit `qr_code`	vorbereitet
Datenqualität vollständig	`Equipment.dataQualityStatus`	vorhanden
Equipment-Typ `unknown` blockieren	`EquipmentType.unknown`	vorhanden
aktive / inaktive Status	`EquipmentStatus`	vorhanden
Zustand Stammdaten	`Equipment.condition`	vorhanden, aber nicht als Verleihhistorie verwenden
Ausgabezustand	`rental_condition_logs` V2	bewusst nicht V1
Rückgabezustand	`rental_condition_logs` V2	bewusst nicht V1
Verleihvorgang	`rental_transactions` V2	bewusst nicht V1
Verleihpositionen	`rental_items` V2	bewusst nicht V1
Kunde / Empfänger	`Customer`, `User`	vorbereitet
überfällige Rückgaben	V2-Tabellen nötig	bewusst nicht V1
Verleihhistorie	V2-Tabellen nötig	bewusst nicht V1
Audit	`AuditLog`, `AccessLog`, `SystemLog`	vorbereitet

4. V1-Kompatibilitätsprüfung¶

4.1 Equipment-Core¶

Relevante V1-Felder:

Equipment.id,
tenantId,
customerId,
equipmentType,
serialNumber,
inventoryNumber,
displayName,
status,
assignmentType,
dataQualityStatus,
location,
condition,
isArchived,
deletedAt.

Bewertung:

Der Equipment-Core ist für UC18 vorbereitet.
Es wurden keine direkten Verleihfelder wie currentRentedTo, rentalStart oder expectedReturn ergänzt. Das ist korrekt, weil UC18 historisiert über eigene V2-Tabellen modelliert werden soll.

4.2 EquipmentIdentifier¶

Relevante Felder:

identifierType = qr_code,
identifierValue,
isPrimary.

Bewertung:

QR-Code-Nutzung für Ausgabe/Rückgabe ist konzeptionell vorbereitet.

4.3 EquipmentNote¶

Bewertung:

Allgemeine Notizhistorie ist vorbereitet.
Zustandsprotokolle für Ausgabe/Rückgabe sollen später dennoch in rental_condition_logs, nicht nur in equipment_notes geführt werden.

5. Blockadeprüfung¶

Prüffrage	Ergebnis
Blockiert `equipment` spätere Verleihhistorien?	Nein
Wird Verleihstatus falsch in Equipment-Stammdaten modelliert?	Nein
Gibt es stabile Equipment-IDs?	Ja
Gibt es QR-/Identifier-Vorbereitung?	Ja
Gibt es Kundenbezug?	Ja
Gibt es Datenqualität und `unknown`-Blockade?	Ja
Gibt es Zustand als Stammdatenfeld?	Ja, aber nicht als Verleihhistorie zu verwenden
Gibt es Platz für spätere V2-Tabellen?	Ja

6. Relevante Abweichungen / offene Designpunkte für V2¶

Punkt	Bewertung	Empfehlung
keine `rental_transactions` in V1	korrekt, weil UC18 V2	in Roadmap sichtbar halten
keine `rental_items` in V1	korrekt, weil UC18 V2	V2-Schema später ergänzen
keine `rental_condition_logs` in V1	korrekt, weil UC18 V2	V2-Schema später ergänzen
kein Verfügbarkeitsstatus in Equipment	korrekt, nicht direkt in Stammdaten	Verfügbarkeit aus aktiven Rentals ableiten
keine Kaution / Preislogik	Spezifikation offen	V2-Entscheidung
keine Unterschrift	Spezifikation offen	V2-Entscheidung

7. Ergebnis¶

UC18 ist im Prisma-Zielschema v3 nicht als V1-Implementierung abgebildet, aber als V2-Kompatibilitätsanforderung konzeptionell sauber berücksichtigt.

Das Prisma-Zielschema v3 blockiert UC18 nach aktueller Prüfung nicht.

Korrekte Statusformulierung:

UC18 ist gegen die vorhandene Spezifikation geprüft. UC18 bleibt V2; das V1-Prisma-Zielschema enthält keine rental_*-Tabellen, blockiert deren spätere Ergänzung aber nach aktueller konzeptioneller Prüfung nicht.

8. Offene Nacharbeit¶

[ ] UC18 bleibt in Roadmap als V2 im Scope sichtbar.
[ ] Späteres V2-Schema für rental_transactions, rental_items, rental_condition_logs ausarbeiten.
[ ] Verfügbarkeitslogik aus aktiven Verleihen statt aus Equipment-Stammdaten modellieren.
[ ] Kaution, Preislogik, Unterschrift und Batch-Ausgabe später entscheiden.
[ ] Technische Prisma-Validierung bleibt offen.