[Halluda hurgente] Programadores geperos a mí (problema de base de datos E/R)

[selecter25]

Hola pamicos, estoy dándole vueltas a una **** base de datos de modelo entidad/relación y voy loco. Seguro que para los eruditos geperos esto es un 2+2. El enunciado es este:

https://i.imgur.com/MBKLgWN.png

La parte de hotel, categoría, habitaciones la tengo más o menos encarada, el problema viene con la maldita reserva. Tal cual y como está expuesto el problema, no sé si introducir la reserva como relación o como entidad.

Si la meto como entidad...

https://i.imgur.com/ynCz27z.png

Doy por hecho que los datos del cliente figuran en la propia reserva, y que no son necesarios hasta que no se realiza una, por lo que la entidad "Cliente" se queda sin atributos y pierde todo el sentido.

Si la meto como relación...

https://i.imgur.com/K7n0PIE.png

Parece un modelo E/R más lógico pero creo que no se ajusta a lo que pide el enunciado.

Alguna idea gepera?

[akualung]

Yo creo que una reserva tiene suficiente peso para ser una entidad en sí misma. Además, así si en el futuro te piden poner un nuevo campo que sea de una reserva (yo que sé, por poner un ejemplo que se ocurre al vuelo, una promociónen que la gente que su reserva cumpla X condiciones recibe un desayuno gratis) no tengas que ir pensando en qué entidad poner ese campo nuevo.

No si te he ayudado o te he confundido más, jejeje.

[selecter25]

Yo creo que una reserva tiene suficiente peso para ser una entidad en sí misma. Además, así si en el futuro te piden poner un nuevo campo que sea de una reserva (yo que sé, por poner un ejemplo que se ocurre al vuelo, una promociónen que la gente que su reserva cumpla X condiciones recibe un desayuno gratis) no tengas que ir pensando en qué entidad poner ese campo nuevo.

No si te he ayudado o te he confundido más, jejeje.

Gracias! Me has ayudado a reafirmar algo mi elección, yo también creo que por atributos y por las exigencias en las relaciones, tiene más sentido que la reserva sea una entidad, pero necesitaba opiniones de gente pro, porque la mayoría del resto de compañeros lo han planteado como una relación.

[swapd0]

Yo tendría la reserva como entidades, pero le quitaría muchos de los datos que has puesto, creo que deberían de ir al cliente. En la reserva iría, la fecha en la que se hizo y una referencia al cliente y creo que poco mas, estoy un poco espeso.

[selecter25]

Yo tendría la reserva como entidades, pero le quitaría muchos de los datos que has puesto, creo que deberían de ir al cliente. En la reserva iría, la fecha en la que se hizo y una referencia al cliente y creo que poco mas, estoy un poco espeso.

La versión final ha quedado como propones, los datos del cliente en el cliente y la reserva con llaves foráneas del código del cliente, código de habitación y código de hotel. Gracias pamicos!

[Drumpi]

A ver, yo no soy un experto en BBDD, pero si nos atenemos al enunciado, yo también opino que los clientes deben ser una entidad aparte, con sus datos propios, sobre todo porque eso puede facilitar reservas posteriores.
Sin embargo, yo estoy usando una BBDD que usa muchos datos redundantes, y sí que metería esos datos del cliente en la reserva, pero siendo esto un ejercicio, ni te lo plantees. Además, si miramos más allá del enunciado, si alguien cancelase una reserva, ese cliente dejaría de serlo, y sus datos no deberían seguir formando parte de la BBDD, lo que le daría más sentido a que dichos datos permanezcan en la reserva.

Pero no te líes, los clientes aparte.
Por cierto, creo que se te ha olvidado la parte de las facturas asociadas a la reserva.

[selecter25]

A ver, yo no soy un experto en BBDD, pero si nos atenemos al enunciado, yo también opino que los clientes deben ser una entidad aparte, con sus datos propios, sobre todo porque eso puede facilitar reservas posteriores.
Sin embargo, yo estoy usando una BBDD que usa muchos datos redundantes, y sí que metería esos datos del cliente en la reserva, pero siendo esto un ejercicio, ni te lo plantees. Además, si miramos más allá del enunciado, si alguien cancelase una reserva, ese cliente dejaría de serlo, y sus datos no deberían seguir formando parte de la BBDD, lo que le daría más sentido a que dichos datos permanezcan en la reserva.

Pero no te líes, los clientes aparte.
Por cierto, creo que se te ha olvidado la parte de las facturas asociadas a la reserva.

Gracias drumpi. Sí, la parte de las facturas la metí finalmente, y lo que comentas es lo que más me perturbaba, el tema de los datos del cliente, ya que como dice el enunciado solo se almacenan datos de clientes que hayan realizado al menos una reserva. En ese caso, o bien caemos en redundancia de datos o bien el cliente se queda sin atributos, al estar en la reserva, y por lo tanto dejaría de ser una entidad. Al final los metí en la entidad del cliente y lo entregué.

[Drumpi]

Así que eres un perturbado :lol:

De todas formas, cuando te lo corrijan, me interesa saber cuál es la respuesta correcta.
Sobre todo, porque si al final puedes preguntarle a tu profesor/a, es importante tener en cuenta que en entornos productivos reales, almacenar datos personales de gente que no son clientes no sé si irá en contra de la Ley de Protección de Datos, y cómo se implantaría sin caer en redundancia de datos.
Obviamente, por código se puede hacer fácilmente que si se cancela la reserva, y no hay otra anterior asociada a ese cliente, se borre la entrada de la tabla de clientes... pero una cosa es lo que se puede hacer por código, y otra cómo se debe organizar la BBDD para que esté bien construida y no ser una chapuza.

A mi me dicen que miro demasiado el tema de rendimiento y eficiencia (y puede ser, me enseñaron entre micros y ensambladores :D) y por eso quiero ver cómo se hacen las cosas.

[swapd0]

bye luciham20