PROGETTO BASI DI DATI

Gestione di un negozio virtuale di videogiochi

Salvo Polizzi Salamone

Dipartimento di Matematica e Informatica

Università di Catania
Italia
2
Indice

Introduzione 5

1 Progettazione Concettuale 7
1.1 Analisi dei Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.1 Requisiti in linguaggio naturale . . . . . . . . . . . . . . . . 7
1.1.2 Glossario dei termini . . . . . . . . . . . . . . . . . . . . . . 8
1.1.3 Raggruppamento dei requisiti . . . . . . . . . . . . . . . . . 8
1.1.4 Generalizzazioni . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.5 Definizione delle operazioni . . . . . . . . . . . . . . . . . . 10
1.2 Progettazione Schema E-R . . . . . . . . . . . . . . . . . . . . . . 11
1.2.1 Schema Scheletro . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.2 Raffinamenti . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.3 Vincoli e attributi derivabili . . . . . . . . . . . . . . . . . . 18
1.2.4 Dizionario dei dati . . . . . . . . . . . . . . . . . . . . . . . 18

2 Progettazione Logica 21
2.1 Stime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.1 Tabella dei volumi . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.2 Tabella delle operazioni . . . . . . . . . . . . . . . . . . . . 22
2.2 Schemi delle operazioni . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1 Schema Operazione 1 . . . . . . . . . . . . . . . . . . . . . 23
2.2.2 Schema operazione 2 . . . . . . . . . . . . . . . . . . . . . 23
2.2.3 Schema operazione 3 . . . . . . . . . . . . . . . . . . . . . 24
2.2.4 Schema operazione 4 . . . . . . . . . . . . . . . . . . . . . 26
2.2.5 Schema Operazione 5 . . . . . . . . . . . . . . . . . . . . . 28
2.2.6 Schema Operazione 6 . . . . . . . . . . . . . . . . . . . . . 29
2.2.7 Schema Operazione 7 . . . . . . . . . . . . . . . . . . . . . 31
2.2.8 Schema Operazione 8 . . . . . . . . . . . . . . . . . . . . . 31
2.2.9 Schema Operazione 9 . . . . . . . . . . . . . . . . . . . . . 31
2.2.10 Schema Operazione 10 . . . . . . . . . . . . . . . . . . . . 32
2.2.11 Schema Operazione 11 . . . . . . . . . . . . . . . . . . . . 33
2.3 Eliminazione Gerarchie . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4 Eliminazione Attributi Multivalore . . . . . . . . . . . . . . . . . . 35
2.4.1 Schema E-R finale ristrutturato . . . . . . . . . . . . . . . . 36

3
INDICE 4

2.5 Traduzione verso lo schema logico . . . . . . . . . . . . . . . . . . 38

2.5.1 Schema UML . . . . . . . . . . . . . . . . . . . . . . . . . 38

3 Progettazione Fisica 41
Introduzione

Lo scopo di tale progetto è realizzare una base di dati che possa soddisfare tutte
le richieste di un negozio virtuale di videogiochi. La progettazione della base di
dati si svilupperà in 3 fasi:
1. Progettazione Concettuale: in questa fase il nostro scopo sarà quello di
descrivere un analisi dei requisiti della base di dati e produrre uno schema
E-R che soddisfi tutti i requisiti

2. Progettazione Logica: in questa fase il nostro scopo sarà quello di ristrut-

turare lo schema E-R sulla base dei costi delle operazioni e sui volumi dei
dati e produrre uno schema logico finale.
3. Progettazione fisica: in questa fase il nostro scopo sarà quello di implementare
tabelle, trigger e operazioni previste per la base di dati

5
INTRODUZIONE 6
Parte 1

Progettazione Concettuale

1.1 Analisi dei Requisiti

L’analisi dei requisiti sarà suddivisa nelle seguenti fasi:

• Descrizione dei requisiti in linguaggio naturale

• Si produrrà un glossario dei termini individuati dall’analisi precedente

• Si decomporrà l’analisi strutturando i requisiti in brevi periodi

• Si definiranno le operazioni che dovranno essere svolte con la base di dati

1.1.1 Requisiti in linguaggio naturale

