Newsgroup: it.comp.appl.access
Titolo: Sistema archiviazione dati 'flessibili'

Supponiamo di voler realizzare un archivio di informazioni relative ad 
uno negozio di articoli di vario tipo
Per mantenere memoria dei vari articoli, sara' necessario prima capire 
di quali articoli stiamo parlando
Supponiamo di fare una prima suddivisione in CATEGORIE1
Quindi esisteranno le categorie:
-elettronica
-ferramenta
-medicinali e cosi' via
A livello di struttura db potrebbe essere una semplice tabella con 
codice e descrizione
 
Per ogni categoria (quindi per ogni record nella tabella categorie1) gli 
articoli saranno ulteriormente suddivisi in CATEGORIE2
 
E gia' qui casca il pero perche' per la ferramenta avro' bisogno 
solamente di un campo DESCRIZIONE per descrivere la categoria2, mentre 
per l'elettronica potrei avere bisogno di piu' campi (o comunque diversi 
da quelli necessari per la ferramenta)
 
Mano a mano che ci avviciniamo alla descrizione precisa del singolo 
articolo, la diversa struttura di memorizzazione delle informazioni si 
rende sempre piu' evidente, sia come livello di profondita' (per la 
ferramenta potrebbe bastare Categoria/Sottocategoria, mentre per i 
medicinali potrebbe essere necessaria 
Categoria/Sottocategoria/SottoSottocategoria ) sia per i campi diversi 
necessari a descrivere correttamente i vari prodotti di natura diversa
 
Per chi ha accesso al sistema Esprinet, un qualcosa di simile, la 
categoria 'stampanti' ha campi descrittivi diversi dalla categoria 
'hard-disk'
 
Ovviamente la struttura deve essere programmata, non cablata nel db, 
altrimenti quando dovessi aggiungere una nuova categoria dovrei mettere 
mano alle tabelle e questo e' quello che non vorrei fare
 
Dal punto di vista struttura db, come affrontereste il problema?
 
 
 

 Dal punto di vista struttura db, come affrontereste il problema?
 
faccio la mia aggiunta (non è proprio una proposta ...)
perchè l'argomento, a livello generale, 
è fra quelli di mio (primario) interesse
(mi trovo a definire "schede prodotto"
con più livelli di componenti, in ambito tessile)
 
per ora l'aggiunta è fugace
(posso riprendere da domani)
 
allora:
(ritieni che) NON è sufficiente la "solita"
struttura tabellare di items padre-figlio ?
 
in cui, per le aggiunte di righe 
(in genere di figli, ma anche di padri ...)
si prepara una "semplice" form di accodamento record
chiedendo all'utente di precisare se si tratta di un item padre
oppure di un item figlio (indicando la scelta del padre) ?
 
in modo che sia l'utente ad ADEGUARE via via la correlazione degli item


Ho letto due volte ma non ho capito una mazza
Abbi pazienza, spiegati meglio
 

Credo possa bastare una gestione gerarchica Multilivello... per capirci strutturata cone so struttura la gestione di un Treeview.
Un sistema gerarchico multilivello richiede 2 tabelle... e la struttura avviene affinché sia gestibile in modo ricorsivo a scendere o salire la rerarchia ma non mi dilungo perché è una struttura banale...
 
@Alex


Si per la discesa in verticale basta la classica tabella con campo 
'livello' e ad esempio 'descrizione' della categoria articolo
Ma per l'allargamento in orizzontale (i campi informazione delle diverse 
categorie che dovrebbero essere diversi, ad esempio per le stampanti 
basta la descrizione e peso, per gli hard-disk serve descrizione, 
capacita, velocita, per i monitor serve diagonale, tecnologia, 
risoluzione, peso)?

Non si salva il livello nella tabella laterale... ma solo il rapporto IDArticolo-IDArticoloPadre ed eventuali dettagli dell'aggressione specifica...
 
Per gli atrributi devi avere una tabella attributi e poter definire per ogni TipoAtricolo un catalogo Attributi in relazione M-M.
Questo definirà solo quali attributi esporre quando inserisci quel TipoArticolo.
 
