MySQL WorkBench Modelo Entidad-Relacion

FoxWinterMan

Buenas tardes,

Tengo que realizar una base de datos de una gestion hotelera, y tengo mas bien nula experiencia realizando modelos y estoy sufriendo una parafernalia para darle sentido a esto.

En principio tengo 5 entidades que son :
Habitacion: PK VARCHAR(4)
Clientes: PK DNI VARCHAR(12)
Servicios : PK VARCHAR(4) -> Servicios de garaje, de consumo de bebidas, etc etc...

Bueno el hotel evidentemente realiza Aperturas que contienen los siguientes datos:

Datos del cliente que realiza la apertura.

Datos de las habitaciones contratadas: pudiendo ser 1 o mas. Cada habitacion tiene fecha de llegada y fecha de salida.

Datos de los servicios contratados: pudiendo ser 0 o mas.

Las aperturas una vez finalizadas tienen una factura que tiene pues simplemente las habitaciones contratadas los servicios contratados la fecha de la factura los datos del cliente y el total a pagar.

Alguien me puede echar una mano con las relaciones que hay? No entiendo bien como funcionan para que luego se pueda realizar consultas de facturas por cliente, por fechas, consultas de habitaciones libres y ocupadas.

Las foreign_key que se usan tampoco me quedan claras, porque veo que todas mis relaciones llegan a que mucho es mucho y eso tiene que ser incorrecto si o si, o esa impresion me da.

Muchas gracias.

eXtreM3

1 cliente paga N habitaciones.
t_cliente_habitacion: id, dniCliente, idHabitacion, fechaEntrada, fechaSalida, ...

1 cliente paga por N servicios.
t_cliente_servicio: id, dniCliente, idServicio, ...

Y ya está. Puedes añadir un campo 'ocupada' a la tabla Habitacion y ponerle valores 0 ó 1 según esté libre o no.

1 respuesta
Daredevil

Veo que estás bastante perdido...

Primero debes saber hacer el modelo E/R y claramente no es así ya que hablas de que no puede haber relaciones N:N (muchos a muchos cómo le has llamado tú) y claro que puede haberlas.

Sin una comprensión clara de este modelo no sabes por qué una clave es foránea o no, porque ni siquiera sabes construir una tabla como la de #2 a partir de este primero.

Un saludo.

1 1 respuesta
Soltrac

Si te digo que nuestro módulo de hotel tiene 32 tablas en forma normal, y no es un software completo, solo un módulo xDDDDD

1 1 respuesta
CrIpI

#3 Creo que a lo que el se refiere de que no puede haber una relacion N:N es porque tiene que haber una tabla intermedia no?

JuAn4k4

Mi recomendación es que utilices un int / bigint en auto_increment para las PK.

Hotel > 1:N > Habitacion
Cliente > 1:N > Apertura
Apertura > 1:N > Servicio
Apertura > 1:N > Habitacion
Hotel > 1:N > Aperturas

Date cuenta que una Apertura puede tener un servicio de parking cuyas fechas no sean las mismas que las fechas de la habitación (por ejemplo contrato el parking los 3 primeros dias de estancia).

Apertura >1:N> Servicio (fechas,etc) > 1:1 > TipoServicio

Hotel (id, nombre, direccion, ...)
Habitacion (id, nombre, hotel_id, ...)
Cliente (id, dni, nombre, ...)
TipoServicio (id, nombre, descripcion, ...)

Apertura (id, id_cliente, id_hotel, fecha_reserva, fecha_inicio, fecha_fin )
Servicio (id, id_apertura, fecha_inicio, fecha_fin)

Algo así haria yo, de todas formas el parking tendrá plazas limitadas, igual que las habitaciones, lo mismo para muchos otros servicios. Esto es algo asi como gestión de recursos (reservas y demás), pero bueno como imagino que será para algun ejercicio de clase....

2 respuestas
eXtreM3

#6 yo creo que dado el grado de profundidad de su pregunta, no hace falta desarrollar tanto el modelo.

La tabla servicios que tenga los nombres de los servicios que oferta el hotel y fuera, un cliente los contrata o no.

Es que si te pones a mezclar TODO lo que un hotel puede tener con unos HORARIOS... eso no se hace en 10 minutos xD

Kiroushi

#6 Un bigint para el PK? Buena suerte con eso. Un int unsigned son 2147483647 valores.

Si crees que vas a tener más de ese número de filas empieza a buscar otro tipo de solución, porque MySQL no es lo que necesitas.

Espero que los que dais ese tipo de consejos no os dediquéis a esto profesionalmente.

1 respuesta
FoxWinterMan

Muchas gracia a todos sobre todo a #4 que me ha abierto bastante los ojos.
Yo no necesito 5 tablas sino como unas 25. Aqui va un resumen mental que tengo y a ver si aprendo a usar el WorkBench.