Di seguito si presenta la descrizione dei requisiti richiesti dal cliente:
Si vuole realizzare una base di dati per la gestione di un negozio virtuale di video-
giochi che riesca a gestire un certo numero di utenti che acquistano videogiochi, le
librerie e le liste dei desideri di ogni utente, il portafoglio virtuale di tali utenti e i
prezzi dei videogiochi che possono variare in base a periodi promozionali.
Ogni videogioco (circa 10000) è identificato dal nome ed è caratterizzato da prezzo,
genere e rating. I videogiochi presenti nella base di dati possono essere TRIPLA A,
caratterizzati in tal caso dalla casa produttrice, e INDIE, caratterizzati in tal caso
dal nome degli sviluppatori. La base di dati dovrà permettere di cambiare il prezzo
se vi è un periodo promozionale, o se è terminato un periodo promozionale. Ogni
gioco, inoltre, può essere acquistato una sola volta da un utente.
Ogni utente (circa 1000) è identificato da un username ed è caratterizzato da una
password, un email. Un utente, inoltre, può essere amico di un altro utente iscritto
nel sito. Per ogni amicizia si vuole salvare la data in cui è stata fatta e per ogni
utente si vuole conoscere il numero di amici che ha.
Ogni utente possiede una libreria, che è identificata da un ID ed è caratterizzata
dal numero di giochi acquistati dall’utente e da un nome che l’utente può inserire
liberamente. Inoltre si dovrà indicare l’ultima (eventuale) data di installazione e

7
PARTE 1. PROGETTAZIONE CONCETTUALE 8

l’ultima (eventuale) data di disinstallazione di un gioco contenuto nella libreria di

un utente.
Ogni utente ha a disposizione all’interno del sito il suo portafoglio virtuale per
acquistare i videogiochi presenti all’interno del sito. Tale portafoglio sarà quindi
caratterizzato dal saldo attuale e sarà identificato da un ID. La base di dati dovrà
permettere all’utente di effettuare versamenti e di conseguenza aggiornare il saldo
del portafoglio e dovrà impedire all’utente l’acquisto del videogioco se non ha ab-
bastanza liquidità nel portafoglio. Inoltre ogni utente ha a disposizione un tetto
massimo, nel suo portafoglio, di 1000€.
Ogni utente può produrre una lista di desideri, identificata da un ID e dai giochi
che si desidera acquistare. La lista dei desideri può assumere un nome a piacere
inserito dall’utente. Infine, La base di dati dovrà gestire tale lista in modo tale che
non possano essere inseriti giochi già acquistati dell’utente.
La base di dati dovrà gestire inoltre dei periodi promozionali, identificati da data
di inizio e data di fine, e caratterizzati ognuno da un nome, ad esempio "black
friday..." e da una percentuale di sconto sui giochi in promozione per quel periodo.
Durante un periodo promozionale la massima percentuale di sconto è del 15%

1.1.2 Glossario dei termini

Dall’analisi dei requisiti richiesti dal cliente riusciamo a desumere il seguente glos-
sario dei termini:

Termine Descrizione Sinonimi Collegamenti

Utente,
Gioco in vendita all’interno Libreria,
Videogioco Gioco
del negozio virtuale Lista dei desideri,
Sconto
Videogioco,
Utente Coloro che usufruiscono del negozio Libreria,
Lista dei desideri
Utente,
Libreria Videogiochi acquistati da ogni utente Videogioco,
Preferiti
Portafoglio Virtuale Metodo di pagamento all’interno del sito Utente
Utente,
Lista di videogiochi che
Lista dei desideri Videogioco,
l’utente crea per i videogiochi desiderati
Sconto
Periodo nel quale i Videogioco,
Periodo Promozionale
videogiochi di uno specifico genere sono scontati Sconto

1.1.3 Raggruppamento dei requisiti

Di seguito vengono raggruppati e decomposti i requisiti in gruppi di frasi che iden-

tificano dei concetti utilizzando i termini individuati nel glossario.
9 1.1. ANALISI DEI REQUISITI

Dati di carattere generale

Si vuole realizzare una base di dati per la gestione di un negozio virtuale di videogiochi che riesca
a gestire un certo numero di utenti che acquistano videogiochi,
le librerie e le liste dei desideri di ogni utente,
il portafoglio virtuale di tali utenti e i prezzi dei videogiochi
che possono variare in base a periodi promozionali.

Frasi relative ai videogiochi

Ogni videogioco (circa 10000) è identificato dal nome
ed è caratterizzato da prezzo, rating e genere.
I videogiochi presenti nella base di dati possono essere TRIPLA A,
caratterizzati in tal caso dalla casa produttrice,
e INDIE, caratterizzati in tal caso dal nome degli sviluppatori.
La base di dati dovrà permettere di cambiare il prezzo se è in corso un periodo promozionale
o se è terminato un periodo promozionale.
Ogni gioco, inoltre, può essere acquistato una sola volta da un utente.

