Please enable JavaScript.
Coggle requires JavaScript to display documents.
PROGETTAZIONE DI UN DATABASE_2 - Coggle Diagram
PROGETTAZIONE
DI UN DATABASE_2
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 a ottenere la modellazione dei dati
(dallo schema concettule a quello logico)
FASI DI SVILUPPO
definizione degli
OGGETTI
che andranno a comporre il diagramma
ANALISI DELLA
DOCUMENTAZIONE
documentazione esistente:
normative generali e di settore;
regolamenti interni;
procedure aziendali;
il sistema esistente:
sistema da rimpiazzare e sue integrazioni;
documentazione specifica prodotta per il progetto:
nota delle riunioni tecniche;
richieste del cliente;
apunti di interviste all'utente finale;
documentazione scritta appositamente;
AMBIGUITÀ
omonimie;
simonimie;
similitudini;
conflitti di descrizione;
individuazione delle
ENTITÀ
e
definizione degli
ATTRIBUTI
SCELTA DEI NOMI
devono essere
UNICI
devono avere un significato
per
L'UTENTE FINALE
devono contenere un
NUMERO MINIMO
di parole per descrivere l'oggetto
INDIVIDUARE LE ENTITÀ
richiamo: cosa-concetto-oggetto
che contiene delle informazioni descrittive
DEFINIRE
GLI ATTRIBUTI
1-ATOMICO
(un singolo fatto, una singola informazione)
codici complessi
esempio:
NUMERO DI TELEFONO
contiene:
il prefisso nazionale (0039);
il prefisso dell'operatore (0474 BK- 070 CA);
il numero del cliente (346...);
aggregazioni semplici
esempio:
INDIRIZZO
contiene:
il tipo della via;
il nome della via;
il numero civico;
attributi testuali
definiti erroneamente di
"TIPO TESTO"
quando in realtà sono altre tipologie
esempio:
CAP
(codice di avviamento postale)
39031 BK-09040 CA
sono attributi testuali, anche se numeri, tutto ciò che non è
soggetto a operazioni matematiche;
2-ATTRIBUTI DERIVATI
sono ottenuti come
RISULTATI DI UNA OPERAZIONE
E NON VANNO MEMORIZZATI NEL MODELLO ER
esempio:
ora decollo
ora atterraggio
la
durata del volo NO!
perché si può determinare dalla sottrazione dei precedenti
3-CODICI
è consigliato codificare gli attributi con dei codici
esempio:
SESSO
(M-F-A e non maschio-femmina-altro);
CODICE FISCALE
(Cod_Fis);
NUMERO CARTA D'IDENTITÀ
(n_CI);
NUMERO PATENTE
(n_Patente);
INDIVIDUARE LE RELAZIONI
ESISTENTI TRA LE ENTITÀ
REGOLE
DI LETTURA
si inizia sempre con la parola "OGNI"
si riporta il nome dell'ENTITÀ A
si indica la opzionalità della relazione (deve-può)
si riporta il verbo che descrive la relazione
si indica la cardinalità della relazione (uno solo-uno o più)
si riporta il nome dell'ENTITÀ B
CONCLUSIONI
CORRETTEZZA
non devono essere presenti errori (sintattici o semantici)
COMPLETEZZA
tutti i dati di interesse sono specificati
LEGGIBILITA'
riguarda anche aspetti prettamente estetici dello schema
MINIMALITA'
è importante capire se esistono 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
RISTRUTTURAZIONE
AFFINAMENTO
ELIMINAZIONE ATTRIBUTI
COMPOSTI
considerare tutti i sotto-attributi come attributi
eliminare i sotto-attributi 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 un'unica entità
che contiene gli attributi di entrambi
SEMPLIFICAZIONE
DIVIDERE LE RELAZIONI 1:1
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'
ogni entità viene generata una tabella
che ha un attributo per ogni attributo dell'entità