Tabla eventos que se relaciona con otras tablas

[kitune]

Hola a todos,

Tengo una duda en la estructura de unas tablas.

Tengo una tabla de Eventos tipo facebook, con nombre, descripción, fecha inicio, fecha fin, etc.

Luego tengo otras tablas Academias, Locales y Usuarios. Cada uno de estos grupos pueden crear eventos, una academia puede hacerlo en su nombre o un usuario también.

La duda que tengo es como relacionar quien ha creado un determinado evento. Se me ocurre que hayan 2 columnas en la tabla Eventos: tipo_creador, id_creador. Donde tipo_creador identificará si es una academia, local, etc. Y el id_creador lo que indica su propio nombre. Me parece un poco de ir por casa esa solución, no sé si hay alguna mejor.

Gracias.

[gnzsoloyo]

La solución pasa un poco por analizar una parte del problema: Los usuarios.
En realidad, si lo piensas, no tienes Usuarios y Academias como entidades que pueden usar tu sistema. Lo que tienes son usuarios que pueden ser Personas o Academias (decir Instituciones sería mejor). Esto significa que tienes tres tabla: Usuarios (Entidad padre), Personas (Entidad hija) y Academias (Entidad hija), tal que las dos hijas heredan su PK de la entidad padre. Eso se denomina herencia, y es una extensión al modelo E-R.
En esa forma, el Evento en realidad está relacionado con Usuario, y por su PK, puedes discriminar si es una Academia o una Persona.
¿Se entiende?
Lo que puedes agregar, por razones de necesidad para la aplicación, es en la entidad Usuario un campo de categoría que permita discriminar sin es Academia o Persona, cosa de simplificar luego la implementación de las búsquedas, y no tener que hacer consultas con UNION para buscar una entidad dada.

[kitune]

Iniciado por gnzsoloyo

La solución pasa un poco por analizar una parte del problema: Los usuarios.
En realidad, si lo piensas, no tienes Usuarios y Academias como entidades que pueden usar tu sistema. Lo que tienes son usuarios que pueden ser Personas o Academias (decir Instituciones sería mejor). Esto significa que tienes tres tabla: Usuarios (Entidad padre), Personas (Entidad hija) y Academias (Entidad hija), tal que las dos hijas heredan su PK de la entidad padre. Eso se denomina herencia, y es una extensión al modelo E-R.
En esa forma, el Evento en realidad está relacionado con Usuario, y por su PK, puedes discriminar si es una Academia o una Persona.
¿Se entiende?
Lo que puedes agregar, por razones de necesidad para la aplicación, es en la entidad Usuario un campo de categoría que permita discriminar sin es Academia o Persona, cosa de simplificar luego la implementación de las búsquedas, y no tener que hacer consultas con UNION para buscar una entidad dada.

Si he entendido bien ¿dices de crear una tabla usuarios y poner un campo de categoria para ver saber si el tipo usuario es persona, academia, tienda o local?

En ese caso no tendría el problema para relacionar un evento pero hay muchos campos que tiene una academia que no tiene una tienda, o un local que no tiene una persona, etc..

Y luego está el tema de las búsquedas, si tengo todo en una misma tabla es más costoso creo yo.

[gnzsoloyo]

En ese caso no tendría el problema para relacionar un evento pero hay muchos campos que tiene una academia que no tiene una tienda, o un local que no tiene una persona, etc..

¿Y para qué crees que se crean las herencias?
Precisamente para poner en la entidad padre todos los atributos comunes a ambas (user_id, password, fecha_alta, fecha_baja, dirección, CUIT o RUT según el país, tipo de documento, etc.), mientras que todo el resto va en la tabla hija.

Y luego está el tema de las búsquedas, si tengo todo en una misma tabla es más costoso creo yo.

No necesariamente. El costo de la consultas se calcula de otras formas, y por otro lado nadie n su sano juicio us el SELECT * en una consulta optimizada, por lo que ese caso en una aplicación bien diseñada no existe.
Además, no estoy diciendo que pongas todo en una tabla, sino que pongas en cada una de las hijas los atributos que le pertenecen.
Te recomiendo leer de POO y el modelo E-R extendido.

[kitune]

Iniciado por gnzsoloyo