Frasi relative agli utenti

Ogni utente (circa 5000) è identificato da un username ed è
caratterizzato da una password, un email e dal numero di giochi posseduti.
Un utente, inoltre, può essere amico di un altro utente iscritto nel sito.

Frasi relative alla libreria di ogni utente

Ogni utente possiede una libreria,
che è identificata da un ID ed è caratterizzata
dal numero di giochi acquistati dall’utente
e da un nome che l’utente può inserire liberamente.
Inoltre si dovrà indicare
l’ultima (eventuale) data di installazione
e l’ultima (eventuale) data di disinstallazione
di un gioco contenuto nella libreria di un utente.
PARTE 1. PROGETTAZIONE CONCETTUALE 10

Frasi relative al portafoglio virtuale di ogni utente

Ogni utente ha a disposizione all’interno del sito il suo portafoglio virtuale
per acquistare i videogiochi presenti all’interno del sito.
Tale portafoglio sarà quindi caratterizzato
dal saldo attuale e sarà identificato da un ID.
La base di dati dovrà permettere all’utente di effettuare versamenti
e di conseguenza aggiornare il saldo del portafoglio
e dovrà impedire il pagamento se
non è disponibile abbastanza liquidità.
Inoltre ogni utente ha a disposizione un tetto massimo, nel suo portafoglio, di 1000€.

Frasi relative alla lista di desideri di ogni utente

Ogni utente può produrre una lista di desideri,
identificata da un ID e contiene i giochi che si desidera acquistare.
Infine, La base di dati dovrà gestire tale lista in modo tale
che non possano essere inseriti giochi già acquistati dell’utente.

Frasi relative ai periodi promozionali

La base di dati dovrà gestire inoltre dei periodi promozionali,
identificati da data di inizio e data di fine,
e caratterizzati ognuno da un nome, ad esempio "black friday..." e da una percentuale di sconto
sui giochi in promozione per quel periodo.
Alla fine del periodo promozionale tali videogiochi dovranno ritornare al prezzo originale.

1.1.4 Generalizzazioni
Come espresso nell’analisi dei requisiti, possiamo creare una gerarchia sull’entità
videogioco, distinguendo fra videogiochi TRIPLA A, caratterizzati dalla casa pro-
duttrice, e videogiochi INDIE, caratterizzati dal nome degli sviluppatori. Possiamo
inoltre dire che tale gerarchia è totale ed esclusiva in quanto i videogiochi con-
tenuti all’interno del negozio sono tutti TRIPLA A e INDIE, e inoltre è esclusiva in
quanto un videogioco TRIPLA A non può essere INDIE e viceversa.

1.1.5 Definizione delle operazioni

Di seguito si propone un elenco delle operazioni più frequenti che si dovranno svol-
gere con la base di dati:
11 1.2. PROGETTAZIONE SCHEMA E-R

Indice Operazione
Op.1 Inserire un nuovo videogioco
Op.2 Inserire un nuovo utente
Op.3 Inserimento di acquisto di un videogioco da parte di un utente
Op.4 Stampa il numero di giochi contenuti in libreria di un utente
Op.5 Inserimento di un videogioco nella lista dei desideri di un utente
Op.6 Stampa del numero di giochi contenuti in lista dei desideri di un utente
Op.7 Inserimento di un versamento
Op.8 Inserimento di un periodo promozionale
Op.9 Inserimento di uno sconto per un videogioco
Op.10 Inserimento di un amico
Op.11 Stampa il numero di amici per ogni utente

Table 1.1: Operazioni

1.2 Progettazione Schema E-R

Procediamo adesso, tramite una strategia di progettazione top-down, a costruire

uno schema E-R finale che soddisfi tutti i requisiti visti nella sezione precedente.
Svilupperemo lo schema, quindi, partendo da uno schema scheletro e, tramite raf-
finamenti previsti per una strategia top-down, arriveremo allo schema finale.

1.2.1 Schema Scheletro

Di seguito lo schema scheletro:

PARTE 1. PROGETTAZIONE CONCETTUALE 12

Figure 1.1: SCHEMA SCHELETRO

1.2.2 Raffinamenti
Procediamo adesso, come previsto dalla strategia top-down, con i vari raffinamenti
fino ad arrivare allo schema E-R che rappresenti tutti i requisiti.

Raffinamento n.1: utente, videogioco

• Definiamo gli attributi dell’entità videogioco (anche delle entità figlie TRIPLA
A e INDIE)

• Definiamo gli attributi dell’entità utente

• Definiamo gli attributi dell’associazione amico

• Definiamo la cardinalità dell’associazione acquista

• Definiamo la cardinalità dell’associazione amico

13 1.2. PROGETTAZIONE SCHEMA E-R

Figure 1.2: Raffinamento n.1

Raffinamento n.2: libreria

• Definiamo gli attributi dell’entità libreria

• Definiamo gli attributi dell’associazione contiene

• Definiamo la cardinalità dell’associazione possiede

• Definiamo la cardinalità dell’associazione contiene

PARTE 1. PROGETTAZIONE CONCETTUALE 14

Figure 1.3: Raffinamento n.2

Raffinamento n.3: portafoglio

• Definiamo gli attributi dell’entità portafoglio
• Definiamo la cardinalità dell’associazione dispone
• Definiamo gli attributi dell’entità versamento
• Definiamo la cardinalità dell’associazione effettua
15 1.2. PROGETTAZIONE SCHEMA E-R

• Definiamo la cardinalità dell’associazione in

Figure 1.4: Raffinamento n.3

PARTE 1. PROGETTAZIONE CONCETTUALE 16

Raffinamento n.4: lista dei desideri

• Definiamo gli attributi dell’entità lista dei desideri

• Definiamo la cardinalità dell’associazione crea

• Definiamo la cardinalità dell’associazione contiene

Figure 1.5: Raffinamento n.4

Raffinamento n.5: periodo promozionale (schema E-R finale)

• Definiamo gli attributi dell’entità periodo promozionale

• Definiamo la cardinalità dell’associazione sconto

17 1.2. PROGETTAZIONE SCHEMA E-R

Figure 1.6: Schema E-R finale

PARTE 1. PROGETTAZIONE CONCETTUALE 18

1.2.3 Vincoli e attributi derivabili

Vincoli non esprimibili dallo schema E-R
Di seguito si elencano i vincoli non esprimibili dallo schema E-R, che dovranno essere
considerati nell’implementazione della base di dati

• Acquisti degli utente: un utente può acquistare un videogioco una sola volta
e inoltre se non ha abbastanza liquidità nel portafoglio non può acquistare quel
gioco. Se il saldo disponibile è sufficiente allora bisognerà aggiornare il saldo
decurtandolo sulla base del prezzo del videogioco acquistato.

• Inserimento dei giochi in lista dei desideri: un utente non può aggiungere
un gioco già acquistato in lista dei desideri

• Aggiornamento della libreria: per ogni gioco acquistato bisogna aggiornare

il numero di giochi in libreria e aggiungere il gioco comprato nei giochi con-
tenuti in libreria

• Saldo del portafoglio: il tetto massimo del saldo del portafoglio per ogni
utente è di 1000€

• Percentuali di sconto dei periodo promozionali: le percentuali di sconto

durante i periodi promozionali possono essere al più del 15%

• Prezzi dei videogiochi: quando un gioco viene inserito in sconto durante

un periodo promozionale bisogna aggiornare il prezzo scontandolo della per-
centuale prevista in quel periodo.

Attributi derivabili

Numero di giochi di libreria

Nell’entità Libreria l’attributo "num_giochi" può essere calcolato
come il numero di acquisti di videogiochi fatti dall’utente
Numero di giochi di lista dei desideri
Nell’entità Lista dei desideri l’attributo "num_giochi" può essere calcolato
come il numero di giochi contenuti nella lista
Numero di amici di utente
Nell’entità Utente l’attributo "num_amici" può essere calcolato
come il numero di amici grazie all’associazione amicizia

1.2.4 Dizionario dei dati

Di seguito si sviluppa in 2 tabelle il dizionario dei dati: per le entità indichiamo
una loro descrizione, gli attributi e gli identificatori; per le relazioni indichiamo le
entità partecipanti, una descrizione e gli attributi.
19 1.2. PROGETTAZIONE SCHEMA E-R

Entità

Entità Descrizione Attributi Identificatori

