Newsgroup: it.comp.appl.access
Titolo: query ricorsive - tabelle autoreferenziali

Stavo leggendo qualcosa sull'argomento in oggetto e ho provato a crearmi una 
tabella autoreferenziale.
Purtroppo non capisco esattamente lo scopo o la funzione di questo tipo di 
costruzione.
In realtà mi sembra che, per certi versi, evitando di effettuare join tra 
tabelle diverse, vengano stravolti i criteri di normalizzazione.
Che tipo di utilizzo hanno? In quali contesti sono preferibili?
Per ora ho solo intuito che possono servire quando si hanno n livelli di 
dettaglio, ma non mi è molto chiaro.
-- 
ciroteo
MC
"Se la conoscenza può creare dei problemi, non è con l'ignoranza che
possiamo risolverli"
Isaac Asimov 

 di dettaglio, ma non mi è molto chiaro.
tabella Anagrafica
codicecliente
RagioneSociale
etc...
tabelle diversadestinazione (un cliente può avere diverse sedi).
o ti crei una tabella uguale con in più il campo rif_codicecliente (il campo
codicecliente può essere usato anche per la sede diversa)
o ti crei il campo rif_codicecliente nella stessa tabella anagrafica.
Ora nel primo caseo è facile immaginare maschera e sottomaschera
nel secondo invece
Metti come origine "select * from anagrafica where isnull(rif_codicecliente)
e la sottomaschera la leghi con quello.
Ora se anche l'esempio non è eccezionale, pensa a mille livelli di un
prodotto finito ed elemento sciolto
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it

 ha scritto nel messaggio 
news:nHvwe.22637$TR5....@news.edisontel.com...

ok MA avevo visto il tuo esempio, e ho capito il meccanismo di creazione.
Ciò che non mi è chiaro è perchè sia preferibile ad una struttura master - 
detail.
Per esempio nella mia rubrica aziendale ho fatto tbl principale e tbl 
dettaglio per memorizzare i dati dei clienti e i referenti per i singoli 
clienti:
p.e. tbl principale: idcomune,comune di milano indirizzo,tel, mail, cel
tbl dettaglio: id,idcomune,dott. Albertini - sindaco indirizzo,tel, mail,cel 
ecc...
               id,idcomune,dott. Pinco pallino - assessore indirizzo,tel, 
mail,cel ecc...
Qui ho n livelli di dettaglio che potrei tranquillamente gestire con 
un'autoreferenziale. fin qui ci siamo.
altro esempio:
clienti - servizi - dettaglio servizio
Ogni cliente può commissionarci più servizi e ogni servizio può a sua volta 
essere composto da un terzo livello di dettaglio.
p.e.:
clienti:
comune di milano
servizi cliente:
scuola fermi
scuola rossi
scuola bianchi
dettaglio servizi:
scuola fermi : mensa, pulizie, doposcuola.
scuola rossi: mensa, piscina, palestra
In questo caso? Potrei utilizzare solo una tbl, se si come?


sono sono due concetti diversi.
l'autorefernziazione nascerebbe se tu avessi scuola fermi come cliente ma
che fattura però il comune di milano
ma il resto è master detail


 MC
L'uso tipico di Self-Reference-Table o Tabelle Autoreferenziate è nella
gestione di Cataloghi di Componenti, dove ogni componente può essere
a sua volta un SottoComponente di un Componente.
Se facessi 2 tabelle(Componente--Dettagli) limiteresti l'esplosione del
componente ad 1 solo Livello
e saresti costretto ad aggiungere una Tabella per ogni livello, ottenendo
una
struttura non Flessibile e statica ed assolutamente non NORMALIZZABILE.
L'uso dell'Autoreferenza è un giochino difficile però, se usi solo 1 Tabella
ti VINCOLA sempre al fatto che un Componente può far parte solo di un
Componente superiore, ed anche questo è un errore da non commettere.
Esempio stupido:
Torta di Mele:
Farina
Uova
Mele
StruDel(non so come si scrive)
Mele
Uova
Come vedi sia mele che Uova fanno parte di entrambi i Componenti.
Ora se tu dovessi fare un gestionale per una pasticceria come
potresti pensare di rendere Flessibile a N livelli la strutturazione
di un Prodotto finito, non certo prevedendo 255 Tabelle.
In realtà ne bastano 2.
La prima con l'Elenco di tutti i Componenti Gestiti, siano elementi finiti
come
la "Torta di Mele" che gli elementi primitivi come le Uova, ed una tabella
Dettagli, nella quale ESPLODI la ricetta dei componenti finiti o
parzialmente
lavorati.
Vediamo le 2 Tabelle:
[TB_COMPONENTI]
(PK)    CODICE_COMPONENTE
          DESCRIZIONE
          TIPO
[TB_DETTAGLI]
(PK)    ID_COUNT
          CODICE_COMPONENTE_PARENT
          CODICE_COMPONENTE
          QUANTITA
La Tabella Dettagli avrà un doppio legame con la Tabella Componenti
ottenibile con una Doppia Referenza della Tabella Componenti:
uno lato CODICE_COMPONENTE_PARENT per identificare il Componente
Principale(La torta di Mele) e l'altro CODICE_COMPONENTE per identificare
la Ricetta del CODICE_COMPONENTE_PARENT(Torta di Mele).
Ora capirai facilmente che il Campo TIPO della TB_COMPONENTI serve proprio
per discriminare le cose, una Torta di Mele non potrà mai avere come
Dettaglio una Torta di mele che come Campo[TIPO]=FINITO, ma solo
elementi primi come le Uova o parzialmente lavorati come il PanDiSpagna.
Per quanto riguarda la Normalizzazione, a questo punto ti rendi conto che
questo è esattamente quanto richiede la Normalizzazione.
Ora la parte difficile arriva se devi ottenere la DIBA o DistintaBase, vale
a dire
l'elenco di tutti i Componenti con le Relative Quantità e costi di un
prodotto.
Questa richiesta è all'ordine del giorno per chi fà gestionali e, se
strutturati come
ti ho esposto necessita di funzioni RICORSIVE tutt'altro che banali per
evitare
porcate di codice ed un'estrazione sensata e coerente con le aspettative.
Questo in ogni caso è il sistema migliore di strutturare la cosa. forse un
pò
ostico da affrontare, ma le funzioni di Esplosione per la DIBA sono
abbastanza
semplici, e tieni presente che per la popolazione di TREEVIEW sono
indispensabili
se vuoi evitare inutili perdite di tempo e limiti di Livello.
Saluti
-- 
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.mantuanet.it/alessandro.baraldi/
---------------------------------------------------------------------------