Lors de la conception d’architectures de bases de données robustes pour des domaines complexes comme l’hôtellerie, visualiser clairement les relations est essentiel. Que vous soyez en train de cartographier les profils clients, de suivre les inventaires de chambres ou de gérer la facturation, un diagramme d’entités et de relations (ERD) bien structuré permet d’économiser des centaines d’heures pendant le développement. Dans cette masterclass, je vous montrerai comment j’ai construit un ERD complet de gestion hôtelière depuis zéro en utilisant PlantUML dans l’éditeur gratuit PlantUML, VPasCode.
1. Initialisation de l’environnement PlantUML
Je commence par établir la structure fondamentale du script. Lorsque l’on travaille avec des schémas complexes contenant de nombreuses attributs, la lisibilité du layout est primordiale. Je configure PlantUML pour masquer les éléments superflus et optimiser la direction du layout du diagramme :
@startuml
titre Diagramme ER de gestion hôtelière
masquer cercle
direction de gauche à droite
Pourquoi cette approche ?Masquer les cercles d’attributs par défaut maintient les boîtes d’entités propres et modernes. Définir la direction à direction de gauche à droiteaide à éviter que les ERD larges ne deviennent verticalement ingérables, en étalant logiquement les relations entre plusieurs tables.
2. Définition des entités et attributs principaux
Ensuite, je dois définir les entités principales représentant notre domaine métier. J’organise chaque entité avec ses clés primaires, ses contraintes uniques et ses attributs typés. Voyons comment j’ai configuré les entités principales Client et Type de chambre des entités :
entité "Client" comme client {
* 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)
}
entité "Type de chambre" comme 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
}
En définissant des marqueurs explicites comme <<PK>> et <<UK>>, tout lecteur du code comprend instantanément les règles d’indexation et d’unicité avant même la rédaction des scripts de migration de base de données.
3. Cartographie des entités opérationnelles (Chambres, Réservations et Personnel)
Avec nos données de référence en place, je passe au cœur opérationnel du système de gestion hôtelière : les chambres, les réservations et les flux de travail du personnel. Chaque entité est liée à nos tables fondamentales à l’aide de clés étrangères :
entité "Chambre" comme chambre {
* 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
}
entité "Réservation" comme réservation {
* 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. Établissement des relations financières et de services
Pour conclure l’architecture, je mets en place les enregistrements de facturation (Paiements et Factures) ainsi que les services auxiliaires comme le service en chambre géré par le personnel hôtelier. Pour connecter tout cela, je définis explicitement la cardinalité en utilisant la notation standard de PlantUML :
' Relations
customer ||--o{ reservation : "effectue"
room ||--o{ reservation : "affectée à"
reservation ||--|| payment : "possède"
reservation ||--|| invoice : "génère"
reservation ||--o{ roomservice : "demande"
staff ||--o{ roomservice : "remplit"
roomtype ||--o{ room : "catégorise"
@enduml
Choix de conception : Utilisation de la notation précise en forme de bec de corbeau (telle que ||--o{ pour les relations un-à-plusieurs obligatoires-à-optionnelles) garantit que les règles de logique métier—comme une réservation nécessitant un client, mais un client pouvant avoir plusieurs ou zéro réservations actives—soient correctement modélisées.
Le script PlantUML complet
Voici le code source complet et assemblé pour notre modèle ER de gestion d’hôtel. Vous pouvez copier-coller ce code directement dans votre éditeur PlantUML préféré éditeur PlantUML gratuit pour éditer ou rendre des graphiques vectoriels :
@startuml
title Modèle ER de gestion d'hôtel
masquer cercle
direction de gauche à droite
' Définir les entités avec leurs attributs
entity "Client" 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 "Chambre" 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 "Type de Chambre" 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 "Réservation" 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 "Paiement" 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 "Facture" 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 "Personnel" 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 "Service de Chambre" 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)
}
' Relations
customer ||--o{ reservation : "effectue"
room ||--o{ reservation : "affectée à"
reservation ||--|| payment : "possède"
reservation ||--|| invoice : "génère"
reservation ||--o{ roomservice : "demande"
staff ||--o{ roomservice : "remplit"
roomtype ||--o{ room : "catégorise"
@enduml
Construire des modèles de bases de données complexes n’a pas à signifier lutter avec des interfaces utilisateur maladroites basées sur le glisser-déposer. En utilisant une approche diagramme-en-code, votre architecture reste contrôlée par version, propre et facile à maintenir.
Prêt à essayer de construire vos propres architectures système ? Rendez-vous sur VPasCode pour découvrir le rendu en temps réel, la détection automatique des formats et les exports fluides pour votre documentation technique dès aujourd’hui !
