Newsgroup: it.comp.software.database
Titolo: alberi di dati

Ho la necessità di archiviare dei dati che hanno una relazione ad albero.
Un esempio per tutti:
Regioni -> Provincie -> Comuni
Mi chiedevo quale fosse la miglior struttura da dare alle tabelle per
consentire poi delle query semplici e veloci.
Ovvero una semplice struttura a tre tabelle del tipo:
id _regione | nome_regione
id_provincia | id_regione | nome_capoluogo
id_comune | id_provincia | nome_comune
è consigliabile o c'è qualche soluzione migliore?
Ciao,
Luca

 consentire poi delle query semplici e veloci.
Io proprio alcuni giorni fa ho dovuto archiviare l'elenco delle province 
italiane con relative regioni (per poter filtrare al bisogno città del 
nord/centro/sud).
Per semplicità ed immediatezza di realizzazione del piccolo db ho 
costruito tre tabelle:
REGIONI(ID_Regione, Nome, Geo);
PROVINCE(ID_Provincia, ID_Regione, Nome);
COMUNI(ID_Comune, ID_Provincia, Nome);
Nella prima tabella GEO è un campo che indica se la regione in questione 
è del nord/centro/sud.
Però volendo si potrebbe costruire una tabella ad albero.
Ogni elemento (che sia regione, provincia o comune) è figlio di qualcuno 
eccetto le regioni, che si può dire che nel piccolo della realizzazione 
sono figlie a nessuno (padre=0); per il resto ognuno ha un elemento 
superiore, che sia questo una provincia o una regione.
Quindi gli elementi sono del tipo:
-> ID_Elemento (univoco)
-> ID_Padre (riferito a ID_Elemento, 0 nel caso delle regioni)
-> Tipo ('REGIONE', 'COMUNE', 'PROVINCIA')
-> Nome (Nome dell'elemento ('TOSCANA', 'BARI', 'ACQUAVIVA'));
-> ID_Capoluogo (riferito ad ID_Elemento, ma solo Tipo='REGIONE');
Se ad esempio vuoi tutte le province della Toscana:
SELECT Nome
FROM Tabella
WHERE ID_Padre IN
  ( SELECT ID_Elemento
    FROM Tabella
    WHERE Nome='TOSCANA'
  )
ORDER BY Nome ASC
Se invece vuoi tutte le regioni:
SELECT Nome
FROM Tabella
WHERE ID_Padre=0
oppure
SELECT Nome
FROM Tabella
WHERE Tipo='REGIONE'
Però per pignoleria avrei da ridire che così c'è un'abbondanza di 
colonne: per ogni elemento (che sia esso una provincia o un comune o una 
regione) c'è ID_Capoluogo che non servirebbe a molto per comuni e 
province. E la cosa si ripete aumentando il numero di colonne spesso non 
valorizzate se si rende necessario aggiungere informazioni che possono 
riguardare una particolare categoria di elementi (ad esempio potrebbe 
essere necessario memorizzare il numero di comuni per ogni provincia, ma 
sarebbe un dato riservato alle sole province ed inutile per comuni e 
regioni a meno che non si decide di sfruttare quel campo per indicare il 
numero di province per ogni regione, ma resterebbe comunque vuoto ed 
inutile per i comuni).
In genere la struttura ad albero viene sfruttata in maniera _OTTIMALE_ 
quando i dati sono tutti dello stesso tipo (ad esempio un albero 
genealogico): allora ogni elemento può valorizzare o meno determinati 
campi, ma sarebbero tutti campi potenzialmente necessari per chiunque.
Comunque... questa è la mia soluzione :)
-- 
Quando noi ignoranti eravamo di più, tutto era più bello (A. Celentano).
  ___   _   ___ _  _______   _______ ___
|   \ /_\ | _ \ |/ / _ ) \ / /_   _| __|
| |) / _ \|   / ' <| _ \\ V /  | | | _|
|___/_/ \_\_|_\_|\_\___/ |_|   |_| |___|

 id_comune | id_provincia | nome_comune
Idem come sopra.
A me sembra che UNA sola tabella sia piu' che sufficiente. Ti ritrovi
con due tabelle che contengono UNA sola colonna.
Davide
-- 
Q: What do Windows NT and frozen pizza have in common?
A: They're both half baked. 

 con due tabelle che contengono UNA sola colonna.
E' vero. Solo nel caso specifico perň.
Se per le regioni, per esempio, dovessi inserire piů informazioni, quali
superficie, numero di abitanti, e cosě via, mi ritrovereri con dati
ripetuti, contravvenendo quindi alle regole di normalizzazione. Inoltre se
la regione cambiasse nome (nel caso specifico sarebbe ovviamente
impossibile, ma penso ad altri tipi di dati), dovrei fare un update di
moltissimi record, anzichč di uno solo.
Ciao
Luca

 moltissimi record, anzichč di uno solo.
E con questo si torna al mio discorso fatto nel post precedente (dati 
ripetuti o inutili).
Per quanto riguarda il cambiare nome ad una regione (a titolo di 
esempio, sempre) si usano le foreign keys: una tabella figlia (o meglio, 
un record figlio) č legato a un record padre tramite una chiave 
(esempio: nome della regione). Variando il nome della regione questo 
cambiamento si ripercuote su tutti i record di cui quella regione č padre.
-- 
Quando noi ignoranti eravamo di piů, tutto era piů bello (A. Celentano).


 ripetuti o inutili).
L'ho visto solo ora :-)
Luca