PROGETTAZIONE CONCETTUALE DI UN DATABASE
Supponiamo che un'impresa debba progettare un database per gestire i crediti che avanza dai suoi clienti e i pagamenti derivanti. Voi quale pensate sia la relazione giusta tra la tabella CREDITI e la tabella CLIENTI?
Risposte
Se CLIENTI contiene la lista dei clienti con PK ID_CLIENTE, e CREDITI contiene tutti i crediti effettuati ai clienti (ed eventualmente un cliente può avere più crediti ma non viceversa) con PK ID_CREDITO, direi che la relazione è CREDITI che ha ID_CLIENTE come FK su CLIENTI:
CLIENTI = (ID_CLIENTE (PK), ...)
CREDITI = (ID_CREDITO (PK), ID_CLIENTE (FK), ...)
CLIENTI = (ID_CLIENTE (PK), ...)
CREDITI = (ID_CREDITO (PK), ID_CLIENTE (FK), ...)
Anche io l'ho pensata come una relazione 1:N, ma il mio professore di Informatica ha valutato giusta quella N:N.
Da essa ha derivato una tabella di join PAGAMENTI. Io non sono d'accordo, anche perché così, come faccio a sapere quanto mi deve il singolo cliente? Conosco solo il pagamento parziale di un credito che io vanto nei confronti di N, tra cui lui. Che ne pensate voi?
Da essa ha derivato una tabella di join PAGAMENTI. Io non sono d'accordo, anche perché così, come faccio a sapere quanto mi deve il singolo cliente? Conosco solo il pagamento parziale di un credito che io vanto nei confronti di N, tra cui lui. Che ne pensate voi?
Diciamo che occorrerebbe sapere da un punto di vista funzionale come funziona l'impresa e chi può fare cosa. A occhio io vedo:
- un'anagrafica CLIENTI, che dovrebbe contenere la lista di clienti univoca. Ma cosa è un cliente? Una entità singola? Può esistere un gruppo di clienti che è un cliente (tipo "cointestazione")?
- un'anagrafica CREDITI, che dovrebbe contenere la lista di tutti i crediti aperti verso i clienti. Ma chi può aprire un credito? Un cliente può aprire più crediti? Un credito può essere aperto da più clienti?
- un flusso di PAGAMENTI, che dovrebbe contenere i vari pagamenti parziali dei clienti. Ma chi può pagare una rata? Per forza il cliente che ha aperto il credito? Oppure anche un cliente qualsiasi? Oppure se il credito è stato aperto da un gruppo (se fosse possibile) da un qualsiasi cliente del gruppo?
Senza queste precisazioni è difficile capire cosa ha in mente il prof. Comunque gestire PAGAMENTI è un problema successivo, prima capirei bene come si intende rappresentare CLIENTI/CREDITI.
A tal proposito, un'osservazione importante: se è vero che clienti/crediti è N:N questo è assai problematico per il db, perché si incorre in questioni tipiche della 3FN: mettiamo che Antonio e Francesco aprono entrambi due crediti da 100 e 200 euro. Abbiamo p.e.:
CLIENTI (ID_CLIENTE,NOME):
1;Antonio
2;Francesco
CREDITI (ID_CREDITO,ID_CLIENTE,AMMONTARE)
1;1;100
1;2;100
2;1;200
2;2;200
Quindi in CREDITI la PK diventa per forza (ID_CLIENTE, ID_CREDITO), e in più ho vari problemi, p.e.:
1) se devo andare ad aggiornare l'ammontare il credito con ID_CREDITO=1, devo aggiornare DUE righe e non una altrimenti mi diventa incosistente
2) se voglio sapere quanto credito ho erogato fin'ora in totale NON posso fare sum(AMMONTARE) perché mi uscirebbe 600 che è errato
Io proporrei queste due versioni:
A) non esistono gruppi di clienti che possono aprire un credito, quindi CLIENTI/CREDITI è 1:N come ho scritto sopra
B) volendo fare dei gruppi di clienti, creerei una entità intermedia GRUPPI in cui assegno una chiave univoca al gruppo di clienti che apre il credito, e poi faccio aprire il credito dall'id del gruppo e non da ogni singolo cliente.
- un'anagrafica CLIENTI, che dovrebbe contenere la lista di clienti univoca. Ma cosa è un cliente? Una entità singola? Può esistere un gruppo di clienti che è un cliente (tipo "cointestazione")?
- un'anagrafica CREDITI, che dovrebbe contenere la lista di tutti i crediti aperti verso i clienti. Ma chi può aprire un credito? Un cliente può aprire più crediti? Un credito può essere aperto da più clienti?
- un flusso di PAGAMENTI, che dovrebbe contenere i vari pagamenti parziali dei clienti. Ma chi può pagare una rata? Per forza il cliente che ha aperto il credito? Oppure anche un cliente qualsiasi? Oppure se il credito è stato aperto da un gruppo (se fosse possibile) da un qualsiasi cliente del gruppo?
Senza queste precisazioni è difficile capire cosa ha in mente il prof. Comunque gestire PAGAMENTI è un problema successivo, prima capirei bene come si intende rappresentare CLIENTI/CREDITI.
A tal proposito, un'osservazione importante: se è vero che clienti/crediti è N:N questo è assai problematico per il db, perché si incorre in questioni tipiche della 3FN: mettiamo che Antonio e Francesco aprono entrambi due crediti da 100 e 200 euro. Abbiamo p.e.:
CLIENTI (ID_CLIENTE,NOME):
1;Antonio
2;Francesco
CREDITI (ID_CREDITO,ID_CLIENTE,AMMONTARE)
1;1;100
1;2;100
2;1;200
2;2;200
Quindi in CREDITI la PK diventa per forza (ID_CLIENTE, ID_CREDITO), e in più ho vari problemi, p.e.:
1) se devo andare ad aggiornare l'ammontare il credito con ID_CREDITO=1, devo aggiornare DUE righe e non una altrimenti mi diventa incosistente
2) se voglio sapere quanto credito ho erogato fin'ora in totale NON posso fare sum(AMMONTARE) perché mi uscirebbe 600 che è errato
Io proporrei queste due versioni:
A) non esistono gruppi di clienti che possono aprire un credito, quindi CLIENTI/CREDITI è 1:N come ho scritto sopra
B) volendo fare dei gruppi di clienti, creerei una entità intermedia GRUPPI in cui assegno una chiave univoca al gruppo di clienti che apre il credito, e poi faccio aprire il credito dall'id del gruppo e non da ogni singolo cliente.
Ti spiego come l'ho vista io.
Per me l'ipotesi più plausibile è di una relazione 1 a N. Ad un cliente possono corrispondere N crediti, ma in genere un credito fa riferimento ad un solo cliente. Una tabella di join tra CLIENTI e CREDITI mi sembra forzata.
Che significherebbe, infatti, che per un credito ho N clienti? Se io l'andassi a creare, avrei oltre all’ID Cliente_Credito, le 2 chiavi esterne FK_Cliente ed FK_Credito, cioè dal lato utente saprei che come impresa ho riscosso , per esempio, dal “cliente X”, mettiamo 150 euro di un credito complessivo di 500 euro. Ma un database così che utilità può avere per un’impresa?
Se io fossi titolare di un'impresa, avrei necessità di sapere quanto avanzo da ogni singolo cliente e non da un gruppo di clienti. Se un cliente mi paga a 90 giorni, e ho un credito commerciale nei suoi confronti, ho bisogno di sapere quanto mi deve lui singolarmente. Questa informazione non potrei averla creando una tabella di join tra Clienti e Crediti. Tra l’altro, nella tabella di join nell'ipotetico campo “Importo Versamento” mi potrebbe apparire solo una parte del pagamento, cioè non è detto che il cliente, uno solo, mi paghi tutto quello che mi deve in un’unica soluzione. A che mi servirebbe poi mettere un campo dal nome “Importo dovuto” nella tabella Clienti? L’importo dovuto è il credito.
Al di là di ciò, sulla base di quale logica le imprese andrebbero raggruppate per credito? Sulla base della tipologia, di un tipo di lavoro svolto, ecc.? Si potrebbe creare una tabella TIPOLOGIE, TIPO DI LAVORO, ecc e poi magari tra CLIENTI e TIPOLOGIE si potrebbe mettere una chiave esterna nella tabella Clienti. Anche così una tabella di join tra Clienti e Crediti sarebbe, però, da evitare, questo perché facendo una query saprei quanto mi spetta di credito dai clienti appartenenti tutti ad una stessa tipologia e potrei raggruppare i clienti e sapere quanto mi devono complessivamente, evitando ridondanza.
DOVE SBAGLIO nel mio modo di ragionare?
Per me l'ipotesi più plausibile è di una relazione 1 a N. Ad un cliente possono corrispondere N crediti, ma in genere un credito fa riferimento ad un solo cliente. Una tabella di join tra CLIENTI e CREDITI mi sembra forzata.
Che significherebbe, infatti, che per un credito ho N clienti? Se io l'andassi a creare, avrei oltre all’ID Cliente_Credito, le 2 chiavi esterne FK_Cliente ed FK_Credito, cioè dal lato utente saprei che come impresa ho riscosso , per esempio, dal “cliente X”, mettiamo 150 euro di un credito complessivo di 500 euro. Ma un database così che utilità può avere per un’impresa?
Se io fossi titolare di un'impresa, avrei necessità di sapere quanto avanzo da ogni singolo cliente e non da un gruppo di clienti. Se un cliente mi paga a 90 giorni, e ho un credito commerciale nei suoi confronti, ho bisogno di sapere quanto mi deve lui singolarmente. Questa informazione non potrei averla creando una tabella di join tra Clienti e Crediti. Tra l’altro, nella tabella di join nell'ipotetico campo “Importo Versamento” mi potrebbe apparire solo una parte del pagamento, cioè non è detto che il cliente, uno solo, mi paghi tutto quello che mi deve in un’unica soluzione. A che mi servirebbe poi mettere un campo dal nome “Importo dovuto” nella tabella Clienti? L’importo dovuto è il credito.
Al di là di ciò, sulla base di quale logica le imprese andrebbero raggruppate per credito? Sulla base della tipologia, di un tipo di lavoro svolto, ecc.? Si potrebbe creare una tabella TIPOLOGIE, TIPO DI LAVORO, ecc e poi magari tra CLIENTI e TIPOLOGIE si potrebbe mettere una chiave esterna nella tabella Clienti. Anche così una tabella di join tra Clienti e Crediti sarebbe, però, da evitare, questo perché facendo una query saprei quanto mi spetta di credito dai clienti appartenenti tutti ad una stessa tipologia e potrei raggruppare i clienti e sapere quanto mi devono complessivamente, evitando ridondanza.
DOVE SBAGLIO nel mio modo di ragionare?
Non ho ben capito una cosa.
In che senso "2) se voglio sapere quanto credito ho erogato fin'ora in totale NON posso fare sum(AMMONTARE) perché mi uscirebbe 600 che è errato"?
Al cliente Antonio sono stati concessi due crediti uno di 100 euro e l'altro 200 (totale 300) e al cliente Francesco idem (totale 300), quindi complessivamente 600.
Intendi che se facessi un totale dell'ammontare dei pagamenti, tale somma non mi restituirebbe realmente quanto credito ho erogato, perché magari altri clienti non mi hanno pagato?
In che senso "2) se voglio sapere quanto credito ho erogato fin'ora in totale NON posso fare sum(AMMONTARE) perché mi uscirebbe 600 che è errato"?
Al cliente Antonio sono stati concessi due crediti uno di 100 euro e l'altro 200 (totale 300) e al cliente Francesco idem (totale 300), quindi complessivamente 600.
Intendi che se facessi un totale dell'ammontare dei pagamenti, tale somma non mi restituirebbe realmente quanto credito ho erogato, perché magari altri clienti non mi hanno pagato?
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo