Newsgroup: it.comp.appl.access
Titolo: Vantaggi nel suddividere i campi in più tabelle.

Ciao a tutti! Ho una tabella Utenti che sta raggiungendo i 110 campi.
Molti di questi potrebbero essere raggruppati per categoria. Esempio.
DATI IDENTIFICATIVI: Nome, Cognome, Indirizzo, Data di Nascita, Città
Natale, Città di Residenza, Indirizzo. ATTIVITA': Sports, Hobby,
Impegno Sociale ecc. ecc.
Si potrebbe ridurre il n° di campi della tabella Utenti, creando tante
tabelle quante sono le categorie, e ponendole in relazione con la
tabella principale. Così, nella fattispecie avremmo 3 campi anzichè
11. Su ogni utente però, si andrebbe a creare un nuovo record sulle
tabelle categorie. Immagino che suddividendo i dati, il BE risulti più
grande, ma che l'elaborazione sulla tabella Utenti diventi più rapida.
Però è solo una supposizione.
Domanda: qual'è la soluzione migliore e perchè? C'è un n° di campi
oltre il quale è meglio suddividere i dati su altre tabelle? Grazie a
tutti per il suggerimento! ; )

tutti per il suggerimento! ; )
Non so se ci sia un numero oltre il quale sia meglio dividere.....ma ci sono
sicuramente considerazioni da fare!!! La normalizzazione č FONDAMENTALE nei db
relazionali...quindi se hai delle categorie č quasi ovvio che stiano in altre
tabelle....č cosě che si costruisce un db....(non conoscoi il tuo lavoro ma a
sentimento...). Poi, se per esempio ci sono molti campi che vengono riempiti
per pochi record, ci sono i prolungamenti orrizzontali (tabelle in relazione 1
a 1) per poter meglio gestire il tutto. Insomma, gli scenari sono tanti, ma
effettivamente 110 campi mi sembrano un po ' troppi come caratteristiche
proprie di 1 record....
-- 

?"Francesco Salvagnini"  ha scritto nel messaggio 
news:cf6152ea-5485-48b0...@q40g2000prh.googlegroups.com...



___
110 sono veramente tanti/troppi.
è vero cmq che hai un grosso problema di normalizzazione nella struttura che 
ipotizzi.
Un esempio, tu hai messo sports o anche telefono: bene, se prevedi un campo 
in cui inserire tutto ok, se vuoi l'elenco ti conviene usare una struttura 1 
a molti
in cui hai
tblAnagrafica
id
Nome
cognome
datanascita
luogonascita
codicefiscale
titolo (sig./sig.ra/avv.etcc...)
e ciò che sai essere univoco
e una lato molti tipo
tblcontatti
idcontatti
fkidAnagrafica
iTipocontatto (che è una chiave esterna su una tabella che elenca "telefono, 
email, etc...)
Contatto (in cui inserisci il numero di tel o l'email)
iPosizione (così scegli l'ordinamento delle info)
MA

Che dire? Grazie dei suggerimenti, però...
Però Vi chiederei di spiegarmi tecnicamente quali sono i vantaggi. Voi
parlate di NORMALIZZAZIONE, però questo termine a me dice poco. Cosa
significa? Suddividendo le tabelle, l'elaborazione risulta più veloce?
Oppure ci sono meno problemi di crash (boh, sparo un termine!)? Le
maschere con origine la tabella Utenti si aprono prima? Idem per le
query?
Cioè, prima di lavorare un mese e mezzo a ristrutturare il programma
(con i problemi che implicano gli aggiornamenti agli utenti che
vogliono la nuova versione!), vorrei avere uno stimolo forte... Che ne
dite?
PS: non parlate in informatichese, Vi prego!

PS: non parlate in informatichese, Vi prego!
Qua l'informatichese � di casa....� un NG tecnico....nn puoi avvicinarti ad
access senza sapere cos'� la normalizzazione!!!!! Il db relazionale VIVE su
tabelle, relazioni, indici...saresti strasorpreso vedendo le prestazioni di un
db correttamente normalizzato, indicizzato e ottimizzato...anche in ambito
mdb, senza neanche scomodare SQL server o robe cos�...maschere e query
rapidissime anche in ambito multiutente, report immediati, analisi dei dati
elocissime...jet � un gioiellino se usato bene. Quanche link x cominciare...a
studiare!
http://it.wikipedia.org/wiki/Normalizzazione_(informatica)
http://it.wikipedia.org/wiki/Database_relazionali
http://it.wikipedia.org/wiki/Modello_relazionale
http://it.wikipedia.org/wiki/Database
ecc ecc ecc.....le relazioni, gli indici, primarykey, foregkey......ecc ecc
ecc...
-- 

A volte si è catapultati in progetti di cui non si conosce tutta
l'ampiezza.
E poi Access dà soddisfazione a chiunque, anche il meno preparato, o
quello che si prepara di volta in volta consultando gli amici dell'NG.
Cosa ne pensate dell'analizzatore che c'è in Access? Suggerisce una
buona NORMALIZZAZIONE?? ; )

buona NORMALIZZAZIONE?? ; )
Che l'ambiente Access(jet+vba) sia fin troppo user friendly è stato più e più
volte discusso e bistrattato all'interno del NG....permette di fare delle
mostruosità anche a chi ha sempre e solo usato paint!!!!
Cmq l'analizzatore di access fa il suo lavoro, ma è assolutamente
insufficiente.......e tieni conto anche che le forme normali sono
teoriche....un essere umano probabilmente non le regge se applicate a
pennello!!! Il santo compromesso vince sempre....
-- 

