La genralización de precios no sirve porque no existe desde la óptia de BBDD.
Vamos aclarar algunos conceptos.
Hay algo que debes entender: Que en el modelo de clases del programa puedas y te convenga crear una clase con relaciones padre/hijo,
no implica que eso se pueda trasladar al modelo de datos. No es lo mismo un modelo de clases que un modelo de datos que pueda alimentar las clases.
La generalización aparece en BBDD cuando una entidad puede separarse en dos o más entidades débiles dependientes que refieren al mismo concepto de la primera, y esto sólo se produce cuando existen atributos propios una entidad y no a otra, pero a su vez se los puede analizar como parte de una entidad padre. Es el caso, por ejemplo, de una entidad "Persona", que puede abarcar tanto Clienes, Provedores y Empleados. A su vez, hay una entidad Empleado, que puede ser Administrativo, Comercial, Operario, Mantenimiento, etc.
En cada uno de las subentidades puede haber atributos que le son propios. Pero si no los hay, si sólo se diferencian en una categorización, entonces no existe una "herencia" de lcase o padre/hijo, sino una relación con entidades que identifiquen la categoría a la que pertenecen en su condición de Empleado.
¿Se va entendiendo?
En el caso de los precios, cuando abstraes el modelo, se puede ver que la principal entidad es un precio asignado a un "producto". Es ese "producto" lo que tiene precio, y es el "producto" lo que tiene la descripcion o detalles a los que se asigna un valor monetario.
Lo que estás haciendo es mezclar el concepto de "producto" del gimnasio, con el precio que dicho producto tiene.
En ese sentido, el modelado debe representar correctamente lo que es el producto, y eso es lo que en tu modelo de datos está mal planteado.
Quiero aclarar también, que en sistemas comerciales se entiende como "producto" todfo aquel objeto o servicio que se brinda al cliente, sea este un conjunto de horas de servicio, o un yate de 60 metros de eslora. Todo es un producto comercial. El
qué producto sea es un tema de categorización del producto, el que sí podría (dado el caso de ser necesario) ser un esquema de padre/hijo.
Si analizas con cuidado las tablas donde "divides" los precios en tablas hijas, verás que repites el mismo conjunto de atributos, lo que implica que replicaas esquemas (error), para diferenciar instancias de acuerdo a su
uso dentro de los procesos. Grave error.
La base de datos no representa los procesos. Eso lo haces en los diagramas de la aplicación. La base de datos provee al programa de los datos, de un modo eficiente
y flexible. Es decir, debe ser capaz de responder a todas las consultas presentes o futuras, y para eso lo primero que debe hacerse es
no acoplar la base con la aplicación.
REspecto a lo que dices:
Cita: con esto me refiero que por ejemplo, si una actividad, se paga según la edad ya no me serviría este modelo... porque asistencia según edad..
No hay ninguna razón para que no te funcione el modelo propuesto, porque si no necesitas la edad para realizar el cobro, simplemente no la verificas. Pero si
a futuro, surge la necesidad, ya la tienes.
¿Se entiende?
No planeas para ahora. Planeas para más adelante, te anticipas a las necesidades, a fin de evitar el mayor problema que los DBA tienen todo el tiempo: Tener que modificar la estructura de datos cuando la base ya está productiva... (es una pesadilla).
Cita: Comentarte que cada actividad tiene una única forma de asistencia como tu lo has llamado, es decir, que nada mas se puede pagar de una forma.
Eso se determina por las restricciones entre entidades. El modelo que te propongo, y que se puede mejorar, no impide eso. lo quie hace es plantear un modo más flexible de implementarlo.