Univercity
Studio analitico per la creazione di un
Database atto alla gestione di gioco di ruolo
A cura di Michele Consiglio,Veronica Di Giorgio,Carmelo Pennisi, Giuseppe Tropea
Univercity
Panoramica
Fasi della progettazione
 Progettazione concettuale
 Progettazione logica
 Progettazione fisica
In questo seminario ci concentreremo in particolare
sulle prime due fasi.
2
Univercity
Panoramica
Strategia di progetto
 Strategia top-down
 Strategia bottom-up
 Strategia inside-out
 Strategia mista
Nella maggior parte dei casi la strategia mista è l’unica
applicabile. Nel progettare la nostra base di dati
abbiamo utilizzato proprio questa.
3
Univercity
Panoramica
Progettazione Concettuale
 Analisi dei Requisiti
 Costruzione del Glossario
 Eliminazione delle ambiguità
 Creazione insiemi omogenei
 Creazione Schema Scheletro
 Definizione Business Rule
 Analisi sottosistemi e passi di raffinamento
 Creazione schema finale
 Analisi di qualità
4
Univercity
Panoramica
Progettazione Logica
 Creazione tavola delle Frequenze
 Creazione tavola dei volumi
 Analisi delle ridondanze e calcolo dei costi
 Creazione dipendenze funzionali
 BCNF e 3NF