Grazie per gli esseri umani! ; )
Ho guardato i link che mi hai segnalato, e vedrò di normalizzare 1, 2,
3, ma per adesso, mi puoi dire in parole povere, a cosa vanno incontro
i miei utenti con una tabella anagrafica da 110 campi?

 wrote in news:9ed85433-
4cf5-41ec-8ee...@i39g2000prd.googlegroups.com
:

se i tuoi utenti sanno cosa c'e' dietro la maschera qualcosa non torna, 
perche' la maschera dovrebbe fare in modo che agli utenti non serva 
sapere cosa c'e' dietro...
i 110 campi sono un problema per te.
se inventano un nuovo sport, tu devi modificare la struttura della 
tabella.
e poi aggiornare tutte le query che la consultano.
e poi aggiornare tutte le maschere che visualizzano i dati.
e poi assicurarti che nell'aver ribaltato l'intero programma per un solo 
campo tu non abbia rotto qualche cosa che prima funzionava.
e poi verificare che i dati vecchi non si siano rotti (no, non e' cosi' 
scontato che l'aggiunta di un campo sia indolore...)
e poi mandare l'aggiornamento a tutti gli utenti.
se normalizzi, quando inventano un nuovo sport/hobby/passatempo, 
inserisci una riga nell'apposita tabella e i tuoi utenti ricevono 
l'aggiornamento istantaneamente, senza che tu debba fare modifiche 
strutturali a database, maschere o codice.
se la risposta a tutta la pappardella qui sopra e' 'tanto ho una maschera 
sola', allora hai sbagliato strumento: molla access e usa excel.
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 
no.
e' molto simile al caso di prima.
attivita_disponibili
id_attivita
descrizione 
pk(id_attivita)
unique(descrizione)
scheda
id_attivita
id_utente
pk (id_attivita, id_utente)


 
un'aggiunta, perche' ho risposto a meta'...
se poi vuoi aggiungere le ore settimanali hai due possibilita'; se le
ore in cui fare quell'attivita' sono fisse e uguali per tutti, modifichi
la tabella 'attivita_disponibili', se invece ognuno ha i suoi orari,
modifichi la tabella 'scheda'. 


Cavoli mi sono perso.
Meglio azzerare tutto e darvi dei dati il più vicini alla realtà, in
modo che mi possiate consigliare per il meglio.
Tema: normalizzazione.
Oggetto: tabella Anagrafica.
Contenuto della tabella: 110 campi.
Tipo di campi:
Id: contatore Utenti
Testo: nome, cognome, carte d'identità, passaporto, cellulari,
telefoni, e-mail, note.
Numerico (la maggior parte): indicano l'id di una tabella esterna
(esempio: attività, professione, stato civile, titoli di studio..)
Data: data di nascita, assunzione ecc.
Sì-No: Flag per indicare se il soggetto ha superato determinati test,
se è attivo in azienda o è in pensione e così via.
Visualizzazione struttura tabella Anagrafica:
Id                           Contatore
Nome                     Testo
Cognome                  "
Telefono                    "
Cellulare                    "
e-mail                        "
Id_Paese                Numerico
Id_Vie                        "
Id_Professione             "
id_Status                    "
id_Titoli_Studio            "
Nascita                    Data
Assunzione                "
Test A                      Sì-No
Test B                        "
Test C                        "
Questa in miniatura la situazione. Come procedere?

 wrote in news:76fc295c-
1d06-4796-afe...@u24g2000prn.googlegroups.com
:

a spanne, io farei qualcosa del genere:
- anagrafica
id_utente
[campi anagrafica]
- lista_test
id_test
descrizione
- anagrafica_test
id_utente
id_test
- cellulare
id_utente
numero_cell
- titoli
id_titolo
descrizione
- titolo_anagrafica
id_titolo
id_utente
data_conseguimento
i nomi tabella sono messi a caso; se hai una nomenclatura usala, se non 
ne hai una, definiscila.
hai letto i documenti che ti hanno indicato nei post precedenti?


Andrebbero studiati più che letti.. d'altronde dovendo consegnare un
lavoro entro mercoledì ho pochissimo tempo.
Intanto ti ringrazio. Studio la tua risposta e poi sicuramente avrò
delle domande da farti. Intanto grazie 1000 per la tua pazienza e
buona domenica!

Eccomi qua!
La domanda sorge spontanea: perchè ho costruito un database così poco
funzionale?
Risposta: perchè non essendo un informatico ho pensato che la cosa più
urgente e importante da imparare fosse vb..
e allora vai con i forum, con la trasformazione delle macro in vb, con
l'utilizzo dell'sql delle query per costruire programmi.
Riprendiamo il discorso della normalizzazione.
Domanda: perchè non mi compero un bel manuale di access e non me la
studio? Avete ragione, però se mi date una mano è meglio.
Partiamo dalla cosa più semplice: i campi Sì/No.
Attualmente la supertabella UTENTI come abbiamo visto è:
Id_utente
Nome
Cognome
Test_a
Test_b
Test_c
Normalizziamo:
UTENTI
Id_utente  (chiave primaria)
Nome
Cognome
TEST
Id_test (chiave primaria)
Descrizione_test
ANAGRAFICA (se un Test esclude gli altri) --> non è il mio caso
Id_anagrafica (chiave primaria)
Id_utente
Id_test
Valore (campo booleano Sì/No)
ANAGRAFICA (se bisogna dare Sì/No a ciascun test) --> è il mio caso
Id_anagrafica (chiave primaria)
Id_utente
Test_A (Sì/No)
Test_B(Sì/No)
Test_C(Sì/No)
Domande:
Meglio indicizzare Id_utente e Id_testo della tabella Anagrafica?
Il Valore va in Anagrafica o in Test?
Relazioni: lego Utenti-Anagrafica e Test-Anagrafica con una relazione
Uno a Molti?
Applico l'Integrità referenziale?
Aggiorno i campi correlati a catena?
Elimino i campi correlati a catena?
La maschera come funziona? Mi sembra di capire che serve per popolare
la tabella Anagrafica giusto?
Come origine riga metto tutte e 3 le tabelle?
In effetti considerando il mio caso, non è che diminuiscano i campi
della tabella, però è vero che se ne aggiungo uno, non devo cambiare
la struttura del BE.
Sicuramente ho detto delle castronerie, Vi prego di scusarmi. Intanto
Vi ringrazio per la Vostra disponibilità. ; )

E poi un'altra domanda:
Meglio costruire le tabelle in base all'argomento (esempio: dati di
Battesimo: data, parrocchia, padre, madre, padrino, madrina e
rispettivi domicili ecc. dati di Matrimonio: Data, parrocchia,
coniuge, testimoni ecc) oppure costruirle in base al tipo di dati che
ospitano? Esempio: tabelle per dati booleani Sì/No, tabelle per dati
numerici, tabelle per dati alfanumerici.
Grazie comunque, quantunque, dovunque ; )
PS: naturalmente le varie maschere si aprono per lo meno in base agli
argomenti.

 
compratelo 'sto libro...
rispondere a domande riguardo l'abc via newsgroup diventa lungo.
puoi anche far riferimento al sitocomune, dove trovi esempi e
spiegazioni: 
http://www.sitocomune.com/


 l'intero db.
Infatti, questo è il nocciolo del discorso..andrò a studiarmi
l'architettura dei database relazionali.
Grazie dei suggerimenti!


wrote:
