Newsgroup: it.comp.appl.access
Titolo: Dubbio, campo da cui dipende un altro campo

Ciao a tutti.
Facciamo un esempio: ho una tabella (tabUffici) con un campo
dipartimento e un campo unita. Le unità variano a seconda del
dipartimento scelto (un caso classico), e naturalmente si vuole che
scegliendo il dipartimento, nelle unità escano solo quelle del
dipartimento di appartenenza (altro caso classico) e queste info sono
contenute in due tabelle tabDipartimenti e tabUnita.
Beh, oggi riflettevo che il campo dipartimento all'interno della tabella
tabUffici è inutile: l'informazione del dipartimento è già contenuta nel
campo unita (perché un'unità appartiene ad uno ed un solo dipartimento).
Naturalmente, poiché voglio che l'utente scelga sempre il dipartimento e
poi l'unità, nella maschera (frmUffici) metto un controllo non
associato, o meglio associato ad una SELECT, e là faccio scegliere il
dipartimento, poi metto una condizione WHERE sul controllo associato al
campo unita che la lega al dipartimento.
Non vi sembra più elegante? Quali sono le controindicazioni a questa
scelta?
Thanx
giaconet

 ha scritto nel messaggio
news:an9ihc$c9t1h$1...@ID-71483.news.dfncis.de...

Nessuna.
Quella che stai proponendo è la giusta normalizzazione se operi con un
database relazionale.
--
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------

 ha scritto nel messaggio
news:oPYl9.31068$Eu.6...@twister1.libero.it...

Ok. Ho fatto delle prove e sono nati i primi problemi. Io sono abituato
ad usare la stessa maschera per l'immissione dati e per la lettura
(cambiando tramite codice le varie proprietà della maschera). Con la
soluzione normalizzata sto incontrando difficoltà: riesco a immettere i
dati correttamente ma per visualizzarli sono costretto ad usare una
maschera diversa.
Infatti se, per la maschera di immissione utilizzo l'artificio di cui
parlavo prima, e cioè l'uso del controllo non associato, quando vado a
visualizzare i dati in questo controllo ovviamente non c'è nulla (non è
associato).
Mi è venuta allora l'idea di fare una query in modo da far comparire il
campo che mi serve, basare la maschera su questa query, associare il
controllo al campo che ora è disponibile, lasciare le varie "origine
riga" come prima ma, mentre adesso in lettura funziona bene, in
immissione dati non funziona come mi aspettavo: infatti selezionando
prima un dipartimento e poi un'unità Access mi segnala un errore di join
(però anche variando tipo di join l'errore persiste), se seleziono
un'unità mi scrive direttamente il dipartimento (ma la scelta del
dipartimento all'inizio mi serviva perché le unità sono troppe ed è
molto più semplice per l'utente sceglierne una con la struttura ad
albero dipartimento --> unità).
Senza entrare in dettagli dov'è l'inghippo? Ci sto pensando da ore ma
non riesco a capire...
In realtà una soluzione l'avrei anche trovata: in lettura lascio il
controllo non associato, verifico se c'è qualcosa scritto nel controllo
unita, se si, allora si tratta si un record immesso precedentemente e
carico il valore del dipartimento nel campo non associato; se no, allora
non faccio niente perché significa che è da inserire; cercavo però
qualcosa di più automatico senza passare troppo per il codice.
Thanx again
giaconet

 giaconet


> "giaconet" news:an9ihc$c9t1h$1...@ID-71483.news.dfncis.de...:

        Un Ufficio ha piu' Dipartimenti.
        Un Dipartimento ha piu' Unita'.
        Un Ufficio ha piu' Unita'.
        Una Unita' ha piu' Dipartimenti.
    Quale di queste e' vera? O nessuna delle due? E, se nessuna, come stanno
le cose?
--
Ciao :-)
Maurizio
--------
?SPQR(C)
 X
--------

 ha scritto nel
messaggio news:anbir7$cnadp$1...@ID-52090.news.dfncis.de...

Non ho visto emoticons (se non quella in firma), quindi immagino che tu
sia serio.
Cmq,
Un ufficio appartiene ad una sola unità e un unità appartiente ad un
solo dipartimento.
Di contro un dipartimento può contenere diverse unità e a loro volta
queste potranno contenere diversi uffici.
Es. (scemo):
Ufficio "Access"
Unità "Office"
Dipartimento "Computer"
ovviamente il dipartimento "Computer" contiene anche "Hardware" e
"Internet" come unità.
E la stessa unità "Office" contiene gli uffici "Word", "Excel", ecc.
Bye
giaconet

 queste potranno contenere diversi uffici.
[...]
    Tornando alla tua domanda:
"Beh, oggi riflettevo che il campo dipartimento all'interno della tabella
tabUffici è inutile [...] Non vi sembra più elegante?"
no, non mi sembra piu' elegante. Soltanto corretta.
    C'e' poi la questione della tua perplessita' di fronte alle mie domande
*serie* che secondo me merita qualche attimo di riflessione. Da parte di
entrambi, ovviamente.
