Podczas projektowania solidnych architektur baz danych dla złożonych domen, takich jak hotelarstwo, kluczowe jest jasne wizualizowanie relacji. Niezależnie od tego, czy mapujesz profile klientów, śledzisz stany pokoi, czy zarządzasz rozliczeniami, dobrze strukturyzowany diagram relacji encji (ERD) oszczędza niezliczone godziny podczas rozwoju. W tym warsztacie pokażę Ci, jak od podstaw zbudowałem kompleksowy schemat ERD dla systemu zarządzania hotelem, używając PlantUML wewnątrz darmowego edytora PlantUML, VPasCode.
1. Inicjalizowanie środowiska PlantUML
Zaczynam od ustawienia podstawowej struktury skryptu. Przy pracy ze złożonymi schematami zawierającymi wiele atrybutów, czytelność układu jest priorytetem. Konfiguruję PlantUML tak, aby ukrywać niepotrzebny bałagan i zoptymalizować kierunek układu diagramu:
@startuml
tytuł: Hotel Management ERD
hide circle
kierunek: od lewej do prawej
Dlaczego taka metoda? Ukrywanie domyślnych kółek atrybutów sprawia, że pudełka encji są czyste i nowoczesne. Ustawienie kierunku na od lewej do prawej pomaga zapobiegać temu, aby szerokie schematy ERD nie stały się pionowo niezarządzalne, logicznie rozkładając relacje między wieloma tabelami.
2. Definiowanie podstawowych encji i atrybutów
Następnie muszę zdefiniować podstawowe encje reprezentujące naszą domenę biznesową. Strukturyzuję każdą encję z jej kluczami głównymi, ograniczeniami unikalności i atrybutami o określonym typie. Zobaczmy, jak skonfigurowałem podstawowe Klienta i Typu Pokoju encji:
entity "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)
}
entity "TypPokoiu" jako roomtype {
* 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
}
Poprzez definiowanie jawnego znacznika takiego jak <<PK>> i <<UK>>, każdy przeglądający kod natychmiast rozumie reguły indeksowania i unikalności jeszcze zanim napisane zostaną skrypty migracji bazy danych.
3. Mapowanie encji operacyjnych (Pokoje, Rezerwacje i Personel)
Mając już dane referencyjne, przechodzę do transakcyjnego serca systemu zarządzania hotelem: pokoi, rezerwacji i przepływów pracy personelu. Każda encja łączy się z naszymi podstawowymi tabelami za pomocą kluczy obcych:
entity "Pokój" jako room {
* 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
}
entity "Rezerwacja" jako reservation {
* 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. Ustalanie relacji finansowych i usługowych
Aby zamknąć architekturę, mapuję rekordy rozliczeniowe (Płatności i Faktury) wraz z usługami pomocniczymi, takimi jak Room Service obsługiwane przez personel hotelu. Aby połączyć wszystko ze sobą, jawnie definiuję kardynalność, używając standardowej notacji PlantUML:
' Relacje
customer ||--o{ rezerwacja : "tworzy"
pokój ||--o{ rezerwacja : "przypisany do"
rezerwacja ||--|| płatność : "posiada"
rezerwacja ||--|| faktura : "generuje"
rezerwacja ||--o{ obsługa pokoju : "zgłasza"
personel ||--o{ obsługa pokoju : "realizuje"
typ pokoju ||--o{ pokój : "kategoryzuje"
@enduml
Wybór projektowy: Używanie precyzyjnej notacji „łapy kruka||--o{ dla obowiązkowych relacji jeden-do-wielu z opcjonalnym końcem) zapewnia, że reguły logiki biznesowej — takie jak konieczność posiadania klienta przez rezerwację, podczas gdy klient może mieć wiele lub zero aktywnych rezerwacji — są poprawnie zamodelowane.
Pełny skrypt PlantUML
Oto pełny, zebrany kod źródłowy naszego diagramu ERD dla systemu zarządzania hotelem. Możesz skopiować i wkleić ten kod bezpośrednio do swojego ulubionego darmowego edytora PlantUML aby edytować lub renderować grafikę wektorową:
@startuml
tytuł: Diagram ERD zarządzania hotelem
hide circle
kierunek od lewej do prawej
' Definiowanie encji z atrybutami
entity "Klient" as klient {
* klient_id : UUID <>
--
imię : VARCHAR(50)
nazwisko : VARCHAR(50)
email : VARCHAR(100) <>
telefon : VARCHAR(20)
adres : TEXT
punkty lojalnościowe : INTEGER
całkowita liczba pobytów : INTEGER
data rejestracji : TIMESTAMP
data urodzenia : DATE
narodowość : VARCHAR(50)
}
entity "Pokój" as pokój {
* pokój_id : UUID <>
--
numer pokoju : VARCHAR(10) <>
numer piętra : INTEGER
typ_pokoju_id : UUID <>
pojemność : INTEGER
cena bazowa : DECIMAL(10,2)
dostępny : BOOLEAN
z widokiem : BOOLEAN
powierzchnia : INTEGER
data ostatniego remontu : DATE
}
entity "TypPokoju" as typ_pokoju {
* typ_pokoju_id : UUID <>
--
nazwa_typu : VARCHAR(50) <>
opis : TEXT
standardowa_pojemność : INTEGER
cena_bazowa : DECIMAL(10,2)
dodatkowa_opłata za dodatkowe łóżko : DECIMAL(10,2)
z aneksem kuchennym : BOOLEAN
z balkonem : BOOLEAN
}
entity "Rezerwacja" as rezerwacja {
* rezerwacja_id : UUID <>
--
klient_id : UUID <>
pokój_id : UUID <>
data_wjazdu : DATE
data_wyjazdu : DATE
liczba_gości : INTEGER
kwota_całkowita : DECIMAL(10,2)
status : VARCHAR(20)
specjalne_wymagania : TEXT
utworzono_w : TIMESTAMP
zaktualizowano_w : TIMESTAMP
kod_potwierdzenia : VARCHAR(20) <>
}
entity "Płatność" as płatność {
* płatność_id : UUID <>
--
rezerwacja_id : UUID <>
kwota : DECIMAL(10,2)
data_płatności : TIMESTAMP
metoda_płatności : VARCHAR(30)
numer_transakcji : VARCHAR(50) <>
status : VARCHAR(20)
url_paragonu : TEXT
kwota_zwrotu : DECIMAL(10,2)
}
entity "Faktura" as faktura {
* faktura_id : UUID <>
--
rezerwacja_id : UUID <>
numer_faktury : VARCHAR(20) <>
data_wystawienia : DATE
data_wymagalności : DATE
suma_częściowa : DECIMAL(10,2)
podatek : DECIMAL(10,2)
opłata za usługę : DECIMAL(10,2)
kwota_całkowita : DECIMAL(10,2)
status : VARCHAR(20)
}
entity "Personel" as personel {
* personel_id : UUID <>
--
imię : VARCHAR(50)
nazwisko : VARCHAR(50)
email : VARCHAR(100) <>
telefon : VARCHAR(20)
rola : VARCHAR(30)
data_zatrudnienia : DATE
wynagrodzenie : DECIMAL(10,2)
harmonogram_zmian : VARCHAR(50)
aktywny : BOOLEAN
}
entity "ObsługaPokoiu" as obsługa_pokoju {
* usługa_id : UUID <>
--
rezerwacja_id : UUID <>
personel_id : UUID <>
typ_usługi : VARCHAR(50)
opis : TEXT
czas_zgłoszenia : TIMESTAMP
czas_zakończenia : TIMESTAMP
status : VARCHAR(20)
cena : DECIMAL(10,2)
}
' Relacje
klient ||--o{ rezerwacja : "tworzy"
pokój ||--o{ rezerwacja : "przypisany do"
rezerwacja ||--|| płatność : "posiada"
rezerwacja ||--|| faktura : "generuje"
rezerwacja ||--o{ obsługa_pokoju : "zgłasza"
personel ||--o{ obsługa_pokoju : "realizuje"
typ_pokoju ||--o{ pokój : "kategoryzuje"
@enduml
Tworzenie złożonych modeli baz danych nie musi oznaczać walki z niezgrabnymi interfejsami graficznymi typu „przeciągnij i upuść
Gotów spróbować zbudować własne architektury systemów? Przenieś się na VPasCode aby już dziś doświadczyć renderowania w czasie rzeczywistym, automatycznego wykrywania formatu i bezproblemowego eksportu do swojej dokumentacji technicznej!