Newsgroup: it.comp.software.database
Titolo: Consiglio struttura DB

Ariciao a tutti.
Mi sembra doveroso innanzi tutto ringraziare coloro che mi hanno aiutato
(e molto!) nei miei post precedenti... :D
Adesso, ecco la nuova domanda (scusate se è banale rispetto ad altre
postate qui...)
Vi spiego il problema. Devo creare un Db per la gestione di tessere per
personale. Ci sono diversi tipi di personale: dipendenti, fornitori,
visitatori. Ognuno di essi ha delle proprie caratteristiche: ad es. i
dipendenti hanno la matricola e i visitatori no; i fornitori hanno un
costo e gli altri no, ecc. ecc. ecc....
Allora: come faccio per gestire la relazione tra la tabella "tessere" e
le tabelle "personale" (che a questo punto saranno diverse)? Mi spiego
meglio: io pensavo di fare
Tessere ---- Rel_Tessere_Dipendenti ---- Dipendenti
        +--- Rel_Tessere_Visitatori ---- Visitatori
             ecc.
 
ovvero relazioni diverse per tabelle diverse
Però in questo modo ho poi il problema nel codice (VB): ad esempio: come
faccio per sapere a chi è assegnata una tessera (dato che ho più di una
tabella di relazione)? Esiste forse qualche query SQL furba che io non
conosco (mooolto probabile!) per farlo?
Oppure esiste un altro modo (più furbo del mio) per strutturare il DB? 
Ciao e grazie a tutti, di nuovo
Marco.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ovvero relazioni diverse per tabelle diverse
   Senza impazzire troppo, assegni alla relazione "Tessere" un attributo 
che specifichi il tipo di persona a cui sia stata assegnata la tessera 
stessa. Altrimenti, crei una relazione "Persone" data dall'intersezione 
degli insiemi degli attributi delle relazioni "Dipendenti", 
"Visitatori", ecc., deleghi a questa il compito di specificare dove 
andare a trovare i dati eterogenei e la leghi alla relazione "Tessere".
-- 
Alla prossima,
Marco

 le tabelle "personale" (che a questo punto saranno diverse)?
Forse esiste un'entità intermedia, chessò, persona. Che poi si specializza
in fornitore, ecc...
Ciao.
--------------------------------
Inviato via 
http://usenet.libero.it

 in fornitore, ecc...
Si, in effetti dopo aver postato la cosa ci avevo pensato. Sarebbe
comodo farlo in C++, ma io lavoro in VB. Però, anche qui si riesce a
fare qualcosa del genere con Implements... devo verificare per bene.
Ah, a proposito: grazie della risposta! :)


 andare a trovare i dati eterogenei e la leghi alla relazione "Tessere".
Ah, questo mi piace di piů (anche se costa una tabella in piů). Se ho
capito, tu dici di fare una tabella del tipo:
Personale ---- Persone --- Rel_Persone_Tessere --- Tessere
Visitatori --+
Fornitori  --+
ecc.
In questo modo, posso fare anche query tra le tabelle, giusto? 
Grazie!! :)
M.


 In questo modo, posso fare anche query tra le tabelle, giusto? 
   Di solito, le interrogazioni si fanno sulle tabelle... Ovviamente, 
per i casi nei quali risultino interessanti gli attributi non comuni a 
tutte le entita` "persona" dovrai aggiungere un join: non penso sia 
cosi` difficile.
-- 
Alla prossima,
Marco

 ha scritto nel messaggio
news:bfce373ba0241bdbb3f...@mygate.mailgate.org...

Secondo me intendeva dire che la generalizzazione è da applicare nella
logica dei dati. Spiego meglio:
anziché avere più tabelle che più o meno hanno gli stessi dati ma
organizzati in modo differente, puoi procedere ad una normalizzazione in
questo senso:
TB_ANAGRAFICA: Dati anagrafici di tutti (clienti; fornitori; operatori) e
qualifichi il suo comportamento con un campo in questa tabella, che so
N_TIPO_ANAGRAFICA (0=Cliente, 1=Fornitore; etc);
TB_TESSERE: i dati delle tessere che sono messe in join sulla tabella di
anagrafica tramite la PK della TB_ANAGRAFICA;
La specializzazione la puoi fare già nella tabella anagrafica valorizzando i
campi a seconda del tipo; o meglio ancora normalizzando maggiormente la
tabella delle anagrafica mettendo in tabelle specifiche i dati aventi
oggetto specifico, ad esempio:
TB_FORNITORI: ci metti i dati che non ha senso mettere nell'anagrafica,
perché specifici della categoria FORNITORE: la banca di appoggio, etc;
TB_PERSONALE: ci metti i dati che non ha senso mettere nell'anagrafica,
perché specifici della categoria PERSONALE: la userid di rete; ferie godute,
data di assunzione, etc;
e così via... ovviamente legate tutte in join sulla PK della TB_ANAGRAFICA.
A questo punto a partire dalla tessera riesci, a cascata, ad avere tutti i
dati.
Spero di essere stato chiaro.
Martino.

 Spero di essere stato chiaro.
Ciao,
si, sei stato chiarissimo!
Questa soluzione è più o meno la stessa che ha proposto Marco N. in un
paio di post sopra. Però, a differenza di quella, mi piace l'idea di
mettere nella tabella Anagrafica le "parti comuni" a tutti (tipo Nome e
Cognome, che avranno tutti...), per poi specializzare la cosa con
tabelle apposite.
Grazie tante !!
