Ver Mensaje Individual
  #2 (permalink)  
Antiguo 05/01/2011, 05:36
Avatar de gnzsoloyo
gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 16 años, 5 meses
Puntos: 2658
Respuesta: Problema con claves ajenas

Por lo pronto hay algunos errores de comprensión del uso de los AUTO_INCREMENT, de la sintaxis de FOREIGN KEY, y resulta poco claro el diseño de relaciones que estás planteando.
Por partes:

1) Los campos declarados como AUTO_INCREMENT deben ser forzosamente PRIMARY KEY en MySQL, o al menos deben formar parte de ella. En tu caso, estás violando esta regla de MySQL en la tabla empresas y grupo_empresas, y usandolo mal en calendario_empresa
En el primer caso, si pones un auto_increment, debe ser PK, caso contrario genera un error.
En el segundo debes recordar que los valores tomados por los campos autoincrement son únicos en la tabla para cada registro, por lo que usarlos para una PK de varios campos no sólo carece de sentido, sino que puede prermitir que varios registros distintos repitan los otros valores simplemente porque el AI no es el mismo, y no te olvides que una PK se evalúa en forma integral, no por el valor individual de sus campos.

2) La sintaxis de un FOREIGN KEY es: FOREIGN KEY(campo/s) REFERENCES tablaorigen(campos)
En tu caso no estás poniendo ni el REFERENCES ni el nombre de la tabla.

3) En referencia al diseño de labase propiamente dicho, me parece que no tienes claro el concepto de relaciones y dependencias, porque el que estás proponiendo es innecesariamente complicado.
Me explico: A mi entender, lo primero que existen son las Empresas; cada empresa pertenece a un Grupo y puede haber más de una Empresa en cada Grupo. A su vez una empresa tiene Eventos, pero los eventos no pertenecen sino que se programan para una empresa. Cada evento programado pertenece al calendario de una empresa.
Si esto se ajusta al modelo, entonces las relaciones son así:
- Existe una tabla denominada Grupo con su propia PK.
- La tabla Empresa tiene su PK y posee como FK la del Grupo, porque la Empresa es parte de un grupo pero en el grupo pueden haber más de una.
- Puede existir una tabla Evento, que describe genéricamente los eventos programables y extras, con su propia PK.
- La relación entre Empresa y Evento se expresa en la tabla Calendario_Empresa que tiene como PK las de Empresa y Evento, más un discriminante que puede ser autonumérico o ser la fecha si es evento es único por fecha, o numérico controlado por aplicación, si es incremental por grupos. Incluso, si el evento sólo puede hacerse una vez por empresa, el discriminante no sería necesario.

Una de las cosas a destacar en este caso es que no se necesita crear FK tan largas y complejas porque ciertos datos no necesitan ser parte de la la clave, aunque por cuestiones de proceso se requiera que aparezcan: el ID del usuario, por ejemplo, puede ser práctico, pero no necesario a la hora de crear la PK.
Lo importante para definir una PK es simple: Si para identificar perfectamente un registro en la tabla, uno o más campos pueden ser suficientes, el resto no pertenece a la PK.

Pero ciertamente, la tabla even_cal_emp, tal y como lo planteas, no se necesita porque tiene los mismos campos que la Calendario_Empresa. Su uso aparece como redundante.
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)