[DATABASE] Importante, parere schema ER per progetto da consegnare all'esame

[D4rkAng3l]

Ciao,
allora il 20 devo portare il progetto per l'esame di basi di dati.

Il mio tema è l'implementazione di un piccolo sistema di aste online, simil ebay anche se molto semplificato. Oggi ho tirato giù lo schema ER, ditemi cosa ne pensate.

Per ora mancano ancora i campi perchè devo pensarci bene ma cmq spiego a parole come funziona:

http://www.siatec.net/andrea/uni/db/progetto.jpg


Le ENTITA'coinvolte sono:

1) UTENTE: che rappresenta gli utenti iscritti al mercatino.

2) INSERZIONE: che rappresenta gli oggetti messi in vendita dai vari utenti e che possono essere visionati e comprati da altri utenti.

3) CATEGORIA: che rappresenta le varie categorie di inserzioni messe in vendita (ad esempio: materiale fotografico, strumenti musicali, auto e motori, elettronica, etcetc).

4) PERMESSI: rappresenta dei permessi che gli utenti iscritti possono eventualmente avere e che li abilitano a moderare determinate categorie di oggetti (per controllare ad esempio che non vi siano messaggi scurrili o per eliminare manualmente annunci che potenzialmente potrebbero essere delle truffe).

A questo punto che ho definito le entità del mio proggetto passiamo a escrivere le RELAZIONI che di fatto implementano le funzionalità del mio sistema di aste online:

1) VENDE: mette in relazione le entità UTENTE ed INSERZIONE, di fatto regola l'inserzione e conterrà la data di scadenza dell'asta, la cardinalità è così impostata perchè un utende iscritto al sercizio può vendere minimo 0 oggetti e massimo n oggetti, vicecersa un oggetto può essere venduto da minimo un utente e massimo un utente (mi sono appena accorto di aver fatto un errore nell'ER...bene...)

2) OFFERTA: indica tutte le offerte che gli utenti del sistema possono fare circa gli oggetti, ogni offerta mette in relazione un certo utente con un certo oggetto che vorrebbe comprare e conterrà la cifra offerta per quell'oggetto e la data con l'orario per poi controllare che non si sia superata la scadenza dell'asta (ma questo ci penserà lo script in PHP che non devo sviluppare ai fini del proggetto). La cardinalità dice che un utente può fare minimo 0 offerte per un certo oggetto e massimo n offerte, viceversa un oggetto può ricevere offerte da minimo 0 utenti e massimo n utenti che vorrebbero comprarlo.

3) COMMENTO: commento semplicemente mette in relazione gli utenti con gli oggetti messi in vendita, a prescindere che un utente voglia comprare o meno un certo oggetto può lasciare un commento sul prodotto che viene venduto (ad esempio se Mario Rossi vuole lasciare un commento sull'Olympus E3 dicendo: "Bellissima macchina, balblabla" potrà farlo), quindi tale relazioni oltre alle chievi di UTENTE e INSERZIONE conterrà anche un campo testuale per il commento.

4) MESSAGGIO: è una relazione ricorsiva su UTENTE che conterrà per chiave un proprio identificatore univoco per ogni messaggio, la chiave dell'utente mittente, la chiave dell'utente destinatario e un campo di testo per il messaggio vero e proprio.

5) FEEDBACK: è la relazione più complessa di tutto il sistema perchè è una relazione ternaria tra UTENTE, UTENTE ed INSERZIONE. Allo stato attuale delle cose per semplicità ho pensato che per ora il feedback viene dato solo dall'acquirente al venditore e non viceversa.
Quindi un utente acquirente darà un valotre di feedback (positivo o neutro o negativo) ad un venditore in relazione ad un certo oggetto che ha comprato.

6) APPARTIENTE: dice semplicemente che un oggetto messo in vendita deve appartenere ad una certa categoria (per esempio la Olympus E3 apparterrà alla categoria: MATERIALE FOTOGRAFICO). La cardinalità dice che un oggetto apparterrà ad una ed una sola categoria e che una categoria potrà contare minimo 0 oggetti e massimo n messi in vendita.

