Newsgroup: it.comp.appl.access
Titolo: Struttura database...

Salve,
dovrei gestire gli automezzi dell'azienda...
di ogni automezzo vorrei inserire Targa, immatricolazione, tipo, modello
ecc)
poi controllare (sempre di ogni automezzo):
Assicurazioni ( data_inizio, data scadenza, importo ecc)
Manutenzione ( data_manutenzione, descrizione_intervento, ecc)
Revisione (Data collaudo, scadenza, ecc)
Devo creare 4 tabelle ?
e come metterle in relazione?
potreste darmi un consiglio?
mi piacerebbe aggiungere altre tabelle ma per adesso meglio accontentarmi
(considerando la mia poca esperienza..)
Grazie!

 ha scritto nel messaggio
news:wJIJa.113620$Ny5.3...@twister2.libero.it...


 ha scritto nel messaggio
news:wJIJa.113620$Ny5.3...@twister2.libero.it...

Direi che sei sulla strada giusta: come chiave primaria per la tabella
Automezzi puoi tranquillamente usare il campo Targa che è univoco, il quale
deve essere riportato nelle altre tabelle collegate (relazione 1 a molti).
Per la tabella revisioni, visto che l'intervallo minimo dovrebbe essere un
anno, potresti usare una chiave primaria costituita dai campi Targa
(collegato con la tabella automezzi) ed Anno di revisione.
Per la tabella Assicurazioni, dato che teoricamente potresti farne una
diversa ogni mese, per la chiave primaria io metterei un progressivo da
gestire autonomamente (odio i campi contatore), sempre da unire di seguito
alla Targa automezzo.
Lo stesso per la tabella Manutenzioni. A questa potresti legare una
ulteriore tabella con le righe di dettaglio dei lavori svolti, o pezzi
sostituiti, ma se sei alle prime armi, creati un bel campo di descrizione
breve con il riassunto del lavoro svolto, e poi un bel campo memo in cui
puoi abbondare con i dettagli dell'intervento.
Spero di esserti stato utile... Ciao


 bè.. se va a te... a me piacerebbe vedere com'è !
fai tu!
grazie cmq
... e cmq perchè non mi dai una mano dicendomi come strutturare il
programma?
almeno le 3-4 tabelle principali...
:) ciao e scusami.

 ha scritto nel messaggio
news:PjKJa.234394$g92.5...@news2.tin.it...

Scusami, non ho capito alcune cose..
1) perchè per la tabella revisioni usare un campo chiave composto da Targa e
anno di revisione?
2) lo stesso per la tabella Assicurazioni
3) idem per manutenzioni
a cosa servono queste chiavi doppie? e come si gestiscono?
Grazie Francesco

 a cosa servono queste chiavi doppie? e come si gestiscono?