5
6
Univercity
Panoramica
Progettazione Concettuale
Lo scopo della progettazione concettuale è tradurre la
descrizione informale della realtà, risultato dell’analisi
dei requisiti del DataBase, in uno schema formale, cioè
un insieme di concetti e notazioni standard adatti alla
rappresentazione del dominio applicativo, e completo
che dovrà essere indipendente dai criteri di
rappresentazione del DBMS usato.
7
Univercity
Progettazione Concettuale
Analisi dei Requisiti
•L’Università è divisa in confraternite
•Ogni utente appartiene ad una sola confraternita
•Il giocatore può avere più oggetti
•Ogni giocatore può accedere solo ad oggetti adatti al suo livello
•Ogni utente possiede una stanza
•L’utente può passare ad una nuova stanza
•Gli oggetti sono contenuti nel negozio
•Il giocatore ha un set di attributi modificabili
•Il giocatore ha un livello
•Un utente può vedere le stanze del proprio livello o inferiore
•L’utente sceglie un piano di studi
•Ogni piano di studi contiene più materie
•Le materie sono definite da un livello richiesto per sostenerne l’esame
•Ogni confraternita avrà un livello all'interno dell'università
•Il piano di studi non può essere cambiato
8
Univercity
Progettazione Concettuale
Analisi dei Requisiti
•L’utente può dare le materie del proprio piano di studi
•L’utente può cambiare confraternita
•L’utente può ricercare gli altri giocatori
•Per ogni giocatore viene mostrata solo una parte degli attributi
•L’elenco delle confraternite può essere visto da qualunque utente
•L’utente può effettuare delle attività
•L’utente può fare dei lavori
•Ogni lavoro fa guadagnare dei soldi al giocatore
•Le attività di svago possono far guadagnare soldi al giocatore
•Un giocatore può fare qualunque attività per un massimo di tempo al giorno
•Gli oggetti possono essere richiesti per effettuare le attività
•Un giocatore può sfidare un altro utente
•In caso di sfida gli attributi degli utenti decideranno l’esito
•Per accedere alle attività un utente deve soddisfare dei requisiti
•Acquistando gli oggetti le skill dell’utente aumentano
•Ogni oggetto definisce l’aumento delle skill dell’utente
9
Univercity
Progettazione Concettuale
Analisi dei Requisiti
•Ogni utente può possedere al più 5 oggetti
•La stanza rigenera l’energia dell’utente di un tot
•Le stanze di livello maggiore aumentano la capacita di rigenerazione
•Ogni sfida può far guadagnare all’utente dei punti
•Ogni sfida fa diminuire l’energia del giocatore.
•Il giocatore deve completare un test
•Ogni domanda deve avere un certo numero di risposte disponibili
•Ogni risposta e associata alla prossima domanda da mostrare
•Alla fine del questionario l’utente viene smistato in una confraternita
•Ogni attività concorre all’aumentare dell’esperienza del giocatore
•Ogni volta che l’esperienza raggiunge 100 l’utente sale di livello
•Se l’utente raggiunge determinati livelli dovrà sostenere uno o più esami
•Ogni utente ha un rango all’interno della confraternita
•Ogni attività si svolge in un luogo
•Più attività possono essere svolte nello stesso luogo
•L’utente deve fornire un nome, una password e una email per essere identificato
•Il lavoro fa aumentare le skills dell’utente
10
Progettazione Concettuale
Costruzione del Glossario
Univercity
Termine
Utente
Descrizione
Nome
Email
Password
Livello
Tempo_attività
Confraternita
Livello
Nome
Nome
Nome
Livello
Propedeuticità
Piano di studi
Materia
Negozio
Attività
Denaro
Oggetto_necessario
Aumento_Attributo
Luogo
Sinonimi
Giocatore
Legame
Confraternita
Skills
Rango
Stanza
Attività
Lavoro
Piano di studi
Utente
Categoria
Materia
Piano di studi
Oggetto
Utente
Oggetto
Attributo
11
Progettazione Concettuale
Costruzione del Glossario
Univercity
Termine
Lavoro
Skills
Oggetto
Stanza
Descrizione
Valore_attributo
Remunerazione
Nome
Valore
Nome
Livello
Aumento_attributo
Livello
Valore rigenerazione
Test
Sinonimi
Legame
Attributo
Attributo
Utente
Negozio
Attributo
Questionario
Rango
Domanda
Nome
Testo
Risposta
Testo
DomandaSuccessiva
Utente
Attributo
Confraternita
Utente
Test
Risposta
Domanda
12
Univercity
Progettazione Concettuale
Insiemi omogenei e ambiguità
È stata rilevata una ambiguità nella definizione dei requisiti relativi al negozio e al
test.
Con negozio non si intende effettivamente una nuova entità bensì una congettura
relativa al contenitore degli oggetti, infatti non saranno presenti più negozi ma solo
uno a cui si accederà per acquistare nuovi oggetti, venderne di vecchi…
Anche il test è solo una congettura in quanto non esiste una entità ma solo il
concetto che collega domande e risposte nell’ordine corretto.
13
Univercity
Progettazione Concettuale
Insiemi omogenei e ambiguità
Negozio
•L’ utente può avere più oggetti
•Ogni utente può accedere solo ad oggetti adatti al suo livello
•Gli oggetti sono contenuti nel negozio
•L’utente può possedere al più 5 oggetti
•Gli oggetti possono essere richiesti per effettuare le attività
•Acquistando gli oggetti le skill dell’utente aumentano
Lavoro
•Ogni lavoro fa guadagnare dei soldi all' utente
•L’utente può fare dei lavori
•Il lavoro fa aumentare le skills dell’utente
 Test
