Podczas projektowania wytrzymały architektury baz danych dla skomplikowanych dziedzin, takich jak hospitalka, jasne wizualizowanie relacji jest kluczowe. Niezależnie od tego, czy mapujesz profile klientów, śledzisz zapasy pokoi, czy zarządzasz rozliczeniami, dobrze zorganizowany diagram relacji encji (ERD) oszczędza niewyobrażalną ilość czasu podczas rozwoju. W tym szkoleniu pokażę Ci, jak stworzyłem kompleksowy diagram ERD zarządzania hotelami od zera, używając PlantUML wewnątrz darmowego edytora PlantUML, VPasCode.
1. Inicjowanie środowiska PlantUML
Zaczynam od ustawienia podstawowej struktury skryptu. Przy pracy z złożonymi schematami zawierającymi wiele atrybutów, czytelność układu jest najważniejsza. Konfiguruję PlantUML w taki sposób, aby ukryć zbędne elementy i zoptymalizować kierunek układu diagramu:
@startuml
tytuł Diagram ERD zarządzania hotelami
ukryj okrąg
kierunek od lewej do prawej
Dlaczego ten podejście?Ukrycie domyślnych okręgów atrybutów utrzymuje pola encji czyste i nowoczesne. Ustawienie kierunku na kierunek od lewej do prawej pomaga zapobiegać temu, by szerokie diagramy ERD stały się trudne do zarządzania w pionie, rozszerzając logicznie relacje między wieloma tabelami.
2. Definiowanie podstawowych encji i atrybutów
Następnie muszę zdefiniować podstawowe encje reprezentujące naszą dziedzinę biznesową. Strukturalizuję każdą encję z jej kluczami głównymi, ograniczeniami unikalności i typowanymi atrybutami. Spójrzmy, jak ustawiam podstawowe Klienta oraz RodzajPokojuencje:
encja "Klient" jako klient {
* customer_id : UUID <<PK>>
--
first_name : VARCHAR(50)
last_name : VARCHAR(50)
email : VARCHAR(100) <<UK>>
phone : VARCHAR(20)
address : TEXT
loyalty_points : INTEGER
total_stays : INTEGER
date_registered : TIMESTAMP
date_of_birth : DATE
nationality : VARCHAR(50)
}
encja "RodzajPokoju" jako rodzajpokoju {
* room_type_id : UUID <<PK>>
--
type_name : VARCHAR(50) <<UK>>
description : TEXT
standard_capacity : INTEGER
base_price : DECIMAL(10,2)
extra_bed_charge : DECIMAL(10,2)
has_kitchenette : BOOLEAN
has_balcony : BOOLEAN
}
Definiując jasne oznaczenia, takie jak <<PK>> oraz <<UK>>, każdy przeglądający kod natychmiast rozumie zasady indeksowania i unikalności, zanim nawet zostaną napisane skrypty migracji bazy danych.
3. Mapowanie encji operacyjnych (Pokoje, Rezerwacje i Personel)
Po umieszczeniu danych referencyjnych, przechodzę do centrum systemu zarządzania hotelami: pokoi, rezerwacji i przepływów pracy personelu. Każda encja łączy się z naszymi podstawowymi tabelami za pomocą kluczy obcych:
encja "Pokój" jako pokój {
* room_id : UUID <<PK>>
--
room_number : VARCHAR(10) <<UK>>
floor_number : INTEGER
room_type_id : UUID <<FK>>
capacity : INTEGER
base_price : DECIMAL(10,2)
is_available : BOOLEAN
has_view : BOOLEAN
square_feet : INTEGER
last_renovated : DATE
}
encja "Rezerwacja" jako rezerwacja {
* reservation_id : UUID <<PK>>
--
customer_id : UUID <<FK>>
room_id : UUID <<FK>>
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) <<UK>>
}
4. Ustanawianie relacji finansowych i usługowych
Aby ukończyć architekturę, mapuję rekordy rozliczeniowe (Płatności i Faktury) wraz z pomocniczymi usługami, takimi jak Usługa Pokojowa obsługiwana przez personel hotelu. Aby połączyć wszystko razem, jasno definiuję liczność za pomocą standardowej notacji PlantUML:
' Relacje
customer ||--o{ reservation : "prowadzi"
room ||--o{ reservation : "przypisana do"
reservation ||--|| payment : "ma"
reservation ||--|| invoice : "generuje"
reservation ||--o{ roomservice : "żąda"
staff ||--o{ roomservice : "realizuje"
roomtype ||--o{ room : "kategoryzuje"
@enduml
Wybór projektowy: Używanie dokładnej notacji kłykci (takiej jak ||--o{ do relacji jedno-do-wielu z wymogiem do opcjonalności zapewnia dokładne odwzorowanie reguł logiki biznesowej — takich jak konieczność istnienia klienta dla rezerwacji, ale możliwość istnienia u klienta wielu lub żadnych aktywnych rezerwacji —
Pełny skrypt PlantUML
Oto pełny, złożony kod źródłowy naszego modelu ERD do zarządzania hotelami. Możesz skopiować i wkleić ten kod bezpośrednio do ulubionego darmowego edytora PlantUML aby edytować lub renderować grafikę wektorową:
@startuml
title Zarządzanie hotelowe ERD
hide circle
left to right direction
' Zdefiniuj encje z atrybutami
entity "Klient" 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 "Pomieszczenie" 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 "Typ pomieszczenia" 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 "Rezerwacja" 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 "Płatność" 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 "Faktura" 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 "Personel" 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 "Usługa pokojowa" 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)
}
' Relacje
customer ||--o{ reservation : "prowadzi"
room ||--o{ reservation : "przypisana do"
reservation ||--|| payment : "ma"
reservation ||--|| invoice : "generuje"
reservation ||--o{ roomservice : "żąda"
staff ||--o{ roomservice : "realizuje"
roomtype ||--o{ room : "kategoryzuje"
@enduml
Tworzenie złożonych modeli baz danych nie musi oznaczać walki z nieudolnymi interfejsami typu przeciągnij i upuść. Korzystając z podejścia diagram jako kod, Twoja architektura pozostaje kontrolowana wersjami, czysta i łatwa w utrzymaniu.
Gotowy na próbowanie budowania własnych architektur systemów? Przejdź do VPasCode aby dziś doświadczyć renderowania w czasie rzeczywistym, automatycznego wykrywania formatów oraz płynnych eksportów do dokumentacji technicznej!
