Bases de Datos - Problema con las Relaciones en una Base de Datos

Hola amigos! estoy diseñando una base de datos, aun no la he creado ya que apenas estoy modelándola y me surgió una duda con respecto a las relaciones, en especifico no sé si estoy creando relaciones cíclicas o estoy creando una base de datos poco eficiente o con información redundante,

En esta primera imagen tengo la base de datos tengo relacionada la tabla "Clientes" con: "Pedidos", "Envios" y "Direcciones", no se si estoy creando una relación cíclica o si es redundante colocar en Envíos y en Pedidos el "IdClientes"



En esta imagen estoy eliminado esas relaciones y simplemente dejando una relación de la tabla "Clientes" con "Direcciones"
Ya que existe la relación entre "Envios" y "Direcciones" y como cada dirección solo puede pertenecer a un solo cliente es redundante colocar también IdDliente en "Envios" ? el mismo caso que Pedidos que esta unida con "Envios" y esta a su vez a "Direcciones"



Gracias de antemano!!

Hola:

Lo que planteas es correcto pero poco funcional...

Si el dia de mañana quieres un informe que te diga pedidos pertenecen a que cliente, tendrias que involucrar la tabla envios para saberlo, de tal modo que consultarias mas informacion que NO usaras para obtener el mismo Resultado afectando el performance de tu aplicacion.

Por experiencia te diria que a pesar que suena reduntante el primer planteamiento es mas adecuado, vaya cuando la regla de Normalizacion te habla de evitar duplicar informacion o eliminar redundancia, quiere decir que no pongas el NOMBRE del CLIENTE (por ejemplo) en todas las tablas, pero tener un apuntador (identificador) a modo de llave foranea no esta mal, y a la larga puede ser benefico.

Saludos

Muchas gracias!!

tenia esa duda, es la primera base de datos medianamente grande que hago, muchas gracias por la ayuda,

saludos!!

Yo parto siempre de un modelo Entidad-Relación para evitar redundancias.

Por ejemplo:
pedidos y productos-pedidos (que es entidad débil de pedidos) -> presenta una relación 1 a muchos en la que la clave de productos-pedidos sería idproducto y idpedido.

unificados -> presenta una relación 1 a muchos con pedidos (lo más fácil es eliminar esta tabla y añadir el idunificado a la tabla pedidos, eso se llama propagación de clave). Si unificados tuviera más atributos podrías conservar la tabla, pero la clave sería idpedido)

precios_categoría -> contiene un atributo multivalor llamado precios (son en realidad 7 precios). En este caso se crea una nueva tabla llamada precios cuya clave principal sería idcategoría y idprecio). La tabla categorías queda igual (quitando los atributos precios). Hay una clave foránea de precios a categorías.

envíos y pedidos -> relación 1 a 1 puedes poner idpedido en envíos o idenvío en pedidos.

envíos con clientes y direcciones -> buena propagación de clave de cliente a direcciones (1 a muchos) y de direcciones a envíos (1 a muchos).

No hay redundancias pero una base de datos casi siempre es mejorable. Por ejemplo, unir pedidos con clientes es la mejor opción, y a partir de allí desarrollar la base de datos. El envio nunca lo uniría con el cliente como has hecho, solamente con el pedido (es el pedido el que se une con el cliente). Como regla general piensa cuál es la tabla más importante (pedidos para el negocio) y a partir de ahí desarrolla (clientes, envíos, etc.).
Espero no haberte liado jejeje