•Il giocatore deve completare un test
•Alla fine del questionario l’utente viene smistato in una confraternita
•Ogni domanda deve avere un certo numero di risposte disponibili
• Ogni risposta e associata alla prossima domanda da mostrare
14
Univercity
Progettazione Concettuale
Insiemi omogenei e ambiguità
Skills
•Acquistando gli oggetti le skill dell’utente aumentano
•Il lavoro fa aumentare le skills dell’utente
•Ogni oggetto definisce l’aumento delle skill dell’utente
•Il giocatore ha un set di attributi modificabili
•Per ogni giocatore viene mostrata solo una parte degli attributi
•In caso di sfida gli attributi degli utenti decideranno l’esito
15
Univercity
Progettazione Concettuale
Costruzione dello schema scheletro
Entità fondamentali individuate:
•Lo studente, fulcro del gioco, che effettua numerose azioni e si sposta in diversi
luoghi all’interno dell’università.
•Il negozio, il cui compito è vendere oggetti agli studenti (solo oggetti accessibili al
livello dello studente)
•Le stanze, alloggi indispensabili per la permanenza degli studenti all’interno
dell’università
•Il piano di studi, insieme di materie che lo studente dovrà scegliere e di cui dovrà
sostenere gli esami
•Le materie, il cui superamento è necessario per il miglioramento delle attitudini
dello studente
•Le confraternite, di cui l’utente farà parte una volta completato un questionario
utile all’assegnamento della rispettiva confraternita
16
Univercity
Progettazione Concettuale
Costruzione dello schema scheletro
•Attività, un elenco di attività che l’utente può svolgere per migliorare le sue
attitudini e anche per guadagnare denaro
•Lavoro, indispensabile per lo studente per guadagnare soldi e poter avere una vita
sociale
•Gli oggetti, che permettono allo studente di migliorare le sue abilità e possono
essere richiesti per effettuare qualche attività
•Skill dell’utente, determinanti durante le sfide poiché ne decidono l’esito..esse
possono aumentare grazie agli oggetti
•Il questionario, fondamentale per l’assegnazione dell’utente ad una confraternita.
•Il rango , inteso come grado di importanza all’interno della confraternita
17
Univercity
Progettazione Concettuale
Costruzione dello schema scheletro
18
Progettazione Concettuale
Business Rules: Termini
Univercity
Entità
Descrizione
Utente
Rappresenta l’utente all’interno del
gioco
Email
Stanza
Alloggio per il giocatore all’interno
del gioco
Nome
Piano di studi
Insieme di materie che il giocatore
può scegliere
Insieme di nozioni che lo studente
deve dimostrare di aver acquisito
sostenendo un esame
Materia
Confraternita
Attività
Identificatore
Attributi
Cardinalità









Nome
Email
Password
Livello
Tempo_attività
Denaro
Nome
Livello
Valore_rigenerazione









(1,1)
(1,1)
(1,1)
(1,1)
(1,1)
(1,1)
(1,1)
(1,1)
(1,1)
Nome

Nome

(1,1)
Nome



Nome
Livello
Propedeuticità



(1,1)
(1,1)
(0,N)
Insieme di giocatori caratterizzati da Nome
caratteristiche comuni


Nome
Livello


(1,1)
(1,1)
Delle attività che il giocatore può
effettuare per migliorare e/o
guadagnare denaro







Nome
Denaro
Oggetto_necessario
Aumento_attributo
Attributo
Luogo
Tempo massimo







(1,1)
(0,1)
(0,N)
(1,N)
(1,N)
(1,1)
(1,1)
Nome
19
Progettazione Concettuale
Business Rules: Termini
Univercity
Entità
Descrizione
Identificatore
Lavoro
Lavori che il giocatore può
effettuare per guadagnare denaro
Oggetto
Oggetti utili al giocatore per svolgere (Nome,Livello)
della attività e/o migliorare le
proprie caratteristiche
Skills
Rango
Domanda
Risposta
Nome
Insieme di caratteristiche
appartenenti al giocatore
La qualifica assegnata al giocatore
all’interno della confraternita di
appartenenza
Nome
Domanda del quiz che il giocatore
deve compilare
Risposte possibili alle domande
poste durante il quiz da compilare
Testo
Nome
Testo
Attributi
Cardinalità






Nome
Valore_attributo
Remunerazione
Nome
Livello
Aumento_attributo






(1,1)
(1,1)
(1,1)
(1,1)
(1,1)
(1,1)



Nome
Valore
Nome



(1,1)
(1,1)
(1,1)



Testo
Risposta
Testo



(1,1)
(1,N)
(1,N)
20
Univercity
Progettazione Concettuale
Business Rules: Relazioni
Relazioni
Composizione
Attributi
NomePiano
NomeMateria
Entità coinvolte

