studio analitico per la creazione di un database atto alla gestione di gioco di ruolo univercity a...
TRANSCRIPT
Studio analitico per la creazione di un
Database atto alla gestione di gioco di ruolo
Progettazione di una base di dati
Univercity
A cura di Michele Consiglio,Veronica Di Giorgio,Carmelo Pennisi, Giuseppe Tropea
2
Progettazione concettualeProgettazione logicaProgettazione fisica
In questo seminario ci concentreremo in particolare sulle prime due fasi.
Univercity Panoramica
Fasi della progettazione
3
Strategia top-downStrategia bottom-upStrategia inside-outStrategia mista
Nella maggior parte dei casi la strategia mista è l’unica applicabile. Nel progettare la nostra base di dati abbiamo utilizzato proprio questa.
Univercity Panoramica
Strategia di progetto
4
Analisi dei RequisitiCostruzione del GlossarioEliminazione delle ambiguità Creazione insiemi omogenei Creazione Schema ScheletroDefinizione Business RuleAnalisi sottosistemi e passi di raffinamentoCreazione schema finaleAnalisi di qualità
Univercity PanoramicaProgettazione
Concettuale
5
Univercity PanoramicaProgettazione Logica
Creazione tavola delle FrequenzeCreazione tavola dei volumiAnalisi delle ridondanze e calcolo dei costiCreazione dipendenze funzionaliBCNF e 3NF
6
Progettazione concettuale
7
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.
Univercity Panoramica
Progettazione Concettuale
8
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
9
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
10
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
11
Termine Descrizione Sinonimi LegameUtente Nome
EmailPasswordLivelloTempo_attività
Giocatore ConfraternitaSkillsRangoStanzaAttivitàLavoroPiano di studi
Confraternita LivelloNome
Utente
Piano di studi Nome Categoria MateriaMateria Nome
LivelloPropedeuticità
Piano di studi
Negozio OggettoAttività Denaro
Oggetto_necessarioAumento_AttributoLuogo
UtenteOggettoAttributo
Univercity Progettazione Concettuale
Costruzione del Glossario
12
Lavoro Valore_attributoRemunerazione
Attributo
Skills NomeValore
Attributo Utente
Oggetto NomeLivelloAumento_attributo
NegozioAttributo
Stanza LivelloValore rigenerazione
UtenteAttributo
Test Questionario ConfraternitaUtente
Rango NomeDomanda Testo Test
RispostaRisposta Testo
DomandaSuccessivaDomanda
Termine Descrizione Sinonimi Legame
Univercity Progettazione Concettuale
Costruzione del Glossario
13
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.
14
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
15
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
16
Univercity Progettazione ConcettualeCostruzione dello schema
scheletroEntità 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
17
•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
Univercity Progettazione ConcettualeCostruzione dello schema
scheletro
18
Univercity Progettazione ConcettualeCostruzione dello schema
scheletro
19
Univercity Progettazione Concettuale
Business Rules: TerminiEntità Descrizione Identificatore Attributi Cardinalità
Utente Rappresenta l’utente all’interno del gioco
Email Nome Email Password Livello Tempo_attività Denaro
(1,1) (1,1) (1,1) (1,1) (1,1) (1,1)
Stanza Alloggio per il giocatore all’interno del gioco
Nome Nome Livello Valore_rigenerazione
(1,1) (1,1) (1,1)
Piano di studi Insieme di materie che il giocatore può scegliere
Nome Nome (1,1)
Materia Insieme di nozioni che lo studente deve dimostrare di aver acquisito sostenendo un esame
Nome Nome Livello Propedeuticità
(1,1) (1,1) (0,N)
Confraternita Insieme di giocatori caratterizzati da caratteristiche comuni
Nome Nome Livello
(1,1) (1,1)
Attività Delle attività che il giocatore può effettuare per migliorare e/o guadagnare denaro
Nome Nome Denaro Oggetto_necessario Aumento_attributo Attributo Luogo Tempo massimo
(1,1) (0,1) (0,N) (1,N) (1,N) (1,1) (1,1)
20
Entità Descrizione Identificatore Attributi Cardinalità
Univercity Progettazione Concettuale
Business Rules: TerminiLavoro Lavori che il giocatore può
effettuare per guadagnare denaroNome Nome
Valore_attributo Remunerazione
(1,1) (1,1) (1,1)
Oggetto Oggetti utili al giocatore per svolgere della attività e/o migliorare le proprie caratteristiche
(Nome,Livello) Nome Livello Aumento_attributo
(1,1) (1,1) (1,1)
Skills Insieme di caratteristiche appartenenti al giocatore
Nome Nome Valore
(1,1) (1,1)
Rango La qualifica assegnata al giocatore all’interno della confraternita di appartenenza
Nome Nome (1,1)
Domanda Domanda del quiz che il giocatore deve compilare
Testo Testo Risposta
(1,1) (1,N)
Risposta Risposte possibili alle domande poste durante il quiz da compilare
Testo Testo (1,N)
21
Univercity Progettazione Concettuale
Business Rules: Relazioni
Relazioni Descrizione Attributi Entità coinvolte CardinalitàComposizione Specifica la
composizione del piano di studi da un insieme di materie
NomePianoNomeMateria
PianoDiStudi Materia
(1,N) (1,N)
Frequenza Specifica che l’utente frequenta le lezioni del suo determinato piano di studi
EmailNomePiano
Utente PianoDiStudi
(1,1) (0,N)
Adempimento Specifica che l’utente adempie a dei determinati lavori
EmailNomeLavoro
Utente Lavoro
(0,N) (0,N)
Svolgimento Specifica che l’utente può svolgere determinate attività
EmailNomeAttività
Utente Attività
(0,N) (0,N)
Residenza Specifica che l’utente risiede in una stanza
EmailNomeStanza
Utente Stanza
(1,1) (1,1)
Zaino Specifica che l’utente può possedere diversi oggetti
Email(NomeOggetto,Livello)
Utente Oggetto
(0,N) (0,N)
22
Univercity Progettazione Concettuale
Business Rules: RelazioniVendita 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
TestoDomandaTestoRisposta
Domanda Risposta
(1,N) (1,N)
Appartenenza Specifica l’appartenenza dell’utente alla confraternita
EmailNomeConfraternita
Utente Confraternita
(1,1) (0,N)
Caratterizzazione Specifica che l’utente è caratterizzato da alcune skills
EmailNomeSkill
Utente Skills
(1,N) (1,N)
Assegnazione Specifica che all’utente viene assegnato un rango
EmailNomeRango
Utente Rango
(1,1) (0,N)
Relazioni Descrizione Attributi Entità coinvolte Cardinalità
23
Univercity Progettazione ConcettualeBusiness Rule: Regole di
vincoloNegozio:
• 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
24
Univercity Progettazione ConcettualeBusiness Rule: Regole di
vincoloTest:
• 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
25
Univercity Progettazione ConcettualeBusiness Rule: Regole di
derivazione• 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
26
Univercity Progettazione ConcettualeAnalisi 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
27
Univercity Progettazione ConcettualePrimo Passo
28
Univercity Progettazione ConcettualeSecondo Passo
29
Univercity Progettazione ConcettualeTerzo Passo
30
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
31
Univercity Progettazione Concettuale
Schema Revisionato
32
Univercity Progettazione Concettuale
Piccolo scorcio sulla qualità
CorrettezzaSintattica
Definizione : Uso non ammesso di costruttiSemantica
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.
33
Progettazione Logica
34
Univercity Progettazione LogicaTavola 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
35
Univercity Progettazione LogicaCreazione Tavola dei
VolumiConcetto 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
36
Univercity Progettazione LogicaRidondanze e costi
Analizzeremo adesso le ridondanze riscontrate nel Database
Avete trovato qualcosa?
37
Univercity Progettazione LogicaTavola Accessi O5
Concetto Costrutto Accessi Tipo
Utente Entità 1 L
Zaino Relazione 2 L
Oggetti Entità 1 L
Concetto Costrutto Accessi Tipo
Utente Entità 1 L
Zaino Relazione 1 L
Oggetti Entità 1 L
Utente Entità 1 S
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 zainoNella situazione in cui il contatore venga spostato all’interno dell’utente
Nella situazione in cui il contatore venga spostato all’interno dell’utente
38
Univercity Progettazione LogicaValutazione 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 scrittura5*1000= 5000
Valutazione del costo senza ridondanza
Eliminando la ridondanza saranno eseguite sulle tabelle indicate solo 4 letture quindi:4*1000=4000
39
Univercity Progettazione LogicaConclusione
Conviene non mantenere il contatore all’interno della tabella utente sia per motivi di spazio che per tempi di accesso non concorrenziali.
40
Univercity Progettazione LogicaTavola Accessi O12 e O13
Concetto Costrutto Accessi Tipo
Utente Entità 1 L
Concetto Costrutto Accessi TipoUtente Entità 1 LUtente Entità 1 S
Concetto Costrutto Accessi TipoUtente Entità 1 LAssegnazione Relazione 1 L
Concetto Costrutto Accessi TipoUtente Entità 1 L
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
Il calcolo a seconda del livello implica solo una lettura del valore del livello dell’utente
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
Altrimenti, non conservandolo si ha l’attraversamento della relazione Assegnazione e una selezione del rango dall’utente.
41
Univercity Progettazione LogicaValutazione 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 scrittura1000* 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
42
Univercity Progettazione LogicaConclusione
Conviene non mantenere il rango nella tabella utente.
43
Univercity Progettazione LogicaTavola Accessi O7
Concetto Costrutto Accessi TipoUtente Entità 3 SAttività Entità 1 LSvolgimento Relazione 1 L
Concetto Costrutto Accessi TipoUtente Entità 3 SLavoro Entità 1 LAdempimento Relazione 1 L
Quesito : è più conveniente fare un merge delle tabelle Attività e Lavoro?
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.
44
Univercity Progettazione LogicaValutazione 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=1403 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.
45
Univercity Progettazione LogicaConclusione
Come scelta strategica si è deciso di mantenere le tabelle separate minimizzando così gli accessi e ottimizzando i tempi prestazionali.
46
Univercity Progettazione LogicaDipendenze Funzionali
Entità Dipendenze Funzionali
Utente Nickname->LivelloEmail->Nickname,PasswordLivello ->OreAttività
Stanza Nome ->LivelloLivello ->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
47
Univercity Progettazione LogicaBoyce Codd e Third Normal
FomsDefinizione 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 dipendenzeJoin sulle decomposizioniVerifica dei risultatiUna 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 cancellazioniVerifica dei principi di integrità
48
Univercity Progettazione LogicaConsiderazione
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.
49
Univercity Progettazione LogicaEntità utente
Email Nome Password Livello OreAttività[email protected] Pippo Pippo 1 [email protected] Tizio Tizio 2 [email protected] Caio Caio 1 [email protected]
Sempronio Sempronio 3 Z
Email Nome [email protected] Pippo [email protected] Tizio [email protected] Caio [email protected]
Sempronio Sempronio
Nome LivelloPippo XTizio YCaio XSempronio Z
Livello OreAttività1 X2 Y1 X3 Z
Esempio di istanza
Decomposizione sulle dipendenze
50
Univercity Progettazione LogicaConsiderazione
Email Nome Password
[email protected] Alfredo *****
Nome LivelloAlfredo 1
Livello OreAttività1 X
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
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.
51
Univercity Progettazione LogicaEntità stanza
Esempio di istanza
Nome Livello RigenerazioneStanza1 X AStanza2 Y BStanza3 Z CStanza4 T D
Decomposizione sulle dipendenze
Nome LivelloStanza1 XStanza2 YStanza3 ZStanza4 T
Livello RigenerazioneX AY BZ CT D
52
Univercity Progettazione LogicaConsiderazione
Nome Livello RigenerazioneStanza5 X A
Nome LivelloStanza1 XStanza2 YStanza3 ZStanza4 TStanza5 X
Livello RigenerazioneX AY BZ CT D
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
Comporta una scomposizione di questo tipo
In cui la Join non comporta problemi. La stessa cosa vale per la cancellazione.
53
Univercity Progettazione LogicaIdentificazione 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)
54
Univercity Progettazione LogicaIdentificazione Relazioni ->
Entità
Composizione (Materia,PianoDiStudi)
Associazione (Domanda,Risposta)
Svolgimento (Attività,Utente)
Adempimento (Utente,Lavoro)
Caratterizzazione (Utente,Skill)
Zaino (Oggetto,Utente)
55
Grazie per l’attenzione.
Il team diUnivercity
A cura di Michele Consiglio,Veronica Di Giorgio,Carmelo Pennisi, Giuseppe Tropea