Cita: No se que tal lo he hecho. Tengo algunas dudas acerca de esto. En primer lugar:
Cita:
Iniciado por gnzsoloyo Ver Mensaje
Cita: - No hay relación directa entre un usuario y una actividad, porque un usuario se inscribe en la comisión, no en la actividad, ya que es la comisión la que debe ser de una actividad (cuestiones conceptuales).
No entiendo esto. Si una actividad puede tener una o mas comisiones, y una comision solo puede tener un horario, por qué no decir directamente que una actividad puede tener uno o mas horarios, y eliminar el paso intermedio? Crearía la tabla ACTIVIDAD_HORARIO para relacionar los dos elementos igual que creo la de USUARIO_ACTIVIDAD, pero sin necesidad de añadir un elemento más. Siempre considerando que, como tu dices, un usuario se "inscribe" en un horario, no en una actividad. Es correcto?
Son cuestiones un poco conceptuales, que se vuelven visibles a medida que te adentras en el tema del diseño de bases de datos.
Tienen que ver con los verbos que usas para determinar las relaciones; de allí surge más claridad de por qué los DBA Developer construyen las tablas como lo hacen. Digamos así:
Cuando dices "es de" o "pertenece a", estás estableciendo una relación directa entre dos entidades, muy probablemente 1:1 o 1:N; pero cuando dices "tiene" o "puede tener", es una relación N:N (el "debe tener" indica solamente que la relación tiene en uno de sus extremos una cardinalidad 1:N, es decir, debe haber por lo menos un caso que relacione una tabla con la otra; para el caso,
para dar de alta una comisión debe haber por lo menos un usuario).
Eso te puede ayudar a determinar las cardinalidades de las relaciones.
Ahora bien, el descubrir algunas relaciones que son un poco abstractas requiere un poco más de pensamiento orientado a objetos. Lo que debes descubrir es donde se producen los puntos de unión, y si esos puntos de unión conforman entidades con identidad propia o son parte de otra. El hecho de que sean parte de otra es relativamente fácil de ver: ¿Puede existir esa entidad sin los atributos que están en otra? Si la respuesta es sí, es otra entidad. Si la respuesta es no, estás viendo atributos de una entidad (caso excepcional: jerarquías, ves una subentidad de otra superior).
Veamos un ejemplo como el tuyo:
Un usuario
realiza actividades, no las
tiene. No las tiene porque no son parte de su identidad de usuario, ni tampoco son obligatorias en el sistema. Si las realiza, debe haber un punto donde se determine qué actividades realiza. Esto se puede ver en que
un usuario no tiene una actividad, y una actividad no es de un usuario.
Una comisión, por otra parte, no pertenece a una actividad, sino en todo caso a la facultad, la escuela, el instituto, o lo que sea que forme una parte de la organización, ya que es la organización lo que le da existencia. Pero parte de su identidad está dado por la actividad. Es una comisión
de una actividad. Por lo tanto, está relacionada con la actividad.
En este modelo, entonces el usuario puede realizar una actividad, pero la actividad se realiza por medio de comisiones. Luego, una comisión
tiene usuarios que se inscriben en ella para realizar la actividad.
Como se puede ver, la relación entre los usuarios y la actividad está en realidad gestionada por una tabla que es COMISION_USUARIO.
¿Dónde queda entonces Horario...?
Bueno, en este modelo básicamente hay dos formas de gestionarlo: o hacer una tabla COMISION_HORARIO que contenga la relación, o, mejor aún, hacer una tabla HORARIO que gestione las comisiones creadas con período de vigencia (inicio Y fin), y manejar el reparto de la grilla de horarios dinámicamente en la aplicación... cosa que es la forma en que muchas universidades manejan, porque en definitiva la superposición horaria en sistemas de cursos que no son prefijados, se manejan por usuario (alumno) y no por cursada...
¿Se va comprendiendo la lógica?