PianoDiStudi

Materia
Cardinalità

(1,N)

(1,N)
Email
NomePiano


Utente
PianoDiStudi


(1,1)
(0,N)
Email
NomeLavoro


Utente
Lavoro


(0,N)
(0,N)
Email
NomeAttività


Utente
Attività


(0,N)
(0,N)
Email
NomeStanza
Email
(NomeOggetto,Livello)




Utente
Stanza
Utente
Oggetto




(1,1)
(1,1)
(0,N)
(0,N)
Frequenza
Adempimento
Svolgimento
Residenza
Zaino
Descrizione
Specifica la
composizione del piano
di studi da un insieme di
materie
Specifica che l’utente
frequenta le lezioni del
suo determinato piano
di studi
Specifica che l’utente
adempie a dei
determinati lavori
Specifica che l’utente
può svolgere
determinate attività
Specifica che l’utente
risiede in una stanza
Specifica che l’utente
può possedere diversi
oggetti
21
Progettazione Concettuale
Business Rules: Relazioni
Univercity
Relazioni
Descrizione
Attributi
Entità coinvolte
Cardinalità
Vendita
Specifica che gli oggetti
vengono venduti nel
negozio
(NomeOggetto,Livello)


Oggetto
Negozio


(1,N)
(1,N)
Associazione
Specifica che ad una
domanda sono associate
delle risposte
TestoDomanda
TestoRisposta


Domanda
Risposta


(1,N)
(1,N)
Appartenenza
Specifica l’appartenenza
dell’utente alla confraternita
Email
NomeConfraternita


Utente
Confraternita


(1,1)
(0,N)
Specifica che l’utente è
Email
caratterizzato da alcune skills NomeSkill


Utente
Skills


(1,N)
(1,N)
Specifica che all’utente viene
assegnato un rango


Utente
Rango


