Diseño de una base de datos de un GYM

[Cota_Isla]

Hola estoy aquí liado diseñando una base de datos para un gym y mi duda es si hace falta una entidad llamada baja, por ejemplo.
Pienso esto ya que un cliente se puede dar de baja de una actividad y seguir apuntado en otra.
Y a tabla de esta entidad tendría como atributo un id, la fecha de baja, el cliente y la actividad a la que se ha dado de baja.
También he pensado que en la tabla cliente haya un atributo, baja, q indique si este cliente no asiste a ninguna actividad.
No se si se me escapa algo, ave si me podéis ayudar.
Un saludo y gracias de antemano.

[gnzsoloyo]

No. Lo que debe existir es una tabla que relacione a la tabla Clientes con la tabla Actividad, que gestione las actividades en las que está inscripto.
Esa entidad debe tener además al menos dos campos: inicio_actividad (tipo DATE) y baja_actividad (tipo DATE).
Lo que quiero que comprendas es que la baja es un atributo de la inscripción a la actividad, y debe tener la fecha de baja por necesidades de sistema (actuales o futuras).

También he pensado que en la tabla cliente haya un atributo, baja, q indique si este cliente no asiste a ninguna actividad.

Totalmente innecesario. Si el cliente no aparece inscript en ningua actividad donde fecha_baja no sea NULL, entonces no tiene actividades.
Este modelado te permitiría incluso saber desde cuando no tiene actividades, mientras que el que propones no hay modo de saberlo.
Lo que parece que no tienes claro es cómo se analizan los modelos de clases y cómo se analizan los modelos basados en Entidad-Relación.
Te recomiendo que leas algo del tema y preguntes tus dudas.
La abstracción del modelado es algo que se aprende por experiencia y con guia de profesores. Es difícil hacerlo sin guía porque requiere entrenamiento en el modo de razonar, y eso rara vez lo aprendes por ti mismo...

[Cota_Isla]

Buenas,
con respecto a lo primero, cuando dices con la tabla actividad, en mi caso seria grupo, ya que una actividad tiene varios grupos a los que inscribirse. Es decir de la relación varios a varios entre clientes y grupos una tabla que tendrá como clave primaria cada una de las claves primaria de las tablas que relaciona y dos atributos mas que serán fecha de alta, que no podrá ser nulo, y fecha de baja, que este si podrá serlo, ambos de tipo date.
¿Sería así a lo que te refieres?
Pero a todo esto me surge una duda:
¿En el caso que el cliente este almacenado en la BD y no asista a ningún grupo de ninguna actividad e intente darse de alta en el mismo grupo de la misma actividad después de haber estado de baja durante un tiempo, perdería por ejemplo la fecha anterior de alta y baja no?¿Cómo poder evitar eso?
Muchas gracias de antemano y un saludo!

[gnzsoloyo]

¿En el caso que el cliente este almacenado en la BD y no asista a ningún grupo de ninguna actividad e intente darse de alta en el mismo grupo de la misma actividad después de haber estado de baja durante un tiempo, perdería por ejemplo la fecha anterior de alta y baja no?¿Cómo poder evitar eso?

La registración en la actividad, y el grupo de la actividad son entidades distintas. Para estár en una actividad se debe haber previamente registrado, pero la lista de asistencia y la lista de registraciones no son la misma lista.
Por eso existen en las instituciones los registros de inscripción.
Lo que tienes que haces es plantearlo todo en un DER, entonces vas analizando las relaciones y viendo qué y cuales se necesitan para cubrir esos aspectos.

[Cota_Isla]

Yaya, yo tengo una entidad grupo y una entidad actividad pero los clientes se relacionan con los grupos y no con las actividades. Aun así no veo como solucionar el problema q t expongo, lo unico que se me ocurre es que el atributo fecha de alta sea clave primaria , otra forma no se me ocurre. ¿Podría se asi?

[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.

[Cota_Isla]

Sí, el problema general lo tengo similar a la solución que me expones, pero aún así no veo solución a la duda que me surge.

[gnzsoloyo]

Disculpa, pero lo que te descripto ya está precocinado. Sólo te queda armar el diagrama y construir las tablas con los atributos correspondientes.
¿En qué puede consistir tu duda?

[Alfredex]

Uhmmm ... de acuerdo a lo que entiendo, se supone que ya tienes una tabla de inscripciones dentro de esa tabla, deberás tener los datos del cliente y la actividad a la cual se está inscribiendo por ejemplo (tabla inscripciones: id_inscripcion, id_cliente, id_actividad, fecha_inicio, fecha_fin, estado(en el estado solo tienes que ser de 2 activo o inactivo))
cuando llenes la tabla tendrás:
para el activo: ins001, cli0001, act0001, 12/10/2012, 30/12/12, 1
y para el inactivo: ins001, cli0001, act0001, 12/10/2012, 30/12/12, 0

y si en caso el cliente quiere volver a tomar tal actividad volverás a crear un nuevo registro, con nueva fecha de inicio y de fin y obviamente de estado

[Cota_Isla]

Sí, algo así me refería. Pero yo digo en el caso de que quiera almacenar ambas fechas de altas, ¿cómo lo puedo hacer?

[speaK121]

según te ha comentado gnzsoloyo:
Detalle_Actividad_Persona: Listado de las altas y bajas de una persona en una actividad. Contiene la FK de Persona_GrupoActividad

En esa tabla, por lo que he entendido, se registra cada alta / baja que haga una persona en una determinada actividad. Por lo que con hacer una consulta a esa tabla respecto a un cliente te saldrá todas las fechas de alta / baja que ha tenido.