[Database] Consigli per progetto

[D4rkAng3l]

Ciao,
per l'esame di database devo portare un progetto un minimo articolato.
Il mio tema è: realizzare il db di un mercatino online (una sorta di piccolo ebay per capire).

Mi sono messo a buttare giù lo schema ER mami trovo completamente privo di fantasia.

Alla domanda: quali sono le entità del db ho detto solo:

UTENTI, OGGETTI, CATEGORIE (categorie di oggetti).

Alla domanda: come si collegano tra di loro ho detto:

c'è una relazione VENDITA che collega UTENTI con OGGETTI e c'è una relazione APPARTENENZA che collega OGGETTI con CATEGORIE.

Però così non va bene, deve essere un proggetto articolato...mi date qualche idea di cosa potrebbe contenere lo schema ER di un tale db.
Se mi date una lista di entità che secondo voi potrebbero essere inserite ve ne sarei molto grato, poi ci penso io a collegarle tra loro con le relazioni.

Grazie
Andrea

[magix2003]

Io creerei un'entità contratto che raccoglie i contratti tra venditore, acquirente e oggetto. L'entità dovrebbe essere debole e quindi già questo aumenterebbe la difficoltà del progetto (non di tanto però).

Se ti servono un paio di idee ti linko il sito del progetto che io ho portato per Introduction to Databases (http://archimedes.inf.unibz.it/teaching2007/ida/team3/)

Spero di essere stato d'aiuto..

Ciao ciao

[D4rkAng3l]

che intendi per entità debole?

Diciamo che l'idea del mio progetto è di realizzare una sorta di mini ebay, magari usando proprio un sistema di aste.

Se per aumentare le relazioni dello schema relazionale aggiungessi anche una relazione tra UTENTI ed OGGETTI chiamata OGGETTI OSSERVATI che indicherebbe su quali oggetti ho fatto un'offerta ma non ho ancora potuto comprare in quanto potrebbero essere comprati da qualcun altro che fà un'offerta maggiore.

Poi potrei aggiungere sempre un'altra relazione tra UTENTI ed OGGETTI chiamata OGGETTI COMPRATI che indica quali oggetti ho effettivamente comprato nello storico da quando mi sono iscritto fino ad oggi.

Poi magari potrei aggiungere una relazione ricorsiva tra UTENTI ed UTENTI chiamata MESSAGGI per gestire un servizio di messaggistica tra utenti iscritti per richiedere informazioni.

Già facendo così avrei aumentato di altre 3 tabelle il database. Che ne pensi? dici che ci possono stare?

Cmq si accettano sempre altri consigli su cose da aggiungere perchè dovrei raggiungere almeno le 10-12 tabelle nel progetto da portare.

Grazie
Andrea

[magix2003]

Originariamente inviato da D4rkAng3l

che intendi per entità debole?

In inglese si chiamano weak-entity, io ho l'ho tradotto in entità deboli, ma forse hanno un altro nome:http://en.wikipedia.org/wiki/Weak_entity

Originariamente inviato da D4rkAng3l

Se per aumentare le relazioni dello schema relazionale aggiungessi anche una relazione tra UTENTI ed OGGETTI chiamata OGGETTI OSSERVATI che indicherebbe su quali oggetti ho fatto un'offerta ma non ho ancora potuto comprare in quanto potrebbero essere comprati da qualcun altro che fà un'offerta maggiore.

Magari potresti volere tenere traccia di amministratori dell'asta che tengono sottocontrollo determinate categorie di oggetti (es Mario controlla Giocattoli). Anche se ammetto è un po' campata in aria.

Prendendo spunto da ebay potresti volere tenere traccia anche di commenti di utenti suoggetti e magari feedbacks tra utenti.

[D4rkAng3l]

ahhh le entità che usano la foreign key di un'altra entità per identificare completamente un record, sisi ho capito di cosa si tratta.

Si per i feedback ci avevo pensato anche io ma te come li gestiresti i feedback lasciati da utenti ad altri utenti, sempre come una relazione da UTENTI a UTENTI?

Ed i commenti sugli oggetti? relazione tra UTENTI ed OGGETTI?

Anche perchè in un mercatino credo che come lo fai lo fai ma alla fine per aumentare il numero di tabelle devi aumentare il numero di relazioni dello schema ER in quanto le entità non credo possano essere molte altre oltre le già citate: UTENTI, OGGETTI, CATEGORIE.

Poi pensavo di fare una relazione ricorsiva su CATEGORIE (che collega CATEGORIE con se stessa) per poter gestire sotto categorie, cioè per esempio c'è la categoria "motori", se uso una relazione di questo tipo posso dire quali sono le sotto categorie di motori: "macchine", "moto", "trattori", etcetc. Che ne pensi?

Ciao
Andrea

[magix2003]

Originariamente inviato da D4rkAng3l

ahhh le entità che usano la foreign key di un'altra entità per identificare completamente un record, sisi ho capito di cosa si tratta.

Si per i feedback ci avevo pensato anche io ma te come li gestiresti i feedback lasciati da utenti ad altri utenti, sempre come una relazione da UTENTI a UTENTI?

Ed i commenti sugli oggetti? relazione tra UTENTI ed OGGETTI?

Anche perchè in un mercatino credo che come lo fai lo fai ma alla fine per aumentare il numero di tabelle devi aumentare il numero di relazioni dello schema ER in quanto le entità non credo possano essere molte altre oltre le già citate: UTENTI, OGGETTI, CATEGORIE.

Poi pensavo di fare una relazione ricorsiva su CATEGORIE (che collega CATEGORIE con se stessa) per poter gestire sotto categorie, cioè per esempio c'è la categoria "motori", se uso una relazione di questo tipo posso dire quali sono le sotto categorie di motori: "macchine", "moto", "trattori", etcetc. Che ne pensi?

Ciao
Andrea

Si per i feedback modellerei una relazione ricorsiva con ruoli di ricevente e autore del feedback.
Sono d'accordo anche per quanto riguarda i commenti, è assolutamente una relazione tra oggetti e utenti.

IMHO, però tutte queste relazioni sarebbe meglio modellarle con delle weak-entity. Perché? Beh semplicemente perché non può esistere un commento senza un utente che scrive il commento ed un oggetto che lo riceve, lo stesso discorso si applica hai feedback.


Per quanto riguarda le categorie la scelta di fare una relazione ricorsiva mi sembra la migliore. Un'altra ipotesi sarebbe quella di fare una gerarchia ISA, ma credo sarebbe molto complicato modellare la relazione tra oggetti e categorie.

[HiroNakamura]

Originariamente inviato da D4rkAng3l

in quanto le entità non credo possano essere molte altre oltre le già citate: UTENTI, OGGETTI, CATEGORIE.

Premetto che non sono un esperto di db...
Ma stai sicuro che non ci sono solo quelle 3 entità....molte relazioni è meglio trasformarle in entità.
Ad esempio io metterei altre entità tra le quali :
- feedback (con id,autore,destinatario,#transazione di riferimento, descrizione)
- Transazione (id,data,....)
- Inserzione (id,autore,descrizione,datains,datascadenza....)

Mi sembra più sensato...
Da quello che mi insegnarono, non si fa mai una relazione
UTENTE----vende---OGGETTO, ma
UTENTE----effettua---VENDITA---contiene---OGGETTO

[D4rkAng3l]

Originariamente inviato da HiroNakamura

Premetto che non sono un esperto di db...
Ma stai sicuro che non ci sono solo quelle 3 entità....molte relazioni è meglio trasformarle in entità.
Ad esempio io metterei altre entità tra le quali :
- feedback (con id,autore,destinatario,#transazione di riferimento, descrizione)
- Transazione (id,data,....)
- Inserzione (id,autore,descrizione,datains,datascadenza....)

Mi sembra più sensato...
Da quello che mi insegnarono, non si fa mai una relazione
UTENTE----vende---OGGETTO, ma
UTENTE----effettua---VENDITA---contiene---OGGETTO

Aspetta però, io per ora stò solo parlando di schema ER e non di modello relazionale, poi trasformando lo schema ER nel relativo modello relazionale allora ovviamente alcune relazioni del modello ER verrebbero accorpate e diventerebbero delle entità ma quella è una fase progetturale che viene dopo

[HiroNakamura]

Originariamente inviato da D4rkAng3l

Aspetta però, io per ora stò solo parlando di schema ER e non di modello relazionale, poi trasformando lo schema ER nel relativo modello relazionale allora ovviamente alcune relazioni del modello ER verrebbero accorpate e diventerebbero delle entità ma quella è una fase progetturale che viene dopo

Nono, anche io ti parlo a livello di schema ER. Certo dove ho messo le parentesi con scritto dentro id,data ecc ecc, era un accenno di modello relazionale, ma le ultime 2 righe in cui dico:
UTENTE----vende---OGGETTO, trasformalo in
UTENTE----effettua---VENDITA---contiene---OGGETTO
bhè questo è da fare già in fase di schema ER

[D4rkAng3l]

e che vantaggio avrei a fare così?
Quello che te chiamo inserzione io lo ho semplicemente chiamato vendita...ed un inserzione è una relazione che collega un utente (che la pubblica) ed un oggetto (che viene venduto) quindi i vari campi circa la data di scadenza, etcetc sono contentui in vendita (o inserzione che dir si voglia).

Perchè secondo te dovrei fare:
UTENTE----vende---OGGETTO, ma
UTENTE----effettua---VENDITA---contiene---OGGETTO

in che modo potrebbe giovarmi fare ciò? al più queta cosa potrebbe venir fuori in fase di normalizzazione se si verificasse che la soluzione originale non fosse almeno in terza forma normale ma se lo fosse allora sarebbe meglio mantenere la prima soluzione in quanto quando vai a fare una query devi navigare per meno tabelle quindi hai: query più facili da realizzare, minor tempo per effettuarle in quanto devi navigare meno tabelle.
A meno che non ci fosse una motivazione strutturale nell'ER (che ne sò attaccarci altre relazioni ed altre entità) non vedo il motivo di fare questa cosa nell'ER in quanto se proprio serve lo ottieni in fase di normalizzazione.

Almeno così credo...

[magix2003]

Perchè secondo te dovrei fare:
UTENTE----vende---OGGETTO, ma
UTENTE----effettua---VENDITA---contiene---OGGETTO

Il secondo modo è utile se hai molti attributi associati alla vendita e soprattutto, mi ripeto per l'ennesima volta, per modellare il tutto con delle weak entity. Se non ti interessa questo credo basti la prima alternativa.

[D4rkAng3l]

Originariamente inviato da magix2003

Il secondo modo è utile se hai molti attributi associati alla vendita e soprattutto, mi ripeto per l'ennesima volta, per modellare il tutto con delle weak entity. Se non ti interessa questo credo basti la prima alternativa.

mmm non vorrei dire una vaccata ma se ha molti attributi credo che al 99% ci saranno degli attributi che non saranno in dipendenza funzionale dalla chiave o ci saranno delle dipendenze transitive quindi in fase di normalizzazione spezzi in più tabelle comunque.

[D4rkAng3l]

Originariamente inviato da magix2003

Si per i feedback modellerei una relazione ricorsiva con ruoli di ricevente e autore del feedback.
Sono d'accordo anche per quanto riguarda i commenti, è assolutamente una relazione tra oggetti e utenti.

IMHO, però tutte queste relazioni sarebbe meglio modellarle con delle weak-entity. Perché? Beh semplicemente perché non può esistere un commento senza un utente che scrive il commento ed un oggetto che lo riceve, lo stesso discorso si applica hai feedback.


Per quanto riguarda le categorie la scelta di fare una relazione ricorsiva mi sembra la migliore. Un'altra ipotesi sarebbe quella di fare una gerarchia ISA, ma credo sarebbe molto complicato modellare la relazione tra oggetti e categorie.

Credo di aver capito cosa intendi...dimmi se per te così potrebbe andar bene come soluzione.

Il feedback io non lo dò semplicemente ad un utente ma come su ebay lo dò ad un utente in relazione ad una certa situazione ovvero l'asta che ho vinto dell'oggetto messo in vendita dal venditore (volendo considerare solo il caso in cui dò un feedback solo al venditore e non al compratore).

Allora nella relazione feedback dovrei coinvolgere l'entità utente in maniera ricorsiva ma anche l'entità oggetto: quindi avrei una relazione ternaria tra UTENTI, UTENTI e OGGETTI, ci può stare come ragionamento?

Grazie
Andrea

[HiroNakamura]

Originariamente inviato da D4rkAng3l

Allora nella relazione feedback dovrei coinvolgere l'entità utente in maniera ricorsiva ma anche l'entità oggetto: quindi avrei una relazione ternaria tra UTENTI, UTENTI e OGGETTI, ci può stare come ragionamento?

Bo...sarò di coccio io (vabbhe che avevo premesso che non ero esperto di db, però ci lavoro sopra...)
E' così difficile vedere il "feedback" come entità?!?!? Si evitano relazioni ricorsive e e ternarie!

UTENTE---rilascia---FEEDBACK---riguarda---VENDITA---contiene---OGGETTO
     |                                                             |
     -------inserisce----INSERZIONE----contiene---------------------

[magix2003]

Originariamente inviato da HiroNakamura

Bo...sarò di coccio io (vabbhe che avevo premesso che non ero esperto di db, però ci lavoro sopra...)
E' così difficile vedere il "feedback" come entità?!?!? Si evitano relazioni ricorsive e e ternarie!

UTENTE---rilascia---FEEDBACK---riguarda---VENDITA---contiene---OGGETTO
     |                                                             |
     -------inserisce----INSERZIONE----contiene---------------------

Riflettendoci bene anche a me sembra la scelta migliore. Mi sembra per così dire più ad alto livello.

[D4rkAng3l]

mmm più che altro non mi torna questa parte:

-VENDITA---contiene---OGGETTO

perchè?

Una domanda, con mysql è possibile eliminare un record automaticamente superata la data inserita in un certo campo di tale record?
Per esempio mettiamo che in una colonna chiamata "scadenza" c'è scritto che la riga di un'asta scade alle 14:00 del giorno martedi 12 febraio 2008, è posibile che mysql la elimini automaticamente superata tale data e orario o devo farlo manualmente tramite PHP?

Grazie
Andrea

[HiroNakamura]

Originariamente inviato da D4rkAng3l

mmm più che altro non mi torna questa parte:

-VENDITA---contiene---OGGETTO

perchè?

perchè come VENDITA è intesa la transazione, che avrà ad esempio id,data,tipopagamento,somma ecc... e ovviamente una foreign key verso l'entità oggetto,che avrà altre proprietà, come marca, modello, ecc ecc

Una domanda, con mysql è possibile eliminare un record automaticamente superata la data inserita in un certo campo di tale record?
Per esempio mettiamo che in una colonna chiamata "scadenza" c'è scritto che la riga di un'asta scade alle 14:00 del giorno martedi 12 febraio 2008, è posibile che mysql la elimini automaticamente superata tale data e orario o devo farlo manualmente tramite PHP?

Grazie
Andrea

Questo non lo so, penso serva una store procedure, ma non so se poi effettua l'operazione automaticamente.

edit: ps. nel mio precedente schema ci dovrebbe essere anche una relazione tra INSERZIONE e VENDITA, che verrà poi accorpata nell'entità VENDITA