Newsgroup: it.comp.software.database
Titolo: Chiavi primarie e gestione dei clienti

Visto che in questi giorni parliamo di pk, vi sottopongo un problema che
mi trovo ad affrontare... se avete voglia di darmi un parere, ve ne sono
grato.
Ho la mia bella tabella dei clienti, e tutta una serie di tabelle ad
essa collegate (tanto per citarne una, la tabella in cui è calcolato il
fatturato mensile). Tra le tabelle collegate c'è poi quella che descrive
le varie destinazioni del cliente (e il tipo di destinazione, es. sede
legale, sede amministrativa, magazzino, deposito, negozio, ecc.).
I clienti, nel corso del tempo, possono cambiare una parte dei dati
(ragione sociale, partita iva, ecc.) ma sostanzialmente il soggetto
resta sempre lo stesso e la pk che lo identifica è sempre la stessa.
Succede che un cliente "smette di esistere come cliente" e diventa parte
di un gruppo di acquisto, il che significa che diventa una
"destinazione" di un altro cliente (nuovo oppure già esistente).
Esempio: il cliente con codice "C001" diventa la destinazione "D001" del
cliente "C002".
Il cliente "C001" continua ad esistere nella tabella dei clienti.
Il problema è che la direzione vuole che una parte (non tutti) dei dati
riferiti al cliente "C001" siano spostati al cliente "C002" destinazione
"D001".
Quello che mi chiedo è: a livello concettuale, come gestireste il tutto?
Va bene creare delle procedure che cambiano la pk nelle tabelle
referenziate dalla tabella clienti?
-- 
David Martin

 Quello che mi chiedo è: a livello concettuale, come gestireste il tutto?
Non spostare dati. Usa una view.
Bye :-)
-- 
Rudy
blog: 
http://rdbland.blogspot.com/
e-mail a 
email.it

 "D001".
Né copie né spostamenti: "Informi" il db che
1) il cliente c001 non esiste (più)
2) il cliente c002 ha una (nuova) destinazione d001 che è la ditta xyz
Il data modeler non pensa in termini procedurali; egli innanzitutto
"fotografa" la realtà.

 "fotografa" la realtà.
Ok, ma questo in cosa si traduce, nella realtà?
-- 
David Martin

 Ok, ma questo in cosa si traduce, nella realtà?
Il primo passo per chi viene dalla programmazione è quello di
DISimparare: le pk non sono puntatori, le righe non sono record,
le tabelle non sono files, le relazioni non sono link etc...
Probabilmente non hai ancora avuto il tuo Satori.



... grande... veramente illuminante scambiare opinioni con te!
-- 
David Martin

 
Sorry, io vengo dalla programmazione ma la tua affermazione non l'ho capita.
Potresti spiegermela passo-passo.
Grazie.
	MAX

"massimo61":

In programmazione abbiamo che un oggetto può contenere un puntatore
ad un altro. A seconda di quale oggetto punta, faccio significare
che O1 è "collegato a" O2. Il programmatore può variare l'oggetto
puntato con una semplice sovrascrittura; il resto dell'oggetto resta
inalterato.
Questo modo di pensare (normale nella programmazione), porta a pensare
di adottare lo stesso concetto con le righe di una tabella;
nell'esempio originario, il programmatore è intrappolato nel suo
modo di pensare di "far puntare" la riga di un cliente ad un altro
"oggetto"; questo modo di pensare lo inganna perché non gli permette
di vedere il fatto che STA CERCANDO DI VARIARNE IL SIGNIFICATO!
Legittimo in programmazione, deleterio in un database.
Il modello relazionale fin dall'inizio ha vietato i puntatori, ed
usa solo VALORI dello schema concettuale; esso è intrinsecamente
_descrittivo_ nel suo modo di essere.
I termini puntatore, record, file, link, similmente contengono
indesiderati concetti fisici legati all'hardware, ed il punto
maggiormente negativo è che CONDIZIONANO IL MODO DI PENSARE.

 
Messa giu' cosi', la condivido pienamente.
E' come l'avevi scritta che mi aveva lasciato perplesso.
L'errore e' stato non prevedere una tabella gruppi_acquisto quando c'e' 
stata l'analisi del problema.
Spero per lui che possa rimediare adesso.
Alla prossima.
	MAX

 Spero per lui che possa rimediare adesso.
Tanto per chiarezza, vi illustro la mia posizione:
- ho un gestionale che non gestisco e non ho creato, il cui database è
una vera ciofeca (non ha pk e fk, i campi contengono attributi multipli,
le date sono gestite a volte come testo e a volte come numeri, i numeri
interi sono sempre gestiti come decimal a scala 0, ecc.);
- sempre più spesso devo esportare i dati presenti nel gestionale su un
db esterno, nel quale poi estrarre i dati per stampe ed aggiunta di
varie gestioni.
E' chiaro che ho un margine di manovra piuttosto limitato e volevo un
consiglio a livello concettuale...
-- 
David Martin


Ma chi ha parlato di puntatori & co.? Tanto più che io non vengo dal
mondo della programmazione, per cui non ne sono assolutamente influenzato.
Che nell'esempio che ho postato ci sia un problema concettuale è palese
e nessuno ne discute. Proprio per questo ho chiesto un vostro parere,
per capire come poter bypassare il problema.
Mi aspettavo un consiglio e magari un breve esempio, ovvero "cosa fare",
anziché delle poesie e delle lunghe liste di "cosa non fare".
-- 
David Martin

 Quello che mi chiedo è: a livello concettuale, come gestireste il tutto?
A mio parere, una cosa fondamentale è dare i nomi giusti alle cose. Mi spiego:
quello che chiami "cliente" dici che può essere la "destinazione" di un altro "cliente", all'inizio della tua
spiegazione però sembrerebbe che una  "destinazione" sia un particolare indirizzo di un cliente. Ho l'impressione che
usi il predicato "essere destinazione di" per indicare due fatti differenti, cioè: "essere una sede del cliente" o
"essere un componente di un gruppo di acquisto".
Inoltre registri il fatto che un "cliente X appartiene al gruppo di acquisto Y" affermando che esso diventa la
"destinazione" di un altro "cliente": quindi un "gruppo di acquisto" è un "cliente" a tutti gli effetti? Se sono la
stessa cosa perché chiamarli in due modi diversi? Io ho l'impressione che "essere cliente" ed "essere gruppo di
acquisto" siano due fatti differenti.
Da quello che ho capito, gestirei la situazione concettualmente così:
Ho un cliente che identifico con il codice <cod_cliente>, che ha ragione sociale <ragione_sociale> e partita iva
<partita_iva>...
cliente {cod_cliente, ragione_sociale, partita_iva, ...}
Ho una destinazione che identifico con il codice <cod_destinazione> e si trova all'indirizzo <indirizzo>...
destinazione {cod_destinazione, indirizzo...}
Il cliente identificato dal codice <cod_cliente> ha una destinazione di tipo <tipo_destinazione> che è identificata dal
codice <cod_destinazione>
destinazione_cliente {cod_cliente, cod_destinazione, tipo_destinazione}
Il cliente identificato da <cod_cliente> è un cliente effettivo (cioè può acquistare direttamente)
cliente_effettivo {cod_cliente}
Ho un gruppo di acquisto identificato da <cod_gruppo>
gruppo_di_acquisto {cod_gruppo}
Il cliente identificato da <cod_cliente> appartiene al gruppo identificato da <cod_gruppo>
cliente_gruppo {cod_cliente, cod_gruppo}
È solo un'idea di massima (mancano ad esempio tutti i vincoli di integrità) ma spero si capisca...
Se un cliente non è più un cliente effettivo ma diventa parte di un gruppo è sufficiente registrare il fatto in
cliente_gruppo e cliente_effettivo cancellando e inserendo i record corrispondenti.
Ciao
Zac
P.S. Notare che tutto il discorso non prende in considerazione l'utilizzo di chiavi "sensate" di cui si è discusso nei
giorni scorsi e che porterebbe sicuramente vantaggi.

 MAX

 David Martin

 record corrispondenti.
Un grande Zac che sta rapidamente guadagnando punti...

 fare", anziché delle poesie e delle lunghe liste di "cosa non fare".
Se ad un uomo dai un pesce, egli si sfamerà un giorno.
Se gli insegni a pescare, si sfamerà tutta la vita.



Sono d'accordo con te, e infatti ringrazio moltissimo Zac.
-- 
David Martin

 "essere un componente di un gruppo di acquisto".
Grande Zac. :) :)
Spiegata per filo e per segno la normalizzazione dei dati.
Alla prossima.
	MAX

> Un grande Zac che sta rapidamente guadagnando punti...
Si vince qualche cosa? :)

 "essere un componente di un gruppo di acquisto".
Allora, ci sono tre entità:
- Clienti: soggetti della fatturazione;
- Destinazioni: le varie sedi di un cliente (legale, amministrativa,
deposito, magazzino, showroom, ecc.);
- Gruppi di acquisto: raggruppamento di più Clienti.
Clienti e Gruppi di acquisto sono entità diverse. Li ha nominati come
clienti perché ho esposto la non-logica con la quale sono gestiti oggi:
Clienti e Gruppi di acquisto sono nella stessa tabella!
A questo punto è doveroso dire che il mio post nasceva dall'esigenza di
estrarre i dati attualmente presenti nel gestionale, con la speranza di
trovare una struttura sensata che mi permettesse di gestirli senza
ribaltarli completamente. Ma, come ha scritto Gufo Rosso, a questo punto
sto meno a riscrivere il software!
E se avrò la possibilità di farlo, sicuramente mi sarà di aiuto la tua
proposta di gestione...
Grazie ancora per la pazienza!
-- 
David Martin

 Si vince qualche cosa? :)
no, si lavora per la gloria :)
Alla prossima.
	MAX
p.s.: tra l'altro non la molla facilmente :) :)

 p.s.: tra l'altro non la molla facilmente :) :)
Però la si promette a tutti... :-)