Al diseñar arquitecturas de bases de datos robustas para dominios complejos como la hostelería, visualizar las relaciones con claridad es fundamental. Ya sea que esté mapeando perfiles de clientes, rastreando inventarios de habitaciones o gestionando facturación, un diagrama de entidad-relación (ERD) bien estructurado ahorra innumerables horas durante el desarrollo. En esta clase magistral, le guiaré sobre cómo construí un diagrama ERD integral de gestión hotelera desde cero utilizando PlantUML dentro del editor gratuito de PlantUML, VPasCode.
1. Inicialización del entorno de PlantUML
Comienzo configurando la estructura fundamental del script. Al trabajar con esquemas complejos que contienen numerosos atributos, la legibilidad del diseño es primordial. Configuro PlantUML para ocultar el desorden innecesario y optimizar la dirección del diseño del diagrama:
@startuml
título: Diagrama ERD de Gestión Hotelera
hide circle
dirección de izquierda a derecha
¿Por qué este enfoque? Ocultar los círculos de atributos predeterminados mantiene las cajas de entidad limpias y modernas. Establecer la dirección en dirección de izquierda a derecha ayuda a evitar que los diagramas ERD anchos se vuelvan verticalmente inmanejables, distribuyendo lógicamente las relaciones entre múltiples tablas.
2. Definición de entidades y atributos centrales
A continuación, necesito definir las entidades centrales que representan nuestro dominio empresarial. Estructuro cada entidad con sus claves primarias, restricciones únicas y atributos tipados. Veamos cómo configuré las entidades centrales Cliente y Tipo de Habitación entidades:
entity "Cliente" as 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)
}
entity "Tipo de Habitación" as 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 instantáneamente las reglas de indexación y unicidad antes incluso de que se escriban los scripts de migración de la base de datos.
3. Mapeo de entidades operativas (Habitaciones, Reservas y Personal)
Con nuestros datos de referencia establecidos, paso al núcleo transaccional del sistema de gestión hotelera: habitaciones, reservas y flujos de trabajo del personal. Cada entidad se vincula a nuestras tablas fundamentales utilizando claves foráneas:
entity "Habitación" as 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
}
entity "Reserva" as 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. Establecimiento de relaciones financieras y de servicio
Para finalizar la arquitectura, mapeo los registros de facturación (Pagos e Facturas) junto con servicios auxiliares como el servicio de habitaciones gestionado por el personal del hotel. Para conectar 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: El uso de notación precisa de ‘pie de cuervo’ (como “||--o{ para relaciones uno a muchos de obligatorias a opcionales) garantiza que las reglas de lógica de negocio, como que una reserva requiera un cliente, pero que un cliente pueda tener múltiples o cero reservas activas, se modelen con precisión.
El script completo de PlantUML
Aquí tienes el código fuente completo y ensamblado para nuestro diagrama entidad-relación (ERD) de gestión hotelera. 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 Diagrama Entidad-Relación de Gestión Hotelera
hide circle
direction left to right
' Definir entidades con atributos
entity "Cliente" 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 "Habitación" 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 "Tipo de Habitación" 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 "Reserva" 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 "Pago" 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 "Factura" 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 "Personal" 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 "Servicio de Habitación" 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)
}
' 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
Crear modelos de bases de datos complejos no tiene por qué significar luchar con interfaces de usuario de arrastrar y soltar torpes. Al aprovechar un enfoque de diagramas como código, tu arquitectura permanece controlada por versiones, limpia y fácilmente mantenible.
¿Listo para intentar construir tus propias arquitecturas de sistemas? Dirígete a VPasCode para experimentar el renderizado en tiempo real, la detección automática de formato y las exportaciones sin fisuras para tu documentación técnica hoy mismo!