Nome,
Gioco in vendita all’interno Genere,
Videogioco Nome
del negozio virtuale rating,
Prezzo
Nome,
Genere,
Videogioco sviluppato da
TRIPLA A rating, Nome
una casa di produzione
Casa Produttrice,
Prezzo
Nome,
Genere,
Videogioco sviluppato da
INDIE rating, Nome
sviluppatori autonomi
sviluppatori (1,n),
Prezzo
Username,
Coloro che usufruiscono
Utente Password, Username
del negozio
Email
id,
Videogiochi acquistati
Libreria num_giochi, id
da ogni utente
nome
Saldo attuale dell’utente id,
Portafoglio id
all’interno del sito saldo
id,
Versamento dell’utente
Versamento data, id
nel portafoglio
denaro_versato
Lista di videogiochi che
id,
Lista dei desideri l’utente crea per id
nome
i videogiochi desiderati
Periodo nel quale data_inizio,
i videogiochi data_fine, data_inizio,
Periodo Promozionale
di uno specifico genere nome, data_fine,
sono scontati percentuale

Table 1.2: Dizionario dei dati: Entità

PARTE 1. PROGETTAZIONE CONCETTUALE 20

Relazioni

Relazione Entità Partecipanti Descrizione Attributi

Utente, Videogiochi acquistati
Acquista Data
Videogioco dall’utente
Utente, Libreria posseduta
Possiede
Libreria dall’utente
Utente, Portafoglio a disposizione
Dispone
Portafoglio dell’utente
Utente, Versamento effettuato
Effettua
Versamento dall’utente
Versamento,
In Versamento nel portafoglio
Portafoglio
Utente,
Crea Lista dei desideri creata dall’utente
Lista dei desideri
Videogioco, data_installazione,
Contiene Videogiochi contenuti in libreria
Libreria data_disinstallazione
Videogioco,
Contiene Videogiochi contenuti in lista dei desideri
Lista dei desideri
Periodo Promozionale,
Sconto Videogiochi scontati durante il periodo promozionale
Videogioco
Amico Utente Amici di un utente

Table 1.3: Dizionario dei dati: Relazioni

Parte 2

Progettazione Logica

Vedremo in questa fase di ristrutturare lo schema E-R e tradurlo, infine, nello

schema logico. Procederemo quindi dando delle stime dei volumi sulle entità e sulle
relazioni e delle stime sulle frequenze delle operazioni. Infine analizzeremo lo schema
E-R per ogni operazione ristrutturandolo analizzando ridondanze, partizionando o
accorpando entità e infine lo tradurremo nello schema logico.

2.1 Stime
Si suppongono le seguenti stime non specificate nell’analisi dei requisiti1 :

• Ogni utente acquista in media 10 giochi (10000 videogiochi/1000 utenti)

• Ogni utente fa, in media, 10 versamenti nel suo portafoglio

• Ogni lista dei desideri di un utente contiene, in media, 15 videogiochi

• La base di dati dovrà mantenere in media 20 periodo promozionali

• Ogni periodo promozionale sconta, in media, 20 videogiochi

• Ogni utente ha, in media, 10 amici

2.1.1 Tabella dei volumi

Dopo aver fatto le stime, possiamo sviluppare una tabella dei volumi, che indica il
volume di dati che si andranno a utilizzare in media.
1 Tali stime sono fatte su base mensile

21
PARTE 2. PROGETTAZIONE LOGICA 22

Concetto Tipo Volume

Utente E 1000
Videogioco E 10000
Libreria E 5000
Lista dei Desideri E 5000
Portafoglio E 5000
Versamento E 50000
Periodo Promozionale E 20
Acquista R 10000
Possiede R 5000
Dispone R 5000
Effettua R 50000
In R 50000
Crea R 5000
Contiene (libreria) R 10000
Contiene (lista desideri) R 75000
Sconto R 400
Amico R 50000

Table 2.1: Tabella dei volumi

2.1.2 Tabella delle operazioni

Sviluppiamo, quindi, la tabella delle operazioni2 . La definizione delle operazioni

si trova nella tabella 1.1.

Indice Tipo Frequenza

Op.1 I 50/m
Op.2 I 25/m
Op.3 I 100/m
Op.4 I 100/m
Op.5 I 200/m
Op.6 I 100/m
Op.7 I 10/m
Op.8 B 1/m
Op.9 I 2/a
Op.10 I 150/m
Op.11 I 2/m

Table 2.2: Tabella delle operazioni

2 Con la notazione x/m, dove x è un numero, si intende che tale operazione viene effettuata x

volte al mese
23 2.2. SCHEMI DELLE OPERAZIONI

2.2 Schemi delle operazioni

Analizzeremo adesso per ogni operazione l’insieme di concetti dello schema E-R
utilizzati nell’operazioni. Contestualmente, analizzeremo eventuali attributi ridon-
danti, eventuali accorpamenti/partizionamenti da fare fino ad arrivare allo schema
ristrutturato.

2.2.1 Schema Operazione 1

Operazione 1: Inserire un nuovo videogioco (50 volte al mese)

L’insieme di concetti utilizzati è il seguente:

Non figura in questo caso alcuna ridondanza.

2.2.2 Schema operazione 2

Operazione 2: Inserire un nuovo utente (25 volte al mese)

L’insieme di concetti utilizzati è il seguente:

PARTE 2. PROGETTAZIONE LOGICA 24

Non figura in questo caso alcuna ridondanza.

2.2.3 Schema operazione 3

Operazione 3: Acquisto di un videogioco (100 volte al mese)

In questo caso, l’inserimento di un acquisto di un utente comporta l’aggiornamento

dell’attributo ridondante "num_giochi" di libreria per quanto detto in uno dei
vincoli non esprimibili. Di conseguenza analizzeremo il costo dell’operazione con e
senza la ridondanza valutando gli accessi in lettura mensili.

Valutazione Con Ridondanza L’insieme di concetti utilizzati è il seguente:

25 2.2. SCHEMI DELLE OPERAZIONI

La tavola di accessi in questo caso è la seguente:

Concetto Costrutto Accesso Tipo

Utente E 1 L
Acquisto R 1 S
Videogioco E 1 L
Contiene R 1 S
Libreria E 1 L
Libreria E 1 S

3L + 3S = 9L · 100/m = 900L/m

Valutazione Senza Ridondanza L’insieme di concetti utilizzati è il seguente:

PARTE 2. PROGETTAZIONE LOGICA 26

La tavola di accessi in questo caso è la seguente:

Concetto Costrutto Accesso Tipo

Utente E 1 L
Acquisto R 1 S
Videogioco E 1 L
Contiene R 1 S

2L + 2S = 6L · 100/m = 600L/m
In questo caso quindi il numero di letture mensili è minore con l’eliminazione della
ridondanza. Per dare un riscontro, però, dobbiamo analizzare tutte le operazioni
nella quale è coinvolto l’attributo.

2.2.4 Schema operazione 4

Operazione 4: Stampa del numero di giochi contenuti in libreria di un utente
(100 volte al mese)

Anche in questo caso notiamo che è presente l’attributo ridondante "num_giochi".

Quindi valutiamo lo schema di operazioni prima con la ridondanza e poi senza la
ridondanza, analizzando i costi tramite una tabella di accessi.
27 2.2. SCHEMI DELLE OPERAZIONI

Valutazione Con Ridondanza L’insieme dei concetti utilizzati è il seguente:

La tavola di accessi è dunque la seguente:

Concetto Costrutto Accesso Tipo

Utente E 1 L
Possiede E 1 L
Libreria E 1 L

3L · 100/m = 300 letture mensili.

Valutazione Senza Ridondanza L’insieme dei concetti utilizzati è il seguente:

Consideriamo quanto affermato nelle stime iniziali, ovvero che un utente acquista
PARTE 2. PROGETTAZIONE LOGICA 28

in media 10 videogiochi, e di conseguenza che un utente possieda in media 10

videogiochi in libreria. Di conseguenza la tavola di accessi è la seguente:

Concetto Costrutto Accesso Tipo

Utente E 1 L
Possiede E 1 L
Libreria E 1 L
Contiene R 10 L

13L · 100/m = 1300 letture mensili.

Considerazioni finali sull’attributo ridondante Poichè l’attributo num_giochi

non viene più utilizzato in altre operazioni, possiamo concludere che conviene man-
tenere tale attributo: infatti con la ridondanza abbiamo un totale di 900 + 300 =
1200 letture mensili, mentre senza ridondanza abbiamo un totale di 600 + 1300 =
1900 letture mensili, con un risparmio quindi di 700 letture mensili

2.2.5 Schema Operazione 5

Operazione 5: Inserimento di un videogioco in lista dei desideri di un utente (200
volte al mese)

Anche in questo caso dobbiamo considerare il costo dell’operazione valutando

se mantenere o eliminare la ridondanza "num_giochi" appartenente all’entità lista
dei desideri.

Valutazione Con Ridondanza

L’insieme dei concetti utilizzati è il seguente:

La tavola di accessi è la seguente:

29 2.2. SCHEMI DELLE OPERAZIONI

