elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Entrar al Canal Oficial Telegram de elhacker.net


+  Foro de elhacker.net
|-+  Programación
| |-+  Desarrollo Web
| | |-+  Bases de Datos (Moderador: Carloswaldo)
| | | |-+  Pasar a MySQL
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] 2 Ir Abajo Respuesta Imprimir
Autor Tema: Pasar a MySQL  (Leído 7,544 veces)
thebus4k

Desconectado Desconectado

Mensajes: 39


Ver Perfil
Pasar a MySQL
« en: 31 Mayo 2020, 02:12 am »

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


« Última modificación: 3 Junio 2020, 19:43 pm por thebus4k » En línea

K-YreX


Desconectado Desconectado

Mensajes: 1.008



Ver Perfil
Re: Pasar modelo entidad relacion a MySQL
« Respuesta #1 en: 31 Mayo 2020, 09:25 am »

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
  1. CREATE TABLE [IF NOT EXISTS] Pedido (
  2.  id_pedido INT PRIMARY KEY [AUTO_INCREMENT],
  3.  ...
  4. );
  5.  
  6. CREATE TABLE [IF NOT EXISTS] Producto (
  7.  id_producto INT PRIMARY KEY [AUTO_INCREMENT],
  8.  ...
  9. );
  10.  
  11. -- Tabla resultante de la relacion:
  12. CREATE TABLE [IF NOT EXISTS] Inventario (
  13.  id_pedido INT,
  14.  id_producto INT,
  15.  cantidad INT [DEFAULT 1], -- Cantidad del producto id_producto que hay en el pedido id_pedido, [por defecto: 1]
  16.  PRIMARY KEY(id_pedido, id_producto),
  17.  [CONSTRAINT FK_Inventario_Pedido] FOREIGN KEY (id_pedido) REFERENCES Pedido(id_pedido),
  18.  [CONSTRAINT FK_Inventario_Producto] FOREIGN KEY (id_producto) REFERENCES Producto(id_producto)
  19. );
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
  1. CREATE TABLE [IF NOT EXISTS] Pago (
  2.  id_pago INT PRIMARY KEY [AUTO_INCREMENT],
  3.  ...
  4.  id_pedido INT,
  5.  [CONSTRAINT FK_Pago_Pedido] FOREIGN KEY (id_pedido) REFERENCES Pedido(id_pedido) ON DELETE CASCADE
  6. );


En línea

Código
  1. cout << "Todos tenemos un defecto, un error en nuestro código" << endl;
thebus4k

Desconectado Desconectado

Mensajes: 39


Ver Perfil
Re: Pasar modelo entidad relacion a MySQL
« Respuesta #2 en: 31 Mayo 2020, 11:14 am »

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
  1. CREATE TABLE [IF NOT EXISTS] Pedido (
  2.  id_pedido INT PRIMARY KEY [AUTO_INCREMENT],
  3.  ...
  4. );
  5.  
  6. CREATE TABLE [IF NOT EXISTS] Producto (
  7.  id_producto INT PRIMARY KEY [AUTO_INCREMENT],
  8.  ...
  9. );
  10.  
  11. -- Tabla resultante de la relacion:
  12. CREATE TABLE [IF NOT EXISTS] Inventario (
  13.  id_pedido INT,
  14.  id_producto INT,
  15.  cantidad INT [DEFAULT 1], -- Cantidad del producto id_producto que hay en el pedido id_pedido, [por defecto: 1]
  16.  PRIMARY KEY(id_pedido, id_producto),
  17.  [CONSTRAINT FK_Inventario_Pedido] FOREIGN KEY (id_pedido) REFERENCES Pedido(id_pedido),
  18.  [CONSTRAINT FK_Inventario_Producto] FOREIGN KEY (id_producto) REFERENCES Producto(id_producto)
  19. );
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
  1. CREATE TABLE [IF NOT EXISTS] Pago (
  2.  id_pago INT PRIMARY KEY [AUTO_INCREMENT],
  3.  ...
  4.  id_pedido INT,
  5.  [CONSTRAINT FK_Pago_Pedido] FOREIGN KEY (id_pedido) REFERENCES Pedido(id_pedido) ON DELETE CASCADE
  6. );
Entre las demás tablas y relaciones, habría que crearlas normal o como has hecho tú?
En línea

K-YreX


Desconectado Desconectado

Mensajes: 1.008



Ver Perfil
Re: Pasar modelo entidad relacion a MySQL
« Respuesta #3 en: 31 Mayo 2020, 11:23 am »

Entre las demás tablas y relaciones, habría que crearlas normal o como has hecho tú?
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.
En línea

Código
  1. cout << "Todos tenemos un defecto, un error en nuestro código" << endl;
thebus4k

Desconectado Desconectado

Mensajes: 39


Ver Perfil
Re: Pasar modelo entidad relacion a MySQL
« Respuesta #4 en: 31 Mayo 2020, 11:34 am »

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).
En línea

thebus4k

Desconectado Desconectado

Mensajes: 39


