Please enable JavaScript.
Coggle requires JavaScript to display documents.
PROGETTO DI UN DATABASE_2 - Coggle Diagram
PROGETTO DI UN DATABASE_2
FASI DI SVILUPPO
definizione degli OGGETTI che andranno a comporre il diagramma
ANALISI DELLA DOCUMENTAZIONE
documentazione esistente:
normative generali del settore
regolamenti interni
procedure aziendali
sistema esistente:
sistema da rimpiazzare e sue integrazioni
DOCUMENTAZIONE SPECIFICA PRODOTTA PER IL PROGETTO:
NOTE DELLE RIUNIONI TECNICHE
RICHIESTE DEL CLIENTE
APPUNTI DI INTERVISTE ALL'UTENTE FINALE
DOCUMENTAZIONE SPECIFICA APPOSITAMENTE
AMBIGUITÀ
omonimie
sinonimie
similitudini
conflitti di descrizione
individuazione dell'ENTITÀ
e si definiscono degli ATTRIBUTI
SCELTA DEI NOMI
devono avere significato per l'utente finale
devono contenere un numero minimo
di parole per descrivere un oggetto
devono essere unici
individuare le ENTITÀ
RICHIAMO: cosa - concetto - oggetto che
contiene delle informazioni descritive
1 -ATOMICO
(un singolo fatto una singola informazione)
aggregazioni semplici
esempio: INDIRIZZO
contiene il tipo della via;
il nome della via;
il numero civico
codici complessi
esempio: NUMERO TELEFONO
contiene il prefisso nazionale (0039)
il prefisso operatore (0474 BK - 070 CA)
il numero del cliente (0971 ....)
attributi testuali
definiti erroneamente di "tipo testo" quando
in realtà sono altre tipologie
esempio: CAP (codice avviamento postale)
39031 BK - 09040 CA
sono attributi testuali, anche see numeri, tutto ciò che
non è soggetto a operazioni matematiche
2 - DERIVATI
sono ottenuti come risultato di una operazione e NON vanno memorizzati sul modello ER.
esempiio: ora decollo - ora atteraggio - durata volo NO! perché si può determinare della sottrazione dei precedenti attributi.
3 - CODICI
è consigliato codificare gli attributi con dei codici
esempio: Sesso (M - F - A e non maschio - femmina - altro)
Codice Fiscale --> Cod_Fis (CodFis)
Numero Carta d'Identità --> n_CI (nCI)
Numero Patente --> n_Patente (nPatente)
individuare le RELAZIONI
esistenti tra le ENTITA'
REGOLE DI LETTURA
Si inizia sempre con la parola OGNI
si scrive il nome dell'ENTITA' A
si indica l'opzionalità (deve-può)
si riporta il verbo che descrive la relazione
si indica la carnalità dell'operazione (uno solo - uno più)
si riporta il nome dell'ENTIA' B
CONCLUSIONI
COMPLETEZZA
tutti i dati di interesse sono specificati
LEGGIBILITA'
riguarda anche aspetti prettamente estetici dello schema
CORRETTEZZA
non devono essere presenti errori
MINIMALITA'
è importante capire se ci sono elementi ridondanti nello schema e se queste situazioni costituiscono un problema oppure sono dovute a una scelta di progettazione volta a favorire l'esecuzione di certe operazioni
DATABASE DESIGNER
colui che ha il compito di defInire
, assieme all'utente del prodotto, il DATABASE
è responsabile dell'astrazione dei dati dal mondo reale (analisi dei requisiti) fino ad ottenere la modellazione dei dati (dallo schema concettuale a quello logico)
RISTRUTTURAZIONE
AFFFINAMENTO
ELIMINAZIONE ATTRIBUTI
COMPOSTI
considerare tutti i sottoattributi come attributi
eliminare i sottoattributi considerando
l'attributo composto come attributo semplice
MULTIVALORE
questi vengono promossi a ENTITA'
TRASFORMAZIONE
RELAZIONI
RIDONDANZA
UNIFICARE le RELAZIONI 1:1
due entità legate da una relazione 1:1
possono essere ridotte a una'unica entità
che contiene gli attributi di entrambi
SEMPLIFICAZIONE
DIVIDERE le RELAZIONI N:M
due entità legate da una relazione N:M
possono essere semplificate individuando
una ENTITA' ASSOCIATIVA
ovvero si ottengono due relazioni N:1 e 1:M
ENTITA'
ENTITA'
per ogni entità viene generata una tabella che ha un attributo per ogni attributo dell'entità