La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

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.

Presentazioni simili


Presentazione sul tema: "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."— Transcript della presentazione:

1 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 Progettazione concettuale Progettazione logica Progettazione fisica In questo seminario ci concentreremo in particolare sulle prime due fasi. 2 Univercity Panoramica Fasi della progettazione

3 Strategia top-down Strategia bottom-up Strategia inside-out Strategia mista Nella maggior parte dei casi la strategia mista è lunica applicabile. Nel progettare la nostra base di dati abbiamo utilizzato proprio questa. 3 Univercity Panoramica Strategia di progetto

4 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 Concettuale

5 5 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

6 6

7 Lo scopo della progettazione concettuale è tradurre la descrizione informale della realtà, risultato dellanalisi 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 Panoramica Progettazione Concettuale

8 8 Univercity Progettazione Concettuale Analisi dei Requisiti LUniversità è 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 Lutente 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 Lutente sceglie un piano di studi Ogni piano di studi contiene più materie Le materie sono definite da un livello richiesto per sostenerne lesame Ogni confraternita avrà un livello all'interno dell'università Il piano di studi non può essere cambiato

9 9 Univercity Progettazione Concettuale Analisi dei Requisiti Lutente può dare le materie del proprio piano di studi Lutente può cambiare confraternita Lutente può ricercare gli altri giocatori Per ogni giocatore viene mostrata solo una parte degli attributi Lelenco delle confraternite può essere visto da qualunque utente Lutente può effettuare delle attività Lutente 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 lesito Per accedere alle attività un utente deve soddisfare dei requisiti Acquistando gli oggetti le skill dellutente aumentano Ogni oggetto definisce laumento delle skill dellutente

10 10 Univercity Progettazione Concettuale Analisi dei Requisiti Ogni utente può possedere al più 5 oggetti La stanza rigenera lenergia dellutente di un tot Le stanze di livello maggiore aumentano la capacita di rigenerazione Ogni sfida può far guadagnare allutente dei punti Ogni sfida fa diminuire lenergia 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 lutente viene smistato in una confraternita Ogni attività concorre allaumentare dellesperienza del giocatore Ogni volta che lesperienza raggiunge 100 lutente sale di livello Se lutente raggiunge determinati livelli dovrà sostenere uno o più esami Ogni utente ha un rango allinterno della confraternita Ogni attività si svolge in un luogo Più attività possono essere svolte nello stesso luogo Lutente deve fornire un nome, una password e una per essere identificato Il lavoro fa aumentare le skills dellutente

11 11 TermineDescrizioneSinonimiLegame Utente Nome Password Livello Tempo_attività Giocatore Confraternita Skills Rango Stanza Attività Lavoro Piano di studi Confraternita Livello Nome Utente Piano di studiNomeCategoriaMateria Nome Livello Propedeuticità Piano di studi NegozioOggetto AttivitàDenaro Oggetto_necessario Aumento_Attributo Luogo Utente Oggetto Attributo Univercity Progettazione Concettuale Costruzione del Glossario

12 12 Lavoro Valore_attributo Remunerazione Attributo Skills Nome Valore AttributoUtente Oggetto Nome Livello Aumento_attributo Negozio Attributo Stanza Livello Valore rigenerazione Utente Attributo TestQuestionario Confraternita Utente RangoNome DomandaTesto Test Risposta Testo DomandaSuccessiva Domanda TermineDescrizioneSinonimiLegame Univercity Progettazione Concettuale Costruzione del Glossario

13 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 nellordine corretto.

14 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 Lutente può possedere al più 5 oggetti Gli oggetti possono essere richiesti per effettuare le attività Acquistando gli oggetti le skill dellutente aumentano Lavoro Ogni lavoro fa guadagnare dei soldi all' utente Lutente può fare dei lavori Il lavoro fa aumentare le skills dellutente Test Il giocatore deve completare un test Alla fine del questionario lutente 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 15 Univercity Progettazione Concettuale Insiemi omogenei e ambiguità Skills Acquistando gli oggetti le skill dellutente aumentano Il lavoro fa aumentare le skills dellutente Ogni oggetto definisce laumento delle skill dellutente 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 lesito

16 16 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 allinterno delluniversità. 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 allinterno delluniversità 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 lutente farà parte una volta completato un questionario utile allassegnamento della rispettiva confraternita