Ver Perfil
Re: Pasar modelo entidad relacion a MySQL
« Respuesta #5 en: 31 Mayo 2020, 17:19 pm »

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
  1. CREATE TABLE [IF NOT EXISTS] Pedido (
  2.  id_pedido INT PRIMARY KEY [AUTO_INCREMENT],
  3.  ...
  4. );
  5.  
  6. CREATE TABLE [IF NOT EXISTS] Producto (
  7.  id_producto INT PRIMARY KEY [AUTO_INCREMENT],
  8.  ...
  9. );
  10.  
  11. -- Tabla resultante de la relacion:
  12. CREATE TABLE [IF NOT EXISTS] Inventario (
  13.  id_pedido INT,
  14.  id_producto INT,
  15.  cantidad INT [DEFAULT 1], -- Cantidad del producto id_producto que hay en el pedido id_pedido, [por defecto: 1]
  16.  PRIMARY KEY(id_pedido, id_producto),
  17.  [CONSTRAINT FK_Inventario_Pedido] FOREIGN KEY (id_pedido) REFERENCES Pedido(id_pedido),
  18.  [CONSTRAINT FK_Inventario_Producto] FOREIGN KEY (id_producto) REFERENCES Producto(id_producto)
  19. );
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
  1. CREATE TABLE [IF NOT EXISTS] Pago (
  2.  id_pago INT PRIMARY KEY [AUTO_INCREMENT],
  3.  ...
  4.  id_pedido INT,
  5.  [CONSTRAINT FK_Pago_Pedido] FOREIGN KEY (id_pedido) REFERENCES Pedido(id_pedido) ON DELETE CASCADE
  6. );
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
En línea

K-YreX


Desconectado Desconectado

Mensajes: 1.008



Ver Perfil
Re: Pasar modelo entidad relacion a MySQL
« Respuesta #6 en: 31 Mayo 2020, 20:58 pm »

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
Mira a ver si tal y como tú dices se cumplen las normas que te puse antes sobre cómo establecer las relaciones.
Ya te adelanto que la segunda no lo cumple.
Y la tercera ya te lo puse yo con la clave de id_pedido en Pago, no sé si de verdad necesitas guardarlo al revés también.
En línea

Código
  1. cout << "Todos tenemos un defecto, un error en nuestro código" << endl;
thebus4k

Desconectado Desconectado

Mensajes: 39


Ver Perfil
Re: Pasar modelo entidad relacion a MySQL
« Respuesta #7 en: 1 Junio 2020, 00:21 am »

Mira a ver si tal y como tú dices se cumplen las normas que te puse antes sobre cómo establecer las relaciones.
Ya te adelanto que la segunda no lo cumple.
Y la tercera ya te lo puse yo con la clave de id_pedido en Pago, no sé si de verdad necesitas guardarlo al revés también.
No sería necesario guardarlo al revés creo yo, solo necesito lo que puse en la primera entrada(no estoy seguro xdd)
En línea

K-YreX


Desconectado Desconectado

Mensajes: 1.008



Ver Perfil
Re: Pasar modelo entidad relacion a MySQL
« Respuesta #8 en: 1 Junio 2020, 00:34 am »

No sería necesario guardarlo al revés creo yo, solo necesito lo que puse en la primera entrada(no estoy seguro xdd)
Pues entonces con tener la relación hecha en el otro sentido ya vale. Además la importante es la que te permite borrar el pago automáticamente cuando borras el pedido relacionado. Así que ya sabes: esa no hace falta y la otra la estabas poniendo al revés. Ahora te toca hacerlo en MySQL.
En línea

Código
  1. cout << "Todos tenemos un defecto, un error en nuestro código" << endl;
thebus4k

Desconectado Desconectado

Mensajes: 39


Ver Perfil
Re: Pasar modelo entidad relacion a MySQL
« Respuesta #9 en: 1 Junio 2020, 11:27 am »

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
  1. CREATE TABLE [IF NOT EXISTS] Pedido (
  2.  id_pedido INT PRIMARY KEY [AUTO_INCREMENT],
  3.  ...
  4. );
  5.  
  6. CREATE TABLE [IF NOT EXISTS] Producto (
  7.  id_producto INT PRIMARY KEY [AUTO_INCREMENT],
  8.  ...
  9. );
  10.  
  11. -- Tabla resultante de la relacion:
  12. CREATE TABLE [IF NOT EXISTS] Inventario (
  13.  id_pedido INT,
  14.  id_producto INT,
  15.  cantidad INT [DEFAULT 1], -- Cantidad del producto id_producto que hay en el pedido id_pedido, [por defecto: 1]
  16.  PRIMARY KEY(id_pedido, id_producto),
  17.  [CONSTRAINT FK_Inventario_Pedido] FOREIGN KEY (id_pedido) REFERENCES Pedido(id_pedido),
  18.  [CONSTRAINT FK_Inventario_Producto] FOREIGN KEY (id_producto) REFERENCES Producto(id_producto)
  19. );
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
  1. CREATE TABLE [IF NOT EXISTS] Pago (
  2.  id_pago INT PRIMARY KEY [AUTO_INCREMENT],
  3.  ...
  4.  id_pedido INT,
  5.  [CONSTRAINT FK_Pago_Pedido] FOREIGN KEY (id_pedido) REFERENCES Pedido(id_pedido) ON DELETE CASCADE
  6. );
Hola de nuevo releyendo me he encontrado con esto: El campo BANCO es un string que representa el nombre del BANCO. (los datos concretos de pago como numero de cuenta se encuentran alojados en otra tabla a la cual se accede a través del número de control)
Lo que me raya la cabeza es el contenido del paréntesis, que significa, por más que intento comprender no entiendo lo que se pide.
En línea

Páginas: [1] 2 Ir Arriba Respuesta Imprimir 

Ir a:  

WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines