Progettazione di una base di dati

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.


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.


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


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


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


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


Costruzione del Glossario

13


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



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



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


scheletro

18


scheletro

19


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à


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


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


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


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


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


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


Schema Revisionato

32


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 VolumeUtente E 1’000Stanza E 30Piano di studi E 10Materia E 100Confraternita E 9Attività E 50Lavoro E 50Oggetto E 50Skills E 7Rango E 10Domanda E 16Risposta E 55Composizione R 20Frequenza R 100Adempimento R 40Svolgimento R 40Residenza R 1’000Zaino R 2’000Vendita R 1’000Associazione R 40Appartenenza R 1’000Caratterizzazione R 7’000Assegnazione 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 TipoUtente 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



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


Eliminando la ridondanza si ha che saranno eseguite sulle tabelle indicate solo 3 letture quindi:1000 * 3 = 3000

42


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



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.


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


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


Email Nome [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


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

Progettazione di una base di dati

Documents

Transcript of Progettazione di una base di dati