progetto di un database per un negozio di videogiochi

1. università degli studi di Trieste corso di laurea triennale in ingegneria informatica progetto di un database per un negozio di videogiochi

2. Negozio di videogiochi Si vuole realizzare un database per la gestione di un negozio di vendita videogiochi. I prodotti che il negozio vende sono videogiochi, console, alcune guide di giochi e svariati accessori per console e computer. I dipendenti che lavorano nel negozio al momento della vendita di un prodotto devono inserire il proprio codice personale. I dati del dipendente che servono sono codice dipendente, nome, cognome, il ruolo all’interno del negozio, sesso, indirizzo, telefono, e-mail. Il dipendente inoltre può vendere solo prodotti disponibili e non può vendere una quantità negativa o nulla. Le console possono essere portatili o per tv e ogni console possiede i suoi giochi. Di ogni gioco si vuole memorizzare il codice prodotto, il titolo, la casa produttrice, il prezzo, la trama, il genere, la console a cui fa riferimento, il supporto (se cd, dvd, ecc.), la quantità e l’ anno di produzione. Per ogni console si vogliono memorizzare i dati relativi al codice prodotto, nome, la versione, il prezzo, la casa produttrice e alla quantità. Per ogni accessorio si vuole memorizzare il codice prodotto, tipo (se joystick, joypad, ecc.), a quale modello si riferisce, il prezzo e la quantità. Il negozio ha diversi fornitori da cui può comprare. Per fornitore si intende una società. Per ciascun fornitore si vuole memorizzare il nome della sede, l’indirizzo della società, il numero di telefono,la città e lo stato in cui si trova. Per ciascuna guida al gioco si vuole memorizzare titolo, il prezzo, la sua quantità e a quale console si riferisce. La guida può far riferimento anche a più console.

3. Glossario dei termini

4. Strutturazione dei requisiti

6. Operazioni sui dati • Inserimento dati anagrafici di un fornitore e di un dipendente (circa 1 volta l’anno) • Inserimento dati console, videogioco, accessorio e guida (circa 3 volte al mese) • Modifica dati anagrafici di un fornitore e di un dipendente (circa 1 volta l’anno) • Modifica dati console, videogioco, guida e accessorio (circa 2 volte al mese) • Visualizzare tutti i dati di un fornitore (circa 2 volte al mese) • Dato il titolo del videogioco visualizzare tutti i suoi dati (circa 50 volte al giorno) • Dato il nome di una console visualizzare tutti i dati e tutte le versioni disponibili con i relativi prezzi e quantità disponibile (circa 1 volta al giorno) • Dato il tipo di accessorio visualizzare tutti i dati e a che console si riferisce (circa 1 volta al giorno) • Dato il titolo di una guida visualizzare tutti i suoi dati (circa 5 volte a settimana) • Vendita di un videogioco, di una console, di una guida e di un accessorio inserendo il codice dipendente, la data in cui avviene la vendita e la quantità venduta (circa 50 volte al giorno) • Classifica dei dipendenti visualizzando oltre i dati relativi al dipendente anche la quantità di videogiochi venduti tra due date (circa 1 volta al mese ) • Classifica dei videogiochi in base alla quantità venduta tra due date (circa 1 volta alla settimana) • Classifica delle console più vendute in un intervallo di date (circa 1 volta al mese) • Classifica dei dipendenti visualizzando, oltre i dati del cliente, anche il fatturato di vendita dei videogiochi tra due date(1 volta al mese)

7. PROGETTAZIONE CONCETTUALESchema scheletro • Strategia di progetto usata • progettazione mista • Suddivisione in sottoproblemi • Raffinamenti successivi

8. Diagrammi E R : raffinamento dell’entità videogioco • Hanno un loro genere • Fanno riferimento ad una casa produttrice • Possono avere diversi supporti (cd, dvd, ecc.) • Un videogioco è riferito ad una determinata console (es: resident evil 4 per playstation, wii ecc.) Di ogni videogioco si registrano il numero di serie, il titolo, il prezzo, la trama, la disponibilità e l’ anno di produzione. La disponibilità è intesa come quantità disponibile.

9. Raffinamento dell’entità console: La console è prodotta da una casa produttrice → Per ogni console si conoscono i dati relativi al numero di serie, nome, il prezzo e la quantità. Una console può avere diversi tipi di versione (es: la playstation 2 versione ‘original’ e la playstation 2 versione ‘slim’) • Si dividono in console portatile oppure in console per televisione Generalizzazione TOTALE ed ESCLUSIVA: una console può essere solo portatile o solo per tv, non può essere tutte e due.