7) SUBCAT è una relazione ricorsiva sull'entità CATEGORIA per poter gestire vari livelli di sottocategorie annidate l'una dentro l'altra, sostanzialmente dice che una categoria può essere sotto categoria di un'altra. Per esempio la categoria "Reflex Digitali" sarà sottocategoria della categoria: "Materiale Fotografico"...eventualmente così facendo potrei anche gestire più livelli di annidamento in modo molto pratico creando ad esempio le categorie: "Reflex Digitali Olympus", "Reflex Digitali Canon", "Reflex Digitali Nikon" come sotto categorie della sotto categoria "Reflex Digitali".
La cardinalità mi dice che una categoria può avere minimo 0 e massimo n categorie figle e viceversa che una categoria figlia può avere al più una categoria padre (anche quà c'è un errorino in quanto potrebbe anche avere 0 categorie padre qualora non fosse annidata).

8) POSSIDE: mi mette in relazione l'entità UTENTE con l'entità PERMESSI e di fatto mi dice quali permessi possiere un utente, un pemesso sarà identificato da un codice e avrà una descrizione testuale ma di fatto la relazione fà solo una associazione tra gli utenti e i suoi permessi, ad esempio:

0052 001
0052 003
0067 004

potrebbe significare che l'utente 0052 avrà abilitati i permessi 001 e 003 mentre l'utente 0067 avrà abilitato il solo permesso 004.
Ora dal momento che si tratta di moderatori e che i moderatori saranno pochi rispetto al numero degli utenti l'eventuale ridondanza di righe la potrei considerare trascurabile perchè tale tabella avrà cmq un'occupazione molto limitata per sua stessa natura.

MODERA: mette in relazione i permessi con le sezioni che possono moderare e dice che un permesso abilita la moderazione ad una ed una sola categoria di oggetti e viceversa che una categoria è moderata da uno ed un solo permesso (ovviamente in fase di trasformazione in schema relazionale questa relazione verrà eliminata e permessi punterà direttamente a categoria).

Ora magari non è perfetto, ma è stato fatto con tantoooo ammmoreeee :D (e soprattutto mi son rotto le balline e vorrei finire al più presto senza smadonnare troppo).

Secondo voi come idea ha una sua decenza? Dite che potrei andare avanti o dovrei rivederlo da 0?

Grazie
Andrea

[gugoXX]

A me piace.

Solo con l'occhio "pratico" di chi poi dovrebbe usarlo, vedo che manca la relazione che dice quali sono stati effettivamenti gli scambi.
Una tabella che mi dice chi ha venduto, che cosa e a chi.
Certo, le informazioni ci sono tutte, ma sono costretto ad andare in JOIN su qualche tabella, e se chi disegna non mi da anche una mano con qualche campo, non solo devo fare queste JOIN, ma devo anche andare a fare una brutta FULL TABLE SCAN sulle offerte, per andare a trovare questi dati.

Per intenderci, (tanto se devi dare l'esame l'SQL lo dovresti sapere fare) quale query faresti per andare a pescare gli scambi effettivamente fatti grazie al servizio di aste?

Poi, incastrare questa relazione sarebbe banale, ma non rientra in un bel disegno normalizzato proprio perche' le informazioni gia' nel tuo modello ci sono tutte.
Che dire, speriamo al prof. non sia venuta in mente questo particolare che secondo me e' probabile che sia sfuggito a molti.

Ah, ancora, Modera lo consideri ereditario?
Se modero il "materiale fotografico" modero anche le "Canon"?
Ma ho entrambe le relazioni oppure solo quella verso il padre?
Boh, su questo punto applicativamente non ci sono problemi, ma sono domande che e' bene porsi prima del professore.

[D4rkAng3l]

A me piace.

Solo con l'occhio "pratico" di chi poi dovrebbe usarlo, vedo che manca la relazione che dice quali sono stati effettivamenti gli scambi.
Una tabella che mi dice chi ha venduto, che cosa e a chi.
Certo, le informazioni ci sono tutte, ma sono costretto ad andare in JOIN su qualche tabella, e se chi disegna non mi da anche una mano con qualche campo, non solo devo fare queste JOIN, ma devo anche andare a fare una brutta FULL TABLE SCAN sulle offerte, per andare a trovare questi dati.

Per intenderci, (tanto se devi dare l'esame l'SQL lo dovresti sapere fare) quale query faresti per andare a pescare gli scambi effettivamente fatti grazie al servizio di aste?

Poi, incastrare questa relazione sarebbe banale, ma non rientra in un bel disegno normalizzato proprio perche' le informazioni gia' nel tuo modello ci sono tutte.
Che dire, speriamo al prof. non sia venuta in mente questo particolare che secondo me e' probabile che sia sfuggito a molti.

Ah, ancora, Modera lo consideri ereditario?
Se modero il "materiale fotografico" modero anche le "Canon"?
Ma ho entrambe le relazioni oppure solo quella verso il padre?
Boh, su questo punto applicativamente non ci sono problemi, ma sono domande che e' bene porsi prima del professore.

Ti ringrazio della tua risposta,
per quanto riguarda la domanda circa la tabella di chi ha venduto un certo oggetto e a chi (correggimi se dico una marea di vaccate), visto che:
1) Ho premesso che per motivi di semplicità al momento il feedback è solo dato dall'acquirente al venditore (e non viceversa nella relazione FEEDBACK)

2) Ogni riga della relazione FEEDBACK contiene al proprio interno l'utente acquirente (che rilascia il feedback), l'utente venditore (che riceve il feedback su come si è comportato all'atto di una certa vendita) e appunto l'oggetto che è stato venduto.

Così penso che se volessi fare la famosa query.
Quindi metti caso che volessi tirar fuori tutti gli ogetti che ha comprato l'utente Mario Rossi potrei fare una query sulla relazione FEEDBACK con campo aquirente uguale a Mario Rossi.

mmm potrebbe andare come idea? :D

[gugoXX]

Va benissimo, a patto di aggiungere un vincolo "applicativo", ovvero forzare applicativamente l'esistenza di uno e un solo feedback per ciascuno scambio effettuato.
Dico applicativo perche' sul tuo modello non mi sembra potrai forzarlo con qualche constraint.

Il fatto di considerare quella come tabella degli scambi purtroppo non riponde ancora appieno alla domanda a cui pensavo ieri:
Quanti euro totali Giovanni ha pagato a Pino, grazie alle vendite sul nostro servizio?
La risposta e' ancora un po' scomoda e purtroppo alla fine i commerciali quello vogliono...
Ma per fortuna i Professori non sono commerciali, e magari non se lo chiedono.
Diciamo che nel tuo caso questa query potrebbe essere una bella vista, e nessuno avra' nulla da ridire fintantoche' sara' abbastanza veloce.

[D4rkAng3l]

Va benissimo, a patto di aggiungere un vincolo "applicativo", ovvero forzare applicativamente l'esistenza di uno e un solo feedback per ciascuno scambio effettuato.
Dico applicativo perche' sul tuo modello non mi sembra potrai forzarlo con qualche constraint.

Il fatto di considerare quella come tabella degli scambi purtroppo non riponde ancora appieno alla domanda a cui pensavo ieri:
Quanti euro totali Giovanni ha pagato a Pino, grazie alle vendite sul nostro servizio?
La risposta e' ancora un po' scomoda e purtroppo alla fine i commerciali quello vogliono...
Ma per fortuna i Professori non sono commerciali, e magari non se lo chiedono.
Diciamo che nel tuo caso questa query potrebbe essere una bella vista, e nessuno avra' nulla da ridire fintantoche' sara' abbastanza veloce.

mmm speriamo le vada bene.
Pensavo anche di poter fare un'altra cosa, visto che di fatto Offerta contiene qual'è il prezzo speso dall'utente potrei fare una query un po' più complessa che prenda in considerazione 3 tabelle nel from e tramite la quale estrae anche il prezzo di ogni oggetto comprato...è un po' macchinoso però dovrebbe funzionare. che ne dici?

[HiroNakamura]

Già sai la mia risposta :D
A costo di essere ripetitivo...non mi piace per niente! :eek: :eek:

Ci sono parecchi errori.
In ordine sparso:
-COMMENTO non è una relazione ma un entità
-FEEDBACK non è una relazione ma un entità
-OFFERTA non è una relazione ma un entità
-la ricorsione SUBCAT, mi solleva parecchi dubbi. Meglio prevedere in fase di progetto un livello di profondità, con eredità dalla categoria superiore e non una relazione ricorsiva
-MESSAGGIO...bo anche questo farei come entità ma può andare anche così forse...

Ovviamente tutto secondo me :)

[gugoXX]

mmm speriamo le vada bene.
Pensavo anche di poter fare un'altra cosa, visto che di fatto Offerta contiene qual'è il prezzo speso dall'utente potrei fare una query un po' più complessa che prenda in considerazione 3 tabelle nel from e tramite la quale estrae anche il prezzo di ogni oggetto comprato...è un po' macchinoso però dovrebbe funzionare. che ne dici?

Vedrai che se non aggiungi comunque qualcosa e' davvero "bruttina".
Ti consiglio, anche solo a titolo di esercizio preparativo per l'esame, di provare a scriverla.
Prima di scriverla ti consiglio di districare ancora un "errore" comune, che si fa non solo a livello accademico ma anche in pratica.
Quali sono le entita' che insistono sulle tue tabelle Offerta e Commento?
In pratica, quale e' la chiave primaria di ciascuna di tali tabelle?

[D4rkAng3l]

ah si ma le chiavi le ho fatte...è che non le ho inserite nel disegno solo perchè l'ho fatto con photoshop e stavo impazzendo...ora mi installo Visio e rifaccio con quello, sul disegno su carta le ho messe tutte ;-)

[gugoXX]

Ecco, dicci la chiave di quelle 2 relazioni... (Offerta e Commento)

[D4rkAng3l]

beh per OFFERTA metterei un id univoco per ogni offerta in quanto un utente potrebbe effettuare più offerte per uno stesso oggetto quindi la relazione probabilmente avrebbe una forma tabellare del genere:

OFFERTA(id_offerta, id_utente, id_oggetto, valore_offerta)

Per COMMENTO potrei fare una cosa simile oppure potrei dire che un utente può lasciare un solo commento su un certo oggetto e impostare come chiave della relazione i campi id_utente ed id_oggetto senza dover creare un id_commento per ogni commento.

Cmq credo che nel primo caso di OFFERTA possa andare bene perchè su un vecchio esame scritto c'era da creare un db degli atterraggi su varie portaerei e visto che la relazione era simile avevo:
ATTERRAGGIO(id_atterraggio, nome_portaerei, codice_aereo, data, oraraio)

Quindi di fatto non le dovrebbe dispiacere troppo creare un id univoco in situazioni potenzialmente ambigue come queste...credo che absti specificarlo nella documentazione e motivare la scelta, o no?

[gugoXX]

A me cosi' non piace.
Cerco di spiegarmi.
Non mi ricordo che forma normale sia, ma mi piace vedere le entita' realizzate con chiave primaria unica, singola (il classico ID), e le relazioni realizzate con chiave primaria multipla, esattamente l'unione delle chiavi primarie delle entita' che vi insistono.

Ora, se tu realizzi Offerta con chiave primaria unica (ID), allora mi sembra che tu la stia trattando un po' come una entita', come suggerito da HiroNakamura.
Ed essendo entita' non dovresti legarla direttamente alle altre (Utente ed Inserzione) del modello.

Ovviamente per realizzarla come relazione pura occorre ancora "qualcosa", se vuoi giustamente dare la possibilita' ad un utente di fare piu' offerte per la medesima inserzione.

Ma supponiamo pure che tu decida di lasciare tutto cosi'.
Hai idea della fatica per andare a rispondere alla mia query:
Quanti euro totali Giovanni ha pagato a Pino, grazie alle vendite sul nostro servizio?
Prova a scriverla, tanto sono domande classiche da esame.

[D4rkAng3l]

A me cosi' non piace.
Cerco di spiegarmi.
Non mi ricordo che forma normale sia, ma mi piace vedere le entita' realizzate con chiave primaria unica, singola (il classico ID), e le relazioni realizzate con chiave primaria multipla, esattamente l'unione delle chiavi primarie delle entita' che vi insistono.

Ora, se tu realizzi Offerta con chiave primaria unica (ID), allora mi sembra che tu la stia trattando un po' come una entita', come suggerito da HiroNakamura.
Ed essendo entita' non dovresti legarla direttamente alle altre (Utente ed Inserzione) del modello.

Ovviamente per realizzarla come relazione pura occorre ancora "qualcosa", se vuoi giustamente dare la possibilita' ad un utente di fare piu' offerte per la medesima inserzione.

Ma supponiamo pure che tu decida di lasciare tutto cosi'.
Hai idea della fatica per andare a rispondere alla mia query:
Quanti euro totali Giovanni ha pagato a Pino, grazie alle vendite sul nostro servizio?
Prova a scriverla, tanto sono domande classiche da esame.

Si lo sò, però allora o metto come chiave primaria della relazione OFFERTA sia id_utente sia id_oggetto che il valore dell'offerta allora identificherei univocamante comuqnue ma avrei 3 campi per una chiave e non mi pare molto carino.

Lo sò che stilisticamente non è bellissima come soluzione ma allo stesso tempo in questo caso mi pare la più pratica...per te è cmq praticabile (ovviamente motivandogli la scelta nella relazione) oppure mi potrebbe uccidere?