17 17 Attività, un elenco di attività che lutente 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 dellutente, determinanti durante le sfide poiché ne decidono lesito..esse possono aumentare grazie agli oggetti Il questionario, fondamentale per lassegnazione dellutente ad una confraternita. Il rango, inteso come grado di importanza allinterno della confraternita Univercity Progettazione Concettuale Costruzione dello schema scheletro

18 18 Univercity Progettazione Concettuale Costruzione dello schema scheletro

19 19 Univercity Progettazione Concettuale Business Rules: Termini EntitàDescrizioneIdentificatoreAttributiCardinalità Utente Rappresenta lutente allinterno del gioco Nome Password Livello Tempo_attività Denaro (1,1) Stanza Alloggio per il giocatore allinterno del gioco Nome Livello Valore_rigenerazione (1,1) Piano di studi Insieme di materie che il giocatore può scegliere Nome (1,1) Materia Insieme di nozioni che lo studente deve dimostrare di aver acquisito sostenendo un esame Nome Livello Propedeuticità (1,1) (0,N) Confraternita Insieme di giocatori caratterizzati da caratteristiche comuni Nome Livello (1,1) Attività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,1)

20 20 EntitàDescrizioneIdentificatoreAttributiCardinalità Univercity Progettazione Concettuale Business Rules: Termini Lavoro Lavori che il giocatore può effettuare per guadagnare denaro Nome Valore_attributo Remunerazione (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) Skills Insieme di caratteristiche appartenenti al giocatore Nome Valore (1,1) Rango La qualifica assegnata al giocatore allinterno della confraternita di appartenenza Nome (1,1) Domanda Domanda del quiz che il giocatore deve compilare Testo Risposta (1,1) (1,N) RispostaRisposte possibili alle domande poste durante il quiz da compilare Testo (1,N)

21 21 Univercity Progettazione Concettuale Business Rules: Relazioni RelazioniDescrizioneAttributiEntità coinvolteCardinalità Composizione Specifica la composizione del piano di studi da un insieme di materie NomePiano NomeMateria PianoDiStudi Materia (1,N) Frequenza Specifica che lutente frequenta le lezioni del suo determinato piano di studi NomePiano Utente PianoDiStudi (1,1) (0,N) Adempimento Specifica che lutente adempie a dei determinati lavori NomeLavoro Utente Lavoro (0,N) Svolgimento Specifica che lutente può svolgere determinate attività NomeAttività Utente Attività (0,N) Residenza Specifica che lutente risiede in una stanza NomeStanza Utente Stanza (1,1) ZainoSpecifica che lutente può possedere diversi oggetti (NomeOggetto,Livello) Utente Oggetto (0,N)

22 22 Univercity Progettazione Concettuale Business Rules: Relazioni Vendita Specifica che gli oggetti vengono venduti nel negozio (NomeOggetto,Livello) Oggetto Negozio (1,N) Associazione Specifica che ad una domanda sono associate delle risposte TestoDomanda TestoRisposta Domanda Risposta (1,N) Appartenenza Specifica lappartenenza dellutente alla confraternita NomeConfraternita Utente Confraternita (1,1) (0,N) Caratterizzazione Specifica che lutente è caratterizzato da alcune skills NomeSkill Utente Skills (1,N) AssegnazioneSpecifica che allutente viene assegnato un rango NomeRango Utente Rango (1,1) (0,N) RelazioniDescrizioneAttributiEntità coinvolteCardinalità

23 23 Univercity Progettazione Concettuale Business Rule: Regole di vincolo Negozio: Lutente DEVE acquistare solo oggetti adatti al suo livello Gli oggetti DEVONO essere venduti nel negozio Lacquisto degli oggetti DEVE far aumentare le skills dellutente Lutente NON DEVE possedere più di 5 oggetti Lutente DEVE soddisfare dei requisiti per accedere alle attività Lavoro: Lutente DEVE fare dei lavori Le attività DEVONO svolgersi in un luogo Il lavoro DEVE fare aumentare le skills dellutente

