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