Calve foránea igual a clave primaria

[kabe_jrr]

Hola amigos:

Me gustaría saber si tiene sentido que en una tabla se pongan claves foráneas que están incluidas en la primaria. Es decir, algo como esto:

Código:

CREATE TABLE Pedido ( 
idPedido INT(4) NOT NULL AUTO_INCREMENT, 
idCliente INT(4) NOT NULL, 
cifRestaurante VARCHAR(9) NOT NULL, 
primer_plato VARCHAR(50), 
segundo_plato VARCHAR(50), 
postre VARCHAR(50), 
precio FLOAT(3,2),
PRIMARY KEY (idPedido, idCliente, cifRestaurante),
FOREIGN KEY(idCliente) REFERENCES Cliente(idCliente)
ON DELETE CASCADE ON UPDATE CASCADE,
FOREIGN KEY(cifRestaurante) REFERENCES Restaurante(cif)
ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB;

Donde los campos "idCliente" y "cifRestaurante" que están en PRIMARY KEY, a su vez estén como FOREIGN KEY (referenciando a otras tablas de la base de datos.

¿Tiene sentido? Muchísimas gracias de antemano!!

[quimfv]

PRIMARY KEY (idPedido, idCliente, cifRestaurante),

Lo raro es esto, segun esto el pedio X (idPedido=X) peude ser de varios clientes ....?

Lo normal es que los pedidos tengan un identificador único, no dependiente de clientes.

idCliente, cifRestaurante entendiendo que el cliente será un restaurante tampoco tiene mucho sentido mezclar por ahí el cif que en principio será tambien único.

Finalmente y suponiendo que la PK es correcta, por que los pedidos efectivamente se desglosan en clientes y restaurantes, SI tiene todo el sentido del mundo que idCliente sea una FK a la tabla clientes, si el resutaurante y el cliente son lo mismo luego no tiene sentido hacer otra FK con el cifRestaurante ya que apuntarà a lo mismo....si no són lo mismo obviamente tambien tiene todo el sentido del mundo esa FK.

Repasa la función de las PK y las FK

[gnzsoloyo]

Iniciado por kabe_jrr

Hola amigos:

Me gustaría saber si tiene sentido que en una tabla se pongan claves foráneas que están incluidas en la primaria. Es decir, algo como esto:

Código:

CREATE TABLE Pedido ( 
idPedido INT(4) NOT NULL AUTO_INCREMENT, 
idCliente INT(4) NOT NULL, 
cifRestaurante VARCHAR(9) NOT NULL, 
primer_plato VARCHAR(50), 
segundo_plato VARCHAR(50), 
postre VARCHAR(50), 
precio FLOAT(3,2),
PRIMARY KEY (idPedido, idCliente, cifRestaurante),
FOREIGN KEY(idCliente) REFERENCES Cliente(idCliente)
ON DELETE CASCADE ON UPDATE CASCADE,
FOREIGN KEY(cifRestaurante) REFERENCES Restaurante(cif)
ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB;

Donde los campos "idCliente" y "cifRestaurante" que están en PRIMARY KEY, a su vez estén como FOREIGN KEY (referenciando a otras tablas de la base de datos.

¿Tiene sentido? Muchísimas gracias de antemano!!

Tienen perfecto sentido si es una relación entre dos o más entidades, donde existe una dependencia funcional. En tu caso habría que ver el modelo un poco más compelto para saber si está bien diseñao pero la base es correcta.
Un mismo restaurante y un cliente pueden tener N pedidos, cada uno de los cuales tiene su discriminante, que es el ID pedido.
Lo que no podrá existir es que se repita el mismo IDPEDIDO para el mismo cliente y restaurante.
Personalmente le veo el defecto de que podrías usar el mismo IDpedido paras más de una dupla de Cliente+Restaurante, por lo que me da la impresión que podría existir un error de diseño. Pero sin ver el conjunto completo y saber cuáles son las reglas de negocio aplicables a los pedidos, no se puede decir mucho más.

[kabe_jrr]

Hola quimfv, gracias por tu respuesta:

Bueno... es que realmente no expliqué el sentido de la tabla PEDIDO... El restaurante no es el cliente, es quien recoge los pedidos de los clientes. Y la tabla PEDIDO, en el diagrama Entidad/Relación está indicada como entidad débil, necesitando de los datos del cliente y del restaurante para existir... Vamos, que por una parte está la entidad RESTAURANTE y por otra CLIENTE, y luego están los pedidos que los clientes hacen al restaurante.

Espero estar explicándome bien... De todas formas esa no era la cuestión que planteaba (aun así, muchas gracias por supuesto! XD ). Por lo que dices, entonces ya me quedo tranquilo sabiendo que si se supone que tal y como he planteado la tabla está bien definida la clave, lo de las FK (idCliente y cifRestaurante) está bien al crear la tabla con MySQL.

Lo dicho: ¡¡Muchas gracias!!

[kabe_jrr]

Iniciado por gnzsoloyo

Tienen perfecto sentido si es una relación entre dos o más entidades, donde existe una dependencia funcional. En tu caso habría que ver el modelo un poco más compelto para saber si está bien diseñao pero la base es correcta.
Un mismo restaurante y un cliente pueden tener N pedidos, cada uno de los cuales tiene su discriminante, que es el ID pedido.
Lo que no podrá existir es que se repita el mismo IDPEDIDO para el mismo cliente y restaurante.
Personalmente le veo el defecto de que podrías usar el mismo IDpedido paras más de una dupla de Cliente+Restaurante, por lo que me da la impresión que podría existir un error de diseño. Pero sin ver el conjunto completo y saber cuáles son las reglas de negocio aplicables a los pedidos, no se puede decir mucho más.

Qué bien, muchas gracias a ti también. En realidad lo que más me interesaba de la creación de la tabla era saber si se podía indicar lo de las PK también como FK, y por lo que veo sí que se puede, gracias a tu respuesta, y a la anterior.

¡Saludos!

[gnzsoloyo]

Por lo que describas ahora, hay un fallo en el modelado de pedido, porque estás poniendo el pedido y el detalle del pedido en una msima tabla, y eso no está bien.
Necesitas normalizar la tabla de Pedido.
No te olvides que el diagrama Entidad-relación no representa el esquema de tablas que realmente se implementa, sino sólo las entidades a nivel lógico.
el paso a tablas físicas requiere un analisisi más cuidadoso.

[kabe_jrr]

Iniciado por gnzsoloyo

Por lo que describas ahora, hay un fallo en el modelado de pedido, porque estás poniendo el pedido y el detalle del pedido en una msima tabla, y eso no está bien.
Necesitas normalizar la tabla de Pedido.
No te olvides que el diagrama Entidad-relación no representa el esquema de tablas que realmente se implementa, sino sólo las entidades a nivel lógico.
el paso a tablas físicas requiere un analisisi más cuidadoso.

Sí, lo sé... bueno en este caso no es necesario normalizar la tabla. Como bien dices, en el mundo real sí lo sería, pero para este caso concreto, me es indiferente.

¡Gracias!

Iniciado por gnzsoloyo

Por lo que describas ahora, hay un fallo en el modelado de pedido, porque estás poniendo el pedido y el detalle del pedido en una msima tabla, y eso no está bien.
Necesitas normalizar la tabla de Pedido.
No te olvides que el diagrama Entidad-relación no representa el esquema de tablas que realmente se implementa, sino sólo las entidades a nivel lógico.
el paso a tablas físicas requiere un analisisi más cuidadoso.

Supongo que a la hora de normalizar, por un lado debería poner en una nueva tabla el detalle del pedido (id, primer_plato, segundo_plato, postre, precio) y luego en la tabla que tengo como PEDIDO, poner (idPedido, idCliente, cifRestaurante)...

[gnzsoloyo]

Supongo que a la hora de normalizar, por un lado debería poner en una nueva tabla el detalle del pedido (id, primer_plato, segundo_plato, postre, precio) y luego en la tabla que tengo como PEDIDO, poner (idPedido, idCliente, cifRestaurante)...

No exactamente. Las necesidades de normalización probablemente llevarían esa única tabla a más de siete, en realidad.
¿Qué pasaría si un pedido no incluye postre, o no tiene segundo plato, o el cliente quiere cuatro platos y no dos?
Esas cosas sólo pueden surgir del relevamiento de las reglas de negocio, y el diseño de tablas que hagas requiere cumplir con la regla cero: Debe ser flexible a los cambios de entorno. Y el esquema que porpones no lo es.
Incluso el precio no puede ser parte de esa tabla. El precio surge de listas de precio donde se ponen los valores para cada producto (plato), el cual a su vez debería estar categorizado.
Básicamente, incluso considerado como modelado de entidad-relación, tiene fallas que vas a arrastrar luego a tu práctica laboral.
Es siemrpe preferible hacerlo bien de entrada. Reparar cosas mal resueltas lleva un enorme esfuerzo.

[kabe_jrr]

Iniciado por gnzsoloyo

No exactamente. Las necesidades de normalización probablemente llevarían esa única tabla a más de siete, en realidad.
¿Qué pasaría si un pedido no incluye postre, o no tiene segundo plato, o el cliente quiere cuatro platos y no dos?
Esas cosas sólo pueden surgir del relevamiento de las reglas de negocio, y el diseño de tablas que hagas requiere cumplir con la regla cero: Debe ser flexible a los cambios de entorno. Y el esquema que porpones no lo es.
Incluso el precio no puede ser parte de esa tabla. El precio surge de listas de precio donde se ponen los valores para cada producto (plato), el cual a su vez debería estar categorizado.
Básicamente, incluso considerado como modelado de entidad-relación, tiene fallas que vas a arrastrar luego a tu práctica laboral.
Es siemrpe preferible hacerlo bien de entrada. Reparar cosas mal resueltas lleva un enorme esfuerzo.

Entiendo... Entonces con esto de la normalización, ¿podrías darme tu opinión sobre otro hilo que abrí no hace mucho? Está localizado aquí