progetto di un database per un negozio di videogiochi

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

description

università degli studi di Trieste corso di laurea triennale in ingegneria informatica. progetto di un database per un negozio di videogiochi. Negozio di videogiochi Si vuole realizzare un database per la gestione di un negozio di vendita videogiochi . - PowerPoint PPT Presentation

Transcript of progetto di un database per un negozio di videogiochi

Page 1: progetto di un database per un negozio  di videogiochi

progetto di un database per un negozio

di videogiochi

università degli studi di Triestecorso di laurea triennale in ingegneria informatica

Page 2: progetto di un database per un negozio  di videogiochi

Negozio di videogiochiNegozio di videogiochiSi 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.

Page 3: progetto di un database per un negozio  di videogiochi

Glossario dei terminiGlossario dei termini

Termine Descrizione Sinonimi Collegamenti

VideogiocoVideogioco per console e per pc che il cliente può comprare

Gioco Dipendente, fornitore

GuidaGuida pratica per la soluzione e i trucchi di un videogioco

Dipendente, fornitore

Accessorio Componente aggiuntivo ad una console o ad un computer

Fornitore, dipendente

Console Oggetto che permette di giocare ad un videogioco

Modello Fornitore, dipendente

Fornitore Società che fornisce i prodotti al negozio

Videogioco, console, guida, accessorio

Dipendente Persona che lavora nel negozio Videogioco, console, guida, accessorio

Page 4: progetto di un database per un negozio  di videogiochi

Strutturazione dei requisitiStrutturazione dei requisitiFrasi di carattere generale

•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.

Frasi relative al dipendente

•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.

Frasi relative al fornitore

•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.

Page 5: progetto di un database per un negozio  di videogiochi

Frasi relative al videogioco

•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.

Frasi relative alla console

•Le console possono essere portatili o per tv. •Ogni console possiede i suoi giochi.•Per ogni console si vogliono memorizzare i dati relativi al codice prodotto, al nome, la versione, il prezzo, la casa produttrice e la quantità.

Frasi relative all’ accessorio

•Per ogni accessorio si vuole memorizzare il codice prodotto, il tipo (se joystick, joypad, ecc.), a quale console si riferisce, il prezzo, la quantità.

Frasi relative alla guida

•Per ciascuna guida al gioco si vuole memorizzare il titolo, il prezzo, la quantità e a quale console si riferisce. •La guida può far riferimento anche a più console.

Page 6: progetto di un database per un negozio  di videogiochi

Operazioni sui datiOperazioni sui dati

1. Inserimento dati anagrafici di un fornitore e di un dipendente (circa 1 volta l’anno)

2. Inserimento dati console, videogioco, accessorio e guida (circa 3 volte al mese)

3. Modifica dati anagrafici di un fornitore e di un dipendente (circa 1 volta l’anno)

4. Modifica dati console, videogioco, guida e accessorio (circa 2 volte al mese)

5. Visualizzare tutti i dati di un fornitore (circa 2 volte al mese)

6. Dato il titolo del videogioco visualizzare tutti i suoi dati (circa 50 volte al giorno)

7. 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)

8. Dato il tipo di accessorio visualizzare tutti i dati e a che console si riferisce (circa 1 volta al giorno)

9. Dato il titolo di una guida visualizzare tutti i suoi dati (circa 5 volte a settimana)

10. 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)

11. Classifica dei dipendenti visualizzando oltre i dati relativi al dipendente anche la quantità di videogiochi venduti tra due date (circa 1 volta al mese )

12. Classifica dei videogiochi in base alla quantità venduta tra due date (circa 1 volta alla settimana)

13. Classifica delle console più vendute in un intervallo di date (circa 1 volta al mese)

14. Classifica dei dipendenti visualizzando, oltre i dati del cliente, anche il fatturato di vendita dei videogiochi tra due date(1 volta al mese)

Page 7: progetto di un database per un negozio  di videogiochi

PROGETTAZIONE CONCETTUALEPROGETTAZIONE CONCETTUALESchema scheletroSchema scheletro

Strategia di progetto usata

progettazione mista

•Suddivisione in sottoproblemi

• Raffinamenti successivi

VIDEOGIOCO CONSOLE GUIDA ACCESSORIO

FORNITORE

DIPENDENTE

VENDITA

FORNITURA

Page 8: progetto di un database per un negozio  di videogiochi

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.

VIDEOGIOCOSUPPORTO

CASA PRODUTTRICE

GENERE

TIPO SUPPORTO

PRODUZIONE TIPO GENERE

CONSOLERIFERITO

Page 9: progetto di un database per un negozio  di videogiochi

Raffinamento dell’entità console:

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.

→ Per ogni console si conoscono i dati relativi al numero di serie, nome, il prezzo e la quantità.

CONSOLE VERSIONECASA

PRODUTTRICETIPO

VERSIONEPRODUZIONE

PORTATILETV

La console è prodotta da una casa produttrice

Page 10: progetto di un database per un negozio  di videogiochi

Raffinamento dell’entità guida e accessorio:

GUIDACONSOLE ASSOCIATA

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.

Un accessorio è associato ad una determinata console (per esempio presa scart per playstation 2).

ACCESSORIOASSOCIATO

C ACONSOLE

Di ciascuna guida al gioco si conosce il titolo, il prezzo e la quantità disponibile a magazzino.

Page 11: progetto di un database per un negozio  di videogiochi

Raffinamento dell’entità fornitore e relazioni con videogioco, console, guida e accessorio

Il fornitore, inteso come società, risiederà in una città precisa di uno stato. Per esempio, Tecnogroup s.p.a., Roma, Italia.

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.FORNITORESEDE

POSSIEDE

FORNITURA

VIDEOGIOCO CONSOLE GUIDA ACCESSORIO

STATO

CITTA’

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.

Page 12: progetto di un database per un negozio  di videogiochi

L’entità dipendente e la relazione vendita dei prodotti

VIDEOGIOCO CONSOLE GUIDA ACCESSORIO

DIPENDENTE

VENDITA

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.

Il dipendente al momento della vendita deve inserire il suo codice personale per un eventuale identificazione successiva.

Page 13: progetto di un database per un negozio  di videogiochi

Schema concettuale finaleSchema concettuale finale

VIDEOGIOCOSUPPORTO

GENERE

TIPO SUPPORTO

TIPO GENERE

CONSOLE

VERSIONE

CASA PRODUTTRICE

TIPO VERSIONE

PRODUZIONE

PORTATILETV

RIFERITO GUIDA

ACCESSORIO

ASSOCIATO C A

ASSOCIATA

FORNITORE

SEDE

FORNITURA

DIPENDENTE

VENDITA

STATOPOSSIEDE

CITTA’

Page 14: progetto di un database per un negozio  di videogiochi

ANALISIANALISI DELLEDELLE ENTITA’ENTITA’FORNITORE

FornitoreIDE’ il codice univoco che identifica il fornitore;è candidato ad essere chiave primaria dell’entità “fornitore”.

Nome Definisce il nome del fornitore inteso come società – azienda.

Telefono E’ il numero di telefono del fornitore. Attributo multivalore.

Indirizzo E’ il sito dove si trova la società del fornitore. Attributo composto.

CITTA’

CittàIDE’ il codice univoco che identifica la città dove lavora il fornitore; è candidato ad essere chiave primaria dell’entità “città”.

Nome Definisce il nome della città.

STATO

StatoIDE’ il codice univoco che identifica lo stato dove si trova la città in cui lavora il fornitore; è candidato ad essere chiave primaria dell’entità “stato”.

Nome Definisce il nome dello stato.

Page 15: progetto di un database per un negozio  di videogiochi

VIDEOGIOCO

VideogiocoIDE’ il codice univoco che identifica il videogioco univocamente; è candidato ad essere chiave primaria dell’entità “videogioco”.

Titolo E’ il titolo del videogioco.

Trama Informazioni della storia del videogioco.

Anno E’ l’anno in cui il videogioco è uscito in commercio.

Prezzo Rappresenta il costo del videogioco.

Quantità Rappresenta il numero di elementi presenti a magazzino.

CASA PRODUTTRICE

CasaprodIDE’ il codice univoco che identifica la casa produttrice; è candidata ad essere chiave primaria dell’entità “casa produttrice”.

Nome E’ il nome della casa produttrice.

GENERE

GenereIDE’ il codice che identifica univocamente il genere; è candidata ad essere chiave primaria dell’entità “genere”.

Nome E’ il genere di appartenenza di un videogioco; ad esempio sportivo, picchiaduro ecc.

Page 16: progetto di un database per un negozio  di videogiochi

SUPPORTO

SupportoIDE’ il codice univoco che identifica il tipo di supporto;è candidata ad essere chiave primaria dell’entità “supporto”.

Tipo Descrive il tipo di supporto (Dvd, Blue Rey ecc.)

CONSOLE ConsoleID E’ il codice univoco che identifica la console; è candidata ad essere chiave primaria

dell’entità “console”.

Nome Definisce il nome della console.

Quantità Rappresenta il numero di elementi presenti a magazzino.

Prezzo Rappresenta il costo della console in euro.

PORTATILENessun attributo.

TVNessun attributo.

VERSIONEVersioneID E’ il codice univoco che identifica la versione di una console; è candidata ad essere

chiave primaria dell’entità “versione”.

Nome E’ il nome della versione di una console. Per esempio slim, original, ecc.

Page 17: progetto di un database per un negozio  di videogiochi

ACCESSORIO AccessorioID E’ il codice univoco che identifica l’accessorio; è candidato ad essere chiave

primaria dell’entità “accessorio”.

Prezzo E’ il costo dell’accessorio in euro.

Quantità Rappresenta la quantità a magazzino dell’accessorio.

Tipo Definisce la tipologia dell’accessorio.

DIPENDENTEDipendenteID E’ il codice univoco che identifica il dipendente del negozio; è candidato ad essere

chiave primaria dell’entità “dipendente”.

Nome E’ il nome proprio del dipendente.

Cognome E’ il cognome del dipendente.

Sesso Maschio o Femmina.

Indirizzo E’ la residenza del dipendente. Attributo composto.

Telefono E’ il numero di telefono del dipendente. Attributo multivalore.

Email E’ l’indirizzo di posta elettronica del dipendente.

Ruolo Rappresenta il ruolo all’interno del negozio (venditore, tecnico ecc.) Attributo multivalore.

Page 18: progetto di un database per un negozio  di videogiochi

GUIDAGuidaID E’ il codice univoco che identifica la guida; è candidata ad essere chiave primaria

dell’entità “guida”.

Titolo E’ il titolo della guida.

Prezzo E’ il costo in euro della guida.

Quantità Rappresenta il numero di copie presenti in negozio della guida.

Page 19: progetto di un database per un negozio  di videogiochi

ANALISI DELLE RELAZIONI E DELLA CARDINALITA’ANALISI DELLE RELAZIONI E DELLA CARDINALITA’

POSSIDE

Collega l’entità “stato” con l’entità “città”.

CardinalitàUNO A MOLTI : una città può risiedere in un solo stato ma uno stato possiede più città.

SEDECollega l’entità “fornitore” con l’entità “città”. Rappresenta la città dove ha sede l’azienda fornitrice

CardinalitàUNO A MOLTI : un fornitore ha sede in una sola città ma in quella città ci possono essere più fornitori.

FORNITURACollega l’entità “”fornitore” con le entità “videogioco”, con l’entità “console”, con l’entità “guida” e con l’entità “accessorio”. Relazione quinquennaria.

CardinalitàMOLTI A MOLTI : un fornitore può fornire uno o più prodotti e un prodotto può essere fornito da uno o più fornitori.

Data E’ la data in cui avviene la fornitura.

Quantità E’ il numero di pezzi di un prodotto fornito.

Page 20: progetto di un database per un negozio  di videogiochi

TIPO SUPPORTO

Collega l’entità “supporto” con l’entità “videogioco”.

CardinalitàUNO A MOLTI : un videogioco ha uno e uno solo tipo di supporto ma un tipo di supporto può essere associato a più videogiochi.

TIPO GENERE

Collega l’entità “videogioco” all’entità “genere”.

CardinalitàUNO A MOLTI : ogni videogioco è assegnato ad un solo genere mentre un genere può essere associato a più videogiochi.

PRODUZIONE

Collega l’entità “casa produttrice” all’entità “videogioco” e all’entità “console”. Relazione ternaria.

CardinalitàUNO A MOLTI : una casa produttrice produce uno o più videogiochi (oppure console) ma un videogioco (oppure una console) viene prodotta da una sola casa produttrice.

Page 21: progetto di un database per un negozio  di videogiochi

RIFERITO

Collega l’entità “videogioco” con l’entità “console”.

CardinalitàMOLTI A MOLTI :un videogioco può fare riferimento a una o più console e una console può avere uno o più giochi.

ASSOCIATA

Collega l’entità “console” all’entità “guida”.

CardinalitàMOLTI A MOLTI : una guida può far riferimento a una o più console e una console può essere associata a una o più guide.

ASSOCIATO C – A

Collega l’entità “console” all’entità “accessorio”.

CardinalitàMOLTI A MOLTI : un tipo di accessorio può far riferimento ad una o più console e quella console può essere associata ad uno o più accessori.

TIPO VERSIONE

Collega l’entità “console” all’entità “versione”.

CardinalitàMOLTI A MOLTI : una console può avere una o più versioni e una versione può riguardare una o più console.

Page 22: progetto di un database per un negozio  di videogiochi

VENDITACollega l’entità “dipendente” alle entità “videogioco”, “console”, “guida” e “accessorio”. Relazione quinquennaria.

CardinalitàMOLTI A MOLTI : un dipendente può vendere uno o più prodotti e un prodotto può essere venduto da più dipendente.

Data E’ la data in cui avviene una vendita.

Quantità Rappresenta il numero di pezzi venduti.

Page 23: progetto di un database per un negozio  di videogiochi

Business RulesBusiness Rules

Page 24: progetto di un database per un negozio  di videogiochi

Schema E R finale con attributi e cardinalitàSchema E R finale con attributi e cardinalità

VIDEOGIOCOSUPPORTO

GENERE

TIPO SUPPORTO

TIPO GENERE

CONSOLE

VERSIONE

CASA PRODUTTRICE

TIPO VERSIONE

PRODUZIONE

PORTATILETV

RIFERITO GUIDA

ACCESSORIO

ASSOCIATO C A

ASSOCIATA

FORNITORE

SEDE

FORNITURA

DIPENDENTE

VENDITA

ConsoleID

FornitoreID

Nom

e

Telefono

CittàID

Nome

StatoID

Nom

e

VideogiocoID

Titolo

Trama

Anno

CasaprodID

Nome

GenereID

Nome

SupportoID

Tipo

Nome

AccessorioID

Prezzo

Quantità

Tipo

GuidaID

Titolo

Prezzo

Quantità

VersioneID

Nome

DipendenteID

Nom

eC

ognome

Sesso

Telefono

Em

ail

Data

Data(1,N)

Indirizzo (1,N)

(1,N)

(1,1)

(1,N)

(1,1)

(1,N)

(1,N)

(1,N)

(1,N)

(1,N)

(1,N)

(1,N) (1,1)

(1,N) (1,1)

(1,1)

(1,N)

(1,N)

(1,N)

(1,1)

(1,N)

(1,N)

(0,N)

(1,N)

(1,N)

(1,N)

STATO

CITTA’

POSSIEDE

Quantità

Prezzo

Quantità

Prezzo

Indirizzo

Quantità

Ru

olo

(1,N)

(1,N)

(1,N)

(1,N)

(1,N)

Page 25: progetto di un database per un negozio  di videogiochi

PROGETTAZIONE LOGICA: PROGETTAZIONE LOGICA: tavola dei volumi

Concetto Volume

Fornitore 20

Città 20

Stato 10

Dipendente 5

Accessorio 50

Videogioco 2000

Console 10

Guida 20

Supporti 10

Genere 10

Casa produttrice 1000

Versioni 20

Tv (Console) 6

Portatili (Console) 4

Concetto Volume

Sede 20

Possiede 20

Fornitura 1080

Vendita 1080

Tipo supporto 2000

Tipo genere 2000

Produzione 1010

Riferito 2000

Tipo versione 10

Associata 20

Associato C A 50

Nella tavola dei volumi vengono riportati tutti i concetti dello schema con il volume (numero di occorrenze) previsto a regime.

Entità

Relazioni

Page 26: progetto di un database per un negozio  di videogiochi

Tavola delle operazioni

Operazione Tipo Frequenza

Inserimento dati anagrafici di un fornitore e di un dipendente I 1 / anno

Inserimento dati console, videogioco, accessorio e guida I 3 / mese

Modifica dati anagrafici di un fornitore e di un dipendente

I 1 / anno

Modifica dati console, videogioco, guida e accessorio I 2 / mese

Visualizzare tutti i dati di un fornitore B 2 / mese

Dato il titolo del videogioco visualizzare tutti i suoi dati B 50 / giorno

Dato il nome di una console visualizzare tutti i dati e tutte le versioni disponibili con i relativi prezzi e quantità disponibile

B 1 / giorno

Dato il tipo di accessorio visualizzare tutti i dati e a che console si riferisce B 1 / giorno

Dato il titolo di una guida visualizzare tutti i suoi dati B 5 / settimana

Vendita di un videogioco I 50 / giorno

Classifica dei dipendenti visualizzando oltre i dati relativi al dipendente anche la quantità di videogiochi venduti tra due date

B 1 / mese

Classifica dei videogiochi in base alla quantità venduta tra due date B 1 / settimana

Classifica delle console più vendute in un intervallo di date B 1 / mese

Classifica dei dipendenti visualizzando, oltre i dati del cliente, anche il fatturato di vendita dei videogiochi tra due date

B 1 / mese

Vendita di una console I 1 / giorno

Vendita di una guida I 1 / giorno

Vendita di un accessorio I 2 / settimana

Page 27: progetto di un database per un negozio  di videogiochi

Schema di operazione – tavola degli accessi

CONCETTO COSTRUTTO ACCESSI TIPO

Videogioco Entità 1 Lettura

Tipo supporto Relazione 2 Lettura

Supporto Entità 2 Lettura

Tipo genere Relazione 1 Lettura

Genere Entità 1 Lettura

Riferito Relazione 2 Lettura

Console Entità 2 Lettura

Produzione Relazione 1 Lettura

Casa produttrice

Entità 1 Lettura

VIDEOGIOCOSUPPORTO

GENERE

TIPO SUPPORTO

TIPO GENERE

CONSOLE

CASA PRODUTTRICE

PRODUZIONE

RIFERITO

ConsoleID

VideogiocoID

Titolo

Trama

Anno

CasaprodID

Nome

GenereID

Nome

SupportoID

Tipo

Nome

(1,N) (1,1)

(1,N) (1,1)

(1,1)

(1,N)

(1,N)

(1,N)

Quantità

Prezzo

QuantitàPrezzo

OPERAZIONE : Dato il titolo del videogioco visualizzare tutti i suoi dati

In media un titolo di videogioco è venduto per 2 console.

Un titolo di videogioco ha un unico genere

Un titolo di videogioco in media ha 2 supporti perché è venduto per 2 console diverse

Un titolo di videogioco ha una sola casa produttrice

Page 28: progetto di un database per un negozio  di videogiochi

Eliminazione delle generalizzazioni

CONSOLE

TIPO VERSIONE

PORTATILETV

RIFERITO

ASSOCIATO C A

ASSOCIATA

ConsoleID

Nome

Quantità

Prezzo

CONSOLE

TIPO VERSIONE

RIFERITO ASSOCIATO C A

ASSOCIATA

ConsoleID

Nome

Quantità

PrezzoPortatilePortatile

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ì.

Ristrutturazione dello schema E-R :

Page 29: progetto di un database per un negozio  di videogiochi

Ristrutturazione dello schema E-R : Partizionamento dell’entità videogioco

VIDEOGIOCO CONSOLERIFERITO(1,N) (1,N)

ConsoleID

VideogiocoID

Titolo

Trama

Anno

NomeQuantità

PrezzoQuantità

Prezzo

L’entità “videogioco” viene partizionata in dueentità “dati videogioco” e “videogioco” separandocosì i suoi attributi che: 1. vengono acceduti da operazioni diverse2. 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 ilconcetto operando sui suoi attributi.

Soluzione: si decide di accorpare gli attributi“quantità” e “prezzo” nell’ entità “videogioco” e gliattributi “videogiocoID”, “titolo”, “”anno” e “trama”nell’entità “dati videogioco”.La chiave primaria dell’entità “videogioco” è unachiave composta dagli attributi “VideogiocoID” e“ConsoleID” che sono anche le due chiavi esternedella stessa entità.

VIDEOGIOCO

CONSOLE

RIFERITO

VideogiocoID

Titolo

Tram

a

Anno Q

uantità

Prezzo

DATIDATI

VIDEOGIOCO

(1,N) (1,1) (1,1)

Page 30: progetto di un database per un negozio  di videogiochi

Ristrutturazione dello schema E-R :

CONSOLE

VERSIONETIPO

VERSIONE

ConsoleID

Nome

VersioneID

Nome

(1,N)

(1,N)

Quantità

Prezzo

CONSOLE

VERSIONE

TIPO VERSIONEConsoleID

Nome

Ver

sion

eID

Nom

e

(1,1)

(1,N)

Quantità

Prezzo

DATI CDATI CONSOLE

(1,N) (1,1)

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à.

Partizionamento dell’entità console

Page 31: progetto di un database per un negozio  di videogiochi

CONSOLE ACCESSORIOASSOCIATO

C A(1,N) (1,N)

AccessorioID

Quantità

Tipo

Prezzo

ConsoleID

Nome

Portatile

Ristrutturazione dello schema E-R :

Partizionamento dell’entità accessorio

TIPO ACCESSORIO

ACCESSORIOTIPO(1,N) (1,1)

AccessorioID

Qu

antità

Tipo

Pre

zzo

TIPO

DATI CONSOLE

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à.

Page 32: progetto di un database per un negozio  di videogiochi

Partizionamento delle relazioni vendita e fornitura

Ristrutturazione dello schema E-R :

DIPENDENTE

VENDITA A

Dip

end

en

teID

Nom

eC

og

no

me

Sesso

Te

lefo

no

Em

ail

Data

Indirizzo

VENDITA C VENDITA G

VENDITA VData

Data

Data

Quantità

Quantità

Quantità Quantità

DIPENDENTE

VENDITA

Dip

en

de

nte

IDN

om

eC

og

no

me

Se

sso

Te

lefo

no

Em

ail

Data

Ind

irizzo

Quantità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.

FORNITORE

FORNITURAF

ornitoreID

Nom

e

Telefono

Data

Indirizzo

(1,1)

(1,N)

Quantità

FORNITORE

Fo

rnito

reID

No

me

Te

lefo

no

Ind

irizzo

FORNITURA A

Data

FORNITURA CFORNITURA

G

FORNITURA VData

Data

Data

Quantità

Quantità

Quantità Quantità

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.

Page 33: progetto di un database per un negozio  di videogiochi

attributi composti e multivaloreRistrutturazione dello schema E-

R :

CONCETTO ATTRIBUTO SOLUZIONE ADOTTATA

Dipendente (entità) Telefono Bisogna conoscere ALMENO un numero di telefono del dipendente. Tuttavia ai fini dell’applicazione può essere utile registrare anche solo due numeri di telefono; l’attributo “telefono” viene diviso in “cellulare” e “casa”, che diventano 2 attributi distinti dell’entità “dipendente”. Se fosse necessario memorizzare più numeri di telefono, la ristrutturazione dell’attributo passa attraverso la definizione di un’ulteriore entità e di una relazione uno a molti (per un dipendente fino a n numeri di telefono).

Fornitore (entità) Telefono L’entità “fornitore” deve avere ALMENO un numero di telefono; poiché i numeri di telefono necessari ai fini dell’applicazione si suppone possano essere soltanto due (fisso e mobile), l’attributo viene diviso in due attributi semplici (“cellulare” e “aziendale”) che vengono accorpati all’entità “fornitore”; nel caso fosse necessario memorizzare più numeri di telefono, la ristrutturazione dell’attributo passa attraverso la definizione di un’ulteriore entità (telefono) e di una relazione uno a molti.

Dipendente (entità) Ruolo Il dipendente possiede un ruolo all’interno del negozio e quel ruolo può essere associato ad uno o più dipendenti; la ristrutturazione dell’attributo passa attraverso la definizione di un’ulteriore entità (ruolo) e di una relazione uno a molti.

Eliminazione degli attributi multivalore

Page 34: progetto di un database per un negozio  di videogiochi

Eliminazione degli attributi composti

CONCETTO ATTRIBUTO SOLUZIONE ADOTTATA

Dipendente (entità) Indirizzo L’ indirizzo del dipendente viene suddiviso nei seguenti attributi :• Via• Città• Provincia• Cap.

Solo l’attributo “Via” viene accorpato nell’entità “Dipendente”;

Gli attributi “Città”, “Provincia” e “Cap” vengono trasformati in 3 entità distinte per evitare ridondanze nell’entità “dipendente”.

Fornitore (entità) Indirizzo L’indirizzo del fornitore viene suddiviso nei seguenti attributi che vengono accorpati nell’entità stessa:• Via• numero civico

Page 35: progetto di un database per un negozio  di videogiochi

Ristrutturazione dello schema E-R :

BUSINESS RULES REGOLE DI VINCOLO (1), (2) e (3)

“Il dipendente non deve vendere una quantità nulla o negativa”

DIPENDENTE

VENDITA A

Dip

end

en

teID

Nom

eC

og

no

me

Sesso

Te

lefo

no

Em

ail

Data

Indirizzo

VENDITA CVENDITA G

VENDITA VData

Data

DataQuantità

Quantità

Quantità

Quantità

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, al momento della vendita di un prodotto, deve inserire il proprio codice personale”

“Il dipendente deve vendere solo prodotti disponibili”

Il dipendente inserisce il proprio codice personale nelle tabelle di vendita.

Non posso vendere un prodotto la cui quantità in magazzino è uguale a zero!

Page 36: progetto di un database per un negozio  di videogiochi

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.

Page 37: progetto di un database per un negozio  di videogiochi

Schema E R ristrutturatoSchema E R ristrutturato

VIDEOGIOCO RIFERITO

Vid

eog

iocoID

Titolo

Tram

a

Ann

o

Qu

antità

Prezzo

DATIDATI

VIDEOGIOCO

(1,N) (1,1) (1,1)CONSOLE

VERSIONE

TIPO VERSIONE

ConsoleIDNome

Ver

sion

eID

No

me

(1,1)

(1,N)

Qu

antità

Prezzo

DATI CDATI CONSOLE

(1,N) (1,1)

ACCESSORIOTIPO

ACCESSORIOTIPO

(1,N)(1,1)

AccessorioID

Qu

antità

Tipo

Prezzo

DIPENDENTE

VENDITA A

Dip

ende

nteIDN

om

eC

og

nom

eS

esso

Ce

llula

reE

ma

il

Data

VENDITA C VENDITA G

VENDITA VData

Data

Data

Quantità

Quantità

Quantità Quantità

ViaCittà

ProvinciaCap

Ca

sa

(1,N) (1,N)

(1,N) (1,N)

Portatile

(1,N)

ASSOCIATO C A

(1,1)(1,N)

(1,N)

(1,N)

(1,N)

GUIDAASSOCIATA

Gu

idaID

Titolo

Prezzo

Qu

antità

(1,N)

(1,N)

CASA PRODUTTRICE

PRODUZIONE

CasaprodID

Nome

(1,N)

(1,1)(1,1)

SUPPORTOTIPO

SUPPORTO

SupportoID

Tipo

(1,N) (1,1)

GENERETIPO GENERE

GenereID

Nome

(1,N)(1,1)

(1,N)SEDE

CittàID

Nome

Sta

toID

No

me

(1,N)

(1,1)

(1,N)

STATO

CITTA’

POSSIEDE

FORNITORE

Fo

rnitore

IDN

om

e

Azie

ndale

FORNITURA A

Data

FORNITURA CFORNITURA

G

FORNITURA VData

Data

Data

Quantità

Quantità

Quantità Quantità

(1,N)

(1,N)

(1,N)(1,N)

(1,1) Via

Nu

mero

C

Ce

llula

re

(1,N)

(1,N)

(1,N)

(1,N)

TIPO RUOLO

RUOLO

(1,1)

(1,N)

RuoloID Tipo

Ora

Ora

Ora

Ora

CITTADIP

PROVINCIA

CAP

RESIDENZA POSSIEDE

ASSOCIATA

ProvinciaID

Nome

CittaDipID Nome

CapID Cap

(1,1)

(1,N)

(1,N)

(1,1)

(1,1)

(1,1)

Page 38: progetto di un database per un negozio  di videogiochi

tblStato

PK StatoID

Nome

tblCitta

PK CittaID

NomeFK1 StatoID

tblFornitore

PK FornitoreID

Nome Via NumeroCivico Cellulare AziendaleFK1 CittaID

tblVideogioco

PK,FK1 VideogiocoIDPK,FK2 ConsoleID

Prezzo QuantitàFK3 SupportoID

tblDatiVideogioco

PK VideogiocoID

Titolo Anno TramaFK1 CasaprodIDFK2 GenereID

tblDatiConsole

PK ConsoleID

Nome PortatileFK1 CasaprodID

tblConsole

PK,FK1 ConsoleIDPK,FK2 VersioneID

Prezzo Quantita

tblVersione

PK VersioneID

Nome

tblCasaProduttrice

PK CasaprodID

Nome

tblGenere

PK GenereID

Nome

tblGuida

PK GuidaID

Titolo Prezzo Quantità

tblDatiConsoleGuida

PK,FK2 GuidaIDPK,FK1 ConsoleID

tblAccessorio

PK,FK1 ConsoleIDPK,FK2 AccessorioID

Prezzo Quantita

tblTipoAccessorio

PK AccessorioID

Tipo

tblFornitoreConsole

PK,FK2 ConsoleIDPK,FK2 VersioneIDPK,FK1 FornitoreIDPK Data

Quantita

tblFornitoreVideogioco

PK,FK2 VideogiocoIDPK,FK2 ConsoleIDPK,FK1 FornitoreIDPK Data

Quantita

tblFornitoreGuida

PK,FK1 FornitoreIDPK,FK2 GuidaIDPK Data

Quantita

tblFornitoreAccessorio

PK,FK2 AccessorioIDPK,FK2 ConsoleIDPK,FK1 FornitoreIDPK Data

Quantita

tblDipendente

PK DipendenteID

Cognome Nome Sesso Via Citta Provincia Cap Cellulare Casa EmailFK1 RuoloIDFK2 CittaDipID

tblRuolo

PK RuoloID

Tipo

tblDipendenteVideogioco

PK DataPK Ora

FK1 DipendenteIDFK2 VideogiocoIDFK2 ConsoleID Quantita

tblDipendenteConsole

PK DataPK Ora

FK1 DipendenteIDFK2 ConsoleIDFK2 VersioneID Quantita

tblDipendenteGuida

PK DataPK Ora

FK1 DipendenteIDFK2 GuidaID Quantita

tblDipendenteAccessorio

PK DataPK Ora

FK1 DipendenteIDFK2 AccessorioIDFK2 ConsoleID Quantita

tblSupporto

PK SupportoID

Tipo

tblCAP

PK CapID

CAP

tblProvinciaDip

PK ProvinciaID

Nome

tblCittaDip

PK CittaDipID

NomeFK1 ProvinciaID

Page 39: progetto di un database per un negozio  di videogiochi

Documentazione di schemi logici

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”.

FornitoreID Nome Via Numero civico Cellulare Aziendale

VideogiocoID ConsoleID FornitoreID Data Quantita

VideogiocoID ConsoleID Prezzo Quantita SupportoID

CittaID

tblFornitore

tblFornitoreVideogioco

tblVideogioco

CiitaID Nome StatoID

StatoID Nome

tblCitta

tblStato

SupportoID Tipo

tblSupporto

Esiste un vincolo di integrità referenziale tra l’attributo “SupportoID” della relazione “tblVideogioco” e l’attributo “SupportoID” della relazione “tblSupporto”.

“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”.