Bases de Datos - Duda con los atributos en una tabla de asociación

   
Vista:

Duda con los atributos en una tabla de asociación

Publicado por José Manuel (3 intervenciones) el 14/05/2016 19:07:27
BBDD-eventos

Muy buenas a tod@s,

Tengo una duda con el mapeo con hibernate h2 y creación de atributos en una miniaplicación de gestión de eventos en la que los usuarios pueden inscribirse, realizar pagos, crear eventos, etc. Tengo la certeza de que el esquema es correcto, lo que no tengo muy claro son los atributos que irían en cada tabla, por ejemplo la lista de eventos viene de la relación de 1 a 1..* entre la clase usuario y la clase evento, luego en la relación de 1..* a 1..*, obligatoriamente surge al tabla ''Asiste'', con la información de los pagos de los usuarios a los eventos, el problema son sus atributos y el mapeo, me explico, llevaría a parte de ''idUsuario'' e ''IdEvento'' algún atributo más?, como un List, o Map?

Espero que alguien pueda resolverme la duda, gracias de antemano
Valora esta pregunta
Me gusta: Está pregunta es útil y esta claraNo me gusta: Está pregunta no esta clara o no es útil
0
Responder

Duda con los atributos en una tabla de asociación

Publicado por Gonzalo (16 intervenciones) el 15/05/2016 14:23:25
llevaría a parte de ''idUsuario'' e ''IdEvento'' algún atributo más?

Bueno, más allá de que Hibernate NO ES un DBMS, sino un ORM, y que aún como ORM debe cumplir con las restricciones necesarias de los datos, para encontrar las respuestas deberías plantearte ciertas preguntas:
- ¿Puede el mismo usuario asistir a un mismo Evento más de una vez en diferentes instancias cronológicas?
- Si puede asistir N veces a un Evento, ¿Qué diferencia la instancia Evento de las restantes?
Esto para empezar.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
1
Comentar

Duda con los atributos en una tabla de asociación

Publicado por José Manuel (3 intervenciones) el 15/05/2016 19:14:16
gestion.eventos

Muchas gracias por tu respuesta,

Aquí tengo las tablas con todos los atributos, lo que ocurre es que cualquier usuario puede crear, asistir, inscribirse, etc. a muchos eventos, pero si quiere asistir al mismo evento otra vez en otra fecha distinta, tendrá que cambiar la fecha y podrá seguir asistiendo a ese evento o bien crear otro.

Por otra parte hay un usuario administrador al que he puesto como boolean para no crear otra clase con los mismos atributos, este usuario puede además, tener privilegios para eliminar usuarios o agregarlos él mismo.
En cuanto a tu segunda pregunta no la entiendo muy bien, no sé qué quieres decir con: ''¿Qué diferencia la instancia Evento de las restantes?''

El caso es que si según la teoría de las tablas y basándome en lo que quiero que cumpla la aplicación, en la relación de 1 a 1..* de Usuario hay un List<Evento> y ahí me quedo, por lo que no sé si en la tabla Evento ha de haber un Usuario y luego en la tabla Asiste ya no sé qué más poner. Por lo que he leído en la teoría en la tabla Asiste debe haber una clase embebida dentro de otra con los atributos correspondientes y las claves primarias de ambas tablas etiquetadas a @ManyToOne, cada id apuntando a una tabla.

Pero me da en la nariz que me dejo algún atributo que recoja las dos tablas o alguna lista dentro de Asiste.
Espero que se vea más claro en este esquema.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Duda con los atributos en una tabla de asociación

Publicado por Gonzalo (16 intervenciones) el 16/05/2016 15:29:53
Bueno, esto va a ser un poco complicado...

Por empezar: Cuando miras la BBDD no estás mirando el modelo de clases, estas viendo el modelo físico, y el modelo físico d e datos NO ES un reflejo idéntico del de clases. Eso es lo primero que debes comprender.

