Struttura database: dubbio su relazioni

[_Mara_]

Buongiorno a tutti,
ho 2 tabelle: 'Manager' e 'Agenti' (ciascuno di questi fa riferimento a un determinato manager) legate nel modo seguente:
SELECT * FROM Agenti INNER JOIN Manager ON Agenti.fk_manager = Manager.pk_manager
Struttura
[Manager]
id_manager
(...)

[Agenti]
id_agente
fk_manager
(...)

Ora devo tenere conto anche delle vendite di ciascuno di loro quindi pensavo 2 possibili strade:
Aggiungo nelle rispettive tabelle un campo 'numero_vendite' (datatype: int)
oppure
creo tabella 'Vendite' dove inserirò campo numerico e un generico campo persona dove inserisco id_manager o fk_agente?

Ultimo dubbio: nel primo caso se mi chiedesseo uno storico degli aggiornamenti del numero vendite come potrei fare?

Grazie
Mara

[-MiStO-]

ho qualche dubbio: le vendite le fanno solo gli agenti o anche i manager?
perchè vedo che vorresti inserire nell ipotetica tabella vendite o l'id dell'agente o quello del manager...

num. vendite concettualmente non è un attributo di agente quindi per me è sbagliato modellarlo all interno della tabella agente

in ogni caso, a mio modo di vedere la soluzione piu pulita è fare una tabella vendite separata, contenente tutti i dati relativi alla singola vendita, tra cui suppongo importo e data (fondamentale per poter pensare ad uno storico) e con chiave esterna l'id dell'agente che l'ha effettuata.

lo storico in questo modo ti viene "gratis": query su vendite per data e via felice

sul tuo dubbio: devi per forza avere una data a cui fare riferimento per avere uno storico, quindi agente dovrebbe avere due nuovi campi ad esempio "num vendite" e "anno vendite"(o mese/anno a seconda del dettaglio che ti serve), ma francamente lo trovo brutto perchè duplicheresti gli agenti per ogni nuova entry di vendita (num vendite, data)

[_Mara_]

ho qualche dubbio: le vendite le fanno solo gli agenti o anche i manager?
perchè vedo che vorresti inserire nell ipotetica tabella vendite o l'id dell'agente o quello del manager...


Esatto, sia manager che agenti fanno N vendite per cui devo tenere traccia dei valori.
Infatti pensavo alla tabella 'Vendite' dove in un generico campo 'id_persona' inserisco id_venditore oppure fk_agente con i suoi attributi.

Non l'avevo scritto ma avevo pensato al discorso data per poi gestire lo storico... grazie del suggerimento :-)

Grazie
Mara

[_Mara_]

in ogni caso, a mio modo di vedere la soluzione piu pulita è fare una tabella vendite separata, contenente tutti i dati relativi alla singola vendita, tra cui suppongo importo e data (fondamentale per poter pensare ad uno storico) e con chiave esterna l'id dell'agente che l'ha effettuata.

Ho un dubbio nella realizzazione:
tab. 'Vendite' (con dati di esempio)
IDvendite | IDpersona |
1 | 1 -- ID di un manager |
2 | 2 -- ID di un agente |
.. | ..
Come faccio a discriminare se l'ID nel campo IDpersona si riferisce a manager o agente?
Lavoro con SQL Server e studio management come tool per creare relazioni e query.

Graficamente posso utilizzare tabella 'Vendite' 2 volte dovendola mettere in relazione sia con id_manager e id_agente?
In pratica: creo 1^ relazione 'Vendite'/'Manager' e poi 2^ relazione 'Vendite_1'/'Agenti': è un'operazione lecita?

Grazie!
Mara

[cdtux]

In una situazione del genere, ho risolto inserendo un campo TIPO nella tabella utente (assegnando ad es. 0 per il manager e 1 per l'agente) per distinguere le varie tipologie.

Non so se è la soluzione migliore, comunque nel mio caso ha funzionato perfettamente.

[Daniels118]

La soluzione è la normalizzazione: crei una tabella "anagrafica" nella quale inserisci tutte le persone indipendentemente dal loro ruolo, in questo modo la tabella vendite potrà referenziare indifferentemente i manager e gli agenti. Per distinguere il ruolo delle persone puoi utilizzare un semplice campo enum nella tabella anagrafica; se i due ruoli necessitano di campi distinti non usare il campo enum, crea invece due tabelle - agenti e manager - con i soli campi differenziati e vi inserisci una relazione con l'anagrafica.

[-MiStO-]

han già detto quasi tutto :)

la soluzione di cdtux è la più rapida e funzionale se non hai bisogno di altre query

Daniels118 invece propone bene di suddividere ulteriormente la base di dati, più flessibile come soluzione:avere un anagrafica "persona" e le tabelle "agente" e "manager" per discriminare sul tipo ti permette, quasi aggratis aggiungendo la relazione tra agenti e manager, tutta una serie di query come "tutti gli agenti di un manager", "tutte le vendite degli agenti di un manager" ecc ecc

come sempre, dipende dal grado di dettaglio desiderato

[Daniels118]

Aggiungo che, visto che c'era la possibilità che venisse chiesto uno storico, si potrebbe ulteriormente normalizzare la base dati anche nella dimensione del tempo, ovvero trasformare le tabelle agente e manager in un'unica tabella denominata rapporto_di_lavoro, avente i seguenti campi:
- id_anagrafica
- tipo_rapporto (enum: {agente, manager})
- data_inizio_rapporto
- data_fine_rapporto
Invece che referenziare direttamente l'anagrafica, le vendite potrebbero puntare al rapporto di lavoro, in questo modo se una persona cambia ruolo puoi facilmente distinguere se le vendite di quella persona sono state fatte in qualità di manager o di agente e in quale periodo (senza necessariamente escludere la possibilità di avere un campo data_vendita nella tabella vendite). Avere una tabella unica ti consente inoltre di poter aggiungere in futuro eventuali nuovi ruoli senza modificare lo schema del database.

[_Mara_]

Preziosissimi! :)

A presto per altre domande.
Mara