Newsgroup: it.comp.appl.access
Titolo: Suddivisione "tabellona" in tabelline e info su creazione ID.

Ciao, brevemente:
E' una tabella con l'anagrafica del personale ed altri elementi come
centro di costo del singolo dipendente ecc.
1. ho una tabella piena di roba e potrei come consigliato
dall'analizzatore suddividere questa in tabelle più piccole, ma ne
vale la pena? non sono un "Guru" ma credo di si.
Se ad esempio nel tempo un dipendente va da un centro di costo ad un
altro è + comodo aggiornare una piccola tabella con
| dipendente | centro di costo | almeno credo.
2. Se ho già una tabella con | cognome | nome | centro di costo |
come posso inserire un ID nella prima colonna univoco (le righe sono
un centinaio) ? (i cognomi/nomi potrebbero ripetersi).
Grazie.

 centinaio) ? (i cognomi/nomi potrebbero ripetersi).
Il problema è mal posto, nel senso che prima bisognerebbe risolvere il problema 
dei duplicati (leggi: attuare la normalizzazione).
In ogni caso, come regola generica, è sempre possibile aggiungere un campo 
di tipo contatore, utilizzato come chiave primaria, ad una tabella che già 
non ne abbia uno con la stessa funzione.
I valori vengono poi attribuiti automaticamente da Jet.
--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype:pbsoftsolution

 skype:pbsoftsolution
Chiarissimo, grazie Gabriele

 migliorato la struttura del tuo database.
Non ho capito questo "una terza tabella relazionata con entrambe
che realizza lo storico dei centri di costo per ogni dipendente"
Come posso realizzarla?

 posso realizzarla?
La tabella intermedia realizza quella che si chiama una relazione "molti 
a molti".
Se il problema è creare la tabella, non vedo dove stia la difficoltà, visto 
che si tratta di una tabella come tutte le altre.
Se il problema è realizzare impostare le giuste relazioni, quello che devi 
fare è inserire in questa tabella intermedia due campi che serviranno da 
chiave esterna: uno serve per la relazione lato "molti" con una tabella, 
l'altro per la stessa funzione ma con una tabella diversa.
Nel tuo caso, avrai le seguenti tabelle:
- dipendenti (contenente ad esempio un campo chiave IDDipendente intero lungo) 
(la chiameremo A)
- centri_di_costo (contenente ad esempio un campo chiave IDCentroDiCosto 
intero lungo) (la chiameremo B)
Tu hai detto che un dipendente può passara da un centro di costo ad un altro 
più volte.
Se non devi rispondere alla domanda "ad una certa data il tal dipendente 
a quale centro di costo apparteneva?", allora non ha bisogno di uno storico, 
quindi non hai bisogno della tabella intermedia.
Se, invece, devi mantenere questa informazione, allora devi crearti una terza 
tabella, chiamata ad esempio centri_di_costo_dipendenti (la chiameremo C), 
che conterrà almeno i seguenti campi:
- IDRelazione (intero lungo, chiave primaria)
- IDDipendente (intero lungo)
- IDCentroDiCosto (intero lungo)
- DataInizioAppartenenza (data/ora)
A questo punto non ti resta che impostare correttamente le relazioni seguenti:
- A.IDDipendente (1) ---- (M) C.IDDipendente
- B.IDCentroDiCosto (1) --- (M) C.CentroDiCosto
E' ovvio che, a questo punto, devi gestire lo storico anche nell'interfaccia 
utente, ma questa è tutta un'altra problematica.



che casino! (per me)
oggi sono a casa, lunedi mattina riprendo il tuo post e ci studio
sopra.
Grazie

 sopra.
Già che sei a casa, rifletti anche sul quoting esagerato del tuo ultimo post.


> ?
Lasciamo perdere.