El modelo de clases acepta asociaciones y agregaciones. Pero el modelo físico de una BBDD no tiene agregaciones, Sólo posee relaciones, y estas relaciones deben cumplir con restricciones del modelo relacional, tales como la no replicación de datos, la unicidad de registros y la normalización de las tablas.

En un esquema como el que tienes en esas tres clases, y de acuerdo a lo que describes, debemos entender que:
1) Existen usuarios, los cuales pueden estar en más de una categoría.
2) Hay al menos dos categorías diferentes, pero sus atributos son iguales.
3) Existen Eventos, los cuales deben ser creados por algún usuario.
4) Cada evento debe tener una fecha de creación, inicio y finalizacion, también debe tener nombre, descripción y precio.
5) Un mismo evento puede tener diferentes fechas de ocurrencia, es decir el mismo evento puede repetirse N veces, pero en fechas difernentes.
6) Cada evento tiene asistentes que deben registrarse. El registro es único para una única celebración de tal evento.
7) Cada evento tiene asistencia, la cual debe ser registrada para cada asistente.
8) Cada usuario que asiste debe inscribirse en el evento para ser admitido. La inscripción y asistencia será abonada por algún medio de pago habilitado, del que se registrará, según el caso, entidad de pago habilitada.
9) Un usuario puede inscribirse en el mismo evento N veces, pero cada inscripción debe ser única para la misma ocurrencia del mismo evento.

AL menos estás reglas de negocio tiene que cumplir ese esquema de BBDD.

Ahora bien, sin entrar en demasiados detalles, puedo decirte que aunque tu puedas crear tres clases para administrar el sistema a nivel aplicación, yo aquí estoy viendo alrededor de cinco o seis tablas como mínimo. Y eso ya marca una diferencia en el funcionamiento del mapeo objeto-relacional.

Desde el punto de vista del esquema de BBDD, tienes al menos: Usuario, CategoriaUsuario, Evento, usuario_evento, evento_usuario_pago y medio_pago.

Es lo mínimo necesario para construir un esquema relacional consistente que pueda alimentar tus clases. De lo contrario se generarán redundancias nocivas e inconsistencias de datos.

Tal vez no hayas jamás escuchado esto, pero cuando piensas en estructura de datos de una BBDD, no puedes pensar como programador. La logica de datos no es la misma que la de procesos.

Son visiones diferentes del mismo sistema.

Nota: Si quieres puedes crear las tablas como tienes las clases, pero eso implicará programación adicional para controlar cosas que la BBDD ya te debería proporcionar consistentes, cuando la creas del modo correcto como BBDD relacional.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
1
Comentar

Duda con los atributos en una tabla de asociación

Publicado por José Manuel (3 intervenciones) el 16/05/2016 20:29:31
Muchísimas gracias de nuevo por tu explicación Gonzalo,

Se nota que tienes buenos conocimientos sobre el tema, yo aún estoy empezando con esto de Java y BBDD y como me han puesto un proyecto para el día 22, esta semana quería tenerlo acabado. El proyecto es web con Servlet, Hibernate y Java, por lo que los profesores me han recomendado no añadir demasiadas clases al proyecto con una base de datos simple (aunque no veo que ninguna lo sea), que cumpla las funciones mínimas para que de tiempo de acabarlo, pero es cierto que esto apunta a tener más esquema ya que los trabajos que he podido ver en Internet contienen como mínimo todo lo que has mencionado, pero si me está costando el esquema y la programación de este programa, imagínate si me pongo a añadir más cosas en tan poco tiempo.

Por otra parte el profesor que días atrás estaba dejando que el personal se buscara un poco la vida buscando información, ha dejado un enlace a una página para los que tengamos este mismo tratamiento en las tablas y etiquetas con Hibernate, también la disposición de los atributos en cada clase, lo dejo aquí por si a alguien más le sirve (espero que el inglés no eche para atrás a nadie):

http://www.codejava.net/frameworks/hibernate/hibernate-many-to-many-association-with-extra-columns-in-join-table-example

No sé qué te parecerá a ti eso,

Muchas gracias de nuevo
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar