Mensajes

Así es, una relación de cardinalidad N:M constituye una nueva entidad (tabla) que estará formada por las claves primarias de ambas tablas originales (que formarán conjuntamente la clave primaria de la nueva tabla) y los atributos de relación que pudiese haber (pudiendo ser alguno de ellos un discrimante y entonces habría que incluirlo en la clave primaria de la nueva tabla).

Código (sql) [Seleccionar] Expandir


CREATE TABLE [if not exists] Pedido (
  id_pedido INT PRIMARY KEY [auto_increment],
  ...
);

CREATE TABLE [if not exists] Producto (
  id_producto INT PRIMARY KEY [auto_increment],
  ...
);

-- Tabla resultante de la relacion:
CREATE TABLE [if not exists] Inventario (
  id_pedido INT,
  id_producto INT,
  cantidad INT [default 1], -- Cantidad del producto id_producto que hay en el pedido id_pedido, [por defecto: 1]
  PRIMARY KEY(id_pedido, id_producto),
  [CONSTRAINT FK_Inventario_Pedido] FOREIGN KEY (id_pedido) REFERENCES Pedido(id_pedido),
  [CONSTRAINT FK_Inventario_Producto] FOREIGN KEY (id_producto) REFERENCES Producto(id_producto)
);
Por ejemplo a esta relación le vendría bastante bien el atributo de relación <cantidad> para saber cuántos productos de cada tipo hay en cada pedido.
Las partes entre corchetes [] son opcionales y si se ponen tienes que quitar los corchetes.


El DELETE ON CASCADE tienes que incluirlo en la FOREIGN KEY de la tabla que quieres que se elimine en cascada, es decir, de la tabla opuesta a la que tú vas a borrar. En este caso si quieres que al eliminar un Pedido, se elimine un Pago, Pedido tiene que ser la tabla independiente (que no contiene la FK) y Pago será la dependiente.

Código (sql) [Seleccionar] Expandir


CREATE TABLE [if not exists] Pago (
  id_pago int primary key [auto_increment],
  ...
  id_pedido int,
  [constraint FK_Pago_Pedido] foreign key (id_pedido) references Pedido(id_pedido) ON DELETE CASCADE
);

Las claves foráneas quedarían así Id_vendedor en pedido, id_pedido en cliente, id_pago en pedido?
No tengo muy claro como crear la estructura con estas claves

No sé a qué te refieres con crearlas normal o como las he hecho yo...

Si te refieres a lo de crear una nueva tabla para la relación, eso es necesario únicamente para las relaciones con cardinalidad N:M. Digamos que la regla general es:

• Cardinalidad N:M -> Nueva tabla formada por las PKs de las dos tablas [+ discriminantes] como PK de la nueva, otros atributos de la relación y FKs de cada PK original a su tabla de origen.
  
• Cardinalidad 1:N -> La tabla con cardinalidad N contiene una FK a la PK de la tabla con cardinalidad 1.
  
• Cardinalidad 1:1 -> Una tabla contiene la FK a la PK de la otra. Cuál? Depende del problema muchas veces. La que más información aporte.
  
  Si te refieres al ON DELETE CASCADE, pues dependerá de lo que quieras eliminar en cascada o no.
  

Sí era eso, el crear una tabla adicional o crear las tablas sin más(con la FK, claro).

Así es, una relación de cardinalidad N:M constituye una nueva entidad (tabla) que estará formada por las claves primarias de ambas tablas originales (que formarán conjuntamente la clave primaria de la nueva tabla) y los atributos de relación que pudiese haber (pudiendo ser alguno de ellos un discrimante y entonces habría que incluirlo en la clave primaria de la nueva tabla).

Código (sql) [Seleccionar] Expandir


CREATE TABLE [if not exists] Pedido (
  id_pedido INT PRIMARY KEY [auto_increment],
  ...
);

CREATE TABLE [if not exists] Producto (
  id_producto INT PRIMARY KEY [auto_increment],
  ...
);

-- Tabla resultante de la relacion:
CREATE TABLE [if not exists] Inventario (
  id_pedido INT,
  id_producto INT,
  cantidad INT [default 1], -- Cantidad del producto id_producto que hay en el pedido id_pedido, [por defecto: 1]
  PRIMARY KEY(id_pedido, id_producto),
  [CONSTRAINT FK_Inventario_Pedido] FOREIGN KEY (id_pedido) REFERENCES Pedido(id_pedido),
  [CONSTRAINT FK_Inventario_Producto] FOREIGN KEY (id_producto) REFERENCES Producto(id_producto)
);
Por ejemplo a esta relación le vendría bastante bien el atributo de relación <cantidad> para saber cuántos productos de cada tipo hay en cada pedido.
Las partes entre corchetes [] son opcionales y si se ponen tienes que quitar los corchetes.


El DELETE ON CASCADE tienes que incluirlo en la FOREIGN KEY de la tabla que quieres que se elimine en cascada, es decir, de la tabla opuesta a la que tú vas a borrar. En este caso si quieres que al eliminar un Pedido, se elimine un Pago, Pedido tiene que ser la tabla independiente (que no contiene la FK) y Pago será la dependiente.

Código (sql) [Seleccionar] Expandir


CREATE TABLE [if not exists] Pago (
  id_pago int primary key [auto_increment],
  ...
  id_pedido int,
  [constraint FK_Pago_Pedido] foreign key (id_pedido) references Pedido(id_pedido) ON DELETE CASCADE
);

Entre las demás tablas y relaciones, habría que crearlas normal o como has hecho tú?

Hola a todos!

Me ha surgido un problema a la hora de crear una base de datos
El problema es que según entiendo se necesita una tabla adicional y tres claves foráneas y no sé muy bien como crear la sentencia que cree todo ello.

Un saludo.

En MySQL es obligatorio que cada sentencia termine con punto y coma a diferencia de SQL Server por ejemplo. Si un trigger tiene varias instrucciones, cada una tiene que terminar en punto y coma. Entonces para delimitar el trigger completo tienes que usar un delimitador diferente de ahí el DELIMITER $$.

En estos casos como el trigger solo tiene una instrucción, puedes obviar el BEGIN...END y así no necesitas usar DELIMITER. Pero para otros casos en los que tus triggers tengan más de una instrucción, estarás obligado a utilizarlo.

PD: Utiliza las etiquetas de Código GeSHi para mostrar código. En tu caso selecciona la correspondiente a SQL.

De acuerdo, para la próxima me lo apunto.
Gracias y un saludo.

Claro, exactamente. En el segundo caso sería AFTER DELETE ON.

Y en el tercer caso sustituir el INSERT/DELETE por UPDATE. Es más, te diría que igual se puede (y debería ser) AFTER UPDATE. Porque en el caso de que no se confirme la actualización, no quieres que se guarde ese "intento de cambio".
No puedo confirmártelo, lo siento, pero haz ambas pruebas y una de las dos tiene que funcionar seguro.

Suerte.

Ya lo tengo, al final me ha quedado así, no entiendo muy bien el por qué del  DELIMITER $$ etc pero nos lo exigen así.

DELIMITER $$
CREATE TRIGGER tr_persona_insert
AFTER INSERT ON persona
FOR EACH ROW
BEGIN
INSERT INTO logs1
VALUES ('insert', NEW.dni, NULL)
END;$$

DELIMITER $$
CREATE TRIGGER tr_persona_delete
AFTER DELETE ON persona
FOR EACH ROW
BEGIN
INSERT INTO logs1
VALUES ('insert', OLD.dni, NULL)
END;$$

DELIMITER $$
CREATE TRIGGER tr_persona_update
AFTER UPDATE ON persona
FOR EACH ROW
BEGIN
INSERT INTO logs1
VALUES ('update', OLD.dni, NEW.dni)
END;$$

En ese caso no puedes usar las tablas temporales INSERTED y DELETED pues estas son propias de SQL Server.
El símil que existe en MySQL son las partículas NEW y OLD antes del nombre de una columna.

El primer trigger quedaría:

Código (sql) [Seleccionar] Expandir


CREATE TRIGGER tr_persona_insert AFTER INSERT ON tb_persona FOR EACH ROW
  INSERT INTO tb_logs VALUES ('insert', new.dni, null);
La claúsula FOR EACH ROW sirve para los casos en los que insertas varios registros con una única sentencia INSERT. Así el trigger se ejecutará una vez por cada registro. El opuesto sería FOR EACH STATEMENT.

El siguiente trigger no tiene ninguna complicación. Tendrás que usar OLD en vez de NEW.

Para el tercer trigger, el de UPDATE, tendrás que usar BEFORE en vez de AFTER para poder acceder tanto al valor nuevo (NEW) como al viejo (OLD).

Inténtalo y comenta si tienes algún problema.
Suerte.

Hola, gracias por responder, voy a probar y te comento.
El segundo según lo que me comentas sería sustituir new por old, y también habría que sustituir Insert on por delete on?
Y en el tercero al igual que en el segundo habría que sustituir algún valor más?

- La sintaxis varía dependiendo del Motor de Base de Datos, en mi caso utilicé SQL Server. ¿Qué Motor estás utilizando? => SQL Server, MySQL, PosgreSQL, SQLite, Oracle, etc, etc...

MariaDB que creo que es MySQL

[Mis resultados:]

Saludos,

- Veo unas discrepancias entre tu modelo de datos, el enunciado y tus ejemplos ... Por ejemplo si yo inserto '33333333Z' no es lógico que se guarde '33333333W' como nuevo_valor XD. Por otro lado si actualizo '33333333Z' a '22222222H', lo lógico que se guarde como nuevo _valor '33333333Z' XD

- Voy a considerar lo que yo considero lógico, luego puedes hacer las correcciones que veas convenientes. Además voy a suponer que estás utilizando Microsoft SQL Server, si no es el caso puedes avisar.

Código (sql) [Seleccionar] Expandir

/*
USE master
DROP DATABASE db_prueba
*/

CREATE DATABASE db_prueba
GO
USE db_prueba

CREATE TABLE tb_persona (
  dni    CHAR(9),
  nombre VARCHAR(50)
)

INSERT INTO tb_persona VALUES
( '11111111X', 'jaimico' )

CREATE TABLE tb_logs (
  accion      CHAR(6),
  nuevo_valor CHAR(9),
  viejo_valor CHAR(9)
)

GO
CREATE TRIGGER tr_persona_insert ON tb_persona
AFTER INSERT AS
INSERT INTO tb_logs VALUES
( 'insert', (SELECT dni FROM INSERTED), NULL )

GO
CREATE TRIGGER tr_persona_delete ON tb_persona
AFTER DELETE AS
INSERT INTO tb_logs VALUES
( 'delete', NULL, (SELECT dni FROM DELETED) )

GO
CREATE TRIGGER tr_persona_update ON tb_persona
AFTER UPDATE AS
INSERT INTO tb_logs VALUES
( 'update', (SELECT dni FROM INSERTED), (SELECT dni FROM DELETED) )

///////////////////////////////////
INSERT INTO tb_persona VALUES
('33333333Z', 'paco')
SELECT * FROM tb_logs

DELETE FROM tb_persona
WHERE dni = '11111111X'
SELECT * FROM tb_logs

UPDATE tb_persona
SET dni = '22222222H'
WHERE dni = '33333333Z'
SELECT * FROM tb_logs

Mis resultados:

Código [Seleccionar] Expandir

+--------+-------------+-------------+
| accion | nuevo_valor | viejo_valor |
+--------+-------------+-------------+
| insert | 33333333Z   | NULL        |
+--------+-------------+-------------+
| delete | NULL        | 11111111X   |
+--------+-------------+-------------+
| update | 22222222H   | 33333333Z   |
+--------+-------------+-------------+

- En SQL Server exiten las tablas predeterminadas INSERTED y DELETED que solo existen para los TRIGGER, dependiendo de la Acción realizada estos contienen los campos Insertados, Actualizados o Eliminados:

Hola de nuevo, estoy usando tu código y me genera errores en todo el código.
Estoy usando HeidiSql.

[Mis resultados:]

Saludos,

- Veo unas discrepancias entre tu modelo de datos, el enunciado y tus ejemplos ... Por ejemplo si yo inserto '33333333Z' no es lógico que se guarde '33333333W' como nuevo_valor XD. Por otro lado si actualizo '33333333Z' a '22222222H', lo lógico que se guarde como nuevo _valor '33333333Z' XD

- Voy a considerar lo que yo considero lógico, luego puedes hacer las correcciones que veas convenientes. Además voy a suponer que estás utilizando Microsoft SQL Server, si no es el caso puedes avisar.

Código (sql) [Seleccionar] Expandir

/*
USE master
DROP DATABASE db_prueba
*/

CREATE DATABASE db_prueba
GO
USE db_prueba

CREATE TABLE tb_persona (
  dni    CHAR(9),
  nombre VARCHAR(50)
)

INSERT INTO tb_persona VALUES
( '11111111X', 'jaimico' )

CREATE TABLE tb_logs (
  accion      CHAR(6),
  nuevo_valor CHAR(9),
  viejo_valor CHAR(9)
)

GO
CREATE TRIGGER tr_persona_insert ON tb_persona
AFTER INSERT AS
INSERT INTO tb_logs VALUES
( 'insert', (SELECT dni FROM INSERTED), NULL )

GO
CREATE TRIGGER tr_persona_delete ON tb_persona
AFTER DELETE AS
INSERT INTO tb_logs VALUES
( 'delete', NULL, (SELECT dni FROM DELETED) )

GO
CREATE TRIGGER tr_persona_update ON tb_persona
AFTER UPDATE AS
INSERT INTO tb_logs VALUES
( 'update', (SELECT dni FROM INSERTED), (SELECT dni FROM DELETED) )

///////////////////////////////////
INSERT INTO tb_persona VALUES
('33333333Z', 'paco')
SELECT * FROM tb_logs

DELETE FROM tb_persona
WHERE dni = '11111111X'
SELECT * FROM tb_logs

UPDATE tb_persona
SET dni = '22222222H'
WHERE dni = '33333333Z'
SELECT * FROM tb_logs

Mis resultados:

Código [Seleccionar] Expandir

+--------+-------------+-------------+
| accion | nuevo_valor | viejo_valor |
+--------+-------------+-------------+
| insert | 33333333Z   | NULL        |
+--------+-------------+-------------+
| delete | NULL        | 11111111X   |
+--------+-------------+-------------+
| update | 22222222H   | 33333333Z   |
+--------+-------------+-------------+

- En SQL Server exiten las tablas predeterminadas INSERTED y DELETED que solo existen para los TRIGGER, dependiendo de la Acción realizada estos contienen los campos Insertados, Actualizados o Eliminados:

Hola!, muchas gracias por responder y también por indicar los errores en el enunciado del ejercicio, ha sido un error al copiar el enunciado ya que estoy trabajando a parte con otro ejercicio y he mezclado los datos
Un saludo