Concetto Costrutto Accesso Tipo

Utente E 1 L
Lista dei desideri E 1 L
Lista dei desideri E 1 S
Contiene R 1 S

2L + 2S = 6L · 100/m = 600 letture mensili.

Valutazione senza ridondanza

L’insieme dei concetti utilizzati è il seguente:

La tavola di accessi è la seguente:

Concetto Costrutto Accesso Tipo

Lista dei desideri E 1 L
Contiene R 1 S

1L + 1S = 3L · 100/m = 300 letture mensili.

Per valutare se mantenere la ridondanza o meno analizziamo l’operazione 6 in
cui è richiesto di stampare il numero di giochi presenti in libreria.

2.2.6 Schema Operazione 6

Operazione 6: Stampa del numero di giochi contenuti in lista dei desideri di un
utente (100 volte al mese)

Valutazione Con Ridondanza

L’insieme dei concetti utilizzati è il seguente:

PARTE 2. PROGETTAZIONE LOGICA 30

La tavola di accessi è la seguente:

Concetto Costrutto Accesso Tipo

Utente E 1 L
Crea R 1 L
Lista dei desideri E 1 L

3L · 100/m = 300 letture mensili.

Valutazione Senza Ridondanza

L’insieme dei concetti utilizzati è il seguente:

Per quanto detto nelle stime dei volumi, consideriamo che in media la lista dei
desideri di ogni utente contenga 15 videogiochi
La tavola di accessi è la seguente:

Concetto Costrutto Accesso Tipo

Utente E 1 L
Crea R 1 L
Lista dei desideri E 1 L
Contiene R 15 L

18L · 100/m = 1800 letture mensili.

31 2.2. SCHEMI DELLE OPERAZIONI

Valutazione finale Ridondanza

Anche in questo caso conviene mantenere la ridondanza: infatti con la ridondanza

abbiamo un totale di 500 + 100 = 600 letture mensili contro 300 + 1600 = 1900
letture mensili con un risparmio di ben 1300 letture mensili.

2.2.7 Schema Operazione 7

Operazione 7: Inserimento di un versamento (10 volte al mese)

L’insieme dei concetti utilizzati in questa operazione è il seguente:

Non figura in questo caso alcuna ridondanza

2.2.8 Schema Operazione 8

Operazione 8: Inserimento di un periodo promozionale

L’insieme dei concetti utilizzati in questa operazione è il seguente:

Non figura in questo caso alcuna ridondanza.

2.2.9 Schema Operazione 9

Operazione 9: Inserimento di uno sconto per un videogioco

L’insieme dei concetti utilizzati in questa operazione è il seguente:

PARTE 2. PROGETTAZIONE LOGICA 32

Non figura in questo caso alcuna ridondanza.

2.2.10 Schema Operazione 10

Operazione 10: Inserisci un amicizia (150 volte al mese)

In questo caso bisogna valutare i costi della ridondanza "num_amici". L’insieme

dei concetti utilizzati in questa operazione è il seguente:

Valutazione Con Ridondanza

La tavola degli accessi considerando l’attributo num_amici è la seguente:

Concetto Costrutto Accesso Tipo

Utente E 1 L
Utente E 1 S
Amico R 1 S

1L + 2S = 5L · 150/m = 750 letture mensili.

Valutazione Senza Ridondanza

La tavola degli accessi non considerando l’attributo num_amici è la seguente:
33 2.2. SCHEMI DELLE OPERAZIONI

Concetto Costrutto Accesso Tipo

Utente E 1 L
Amico R 1 S

1L + 1S = 3L · 150/m = 450 letture mensili.

Per adesso conviene eliminare la ridondanza; ma per le considerazioni finali
dobbiamo analizzare anche la prossima operazione.

2.2.11 Schema Operazione 11

Operazione 11: Stampa il numero di amici per ogni utente (2 volte al mese)

L’insieme dei concetti utilizzati in questo caso è lo stesso visto per l’operazione
10. Valutiamo però anche in questo caso i costi con e senza ridondanza. Poichè
questa operazione deve essere fatta per ogni utente, consideriamo il volume totale
(5000 utenti).

Valutazione Con Ridondanza

Concetto Costrutto Accesso Tipo

Utente E 5000 L

5000L · 2/m = 10000 letture mensili.

Valutazione Senza Ridondanza

In questo caso, consideriamo quanto detto nelle stime, ovvero che in media ogni
utente ha 10 amici.

Concetto Costrutto Accesso Tipo

