Newsgroup: it.comp.appl.access
Titolo: Chiedo consiglio su come strutturare un database

La mia è una domanda generica, lo so, ma se qualcuno avesse già affrontato 
un problema del genere e avesse qualche consiglio avrebbe tutta la mia 
gratitudine.
Bene: devo realizzare un database per la gestione di sanzioni amministrative 
(quelle che gli esseri umani normali chiamano multe); il fatto è che i dati 
connessi alla "vita" di una sanzione (dall'irrogazione al pagamento possono 
esserci svariate conseguenze - ricorsi, ingiunzioni, ruoli, ecc.) sono tanti 
e articolati a loro volta (siamo in Italia del resto, eh :)) .
Secondo voi è meglio gestire tutti gli aspetti della "multa" in una sola 
tabella (ovviamente a parte ci sarebbero le tabelle relative al 
trasgressore, verbalizzanti, comuni, ecc.) oppure in più tabelle ciascuna 
relativa ad una fase particolare della "vita" della sanzione?
Personalmente ho già provato entrambe le soluzioni ma nessuna delle due mi 
alletta: una sola tabella è enorme per campi (e credo che dopo un certo 
numero di record il database diventi "pesante"); più tabelle mi creano dei 
problemi a livelli di maschera perché non sono in grado di gestire molto 
bene gli automatismi o meglio le sincronizzazioni tra le maschere.
Normalmente mi occupo di database legati a dati contabili (mastri, 
personale, dare/avere, ecc.) che gestendo dati numerici sono più lineari in 
fase di progettazione, mentre in questo caso diventa difficile per me 
riuscire a prevedere tutti gli aspetti che purtroppo con la matematica hanno 
poco a che vedere e non vorrei ricorrere a troppi campo "memo" per gestire 
annotazioni.
Lo so che la mia domanda è banale e forse esula un po' dallo spirito del 
newsgoup, però se qualcuno avesse la pazienza di metter giù due righe....
Grazie, ciao e tutti e buona pasqua ovviamente. 

 ha scritto nel messaggio 
news:fQG0e.695569$b5.31...@news3.tin.it...

La cosa migliore l'hai già detta tu, quella di crearti delle tabelle e 
collegarle tra loro tramite uno o più campi messi in relazione.
Se vuoi avere più informazioni (possibile struttura delle tabelle e loro 
relazioni) devi almeno descrivere i dati da prendere in esame...
Ciao.
-- 
Sergio MAZZA 

 ha scritto nel messaggio 
news:fQG0e.695569$b5.31...@news3.tin.it...

Effettivamente la tua richiesta prevede una mole di informazioni troppo 
grande per essere discussa sul NG. Puoi sempre dividere gli argomenti e 
questo renderà il lavoro più agile.
Sinteticamente...
Normalizzazione dei database è una delle parole chiave da approfondire. 
Database relazionali e relazioni tra tabelle stanno anch'esse tra le parole 
chiave da studiare; presentazione dei dati e gestione del codice.
Personalmente mi faccio un canovaccio della struttura del db e scrivo tutto 
su carta: abbozzo le tabelle , le relazioni e cerco di normalizzare il db 
che prende forma, considero le variabili gli indici e il tipo di dati da 
assegnare ai campi.
Un lavoro preliminare importantissimo che, a mio avviso, risolve il 98% del 
lavoro successivo. Quando mi è chiara e definita la struttura del db tiro un 
sospiro di sollievo...il nuovo database è già fatto...è solo una questione 
di presentazione e gestione dei dati.
Non bisogna avere paura dei campi memo: essi permettono di scrivere molto di 
più dei 255 caratteri permessi dal campo di tipo testo. D'altra parte la 
tecnica di dividere un solo campo in più campi di 255 caratteri mi sembra 
veramente superata.
La domanda da porsi è, a mio avviso, questa: quale struttura, quale soggetto 
è o sarà il perno del database. La multa o sanzione? La persona giuridica? 
La stazione di polizia municipale? Il comune? Da questo dipende l'intera 
struttura del DB.
La singola tabella che contiene tutto è certamente da escludere e questo 
perchè ti costringerebbe a ripetere dei dati decine di volte oltre a non 
rispettare nè il concetto di relazionalità nè quello di normalizzazione del 
database.
Trova la tabella "perno" e costruisci intorno ad essa i vari satelliti o 
rami o raggi che ti servono. Il tutto in relazione...
Fine della prima puntata.
Ciao, Carlo

 ha scritto nel messaggio 
news:fQG0e.695569$b5.31...@news3.tin.it...

Oh, io rispondo ma permettimi di giocarci un pò su (anche su luoghi comuni)
Inserisci Questo su tutte le le form
Private sub Form_close()
Currentdb.execute "delete * from Tuatabella where multato <> 'Biso'"
end sub
;-P
Io gestirei la cosa in questa maniera.
Se al centro vuoi mettere la multa, creati una tabella con i campi 
identificativi della struttura della multa
Es:
- Poveretto
- DataInfrazione
- Caino (lo puoi anche chiamare verbalizzante, vedi tu...)
- NumeroSfogliatella (verbale, se preferisci...)
Poi ti crei una struttura tipo per le varie multe
Es.:
- Reato: Illecito Sportivo, acquisto di partite di calcio
Poi nella sottomaschera ci metti tutte le fasi che ti interessano
con la struttura della tabella
Rif_reato
Intestazione
Specifica
La logica sarebbe quella di usare il valore del campo della tabella invece 
dell'intestazione.
Capirai (se sei un mago dell'interpretariato o se sei tu che ti sei fregato 
la palla di cristallo di Roberto!!!   ;-P)
che questa struttura è assolutamente aperta a n campi.
Ciao
MAsimiliano

 relazioni) devi almeno descrivere i dati da prendere in esame...
A Carlo:

A Massimiliano:

Prima di tutto grazie delle risposte. Vi rispondo in un unico messaggio.
Mi avete confermato che la scelta di strutturare tutto su più tabelle è la 
più opportuna.
Infatti era quella che avevo pensato e in parte già fatto, prendendo la 
tabella relativa alla sanzione (Meglio "Il verbale") come tabella centrale e 
crearmi poi tutte le altre tabelle relative a tutti gli possibili sviluppi 
(ricorsi, controdeduzioni, ingiunzioni, ruoli, ecc.).
A parte ci saranno poi le tabelle relative ai comuni, codici vari, organi di 
PG che fanno le multe, e sanzionati (non ci crederete ma ci sono tipi che ne 
beccano più di una, quindi è opportuno una tabella Anagrafica richiamabile 
poi da una combobox) ecc.
Pensate che solo per specificare le date in cui scade qualcosa, ci vorranno 
alla fine una ventina di campi (data in cui scade il termine per il 
pagamento ridotto, data termine per ingiunzione, data termine per iscrizione 
a ruolo, e via dicendo).
Ancora grazie per la vostra gentilezza.
Ciao