Diseño de una base de datos de un GYM

[gnzsoloyo]

Llegados a este punto, y viendo que te cuesta visualizar un poco el asunto, y aparentemente no usas CASE tools para diseñar tu base, sería mejor que retrocedamos unos pasos y volvamos ver el tema desde el inicio.
Hay algunas cosas que tienes que entender previamente:
- No puedes hacer un diseño de base de datos, sin tener las reglas del negocio. Sólo conseguirías chapucerías.
- No puedes determinar las reglas de negocio sin analizar el sistema.
- No puedes hacer análisis, sin relevar el sistema y conocer sus límites.

Saltándonos la última parte (que dominar te lleva al menos dos años de cursada en la universidad), podemos ir por lo menos a las reglas del negocio, ya que es allí donde las entidades y las relaciones se hacen visibles claramente.

Lo que tienes es:
- Una institución, donde participan diferentes personas y que realiza distintas actividades.
- Una persona se debe registrar en la institución para poder anotarse en las actividades, pero puede participar de los servicios sin realizar actividades.
- Para realizar una actividad debe inscribirse en ella.
- Cada coordinador de una actividad tiene un registro de participantes en la actividad, los que pueden ir variando a lo largo del año.
- Un participante puede abandonar una actividad y volver a ella una o más veces.
- Se debe registrar tanto el momento en que ingresa, como el momento en que abandona una actividad, y esa registración debe poder verificarse históricamente.
- Una persona puede tener N periodos donde abandona o continúa la actividad.
- Todo su historial de actividades con inicios y suspensiones se debe conservar para usos contables y administrativos.
- Diariamente se emitirá una lista de los participantes de cada actividad que estén vigentes.

Estas son reglas que se infieren de lo que has dicho. No necesariamente son las que tu utilizas, esas las conoces solamente tu.

Para el caso, según estas reglas de
negocio, lo que tienes es:

- Institución: Tabla central que identifica la empresa o institución (necesaria solo a los efectos de integridad del sistema)
- Persona: Personas registradas en algún momento en la institución.
- Actividad: Listado de actividades desarrolladas en la institución.
- Coordinadores: Personas a cargo de las actividades.
- Persona_Actividad: Registro de inscripciones a una actividad, con su alta original.
- Detalle_Actividad_Persona: Listado de las altas y bajas de una apersona en una actividad. Contiene la FK de Persona_GrupoActividad.
- Coordinador_Actividad: Listado de Cada Coordinador y Actividad que supervisa.
- Coordinaror_GrupoActividad: Lista de grupos activos de cada coordinador.
- Persona_GrupoActividad: Registración de la Persona en un grupo para una actividad dada.

Este sería un esquema mínimo que cumpliría todas las condiciones que las reglas del negocio imponen. No está totalmente normalizado, y no me explayo en los atributos, que podrían incluso requerir algunas tablas más (Ciudades, Provincias, categorías de usuario, categoría de actividades, salas o áreas de desarrollo, etc.).
Como ves, el modelo que se requiere, para que el sistema sea mínimamente eficiente y las consultas no se vuelvan un infierno, son al menos seis tablas...
No estoy ni siquiera exagerando. Puede que en realidad el sistema sea algo más elaborado, pero con esto es para comenzar.
Nota: El que el único tipo de actividades posibles para tu caso sea de Gym, es irrelevante para el modelado. El esquema de BBDD es siempre independiente de la aplicación y se planea para que soporte modificaciones a futuro entre dos a cinco años. Y eso hace que se lo diseñe para soportar cualquier cambio en la orientación del negocio.
Una base de datos debe ser estructuralmente fija, porque cambios sutiles en la estructura de la misma, generan catástrofes en las aplicaciones y en la propia base. Por eso se planea para el futuro y no solamente para el presente. Y en ese sentido debe ser flexible.
¿Se comprende el problema?

Si esto te parece exagerado recuerda: No por que sí, Base de Datos es una especialidad profesional.