[SOLUCIONADO] Opción "Mandatory" en MySQL Workbench

[metalfox6383]

Hola, compañeros:

¿Dónde encuentro la opción "Mandatory" para MySQL Workbench? Sé que esa opción está visible durante el diseño de la base de datos, para las llaves foráneas (en los diagrámas). Pero una vez que he creado mi base de datos, no encuentro tal opción para poder desactivarla.

Muchas gracias.

[gnzsoloyo]

No existe tal opción a nivel físico. Se la nombra así en la herramienta de diseño, y corresponde a las relaciones de FK que crean a su vez claves primarias compuestas o heredadas.
Una vez creada la base con esa estructura,esas claves son parte de las restricciones de clave foránea que no puedes violar. No se desactivan a menos que modifiques las tablas.

[metalfox6383]

Caray. ¿Eso quiere decir que sólo tengo opción a modificar tal opción durante el diseño de mi base de datos y no cuando ésta ya esté creada? Practicamente me obligaría a eliminar la lleva foránea para ya no tener restricciones.

[gnzsoloyo]

Yo no he dicho eso.
Lo que rato de explicarte es que una relación mandatoria es la forma en el diagrama de determinar una restricción de dependencia funcional, que uno como analista define para establecer ciertas condiciones que los datos deben cumplir, a fin de proteger la consistencia de la información y la integridad referencial.
Uno no genera una relacion mandatoria por que si. Lo hace porque es necesaria y obligatoria de acuerdo al relevamiento del sistema. Es en realidad una forma de crear cosas que el sistema ya tiene, y que uno debe proteger para evitar que, entre otros, los programadores hagan cualquier barbaridad.
Y no creas que no lo hacen...

Por lo demás, no es sólo en la etapa de diseño donde aparecen estas cosas.
Bien puede suceder que cuando ya tengas la base en trabajo productivo, veas que ciertas relaciones se vuelven necesarias, precisamente para proteger integridades de datos que no se vieron en el momento de diseño. En esos casos se deben agregar, y no quitar.
No he visto casos donde en una base se eliminen este tipo de dependencias. Si que se agreguen, pero no que se quiten.
En todo caso, como una relación mandatoria es en la base física una FK, y una FK se puede sacar o quitar, siempre puedes hacerlo. Pero te insisto: No es si se puede hacer o no, la pregunta es si se debe hacer en tu caso.
Muéstranos el diseño de la base, y dinos cual es el problema que tienes, y entonces veremos si corresponde que exista o no es dependencia.
En el aire no se habla.

[metalfox6383]

Guau. Gracias, pero mi pregunta inicial fue simple. ¿Dónde encuentro la opción una vez que he creado la base de datos? Tu primera respuesta fue que esa opción no está presente, que sólo se encuentra en diseño para establecer la lógical relacional del diagrama. Entendido con ello.

Estoy en la etapa de planeamiento y desarrollo de prototipo, resulta que durante los ensayos, algunas restricciones deben desaparecer porque no son necesarias, y ya que no quiero volver a hacer el "Forward Engineer" sólo para anular una restricción, buscaba tal opción en la base de datos.

Mi problema es el siguiente:
Tengo una tabla que hace referencia a otra (con los campos ID). He establecido una llave foránea en el diagrama. Resulta que no puedo ingresar un registro en esta tabla si el registro referenciado en la otra no existe, pero a fin de cuentas, necesito hacerlo así.
Desactivando la opción "Mandatory" (en el diagrama), la llave foránea sigue existiendo pero tal restricción queda desactivada.
Por el momento sólo me interesa mantener las restricciones ON UPDATE y ON DELETE en tal llave foránea.

Bueno, ese es mi problema. ¿Cómo podría solucionarlo? Muchas gracias.

[gnzsoloyo]

Desactivando la opción "Mandatory" (en el diagrama), la llave foránea sigue existiendo pero tal restricción queda desactivada.
Por el momento sólo me interesa mantener las restricciones ON UPDATE y ON DELETE en tal llave foránea.

Bueno, ese es mi problema. ¿Cómo podría solucionarlo?

En primer lugar, tu pregunta es muy abstracta. Es demasiado general, y en BBDD no existen demasiadas "generalidades", ya que cada modelo en particular puede tener caracteristicas propias.
Si quieres una respuesta que te sirva en tu caso, postea la estructura de esa parte de tus tablas, explicanos por qué definiste esas relaciones de ese modo y entonces si podremos ver si hay que quitarlas o no. Puede suceder perfectamente que haya relaciones mal definidas, algo falte, o bien algo sobre.
Hay que ver el caso concreto.
Desde ya, cuando me explicas esto:

Tengo una tabla que hace referencia a otra (con los campos ID). He establecido una llave foránea en el diagrama. Resulta que no puedo ingresar un registro en esta tabla si el registro referenciado en la otra no existe, pero a fin de cuentas, necesito hacerlo así.

a mi me da toda la impresión de que diseñaste mal esas relaciones. Pero sin ver lo que hiciste en concreto, no puedo estar seguro. Podría estar sucediendo que hayas definido na relacion de dependencia circular, cosa que sería un error grave...
Es posible que el problema sea tanto de datos como de procesos. Si es el primer caso, con que postees los CREATE TABLE de las tablas involucradas, se podrá ver.
Pero si es un problema de procesos, eso es ajeno a la estructura de la base, y en todo caso caería en temas de programación.

Postea lo que te pido así podemos avanzar.

[metalfox6383]

Gracias por la ayuda, aunque insisto que mi problema es algo más técnico.

No puedo postear el código porque es muy grande. Copio el link de descarga de un archivo txt donde se encuentra código.

Saludos.
http://we.tl/V2vw5OxLCI

[gnzsoloyo]

Postea el repositorio en un sitio que no pida cookies. Por cuestiones de seguridad no acepto ese tipo de cosas.
Además, no le veo sentido a que postees todo. Solo te estoy pidiendo las tablas que afectan el problema, es decir el script SQL, y con eso no debería haber problemas.
Solo los CREATE TABLE de las tablas involucradas. Si necesitamos algo mas, te lo pediremos.

[metalfox6383]

Oh! Ok. Aquí va:

Código MySQL:

-- -----------------------------------------------------
-- Table `bd_kachito`.`tiendas`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `bd_kachito`.`tiendas` (
  `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `Nombre` TEXT NULL DEFAULT NULL,
  `Direccion` TEXT NULL DEFAULT NULL,
  `NumeroPrefijo` INT(10) UNSIGNED NOT NULL COMMENT 'Número prefijo que se usará en las facturas.',
  PRIMARY KEY (`id`))
ENGINE = InnoDB
DEFAULT CHARACTER SET = latin1;
 
-- -----------------------------------------------------
-- Table `bd_kachito`.`platos`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `bd_kachito`.`platos` (
  `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `Nombre` TEXT NULL DEFAULT NULL COMMENT 'Texto comercial que se utilizará al momento de la impresión o muestra de título en pantalla.',
  `Descripcion` TEXT NULL DEFAULT NULL COMMENT 'Descripción del producto, sólo para mostrar en pantalla al mesero.',
  `PrecioUnitario` DECIMAL(6,2) UNSIGNED NOT NULL,
  `Categoria` TEXT NULL COMMENT 'Categoría al cuál pertenece el producto.',
  `EnCirculacion` BIT NOT NULL COMMENT 'Booleano que indica si el producto se encuentra en circulación, es decir, si aún se vende.',
  `idInsumos` INT UNSIGNED NOT NULL COMMENT 'ID de la relación entre Productos e Insumos.',
  `idTienda` INT UNSIGNED NULL,
  `idArea` INT UNSIGNED NOT NULL COMMENT 'Id del área encargada de elaborar el plato.',
  PRIMARY KEY (`id`),
  INDEX `fk_tiendas_idx` (`idTienda` ASC),
  INDEX `fk_platos_areas1_idx` (`idArea` ASC),
  CONSTRAINT `fk_tiendas_platos`
    FOREIGN KEY (`idTienda`)
    REFERENCES `bd_kachito`.`tiendas` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_platos_areas1`
    FOREIGN KEY (`idArea`)
    REFERENCES `bd_kachito`.`areas` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB
DEFAULT CHARACTER SET = latin1
COMMENT = 'Almacena los platillos que en cada tienda se sirven.';
 

Es una tabla de platos y otra de tiendas. En mi lógica, cada tienda puede tener sus propios platos, por tal, un registro en la tabla "platos" hace referencia a la tienda al que pertenece. Pero quiero guardar platos generales (con idTienda=0) que serán jalados por todas las tiendas.
Sucede que el registro en la tabla "tiendas" con id=0 no existe, porque el id inicia con 1, es así que si quiero guardar un registro en la tabla "platos" con idTienda=0 no me lo permite.
Desactivando "Mandatory" en el diseño de mi diagrama, la restricción desaparece sin eliminar la llave foránea. Me interesa la eixstencia de la llave foránea, ya que así puedo eliminar un registro en la tabla "tiendas" y así eliminar también todos sus platos (por ejemplo).

Caí en esa lógica luego de haber desarrollado mi base de datos y haber experimentado con ella. Tal restricción estaba presente pero quería desactivarla sin tener que rehacer la base de datos completa.

Muchas gracias por la ayuda, amigo. Saludos.

[gnzsoloyo]

Es un problema muy habitual en ciertos sistemas, y la solución práctica pasa por crear una tienda genérica, precisamente, a la que se suele llamar "virtual", "genérica", e incluso "global ".
De ese modo respetas las relaciones sin dejar de tener una condición funcionalmente necesaria.
En otros contextos, como el de categorías, por ejemplo, se suele agregar una categoría que se denomina "No categorizado", para el caso de gestiones que deben pasar por aprobación, pero que deben ser registradas previamente.
En esencia, tu problema es funcional, no de estructuras de datos.

¿Se entiende?

[metalfox6383]

Muy claro y muy acertado. Muchas gracias. De esa forma se mantendría la existencia de la restricción y solucionaría el problema.

Saludos.

[metalfox6383]

Hola:

Como aporte técnico. Tal opción "Mandatory", que sólo está presente durante el diseño del diagrama de Base de Datos, es semejante a poner el campo FK en Not Null, es decir, si el FK en la tabla hija tiene como atributo Not Null, su valor es obligatorio y debe existir en la tabla padre, caso contrario, puede ir vacío.