24 24 Univercity Progettazione Concettuale Business Rule: Regole di vincolo Test: Lutente DEVE completare un test Ogni domanda DEVE avere un certo numero di risposte Ogni risposta DEVE essere associata alla domanda successiva Dopo il test lutente DEVE essere smistato in una confraternita Skills: Lutente DEVE visualizzare solo alcune caratteristiche degli altri utenti Lesito della sfida DEVE essere deciso dalle skills dei due utenti Lacquisto degli oggetti DEVE far aumentare le skills dellutente Lutente DEVE soddisfare dei requisiti per accedere alle attività La stanza DEVE far rigenerare lenergia dellutente in parte La sfida DEVE far diminuire lenergia allutente Il lavoro DEVE fare aumentare le skills dellutente

25 25 Univercity Progettazione Concettuale Business Rule: Regole di derivazione Laumento delle skills è ottenuto tramite lacquisto di un oggetto Il livello di una confraternita è ottenuto tramite la media dei livelli dei singoli utenti appartenenti alla confraternita Laumento delle skills è ottenuto tramite lo svolgimento di un lavoro( se laumento è previsto da quel lavoro) Laumento delle skills è ottenuto tramite lo svolgimento di una attività ( se laumento è previsto da quella attività) Laumento delle skills è ottenuto dalla vittoria di una sfida Laumento di energia dellutente è ottenuto dalla stanza La diminuizione di energia dellutente è ottenuta dalla sfida Laumento dellesperienza è ottenuto dallo svolgimento di attività Laumento di livello dellutente è ottenuto dal raggiungimento di 100 nellesperienza

26 26 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

27 27 Univercity Progettazione Concettuale Primo Passo

28 28 Univercity Progettazione Concettuale Secondo Passo

29 29 Univercity Progettazione Concettuale Terzo Passo

30 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, lattraversamento degli schemi tramite lesecuzione 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 31 Univercity Progettazione Concettuale Schema Revisionato

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

33 33

34 34 Univercity Progettazione Logica Tavola delle Frequenze Id operazioneOperazioneFrequenzaTipo O1Registrazione di un nuovo utente30 volte al giornoI O2Login Utente60 volte al giornoI O3Conteggio/visualizzazione oggetti60 volte al giornoB O4Modifica delle skills160 volte al giornoB O5Acquisto oggetti15 volte al giornoI O6Sfida tra utenti80 volte al giornoI O7Svolgimento di una attività/lavoro120 volte al giornoI O8Cambiamento di stanza15 volte al giornoI O9Dare Materie4 volte al giornoI O10Cambio di confraternita3 volte al meseI O11Visualizzazione delle skills60 volte al giornoB O12Visualizzazione del rango60 volte al giornoB O13Update del rango2 volte al giornoB

35 35 Univercity Progettazione Logica Creazione Tavola dei Volumi ConcettoTipoVolume UtenteE1000 StanzaE30 Piano di studiE10 MateriaE100 ConfraternitaE9 AttivitàE50 LavoroE50 OggettoE50 SkillsE7 RangoE10 DomandaE16 RispostaE55 ComposizioneR20 FrequenzaR100 AdempimentoR40 SvolgimentoR40 ResidenzaR1000 ZainoR2000 VenditaR1000 AssociazioneR40 AppartenenzaR1000 CaratterizzazioneR7000 AssegnazioneR1000

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

37 37 Univercity Progettazione Logica Tavola Accessi O5 ConcettoCostruttoAccessiTipo UtenteEntità1L ZainoRelazione2L OggettiEntità1L ConcettoCostruttoAccessiTipo UtenteEntità1L ZainoRelazione1L OggettiEntità1L UtenteEntità1S 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 allinterno dellutente

38 38 Univercity Progettazione Logica Valutazione dei costi Valutazione del costo con ridondanza Mantenendo il contatore allinterno 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 laggiunta di un campo per ogni utente aggiunto. Avendo valutato nella tabella dei volumi 1000 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 39 Univercity Progettazione Logica Conclusione Conviene non mantenere il contatore allinterno della tabella utente sia per motivi di spazio che per tempi di accesso non concorrenziali.

40 40 Univercity Progettazione Logica Tavola Accessi O12 e O13 ConcettoCostruttoAccessiTipo UtenteEntità1L ConcettoCostruttoAccessiTipo UtenteEntità1L UtenteEntità1S ConcettoCostruttoAccessiTipo UtenteEntità1L AssegnazioneRelazione1L ConcettoCostruttoAccessiTipo UtenteEntità1L 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 dellutente Per aumentare il rango dellutente 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 lattraversamento della relazione Assegnazione e una selezione del rango dallutente.