¿Y para qué crees que se crean las herencias?
Precisamente para poner en la entidad padre todos los atributos comunes a ambas (user_id, password, fecha_alta, fecha_baja, dirección, CUIT o RUT según el país, tipo de documento, etc.), mientras que todo el resto va en la tabla hija.

Ok, pero en mi caso (a no ser que lo haya entendido mal) no hay un usuario y contraseña que identifique una academia o local. Sería un único usuario que crea cuantas academias o locales quiera.

Pensé en tener la tabla usuarios y luego otra de "empresas" y que locales, tiendas y academias estén en esa tabla. Pero eso me crea otra vez el problema de 2 o más tablas relacionadas con la de eventos.

Iniciado por gnzsoloyo

No necesariamente. El costo de la consultas se calcula de otras formas, y por otro lado nadie n su sano juicio us el SELECT * en una consulta optimizada, por lo que ese caso en una aplicación bien diseñada no existe.
Además, no estoy diciendo que pongas todo en una tabla, sino que pongas en cada una de las hijas los atributos que le pertenecen.
Te recomiendo leer de POO y el modelo E-R extendido.

Si, la verdad es que voy un poco justo de la parte teórica.

[gnzsoloyo]

Ok, pero en mi caso (a no ser que lo haya entendido mal) no hay un usuario y contraseña que identifique una academia o local. Sería un único usuario que crea cuantas academias o locales quiera.

Pensé en tener la tabla usuarios y luego otra de "empresas" y que locales, tiendas y academias estén en esa tabla. Pero eso me crea otra vez el problema de 2 o más tablas relacionadas con la de eventos.

Pues en ese caso los Usuarios componen una sola tabla, y las Academias, son el sitio donde se desarrolla el evento, pero no son quienes lo organizan, porque el responsable de dar el alta en ambos casos es el Usuario.
Entonces, las Academias dependen del usuario, y en el Evento van ambas FK: Usuario y Academia. Pero el "dueño" del evento y su responsable, sigue siendo el Usuario.

¿Se entiende la lógica aplicada en este análisis?

Como no puede haber un Evento sin lugar y usuario, esa tabla depende de ambas cosas al mismo tiempo. Pero la Academia no puede existir sin Usuario, así que toda la dependencia nace en él.
Esa es la entidad fuerte y de donde surge toda esa cadena.
La única excepcion sería si el usuario puede organizar eventos sin academias. En ese caso Evento tendría a su vez otro nivel de relaciones, y por ende más tablas.
Peor el esquema base (esas tres) permanecería estable. cuando mucho se agregan.

[kitune]

Iniciado por gnzsoloyo

Pues en ese caso los Usuarios componen una sola tabla, y las Academias, son el sitio donde se desarrolla el evento, pero no son quienes lo organizan, porque el responsable de dar el alta en ambos casos es el Usuario.
Entonces, las Academias dependen del usuario, y en el Evento van ambas FK: Usuario y Academia. Pero el "dueño" del evento y su responsable, sigue siendo el Usuario.

¿Se entiende la lógica aplicada en este análisis?.

Ok, entonces en la tabla eventos hay 2 FK para el usuario y para la empresa (academia, local, tienda...) que me dicen que usuario ha creado el evento y donde se realiza (aunque no es del todo correcto, puede que una academia organice un evento pero sea en otro lugar).

¿Entonces para hacer una consulta del tipo "Muestra todos los eventos para la academia con id=36" tengo que unir 3 tablas? porque con la de academias y la de eventos no tengo forma de saberlo.

Iniciado por gnzsoloyo

Como no puede haber un Evento sin lugar y usuario, esa tabla depende de ambas cosas al mismo tiempo. Pero la Academia no puede existir sin Usuario, así que toda la dependencia nace en él.
Esa es la entidad fuerte y de donde surge toda esa cadena.
La única excepcion sería si el usuario puede organizar eventos sin academias. En ese caso Evento tendría a su vez otro nivel de relaciones, y por ende más tablas.
Peor el esquema base (esas tres) permanecería estable. cuando mucho se agregan.

Pues el caso es que si sería ese caso.. Yo como usuario de la red social puedo crear eventos independientes, puedo crear academias, puedo crear locales, puedo crear tiendas y también puedo crear eventos asociados a alguna de las empresas que he dado de alta yo antes.

Por cierto, gracias por las respuestas.