Tipo_ID --> Tabla que tiene los distintos tipos de documento de identifiacion 1 DNI 2 NIF 3 PASAPORTE etc..

Clientes --> ID_Cliente ( PK AI ) relacion con Tipo_ID. Los atributos son DNI ( PK), tipo_documento, nombre, telefono, cif empresa, direccion empresa etc...

Servicios --> ID_Servicios ( PK AI ), Tipo_Servicio, Tarifa_General y Tarifa_Especial.

ID_Hab --> Como muchas de las categorías se repiten decidi crear una tabla para esto con los siguientes datos: Num_Hab ( PK AI) ID_TIPO.

Habitaciones --> idHabitacion ( PK AI), ID_TIPO ( relacion a la tabla ID_Hab ) Descripcion, Tarifa_General y Tarifa_Especial.

Aperturas --> id_Apertura (PK AI) DNI_Cliente ( PK ), Nombre_Cliente, Fecha_Apertura, Personas_a_hospedar, Numero_Habitaciones.

Y ahora es cuando empieza lo que más me lía:

Cada apertura tendrá una tabla para las habitaciones ( 1 o ++), donde estará relacionado con el id_Apertura y contendrá las habitaciones seleccionadas por el cliente con su fecha de llegada y fecha de salida de cada habitación y el montante total de las habitaciones.

Lo mismo para los servicios, relacionado con el id_Apertura y contendrá todos los servicios que el cliente desee ( 0 o ++), aqui veo el problema de que no se como hacer que un Servicio se agrege a una habitación en particular y el precio de todos los servicios contratados.

Habrá una tabla que va a ser Aperturas_Actuales donde vendrá la información de los huespedes actuales con su fecha de apertura, id_apertura, fecha de entrada y salida del cliente del hotel, en esta tabla es donde se modificará las aperturas, por ejemplo si para la apertura del cliente 87623489J quiera quedarse en la habitacion 12 dos días más se pueda gestionar desde aqui.

Estado_HAN --> Estado de todas las habitaciones : Libre/Ocupada. Me gustaría que en esta tabla si está Libre solo salga id_Hab y estado libre, pero en caso de que Ocupada salga el nombre y dni de quien este ocupandola y fecha desde hasta ocupacion.

******************FACTURACION**********************

El cliente puede abonar en cualquier momento el dinero que debe, con lo cual he pensado en 2 soluciones:
1º) Que las facturas no se puedan modificar, de manera que si el cliente abona el total de la apertura se genere la factura, se imprima y se almacene, de manera que si la apertura se vea modificada saque la factura solamente con los nuevos conceptos contratados.

2º) Que cada apertura solamente tenga 1 factura, de manera que si el cliente abona la apertura y despues la modifica, se cree otra factura nueva solamente con los conceptos nuevos relacionados con la misma apertura.

Habrá una tabla de consultas donde mediante el DNI de los clientes se pueda acceder a su historial de aperturas con la facturacion total hecha.

Otra tabla contendra el historico de las ganancias por habitacion mostrando por cada habitacion el dinero obtenido y el total de aperturas realizadas.

De la misma manera habra una tabla practicamente identica con los servicios.

2 respuestas
eXtreM3

Madre del amor hermoso, viendo #1 y viendo #9 ... buena suerte...

JuAn4k4

#8 Ya bueno... pues que ponga usnigned int, el consejo era que no usara el DNI como pk.

#9 Llevas un lio de cojones, los nombres de las tablas que quieres crear te dan una pista.

Solo compara los nombres de estas tablas:

"Tipo_ID", "Estado_HAN", "ID_Hab"

Con estas:

"Clientes", "Servicios", "Habitaciones"

Te tiene que quedar clara una cosa que ahora mismo no tienes :

Una cosa es los datos que guardas y otra muy distinta como los muestras después.

Es decir, no necesitas una tabla para guardar "aperturas_actuales", ni el estado de la habitación.

Las aperturas actuales son las "Aperturas" que tienen una fecha de inicio <= hoy y una fecha de final > hoy, es decir, han empezado pero no han acabado.

El estado de una habitación depende de la fecha, si es para "hoy", será "ocupada" si hay un servicio de habitación que empiece <= hoy y acabe > hoy.

Y después, no vas a necesitar los "TIPO_ID", serán los 3 o 4 que soportes tu, DNI, NIE, Pasaporte, y si acaso "Otro", es decir : Cliente [ id, dni, tipo_documento, ...]

Mucha suerte...

Usuarios habituales

  • JuAn4k4
  • eXtreM3
  • FoxWinterMan
  • Kiroushi
  • CrIpI
  • Soltrac
  • Daredevil