Please enable JavaScript.
Coggle requires JavaScript to display documents.
PROGETTO DI UN DATABASE_2a, vitali laura - Coggle Diagram
PROGETTO DI UN
DATABASE_2a
FASI DI SVILUPPO
CONCLUSIONI
COMPLETEZZA
tutti i dati devono essere specifici
LEGGIBILITA'
riguarda solo l'aspetto estetico
CORRETTEZZA
non devono essere presenti errori (sintattici o semantici)
MINIMALITA'
è importante capire se esiste la
ridondanza
(ripetizione di uno stesso dato [prof & insegnante]) per eliminarla
definizione degli OGGETTI che
andranno a comporre il diagramma
ANALISI DELLA DOCUMENTAZIONE
documentazione specifica prodotta per il
progetto:
appunti sulle interviste agli utenti finali
documentazione scritta predisposta appositamente
note delle riunioni tecniche e richieste del cliente
documentazione esistente
regolamenti interni
procedure aziendali
normative generali
sistema esistente
sistema da rimpiazzare
specifiche di integrazione con sistemi esistenti
AMBIGUITA'
pluralismo di percezione (omonimie, sinonimie e similitudini)
incompletezze di descrizione (conflitti di descrizione)
STRATEGIE
RICHIAMO (vedi mappa 2)
FASE 1 - ANALISI
individuazione delle ENTITA'
e definizione degli ATTRIBUTI
SCELTA DEI NOMI
avere un significato per l'utente
contenere un numero minimo di parole
devono essere unici
individuare le ENTITA'
RICHIAMO: cosa-concetto-oggetto che
contiene delle informazioni descrittive
(vedi mappa 3)
definire gli ATTRIBUTI:
REGOLE FONDAMENTALI
1- ATOMICO
(un singolo fatto, una singola informazione)
aggregazioni semplici
attributo costituito da più elementi ma eccezionalmente riconosciuto come atomico
es: INDIRIZZO [Via San Silvestro, 37 --> tipologia (via, vicolo, largo,...) nome (San Silvestro) civico (37)]
codici complessi
es: NUMERO TELEFONO [+39 347 8064288 --> prefisso nazionale (+39) prefisso operatore (347), numero (8064288)]
--> altri esempi: CODICE FISCALE
attributi testuali
sono quegli attributi definiti erroneamente di "
tipo
testo
" (es: CAP)
2- DERIVATI
NON VANNO MEMORIZZATI
, sono quegli ottenuti da operazioni (es: aeroporto --> orario di partenza & orario d'arrivo [calcoliamo la durata])
3- CODICI
lettere o numeri che rappresentano un dato specifico (es: i sessi --> M & F)
individuare le RELAZIONI
esistenti tra le ENTITA'
REGOLE DI LETTURA
RICHIAMO (vedi mappa 3)
DATABASE DESIGNER
colui che ha il compito di definire, insieme all'utente del prodotto, il
database
è responsabile dell'
astrazione
dei dati dal mondo reale (a partire dall'
analisi dei requisiti
) fino a ottenere la corretta modellazione degli stessi dapprima nello
schema concettuale
e successivamente nello
schema logico
: il suo compito è scomponibile in passi successivi
RISTRUTTURAZIONE
AFFINAMENTO
TRASFORMAZIONE
ENTITA'
per ogni entità viene generata una tabella che ha come attributo per ogni attributo dell'entità
RELAZIONI
RIDONDANZA
UNIFICARE le RELAZIONI 1:1
due entità legate da una relazione
1:1
possono essere ridotte a un'unica entità che contiene sia gli attributi della prima che quelli della seconda
(
OGNI
cittadino deve possedere
UNA SOLA
tessera sanitaria -->
OGNI
tessera sanitaria deve essere posseduta da
UN SOLO
cittadino)
SEMPLIFICAZIONE
DIVIDERE le RELAZIONI N:M
le relazioni N:N non possono essere usate nel modello dei dati, devono essere risolte con un'
entità associativa
(guarda mappa 3)
(
OGNI
cinema proietta
TANTI
film -->
TANTI
film possono esser proiettati in
OGNI
cinema)
ELIMINAZIONE ATTRIBUTI
COMPOSTI
-considerare il sottoattributi come nuovi attributi
-eliminare i sottoattributi e considerare l'attributo composto come attributo semplice
MULTIVALORE
attributo multivalore viene "promosso" a nuova entità (scaturire nuova relazione 1:N o N:N)
vitali laura