Lo que dices es esto:
Cita: estoy realizando una BD de un Gimnasio, y necesito ayuda: se supone que dicho gimnasio tiene distintos tipos de precios en los que cada actividad se paga únicamente de una forma. Las formas posibles son: mensual, asistencia de días a la semana, asistencia medio día o día completo, o por edad. Estas son las formas de pago, entonces, a la hora de implementarlo en MySQL generé una única tabla
Según esto, tienes.
* Un asociado al gimnasio puede realizar una o más actividades.
* Cada actividad puede tener una o más modalidades de asistencia (mensual, semanal o diaria).
* Cada modalidad de asistencia tiene una única forma de pago.
* Cada actividad tiene un diferente valor por cada modalidad.
* Una actividad puede tener una edad mínima de asistencia (no queda claro si tiene una edad máxima).
Una aproximación al problema sería, por ejemplo:
- Actividades(actividad_id, denominacion, edad_minima).
- Modalidad_asistencia(modalidad_id, descripcion)
- Valor_Actvidad_modalidad(precio_id, actividad_id, modalidad_id, precio)
- Asociados(asociado_id, nombre, apellido, documento, fecha_nacimiento, tipo, calle, numero, depto, piso, unidad, barrio, ....)
- Suscripcion_Asociados(suscripcion_id, asociado_id, Actividad_id, precio_id)
- asistencia(suscripcion_id, fecha)
Con un esquema de ese tipo podrían cubrirse las funcionalidades. Por supuesto, hace falta una mejor descripcion de todo para ver cómo se debe armar.
Esa decripción que te pongo antes, es una parte muy importante, sin la cual no se puede crear el esquema de entidades y relaciones correctamente. Es llo que se denominan "reglas de negocio", y nos permiten inferir los esquemas que la BBDD deberá tener.
Tienes que tener en cuenta que las entidades en el modelo de clases
no representa las entidades del modelo de datos.
Pueden parecese, pero no son lo mismo, porque se basan en paradigmas algo diferentes.