Newsgroup: it.comp.appl.access
Titolo: Normalizzazione DB .. mi date un consiglio ? Grazie !

Devo realizzare un applicativo per un mio amico che ha un centro assistenza
tecnica caldaie a gas.
Visto che sono un po' newbie, volevo chiedervi se potevate consigliarmi su
come organizzare le tabelle.
A parte le solite cose (nome, cognome , etc.) mi trovo in una situazione un
po' offuscata (almeno per me).
Devo fare in modo che il db gestisca diverse tipologie di clienti e, a
seconda del tipo di cliente, siano relazionati altri clienti.
Mi spiego con un esempio :
Tipo cliente 1 = Amministratore
Tipo cliente 2 = Inquilino
L'amministratore del condominio "Rosa" (cliente anche lui) e' il
responsabile di tutti gli inquilini (clienti) del condominio stesso.
Si crea la necessita', quindi, di "legare" (passatemi il termine) tutti gli
inquilini del condominio all'amministratore.
In altre parole, aprendo la scheda dell'amministratore , vorrei creare una
griglia con il riepilogo dei nominativi amministrati. Fermo restando che per
ognuno di essi (amministratore e inquilini) i campi utilizzati sono
identici.
Quante tabelle fareste voi e con che tipo di relazioni  ?
Grazie
Aldo

 wrote in message
ESFK6.893$RX4.1...@news.infostrada.it...


 applicazioni access
Per prima cosa dovresti scrivere DOPO il quoting
Antonio

 ha scritto nel messaggio
news:ESFK6.893$RX4.1...@news.infostrada.it...

CUT
Premetto che non sono quell'espertone come altri nel NG ma cosě di primo
impatto direi che puoi fare una sola tabella, aggiungere un campo
Amministratore ed uno CodiceAmministratoreCollegato, gestendo poi i dati
con un codice tipo questo:
.
Test su CodiceAmministratoreCollegato
    se non č vuoto allora
        se Amministratore = CodiceAmministratoreCollegato
            Inquilino E Amministratore
        altrimenti
            Inquilino Con Amministratore
        FineTest
    altrimenti
        Amministratore
FineTest
Poi con una query
select * from TuaTabella where CodiceAmministratoreCollegato =
Amministratore che vuoi vedere
Ovviamente lascio a chi č piů esperto di me il compito di darti soluzioni
migliori,
visto che con questo sistema un inquilino puň avere un solo amministratore
a meno di non inserire 2 volte l'anagrafica con codici differenti.
La mia č solo un'ideuzza. ;-)
Saluti
--
Claudio Tregambe

 ha scritto nel messaggio
news:3GKK6.1179$RX4.1...@news.infostrada.it...


 ha scritto nel messaggio
news:ESFK6.893$RX4.1...@news.infostrada.it...

Innanzitutto mi creerei una tabella Clienti che deve contenere i dati di
tutte le persone fisiche o giuridiche cui è possibile intestare una fattura.
Mi creerei poi una tabella Amministratori che conterrà i dati di tutti gli
amministratori con i quali posso avere rapporti di lavoro a prescindere
dalla fatturazione; se un tizio è sia amministratore di un condominio che
cliente, lo piazzerei su ambedue le tabelle.
Mi creerei anche una tabella Condominii che conterrà i dati anagrafici dei
vari condominii nei quali ho rapporti operativi.
Mi creerei infine una tabella Appartamenti.
Poichè un condominio può avere un solo amministratore ma un amministratore
può gestire più condominii, mi creerei tra la tabella Amministratori e la
tabella Condominii una relazione uno-a-molti in base al campo
IDAmministratore che sarà chiave primaria della tabella Amministratori e
chiave esterna della tabella Condominii.
Poiché un appartamento può far parte di un solo condominio ma un condominio
contiene più appartamenti, mi creerei tra la tabella Condominii e la tabella
Appartamenti una relazione uno-a-molti in base al campo IDCondominio che
sarà chiave primaria della tabella Condominii e chiave esterna della tabella
Appartamenti.
Poiché un appartamento può appartenere a un solo cliente ma un cliente può
possedere più appartamenti, mi creerei una relazione uno-a-molti tra la
tabella Clienti e la tabella Appartamenti in base al campo IDCliente che
sarà chiave primaria della tabella Clienti e chiave esterna della tabella
Appartamenti.
Così facendo ti sarai creato, senza accorgertene, una relazione
molti-a-molti tra la tabella Clienti e la tabella Condominii tramite la
tabella Appartamenti (un condominio ha più clienti e un cliente può essere
in più condominii).
A mio avviso questa è l'architettura di tabelle più completa e flessibile
che ti permetterà sia la gestione della fatturazione/contabilità clienti che
la gestine operativa delle manutenzioni e dei contratti di manutenzione (che
secondo me vanno imputati al livello appartamento).
Sarebbe poi forse opportuno crearsi una tabella Interventi da mettere in
relazione uno-a-molti con la tabella Appartamenti in base al campo
IDAppartamento che sarà chiave primaria della tabella Appartamenti e chiave
esterna della tabella Interventi che avrà invece come chiave primaria
IDIntervento. In questa tabella registrerai, uno per uno, tutti gli
interventi dei lavori che l'azienda fa.
Con l'uso delle query, della tecnica
maschere/sottomaschere/sottosottomaschere e della tecnica delle maschere
sincronizzate e/o filtrate, otterrai tutte le visualizzazioni dei dati che
ti servono.
--
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------
--
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------

 Mi creerei poi una tabella Amministratori che conterrà i dati di tutti gli
---cut---

 "metabolizzare" i tuoi consigli.
Potresti prenderti qualche giorno per metabolizzare anche il fatto che si
scrive DOPO il quoting?
Antonio

 ha scritto nel messaggio
news:Ms6L6.8049$RX4.5...@news.infostrada.it...

A parte parlare di quoting, sai fare altro ?
:-)
Va bene cosi' ???
Ciao
Aldo

 :-)
Masssiiiiìììì... è così bravo che cià pure il clone.... ;-)
--
Silvio
il sito comune di it.comp.appl.access:
http://www.sitocomune.com

 Va bene cosi' ???
Lo vedi che lo sai fa?
Antonio

 Lo vedi che lo sai fa?
Anvedi che ce so riuscito.... !!!!
:-)
Ciao
Aldo

 :-))))
Dai, tutto ok
Antonio