Al diseñar arquitecturas de bases de datos robustas para dominios complejos como la hospitalidad, visualizar claramente las relaciones es fundamental. Ya sea que estés mapeando perfiles de clientes, rastreando inventarios de habitaciones o gestionando facturación, un diagrama de relaciones de entidades (ERD) bien estructurado ahorra incontables horas durante el desarrollo. En esta masterclass, te mostraré paso a paso cómo creé un ERD completo para la gestión de hoteles desde cero utilizando PlantUML dentro deleditor gratuito de PlantUML, VPasCode.
1. Inicializando el entorno de PlantUML
Comienzo estableciendo la estructura fundamental del script. Al trabajar con esquemas complejos que contienen numerosos atributos, la legibilidad del diseño es fundamental. Configuro PlantUML para ocultar el ruido innecesario y optimizar la dirección del diseño del diagrama:
@startuml
título Diagrama ERD de gestión de hoteles
ocultar círculo
dirección de izquierda a derecha
¿Por qué este enfoque?Ocultar los círculos de atributos predeterminados mantiene las cajas de entidades limpias y modernas. Establecer la dirección endirección de izquierda a derechaayuda a evitar que los ERD amplios se vuelvan verticalmente inmanejables, distribuyendo de forma lógica las relaciones entre múltiples tablas.
2. Definiendo entidades y atributos principales
A continuación, debo definir las entidades principales que representan nuestro dominio empresarial. Estructuro cada entidad con sus claves primarias, restricciones únicas y atributos tipificados. Veamos cómo configuré las entidades principalesCliente y Tipo de Habitación entidades:
entidad "Cliente" como cliente {
* 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)
}
entidad "Tipo de Habitación" como tipohabitacion {
* 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
}
Al definir marcadores explícitos como<<PK>> y <<UK>>, cualquier persona que revise el código entiende de inmediato las reglas de indexación y unicidad antes incluso de que se escriban los scripts de migración de la base de datos.
3. Mapeando entidades operativas (Habitaciones, Reservas y Personal)
Con nuestros datos de referencia establecidos, paso al núcleo operativo del sistema de gestión de hoteles: habitaciones, reservas y flujos de trabajo del personal. Cada entidad se vincula de nuevo a nuestras tablas fundamentales mediante claves foráneas:
entidad "Habitación" como habitacion {
* 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
}
entidad "Reserva" como reserva {
* 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. Estableciendo relaciones financieras y de servicios
Para finalizar la arquitectura, mapeo los registros de facturación (Pagos e Facturas) junto con servicios auxiliares como el servicio de habitación gestionado por el personal del hotel. Para unir todo, defino explícitamente la cardinalidad utilizando la notación estándar de PlantUML:
' Relaciones
customer ||--o{ reservation : "realiza"
room ||--o{ reservation : "asignada a"
reservation ||--|| payment : "tiene"
reservation ||--|| invoice : "genera"
reservation ||--o{ roomservice : "solicita"
staff ||--o{ roomservice : "cumple"
roomtype ||--o{ room : "categoriza"
@enduml
Elección de diseño: Utilizando la notación precisa de pie de cuervo (como ||--o{ para relaciones uno a muchos obligatorias a opcionales) garantiza que las reglas de lógica de negocio—como una reserva que requiere un cliente, pero un cliente que potencialmente puede tener múltiples o cero reservas activas—se modelen con precisión.
El script completo de PlantUML
Aquí está el código fuente completo y ensamblado para nuestro modelo ERD de gestión de hoteles. Puedes copiar y pegar este código directamente en tu editor favorito de editor gratuito de PlantUML para editar o renderizar gráficos vectoriales:
@startuml
title Modelo ERD de gestión de hoteles
ocultar círculo
dirección de izquierda a derecha
' Definir entidades con atributos
entidad "Cliente" como 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)
}
entidad "Habitación" como 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
}
entidad "Tipo de Habitación" como 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
}
entidad "Reserva" como 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) <>
}
entidad "Pago" como 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)
}
entidad "Factura" como 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)
}
entidad "Personal" como 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
}
entidad "Servicio de Habitación" como 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)
}
' Relaciones
customer ||--o{ reservation : "realiza"
room ||--o{ reservation : "asignada a"
reservation ||--|| payment : "tiene"
reservation ||--|| invoice : "genera"
reservation ||--o{ roomservice : "solicita"
staff ||--o{ roomservice : "cumple"
roomtype ||--o{ room : "categoriza"
@enduml
Construir modelos de bases de datos complejos no tiene por qué significar lidiar con interfaces de usuario incómodas y arrastrar y soltar. Al aprovechar un enfoque de diagramas como código, tu arquitectura permanece controlada por versiones, limpia y fácil de mantener.
¿Listo para probar la creación de tus propias arquitecturas de sistemas? Dirígete a VPasCode para experimentar con renderizado en tiempo real, detección automática de formatos y exportaciones sin problemas para tu documentación técnica hoy mismo!
