Prova questa Struttura2:
Fornitori
IDFornitore (chiave primaria)
Fornitore
Indirizzo
...altri campi...
Ordini
IDOrdine (chiave primaria)
DataOrdine
IDFornitore
DettagliOrdini
IDDettaglio (chiave primaria)
IDProdotto
Quantità
PrezzoUnitarioAcquisto
IDOrdine
Prodotti
IDProdotto (chiave primaria)
Prodotto
Categoria
Categoria
Categoria (testo, chiave primaria)
Vendite
IDVendita
DataVendita
IDProdotto
Quantità
PrezzoUnitarioVendita
Relazioni:
Fornitori.IDFornitore uno-a-molti con Ordini.IDFornitore
Ordini.IDOrdine uno-a-molti con DettagliOrdini.IDOrdine
Prodotti.IDProdotto uno-a-molti con DettagliOrdini.IDProdotto
Categorie.Categoria uno-a-molti con Prodotti.Categoria
Prodotti.IDProdotto uno-a-molti con Vendite.IDProdotto
Chiamerò Struttura1 quella che ti avevo prospettato nel post precedente, Struttura2 quest'ultima.
Pro per Struttura2:
1. Appare più chiara da un punto di vista interpretativo.
2. Conseguenza di 1. sarebbe più semplice creare e interpretare eventuali maschera/sottomaschera
3. Non avresti per ogni Vendita, la zavorra di indicare per forza un IDSoggetto.
Contro di Struttura2:
1. Osserva DettagliOrdini e Vendite e dimmi se non si assomigliano troppo. Manca un solo campo IDSoggetto in Vendite che io avevo pensato di sostituire con il Cliente "0". Dal punto di vista della NORMALIZZAZIONE, non sarebbe tanto corretto descrivere dati QUALITATIVAMENTE IDENTICI su tabelle diverse. Basta averne una sola e aggiungere un campo che distingue se un record appartiene a una "parrocchia" (Entrata) oppure un'altra (Uscita)...ecco il perchè del campo E/U.
2. Il problema che a te stava più a cuore. Prova a creare una query che deve calcolare le Quantità in Magazzino. Sei costretto a prendere i campi Vendite.Quantità e DettagliOrdini.Quantità, metterli a confronto ecc...ti ricordo che una query fatta bene, in questo caso deve contemplare tutte le tabelle intermedie che vedi nella tua finestra Struttura2...a me sembra più complessa...e forse pure più lenta.
A corollario di tutta la discussione che mi sembra essere andata molto oltre il titolo iniziale e straripata nella visione più ampia della progettazione, mi sento di dire qualcosa che non so se altri utenti sono d'accordo. Access punta a una visione ARCHIVISTICA dei dati. L'aspetto ARITMETICO non è proprio il suo forte. Quest'ultima è una caratteristica più spiccata in Excel. Molti utenti ne confondono spesso le acque. Spero tu abbia preso in considerazione questo aspetto.