Datenbank-Gegencheck UC00 – Schritt 8: Abgleich UC01-Spezifikation

Stand: 01.08.2026 14:55 Branch: docs/einheitliche-kopfbereiche Status: Schritt 8 durchgeführt

Datum, Uhrzeit	Version	Änderung	Autor
01.08.2026 14:55	1.0	Kopfbereich vereinheitlicht	David Mittig

Quellen:

• docs/developer/uc01/uc01-spezifikation.md
• backend/prisma/schema.prisma
• docs/management/roadmap.md
• docs/developer/uc00/db-schema-istaufnahme-schritt-1.md
• docs/developer/uc00/db-schema-abgleich-schritt-7-uc-vorentscheide.md

Ziel von Schritt 8

Ziel dieses Schritts ist der Abgleich der UC01-Spezifikation „Equipment erfassen“ gegen das aktuelle Prisma-Schema.

Der Fokus liegt auf:

• Equipment-Core,
• Equipment-Typen,
• Pflichtfelder,
• Datenqualität,
• Kundenzuordnung,
• typabhängigen Detaildaten,
• Notizen,
• QR-Code / Identifikatoren,
• Offline- und Sync-Fähigkeit,
• Vorbereitung späterer Use-Cases inklusive UC18 Equipment-Verleih.

1. Kurzfazit

UC01 ist fachlich als Equipment-Core sinnvoll aufgebaut und passt grundsätzlich zur Architekturidee des aktuellen Prisma-Schemas.

Der Kern ist vorhanden:

• equipment
• cylinder_details
• regulator_details
• custom_data
• optionaler Kundenbezug
• Tenant-Bezug
• UUID-basierte Identifikation
• Soft-Delete / Archivierung
• Audit- und CRDT-Felder

Aber: UC01 beschreibt deutlich mehr Felder und Konzepte, als im aktuellen Prisma-Schema tatsächlich vorhanden sind.

Die wichtigsten Lücken sind:

• kein data_quality_status,
• kein assignment_type / Zuordnungstyp,
• keine Inventarnummer als Alternative zur Seriennummer,
• kein Anzeigename,
• keine strukturierte Notizhistorie,
• keine QR-Code- oder Identifier-Tabelle,
• keine Felder für Standort, Kaufdatum, Zustand oder Farbe,
• Equipment-Typen in UC01 stimmen nicht vollständig mit EquipmentType im Prisma-Schema überein,
• equipment_status in UC01 enthält archived, im Prisma-Schema ist Archivierung separat über isArchived abgebildet,
• unbestimmtes Equipment (unknown) ist im Prisma-Enum nicht vorhanden,
• serialNumber ist im Prisma-Schema Pflicht, UC01 erlaubt aber Seriennummer oder Inventarnummer bzw. temporäre ID.

Damit ist UC01 derzeit fachlich vorbereitet, aber noch nicht vollständig durch das aktuelle Prisma-Schema abgedeckt.

2. Konsistente Punkte

UC01-Anforderung	Prisma-Schema	Bewertung
Jedes Equipment gehört zu einem Tenant	Equipment.tenantId	Konsistent
Equipment wird über UUID identifiziert	Equipment.id UUID	Konsistent
Kundenbezug optional	Equipment.customerId optional	Konsistent
Equipment-Typ vorhanden	Equipment.equipmentType	Grundsätzlich konsistent
Hersteller / Modell	manufacturer, model	Konsistent
Seriennummer je Tenant + Typ eindeutig	@@unique([tenantId, equipmentType, serialNumber])	Konsistent
Foto vorgesehen	photoPath	Konsistent als Pfadfeld
Freitextnotiz vorhanden	notes	Teilweise konsistent
flexible Zusatzdaten	customData JSON	Konsistent
Flaschendetails	CylinderDetails	weitgehend konsistent
Atemreglerdetails	RegulatorDetails	weitgehend konsistent
Soft-Delete / Archivierung	deletedAt, isArchived, archivedAt	Konsistent
CRDT-/Offline-Vorbereitung	vectorClock, originClient, SyncQueue	Grundsätzlich konsistent

3. Harte oder deutliche Abweichungen

3.1 Equipment-Typen stimmen nicht vollständig überein

UC01 nennt als V1-Equipment-Typen:

• cylinder
• regulator
• bcd
• computer
• suit
• mask
• fins
• compass
• lamp
• weight
• smb
• other

Das Prisma-Enum EquipmentType enthält aktuell:

• cylinder
• regulator
• jacket
• wetsuit
• computer
• torch
• other

Bewertung:

• UC01 und Prisma verwenden unterschiedliche technische Typnamen.
• bcd entspricht fachlich vermutlich jacket.
• suit entspricht fachlich vermutlich wetsuit.
• lamp entspricht fachlich vermutlich torch.
• mask, fins, compass, weight und smb fehlen im Prisma-Enum.
• unknown für unbestimmtes Equipment fehlt ebenfalls.

Entscheidungsbedarf:

• Soll UC01 auf die vorhandenen Prisma-Typen reduziert werden?
• Oder soll EquipmentType um die UC01-Typen erweitert werden?
• Sollen technische Begriffe vereinheitlicht werden: bcd vs. jacket, suit vs. wetsuit, lamp vs. torch?

3.2 data_quality_status fehlt

UC01 fordert Datenqualität mit:

• complete
• incomplete
• needs_review

Das aktuelle Prisma-Schema enthält kein entsprechendes Feld und kein Enum.

Bewertung:

• Harte Abweichung.
• UC01-Regeln G16 und G17 sind ohne Datenqualitätsfeld nicht direkt umsetzbar.
• Auch die Sperre für Workflows bei unvollständigen Daten ist damit nicht sauber abbildbar.

3.3 Zuordnungstyp fehlt

UC01 fordert eine Zuordnung:

• internal
• customer
• unassigned

Das aktuelle Prisma-Schema hat nur:

• customerId optional

Bewertung:

• Teilweise abbildbar, aber fachlich nicht vollständig.
• customerId = null kann sowohl internal als auch unassigned bedeuten.
• Ohne eigenes Feld ist die Unterscheidung nicht möglich.

Entscheidungsbedarf:

• Soll ein assignmentType-Feld oder ein entsprechendes Enum ergänzt werden?
• Oder reicht customerId plus Status / Notiz?

3.4 Inventarnummer / temporäre ID fehlt

UC01 fordert:

• Seriennummer oder Inventarnummer,
• temporäre ID bei unbestimmtem Equipment,
• Zufalls-ID bei unklarer Erfassung.

Das Prisma-Schema hat:

• serialNumber als Pflichtfeld.

Bewertung:

• Harte Abweichung zur UC01-Regel „Seriennummer oder Inventarnummer“.
• Das aktuelle Schema erzwingt eine Seriennummer.
• Temporäre Erfassung ist nur möglich, wenn eine künstliche Seriennummer in serialNumber gespeichert wird.

Entscheidungsbedarf:

• Soll serialNumber optional werden?
• Soll inventoryNumber ergänzt werden?
• Soll eine separate temporäre Identifikation eingeführt werden?

3.5 Anzeigename fehlt

UC01 nennt „Anzeigename“ als Pflichtfeld für Listen, Suche und Praxisbetrieb.

Das Prisma-Schema enthält kein eigenes Feld dafür.

Mögliche Ableitung:

• aus manufacturer + model + serialNumber,
• oder über customData.

Bewertung:

• UC01-Pflichtfeld ist im Schema nicht explizit vorhanden.

3.6 Strukturierte Notizen fehlen

UC01 fordert strukturierte Notizen mit:

• equipment_id
• note_text
• created_at
• created_by
• optional note_type

Das aktuelle Prisma-Schema hat nur:

• Equipment.notes als Freitext.

Bewertung:

• Teilweise abbildbar, aber nicht historisiert.
• UC01 G24 ist mit dem aktuellen Schema nicht vollständig erfüllt.
• Für UC18 ist strukturierte Notizhistorie ebenfalls relevant.

3.7 QR-Code / Identifier fehlen

UC01 fordert QR-Code-Vorbereitung und nennt equipment_identifiers als mögliche eigene Tabelle.

Das aktuelle Prisma-Schema enthält:

• keine equipment_identifiers-Tabelle,
• kein eigenes QR-Code-Feld im Equipment-Model.

Bewertung:

• Noch nicht umgesetzt.
• Für UC18 später relevant, aber nicht zwingend V1, falls bewusst vorbereitet statt implementiert.

3.8 Standort, Kaufdatum, Zustand, Farbe fehlen

UC01 nennt diese Felder als empfohlen oder fachlich relevant:

• Standort / Lagerort,
• Kaufdatum,
• Zustand,
• Farbe / Kennzeichnung.

Das aktuelle Prisma-Schema enthält dafür keine dedizierten Felder.

Mögliche Abbildung:

• über customData.

Bewertung:

• Für V1 möglicherweise akzeptabel, falls bewusst über customData gelöst.
• Für UC18 ist Zustand besonders wichtig und sollte nicht nur als überschreibbarer Stammdatenwert verstanden werden.

3.9 equipment_status weicht fachlich ab

UC01 beschreibt Statuswerte:

• active
• inactive
• retired
• archived
• deleted

Das Prisma-Enum EquipmentStatus enthält:

• active
• at_inspection
• expired
• retired
• inactive

Archivierung und Löschung sind im Prisma-Schema separat abgebildet:

• isArchived
• archivedAt
• deletedAt

Bewertung:

• Fachlich nicht zwingend falsch, aber dokumentationsseitig uneinheitlich.
• UC01 sollte archived und deleted nicht als equipment_status darstellen, wenn sie im Schema separate Lifecycle-Felder sind.
• at_inspection und expired sollten in UC01 ergänzt oder bewusst späteren UCs zugeordnet werden.

3.10 Offline-Konfliktstatus fehlt im Equipment

UC01 nennt bei Fehlerfall F7:

• sync_status = conflict

Das aktuelle Prisma-Schema enthält keine syncStatus-Spalte im Equipment-Model.

Es gibt jedoch:

• SyncQueue.resolved
• SyncQueue.conflict

Bewertung:

• Konfliktlogik ist über SyncQueue grundsätzlich vorbereitet.
• UC01 sollte nicht zwingend ein Feld sync_status in equipment voraussetzen, sofern Konflikte über sync_queue geführt werden.

4. Typabhängige Details

4.1 Tauchflasche

UC01 fordert für Tauchflaschen:

• Material,
• Volumen,
• Arbeitsdruck,
• Gewinde,
• Ventiltyp / Ventilform,
• letzte Prüfung,
• nächste Prüfung,
• Normreferenz,
• Prüfstelle,
• Markierung / Stempel.

Das aktuelle CylinderDetails-Model enthält:

• material,
• thread,
• pressureBar,
• sizeLiters,
• valveShape,
• valveMarking,
• tuvLast,
• tuvNext,
• normReference,
• inspectionBody,
• inspectorId.

Bewertung:

• Weitgehend konsistent.
• Begrifflich sollten „Ventiltyp“ und valveShape abgeglichen werden.
• inspectorId ist zusätzlich vorhanden und sinnvoll.

4.2 Atemregler

UC01 fordert für Atemregler:

• Anzahl Stufen,
• Anschluss DIN / INT,
• letzte Revision,
• nächste Revision,
• Serviceintervall Monate,
• Seriennummer 1. Stufe,
• Seriennummer 2. Stufe,
• Oktopus vorhanden.

Das aktuelle RegulatorDetails-Model enthält:

• stages,
• dinOrYoke,
• lastService,
• nextService,
• serviceIntervalMonths.

Nicht vorhanden:

• Seriennummer 1. Stufe,
• Seriennummer 2. Stufe,
• Oktopus vorhanden.

Bewertung:

• Basismodell ist vorhanden, aber nicht vollständig gemäss UC01.
• Zusatzfelder könnten über customData abgebildet werden, sollten aber bewusst entschieden werden.

4.3 Weitere Equipment-Typen

UC01 nennt weitere Typen wie Jacket, Tauchcomputer, Tauchanzug, Maske, Flossen, Kompass und Lampe mit typabhängigen Feldern.

Das aktuelle Prisma-Schema enthält keine eigenen Detailtabellen dafür.

Bewertung:

• Mit dem Hybrid-Modell ist das grundsätzlich akzeptabel, wenn diese Zusatzdaten über customData abgebildet werden.
• Die UC01-Spezifikation sollte klarer angeben, welche Typdaten fest modelliert und welche über customData gelöst werden.

5. UC18 V2-Kompatibilität

UC01 enthält wichtige Aussagen, die UC18 unterstützen:

• Equipment-Verleih gehört nicht zu UC01.
• Zustand im Verleih soll nicht als einfacher Stammdatenwert behandelt werden.
• Zustand bei Ausgabe und Rückgabe soll gesondert protokolliert werden.
• Equipment-Verleih wird als eigenes späteres Modul genannt.

Bewertung:

• Diese Aussagen sind sehr gut für die V2-Kompatibilität von UC18.
• UC01 blockiert UC18 fachlich nicht.
• Das aktuelle Prisma-Schema enthält die UC18-Tabellen noch nicht, was korrekt ist, solange UC18 V2 bleibt.

Wichtig:

• Kein current_rented_to, rental_start oder ähnliches direkt in equipment ergänzen.
• Spätere Verleihdaten sollen in rental_transactions, rental_items und rental_condition_logs geführt werden.
• Strukturierte Notizen und QR-Code-Vorbereitung sollten UC18-fähig gestaltet werden.

6. Auswirkungen auf spätere Use-Cases

