Premetto che ho letto gli ultimi 2 post, e premesso che ti stai facendo il 99% delle domande sbagliate e dei problemi che non ci sono, sottolineo che questo
Solo dopo aver assodato per bene la struttura tabelle, per queste domande devi aprire una nuova discussione nella sezione Access.
è sbagliato, o meglio è un approccio dilettantistico (o didattico, o come lo vogliamo chiamare).
Faccio subito un esempio, e visto che sono pigrissimo, prendo proprio l'ultimo pezzetto.
marche e articoli
nell'approccio diciamo così didattico-dilettantistico si parte in quarta: ci sono le marche, e ci sono gli articoli.
si mettono tante belle chiavi, si normalizza, et voilà
nel "mondo reale" invece ci si chiede: quanto è, o sarà, scomodo o inefficiente avere due tabelle diverse?
in ogni interrogazione dovrò avere un join e, soprattutto, lo avrò in ogni report (e tipicamente userò un qualche tipo di generatore di report. sì lo so che in questo caso sarà forse access, ma nel mondo "vero" avrai qualcos'altro).
la domanda si sposta quindi in:
quali sono i pregi e i difetti di avere marche e articoli separati ?
perchè ci sono dei corollari non così banali, cioè derivanti dalla semantica del problema, non dalla struttura.
Che succede, ad esempio, se un articolo è prodotto da più marche?
Cosa accad se ho una denormalizzazione, cioè ho l'articolo X una volta impostato come marca cocacola e una seconda volta come coca-cola?
La cosa mi turba? Dovrò fare un inventario? Avrò problemi in produzione?
O me ne potrei "fregare" altamente?
Perchè ne secondo caso mi renderò la vita estremamente più semplice se nella tabella articoli ci metto dentro direttamente la marca.
Volendo poi c'è l'approccio diciamo così di livello successivo, cioè con gestione della normalizzazione da applicazione.
Quando inserisci un nuovo articolo, ad esempio, proporrai l'elenco delle marche direttamente dal group-by degli articoli medesimi, così da consentire all'operatore di mantenere la normalizzazione.
Se non esiste ci sarà un bottone del tipo "aggiungi nuova marca" o qualcosa del genere
===========================
Insomma, di nuovo, è l'UTILIZZO che farai dell'archivio che deve "plasmare" come sarà fatto.
Devi metterti nelle condizioni di avere un FACILE piano di interrogazioni, una FACILE gestione dei report, una (possibilmente) EFFICIENTE [nel tuo caso inutile i dati sono pochissimi].
La progettazione è quindi un processo top-down-up-multiplo-a-fontana-come-stizzi, nel senso che se il tuo schema è bellissimo, ma terribile da utilizzare, non hai fatto la scelta migliore.
Ovviamente ci vogliono quei 15-20-30 anni di esperienza, ed errori, per "prevedere" i pattern e gli antipattern tipici.
Esattamente come un meccanico esperto sente un "rumorino" da un motore e dice al 99% è questo, senza smontare l'intera auto, analogamente non c'è il modo Più Giusto Letto Sui Libri Scritti Per Sistemi di Cinquanta Anni Fa.
Neppure quello Scritto Oggi Con Metodi Fichi Ma Che Non Funzionano Che Si Usano Solo Perchè Fichi (Ma Nessuno o Meglio Pochi Li Conoscono Davvero)