Utente E 5000 L
Amico R 50000 L

55000 letture mensili.

Valutazione Finale sulla ridondanza

E’ evidente il fatto che convenga mantenere la ridondanza: infatti i costi per man-
tenerla sono 10000 + 750 = 10750 letture mensili a fronte di 450 + 55000 = 55450
letture mensili per eliminarla.
PARTE 2. PROGETTAZIONE LOGICA 34

2.3 Eliminazione Gerarchie

L’unica gerarchia presente nello schema è quella di videogioco. Si decide in questo

caso di mantenere le entità figlie con delle associazioni. Inseriamo inoltre 2 attributi
nell’entità videogiochi, ovvero triplaa e indie, che sono dei booleani con lo scopo
di indicare se il videogioco è triplaa o meno o se è indie o meno. Lo schema si
presenterà dunque nel seguente modo:
35 2.4. ELIMINAZIONE ATTRIBUTI MULTIVALORE

2.4 Eliminazione Attributi Multivalore

Nell’entità INDIE è presente l’attributo multivalore sviluppatori. Possiamo eliminarlo
utilizzando una nuova entità sviluppatore che colleghiamo tramite un associazione
a INDIE:
PARTE 2. PROGETTAZIONE LOGICA 36

2.4.1 Schema E-R finale ristrutturato

Infine mostriamo lo schema E-R finale ristrutturato, in quanto abbiamo analizzato

tutte le operazioni e non vi sono gerarchie o identificatori da analizzare.
37 2.4. ELIMINAZIONE ATTRIBUTI MULTIVALORE

Figure 2.1: Schema E-R finale

PARTE 2. PROGETTAZIONE LOGICA 38

2.5 Traduzione verso lo schema logico

Dopo aver ristrutturato lo schema E-R, possiamo costruire lo schema logico re-
lazionale equivalente. Decidiamo di accorpare nelle entità Libreria, Lista dei desideri
e portafoglio le associazioni che le legano ad utente, in quanto partecipano con
cardinalità (1,1). Decidiamo anche di accorpare nelle entità TRIPLA A e INDIE
le corrispettive associazioni con videogioco in quanto partecipano con cardinalità
(1,1). Infine decidiamo di accorpare le associazioni di versamento verso portafoglio
e utente nell’entità stessa in quanto partecipa con cardinalità (1,1).

Utente(username, password, email, num_amici)

Videogioco(nome, genere, rating, prezzo, tripla_a, indie)

TRIPLA A(nome_videogioco, casa_produttrice)

INDIE(nome_videogioco)

Sviluppatori (nome_sviluppatore)
SviluppatoriGiocoIndie(nome_videogioco, nome_sviluppatore)

AcquistoVideogioco(username_utente, nome_videogioco, data_acquisto)

Amicizia(username_utente1, username_utente2, data_amicizia)

Libreria(id, nome_libreria, num_giochi, username_utente)

VideogiochiContenutiLibreria (id_libreria, nome_videogioco, data_installazione,
data_disinstallazione)
Portafoglio(id_portafoglio, saldo)

Versamento(id_versamento, data, denaro_versato, username_utente_versa,

id_portafoglio)
Lista dei desideri(id, nome_lista, num_giochi, username_utente)
VideogiochiContenutiListaDesideri(id_lista, nome_videogioco)

PeriodoPromozionale(data_inizio, data_fine, nome_periodo, percentuale_sconto)

VideogiochiScontoPromozione(data_inizio_promozione, data_fine_promozione,nome_videogioco)

2.5.1 Schema UML

39 2.5. TRADUZIONE VERSO LO SCHEMA LOGICO

Figure 2.2: SCHEMA UML

PARTE 2. PROGETTAZIONE LOGICA 40
Parte 3

Progettazione Fisica

Questo progetto è stato realizzato tramite il DBMS MySQL. I file di definizione

sono allegati nella cartella implementazione. In particolare:

• La definizione delle tabelle è contenuta nel file tables.sql

• La definizione dei trigger è contenuta nel file triggers.sql
• La definizione di stored procedures per alcune operazioni è contenuta nel
file procedures.sql

• La definizione delle operazioni 1

con alcuni dati di esempio è contenuta nel
file operations.sql
Per il funzionamento corretto della base di dati è opportuno eseguire i file
nell’ordine in cui sono stati elencati

1 Per semplicità di implementazione delle operazioni è stato assegnato un saldo iniziale ad ogni

utente nel suo portafoglio

41