[gnzsoloyo]

puede que una academia organice un evento pero sea en otro lugar

En ese caso el evento debería, por definición del modelo E-R contar con una relación opcional que registro la localización del evento.
Como esta relación es opcional, esto se puede resolver agregando un flag que indique que el lugar es o no el sitio de la academia, y es FALSE, que busque en otra tabla la dirección del evento.
Como te dije, un diseño detallado puede requerir relaciones que a simple vista no son perceptibles.
Lo que tienes que tener claro es que ningún cambio o detalle puede quedar fuera de un modelado de E-R. Donde fuerces el pardigma, empezarás a tener serios dolores de cabeza.

¿Entonces para hacer una consulta del tipo "Muestra todos los eventos para la academia con id=36" tengo que unir 3 tablas? porque con la de academias y la de eventos no tengo forma de saberlo.

Exacto.
Ese es el precio de un modelado optimizado. Y si tres tablas tablas te parecen mucho, te advierto que he visto consultas que cruzan 16 tablas sólo en el FROM, sin contar con las que se ponen en subconsultas del WHERE, o validaciones de funciones almacenadas.
La ventaja es que todas esas cosas hacen que las consultas se aceleren gracias a los recursos de los DBMS que resuelven los planes de consulta para estos detalles.

puedo crear academias, puedo crear locales, puedo crear tiendas y también puedo crear eventos asociados a alguna de las empresas que he dado de alta yo ante

Cuando te topas con casos como ese, conviene que analices cuidadosamente los atributos de cada entidad, para ver si se los puede englobar en una sola categorizada, o bien se requiere crear un árbol de herencias y relacionar los eventos a una tabla padre.
Todo dependerá de aquellos atributos que sean esenciales.
Si la diferencia entre cada uno de esos elementos es sólo de uno o más datos, que no sean obligatorios o trascendentes, se pueden agregar tablas de "observaciones" o cosas así, donde se los relacione con esa entidad y luego se obtengan encadenados. Como las tablas de Tags.

[kitune]

Iniciado por gnzsoloyo

En ese caso el evento debería, por definición del modelo E-R contar con una relación opcional que registro la localización del evento.
Como esta relación es opcional, esto se puede resolver agregando un flag que indique que el lugar es o no el sitio de la academia, y es FALSE, que busque en otra tabla la dirección del evento.
Como te dije, un diseño detallado puede requerir relaciones que a simple vista no son perceptibles.
Lo que tienes que tener claro es que ningún cambio o detalle puede quedar fuera de un modelado de E-R. Donde fuerces el pardigma, empezarás a tener serios dolores de cabeza.
Exacto.
Ese es el precio de un modelado optimizado. Y si tres tablas tablas te parecen mucho, te advierto que he visto consultas que cruzan 16 tablas sólo en el FROM, sin contar con las que se ponen en subconsultas del WHERE, o validaciones de funciones almacenadas.
La ventaja es que todas esas cosas hacen que las consultas se aceleren gracias a los recursos de los DBMS que resuelven los planes de consulta para estos detalles.
Cuando te topas con casos como ese, conviene que analices cuidadosamente los atributos de cada entidad, para ver si se los puede englobar en una sola categorizada, o bien se requiere crear un árbol de herencias y relacionar los eventos a una tabla padre.
Todo dependerá de aquellos atributos que sean esenciales.
Si la diferencia entre cada uno de esos elementos es sólo de uno o más datos, que no sean obligatorios o trascendentes, se pueden agregar tablas de "observaciones" o cosas así, donde se los relacione con esa entidad y luego se obtengan encadenados. Como las tablas de Tags.

Hola de nuevo, voy a hacer caso de tus recomendaciones y ver si puedo unir en una tabla de "empresas" a todos los tipos de locales, academias y tiendas con la información común entre ellas como pueda ser nombre, telefonos, direccion, email, etc.

Para las cosas que sean específicas de cada tipo ¿cual puede ser la mejor forma?

Pongo un ejemplo, las tiendas podrán subir a su ficha 5 productos destacados de su catálogo. Cosa que no pueden hacer academias ni locales.

Voy a crear una tabla de productos, con el id_empresa asociado a cada tienda. ¿Es necesario hacer algo más?

Un saludo y gracias por toda la ayuda.