Non sono all'altezza di spiegare la teoria dei database, per la quale sono
stati scritti decine di libroni molto complessi, cmq qualche informazione
proverò  a buttarla giù, sperando di essere + di aiuto che di confusione.
Inoltre, dato che ho notato che molti si avvicinano ad Access trattandolo
quasi come un foglio elettronico, qualche volenteroso + capace di me,
potrebbe aggiungere altre informazioni e regole di aiuto per i nuovissimi.
PRIMA PUNTATA
-Un sistema di gestione di database (DBMS) (molto semplicisticamente),
consente di memorizzare informazioni tra loro omogenee, in strutture di dati
che in Access vengono chiamate Tabelle e memorizzate in un unico file
insieme a tutto il resto (in altri sistemi hanno altri nomi, o + comunemente
vengono creati tanti file su disco).
-La funzione principale di un gestore di database è quella di occuparsi,
anzitutto di dare gli strumenti per la creazione e manipolazione delle
strutture di queste tabelle (definizione campi, loro tipologia, aggiunta,
eliminazione, definizione delle chiavi, ecc...),  successivamente di
provvedere ad inserire, ritrovare, modificare e cancellare, le informazioni
che gli utenti forniranno o richiederanno.
-Prima ho parlato di strutture di dati omogenee; nessuno ci picchierà, se
per memorizzare le ns. informazioni, creeremo un unica tabella costituita da
un unico campo memo, in cui inserire ogni cosa ci venga in mente di voler un
giorno ritirar fuori.
Tuttavia a questo punto avremo una situazione paradossale, simile ad un file
di testo contraddistinto da un nome, in cui nessuno se non noi (dotati di
molta pazienza) potrà poi ricavarne niente.
E' proprio qui il punto e la difficoltà del progettare una struttura di
database: Occorre suddividere il materiale o la questione (rabbrividisco per
il termine), che vogliamo gestire, in sottounità tali che il sistema possa
meglio trattarle, con gli strumenti che ha a disposizione: lui è una
macchina, non è in grado di percepire cose complesse come le percepiamo noi,
ed allora dobbiamo rendergliele semplici semplici (non me ne vorranno i
seguaci dell'intelligenza artificiale e sistemi di autoapprendimento, qui
siamo terra terra, inseriamo informazioni e le rivogliamo indietro, magari
raggruppate in bella forma).
-La prima entità base per memorizzare una questione (qualcuno mi suggerirà
un termine migliore), è la tabella stessa, nella quale ogni volta che
andremo ad inserire un gruppo di informazioni, il sistema le memorizzerà
tutte insieme in un record (memorizzazione).
-A sua volta un record può essere scomposto in una serie di campi, ognuno
specializzato a ricevere un ben determinato tipo di informazione e solo
quello. Nei campi, se ben creati, potremo riporre ben suddivisa e catalogata
ogni singola informazione.
-Ricordiamo sempre che tutti i campi che costituiscono un record di una
tabella, vengono scritti e letti in un'operazione unica dal gestore di
database e sarà proprio questa caratteristica a farci decidere quali campi
comporranno il record di una tabella.
Ripeto: + sapremo catalogare, spezzettare e specializzare le strutture di
dati che accoglieranno le informazioni, + la ns. macchina stupida sarà in
grado di capirci qualcosa e darci ad intendere di essere intelligente,
estrapolando ed aggregando informazioni in maniera fulminea.
L'altra faccia della medaglia, sarà la crescente complessità della struttura
che andremo a creare, con i conseguenti costi in termini di tempo per la
creazione di tutti gli altri elementi che girano intorno alle tabelle:
query, maschere, stampe, ecc...
Considerazione: Una struttura ben creata, consente l'aggiunta anche a
distanza di tempo di nuove componenti, con uno sforzo di molto inferiore a
quello necessario se non si fosse partiti col piede giusto.
-Prima di passare alle chiavi ed alle relazioni, prendiamo l'esempio
originale:
Voglio gestire tutto ciò che ruota intorno agli automezzi di una azienda.
Anzitutto avrò un'entità Automezzi; cosa voglio memorizzare di un automezzo?
Targa, Tipo di automezzo (auto, furgone, camion, ecc...),  N°Di telaio, Tipo
di carburante (benzina, gas, gasolio, ecc...), tutte le polizze assicurative
su quel mezzo, per ogni polizza i vari premi pagati, tutte le manutenzioni
eseguite, in ogni manutenzione, i vari pezzi cambiati. E qui mi fermo, xchè
sennò ad agosto non vado in ferie.
OK, decido di creare un'unica tabella automezzi, nella quale ogni record
conterrà tutte queste informazioni, da scrivere e reperire in un unica
operazione.
Daccordo, per alcuni campi tutto bene, tuttavia... quanti campi destinare
per accogliere ad es. Polizza1, polizza2, ..., PolizzaN?
Inoltre per ogni polizza voglio memorizzare tutta una serie di informazioni:
Polizza1: Scadenza1, Importo1; Scadenza2 Importo2; Scadenza3, Importo3
Polizza2: Scadenza1, Importo1; Scadenza2 Importo2; Scadenza3, Importo3
ecc...
Posso prevedere un numero massimo di elementi sufficienti, e creare tanti
campi per contenerli; tuttavia, in questo modo, da un lato rischio di non
prevederne a sufficienza, da un altro, rischio di sprecare uno spazio
immenso se non ho informazioni da inserire.
SIAMO ARRIVATI AL PUNTO CRUCIALE:
In realtà sono in presenza di un'entità a se stante "Polizze", se infatti mi
creo una tabella a parte, in cui contenere le polizze, avrò un record per
ogni polizza, quindi tutte e solo le polizze che voglio, senza alcuno spreco
di spazio.
SARA' SUFFICIENTE inserire all'interno del record della polizza, ad esempio
il numero di targa dell'automezzo su cui è stata fatta, per ricondurla solo
e soltanto a quell'automezzo.
Bene, definiamo i campi che compongono il record della ns. tabella Polizze:
N°Polizza, N°Targa automezzo, Compagnia, Data decorrenza, Data estinzione,
Scadenza1, Importo1; Scadenza2 Importo2; Scadenza3, Importo3.
Di nuovo, per i primi campi va tutto bene, però per quanto riguarda le varie
scadenze, non sappiamo quanti campi dobbiamo destinare per contenere tutte
le possibili scadenze passate e future di una certa polizza.
DI NUOVO, ci troviamo in presenza di una entità a se stante "Scadenze", per
la quale creeremo un'altra tabella.
Sarà sufficiente nel record della scadenza, indicare il N° di polizza cui la
scadenza si riferisce, per ricondurla solo e soltanto a quella polizza.
Tabella Scadenze:
N°Polizza, Data decorrenza rata, Data scadenza rata, Importo
A QUESTO PUNTO abbiamo creato una struttura composta da 3 tabelle:
Automezzi, Polizze, Scadenze, che da un punto di vista logico sono in
relazione tra loro, occorre solo farlo comprendere fisicamente al ns. Access
e poi si può andare avanti.
Di fatto abbiamo già creato i presupposti per la definizione delle chiavi
primarie e delle relazioni tra tabelle, delle quali però...
IL SEGUITO ALLA PROSSIMA PUNTATA!!!
Son quasi 2 ore e mezzo che scrivo, ora devo andare al lavoro.
Fatemi sapere qualcosa se tutto questo esiste già sul sito comune (io
scorrendolo non l'ho visto), oppure esula dalle ragioni del NG.
Ciao a tutti.

 ha scritto nel messaggio

Il problema e' grave.
Quando si crea una applicazione non si parte dall'idea "Ok, ora mi seggo
davanti al pc e vediamo... quante tabelle? Si', forse tre o quattro." e
comincio a crearle.
Prima di tutto si spegne il pc per resistere alla tentazione di sedercisi
davanti,
poi si prende carta e penna e si comincia ad elencare tutti i dati che si
intende gestire,
a questo punto inizia la parte lunga nella creazione di un database: lo
studio di come dovranno essere strutturati i dati.
Ci sono interi testi in libreria che parlano solo di questo senza neanche
arrivare alla definizione di quale strumento SW utilizzare, anzi ti
consiglio di cercarne uno di questi testi e di leggertelo.
Sib

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:7ISJa.132488$pR3.3...@news1.tin.it...

Non farmi ridere Sib..
inutile dare queste risposte a chi chiede un consiglio e cmq nessuno ti ha
obbligato..
Se ti innervosisci leggendo queste cose fai finta di niente..
..e poi dovresti rispondere così a tutti i frequentatori di questo
newsgroup...
mah
Non te la prendere su!
Faccio tesoro di quanto hai detto (anche se non c'èra bisogno che lo dicessi
tu!)
grazie cmq :)
Ciao

 ha scritto nel messaggio
news:S72Ka.116772$Ny5.3...@twister2.libero.it...

Sib in effetti ha dato un consiglio assolutamente giusto, uno dei più
ricorrenti motivi di frustrazione per un programmatore, è arrivare ad un
certo punto e trovarsi in un vicolo cieco, oppure dover ricorrere a
soluzioni bruttissime per poter andare avanti e tutto questo per ovviare ad
una mancanza di progettazione iniziale.
A tal proposito posso suggerire di leggere almeno la prima parte del libro
"UML e Ingegneria del software" scaricabile dal sito 
www.mokabyte.it
 , io
l'ho iniziato e mi sembra interessantissimo.
Quindi secondo me, rimane l'assoluta verità di quanto Sib ha postato.
Tuttavia, credo che anche lui (non ne conosco l'età), almeno all'inizio sia
stato affascinato dal mettersi li a smanettare per far apparire qualcosa da
quel bussolotto grigio (dicesi monitor).
Mettiamola così, per imparare a suonare, si può partire andando direttamente
a scuola di musica, oppure si può iniziare a strimpellare qualcosa per il
puro divertimento di farlo. Certo in quest'ultimo modo ad un certo punto se
ne troveranno i limiti, ed in maniera automatica si andrà a cercare qualcosa
che affronti la questione da un'altra prospettiva.
In entrambi i casi, se uno ha talento, alla fine questo viene fuori da solo.
Altra osservazione.
Come potrete trovare nel libro citato, uno dei metodi di progettazione del
software che sembra possa dare un buon successo, è quello detto "iterativo,
ed incrementale", stando al quale, si parte da una serie di requisiti, se ne
stabiliscono alcuni + urgenti e fondanti degli altri, li si verifica secondo
le aspettative del cliente e quindi si valuta se i restanti sono rimasti
tali, hanno subito variazioni, ecc... Quindi si ridanno le priorità e si
ricomincia.
Va da se, ma forse non tanto, che in ogni fase, la modularità e la
flessibilità del manufatto creato (così viene ora chiamato il sw!!!), devono
restare un obiettivo primario.
Per chiudere: bando alle polemiche, rimbocchiamoci le maniche (questo è
rivolto a te Sib) e a tutti gli altri molto più esperti di me (non cito per
educazione, ma in questo NG sono davvero molti) e proviamo a buttar giù una
miniguida terra-terra, chissà che non possa divenire qulcosa di più.
Intanto appena avrò un attimo di tempo (non domattina che ho da fare), parto
per la seconda puntata.
Attendo aiuti.
Ciao a tutti.

samR ha scritto:

mah?! cito:".......a cosa servono queste chiavi doppie? e come si
gestiscono?..."
non riporto l'autore che sicuramente conosci.
Ricito:".....Ci sono interi testi in libreria che parlano solo di questo
senza neanche arrivare alla definizione di quale strumento SW
utilizzare, anzi ti
consiglio di cercarne uno di questi testi e di leggertelo...." qui
l'autore  non e' cosi' riconoscibile e sinceramente lo trovo un po'
ermetico. Il concetto, comunque, ha una sua verita'. 
Se riesci a tenere alta l'entropia, forse, il db e' valido 
(anonimo)
Avevo scritto "bassa" ma poi ci ho ripensato.
--
a.cara
togli qualcosa dall'email

 Avevo scritto "bassa" ma poi ci ho ripensato.
What's?
Sib

 tu!)
Questa mi sembra una buona idea, anzi, per maggiore chiarezza, ho lasciato
la parte della mia risposta che rappresenta il mio consiglio, che non era,
come hai impropriamente pensato, una polemica, ma un vero e proprio
suggerimento su come procedere.
Nessuno che non conosca a fondo la tua problematica puo' darti consigli
sulla struttura da creare senza il rischio che, al 90% del lavoro, tu debba
rivedere tutto.
Sib

 > obbligato..
Questa me l'ero persa!
Dopo la sindrome di calimero mancava da un po' la sindrome del "rispondi
come dico io o non rispondere!"
Antonio

 miniguida terra-terra, chissŕ che non possa divenire qulcosa di piů.
[CUT]
Sei sicuro che in questo NG sia opportuno scrivere il bignami della
progettazione dei database?
I bignamini sono sempre serviti a preparare gli esami per le materie di
corollario, ma non credo che uno che volesse diventare un bravo medico
studiasse anatomia su un bignami.
Penso che scopo del NG sia suggerire a chi č in difficoltŕ delle soluzioni
(insomma come ha fatto Sib, anche se nel farlo a pestato involontariamente
la coda di paglia di samR); come ho giŕ detto in altre occasioni, a mio
parere non sarebbe giusto trasformare il NG in un corso per corrispondenza
su Access.
Insomma , se qualcuno non ha idea di come si progetta una base di dati, gli
si dice dove studiarselo.
-- 
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------


Ehi Sib, SCUSAMI!
Si, è vero, forse ero anche un pò agitato quando ho risposto, per cui ho
pensato subito ad una polemica...
tu potevi anche capire, dalla semplicità della domanda, che non si sta
parlando di programmi così importanti da richiedere uno studio approfondito
di database relazionali ecc ecc
se avessi chiesto come strutturereste un programma di contabilità aziendale
con fatturazione, ddt, piano dei conti, centri di costo ec ec allora si...
avresti potuto subito pensare. "questo è scemo, non sa mettere in piedi 3
tabelle e vuole fare un programma di contabilità.."
Cmq sicuramente ho interpretato male quanto hai detto e ti chiedo scusa!
Ah Sib, dimenticavo...
3 tabelle
Automezzi, Assicurazioni e manutenzioni
potresti suggerirmi la struttura per metterle in relazione?  (scherzo
naturalmente, però spero in una tua risposta :) )
Ciao !
Grazie :)

 ha scritto nel messaggio
news:u9eKa.118071$Ny5.3...@twister2.libero.it...

No, non ne sono sicuro, tuttavia sono partito dal presupposto che approcci
diversi ad una questione, possono comunque portare ad avere (magari in tempi
diversi), risultati soddisfacenti.
Sopratutto č importante che ad essere soddisfatta sia la persona che
intraprende il cammino di formazione, in base agli obiettivi che si č posta.
Magari sembra banale il parallelo che ho fatto con l'apprendimento della
musica, ma secondo me calza abbastanza: qualcuno parte giŕ con le idee
chiare sullo sforzo da intraprendere, qualcuno, si accontenta di arrivare ad
una festa con gli amici e farsi bello strimpellando il motivetto di Baglioni
stile anni andati, qualcun'altro (io sono di una categoria intermedia tra la
prima e l'ultima), una volta stupiti gli amici, si rende conto di volere di
piů e solo a quel punto, avendo assaggiato la caramella, di essere disposto
a ben altro per avere tutto il pacchetto.
Credo che se facessimo un sondaggio, ogni frequentatore di questo NG
vorrebbe avere le conoscenze dei frequentatori piů competenti, ma se poi gli
si chiedesse quali sono le reali cose che si propone di fare con Access, in
relazione alle ore necessarie ad ottenerle, solo pochi sarebbero disposti a
fare tanto studio.
Del resto Microsoft ha tirato fuori un prodotto, che se da un lato č in
grado di accontentare i programmatori piů smaliziati, daltro canto č, e
rimarrŕ un pacchetto commerciale volto all'utente medio di PC, che si trova
in una qualsiasi azienda.
...Sě, io credo sufficientemente che, non un bignami, ma un breve testo, che
quantomeno possa far capire che razza di strumento un novizio si trova
davanti, ed un flash sul tipo di atteggiamento mentale in cui bisogna
calarsi prima di affrontare la bestia, ad alcuni possa risultare piů che
utile.
P.S.
Oh! Non volevo sollevare un polverone, anche xchč le mie conoscenze si
fermano lě. Ad averlo saputo me ne stavo buono buono.
Ciao a tutti.

 ha scritto nel messaggio
news:q7nKa.248525$g92.5...@news2.tin.it...

Bč adesso non tirarti indietro... hai promesso la seconda parte...
:)


