Cita: La clave primaria de esta tercera tabla es la fecha del pedido, pero no es unique ya que puede haber la misma fecha para varios clientes que realicen un pedido el mismo día. Para mi ya funcionaría en la práctica pero la pregunta es, ¿sería necesario, por no decir obligatorio, poner una clave primaria unique que fuera una sucesión tipo 1, 2, 3, 4, ....?
Por empezar,
todas, absolutamente todas las claves primarias son UNIQUE. Eso es una condición necesaria y obligatoria de las PK por su propia definición: "Campo o conjunto de campos que identifica
univocamente un registro determinado de una tabla".
Ahora bien, desde el punto de vista de las base de datos relacionales, una tabla que depende de otras para existir, es la representación de una entidad débil, por lo que hereda la clave de otra.
Pero la tabla Pedido puede consierarse o parte de una relación N:N o una entidad independiente. Eso dependerá del análisis del sistema.
Si lo consideramos como parte de una relación N:N, la herencia de las claves de las otras dos tablas debería ser suficiente. Pero sucede que un cliente puede tener muchos pedidos, en diferentes instantes del tiempo, por lo que las dos claves no son suficientes. Necesitan del atributo de tiempo para completar la clave, ya que lo que seguro que no puede existir es dos pedidos del mismo cliente, creados en el mismo momento.
Ergo, La PK debería estar compuesta por PK de Cliente, Pk de Artículo y Fecha_Hora cuando se ejecuta.
Así podría andar, pero no es correcto...
Un Pedido es, conceptualmente, una entidad independiente, la cual tiene un identificador propio del sistema (usualmente sucursal y numero de emisión), y está relacionado con un cliente y una lista de items.
En ese sentido, la PK está formada por el identificador que el sistema requiera, no hay una regla universal, pero es muy común numerar secuencialmente los documentos. Además, tiene otros atributos que son mandatorios: Pk del Cliente del pedido, Lista de Ids y cantidades de articulos, fecha de emisión del docucmento, fecha de entrega pactada del pedido, y algún otro que el sistema requiera. Todos estos atributos deben ser NOT NULL, pero no UNIQUE, y algunos de ellos serán FK.
Esto no queda acá, porque esa tabla aún debe ser normalizada, lo que generará al menos dos tablas: Pedido y DetallePedido. Pero ese es otro tema.
Finalmente: El modelo E-R determina que cada entidad debe tener una PK, pero
no especifica que sea numérica e incremental. Sólo que debe existir, debe ser
única y
no puede ser nula.
Se usan incrementales por costumbre, pero en determinados contextos traen más problemas que ventajas. Lo mejor, a mi juicio, es buscar qué atributos natural de la entidad puede ser el identificador (determinante) de la misma. Generalmente esa es la mejor PK.
¿Se va entendiendo el tema?
