Progettazione di una base di dati

1. Progettazione di una base di dati Studio analitico per la creazione di un Database atto alla gestione di gioco di ruolo Univercity A cura di Michele Consiglio,Veronica Di Giorgio,Carmelo Pennisi, Giuseppe Tropea

2. Panoramica Fasi della progettazione Univercity • Progettazione concettuale • Progettazione logica • Progettazione fisica In questo seminario ci concentreremo in particolare sulle prime due fasi.

3. Panoramica Strategia di progetto Univercity • 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.

4. Panoramica Progettazione Concettuale Univercity • 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à

5. Panoramica Progettazione Logica Univercity • Creazione tavola delle Frequenze • Creazione tavola dei volumi • Analisi delle ridondanze e calcolo dei costi • Creazione dipendenze funzionali • BCNF e 3NF

6. Progettazione concettuale

7. Panoramica Progettazione Concettuale Univercity 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.

8. Progettazione Concettuale Analisi dei Requisiti Univercity • 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. Progettazione Concettuale Analisi dei Requisiti Univercity • 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. Progettazione Concettuale Analisi dei Requisiti Univercity • 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. Progettazione Concettuale Costruzione del Glossario Univercity

12. Progettazione Concettuale Costruzione del Glossario Univercity

13. Progettazione Concettuale Insiemi omogenei e ambiguità Univercity È 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. Progettazione Concettuale Insiemi omogenei e ambiguità Univercity • 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. Progettazione Concettuale Insiemi omogenei e ambiguità Univercity • 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. Progettazione Concettuale Costruzione dello schema scheletro Univercity • 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

17. Progettazione Concettuale Costruzione dello schema scheletro Univercity • 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

18. Progettazione Concettuale Costruzione dello schema scheletro Univercity

19. Progettazione Concettuale Business Rules: Termini Univercity

20. Progettazione Concettuale Business Rules: Termini Univercity

21. Progettazione Concettuale Business Rules: Relazioni Univercity

22. Progettazione Concettuale Business Rules: Relazioni Univercity

23. Progettazione Concettuale Business Rule: Regole di vincolo Univercity • 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

24. Progettazione Concettuale Business Rule: Regole di vincolo Univercity • 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

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

26. Progettazione Concettuale Analisi sottosistemi e passi di raffinamento Univercity 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. Progettazione Concettuale Primo Passo Univercity

28. Progettazione Concettuale Secondo Passo Univercity

29. Progettazione Concettuale Terzo Passo Univercity

30. Progettazione Concettuale Piccolo scorcio sulla qualità Univercity • 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. Progettazione Concettuale Schema Revisionato Univercity

32. Progettazione Concettuale Piccolo scorcio sulla qualità Univercity • 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.

33. Progettazione Logica

34. Progettazione Logica Tavola delle Frequenze Univercity

35. Progettazione Logica Creazione Tavola dei Volumi Univercity

36. Progettazione Logica Ridondanze e costi Univercity Analizzeremo adesso le ridondanze riscontrate nel Database Avete trovato qualcosa?

37. 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 • Nella situazione in cui il contatore venga spostato all’interno dell’utente

38. Progettazione Logica Valutazione dei costi Univercity • 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

39. Progettazione Logica Conclusione Univercity Conviene non mantenere il contatore all’interno della tabella utente sia per motivi di spazio che per tempi di accesso non concorrenziali.

40. 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 • 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. • Il calcolo a seconda del livello implica solo una lettura del valore del livello dell’utente

41. Progettazione Logica Valutazione dei costi Univercity 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

42. Progettazione Logica Conclusione Univercity Conviene non mantenere il rango nella tabella utente.

43. Progettazione Logica Tavola Accessi O7 Univercity 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. Progettazione Logica Valutazione dei costi Univercity 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.

45. Progettazione Logica Conclusione Univercity Come scelta strategica si è deciso di mantenere le tabelle separate minimizzando così gli accessi e ottimizzando i tempi prestazionali.

46. Progettazione Logica Dipendenze Funzionali Univercity

47. Progettazione Logica Boyce Codd e Third Normal Foms Univercity • 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à

48. Progettazione Logica Considerazione Univercity 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. Progettazione Logica Entità utente Univercity Esempio di istanza • Decomposizione sulle dipendenze

50. Progettazione Logica Considerazione Univercity Il join tra le tabelle non contiene ennuple spurie. Supponiamo ora di voler inserire un nuovo utente, Alfredo con email alfredo@dom.it, 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.