SECONDA PUNTATA
Come ci si aspetta da un bravo gestore di database, (DBMS (Access è un RDBMS
ma faremo la distinsione in seguito)), una volta datigli in pasto tutti i
ns. dati, quando li rivogliamo indietro, dato che il ns. PC rimane una
macchina piuttosto stupida, almeno che riguadagni punti dimostrandosi un pò
veloce: pertanto non è che questi record memorizzati li può mettere a
casaccio, ed infatti come una brava segretaria, se li dispone secondo un
certo criterio, in base alle esigenze del capoufficio, per poi ritirarli
fuori su richiesta.
Tutto bene, se non fosse che il capoufficio è uno di quelli che sclera mica
male, quindi un giorno glieli chiede per nominativo, un'altro per indirizzo,
un'altro ancora per data di nascita...
E la segretaria giù lì, ogni giorno a riordinare tutte quelle schede, almeno
gli pagassero gli straordinari...
Ma quella mica è fessa, alla terza volta, ha adottato una tecnica di questo
tipo:
Le schede le ripone una dietro l'altra come arrivano arrivano e per ogni
scheda si segna la posizione nell'archivio in cui l'ha messa (posizione
fisica del record), contestualmente, per quelli che sono i dati (campi) in
base ai quali effettuare le ricerche, si ritaglia tanti pezzetti di
cartoncino, sui quali ad esempio si segna:
(nominativo: "Rossi Arturo" - posizione archivio: 653.127),
(indirizzo: "Via Vattelapesca,105 - Roma" - posizione 653.127),
(data di nascita: 15/11/2001 - posizione archivio: 653.127),
(codice fiscale: GFAFGR68E15D288F - posizione archivio: 653.127),
a questo punto, gli basta mettere in ordine ognuno dei quattro cartoncini
nella rispettiva lista (indice), per poter rapidamente ritrovare la cartella
indicata, secondo il dato richiesto (chiave).
Nota: Chiaramente l'esempio riportato è del tutto semplicistico, e le
tecnologie adottate dai vari DBMS possono essere sofisticatissime e
diversificate a seconda del tipo di informazione da trattare (In merito si
rimanda alla vastissima letteratura sull'argomento), tuttavia il concetto
alla base rimane quello: in varia maniera tenere ordinati dei piccoli
indici, che puntino al grosso record memorizzato in una data posizione.
CHIAVE PRIMARIA (UNIVOCA), CHIAVI SECONDARIE (UNIVOCHE oppure DUPLICABILI):
Se stiamo ad un festino tra pochi amici e si fa un'estrazione a premi, sui
biglietti potrebbe bastare segnarsi il nome della persona, tuttavia è
sufficiente che due persone abbiano lo stesso nome per scatenare una bella
rissa e mandare a pallino l'intera serata.
No, bisogna assegnare un dato ad ogni persona, che possa identificare lei e
solo lei all'interno del gruppo: questo dato deve essere UNIVOCO.
Si potrebbe optare per un numero crescente (chiave numerica progressiva),
oppure tra le informazioni (campi) relative alla persona, trovarne una che
sia già indiscutibilmente univoca, e nel ns. caso potrebbe essere il 'codice
fiscale'. Bene, per il ns. gruppo di festaioli abbiamo creato una chiave
primaria che per definizione è e deve essere univoca.
Ragioniamo bene, nel caso precedente della segretaria, non le sarà stato
sufficiente prepararsi gli indici per i campi [Nominativo], [Indirizzo],
[Data di Nascita] e [Codice fiscale]:
-Infatti i primi 3 campi non possono porre in essere una chiave primaria,
perchè se è innegabile che  rendono sicuramente più agevole la ricerca delle
schede, è altrettanto lampante che in caso di omonimi, o abitanti nello
stesso condominio, o nati lo stesso giorno, le schede restituite dalla
ricerca potrebbero essere anche molte: i primi 3 campi si dicono "chiavi
secondarie duplicabili", utilissime sì, ma non indirizzanti univocamente ad
un solo record.
-Resterebbe il [Codice fiscale], che essendo univoco, ad una prima analisi
si presterebbe benissimo a divenire "chiave primaria", tuttavia bisogna
calarsi bene nei casi pratici che si andranno a presentare nel lavoro
dell'ufficio di tutti i giorni (utilizzo dell'applicazione), frequentemente
ci si troverebbe a memorizzare la scheda di una persona, magari con
centinaia di dati e non avere sul momento disponibile il codice fiscale
della persona stessa.
No, la nostra brava segretaria si sarà preparata uno di quei timbri a
numerazione automatica, con il quale assegnare un numero di protocollo per
le schede, ed avrà previsto un'altro cartoncino (N° Progressivo - posizione
archivio), che a questo punto diverrà la chiave primaria dell'archivio.
-Per quanto riguarda il  [Codice fiscale], esso rimarrà comunque
induplicabile (univoco), la sua assenza non genererà blocchi di sorta
durante l'archiviazione, se però si tentasse per due nominativi diversi di
inserire lo stesso codice, durante l'ordinamento dei
cartoncini(indicizzazione) la ns. segretaria (DBMS)  si accorgerebbe del
doppione e segnalerebbe l'errore interrompendo l'archiviazione. Nel ns.
esempio il [Codice fiscale] diviene una chiave secondaria univoca.
--------------------------------------------------------
NOTA.
Quello che stò cercando di evidenzare con un linguaggio anche improprio, è
che dietro un pacchetto che di prim'acchitto può sembrare semplice ed
amichevole, si nascondono teorie matematiche e logiche molto complesse,
senza la conoscenza almeno superficiale delle quali, appena ci si spinge un
pò oltre la creazione guidata che Access mette a disposizione, si è
destinati per forza a fermarsi.
In merito spero almeno di fornire un'idea, un'accenno, a quanto dovrete (e
devo) imparare.
---------------------------------------------------------
Rinnovo l'invito a segnalarmi inesattezze (castronerie), o carenze su quanto
esposto.
Per adesso basta.
Ciao a tutti, ed alla prossima puntata.

 Per adesso basta.
Non c'hai proprio un cavolo da fa eh? :-P
Antonio

 Ciao a tutti.
Per quanto mi riguarda non hai alzato alcun polverone, perň resto
dell'avviso, prescindendo dall'utilitŕ dei bignami su Access, che il NG non
č il luogo adatto dove tenere corsi su Access per corrispondenza ed a
puntate.
Forse il Sito Comune potrebbe essere piů adatto, naturalmente dopo aver
concordato con il webmaster la creazione di una sezione specifica.


 ha scritto nel messaggio
news:hmxKa.122942$lK4.3...@twister1.libero.it...

Veramente, anche se non sembra, da fare ne ho veramente troppo, però visto
che comunque le incompiute sono più frustranti delle compiute pur dozzinali,
ormai pur pentito, porto a termine e poi mi ritiro.
Ciao.

 ha
scritto:

Tempo fa si parlava di costruire un db con l'ausilio di tutto il NG. Dopo
mesi di vuota discussione iniziai a metetre giù l'impostazione e le tabelle.
Adesioni = ZERO.
Sorry
MAssimiliano
--------------------------------
Inviato via 
http://usenet.libero.it

 naturalmente, però spero in una tua risposta :) )
Vabbe', diciamo questo:
In linea di principio devi partire dal presupposto che la tua struttura deve
avere, in linea di principio, un fulcro principale (nelle strutture piu'
complesse possono essere piu' d'uno, ma nel tuo caso non cerdo).
Nel tuo caso, certamente, il fulcro e' rappresentato dagli automezzi che
hanno determinate proprieta' (assicurazioni e manutenzioni).
Detto questo dovrebbe risultarti intuitivo come strutturare la tua base dati
Sib


che e' che?
--
a.cara 
Togli qualcosa dall'email

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:UmAKa.144479$pR3.3...@news1.tin.it...

:) ehi Sib, non ti va proprio di sbottonarti un pò eh?
Ho creato 4 tabelle, Automezzi, Assicurazioni, Revisioni, Manutenzioni;
Tutte le tabelle hanno il campo Targa in comune... (anche su consiglio di
Francesco R)
quindi Automezzi è in relazione 1 a molti con Assicurazioni, Revisioni,
Manutenzioni...
i record vengono inseriti di volta in volta in ogni tabella nel senso che
ritiro l'assicurazione e ne registro, nella tabella SCADENZAPOLIZZA in
relazione con ASSICURAZIONI per mezzo del Campo Polizza,  il mese di
decorrenza, l'importo ecc mentre la scadenza viene calcolata in base ad
un'altra tabella che ha un campo descrizione ed un campo numerico intero del
tipo:
MENSILE 1
TRIMESTRALE 3
SEMESTRALE 6
Ecc..
quindi  quando mi serve la scadenza:
DATASCADENZA = DateAdd("m"; ValoreSemestrale; [Decorrenza]) per calcolare la
scadenza semestrale dell'assicurazione...
è una procedura che ha senso secondo te?
è preferibile gestire le scadenze a parte?
 se è troppo confusa come domanda abbi pazienza... :)
Ciao e grazie!


Poco tempo fa ho già provato a buttar giù ad uso personale, uno schemino sul
quale basare l'impostazione di default, la verifica e l'abilitazione, di una
serie di campi interdipendenti, in maniera da potermi basare su quello ogni
volta che vado a costruire una maschera, indipendentemente dalla sua
complessità. Funziona ma è troppo farraginoso. Non sono per niente
soddisfatto.
Mi è arrivato il libro su Access 2000 che mi avete consigliato, spero di
riuscire a trovare lì qualche spunto per snellire di molto lo schema,
altrimenti potrei sottoporlo al NG per averne dei commenti e naturalmente
(in tal caso), mi farebbe piacere leggere i tuoi. Cmq dovrà passarne di
acqua, xchè ora stò andando avanti su altre cose.
A prop. la Jackson Libri sembra sia in amministrazione controllata o giù di
lì, il libro 'Access 2000 manuale di programmazione' non si riesce più ad
averlo ordinandolo in libreria, ma solo attraverso internet.
Ciao a tutti e scusate il non cambio di subject.

 concordato con il webmaster la creazione di una sezione specifica.
Su questo, Roberto concordo in pieno con te, ma a prescindere dal documento
in questione, un NG è il luogo informatico naturale dove a più mani il
documento stesso può essere elaborato, accresciuto e messo a punto, per poi
infine essere messo a disposizione della comunità informatica su di un sito.
Ciao a tutti.

 che e' che?
Di quale entropia parli?
Perche' alta e non bassa?
Sib

 avere, in linea di principio, un fulcro principale (nelle strutture piu'
cut
Caz...
ma quante linee di principio ci'ho messo?
Sib

 č preferibile gestire le scadenze a parte?
Direi che, siccome le assicurazioni hanno una data di scadenza ben precisa
indicata e che puo' non corrispondere esattamente a tot mesi dopo la
stipula, e' preferibile indicarla esplicitamente in tabella.
Sib

 "Insegna a pescare, non dare il pesce"
Questa è istigazione alla prostituzione!!!
Antonio

 Perche' alta e non bassa?
cito:
"....Maggiore entropia significa 
più disordine (ovvero più stati dinamici possibili), minore entropia significa
più ordine (ovvero meno stati dinamici possibili)...." 
Metti un db in 5NF e poi misurane il "disordine".
In genere mi fermo alla 3NF e pure denormalizzata ("sometimes"), la 4 e la 5
dicono che esistono, per quanto mi riguarda, in antico italico aulico, le
ritengo "pippe al cervello"
Vuoi mettere un bel file sequenziale in 1NF quella si che e' vita!


 ha scritto nel messaggio
news:maPKa.257317$g92.5...@news2.tin.it...

Rispetto il tuo punto di vista ma non lo condivido.



Caz...
ma che c'entra l'apostrofo?
Sib

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:Pq2La.263935$g92.6...@news2.tin.it...

Caz...
ma non potresti farti meno problemi?

 [CUT]
TERZA PUNTATA
... la morte nera aveva ormai scoperto il covo dei ribelli sul pianeta ...
chsrssshshzhzrshhhst ...
... aspettate, adesso mi sintonizzo meglio ...
eccoci qua, prima di tornare ai ns. automezzi, che nel frattempo cominciano
a dare segni di usura, supponiamo di dover identificare all'interno di un
database (qui si parla di Access), il posizionamento dei materiali in un
magazzino, si ha quindi una tabella "PosMag" con i seguenti campi:
[N°Ripiano], [N°Cella], [Quantità max]
Nella scelta di come definire una chiave primaria, andiamo a vedere se tra i
campi che sono nel record ne esiste almeno uno che risulti univoco per
identificare quella e solo quella posizione di magazzino... no! Niente da
fare, ci sarebbero + record con lo stesso ripiano e cisarebbero più record
con lo stesso N° di cella.
Allora potremmo optare per un N° progressivo, magari da gestire via codice
per consentirne modifiche e tutto filerebbe via liscio, magari si potrebbero
eliminare addirittura i campi [N° Ripiano] e [N° Cella] e costringere il
magazziniere a rinumerare tutte le singole celle con il progressivo che il
CED gli suggerisce (con somme bestemmie del magazziniere (e sì che ce ne
sono di programmatori che vorrebbero trasformare le aziende sulle necessità
dei propri programmi))... Lasciamo in pace la realtà (ed i campi esistenti)
e continuiamo a
ragionare sul N° progressivo: come dicevo, tutto funzionerebbe, senonché
sarebbe un campo in più, che comunque occupa dello spazio, deve essere
gestito nelle maschere e stampe, ma sopratutto nel nostro caso, è poco
significativo se non ai fini della chiave stessa.
Guardiamo meglio, se si potesse creare una chiave primaria che comprendesse
in se i campi [Ripiano] & [N°Cella], saremmo a posto, infatti per ogni
record avremo identificato la singola cella all'interno del ripiano e la
chiave risulterebbe appunto UNIVOCA. Bene diviene stucchevole confermare che
questa possibilita esiste e viene anche utilizzata spesso.
Nota operativa:
Per usarla all'interno di Access, è sufficiente andare nella modalità
struttura di una tabella, selezionare nella parte in altro a destra i campi
interessati e quindi fare click sul tasto con la chiave gialla nella barra
degli strumenti. In alternativa, dal menu 'Visualizza' scegliere 'Indici',
per far comparire una finestra dove si possono definire tutte le chiavi
della tabella con le relative proprietà (per ogni dettaglio si rimanda alla
guida in linea, o a qualsiasi guida su Access: anche in quelle tipo "Tutto
Access in 15 minuti", sono costretti a parlarne)
A noi per il momento interessa di + avere un'idea dell'atteggiamento mentale
in cui ci si cala nel progettare la struttura di un database (piuttosto,
come consigliato da Sib, si prendono carta e penna e l'unica
cosa che deve rimanere accesa e collegata è il ns. cervello).
A questo punto, siamo pronti a definire le chiavi primarie per le tre
tabelle del database per la gestione degli automezzi che abbiamo iniziato a
costruire:
Per la tabella "Automezzi" sarà: [Targa] che è univoca e sempre disponibile
come dato per ogni automezzo.
Per la tabella "Polizze" sarà: [N°Polizza]
Per la tabella "Scadenze" sarà una chiave a due campi formata da:
[N°Polizza] & [Data decorrenza], chiave che identificherà univocamente ogni
decorrenza all'interno della propria polizza.
Inoltre abbiamo visto che per legare il record della polizza al relativo
automezzo, sempre all'interno della tabella "Polizze" (guarda caso), abbiamo
riportato il campo chiave della tabella automezzi [Targa], perlappunto una
chiave univoca che una volta inserita anche all'interno del record della
polizza, lo legherà ad un solo record della tabella "Automezzi".
Ma continuiamo a ragionare ancora sulla scelta della composizione della
chiave primaria, che è un argomento molto importante, in quanto da questa
dipenderà molto del lavoro che dovremo svolgere nella gestione delle varie
tabelle.
Nel precedente caso del magazzino, supponiamo di voler memorizzare per ogni
articolo la posizione in cui lo stesso viene riposto: Come nel caso del
campo [Targa] portato nella tabella "Polizze", nella tabella "Articoli" sarà
sufficiente riportare i campi [N°Ripiano] & [N°Cella]che formano la chiave
primaria della tabella "PosMag, per indicare con precisione in quale
ripiano/cella l'articolo è stato posizionato.
Ora, supponiamo che la ns. azienda non risieda in un sottoscala di un
condominio e che + realisticamente la ns tabella con le posizioni di
magazzino sia così composta:
"PosMag_2":
[Cod.Capannone], [Cod.Area], [N°Corridoio], [N°Scaffale], [N°Ripiano],
[N°Cella], [Quantità max]
A questo punto, riportare in un'altra tabella tutti i codici che
identificano la singola cella, diviene sicuramente gravoso e per giunta
fonte di possibili errori durante la programmazione.
In questo caso diviene straconveniente creare un campo numerico progressivo
come chiave primaria ( [N°Posizione] ) e lasciare una chiave secondaria
univoca composta dai 6 campi che individuano la posizione della cella nella
ns. azienda. Con una chiave primaria così definita, per riportare in un
qualsiasi archivio la posizione di magazzino, basterà riportare solamente il
campo [N°Posizione].
Per il momento basta, ciao a tutti ed alla prossima puntata.

 Per il momento basta, ciao a tutti ed alla prossima puntata.
Ti ho scoperto!!!!!
Tu sei quello che inZegna nelle lezioni Nettuno alle 3 di mattina!!!!
Antonio

 ha scritto nel messaggio
news:pkTLa.132708$Ny5.3...@twister2.libero.it...

No, però sono in cerca di nuova occupazione, ed a RAI-SAT potrò citare nel
curriculum quest'opera accademica!!
Saluti

QUARTA PUNTATA
RELAZIONI
Posto che quelle più interessanti da studiare sono quelle tra persone di
sesso diverso, almeno per quanto mi riguarda (sui gusti altrui non
garantisco), in questa sede ci limiteremo ad occuparci delle relazioni che
dobbiamo intrattenere, pardon, creare tra tabelle.
Esaminiamo gli esempi finora presentati:
Per un automezzo, possono esistere più polizze;
Per una polizza possono esistere più scadenze;
In una posizione del magazzino possono essere messi più articoli;
In tutte queste situazioni si verifica che ad un record di una tabella,
possono venir riferiti + record in un'altra tabella. Siamo in presenza di
una relazione di tipo "uno a molti" (1-n (in Access la 'n' viene sostituita
col simbolo di infinito)). In questo caso, in maniera generica si parla di
"tabella lato uno" e "tabella lato molti".
C'è una distinzione fondamentale da compiere tra gli esempi portati, ed è
nel tipo di rapporto funzionale che si è creato tra le tabelle:
Le tabelle "Polizze" ed "Automezzi", rappresentano entità a se stanti del
mondo reale, infatti nulla vieta (per motivi ad onor del vero improbabili),
di memorizzare una polizza senza inserire la targa dell'automezzo cui essa è
riferita, comunque se ne potrebbero pagare le rate ed inserire le altre
informazioni.
Lo stesso si può dire della relazione che lega le tabelle "PosMag_2" ed
"Articoli", infatti anche in questo caso (per motivi più comprensibili),
possiamo inserire un articolo di magazzino e gestirlo in varie operazioni,
senza porne il riferimento alla posizione di magazzino in cui è riposto.
Ben diversa è la situazione che lega le scadenze alla loro polizza, infatti
una scadenza è parte integrante delle caratteristiche di una polizza e non
può aver luogo se la polizza stessa non esiste. Non è possibile inserire una
scadenza senza aver prima creato il relativo record della polizza.
Analoga relazione si ha più comunemente e chiaramente, tra il record di
testa di una fattura, e le relative righe di dettaglio, le seconde non
possono esistere senza la prima.
Come distinguere bene i due casi?
Quando un campo chiave (primaria o no, purchè si tratti di una chiave
univoca), da una tabella "lato uno" viene riportato in una tabella "lato
molti" per porle in relazione, se questo campo viene a far parte della
chiave primaria della tabella lato molti, ci si trova in presenza di una
stretta dipendenza funzionale, se invece il campo riportato rimane uno dei
tanti all'interno della seconda tabella, ci si trova in presenza di due
entità a se stanti.
Su, Su, fatevi coraggio che ancora ce n'è un pochino...
Mica son finiti qui i tipi di relazione che è possibile creare tra 2
tabelle.
Torniamo a trovare la ns. segretaria, che dopo qualche giorno di mare ha
preso un colorito davvero gradevole, con la minigonna poi...
Ora gli capita che il solito capo (ma tanto tra poco se ne va in pensione),
quando vuol mandare una circolare per la chiusura ferie, la vuol spedire
proprio a tutti: Clienti, fornitori e dipendenti, e vuole tutte le etichette
raggruppate per provincia/città/via.
Così la ns. tenace miss, decide di riunire l'archivio clienti, l'archivio
fornitori e l'archivio dipendenti in un'unico armadione, utilizzando per
tutti uno stesso modulo, con tutti i campi che servono a memorizzare le 3
entità diverse. Lascerà in bianco i campi che non avrà senso riempire.
Non è che la soluzione proprio non possa funzionare, tuttavia, si è accorta
che quando ha bisogno di compilare una statistica sui fornitori, tutte le
volte deve prima controllare bene quali sono le schede che la interessano,
quindi può fare la sua statistica, ma nel frattempo ha perso un sacco di
tempo.
Inoltre stà sprecando un mucchio di carta, in quanto gran parte del modulo
rimane in bianco.
Naturalmente è corsa subito al riparo, quindi ha preparato 4 moduli
(tabelle) da tenere in quattro classificatori separati:
"Anagrafica" per i dati in comune per tutte le anagrafiche:
[Cod.Anagrafica], [Indirizzo], [CAP], [Citta], [Prov], [Tipo]:C=Clienti;
F=Fornitori; D=Dipendenti
"Clienti" nel quale ha riportato il campo [Cod.Anagrafica] per legarlo al
primo modulo:
[Cod.Anagrafica], [Rag.Sociale], [Partita IVA], [Referente], [Perc.Sconto],
[Fido massimo]
"Fornitori" dove seguendo lo stesso principio:
[Cod.Anagrafica], [Rag.Sociale], [Partita IVA], [Referente], [N°Giorni
riordino]
"Dipendenti":
[Cod.Anagrafica], [Cognome], [Nome], [Data di nascita], [Data assunzione]
A questo punto diviene abbastanza evidente come, seppure ora non ci siano
più campi in cui durante gli inserimenti sia logicamente assurdo immettere
dati, se si avesse la necessità di avere un'elenco unico delle aziende,
clienti o fornitrici, con le quali si hanno rapporti, questo non sarebbe
possibile, se non attraverso un'operazione preliminare di "incastro" (merge)
in una tabella temporanea di appoggio (non parlerò delle query neanche sotto
tortura).
OK! Ci serve un'altra tabella "Aziende", nella quale portare fuori i campi
in comune tra clienti e fornitori: [Cod.Anagrafica], [Rag.Sociale], [Partita
IVA], [Referente].
A questo punto abbiamo creato una serie di tabelle tutte legate alla prima,
nelle quali per un codice presente nella tabella base (dove sono presenti
tutti i codici progressivi), o non è presente nessun record, o ce n'è al
massimo uno.
Abbiamo creato delle relazioni UNO ad UNO (1-1). In questo tipo di relazione
la chiave primaria viene riportata pari pari nella tabella collegata, senza
l'aggiunta di nessun'altro campo.
---------------------------
NOTA
Tanto per la cronaca, tutte queste operazioni che svolgiamo fin dalla prima
puntata, in cui si suddivide una tabella principale in più tabelle messe in
relazione tra loro, al fine di eliminare ridondanze, incongruenze, o spreco
di spazio, sono operazioni dette di "normalizzazione" del database. Sono
basate su principi matematici, rispondono a delle regole ben precise e sono
suddivise in livelli di normalizzazione. Non sempre sono obbligatorie e
spesso è il caso specifico a dettare la convenienza o meno di operare tali
separazioni. Se su di un motore di ricerca come ad esempio Google si cercano
le parole 'database' e 'normalizzazione', esce fuori una marea di roba cui
vi consiglio vivamente di dare almeno un'occhiata.
A tal proposito, di più... nin'zò.
---------------------------
Da notare che all'atto pratico, una struttura del tipo appena descritta,
necessita di particolari accorgimenti per evitare assolutamente che ad un
codice nella tabella "Anagrafica", ad esempio corrispondano sia un record
nella tabella "Clienti", sia uno in quella "Dipendenti", oppure che non ci
sia un record collegato in nessuna delle tabelle.
CREARE UNA RELAZIONE IN ACCESS
Finalmente è venuto il momento di spiegare come si possono creare queste
benedette relazioni in Access.
Dalla finestra principale dove compaiono gli oggetti del database,
selezionare 'Tabelle', quindi dal menu 'Strumenti' scegliere 'Relazioni...'.
Compare una finestra in cui, scegliendo dal menu 'Relazioni' la voce 'Mostra
tabella...', andremo a posizionare le immagini delle varie tabelle.
A questo punto selezionare dalla tabella che contiene la chiave univoca da
collegare (quasi sempre la primaria), la chiave stessa, per poi trascinarla
sul corrispondente campo riportato nella tabella da collegare.
A questo punto si apre una finestra in cui definire le proprietà della
relazione, compresa l'aggiunta degli altri campi in caso di chiavi a campi
multipli.
Per tutto ciò si rimanda alla guida in linea, o ad altre guide, a noi
interessa di dare un breve cenno su di una sola opzione:
"Applica integrità referenziale"
Nella prima puntata, avevamo accennato che Access è un RDBMS, ossia un
gestore di database relazionale. Ora ciò che distingue un database
"semplice" da uno turbo... ehm... "relazionale", è una serie di meccanismi
ferrei messi in atto dal motore del database, per controllare la congruenza
e la consistenza delle informazioni distribuite nelle varie tabelle.
...?!
Ma... che ha detto?
Insomma, se selezionate quella casella di spunta e quella successiva
"Aggiorna campi correlati a catena", Bill in persona vi garantisce che se
cambiate una chiave in una tabella, lo stesso valore ve lo ritrovate senza
fare niente in tutti i record collegati nella tabella collegata.
Se durante un'aggiornamento di tali valori sparisce la corrente (chissà poi
dove va nel frattempo), Access fa sì che sia come se l'aggiornamento non
fosse mai iniziato (voglio vedere se c'è un bel crash delle testine da fare
trucioli, ma tanto avevate le copie vero?).
Inoltre, se si seleziona anche l'ultima voce "Elimina record collegati a
catena", in caso di cancellazione del record nella tabella per così dire
base, vengono cancellati anche i record relativi nella tabella collegata. In
caso contrario, l'annullamento non viene consentito se ci sono record
collegati.
E che questo, almeno qui, vi basti!
Ma i tipi di relazione non sono terminati, ne esiste un'altro:
Relazione "molti a molti" (n-n)
nella quale, ad un record nella prima tabella, possono essere collegati
molti record nella seconda e contemporaneamente, ad un record nella seconda,
possono risultare collegati molti record nella prima.
Procediamo sempre con un esempio, se nel ns. database della gestione
automezzi, volessimo indicare per ogni veicolo quali sono gli autisti che
possono guidarlo e per ogni autista, quali sono i veicoli che egli può
guidare, di prim'acchitto si potrebbe pensare che basti aggiungere una
tabella "Autisti", così composta:
[Cod.Autista], [Nominativo], [Tipo Patente], [Targa]
e successivamente basti riportare il [Cod.Autista] nella tabella automezzi,
per poter effettuare tutti gli incroci necessari.
No, in questo modo potrei trovarmi in una situazione in cui nel record della
'Fiat UNO' si fa riferimento all'autista 'Rossi', mentre nel record
dell'autista 'Rossi' si fa riferimento al 'Furgone Ford', pergiunta non
posso creare un'altro record contenente sempre l'autista 'Rossi', nel quale
far riferimento anche al 'Furgone Mercedes'. Questa soluzione porta a delle
grosse incongruenze ed è sempre da scartare.
Una relazione di tipo n-n viene sempre risolta creando una terza tabella,
nel cui record figura esclusivamente la chiave primaria e che è composta
dalle chiavi primarie delle due tabelle originali:
Tabella "AutistiEVeicoli"
Chiave primaria = [Targa] & [Cod.Autista]
La nuova tabella sarà legata da una relazione 1-n con la tabella "Autisti" e
da un'altra relazione 1-n con la tabella "Automezzi". La creazione di
"AutistiEVeicoli" ci consentirà di effettuare tutti gli incroci di cui
abbiamo bisogno senza incongruenze, o ridondanze.
E' superfluo ricordare che nella tabella "Autisti" non comparirà più il
campo di collegamento [Targa], che è stato trasferito in "AutistiEVeicoli" e
nella tabella "Automezzi" non comparirà più il campo [Cod.Autista], per il
quale è stato fatto lo stesso trasferimento.
------------------------------------------------------
ALCUNE OSSERVAZIONI FINALI
Nella prima puntata, quando elencavamo i campi che avrebbero potuto comporre
la tabella automezzi, avevamo citato [Tipo Automezzo] e [Tipo Carburante].
In che modo possiamo creare il primo?
Se creiamo un campo di tipo testo, diciamo di 30 caratteri, avremo una
soluzione semplice e funzionale, per contro, ogni volta che inseriremo la
voce 'Autocaravan', potremmo sbagliare la digitazione di qualche carattere,
senza contare che se i record fossero molti, lo spazio impiegato sarebbe
notevole.
L'alternativa sarebbe quella di creare il campo come numerico (Tipo 'Byte'
potrebbe bastare) e portare la descrizione in una tabella separata
"TipiVeicolo" con i campi:
[Tipo Automezzo], [Descrizione Automezzo]. La decisione se sia opportuno o
meno compiere questa normalizzazione, rimane alla sensibiltà del
programmatore, che deve valutare i pro ed i contro di una simile decisione.
Supponiamo di aver optato per la separazione della descrizione in una
tabella separata, in questo caso l'utente finale potrebbe in qualsiasi
momento modificare la descrizione di un tipo di automezzo, per vedersela
modificata su tutti i veicoli in cui viene fatto riferimento a quel tipo.
Inoltre può in ogni momento decidere di inserire un nuovo tipo di veicolo.
Sulla scia di questa decisione, come tratteremo il campo [Tipo carburante]?
Cominciamo col creare un campo di tipo numerico byte (ricordo che occupa
appunto 1 byte ed accetta valori interi fino a 255), la domanda è, se con
questo campo valga la pena  di creare (e poi dover gestire) un'altra tabella
con le relative descrizioni. Secondo me, dal momento che non credo che nei
prossimi 5 anni inventino nuovi carburanti, sarebbe più opportuno crearsi
una funzione in Visual Basic, alla quale passare il [Tipo carburante] e che
ne restituisca la descrizione.
Ad esempio
Private Sub DescriCarburante(TipoCarb As Integer) As String
 Select Case TipoCarb
 Case 0
  DescriCarburante = "Nessuno"
 Case 1
  DescriCarburante = "Benzina"
 Case 2
  DescriCarburante = "Diesel"
 Case 3
  DescriCarburante = "GPL"
 Case 4
  DescriCarburante = "Metano"
 Case else
  DescriCarburante = "Non Previsto"
 End Select
