Informativa:
questo sito o gli strumenti terzi da questo utilizzati si avvalgono di cookie necessari al funzionamento ed utili alle finalit� illustrate nella cookie policy. Se vuoi saperne di pi� o negare il consenso a tutti o ad alcuni cookie, consulta la cookie policy. Cliccando su "OK" acconsenti all�uso dei cookie.
OK
 torna all'home page
 
  Spazio Culturale
 
MANUALI

accesso diretto
 OFFICE
   access2000
   excel2000
   word2000
   backup
   virus
 TOOLS
   harddisk
   registry
   winzip
   dos
 WEB
   flash5
percorso:: _Home > _Manuali > _ACCESS2000 > _Capitolo 04
 fine testo aumenta dimensioni testo diminuisci dimensioni testo informazioni indice manuale ACCESS2000
     Manuale ACCESS2000
04    TABELLE    
 aggiungi ai preferiti

PROPRIETÀ CAMPI

I database relazionali sono costituiti, in genere, da molte tabelle in relazione tra di loro. Nella fase di progettazione si devono stabilire le tabelle da realizzare e le loro proprietà, basandosi sul risultato dell’analisi dei requisiti.
Di solito non è difficile capire quali sono le tabelle necessarie per la base di dati: un archivio rappresenta una particolare situazione della vita reale, ogni elemento o oggetto che si deve memorizzare è una tabella.
Ad ogni tabella si deve assegnare un NOME, che, per convenzione, è al plurale, per esempio Studenti, Libri o Clienti. Anche l’iniziale maiuscola è una convenzione. Il nome al plurale indica che la tabella non è un elemento o un singolo oggetto, ma è un contenitore di oggetti dello stesso tipo: la tabella Studenti conterrà tutti gli studenti, la tabella è unica, ma gli studenti possono essere migliaia.
Ogni COLONNA della tabella memorizza i “campi di interesse”, cioè le informazioni utili per la base di dati. Si deve decidere, per ogni tabella, quante colonne dovrà avere. Ad ogni colonna si assegna un nome, chiamato CAMPO, diverso da quelli delle altre colonne. Il nome delle colonne è, per convenzione, scritto al singolare, per esempio la tabella studenti potrebbe avere i campi Matricola, Cognome, Nome, Indirizzo, Numero di telefono, ecc. Anche in questo caso, l’iniziale maiuscola è una convenzione. Il nome del campo indica che in quella colonna verranno memorizzate le informazioni degli studenti, relative solo a quel “campo di interesse”: nella colonna Cognome verranno memorizzati solo i cognomi degli studenti, ogni altra informazione che non sia un cognome non deve essere memorizzata in questa colonna. Se per errore si memorizza il nome di uno studente nel campo Cognome, quel nome per il database verrebbe considerato il cognome dello studente stesso.
Per ogni campo si devono poi stabilire le PROPRIETÀ, cioè le caratteristiche e i vincoli dei dati che verranno inseriti nella colonna. Si deve decidere se il campo contiene un testo, un numero, una valuta, o un altro tipo di dato. A seconda del tipo di dato scelto si devono stabilire alcuni vincoli, per esempio per i testi la lunghezza in caratteri, per i numeri il tipo (intero, reale, percentuale, frazione).
La figura 4.01 illustra un esempio.
 

 
FIG. 4.01
 

La figura 4.01 rappresenta lo schema della tabella, quello che abbiamo chiamato METADATI, la tabella vera e propria si avrà solo dopo la realizzazione del database, con l’inserimento delle informazioni. Per il momento si stanno analizzando le caratteristiche principali, in seguito si studieranno in dettaglio tutti i tipi di dati e le relative proprietà.
Le informazioni riguardanti gli studenti saranno memorizzate sulle RIGHE della tabella. Ogni riga contiene un unico elemento o soggetto: ogni studente sarà registrato su una sola riga, se due righe memorizzano le stesse informazioni (stesso nome, cognome, data di nascita, ecc.), quelle due righe rappresentano, per l’archivio, due persone diverse. I dati memorizzati in una riga, che rappresentano un elemento della tabella, si chiamano RECORD. Un record può essere per esempio uno studente, un libro, un cliente. È possibile che ci siano informazioni mancanti in alcuni campi di un record, per esempio uno studente potrebbe non avere il numero di telefono.
La figura 4.02 visualizza un esempio di tabella con record.
 

 
FIG. 4.02
 

