Lors de la conception d’architectures de bases de données robustes pour des domaines complexes comme l’hôtellerie, la visualisation claire des relations est essentielle. Que vous cartographiez des profils clients, suiviez les stocks de chambres ou gériez la facturation, un schéma entité-association (MCD) bien structuré fait gagner des heures de développement. Dans ce masterclass, je vous expliquerai comment j’ai construit de zéro un MCD complet de gestion hôtelière en utilisant PlantUML dans le éditeur PlantUML gratuit, VPasCode.
1. Initialisation de l’environnement PlantUML
Je commence par mettre en place la structure de base du script. Lorsqu’on travaille avec des schémas complexes contenant de nombreux attributs, la lisibilité de la mise en page est primordiale. Je configure PlantUML pour masquer les éléments inutiles et optimiser la direction de la disposition du diagramme :
@startuml
titre MCD de gestion hôtelière
hide circle
direction de gauche à droite
Pourquoi cette approche ? Masquer les cercles d’attributs par défaut garde les boîtes d’entités propres et modernes. Définir la direction sur direction de gauche à droite aide à éviter que les MCD larges ne deviennent verticalement ingérables, en répartissant logiquement les relations multi-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. Je structure chaque entité avec ses clés primaires, ses contraintes d’unicité et ses attributs typés. Voyons comment j’ai configuré les entités principales Client et Type de chambre :
entité "Client" as 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" as typechambre {
* 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>>, toute personne examinant le code comprend instantanément les règles d’indexation et d’unicité avant même que les scripts de migration de la base de données ne soient écrits.
3. Cartographie des entités opérationnelles (Chambres, Réservations et Personnel)
Une fois nos données de référence en place, je passe au cœur transactionnel du système de gestion hôtelière : les chambres, les réservations et les flux de travail du personnel. Chaque entité se lie aux tables de base à l’aide de clés étrangères :
entité "Chambre" as 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" as 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. Établissement des relations financières et de service
Pour conclure l’architecture, je cartographie les enregistrements de facturation (Paiements et Factures) ainsi que les services auxiliaires comme le service en chambre géré par le personnel de l’hôtel. Pour tout relier, je définis explicitement la cardinalité en utilisant la notation standard de PlantUML :
' Relations
customer ||--o{ reservation : "effectue"
room ||--o{ reservation : "attribué à"
reservation ||--|| payment : "possède"
reservation ||--|| invoice : "génère"
reservation ||--o{ roomservice : "demande"
staff ||--o{ roomservice : "exécute"
roomtype ||--o{ room : "catégorise"
@enduml
Choix de conception : L’utilisation d’une notation précise en forme de patte de corbeau (telle que “||--o{ pour les relations un-à-plusieurs obligatoires vers 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 — sont modélisées avec précision.
Le script PlantUML complet
Voici le code source complet et assemblé pour notre MCD de gestion hôtelière. Vous pouvez copier et coller ce code directement dans votre éditeur PlantUML préféré éditeur PlantUML gratuit pour modifier ou générer des graphiques vectoriels :
@startuml
titre MCD de gestion hôtelière
hide circle
direction left to right
' 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 en 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 : "attribué à"
reservation ||--|| payment : "possède"
reservation ||--|| invoice : "génère"
reservation ||--o{ roomservice : "demande"
staff ||--o{ roomservice : "exécute"
roomtype ||--o{ room : "catégorise"
@enduml
Construire des modèles de base de données complexes ne signifie pas nécessairement lutter avec des interfaces utilisateur de glisser-déposer maladroites. En adoptant une approche diagramme-as-code, votre architecture reste versionnée, propre et facilement maintenable.
Prêt à essayer de créer vos propres architectures de système ? Rendez-vous sur VPasCode pour découvrir le rendu en temps réel, la détection automatique de format et les exports fluides pour votre documentation technique dès aujourd’hui !