Varias preguntas

[speaK121]

Hola buenas tardes,

Primero de todo explicaros que hace ya muchos años estudié un módulo de diseño de aplicaciones, pero por cosas de la vida no volví a tomar contacto con la materia; por lo que si lo que pregunto es muy básico perdonadme, pero me estoy volviendo un poco tarumba con el tema.

Os cuento, estoy desarrollando una aplicación para mi negocio, más o menos tengo las tablas y relaciones creadas, pero tengo un problema que me desquicia con respecto a la relación de una de ellas.

Tablas:
- PROVEEDOR : Datos del proveedor. Clave primaria: IDProve
- ARTICULO : Datos de los artículos sin precio de coste ni de venta. Clave primaria: IDArticulo (código EAN)
- ARPRO : Tabla resultante de la relación N:N que se forma entre AR(TICULO) y PRO(VEEDOR). En esta tabla si se almacena precio de coste y de venta, junto con un código que es el utilizado por el proveedor para este artículo. Clave primaria: IDProve, IDArticulo, IDCod
- DETALLE: El detalle de la factura que se pretende generar. Clave primaria: IDDetalle



Situación:
1 . Los proveedores pueden tener muchos artículos y cada artículo es suministrado por varios proveedores (relación N:N).
2 . Por cada proveedor el precio de coste es distinto.
3 . Cada proveedor que me suministra un artículo no siempre lo suministra al mismo precio, puesto que sacan ofertas puntuales, estando en stock de mi tienda el articulo con dos precios diferentes. Lo único que cambia es el código que maneja el proveedor, por lo que añado la tercera clave primaria a ARPRO.

Problema:
Al ser la tabla ARPRO una tabla resultante de una relación N:N, no sé si esta bien haber añadido una tercera clave primaria.
Por otro lado, al tener IDCod en la tabla iba a utilizarlo para enlazarlo con la tabla DETALLE pero no me deja, dándome el error "No se encontró ningún índice único para el campo al que se hace referencia en la tabla principal".


Aparte de eso, y al no haberlo tocado en tanto tiempo, me decidí a crear la BD en Access, y después la aplicación en Delphi. Las relaciones entre las tablas ¿puedo dejarlas creadas en Access?

Muchas gracias.

[gnzsoloyo]

Al ser la tabla ARPRO una tabla resultante de una relación N:N, no sé si esta bien haber añadido una tercera clave primaria.

Las dos FK ya definen la PK de esa tabla. Únicamente se agrega un discriminante si cada par puede aparecer más de una vez, como por ejemplo, una tabla donde la misma relación pueda ocurrir en diferentes fechas, en ese caso la fecha es parte de la PK.

or otro lado, al tener IDCod en la tabla iba a utilizarlo para enlazarlo con la tabla DETALLE pero no me deja, dándome el error "No se encontró ningún índice único para el campo al que se hace referencia en la tabla principal".

No puedes relaciona una tabla por el "Detalle", sino por su PK.
Además, en una tabla "DETALLE", no existe un ID único, sino que su PK se define por FK de tabla origen (cabecera de datos) + ID de subitem. Es el caso de una factura, por ejemplo, donde la factura Nº 23789, donde se vendieron 5 productos, tiene cinco registros de detalle cuyas PK son los pares

(23789, 1)
(23789, 2)
(23789, 3)
(23789, 4)
(23789, 5)

Nunca se usa un AI para una tabla de detalle. Es un error conceptual.
Si se llega a usar es por exigencia del sistema, y representa casos excepcionales.

Aparte de eso, y al no haberlo tocado en tanto tiempo, me decidí a crear la BD en Access, y después la aplicación en Delphi. Las relaciones entre las tablas ¿puedo dejarlas creadas en Access?

Es tu decisión. Access no es un sistema de gestion de bases de datos, sino un manejador de tablas con recursos de SQL embebidos.
Si lo que quieres es usar un verdadero DBMS, hay cosas mucho mejores, incluso entre las portables.

[speaK121]

Iniciado por gnzsoloyo

Las dos FK ya definen la PK de esa tabla. Únicamente se agrega un discriminante si cada par puede aparecer más de una vez, como por ejemplo, una tabla donde la misma relación pueda ocurrir en diferentes fechas, en ese caso la fecha es parte de la PK.

Entonces eso está bien, porque por eso pensé en poner la tercera clave primaria IDCod; ya que un mismo proveedor puede tener el mismo artículo con dos precios distintos.

Iniciado por gnzsoloyo

No puedes relaciona una tabla por el "Detalle", sino por su PK.
Además, en una tabla "DETALLE", no existe un ID único, sino que su PK se define por FK de tabla origen (cabecera de datos) + ID de subitem. Es el caso de una factura, por ejemplo, donde la factura Nº 23789, donde se vendieron 5 productos, tiene cinco registros de detalle cuyas PK son los pares

No me hice explicar bien, Detalle es una tabla relacionada a su vez con la tabla Factura.
Dentro de la tabla Detalle está la FK IDCod correspondiente a la PK IDCod de la tabla ARPRO; es decir IDCod me sirve para enlazar la tabla Detalle al Artículo en sí (tabla ARPRO).
Esto a lo mejor es lo que falla, pero no se me ocurre otra idea.

Iniciado por gnzsoloyo

Nunca se usa un AI para una tabla de detalle. Es un error conceptual.
Si se llega a usar es por exigencia del sistema, y representa casos excepcionales.

Perdona.. ¿qué es un AI?

Iniciado por gnzsoloyo

Es tu decisión. Access no es un sistema de gestion de bases de datos, sino un manejador de tablas con recursos de SQL embebidos.
Si lo que quieres es usar un verdadero DBMS, hay cosas mucho mejores, incluso entre las portables.

Lo que no quería meterme es en crear la BD con SQL, aunque ya ni me acuerdo si las relaciones (cuando creabamos las tablas por access) las creabamos por SQL o por el Access en sí.

Muchas gracias por tu ayuda, estoy un poco desesperado con el tema, los años no pasan en balde.

Un saludo.

[gnzsoloyo]

Entonces eso está bien, porque por eso pensé en poner la tercera clave primaria IDCod; ya que un mismo proveedor puede tener el mismo artículo con dos precios distintos.

Eso es un error a nivel de análisis: SI un proveedor tiene más de un precio para algo, eso en todo caso aparecerá en otro nivel del análisis, pero no en la relación producto-proveedor.
De hecho, los precios son por definición móviles, por cuanto si son productos adquiridos apra tu empresa, aparecerán en el análisis del subsistema de Compras, y no específicamente con el proveedor.
A nivel Proveedor, la existencia de más de un precio para un mismo producto puede implicar la existencia de una relación ListasDePrecios, pero no diferentes relaciones de Producto-Proveedor.
Además, deberías determinar si las diferencias de precios se originan en categorías diferentes del mismo producto, o el impacto de descuentos o incrementos por tipo de compra.
No es lo mismo.

No me hice explicar bien, Detalle es una tabla relacionada a su vez con la tabla Factura.
Dentro de la tabla Detalle está la FK IDCod correspondiente a la PK IDCod de la tabla ARPRO; es decir IDCod me sirve para enlazar la tabla Detalle al Artículo en sí (tabla ARPRO).

En un sistema de facturación las facturas se componen de al menos dos tablas: CabeceraFactura y DetalleFactura.
A su vez el DetalleFactura se relaciona con las tablas de Productos, pero no con las de Proveedores. El análisis de qué proveedor está vinculado a una factura es ajeno a la factura, porque es Adminsitración de Inventarios, y no Administración de Ventas. Son áreas con alcances completamente distintos.
Entonces, el DetalleFactura sólo tendrá relación con la cabecera de Factura, y con Producto, pero no con otra.
Cuando diseñas luego el segmento que muestra el movimiento de inventario es donde relacionas al proveedor, pero sólo a los efectos de definir el balance de Comrpas/Ventas, donde estableces a qué valor de compra imputas la venta realizada. Pero eso es un subsistema diferente.
¿Se entiende la idea?

No mezcles a los proveedores con las facturas de venta. A menos que seas un intermediario o agente de ventas de terceros, esa imputación es incorrecta.

[speaK121]

Ante todo muchas gracias por lo que estás haciendo.

Acabo de imprimirme tu último comentario (lo imprimo para analizar lo que me dices tranquilamente y que me dé tiempo a pensarlo) y a primera vista matizo algunas cosas:

- La tabla Detalle es lo que tú llamas DetalleFactura
- El proveedor afecta no sólo al sistema de compras, sino también al de ventas ya que el impone unos precios dependiendo del precio al vende. Es decir, él saca una promoción de un producto vendiéndomelo más económico pero fijando el precio de venta en mi negocio.
- La promoción del producto no viene dado por un volumen de compras por parte de mi empresa, sino que lo hace aleatoriamente el proveedor sin tener yo que haber comprado una cantidad determinada, etc...
- la tabla ListadePrecios de la que hablas, teniendo en cuenta lo que he expuesto, ¿ no es mi tabla ARPRO?
- Efectivamente la tabla Factura debería relacionarse con la tabla Artículos y no con Proveedores (al principio lo tenía hecho como dices), pero el precio del artículo al depender del proveedor, tengo que implementarlo de alguna forma.

Voy a leer tranquilamente lo que me dices, y analizar muy bien la estructura de las tablas, porque seguramente la interpretación que estoy haciendo es incorrecta y por eso no encuentro salida.

Por favor intenta corregirme en lo que te he expuesto porque me ayudaría a entender el problema de análisis. Gracias

[gnzsoloyo]

Por ahora, un detalle:

la tabla ListadePrecios de la que hablas, teniendo en cuenta lo que he expuesto, ¿ no es mi tabla ARPRO?

No. La tabla que relaciona un Proveedor con un Artículo se relaciona además con otra tabla que componga las listas de precio de cada proveedor, y a su vez relacioada con cada artículo en un momento dado.
A su vez esa tabla se descompone en la cabecera de la lista y el detalle, donde está el precio de cada articulo en una lista (o promoción) determinada.
De esa forma puedes incluso hacer un seguimiento histórico de precios.

- El proveedor afecta no sólo al sistema de compras, sino también al de ventas ya que el impone unos precios dependiendo del precio al vende. Es decir, él saca una promoción de un producto vendiéndomelo más económico pero fijando el precio de venta en mi negocio.

Si el proveedor es el que define el precio de venta al público, eso para la emisión de la factura es relativamente determinante, pero no es definitorio, porque la factura no la emite él al cliente, sino tu.
Aunque que todos los proveedores fijen el precio de venta al público, la lista de precios de tu empresa es una entidad independiente. De dónde tome el sistema el precio es lógica de negocios, pero no de la capa de datos.
Es decir: Tu confeccionas la lista de precios de venta al público para los productos que comercias. De dónde tomas el dato o cómo lo calculas no hace que el precio que obtiene el cliente se deba tomar directamente. Lo que la base debe aportarte es la posibilidad de tomar el precio para tu lista de allí, o poner otro precio por conveniencia comercial.

¿Se entiende?

Resumiendo: La lista de precios al publico es de donde tomas el precio a aplicar a la factura. Que sea una copia del precio definido por el proveedor, o lo defines tu, es una etapa de procesos previa, que tu sistema debe gestionar.
Lo que no debes hacer es relacionar directamente los precios aplicados en la factura con la lista del proveedor, porque no es el proveedor el que emite la factura.
Además, ten en cuenta que debes considerar el stock prexistente con precios distintos,
¿Recuerdas el concepto de LIFO y FIFO de contabilidad?
Bueno, eso es lo que debes resolver, y por eso se usa la lista de precios al publico como filtro.

A nivel de obtención de los datos para emitir la factura, lo que cambia son los caminos para validar los precios finales, o más exactamente las ganancias obtenidas por ti, pero todo eso es invisible para el cliente.
Las consultas en la capa de datos son las que te darán la información, pero para simplificar la tarea, los JOIN se deben hacer contra la lista de precios al publico, donde ya consolidaste toda es data.
Descomponer los datos y los procesos te ayudará a hacer que el sistema sea más sencillo de administrar, aunque el desarrollo te lleve más tiempo.

[speaK121]

Perdóname, porque aparte de marearme yo te estoy mareando a ti.

Estoy cambiando toda esa parte de la estructura de la base de datos, intentando ser acorde a los consejos que me has dado, y me he parado de nuevo. Te explico:

- Los articulos de mi tienda pueden venir en diferentes formatos (1 kg, 3 kg, etc..) por lo que entre Articulos y Formato (relación N:N) sale otra tabla Formato_Articulos -> de donde resulta realmente el articulo en sí, ya que por ejemplo un saco de cemento de 1 kg no es lo mismo que un saco de 3 kg a todos los efectos.

- Formato_Articulo creo que es la tabla que se debería unir a Listado_Precios_Venta

Me estoy rayando sobre como se hace una FK de una tabla compuesta por dos PK, es decir, para crear la relación en la tabla Listado_Precios_Venta como lo hago? pongo dos FK referentes a las dos PK de Formato_Articulo?

No sé si me explico porque tengo la cabeza como un bombo.

Gracias.

[gnzsoloyo]

Me estoy rayando sobre como se hace una FK de una tabla compuesta por dos PK, es decir, para crear la relación en la tabla Listado_Precios_Venta como lo hago? pongo dos FK referentes a las dos PK de Formato_Articulo?

Vamos por partes: Eso es más simple de lo que parece.
Una PK de más de un campo sólo requiere que declares la PK incluyendo ambos campos dentro de la definición de la tabla.

Código SQL:

PRIMARY KEY (campo1, campo2)
 

La condición sine qua non es que ambos campos deben ser NOT NULL. Nada más.
Si ambos campos o uno de ellos es FK, eso no impacta en la creación de la PK, sino en los INSERT, ya que antes de insertar un registro en esta tabla, deben existir los datos en las tablas referenciadas.

[gnzsoloyo]

Los articulos de mi tienda pueden venir en diferentes formatos (1 kg, 3 kg, etc..) por lo que entre Articulos y Formato (relación N:N) sale otra tabla Formato_Articulos -> de donde resulta realmente el articulo en sí, ya que por ejemplo un saco de cemento de 1 kg no es lo mismo que un saco de 3 kg a todos los efectos.

Este tema es un poco más complejo, pero la idea es que cada producto lleve un único numero por cada presentación que tenga (presentación es un término habitual en Argentina), es decir que por cada producto habrá un numero según sea de 1 Kg, 2, Kg, 5 Kg, etc.
A pesar de lo raro que te parezca, esto es normal. Si te fijas en los códigos de barra del mismo producto en diferentes envases en el mercado, verás que si bien la primera parte es igual, el final del número cambia. Esto es precisamente porque el envase es parte del ID, y por cada "formato", corresponde un ID diferente.
Si tus productos están registrados, es conveniente que uses esos mismos ID universales como identificadores. Además, en el futuro podrás usar esos mismos identificadores para obtener más información o acuatizar la que tienes por medio de webservices. Especialmente si son códigos EAN o cosa similar.
Lo mismo corre para los ISBN (editoriales): Cada edición de un libro o revista tiene un numero de ISBN distinto, y si cambia el tamaño aunque sea por 1 cm de lado, debe tener un ISBN nuevo (lo sé: trabajaé para un editor).

Si tus productos no tienen un sistema de clasificación como ese, es mejor que pienses uno, por ejemplo con un sistema de códigos por rubro, subrubro y producto. Como cada producto sólo lo darás de alta una vez, y luego administrarás el stock, por complicado que parezca resultar, en realidad terminará siendo simple de manejar. Sólo la carga inicial se complicaría un poco.

[speaK121]

Iniciado por gnzsoloyo;

Vamos por partes: Eso es más simple de lo que parece.
Una PK de más de un campo sólo requiere que declares la PK incluyendo ambos campos dentro de la definición de la tabla.

Código SQL:

PRIMARY KEY (campo1, campo2)
 

No me expliqué.
Te pongo el ejemplo, ¿como uno la tabla ARPRO (dos PK: IDProveedor, IDArticulo) con la tabla Listado_Precios_Proveedor?
Se supone que es una relación 1:N, por lo que debería llevar la clave primaria de ARPRO hacia la tabla Listado_Precios_Proveedor.
ARPRO al tener dos claves primarias.. llevo las dos claves como FK de Listado_Precios_Proveedor? ¿esto sería correcto?

[gnzsoloyo]

Exacto.
Tienes que recordar siempre que si relacionas una tabla cuya PK es compuesta, la FK que tomas debe representar esa PK, por ende la FK en la tercera tabla requiere siempre todos los campos de la PK compuesta, con el mismo tipo de dato, y en el mismo orden.
Con esto último me refiero a que si la PK fuese, por ejemplo un conjunto como: (numero, fecha, varchar, numero), la tabla que tome esa FK debe contar con esos mismos cuatro campos, y la declaración de FK los debe listar en el mismo orden.
Hay que tener mucho cuidado con no confundir los tipos de columna que se usen en ambas tablas, especialmente los campos VARCHAR, porque si uno es declarado como charset latin1 y el otro UTF8, no te permitirá crear la FK, ya que a nivel binario los mismos caracteres no tienen el mismo valor binario. Usan representaciones distintas.
¿Se entiende?

Es común que los que comienzan en este tema cometan ese tipo de errores sin saberlo, y luego no entienden por qué falla.

En el caso de los campos numéricos ambos deben ser del mismo tipo, sea con singo o sin signo, ya que el rango de representación es diferente en un caso u otro.
Por ejemplo: el TINYINT con signo representa numeros entre el +127 y -128, pero el TINYINT UNSIGNED representa números entre el 0 y 255. Como puedes ver, no tienen el mismo rango, y por eso no se puede crear una FK con tipos cruzados.

Un consejo final sobre el nombre de las PK y las FK: Normalmente, por simpleza y facilidad de lectura y escritura, se recomienda que no se usen nombres como "ID", "FECHA", y cosas simples así. Es decir, no uses nombres abreviados que no te permitan saber a qué tabla pertenecen.
Lo que conviene es que esos campos tengan como prefijo o sufijo parte del nombre de la tabla.
Exactamente como muestra tu gráfico.
Pero también es muy conveniente que los campos que van como FK en otra tabla tengan el mismo nombre de su campo de origen, sin prefijos adicionados o nombres cambiados, si no es estrictamente por necesidades reales de implementación.
Con esto último me refiero, por ejemplo, al caso de que haya dos FK en una misma tabla que apunten a la misma tabla referenciada. De algún modo una de las dos FK debe diferenciarse de la otra.

[speaK121]

(aún no he impreso lo último que me has comentado)

como en la tienda converge el mismo artículo con distintos precios, para poder controlar el precio al que se han vendido los productos, en la tabla Detalle_Factura tendré que agregar un campo para recoger el precio al que se ha vendido no? (ya que el campo fecha de la tabla Cabecera_Factura no me sirve para contrastarlo con el precio por fecha).
NO ->El stock de producto lo estoy poniendo en las tablas Listado_Precios_Venta y Listado_Precios_Compras siendo campos de stock distintos como me dijiste.
EDITO: Que locura, el stock lo controlaré con sólo un campo en Listado_Precios_Compras no? porque si se contabiliza desde el Detalle_Albarán, el que un producto haya sido entregado por el proveedor significa que está a la venta.. o no? jajaja

PD: Siento que vivas tan lejos, porque ya te has ganado de sobra una cerveza xD