10. Raffinamento dell’entità guida e accessorio: Una guida di videogiochi deve essere associata ad una console perché il cliente che richiede una particolare guida deve conoscere per che console è stata scritta. Di ciascuna guida al gioco si conosce il titolo, il prezzo e la quantità disponibile a magazzino. Un accessorio è associato ad una determinata console (per esempio presa scart per playstation 2).

11. Raffinamento dell’entità fornitore e relazioni con videogioco, console, guida e accessorio • Il fornitore fornisce al negozio dei prodotti, quali videogiochi, console, guide e accessori. • Esistono diversi fornitori per i diversi prodotti del negozio. • Dato un prodotto qualsiasi si può conoscere qual è il fornitore associato. Per ciascun fornitore si conosce il nome della sede, l’indirizzo della società, il numero di telefono,la città e lo stato in cui si trova. Il fornitore, inteso come società, risiederà in una città precisa di uno stato. Per esempio, Tecnogroup s.p.a., Roma, Italia.

12. L’entità dipendente e la relazione vendita dei prodotti Il dipendente al momento della vendita deve inserire il suo codice personale per un eventuale identificazione successiva. I dati del dipendente che si conoscono sono il codice dipendente, il nome, il cognome, il ruolo che ha all’interno del negozio, il sesso, l’ indirizzo, il telefono e la e-mail.

13. Schema concettuale finale

14. ANALISIDELLEENTITA’

19. ANALISI DELLE RELAZIONI E DELLA CARDINALITA’

23. Business Rules

24. Schema E R finale con attributi e cardinalità

25. PROGETTAZIONE LOGICA: tavola dei volumi Entità Relazioni Nella tavola dei volumi vengono riportati tutti i concetti dello schema con il volume (numero di occorrenze) previsto a regime.

26. Tavola delle operazioni

27. Schema di operazione – tavola degli accessi OPERAZIONE : Dato il titolo del videogioco visualizzare tutti i suoi dati Un titolo di videogioco in media ha 2 supporti perché è venduto per 2 console diverse Un titolo di videogioco ha un unico genere In media un titolo di videogioco è venduto per 2 console. Un titolo di videogioco ha una sola casa produttrice

28. Ristrutturazione dello schema E-R : Eliminazione delle generalizzazioni La gerarchia “console”-“tv”-“portatile”, non avendo i figli attributi specifici che li distinguono, viene risolta inglobando le entità figlie della generalizzazione nel padre, aggiungendo un attributo “portatile” che contraddistingue il tipo di console. Non ci sono relazioni che interessavano “tv” e “portatile” quindi la gerarchia rimane così.

29. Ristrutturazione dello schema E-R : Partizionamento dell’entità videogioco • L’entità “videogioco” viene partizionata in due • entità “dati videogioco” e “videogioco” separando • così i suoi attributi che: • vengono acceduti da operazioni diverse • in fase di caricamento si presentano delle ridondanze di dati (si pensi che in media un videogioco è riferito a 2 console distinte). • Questo tipo di partizionamento si chiama • ‘decomposizione verticale’ cioè si suddivide il • concetto operando sui suoi attributi. • Soluzione: si decide di accorpare gli attributi • “quantità” e “prezzo” nell’ entità “videogioco” e gli • attributi “videogiocoID”, “titolo”, “”anno” e “trama” • nell’entità “dati videogioco”. • La chiave primaria dell’entità “videogioco” è una • chiave composta dagli attributi “VideogiocoID” e • “ConsoleID” che sono anche le due chiavi esterne • della stessa entità.

30. Ristrutturazione dello schema E-R : Partizionamento dell’entità console L’entità “console” viene partizionata in due entità “dati console” e “console” separando così i suoi attributi che vengono acceduti da operazioni diverse e presenterebbero ridondanza dati. Anche in questo caso si tratta di una ‘decomposizione verticale’. Soluzione: si decide di accorpare gli attributi “quantità” e “prezzo” nell’ entità “console” e gli attributi “consoleID” e “nome” nell’entità “dati console”. La chiave primaria dell’entità “console” è composta da 2 attributi “ConsoleID” e “VersioneID” che sono anche chiave esterne per la stessa entità.

