Newsgroup: it.comp.software.database
Titolo: Problema di concetto - Come fare il join

Ciao ragazzi...
Devo costruire un database "solido" che permettera' di gestire degli
impianti di melo sperimentali.
Ecco cosa succede.
Ho una pianta e quella pianta univoca avra' un codice di questo tipo:
localita: 01
Parcella :10D
Replicazione :127
Il codice finale (che mi permettera di legarla con un join) a vari
dati annuali sara' 0110D127.
Il problema e' questo. Quella pianta un giorno (tra qualche anno)
verra' eliminata ed al suo posto andra' un'altra pianta con
caratteristiche diverse , ma con lo stecco codice.
Se voglio costruire un'anagrafica che venga implementata ogni anno (e
non cancellando record, che mi sembra un pagliacciata) come posso
fare?
Se aggiungo un ID (tipo numero progressivo) nella tabella anagrafica
risolverei il problema, ma come farei ad attingere ai dati annuali
(che non hanno ID).
Pensavo di inserire due campi in piu' tipo ANNO di IMPIANTO e ANNO di
ESPIANTO. Con le tabelle annuali dei dati (che contengono l'anno)
potrei fare il controllo ed effettuare il join corretto.
Cosa ne pensate?
PS: la mia non e' una discussione sul software da usare, ma un
discorso di database di concetto.
Grazie di tutto

 dati annuali sara' 0110D127.
usa una chiave composita e non codici. non inserire nella chiave campi
che possono cambiare
--
Greetings, Alessandro
http://www.b3soft.com
Pesaro, Italy
Sent via Deja.com
http://www.deja.com/

 wrote in message
news:nv6t6tgpqfq9ueg82...@4ax.com...


Scusami, ma cosa intendi per chiave composita?


L'unica limitazione che avresti con questa struttura è che non puoi gestire


 Scusami, ma cosa intendi per chiave composita?
e' una chiave su piu' campi. i codici si usavano quando, con i primi
database, non c'era questa possibilita' e sono rimasti in alcune
vecchie applicazioni ma sono da ritenersi completamente superati.
non e' che ti serve necessariamente un campo unico per fare la join,
puoi farla su piu' campi


Che significato hanno i campi  localita, parcella, replic? (te lo chiedo da
profano)
Non riesco a capire se sono caratteristiche della pianta o della "buca" in
cui fonda le radici

 wrote:
E' una caratteristica di quella buca li'...
Ogni volta che una pianta di quel buco viene eliminata, viene
sostituita da un'altra pianta con stessa localita' (nome
dell'azienda),parcella (l'azienda e' divisa in diversi rettangoli
chiamati 1A,1B,1C,1D) e replicazione (la prima pianta del campo 1A e'
chiamata 1, la seconda 2 e via via).
Ogni pianta poi viene controllata durante l'anno ( ad esempio contando
i numeri di fiori, i numeri di fiori che si sono trasformati in frutto
(allegagione), Kg di legno tolti con potatura e cosi' via)). Con i 3
codici (loc,parc,replic) riesco a fare praticamente tutto.
Fino ad adesso come hanno gestito il tutto (facendo un grosso
errore);si creava un database (ma e' forse piu' giusto chiamarli files
in DBF) e si lavorava solo durante l'anno. L'anno non compariva
all'interno dell'anagrafica. Si faceva dei "join" momentanei,il file
risultante veniva tenuto e la struttura veniva mesa nel
dimenticatoio).
Cosa mi ritrovo adesso; una serie di files, in diversi formati
(txt,dbf,xls...) slegati uno dall'altro.
E questo non mi va.
Con una anagrafica fatta bene io non cancellero' piu' niente.
Come ho risolto il problema... con un po' di SQL (anche se non sono un
esperto).
Ho inserito in anagraficai 2 campi che dicevamo, "data di impianto" e
"data di espianto" e le ho confrontate con la data nei dati annuali.
Poi ho fatto i join per la loc,per la parcella e per la replic.
WHERE (((dati.aa)>=[struttura]![aa_in] And
(dati.aa)<=[struttura]![aa_fi]));
Ora mi sembra che funzioni.
Ma se hai consigli...
Ivan
PS: se non scrivo durante il fine settimana e' perche non ho internet
a casa (mi sono appena trasferito)
Ciao e grazie


 (dati.aa)<=[struttura]![aa_fi]));
ok, se le rilevazioni sono annuali non dovresti avere problemi, attenzione
agli anni di impianto ed espianto:
come hai impostato il db se una pianta muore a gennaio 2000 e viene subito
sostituita hai due piante nella stessa buca nel 2000.
Io comunque dall'esame di Base di dati avrei strutturato il db come segue:
[PIANTE]
Data impianto
Data espianto
locazione
..vari dati pianta...
[LOCAZIONI]
idLocazione
loc
parc
replic
..vari dati locazione..
[DATI_RILEVATI]
locazione
numeroFrutti
numeroFiori
dataRilevazione
...vari dati rilevati...
RELAZIONI:
PIANTE.locazione [1,1] LOCAZIONI.idLocazione
LOCAZIONI.idLocazioni [1,molti] DATI_RILEVATI.locazione
Se hai problemi a creare query di interrogazione/aggiornamento per questo
tipo di db chiedi pure (dalla sintassi che hai utilizzato immagino che
utilizzi ACCESS)
PS: se la struttura dati in Excel/DB(n) che ti arriva è impostata in modo
diverso, non c'è alcun problema; si può infatti creare una query di
aggiornamento che legga i dati direttamente da Excel/DB(n) ed aggiorni il
nuovo db.
Spero di averti confuso le idee a sufficienza,
Ciao, Marco

Grazie Marco...
sei sempre puntuale e molto tecnico.
Effettivamente sto usando Access.
Se avro'problemi... ti posso cercare ancora?
Ivan

 Ivan
l' NG è fatto apposta, se non ci sono io ci saranno altri! :-)
Ciao, Marco