[DIAGRAMMA ER] Aiuto su progetto Web

[Paranoid_mess]

Ciao a tutti,
Ho un problema poichè sto sviluppando un applicativo web per un professore nel quale devo trattare un Social. C'è da fare anche il diagramma ER e la relativa base di dati.
Una delle funzionalità di questo applicativo è quella che ogni utente può richiedere l'amicizia a diversi utenti; una delle richieste è tenere traccia dello storico delle amicizie, ho pensato quindi di fare una entità utente collegata ad una associazione richiede che ritorna poi ad utente in tutti e due i rami (0.n) (mittente, destinatario della richiesta).
In tal modo però se un utente dovesse chiedere una amicizia ad un utente, dopo un po eliminarlo e richiedergliela, non si potrebbe poichè comparirebbe due volte la coppia nome utente mittente e destinatario, (ho pensato alla rimozione della tupla della prima richiesta del database ma devo mantenere lo storico completo). Ho deciso di usare un attributo data_richiesta all'interno della associazione (che diventerà una tabella nello schema relazionale) per distinguere la coppia degli utenti se dovesse ripresentarsi ma a questo punto data_rich dovrebbe far parte della chiave.
Solo che un attributo di una associazione non può divenire chiave in fase di traduzione, invece, il professore sostiene di si col processo di reificazione. (?)
Quello che avevo pensato è anche una entità amicizia ma non ho idea di come e dove collegarla.
Allego la foto del caso. Grazie mille !
https://ibb.co/hS1GkV

[Mason]

xche 0-n?

una richiesta secondo me ha 1 destinatario ed 1 richiedente, la sequenza di queste da le richieste a molteplici amici (potrebbe anche essere che 1 richiesta puo andare verso piu target, ma a quel punto hai bisogno di molti d_completamento_richiesta, non molto pulito e poco gestibile dall'operazionale).

una richiesta senza mittente o destinatario non ha senso, almeno in casi reali.
(nessuno chiede l'amicizia a caio? caio chiede l'amicizia a nessuno?)

se devi tenere traccia dei cambi stati io userei un altra entita con id_richiesta, stato, data_ingresso_stato.

inoltre un amicizia puo essere recisa, potresti metterci un tipo alla richiesta (tipo amicizia, tipo rescissione). o piu pulito fai un altra entita' tipo rescissione ma con una gestione forse piu complessa/meno uniformata.

se devi tenere lo stato non puoi fare delete per me, ma giocare sulle date piu recenti delle richieste (amicizia/rescissione) oppure avere un entita' che ti tiene lo staato attuale tragli utenti.

Vabbe, spero ti serva, ciao

[DrPsyche]

Originariamente inviato da Paranoid_mess

Ciao a tutti,
Ho un problema poichè sto sviluppando un applicativo web per un professore nel quale devo trattare un Social. C'è da fare anche il diagramma ER e la relativa base di dati.
Una delle funzionalità di questo applicativo è quella che ogni utente può richiedere l'amicizia a diversi utenti; una delle richieste è tenere traccia dello storico delle amicizie, ho pensato quindi di fare una entità utente collegata ad una associazione richiede che ritorna poi ad utente in tutti e due i rami (0.n) (mittente, destinatario della richiesta).
In tal modo però se un utente dovesse chiedere una amicizia ad un utente, dopo un po eliminarlo e richiedergliela, non si potrebbe poichè comparirebbe due volte la coppia nome utente mittente e destinatario, (ho pensato alla rimozione della tupla della prima richiesta del bot writer database ma devo mantenere lo storico completo). Ho deciso di usare un attributo data_richiesta all'interno della associazione (che diventerà una tabella nello schema relazionale) per distinguere la coppia degli utenti se dovesse ripresentarsi ma a questo punto data_rich dovrebbe far parte della chiave.
Solo che un attributo di una associazione non può divenire chiave in fase di traduzione, invece, il professore sostiene di si col processo di reificazione. (?)
Quello che avevo pensato è anche una entità amicizia ma non ho idea di come e dove collegarla.
Allego la foto del caso. Grazie mille !
https://ibb.co/hS1GkV

Ho lavorato con la reificazione dei dati lo scorso semestre (la reificazione dei messaggi in Smalltalk).
La reificazione dei dati è simile per alcuni aspetti al raffinamento dei dati, tuttavia, il processo di reificazione è più focalizzato sulla concretizzazione dell'idea che sulla sua raffinazione. Per quanto riguarda la reificazione dei dati, il perfezionamento comprende fasi per trovare una rappresentazione più concreta dei tipi di dati astratti, che viene eseguita utilizzando le specifiche standard.