Ver Mensaje Individual
  #7 (permalink)  
Antiguo 06/09/2011, 11:06
Avatar de gnzsoloyo
gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 16 años, 5 meses
Puntos: 2658
Respuesta: error al crear tablas vida o muerte plis

Hay dos cosas que debes tener en cuenta a la hora de definir claves:
1) Una clave primaria es un atributo o conjunto de atributos que identifican unívocamente un registro en una tabla (definición general).
Esto significa que:
- Si tienes un campo que por si mismo es capaz de identificar un registro dado, no necesitas poner más que uno como PK.
- Si y sólo si no es suficiente con un campo, puede usarse para hacer una PK varios al mismo tiempo.
- Es preferible siempre usar un campo cuyo valor sea propio de la entidad representada.

En tu caso, en la tabla "tienda" ya tienes un campo numérico autoincremental, el cual jamás se repetirá. ¿Para qué creas esa PK con dos campos, entonces?
Eso mismo lo estás haciendo con "Pedidos" y "Usuario". Nada de eso tiene sentido.

En el caso de "Usuario", el hecho de que un usuario tenga un username posible irrepetible hace que no se necesite ningún otro dato. No tiene ninguna utilidad en ese caso hacer un autoincremental para ello. Resulta redundante.

2) Una FOREIGN KEY es un campo o conjunto de campos que hacen referencia a la clave primaria de otra tabla.
Las FK surgen de las relaciones entre entidades (tablas en el modelo físico de BBDD), y se ajustan a la cardinalidad de las relaciones.
- En una relación 1:1, la PK va como FK en aquella donde exista correspondencia lógica. El ejemplo sería que la matrícula pertenece a un único vehículo. En ese caso la PK de Matrícula va en vehículo y lno a la inversa.
- En las relaciones 1:N, las PK van como FK en la tabla donde la cardinalidad sea N.
- Las relaciones N:N no transfieren su Pk como FK a la otra tabla, sino que se debe generar una tercera tabla (relacional) que administre la relación. En esa tabla ambas PK van como FK y al mismo tiempo ambas son PK de esa tabla.

Lo que debe quedarte claro es que una FK, como se refiere a una PK de una tabla debe tener la misma cantidad de campos que la PK original, del mismo tipo y ser del mismo rango. Eso es una de las cosas que no estás respetando.

Algunas observaciones que se pueden hacer son, por ejemplo:
- Tienes dos identificadores posibles para "Tienda": tienda_id y tienda. ¿Por qué? Sólo necesitas uno, y si las tiendas en cuestión tienen su propia designación en la empresa, es esa designación la que debes usar. La otra es superflua.
- Usuario puede utilizar un username como identificador, o bien el e-mail. Es más eficiente como dato. Si vas a usar una numeración específica, bien, pero que tenga sentido dentro del ssitema y debe ser la misma que se usa en cualquier otro tipo de documentación no informática que exista.
- La tabla Producto no debe contener el numero de tienda. En todo caso lo que te falta es una tabla para controlar el stock de la tienda, ya que una tienda puede tener muchos productos y cada producto estar en diferentes tiendas (relación N.N). Eso requiere de una tabla específica.
- La tabla usuario_user parece redundante respecto a la tabla usuarios. ¿Qué representa?
- Tablas del tipo Factura se deben desdoblar en Factura y Detalle. Revisa el tema de Formas Normales para una mejor comprensión.

Consejo final (por ahora): Estudia un poco más del modelo entidad-relación y de diseño de bases de datos antes de meterte a planear sistemas algo elaborados como el que quieres hacer, o terminarás inventando la rueda varias veces antes de completarlo.

Suerte...
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)