Use Case	Bewertung aus UC01-Sicht
UC02 TÜV-Inspektion	mit cylinder_details und usecase_workflows grundsätzlich vorbereitet
UC03 Füll-Abo / Füllkarten	durch Equipment/Kundenbezug nicht blockiert, aber eigene Tabellen fehlen
UC04 Inhouse-Service	regulator_details vorbereitet, UsecaseType muss später erweitert werden
UC05 Fristen-Dashboard	tuvNext, nextService, notification_rules grundsätzlich vorbereitet
UC06 Kundenportal	Kundenbezug vorhanden, Portal-Details separat zu prüfen
UC07 Benachrichtigungen	Rules/Logs vorhanden, Templates weiterhin offen
UC09 Berichte / Export	Grunddaten vorhanden, Reporting-Struktur separat zu prüfen
UC18 Equipment-Verleih	fachlich vorbereitet, V2-Tabellen fehlen bewusst

7. Gesamtbewertung Schritt 8

Ergebnis

Schritt 8 ist durchgeführt.

UC01 ist als fachliches Core-Konzept tragfähig, aber das aktuelle Prisma-Schema deckt nicht alle in UC01 genannten V1-Anforderungen ab.

Schweregrad

Bereich	Bewertung
Equipment-Core	grundsätzlich konsistent
Kundenzuordnung	teilweise konsistent
Seriennummer-Eindeutigkeit	konsistent
Equipment-Typen	deutliche Abweichung
Datenqualität	fehlt im Schema
Zuordnungstyp	fehlt im Schema
Inventarnummer / temporäre ID	fehlt im Schema
strukturierte Notizen	fehlen im Schema
QR-Code / Identifier	fehlen im Schema
Statusmodell	dokumentationsseitig uneinheitlich
UC18-Kompatibilität	fachlich gut vorbereitet

8. Empfohlene Korrekturmassnahmen

8.1 Kurzfristig

• [ ] Entscheiden, ob UC01-V1 wirklich alle genannten Equipment-Typen liefern soll.
• [ ] EquipmentType oder UC01-Typenliste vereinheitlichen.
• [ ] Entscheidung zu dataQualityStatus treffen.
• [ ] Entscheidung zu assignmentType treffen.
• [ ] Entscheidung zu inventoryNumber / temporärer ID treffen.
• [ ] Entscheidung zu QR-Code / equipment_identifiers treffen.
• [ ] Entscheidung zu strukturierter Notizhistorie / equipment_notes treffen.
• [ ] UC01-Statusmodell an das Prisma-Schema angleichen.

8.2 Danach

• [ ] Prüfen, ob customData für seltene Typdetails ausreicht.
• [ ] Prüfen, ob RegulatorDetails um Seriennummern der Stufen und Oktopus-Feld ergänzt werden soll.
• [ ] Prüfen, ob Equipment.notes als Übergang genügt oder ob direkt equipment_notes eingeführt wird.
• [ ] UC01 so aktualisieren, dass UC18 V2 sauber vorbereitet bleibt.
• [ ] Roadmap und docs/index.md gegen den tatsächlichen UC01-Status prüfen.

9. Offene Entscheidungsfragen

1. Soll EquipmentType erweitert werden oder wird UC01 auf die bestehenden Prisma-Typen reduziert?
2. Soll ein Equipment-Typ unknown eingeführt werden?
3. Soll serialNumber Pflicht bleiben oder durch inventoryNumber ergänzt werden?
4. Soll dataQualityStatus als eigenes Enum ins Schema?
5. Soll assignmentType als eigenes Enum ins Schema?
6. Soll equipment_notes als eigene Tabelle eingeführt werden?
7. Soll equipment_identifiers als eigene Tabelle eingeführt werden?
8. Soll EquipmentStatus umbenannt oder UC01 an die aktuelle Lifecycle-Abbildung angepasst werden?
9. Welche typabhängigen Zusatzdaten bleiben feste Felder, welche gehen in customData?
10. Soll UC01 vor Umsetzung der Backend-Services erst schemafachlich bereinigt werden?

10. Nächster empfohlener Schritt

Als nächster Prüfschritt sollten die Backend-Module für Tenant, User, Auth und Onboarding gegen das aktuelle Schema und die bisherigen Befunde geprüft werden.

Empfohlener Fokus:

• backend/src/modules/tenants/tenants.service.ts
• backend/src/modules/users/users.service.ts
• backend/src/modules/onboarding/onboarding.service.ts
• backend/src/modules/auth/auth.service.ts
• backend/src/common/services/invitation.service.ts

Ziel:

• prüfen, ob die Implementierung bereits dem aktuellen Prisma-Schema folgt,
• prüfen, ob sie noch auf alte Felder wie isActive, customerId in InvitationToken oder tokenType zugreift,
• prüfen, ob offene Schemafragen bereits im Code sichtbar werden.