La scelta dei campi e delle relative proprietà dipende dalla base di dati che deve essere realizzata. La stessa tabella, con lo stesso nome e che rappresenta lo stesso tipo di elementi, in database diversi potrebbe essere caratterizzata da campi diversi.

ESEMPIO.
Di seguito sono visualizzate diverse possibili tabelle per rappresentare le persone, in ambiti differenti. I campi, per problemi di spazio, sono rappresentati sulle righe.
La figura 4.03 visualizza una tabella che memorizza un elenco di iscritti ad un corso.
 

 
FIG. 4.03
 

La figura 4.04 visualizza una tabella che memorizza un elenco di dipendenti di un’azienda.
 

 
FIG. 4.04
 

La figura 4.05 visualizza una tabella che memorizza un elenco di clienti.
 

 
FIG. 4.05
 

Tutte queste tabelle hanno come “soggetto” persone, ma i campi di interesse sono completamente diversi. Senza un’analisi dei requisiti accurata, la realizzazione della tabella dipendenti potrebbe essere completamente diversa, a seconda di chi realizza l’archivio. È solo attraverso l’analisi dei requisiti che si può stabilire esattamente quali campi deve avere una tabella e quali proprietà devono avere i campi stessi.

CHIAVE PRIMARIA

Il modello relazionale ha un “difetto”: i record di una tabella possono essere ripetuti. Non esiste un sistema, semplice e pratico, per controllare che lo stesso record non sia digitato due volte, su due righe diverse della stessa tabella. Questo può comportare gravi errori nel lavoro del database, si rischia di ottenere risultati sbagliati.

ESEMPIO.
Le tabelle utilizzate sono state semplificate.
SI utilizza un archivio per registrare gli iscritti ai corsi di informatica, il database è composto da più tabelle (questa situazione non è reale). La figura 4.06 visualizza la tabella dei partecipanti.
 

 
FIG. 4.06
 

Come si vede, l’impiegato che ha registrato le iscrizioni ha commesso un errore: ha ripetuto due volte il signor Rossi Mario. La figura 4.07 visualizza la tabella dei corsi, con i relativi iscritti.
 

 
FIG. 4.07
 

Il problema, che il database non può risolvere, è: l’iscritto al corso di Access Rossi Mario, corrisponde al primo record della tabella 4.06 o al quarto?

Ogni volta che si verifica una situazione di questo tipo, il database “va in crash”, o comunque non si comporta correttamente. Per evitare questo problema, è necessario definire, in ogni tabella, una chiave primaria.
Ogni tabella di un database relazionale (e in particolare di Access) dovrebbe avere una chiave primaria. La CHIAVE PRIMARIA è un campo della tabella, scelto dal realizzatore, che identifica in modo univoco ogni record della tabella stessa. In ogni tabella si deve trovare un campo i cui valori non siano mai ripetuti nelle righe dell’intera tabella, esempi di valori simili possono essere la partita IVA, il codice fiscale, la targa e il numero di serie.
Se non esiste un campo con tali caratteristiche, si deve aggiungerne uno: di solito si usa un identificatore, per esempio IdPersona, IdCliente, IdProdotto.
Nella fase di progettazione, dopo aver definito le tabelle e i relativi campi, si deve scegliere una chiave primaria per ogni tabella. Può succedere di incontrare tabelle senza chiave primaria, ma è una situazione anomala e rarissima.
La chiave primaria non risolve completamente il problema dell’esempio precedente, ma solo una parte.

ESEMPIO. Chiave primaria.
La figura 4.08 visualizza la stessa tabella dei partecipanti dell’esempio precedente, con l’aggiunta di una chiave primaria (codice).
 

 
FIG. 4.08
 

La figura 4.09 visualizza la tabella degli iscritti.
 

 
FIG. 4.09
 

In questo caso è ovvio che il numero 1 nella tabella 4.09 corrisponde alla prima riga della tabella 4.08, non alla quarta. La chiave primaria garantisce che i dati della tabella 4.09 siano sempre coerenti con i dati della tabella 4.08.
Il problema che rimane, e che non può essere risolto con mezzi semplici, è che per errore si potrebbe iscrivere Rossi Mario, con numero 4, al corso di Excel, invece di Rossi Mario, con numero 1. Questo non genera errori gravissimi, come nel caso precedente, ma comunque si possono generare situazioni anomale. Si supponga di stampare un elenco delle persone e dei corsi da loro frequentati, il risultato sarebbe quello visualizzato nella figura 4.10.
 

 
FIG. 4.10
 

Mentre Bianchi e Verdi risultano iscritti a due corsi, Rossi Mario, numero 1, risulta iscritto ad un solo corso. Non ha importanza che ci sia un altro record con gli stessi dati (valori), numero 4, infatti, ogni record corrisponde ad una persona diversa.
 

In una tabella ci possono essere più campi candidati ad essere la chiave primaria: CHIAVI CANDIDATE. In termini più semplici, possono esistere nella stessa tabella più colonne i cui valori non sono mai ripetuti, ognuna di queste potrebbe diventare la chiave primaria. Spetta a chi progetta la base di dati stabilire quale campo deve essere definito chiave primaria, la scelta non dipende solo dalle caratteristiche del campo stesso, ma anche dalle “funzioni” del database.

ESEMPIO. Codice fiscale.
Il campo codice fiscale è potenzialmente valido come chiave primaria, in quanto non possono esistere due persone con lo stesso valore di codice. Non è detto però che si possa o si debba necessariamente definire il codice fiscale come la chiave primaria di una tabella. Come si è visto negli esempi precedenti, il valore della chiave primaria viene riportato anche su altre tabelle, con il codice fiscale risulterebbe un’operazione onerosa in termini di tempo. L’impiegato addetto ad inserire i dati dovrebbe ricordare i codici fiscali di centinaia o migliaia di persone diverse, in caso contrario dovrebbe consultare la lista e copiare il codice. Sarebbe molto più semplice ricordare un numero o una sigla (molto più corti del codice fiscale). Si può anche incontrare il problema di iscritti stranieri, provenienti da una nazione senza il codice fiscale, in quel caso il campo dovrebbe rimanere vuoto. Ma, proprio perché per definizione la chiave primaria non può avere ripetizioni, non è permesso saltare il valore del campo chiave primaria, si deve inserire per forza un valore.
 

È possibile definire più campi insieme come chiave primaria, ma di solito non si usa, perché, come si è visto poco fa, i valori della chiave primaria sono ripetuti anche su altre tabelle, con grande spreco di memoria e tempo per inserire i dati ripetuti.

ESEMPIO.
Si definisce una tabella Persone con i seguenti campi: Cognome, Nome, Indirizzo, Cap, Città, Data di nascita, Numero di telefono e Indirizzo Internet. Si vuole definire la chiave primaria, ma nessuno dei campi può essere considerato chiave candidata, in quanto tutti possono avere ripetizioni. Si potrebbero definire come chiave primaria i campi Cognome, Nome, Data di nascita e Città contemporaneamente, cioè tutti insieme, è molto difficile avere ripetizioni, considerando i valori di questi quattro campi insieme. Questo è possibile e corretto per un database, ma, come detto sopra, comporta grossi sprechi se si devono indicare le persone in altre tabelle (per esempio quella delle iscrizioni), in quanto si devono riportare tutti quattro i campi.

CONCLUSIONI

Si parte dal risultato dell’analisi dei requisiti e si stabiliscono i “soggetti” della base di dati, per ogni soggetto si crea una tabella.
Si analizza ogni tabella e, sempre basandosi sul risultato dell’analisi dei requisiti, si definiscono i campi e le relative proprietà.
Infine si deve scegliere una chiave primaria per ogni tabella. Se non esistono chiavi candidate, o se quelle presenti non sono “comode”, si aggiunge un campo con tali caratteristiche.
Non è sufficiente che un campo abbia le caratteristiche per essere la chiave primaria, in Access (anche negli altri programmi) si deve utilizzare un comando per indicare ad Access tale proprietà.


     Manuale ACCESS2000
04     TABELLE    
 
 inizio testo aumenta dimensioni testo diminuisci dimensioni testo informazioni indice manuale ACCESS2000
 
 
Pubblicità  
 
Applicazioni iPhone















Condizioni d'uso | Informativa Privacy e Cookie Policy | Crediti
Copyright©2005 tutti i contenuti sono proprietà esclusiva di ManualiPc.it

 
Manualipc - Via Casette 13 - Saletto di Breda - 31030 Treviso, Italy - tel. 0422.98135 - email info@manualipc.it - P.I. 03687860266