Qquindi quando carichi un Tipo vai a proporre tutti gli attributi recuperabili dalla relazione precedente e salvandoli in una relazione 1-M, quindi in una SubForm, popolando la combo nella subform con il catalogo ma lasciando la possibilità sempre di poter selezionare attributi dall'elenco completo. La combo avrà come origine una query un poco complessa perché prima.deve esporre gli attributi specifici... poi quelli generici...
 
Spero sia chiaro il disegno.
 
@Alex


Purtroppo no
Mi par di capire che ipotizzi una lista generale di attributi, da 
associare parzialmente agli articoli (o categorie)
Quindi ad esempio se la lista attributi fosse:
- peso
- colore esterno
- diagonale
- velocita stampa
- interfaccia comunicazione
- volume scatola
 
------------------------------------
E gli articoli/categorie fossero:
- stampanti
- hard-disk
- monitor
 
------------------------------------
Le stampanti dovranno usare gli attributi:
- peso
- velocita stampa
 
Gli hard disk dovranno usare gli attributi:
- interfaccia comunicazione
- colore esterno
- volume scatola
- interfaccia comunicazione
 
I monitor dovranno usare gli attributi:
- diagonale
- peso
------------------------------------
 
Tradotto in struttura db, tre tabelle, la prima con articoli/categorie e 
livello nella struttura gerarchica (ad esempio campi id_articolo, padre, 
figlio, descrizione), la seconda attributi (ad esempio campo 
id_attributo, descrizione), la terza di collegamento tra le due per 
associare uno o piu' attributi ad un articolo/categoria (ad esempio 
campi id_articolo, id_attributo, valore_testo, valore_numerico)
 
Ho capito male?
 


Io non uso mai la struttura Articoli/Categorie se questa deve essere Multilivello... non funzionerebbe.
 
Io faccio così:
 
[TblArticoli]
IdArticolo
 
[TblGerarchiaArticolo]
IdPKGErarchia
IdArticolo
IdArticoloPadre
 
La 2° Tabella ha in Relazione sempre la Tabella Articoli su entrambi i campi
In questo modo la Categoria di fatto è un Articolo...
Come riconosco le Categorie...? Perchè NON HANNO PADRE quindi IdArticoloPadre Is Null
 
Dove gestisco gli Attributi... in una Relazione Molti-Molti con la Categoria in fase di definizione, ma distinguo il Catalogo che non valorizza gli Attributi ma solo l'esistenza... dal vero inserimento dei dati, infatti non è detto che per ogni Categoria si debbabano inserire TUTTI gli Attributi, come non è detto siano solo gli ATTRIBUTI previsti.
 
Quindi la struttura è più complessa di quello che dici... perchè se il catalogo attributi si assegna alla Categoria(o meglio all'articolo che non ha PADRE nella Tabella [TblGerarchiaArticolo], il valore assunto dagli attributi va invece assegnato all'articolo, ma non lato Tabella Articoli(a meno che questo non abbia sempre gli stessi attributi anche se messo in più categorie)... ma come Relazione della Tabella [TblGerarchiaArticolo]
 
TblArticolo(1)<--->(m)TblGerarchiaArticolo(m)<--->TblArticolo_1(1)
 
TblGerarchiaArticolo(1)<--->(m)TblCatalogoAttributiCategoria(m)<--->(1)TblAttributi
(Solo IdArticoloParent Is NULL)
 
TblGerarchiaArticolo(1)<--->(m)TblAttributiArticolo(m)<--->(1)TblAttributi
 
In quest'ultima nella Tabella intermedia avrai il Campo VALORE che usi per Valorizzare l'attributo con il contenuto...
 
Pensa anche al Type del Valore quindi salva nella Tabella Attributi se ti aspetti che quell'attributo sia  Numerico/Stringa/Data, e sempre nella Tabella Attributi se ha dei Valori Limite o di Default...
 
Ovviamente questa logica strutturale deve essere adattata alla tua esigenza, volevo solo presentarti un ragionamento.
 
Saluti
@Alex