Beim Entwerfen robuster Datenbankarchitekturen für komplexe Domänen wie die Hotellerie ist es entscheidend, Beziehungen klar darzustellen. Egal ob Sie Kundendaten abbilden, Zimmerbestände verfolgen oder Rechnungen verwalten – ein gut strukturierter Entity-Relationship-Diagramm (ERD) spart während der Entwicklung unzählige Stunden. In diesem Meisterkurs führe ich Sie Schritt für Schritt durch die Erstellung eines umfassenden Hotelmanagement-ERDs von Grund auf mit PlantUML innerhalb des kostenlosen PlantUML-Editors, VPasCode.
1. Initialisieren der PlantUML-Umgebung
Ich beginne damit, die grundlegende Struktur des Skripts aufzubauen. Bei der Arbeit mit komplexen Schemata, die zahlreiche Attribute enthalten, ist die Lesbarkeit der Anordnung von entscheidender Bedeutung. Ich konfiguriere PlantUML, um unnötigen Ballast zu verbergen und die Diagrammanordnung zu optimieren:
@startuml
title Hotelmanagement-ERD
verstecke Kreis
von links nach rechts Richtung
Warum diese Vorgehensweise?Das Verbergen der Standard-Attributkreise hält die Entitätsfelder sauber und modern. Die Festlegung der Richtung auf von links nach rechts Richtunghilft, breite ERDs davor zu schützen, vertikal unübersichtlich zu werden, und verteilt die Beziehungen zwischen mehreren Tabellen logisch.
2. Definieren der zentralen Entitäten und Attribute
Als Nächstes muss ich die zentralen Entitäten definieren, die unseren Geschäftsbereich darstellen. Ich strukturiere jede Entität mit ihren Primärschlüsseln, eindeutigen Einschränkungen und typisierten Attributen. Schauen wir uns an, wie ich die zentralen Kunde und ZimmerartEntitäten aufbauen:
entität "Kunde" als kunde {
* kunden_id : UUID <<PK>>
--
vorname : VARCHAR(50)
nachname : VARCHAR(50)
email : VARCHAR(100) <<UK>>
telefon : VARCHAR(20)
adresse : TEXT
treuepunkte : INTEGER
gesamt_aufenthalte : INTEGER
datum_registrierung : TIMESTAMP
geburtsdatum : DATE
nationalität : VARCHAR(50)
}
entität "Zimmerart" als zimmerart {
* zimmerart_id : UUID <<PK>>
--
art_name : VARCHAR(50) <<UK>>
beschreibung : TEXT
standard_kapazität : INTEGER
grundpreis : DECIMAL(10,2)
zusatzbett_geld : DECIMAL(10,2)
hat_küchenzeile : BOOLEAN
hat_balkon : BOOLEAN
}
Durch die Definition expliziter Markierungen wie <<PK>> und <<UK>>, versteht jeder, der den Code überprüft, sofort die Indizierungs- und Eindeutigkeitsregeln, noch bevor die Datenbank-Migrations-Skripte überhaupt geschrieben werden.
3. Abbildung operativer Entitäten (Zimmer, Buchungen und Personal)
Nachdem unsere Referenzdaten vorliegen, gehe ich zum transaktionalen Kern des Hotelmanagement-Systems über: Zimmer, Buchungen und Personalabläufe. Jede Entität verweist mithilfe von Fremdschlüsseln auf unsere Grundtabellen:
entität "Zimmer" als 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_ausblick : BOOLEAN
quadratfuß : INTEGER
letzte_erneuerung : DATE
}
entität "Buchung" als buchung {
* buchungs_id : UUID <<PK>>
--
kunden_id : UUID <<FK>>
zimmer_id : UUID <<FK>>
anreisedatum : DATE
abreisedatum : DATE
anzahl_gäste : INTEGER
gesamtbetrag : DECIMAL(10,2)
status : VARCHAR(20)
besondere_wünsche : TEXT
erstellt_am : TIMESTAMP
aktualisiert_am : TIMESTAMP
bestätigungscode : VARCHAR(20) <<UK>>
}
4. Festlegen finanzieller und servicebezogener Beziehungen
Um die Architektur abzuschließen, stelle ich die Rechnungsdaten (Zahlungen und Rechnungen) sowie Hilfsdienstleistungen wie Zimmerservice, die vom Hotelpersonal erbracht werden, dar. Um alles miteinander zu verbinden, definiere ich die Kardinalität ausdrücklich mit der Standard-Notation von PlantUML:
' Beziehungen
customer ||--o{ reservation : "macht"
room ||--o{ reservation : "zugeordnet zu"
reservation ||--|| payment : "hat"
reservation ||--|| invoice : "erzeugt"
reservation ||--o{ roomservice : "fordert an"
staff ||--o{ roomservice : "erfüllt"
roomtype ||--o{ room : "kategorisiert"
@enduml
Entwurfsentscheidung: Die Verwendung der präzisen Krähenfuß-Notation (wie ||--o{ für obligatorische zu optionale ein-zu-viele-Beziehungen) stellt sicher, dass die Geschäftslogikregeln – wie die Anforderung, dass eine Buchung einen Kunden erfordert, aber ein Kunde möglicherweise mehrere oder keine aktiven Buchungen hat – genau modelliert werden.
Der vollständige PlantUML-Skript
Hier ist der vollständige, zusammengestellte Quellcode für unsere Hotelmanagement-ERD. Sie können diesen Code direkt in Ihren bevorzugten kostenlosen PlantUML-Editor zum Bearbeiten oder Rendern von Vektorgrafiken:
@startuml
title Hotelmanagement-ERD
hide circle
von links nach rechts 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 "Buchung" 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 : "zugeordnet zu"
reservation ||--|| payment : "hat"
reservation ||--|| invoice : "erzeugt"
reservation ||--o{ roomservice : "fordert an"
staff ||--o{ roomservice : "erfüllt"
roomtype ||--o{ room : "kategorisiert"
@enduml
Die Erstellung komplexer Datenbankmodelle muss nicht bedeuten, sich mit unhandlichen Drag-and-Drop-Benutzeroberflächen herumzuschlagen. Durch die Nutzung eines Diagramm-als-Code-Ansatzes bleibt Ihre Architektur versionskontrolliert, sauber und problemlos wartbar.
Bereit, Ihre eigenen Systemarchitekturen zu erstellen? Gehen Sie zu VPasCode um heute Echtzeit-Rendering, automatische Formatdetektion und nahtlose Exporte für Ihre technische Dokumentation zu erleben!