31. Ristrutturazione dello schema E-R : Partizionamento dell’entità accessorio L’entità “accessorio” viene partizionata in due entità “tipo accessorio” e “accessorio” separando così i suoi attributi che vengono acceduti da operazioni diverse e che presenterebbero ridondanza dati. Anche in questo caso si tratta di una ‘decomposizione verticale’. Soluzione: si decide di accorpare gli attributi “quantità” e “prezzo” nell’ entità “accessorio” e gli attributi “accessorioID” e “tipo” nell’entità “tipo accessorio”. La chiave primaria dell’entità “accessorio” è composta da 2 attributi “AccessorioID” e “ConsoleID” che sono anche chiavi esterne per la stessa entità.

32. Ristrutturazione dello schema E-R : Partizionamento delle relazioni vendita e fornitura La relazione “vendita” viene partizionata in quattro relazioni “vendita v”, “vendita g”,”vendita a” e “vendita c”. Il partizionamento della relazione è dovuto al fatto che nell’atto di vendita non si venderà mai (o quasi mai) più prodotti contemporaneamente e quindi ci sarebbe una grossa quantità di valori NULL. La relazione “fornitura” viene partizionata in quattro relazioni “fornitura v”, “fornitura g”,”fornitura a” e “fornitura c”. Il partizionamento della relazione è dovuto al fatto che nell’atto di inserimento a magazzino di un prodotto non si inserirà mai tutti i prodotti contemporaneamente e quindi ci sarebbe una grossa quantità di valori NULL.

33. Ristrutturazione dello schema E-R : attributi composti e multivalore Eliminazione degli attributi multivalore

34. Eliminazione degli attributi composti

35. Ristrutturazione dello schema E-R : BUSINESS RULES  REGOLE DI VINCOLO  (1), (2) e (3) “Il dipendente non deve vendere una quantità nulla o negativa” “Il dipendente, al momento della vendita di un prodotto, deve inserire il proprio codice personale” “Il dipendente deve vendere solo prodotti disponibili” I VINCOLI DEVONO ESSERE RISPETTATI QUI : Non posso vendere un prodotto (in fase di vendita) se in ‘quantità’ è presente un valore non positivo! Il dipendente inserisce il proprio codice personale nelle tabelle di vendita. Non posso vendere un prodotto la cui quantità in magazzino è uguale a zero!

36. Scelta degli identificatori principali Nel modello relazionale gli identificatori principali (chiavi primarie) vengono usati per stabilire legami tra dati in relazioni diverse. Per ogni entità si è creato appositamente un identificatore che: non può contenere valori NULL perché, se così fosse, non garantirebbe l’accesso a tutte le occorrenze dell’entità corrispondente; in quanto identificatore, non può ripetersi all’interno dello stesso concetto; è un identificatore interno, cioè è costituito solo da attributi dell’entità stessa; è formato da un solo attributo (o al massimo 2), in modo da facilitare le operazioni di join e da ridurre le dimensioni degli indici.

37. Schema E R ristrutturato

38. Schema logico

39. Documentazione di schemi logici Esiste un vincolo di integrità referenziale tra l’attributo “SupportoID” della relazione “tblVideogioco” e l’attributo “SupportoID” della relazione “tblSupporto”. Esiste un vincolo di integrità referenziale tra l’attributo “FornitoreID” delle relazione “tblFornitoreVideogioco” e l’attributo “FornitoreID” della relazione “tblFornitore”; Inoltre esiste un vincolo di integrità referenziale tra gli attributi “VideogiocoID” e “ConsoleID” della relazione “tblFornitoreVideogioco” e gli attributi “VideogiocoID” e “ConsoleID” della relazione “tblVideogioco”. “VideogiocoID”, “ConsoleID” e “FornitoreID” della relazione “tblFornitoreVideogioco” non sono sufficienti a determinare una chiave primaria in quanto uno stesso videogioco può essere fornito da uno stesso fornitore nell’arco di un periodo  si aggiunge l’attributo “Data” alla chiave primaria. Esiste un vincolo di integrità referenziale tra l’attributo “CittaID” della relazione “tblFornitore” e l’attributo “CittaID” della relazione “tblCitta”. Esiste un vincolo di integrità referenziale tra l’attributo “StatoID” della relazione “tblCitta” e l’attributo “StatoID” della relazione “tblStato”.