User Tag List

Resultados 1 al 8 de 8

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

  1. #1

    Fecha de ingreso
    Sep 2009
    Ubicación
    Donde quiero
    Mensajes
    5,530
    Mencionado
    152 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,512
    Agradecer Thanks Received 
    1,771
    Thanked in
    Agradecido 1,024 veces en [ARG:2 UNDEFINED] posts

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

    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:



    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...



    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...



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

    Alguna idea gepera?

  2. #2

    Fecha de ingreso
    Jun 2006
    Mensajes
    4,531
    Mencionado
    40 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,200
    Agradecer Thanks Received 
    647
    Thanked in
    Agradecido 397 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    6
    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.
    _
    .▲ ALABADO SEA EL TRI-FORCEPS!

    Nunca me he considerado de clase media. Soy más bien de clase calcetín roñoso.

  3. #3

    Fecha de ingreso
    Sep 2009
    Ubicación
    Donde quiero
    Mensajes
    5,530
    Mencionado
    152 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,512
    Agradecer Thanks Received 
    1,771
    Thanked in
    Agradecido 1,024 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por akualung Ver mensaje
    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.

  4. El siguiente usuario agradece a selecter25 este mensaje:

    akualung (17/10/2021)

  5. #4

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    6,308
    Mencionado
    38 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,099
    Agradecer Thanks Received 
    1,163
    Thanked in
    Agradecido 809 veces en [ARG:2 UNDEFINED] posts
    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.
    Última edición por swapd0; 17/10/2021 a las 16:50
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  6. #5

    Fecha de ingreso
    Sep 2009
    Ubicación
    Donde quiero
    Mensajes
    5,530
    Mencionado
    152 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,512
    Agradecer Thanks Received 
    1,771
    Thanked in
    Agradecido 1,024 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    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!

  7. #6

    Fecha de ingreso
    Sep 2005
    Mensajes
    12,985
    Mencionado
    206 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    385
    Agradecer Thanks Received 
    917
    Thanked in
    Agradecido 655 veces en [ARG:2 UNDEFINED] posts
    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.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  8. #7

    Fecha de ingreso
    Sep 2009
    Ubicación
    Donde quiero
    Mensajes
    5,530
    Mencionado
    152 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,512
    Agradecer Thanks Received 
    1,771
    Thanked in
    Agradecido 1,024 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    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é.

  9. #8

    Fecha de ingreso
    Sep 2005
    Mensajes
    12,985
    Mencionado
    206 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    385
    Agradecer Thanks Received 
    917
    Thanked in
    Agradecido 655 veces en [ARG:2 UNDEFINED] posts
    Así que eres un perturbado

    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 ) y por eso quiero ver cómo se hacen las cosas.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •