dark ha scritto:
Non sono riuscito a mettere l'Integrità referenziale a
VersioniModelli.IDVM uno-a-molti Articoli.IDVM
Articoli.IDArticolo uno-a-molti Listini.IDArticolo
Attento, le FK non devono avere l'indicazione di "chiave primaria". Le FK stanno dal lato MOLTI quindi tenderanno a ripetersi, se metti la univocità della chiave primaria, non potrai avere i molti record. Quindi togli quella impostazione e vedrai che potrai impostare la spunta "Applica integrità referenziale".
Il campo Versioni.CodiceVersione deve essere chiave primaria.
Le linee di join devono partire e raggiungere campi omonimi.
dark ha scritto:
Cmq se posso dire la mia, da ignorante in materia, non capisco a cosa serva creare una Tabella Categoria Pelli, una Tabella Listino (con date) una la tabella Articoli.
I campi di "CATEGORIA PELLE" potevano essere tranquillamente aggiunti nella tabella VERSIONI, come L,H,P perchè fanno parte di un'unica stringa legata alla versione. Sono univoci. Appartengono solo a quella Versione di quel Modello che ha quelle misure
Tu hai (oggi) 8 CategoriePelle. Potresti averne molte di più. Questa cosa la devi gestire VERTICALMENTE con la relazione uno-a-molti.
Diciamo che in sede di QUERY, potrai pensare a una "query a campi incrociati" pensata appositamente per spalmare orizzontalmente valori che generalmente vedi in verticale. Ma a livello di logica di normalizzazione, dal mio punto di vista, credo sia rigorosamente giusto così.
Ti faccio osservare che il foglio Excel mostra un recordset tipico di una query che raccorda campi da più tabelle. In questa sede sei libero di aggiungere tutti i campi che desideri mostrare. Ma a livello di logica normalizzata/relazionale i campi devono essere omogenei con il nome-tabella che li rappresenta.