Relación de Generalización/Especialización

[Cota_Isla]

Hola buenas!
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:

Código:

CREATE TABLE IF NOT EXISTS `precio` (
  `activ` tinyint(3) unsigned NOT NULL,
  `org` enum('GRCSL','UCA') NOT NULL DEFAULT 'GRCSL',
  `ano` year(4) NOT NULL,
  `clase` decimal(4,2) unsigned NOT NULL,
  `mes` decimal(5,2) unsigned DEFAULT NULL,
  `dia_med` decimal(5,2) unsigned DEFAULT NULL,
  `dia_comp` decimal(5,2) unsigned DEFAULT NULL,
  `l_edad` tinyint(3) unsigned DEFAULT NULL,
  `edad1` decimal(5,2) unsigned DEFAULT NULL,
  `edad2` decimal(5,2) unsigned DEFAULT NULL,
  `1d` decimal(5,2) unsigned DEFAULT NULL,
  `2d` decimal(5,2) unsigned DEFAULT NULL,
  `3d` decimal(5,2) unsigned DEFAULT NULL,
  `4d` decimal(5,2) unsigned DEFAULT NULL,
  `5d` decimal(5,2) unsigned DEFAULT NULL,
  FOREIGN KEY (`activ`) REFERENCES `actividad` (`id`) ON DELETE CASCADE ON    UPDATE CASCADE,
  PRIMARY KEY (`activ`,`org`,`ano`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Después de observarlo me di cuenta de que podría ser una relación de generalización/especialización. Mi problema es que no se si sería así:

Código:

CREATE TABLE IF NOT EXISTS `precio` (
  `activ` tinyint(3) unsigned NOT NULL,
  `org` enum('GRCSL','UCA') NOT NULL DEFAULT 'GRCSL',
  `ano` year(4) NOT NULL,
  `clase` decimal(4,2) unsigned NOT NULL,
  FOREIGN KEY (`activ`) REFERENCES `actividad` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
  PRIMARY KEY (`activ`,`org`,`ano`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS `precio_mes` (
  `activ` tinyint(3) unsigned NOT NULL,
  `org` enum('GRCSL','UCA') NOT NULL DEFAULT 'GRCSL',
  `ano` year(4) NOT NULL,
  `mes` decimal(5,2) unsigned DEFAULT NULL,
  FOREIGN KEY (`activ`) REFERENCES `precio` (`activ`) ON DELETE CASCADE ON    UPDATE CASCADE,
FOREIGN KEY (`org`) REFERENCES `precio` (`org`) ON DELETE CASCADE ON    UPDATE CASCADE,
FOREIGN KEY (`ano`) REFERENCES `precio` (`ano`) ON DELETE CASCADE ON    UPDATE CASCADE,
  PRIMARY KEY (`activ`,`org`,`ano`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS `precio_dia` (
  `activ` tinyint(3) unsigned NOT NULL,
  `org` enum('GRCSL','UCA') NOT NULL DEFAULT 'GRCSL',
  `ano` year(4) NOT NULL,
  `dia_med` decimal(5,2) unsigned DEFAULT NULL,
  `dia_comp` decimal(5,2) unsigned DEFAULT NULL,
  FOREIGN KEY (`activ`) REFERENCES `precio` (`activ`) ON DELETE CASCADE ON    UPDATE CASCADE,
FOREIGN KEY (`org`) REFERENCES `precio` (`org`) ON DELETE CASCADE ON    UPDATE CASCADE,
FOREIGN KEY (`ano`) REFERENCES `precio` (`ano`) ON DELETE CASCADE ON    UPDATE CASCADE,
  PRIMARY KEY (`activ`,`org`,`ano`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS `precio_semanal` (
  `activ` tinyint(3) unsigned NOT NULL,
  `org` enum('GRCSL','UCA') NOT NULL DEFAULT 'GRCSL',
  `ano` year(4) NOT NULL,
  `1d` decimal(5,2) unsigned DEFAULT NULL,
  `2d` decimal(5,2) unsigned DEFAULT NULL,
  `3d` decimal(5,2) unsigned DEFAULT NULL,
  `4d` decimal(5,2) unsigned DEFAULT NULL,
  `5d` decimal(5,2) unsigned DEFAULT NULL,
  FOREIGN KEY (`activ`) REFERENCES `precio` (`activ`) ON DELETE CASCADE ON    UPDATE CASCADE,
FOREIGN KEY (`org`) REFERENCES `precio` (`org`) ON DELETE CASCADE ON    UPDATE CASCADE,
FOREIGN KEY (`ano`) REFERENCES `precio` (`ano`) ON DELETE CASCADE ON    UPDATE CASCADE,
  PRIMARY KEY (`activ`,`org`,`ano`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS `precio_edad` (
  `activ` tinyint(3) unsigned NOT NULL,
  `org` enum('GRCSL','UCA') NOT NULL DEFAULT 'GRCSL',
  `ano` year(4) NOT NULL,
  `l_edad` tinyint(3) unsigned DEFAULT NULL,
  `edad1` decimal(5,2) unsigned DEFAULT NULL,
  `edad2` decimal(5,2) unsigned DEFAULT NULL,
  FOREIGN KEY (`activ`) REFERENCES `precio` (`activ`) ON DELETE CASCADE ON    UPDATE CASCADE,
FOREIGN KEY (`org`) REFERENCES `precio` (`org`) ON DELETE CASCADE ON    UPDATE CASCADE,
FOREIGN KEY (`ano`) REFERENCES `precio` (`ano`) ON DELETE CASCADE ON    UPDATE CASCADE,
  PRIMARY KEY (`activ`,`org`,`ano`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

No se si me he explicado con claridad. Podría ser uno de estos casos el correcto: una tabla con todos los atributos como el primer código o la especialización (siguiente código pequeñas tablas con los atributos de la especialidad)??Si fuera este último caso, habría que poner un atributo de tipo??

Espero vuestras respuestas. Un saludo y gracias!!

[Cota_Isla]

Buenas,
estoy leyendo información en la web y me estoy liando un poco, llegando al termino de no saber si este concepto es uno solo o son dos??

[gnzsoloyo]

No se si me he explicado con claridad. Podría ser uno de estos casos el correcto: una tabla con todos los atributos como el primer código o la especialización (siguiente código pequeñas tablas con los atributos de la especialidad)??Si fuera este último caso, habría que poner un atributo de tipo??

Tu problema no es de especialización/generalización (que es en todo caso hablar de herencias y jerarquías), sino de Normalización de Bases de Datos.
Tienes mucha falta de normalización, pero lo miraré con más cuidado. Desde ya que todo eso no es una única tabla.

[Cota_Isla]

Vale!
mi problemas es que no se si generalización y especialización es un mismo concepto o son varios.
A continuación adjunto el código de las modificaciones considerando que es disyunta y total:

Código:

CREATE TABLE IF NOT EXISTS `precio_dia` (
  `activ` tinyint(3) unsigned NOT NULL,
  `org` enum('GRCSL','UCA') NOT NULL DEFAULT 'GRCSL',
  `ano` year(4) NOT NULL,
  `clase` decimal(4,2) unsigned NOT NULL,
  `dia_med` decimal(5,2) unsigned NOT NULL,
  `dia_comp` decimal(5,2) unsigned NOT NULL,
  FOREIGN KEY (`activ`) REFERENCES `actividad` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
  PRIMARY KEY (`activ`,`org`,`ano`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


CREATE TABLE IF NOT EXISTS `precio_edad` (
  `activ` tinyint(3) unsigned NOT NULL,
  `org` enum('GRCSL','UCA') NOT NULL DEFAULT 'GRCSL',
  `ano` year(4) NOT NULL,
  `clase` decimal(4,2) unsigned NOT NULL,
  `l_edad` tinyint(3) unsigned NOT NULL,
  `edad1` decimal(5,2) unsigned NOT NULL,
  `edad2` decimal(5,2) unsigned NOT NULL,
  FOREIGN KEY (`activ`) REFERENCES `actividad` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
  PRIMARY KEY (`activ`,`org`,`ano`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


CREATE TABLE IF NOT EXISTS `precio_mes` (
  `activ` tinyint(3) unsigned NOT NULL,
  `org` enum('GRCSL','UCA') NOT NULL DEFAULT 'GRCSL',
  `ano` year(4) NOT NULL,
  `clase` decimal(4,2) unsigned NOT NULL,
  `mes` decimal(5,2) unsigned NOT NULL,
  FOREIGN KEY (`activ`) REFERENCES `actividad` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
  PRIMARY KEY (`activ`,`org`,`ano`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


CREATE TABLE IF NOT EXISTS `precio_semanal` (
  `activ` tinyint(3) unsigned NOT NULL,
  `org` enum('GRCSL','UCA') NOT NULL DEFAULT 'GRCSL',
  `ano` year(4) NOT NULL,
  `clase` decimal(4,2) unsigned NOT NULL,
  `1d` decimal(5,2) unsigned NOT NULL,
  `2d` decimal(5,2) unsigned NOT NULL,
  `3d` decimal(5,2) unsigned NOT NULL,
  `4d` decimal(5,2) unsigned NOT NULL,
  `5d` decimal(5,2) unsigned NOT NULL,
  FOREIGN KEY (`activ`) REFERENCES `actividad` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
  PRIMARY KEY (`activ`,`org`,`ano`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Yo lo que pienso es que si van en tablas separadas como se diferencia los tipos de generalización o especialización?¿? Habría que añadir un atributo de 'tipo'??
Muchas gracias por tu aporte! Un saludo!

[gnzsoloyo]

No me has entendido: Es un problema de Normalización, y el tema es que el conjunto completo está mal diseñado, porque las entidades y relaciones no han sido correctamente planteadas.
Más tarde te profundizo el tema, pero desde ya, el diseño para ser funcional es compoletamente distinto, hasta lo que puedo ver.

[Cota_Isla]

Partimos entonces de la base que tengo 5 entidades en el diagrama ER:
-Padre: precio con atributos activ,ano,org y clase.
-4 hijas: precio_mes, precio_edad, precio_semana y pecio_dia cada uno con sus atributos de especialidad.

Y ahora convierto al modelo relacional no? que ahí creo que es donde me equivoco, que no saco las tablas como debería sacarlas.

[gnzsoloyo]

Nop.
No hay una relación padre/hijo en tu sistema. No hay clases ni jerarquías.
Es un diseñlo diferente.

[Cota_Isla]

Entonces no lo veo el diseño... es que no se como subir imágenes, quizás así lo vea mejor!

[gnzsoloyo]

Lo que dices es esto:

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.

[Cota_Isla]

Pero es que en verdad son formas de pago, 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...
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.
Por eso yo lo veo mejor como te comentaba.
¿Y por qué no valdría una generalización de precio?

[gnzsoloyo]

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:

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

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.

[Cota_Isla]

Te voy comentando en el orden de tu respuestas:
1º) Comentarte que mi programa no es orientado a objetos por lo que no tendría un modelo de clases no? Este concepto lo no tengo muy claro. Es decir, si mi aplicación esta implementada en un paradigma por procedimientos y no orientado a objetos.

2º) Con respecto a la definición de generalización, sigo sin entender porque precio no es una entidad según he entendido en tu explicación, ¿por que es como un atributo de lo que has llamado producto, es decir, en mi caso es un atributo de mi actividad?
A ver si me explico mejor, porque digamos el precio de una actividad es una característica de la actividad en concreto?

3º) En cuanto a la repetición de atributos en las tablas hijas que me comentas, te refieres a que por ejemplo se repiten los atributos que son clave primaria? por que en teoría con la herencia que hice solo se repite la clave ya que cada tipo tenia sus atributos.

4º) En el tema de pago por edad, me surge la duda de que: y como conocería el sistema que el pago es de esa forma? o de cada forma correspondiente, siendo una modalidad mas??

5º) Hay una cosilla del modelo que me propusiste que no se para que sirve: es en la entidad modalidad_asistencia el atributo precio_id, no veo para que sirve ni que indica.

6º) Por ultimo, las restricciones entre entidades te refiere a factores como cardinalidad y eso no? se imponen en el modelo de datos de alguna forma? Como?

En conclusión, no tendría una entidad precio, si no que cuando hago una inserción de una actividad, sería haría una inserción en modalidad indicando el tipo de pago y precio. Las entidades modalidad y valor no podrían ser una única para mi caso??

Ante todo muchas gracias por tu dedicación y pedirte disculpas por mi exigencia y mi ignorancia en algunos puntos.
Voy a estudiar el modelo y lo muestro cuantito lo tenga. Aunque si sabes como subir una imagen indicamelo y asi lo vemos mejor gáficamente.

Un saludo y muchas gracias!

[Cota_Isla]

Perdona, con respecto a lo que te dije de una única entidad ya se porque son dos, porque cada modalidad puede tener varios precios no?

Se me olvido comentarte que puede haber ofertas entre dos actividades, eso si sería una entidad aparte no¿? Yo puse una entidad oferta con una relacion N:N actividades.

Un saludo!

[gnzsoloyo]

Esta noche te lo escribo más claramente.
Ahora estoy un poquito cargado.

[Cota_Isla]

Valee muchas gracias! Si me coges con el ordenador te contesto directamente!
Un saludo!

[Cota_Isla]

Buenas!

He realizado un pequeño enunciado para el problema:

• Un cliente se puede apuntar a una o varias actividades, o asistir a clases sueltas de una determinada actividad. El cliente puede ser usuario del gimnasio o puede pertenecer algún convenio con precios distintos.

• Una actividad se imparte en grupos de un tamaño determinado de alumnos que pueden ser se asistencia fija o flexible (puede ir los días que quiera o tiene que ir los días determinados.

• Cada actividad se paga de una forma concreta, aunque existen diversas forma: pago mensual único, pago mensual por asistencia al día (medio día o día completo), pago por asistencia de días a la semana o pago en función de la edad.

• Existen ofertas para los clientes que se apuntan a dos actividades concretas, determinadas por el gimnasio. Si el cliente esta apuntado a una actividad y se apunta a otra y estas dos forman parte de una oferta se le aplicaría el precio de la oferta. Cada oferta está formada por dos actividades únicamente.

• De cada actividad existe una lista de espera para futuros clientes.

Te muestro el diagrama ER que tenía anteriormente y vamos viendo si te parece:



Un saludo!