End Sub
---------------------------------------------------------------
Bè... ora vi ho detto, pardon scritto tutto quello che sò sulla
progettazione di un database, non è molto, ma spero vi faccia venire la
voglia di leggere qualcosa di approfondito in merito.
Per quanto riguarda le tabelle relative alle manutenzioni compiute sugli
automezzi di cui avevamo accennato all'inizio, a questo punto... Insomma,
arrangiatevi!!!
----------------------------------------------------------------
A tutti coloro (due o tre) che saranno riusciti a leggere questa barba,
oltre alla + sincera ammirazione per la tenacia, rinnovo l'invito a
completare questo testo con argomenti un pò più succosetti dal punto di
vista tecnico, oppure semplicemente a segnalare lacune, sviste o
castronerie.
Ciao ciao, adesso vado a trovare la famosa segretaria.

 Ciao ciao, adesso vado a trovare la famosa segretaria.
L'ho usata un po' nella seconda e quarta puntata, spero che cio' non ti
adombri. Durante la terza sono stato impegnato nel cambio di targa.
;<)
--
a.cara
togli qualcosa dall'email

 QUARTA PUNTATA
[CUT]
Di la verità, il tutto lo hai scritto nella speranza di essere ingaggiato
dalla Walt Disney per scrivere il soggetto del cartoon "Pippo & Pluto alla
ricerca della relazione perduta". :-)
E per quante altre puntate pensi di "deliziarci" ancora?


 
ma dai Roberto, potrebbe sempre essere utile. Non e' che stia dicendo
"stupidaggini", io personalmente lo preferisco ai 30 post mensili sull'uso delle
caselle combinate



E' vero.
Ma sono convinto che chi ne avrebbe veramente bisogno, non lo leggerà per
niente!!!
Antonio

 niente!!!
Magari potrebbe essere aggiunto sul sito comune...
Antonio


No, no... ho finito, chiuso, stop, basta.
E' ora che torni a fare qualcosa di più produttivo nelle ore mattutine e
serali.
Ciao.

 ha scritto nel messaggio
news:3F02B0FA...@blunet.it...

Come tutti i messaggi del NG anche quelli di Francesco R. sono "volatili",
quindi possono essere risultati utili solo a qualche frequentatore del NG di
questi giorni; io gli avevo suggerito di inviarli al Sito Comune (sempre che
continui ad essere aggiornato).


 
e che da un po che mi sta frullando in testa di mettere su un ennesimo sito
access ("mio") in cui includere una serie di cose, anche prelevate da NG (previo
benestare dell'autore, [e non solo da questo NG]), ma solo cose che "IO" ritengo
interessanti e "quasi" esclusivamente "teoriche" e ovviamente non presenti sul
sito comune per le note regole dello stesso.


 Ciao.
Grazie in ogni caso della tua opera titanica.
MAssimiliano

 Su, Su, fatevi coraggio che ancora ce n'č un pochino...
cut...
Gesu!!
Sib

 >
 
Buongiorno.
Scusami se scrivo qui, volevo sapere se il programmino che ha Spedysoft è possibile averlo, perchè anche io sono in cerca di un programmino in Access con queste caratteristiche. Ho provato a farlo purtroppo le mie conoscenze di Access sono proprio zero.
Eventualmente il programma si può avere, mi spiegate come si fa.
Grazie anticipatamente, a Voi che sapete e che prodigate tanto di aiutare quelli come me che non sanno come fare.
Saluti