(1,1)
(0,N)
Caratterizzazione
Assegnazione
Email
NomeRango
22
Univercity
Progettazione Concettuale
Business Rule: Regole di vincolo
Negozio:
•
•
•
•
•
L’utente DEVE acquistare solo oggetti adatti al suo livello
Gli oggetti DEVONO essere venduti nel negozio
L’acquisto degli oggetti DEVE far aumentare le skills dell’utente
L’utente NON DEVE possedere più di 5 oggetti
L’utente DEVE soddisfare dei requisiti per accedere alle attività
Lavoro:
• L’utente DEVE fare dei lavori
• Le attività DEVONO svolgersi in un luogo
• Il lavoro DEVE fare aumentare le skills dell’utente
23
Univercity
Progettazione Concettuale
Business Rule: Regole di vincolo
Test:
•
•
•
•
L’utente DEVE completare un test
Ogni domanda DEVE avere un certo numero di risposte
Ogni risposta DEVE essere associata alla domanda successiva
Dopo il test l’utente DEVE essere smistato in una confraternita
Skills:
•
•
•
•
•
•
•
L’utente DEVE visualizzare solo alcune caratteristiche degli altri utenti
L’esito della sfida DEVE essere deciso dalle skills dei due utenti
L’acquisto degli oggetti DEVE far aumentare le skills dell’utente
L’utente DEVE soddisfare dei requisiti per accedere alle attività
La stanza DEVE far rigenerare l’energia dell’utente in parte
La sfida DEVE far diminuire l’energia all’utente
Il lavoro DEVE fare aumentare le skills dell’utente
24
Progettazione Concettuale
Business Rule: Regole di derivazione
Univercity
• L’aumento delle skills è ottenuto tramite l’acquisto di un oggetto
• Il livello di una confraternita è ottenuto tramite la media dei livelli dei singoli utenti
appartenenti alla confraternita
• L’aumento delle skills è ottenuto tramite lo svolgimento di un lavoro( se l’aumento è
previsto da quel lavoro)
• L’aumento delle skills è ottenuto tramite lo svolgimento di una attività ( se
l’aumento è previsto da quella attività)
• L’aumento delle skills è ottenuto dalla vittoria di una sfida
• L’aumento di energia dell’utente è ottenuto dalla stanza
• La diminuizione di energia dell’utente è ottenuta dalla sfida
• L’aumento dell’esperienza è ottenuto dallo svolgimento di attività
• L’aumento di livello dell’utente è ottenuto dal raggiungimento di 100
nell’esperienza
25
Univercity
Progettazione Concettuale
Analisi sottosistemi e passi di
raffinamento
Dallo schema scheletro si passa alla decomposizione in
sottoschemi utilizzando i sottoinsiemi omogenei
individuati al passo precedente e raggruppandoli a
seconda di un determinato contesto.
Verranno raffinati i concetti presenti sulla base delle
loro specifiche, aggiungendo nuovi concetti allo
schema per descrivere specifiche non ancora descritte.
Per semplicità faremo vedere solo la ricostruzione degli schemi
26
Univercity
Progettazione Concettuale
Primo Passo
27
Univercity
Progettazione Concettuale
Secondo Passo
28
Univercity
Progettazione Concettuale
Terzo Passo
29
Univercity
Progettazione Concettuale
Piccolo scorcio sulla qualità
Completezza
Definizione : tutti i dati sono rappresentati e le operazioni relative a
questi ultimi possono essere eseguite
Dopo una analisi approfondita dei requisiti, la costruzione degli schemi entità
relazione, l’attraversamento degli schemi tramite l’esecuzione delle operazioni si ci
è resi conto che solo una operazione non era stata prevista ed è stata aggiunta e sarà
documentata nella prossima parte di documentazione.
A questo punto ogni operazione relativa ai dati può essere eseguita.
Si tratta del test che negli schemi visti prima non rispetta i requisiti e il
glossario
30
Univercity
Progettazione Concettuale
Schema Revisionato
31
Univercity
Progettazione Concettuale
Piccolo scorcio sulla qualità
Correttezza
Sintattica
Definizione : Uso non ammesso di costrutti
Semantica
Definizione : Uso rispettato costrutti rispetto al loro significato
Nessun costrutto è stato utilizzato nel modo sbagliato.
Leggibilità
Definizione : rappresentazione semplice dei requisiti
Ogni requisiti è rappresentato nella maniera più semplice
Minimalità
Definizione : Tutte le funzionalità descritte una sola volta.
Nel seguito della documentazione si avrà uno studio delle ridondanze ma ad una
prima analisi ogni operazione è descritta una sola volta.
32
33
Univercity
Progettazione Logica
Tavola delle Frequenze
Id operazione
Operazione
Frequenza
Tipo
O1
Registrazione di un nuovo utente
30 volte al giorno
I
O2
Login Utente
60 volte al giorno
I
O3
Conteggio/visualizzazione oggetti
60 volte al giorno
B
O4
Modifica delle skills
160 volte al giorno
B
O5
Acquisto oggetti
15 volte al giorno
I
O6
Sfida tra utenti
80 volte al giorno
I
O7
Svolgimento di una attività/lavoro
120 volte al giorno
I
O8
Cambiamento di stanza
15 volte al giorno
I
O9
Dare Materie
4 volte al giorno
I
O10
Cambio di confraternita
3 volte al mese
I
O11
Visualizzazione delle skills
60 volte al giorno
B
O12
Visualizzazione del rango
60 volte al giorno
B
O13
Update del rango
2 volte al giorno
B
34
Progettazione Logica
Creazione Tavola dei Volumi
Univercity
Concetto
Tipo
Volume
Utente
E
1’000
Stanza
E
30
Piano di studi
E
10
Materia
E
100
Confraternita
E
9
Attività
E
50
Lavoro
E
50
Oggetto
E
50
Skills
E
7
Rango
E
10
Domanda
E
16
Risposta
E
55
Composizione
R
20
Frequenza
R
100
Adempimento
R
40
Svolgimento
R
40
Residenza
R
1’000
Zaino
R
2’000
Vendita
R
1’000
Associazione
R
40
Appartenenza
R
1’000
Caratterizzazione
R
7’000
Assegnazione
R
1’000
35
Univercity
Progettazione Logica
Ridondanze e costi
Analizzeremo adesso le ridondanze
riscontrate nel Database
Avete trovato qualcosa?
36
Progettazione Logica
Tavola Accessi O5
Univercity
Quesito : è più conveniente mantenere un contatore per gli oggetti nella tabella utente oppure
conteggiarli ad ogni occorrenza?
Per conteggiare il numero di oggetti acquistati nella situazione corrente bisogna accedere alle tabelle
utente e oggetti tramite la relazione zaino
Nella situazione in cui il contatore venga spostato all’interno dell’utente
Concetto
Costrutto
Accessi
Tipo
Utente
Entità
1
L
Zaino
Relazione
2
L
Oggetti
Entità
1
L
Nella situazione in cui il contatore venga spostato all’interno dell’utente
Concetto
Costrutto
Accessi
Tipo
Utente
Entità
1
L
Zaino
Relazione
1
L
Oggetti
Entità
1
L
Utente
Entità
1
S
37
Univercity
Progettazione Logica
Valutazione dei costi
Valutazione del costo con ridondanza
Mantenendo il contatore all’interno della tabella utente, dovremmo aggiungere un
campo di grandezza pari a 1 byte (minimo per ottenere il numero 5 con un intero), che
comporta quindi l’aggiunta di un campo per ogni utente aggiunto.
Avendo valutato nella tabella dei volumi 1’000 utenti avremo 1000 byte in più
contenuti nella tabella, approssimativamente 1 KB in più.
Se consideriamo una lettura come due scritture si ha che per la tabella senza
ridondanze si ha :
3 letture
1 scrittura
5*1000= 5000
Valutazione del costo senza ridondanza
Eliminando la ridondanza saranno eseguite sulle tabelle indicate solo 4 letture quindi:
4*1000=4000
38
Univercity
Progettazione Logica
Conclusione
Conviene non mantenere il contatore all’interno della
tabella utente sia per motivi di spazio che per tempi
di accesso non concorrenziali.
39
Progettazione Logica
Tavola Accessi O12 e O13
Univercity
Quesito: è più conveniente mantenere il rango nella tabella utente o calcolarlo di volta il volta ?
Nel caso in cui il rango è conservato nella tabella utente la tavola degli accessi sarà la seguente
Concetto
Costrutto
Accessi
Tipo
Utente
Entità
1
L
Per aumentare il rango dell’utente bisogna fare due accessi alla tabella utente, uno per il controllo
del livello utente uno per la scrittura del nuovo rango
Concetto
Utente
Utente
Costrutto
Entità
Entità
Accessi
1
1
Tipo
L
S
Altrimenti, non conservandolo si ha l’attraversamento della relazione Assegnazione e una
selezione del rango dall’utente.
Concetto
Utente
Assegnazione
Costrutto
Entità
Relazione
Accessi
1
1
Tipo
L
L
Il calcolo a seconda del livello implica solo una lettura del valore del livello dell’utente
Concetto
Utente
Costrutto
Entità
Accessi
1
Tipo
L
40
Univercity
Progettazione Logica
Valutazione dei costi
Valutazione del costo con ridondanza
Mantenendo il rango all’interno della tabella utente, dovremmo aggiungere un
campo di grandezza pari a 1 byte, che comporta quindi l’aggiunta di un campo per
ogni utente aggiunto.
Avendo valutato nella tabella dei volumi 1’000 utenti avremo 1000 byte in più
contenuti nella tabella, approssimativamente 1 KB in più.
2 letture + 1 scrittura
1000* 4= 4000
Valutazione del costo senza ridondanza
Eliminando la ridondanza si ha che saranno eseguite sulle tabelle indicate solo 3
letture quindi:
1000 * 3 = 3000
41
Univercity
Progettazione Logica
Conclusione
Conviene non mantenere il rango nella tabella utente.
42
Progettazione Logica
Tavola Accessi O7
Univercity
Quesito : è più conveniente fare un merge delle tabelle Attività e Lavoro?
Concetto
Utente
Attività
Svolgimento
Costrutto
Entità
Entità
Relazione
Accessi
3
1
1
Tipo
S
L
L
Concetto
Utente
Lavoro
Adempimento
Costrutto
Entità
Entità
Relazione
Accessi
3
1
1
Tipo
S
L
L
Facendo il merge si dovrebbe aggiungere un boolean nella tabella Attività,
raddoppiandone il volume e sommando i valori nella tabella delle operazioni.
Il boolean sarà rappresentato da un tinyint (1) cioè 1 byte.
43
Univercity
Progettazione Logica
Valutazione dei costi
Valutazione del costo con ridondanza
Il volume delle tabelle separate sarebbe 50+40 = 90*2=180
3 Scritture+2Letture=8 Letture * 180= 1440 operazioni totali per lo svolgimento di
una attività o di un lavoro a scelta, considerando che non si può
contemporaneamente fare una attività e un lavoro.
Valutazione del costo senza ridondanza
Il volume delle tabelle accorpate sarebbe: 50+50+40=140
3 scritture + 2 letture= 8 letture * 140=1120 operazioni totali.
Nonostante il volume totale delle tabelle sia minore, si hanno il doppio degli
accessi su una tabella che proporzionalmente è quasi di grandezza doppia.
44
Univercity
Progettazione Logica
Conclusione
Come scelta strategica si è deciso di mantenere le
tabelle separate minimizzando così gli accessi e
ottimizzando i tempi prestazionali.
45
Univercity
Progettazione Logica
Dipendenze Funzionali
Entità
Dipendenze Funzionali
Utente
Nickname->Livello
Email->Nickname,Password
Livello ->OreAttività
Stanza
Nome ->Livello
Livello ->Rigenerazione
Materia
Nome->Livello
Confraternita
Nome->Livello
Attività
Attività->Nome,Denaro,AumentoAttributo,Luogo
Lavoro
Lavoro->Nome,Guadagno,AumentoAttributi
Oggetto
Nome,Livello->AumentoAttributi
Skills
Nome->Valore
Domanda
Testo->Risposta
Risposta
Testo->DomandaSuccessiva
46
Univercity
Progettazione Logica
Boyce Codd e Third Normal Foms
Definizione BCNF :
Uno schema relazionale R con dipendenze F si dice in Forma Normale di Boyce-Codd
(BCNF) se :
per ogni X--->A di F+ , A non appartiene ad X => X e’ una superchiave di R, cioè
contiene o è una chiave.
Definizione TNF :
Uno schema relazionale R con dipendenze F si dice in Terza Forma Normale (3NF) se :
per ogni X--->A di F+ , A non appartiene ad X => X e’ una superchiave di R oppure A è
primo, cioè appartiene a qualche chiave.
Passi per l’algoritmo 3NF
Decomposizione sulla base delle dipendenze
Join sulle decomposizioni
Verifica dei risultati
Una relazione r si decompone senza perdita su X1 e X2 se il join tra X1 e X2 non
contiene ennuple spurie.
Considerazione di inserimenti e cancellazioni
Verifica dei principi di integrità
47
Univercity
Progettazione Logica
Considerazione
Le entità che saranno prese in considerazione sono
Utente e Stanza perché le altre relazioni si trovano già
in BCNF perché in ogni FD a sinistra si trova la chiave
della tabella ed inoltre sono dipendenze banali su
campi che non sono chiavi alternative.
48
Progettazione Logica
Entità utente
Univercity
Esempio di istanza
Email
[email protected]
[email protected]
[email protected]
sempronio@do
m.it
Nome
Pippo
Tizio
Caio
Sempronio
Password
Pippo
Tizio
Caio
Sempronio
Livello
1
2
1
3
OreAttività
X
Y
X
Z
Decomposizione sulle dipendenze
Email
[email protected]
[email protected]
[email protected]
sempronio@do
m.it
Nome
Pippo
Tizio
Caio
Sempronio
Password
Pippo
Tizio
Caio
Sempronio
Livello
1
2
1
3
Nome
Pippo
Tizio
Caio
Sempronio
OreAttività
X
Y
X
Z
Livello
X
Y
X
Z
49
Progettazione Logica
Considerazione
Univercity
Il join tra le tabelle non contiene ennuple spurie.
Supponiamo ora di voler inserire un nuovo utente, Alfredo con email [email protected], necessario
perché chiave per la relazione.
Allora avremo l’inserimento di
Email
Nome
Password
[email protected]
Alfredo
*****
Nome
Alfredo
Livello
1
Livello
1
OreAttività
X
Ricomponendo con una join non vi sarà violazione dei vincoli d’integrità richiesti sia per i dati
che per le dipendenze.
Neanche la cancellazione comporta la violazione dei vincoli d’integrità richiesti.
50
Progettazione Logica
Entità stanza
Univercity
Esempio di istanza
Nome
Stanza1
Stanza2
Stanza3
Stanza4
Livello
X
Y
Z
T
Rigenerazione
A
B
C
D
Decomposizione sulle dipendenze
Nome
Stanza1
Stanza2
Stanza3
Stanza4
Livello
X
Y
Z
T
Livello
X
Y
Z
T
Rigenerazione
A
B
C
D
51
Progettazione Logica
Considerazione
Univercity
Il join tra le tabelle non contiene ennuple spurie.
È importante notare che nella tabella dei Termini delle business rules Nome è chiave primaria per
la tabella, ma ciò non rende impossibile l’inserimento di due stanze che abbiano lo stesso livello.
Per questo motivo l’inserimento di un nuovo nodo dell’albero decisionale cioè una tupla tipo
Nome
Stanza5
Livello
X
Rigenerazione
A
Comporta una scomposizione di questo tipo
Nome
Stanza1
Stanza2
Stanza3
Stanza4
Stanza5
Livello
X
Y
Z
T
X
Livello
X
Y
Z
T
Rigenerazione
A
B
C
D
In cui la Join non comporta problemi. La stessa cosa vale per la cancellazione.
52
Univercity
Progettazione Logica
Identificazione Entità
Utente (Email,Nome,Password,Livello, Rango, Confraternita, Stanza, PianoDiStudi,
Tempo_attività,Denaro)
Stanza (Nome, Rigenerazione,Livello)
Confraternita (Nome, Livello)
Oggetto (Nome, Livello, Aumento_skill)
PianoDiStudi (Nome)
Materia (Nome, Livello, Propedeudicità)
Attività (Nome, Oggetto,Luogo,Requisito, Guadagno,Tempo_Massimo,Aumento_attributo)
Lavoro (Nome, Valore_attributo, Guadagno)
Skill (Nome,Valore)
Rango (Nome)
Domanda (Testo,Risposta)
Risposta (Testo,DomandaSuccessiva)
53
Univercity
Progettazione Logica
Identificazione Relazioni -> Entità
Composizione (Materia,PianoDiStudi)
Associazione (Domanda,Risposta)
Svolgimento (Attività,Utente)
Adempimento (Utente,Lavoro)
Caratterizzazione (Utente,Skill)
Zaino (Oggetto,Utente)
54
Grazie per l’attenzione.
Il team di
Univercity
A cura di Michele Consiglio,Veronica Di Giorgio,Carmelo Pennisi, Giuseppe Tropea
55