41 41 Univercity Progettazione Logica Valutazione dei costi Valutazione del costo con ridondanza Mantenendo il rango allinterno della tabella utente, dovremmo aggiungere un campo di grandezza pari a 1 byte, che comporta quindi laggiunta di un campo per ogni utente aggiunto. Avendo valutato nella tabella dei volumi 1000 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 42 Univercity Progettazione Logica Conclusione Conviene non mantenere il rango nella tabella utente.

43 43 Univercity Progettazione Logica Tavola Accessi O7 ConcettoCostruttoAccessiTipo UtenteEntità3S AttivitàEntità1L SvolgimentoRelazione1L ConcettoCostruttoAccessiTipo UtenteEntità3S LavoroEntità1L AdempimentoRelazione1L 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 44 Univercity Progettazione Logica Valutazione dei costi Valutazione del costo con ridondanza Il volume delle tabelle separate sarebbe = 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: =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 45 Univercity Progettazione Logica Conclusione Come scelta strategica si è deciso di mantenere le tabelle separate minimizzando così gli accessi e ottimizzando i tempi prestazionali.

46 46 Univercity Progettazione Logica Dipendenze Funzionali EntitàDipendenze Funzionali Utente Nickname->Livello ->Nickname,Password Livello ->OreAttività Stanza Nome ->Livello Livello ->Rigenerazione MateriaNome->Livello ConfraternitaNome->Livello AttivitàAttività->Nome,Denaro,AumentoAttributo,Luogo LavoroLavoro->Nome,Guadagno,AumentoAttributi OggettoNome,Livello->AumentoAttributi SkillsNome->Valore DomandaTesto->Risposta RispostaTesto->DomandaSuccessiva

47 47 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 lalgoritmo 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 48 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.

49 49 Univercity Progettazione Logica Entità utente NomePasswordLivelloOreAttività 1X 2Y 1X m.it Sempronio 3Z NomePassword m.it Sempronio NomeLivello PippoX TizioY CaioX SempronioZ LivelloOreAttività 1X 2Y 1X 3Z Esempio di istanza Decomposizione sulle dipendenze

50 50 Univercity Progettazione Logica Considerazione NomePassword NomeLivello Alfredo1 LivelloOreAttività 1X Il join tra le tabelle non contiene ennuple spurie. Supponiamo ora di voler inserire un nuovo utente, Alfredo con necessario perché chiave per la relazione. Allora avremo linserimento di Ricomponendo con una join non vi sarà violazione dei vincoli dintegrità richiesti sia per i dati che per le dipendenze. Neanche la cancellazione comporta la violazione dei vincoli dintegrità richiesti.

51 51 Univercity Progettazione Logica Entità stanza Esempio di istanza NomeLivelloRigenerazione Stanza1XA Stanza2YB Stanza3ZC Stanza4TD Decomposizione sulle dipendenze NomeLivello Stanza1X Stanza2Y Stanza3Z Stanza4T LivelloRigenerazione XA YB ZC TD

52 52 Univercity Progettazione Logica Considerazione NomeLivelloRigenerazione Stanza5XA NomeLivello Stanza1X Stanza2Y Stanza3Z Stanza4T Stanza5X LivelloRigenerazione XA YB ZC TD 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 linserimento di due stanze che abbiano lo stesso livello. Per questo motivo linserimento di un nuovo nodo dellalbero 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 53 Univercity Progettazione Logica Identificazione Entità Utente ( ,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 54 Univercity Progettazione Logica Identificazione Relazioni -> Entità Composizione (Materia,PianoDiStudi) Associazione (Domanda,Risposta) Svolgimento (Attività,Utente) Adempimento (Utente,Lavoro) Caratterizzazione (Utente,Skill) Zaino (Oggetto,Utente)

55 55 Grazie per lattenzione. Il team di Univercity Il team di Univercity A cura di Michele Consiglio,Veronica Di Giorgio,Carmelo Pennisi, Giuseppe Tropea


Scaricare ppt "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."

Presentazioni simili


Annunci Google