Query unione and back

di il
3 risposte

Query unione and back

Ciao
In un campo di una tabella devo inserire dati che arrivano da tabelle differenti.
Esempio banale: nella tabella tFrutta ho un campo frutto.
Poi ho tabelle per ogni tipo di frutto, ad esempio, tDrupe (prugne, ciliege,...), tAgrumi (limone, arancia, ...).
Le tabelle hanno campi diversi tra di loro.

Con una query unione tra le tabelle di frutti creo un elenco di frutti (usato poi in una combo ricerca) da poter inserire nel campo frutto della tFrutta.
Fin qui tutto funziona ma:
1 - Perdo l'unicità degli id del singolo frutto in quanto in ogni tabella avrò per esempio un ID=1 che corrisponde ad un frutto ovvero nella tabella tDrupe avro' 1- Ciliegia, nella tabella tAgrumi avro' 1- Arancia ecc...

2 - Partendo poi da questa tFrutta, devo eseguire delle query per reperire delle informazioni a ritroso dalla tabella di origine di ogni singolo frutto.
Ovvero, se in un record leggo Arancia, voglio risalire alla tabella tAgrumi.

Detto ciò, quale potrebbe essere il metodo migliore per gestire il punto 1 e generare quindi degli ID univoci che permangano nel tempo?
La risposta che mi sono dato e' stata quella di creare nella query unione un ulteriore campo contenente il nome della tabella che associato al relativo id del frutto, rende il record univoco.

Per il punto 2 pensavo ad una query in cui in funzione del nome tabella mi vada a leggere il relativo ID. Ma questo significa qualcosa tipo:
iif([NomeTabella]="tAgrumi",[tAgrumi].[spicchi] where [tAgrumi].[ID] =[tFrutta].[IDFrutto], iff([NomeTabella]="tDrupe", ecc....

Queste due soluzioni pero' non mi piacciono per nulla e preferirei trovare un altro sistema.

Qualche suggerimento?

Per logiche di business non posso mettere tutti i frutti in una unica tabella e poi specificare che tipo di frutto sono. Devo tenere le tabelle separate.

3 Risposte

  • Re: Query unione and back

    La logica dei database relazionali/normalizzati prevede che tu abbia (diciamo) 2 tabelle:
    CategorieFrutti
    Categoria (qui dentro ci scrivi Agrumi, Drupe…)

    Frutti
    IDFrutto
    Frutto
    Categoria

    Quindi relazione CategorieFrutti.Categoria uno-a-molti Frutti.Categoria.

    Per ottenere le "tabelle" separate (come dici tu) in base a Categoria, crei apposite query che prenderanno appunto i relativi nomi Agrumi, Drupe...
  • Re: Query unione and back

    Hai ragione ed avrei voluto fare come tu suggerisci, ma la realtà e' molto diversa. Quelle che io chiamo tabelle separate sono in realtà delle query separate che hanno già di per se origini differenti e dati che non sono normalizzabili tra di loro.
    Alcuni dati di queste query (selezionati manualmente) devono essere inseriti in una tabella e poi attraverso altre query, basate su questa tabella, devo riprendere alcune informazioni dalle tabelle di origine.
    La frutta e' solo un esempio. I dati sono già esistenti e molto più complessi di come li ho rappresentati.

    Restando sempre a livello di esempio, devo unire i pesi di tutta la frutta prodotta in Italia con tutti i bulloni prodotti in Germania. I dati a monte sono organizzati per esempio, in Italia con Regioni, Provincie e Comuni. In Germania tra comunità religiose e fasce di età.

    In una tabella a parte, in ogni record vengono inseriti:
    [IDMateriale] [Merce] , [Peso]
    I dati selezionati a mano da un elenco, per ragioni che non sto qui a spiegare sono:
    1, Arancia, 20kg
    1, Bullone M20, 2000kg

    Ora, sia Arancia che Bullone hanno lo stesso ID e devo risalire a quanto Ferro contengono per ogni kg;
    Quindi avendo io a disposizione solo il dato ID e Merce , devo risalire alle rispettive tabelle e verificare il contenuto di ferro/kg per ogni tipo di merce e fare la somma totale del ferro per merce. Il tutto attraverso una query, no vba o altro.
  • Re: Query unione and back

    La descrizione che dai appare molto confusa. Se i dati ti sembrano disomogenei, devi essere tu a trovare i punti di omogeneità. Frutti, Bulloni e quant'altro sono tutte Merci. Ogni Merce avrà certamente un nome specifico.
    Tentare di trovare un "accrocchio" che sviluppi "sistematicamente" qualcosa da tabelle disomogenee in unica tabella dati omogenei...appare (in base alle mie conoscenze) una via sbagliata da percorrere.
    Per me devi normalizzare il database.
Devi accedere o registrarti per scrivere nel forum
3 risposte