Beim Entwurf robuster Datenbankarchitekturen für komplexe Domänen wie das Gastgewerbe ist die klare Visualisierung von Beziehungen entscheidend. Ob Sie Kundenprofile abbilden, Zimmerbestände verfolgen oder Abrechnungen verwalten – ein gut strukturierter Entity-Relationship-Diagramm (ERD) spart unzählige Stunden während der Entwicklung. In diesem Masterclass führe ich Sie Schritt für Schritt durch, wie ich eine umfassende Hotel-Management-ERD von Grund auf mit PlantUML innerhalb des kostenlosen PlantUML-Editors, VPasCode.
1. Initialisieren der PlantUML-Umgebung
Ich beginne damit, die grundlegende Struktur des Skripts einzurichten. Bei der Arbeit mit komplexen Schemata, die zahlreiche Attribute enthalten, ist die Lesbarkeit des Layouts von größter Bedeutung. Ich konfiguriere PlantUML so, dass unnötiger Ballast ausgeblendet und die Diagramm-Layout-Richtung optimiert wird:
@startuml
titel Hotel-Management-ERD
hide circle
left to right direction
Warum dieser Ansatz? Das Ausblenden der Standard-Attribut-Kreise hält die Entity-Boxen sauber und modern. Das Einstellen der Richtung auf left to right direction hilft verhindern, dass breite ERDs vertikal unübersichtlich werden, indem sie mehrstellige Beziehungen logisch aufteilen.
2. Definieren von Kern-Entitäten und Attributen
Als Nächstes muss ich die Kern-Entitäten definieren, die unser Geschäftsdomänen abbilden. Ich strukturiere jede Entität mit ihren Primärschlüsseln, Unique-Constraints und typisierten Attributen. Schauen wir uns an, wie ich die Kern-Entitäten Kunde und Zimmerart-Entitäten einrichte:
entity "Kunde" as kunde {
* kunde_id : UUID <<PK>>
--
vorname : VARCHAR(50)
nachname : VARCHAR(50)
email : VARCHAR(100) <<UK>>
telefon : VARCHAR(20)
adresse : TEXT
treuepunkte : INTEGER
gesamtübernachtungen : INTEGER
registrierungsdatum : TIMESTAMP
geburtsdatum : DATE
staatsangehörigkeit : VARCHAR(50)
}
entity "Zimmerart" as zimmerart {
* zimmerart_id : UUID <<PK>>
--
artname : VARCHAR(50) <<UK>>
beschreibung : TEXT
standardkapazität : INTEGER
grundpreis : DECIMAL(10,2)
zusatzbettgebühr : DECIMAL(10,2)
hat_küchenzeile : BOOLEAN
hat_balkon : BOOLEAN
}
Durch das Definieren expliziter Marker wie <<PK>> und <<UK>> versteht jeder, der den Code prüft, sofort die Indizierungs- und Eindeutigkeitsregeln, noch bevor die Datenbank-Migrations-Skripte überhaupt geschrieben werden.
3. Abbilden von operativen Entitäten (Zimmer, Reservierungen und Personal)
Nachdem unsere Referenzdaten bereitstehen, gehe ich zum transaktionalen Kern des Hotel-Management-Systems über: Zimmer, Reservierungen und Personalabläufe. Jede Entität verweist über Fremdschlüssel zurück auf unsere grundlegenden Tabellen:
entity "Zimmer" as zimmer {
* zimmer_id : UUID <<PK>>
--
zimmernummer : VARCHAR(10) <<UK>>
stockwerk : INTEGER
zimmerart_id : UUID <<FK>>
kapazität : INTEGER
grundpreis : DECIMAL(10,2)
ist_verfügbar : BOOLEAN
hat_aussicht : BOOLEAN
quadratmeter : INTEGER
letzte_sanierung : DATE
}
entity "Reservierung" as reservierung {
* reservierungs_id : UUID <<PK>>
--
kunde_id : UUID <<FK>>
zimmer_id : UUID <<FK>>
anreisedatum : DATE
abreisedatum : DATE
anzahl_gäste : INTEGER
gesamtsumme : DECIMAL(10,2)
status : VARCHAR(20)
besondere_wünsche : TEXT
erstellungsdatum : TIMESTAMP
aktualisierungsdatum : TIMESTAMP
bestätigungscode : VARCHAR(20) <<UK>>
}
4. Etablieren von finanziellen und servicebezogenen Beziehungen
Um die Architektur abzurunden, erstelle ich eine Übersicht der Abrechnungsdaten (Zahlungen und Rechnungen) sowie ergänzender Dienstleistungen wie dem Zimmerservice, der vom Hotelpersonal erledigt wird. Um alles miteinander zu verbinden, definiere ich die Kardinalität explizit unter Verwendung der Standard-PlantUML-Notation:
' Beziehungen
customer ||--o{ reservation : "macht"
room ||--o{ reservation : "zugewiesen"
reservation ||--|| payment : "hat"
reservation ||--|| invoice : "generiert"
reservation ||--o{ roomservice : "fordert an"
staff ||--o{ roomservice : "erfüllt"
roomtype ||--o{ room : "kategorisiert"
@enduml
Designentscheidung: Die Verwendung präziser Krähenfuß-Notation (wie “||--o{ für zwingende-zu-optionale Eins-zu-Viele-Beziehungen) stellt sicher, dass die Geschäftslogikregeln – wie eine Reservierung, die einen Kunden erfordert, ein Kunde jedoch möglicherweise mehrere oder keine aktiven Buchungen haben kann – korrekt modelliert werden.
Das vollständige PlantUML-Skript
Hier ist der vollständige, zusammengeführte Quellcode für unsere ERD für das Hotelmanagement. Sie können diesen Code direkt in Ihren bevorzugten kostenlosen PlantUML-Editoreingeben, um Vektorgrafiken zu bearbeiten oder darzustellen:
@startuml
titel Hotelmanagement-ERD
hide circle
left to right direction
' Entitäten mit Attributen definieren
entity "Kunde" as customer {
* customer_id : UUID <>
--
first_name : VARCHAR(50)
last_name : VARCHAR(50)
email : VARCHAR(100) <>
phone : VARCHAR(20)
address : TEXT
loyalty_points : INTEGER
total_stays : INTEGER
date_registered : TIMESTAMP
date_of_birth : DATE
nationality : VARCHAR(50)
}
entity "Zimmer" as room {
* room_id : UUID <>
--
room_number : VARCHAR(10) <>
floor_number : INTEGER
room_type_id : UUID <>
capacity : INTEGER
base_price : DECIMAL(10,2)
is_available : BOOLEAN
has_view : BOOLEAN
square_feet : INTEGER
last_renovated : DATE
}
entity "ZimmerTyp" as roomtype {
* room_type_id : UUID <>
--
type_name : VARCHAR(50) <>
description : TEXT
standard_capacity : INTEGER
base_price : DECIMAL(10,2)
extra_bed_charge : DECIMAL(10,2)
has_kitchenette : BOOLEAN
has_balcony : BOOLEAN
}
entity "Reservierung" as reservation {
* reservation_id : UUID <>
--
customer_id : UUID <>
room_id : UUID <>
check_in_date : DATE
check_out_date : DATE
number_of_guests : INTEGER
total_amount : DECIMAL(10,2)
status : VARCHAR(20)
special_requests : TEXT
created_at : TIMESTAMP
updated_at : TIMESTAMP
confirmation_code : VARCHAR(20) <>
}
entity "Zahlung" as payment {
* payment_id : UUID <>
--
reservation_id : UUID <>
amount : DECIMAL(10,2)
payment_date : TIMESTAMP
payment_method : VARCHAR(30)
transaction_id : VARCHAR(50) <>
status : VARCHAR(20)
receipt_url : TEXT
refund_amount : DECIMAL(10,2)
}
entity "Rechnung" as invoice {
* invoice_id : UUID <>
--
reservation_id : UUID <>
invoice_number : VARCHAR(20) <>
issued_date : DATE
due_date : DATE
subtotal : DECIMAL(10,2)
tax : DECIMAL(10,2)
service_charge : DECIMAL(10,2)
total_amount : DECIMAL(10,2)
status : VARCHAR(20)
}
entity "Mitarbeiter" as staff {
* staff_id : UUID <>
--
first_name : VARCHAR(50)
last_name : VARCHAR(50)
email : VARCHAR(100) <>
phone : VARCHAR(20)
role : VARCHAR(30)
hire_date : DATE
salary : DECIMAL(10,2)
shift_schedule : VARCHAR(50)
is_active : BOOLEAN
}
entity "Zimmerservice" as roomservice {
* service_id : UUID <>
--
reservation_id : UUID <>
staff_id : UUID <>
service_type : VARCHAR(50)
description : TEXT
request_time : TIMESTAMP
completion_time : TIMESTAMP
status : VARCHAR(20)
price : DECIMAL(10,2)
}
' Beziehungen
customer ||--o{ reservation : "macht"
room ||--o{ reservation : "zugewiesen"
reservation ||--|| payment : "hat"
reservation ||--|| invoice : "generiert"
reservation ||--o{ roomservice : "fordert an"
staff ||--o{ roomservice : "erfüllt"
roomtype ||--o{ room : "kategorisiert"
@enduml
Das Erstellen komplexer Datenbankmodelle muss nicht bedeuten, sich mit umständlichen Drag-and-Drop-Benutzeroberflächen herumschlagen zu müssen. Durch die Nutzung eines Diagramm-als-Code-Ansatzes bleibt Ihre Architektur versioniert, sauber und mühelos wartbar.
Bereit, Ihre eigenen Systemarchitekturen zu erstellen? Besuchen Sie VPasCodeum noch heute Echtzeit-Rendering, automatische Formaterkennung und nahtlose Exporte für Ihre technischen Dokumentationen zu erleben!