Please enable JavaScript.
Coggle requires JavaScript to display documents.
PROGETTO DI UN DATABASE_2 - Coggle Diagram
PROGETTO DI UN DATABASE_2
DATABASE DESIGNER
Colui che ha il compito di definire, assieme all’utente del prodotto, il DATABASE
è responsabile dell’estrazione dei dati dal mondo reale (analisi dei requisiti) fino ad ottenere la modella ione dei dati (dallo schema concettuale a quello logico)
FASI DI SVILUPPO
Definizione degli OGGETTI che andranno a comporre il diagramma
ANALISI DELLA DOCUMENTAZIONE
Documentazione specifica prodotta per il progetto:
note delle riunioni tecniche
richieste del cliente
appunti di interviste all’utente finale
documentazione specifica prodotta
Documentazione esistente:
noremative Generali e di settore
regolamenti interni
procedure aziendali
Sistema esistente:
sistema da rimpiazzare e sue integrazioni
AMBIGUITÀ
Omonimie
sinonimie
similitudini
conflitti di descrizione
Individuazione delle ENTITÀ
e definizione degli ATTRIBUTI
SCELTA DEI NOMI
Devono avere un significato per l’utente finale
Devono contenere un numero minimo di parole per descrivere l’oggetto
Devono essere UNICI
Individuare le ENTITÀ
RICHIAMO: cosa - concetto - oggetto che contiene delle informazioni descrittive
Definire gli ATTRIBUTI
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 CIVICO
contiene il prefisso nazionale (0039);
il prefisso operatore (0474 - 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 se 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.
esempio: ora decollo - ora atterraggio -
durata volo
NO! Perché si può determinare dalla sottrazione dei precedenti attributi.
3 - CODICI
È consigliato codificare gli attributi con dei codici
esempio: Sesso (M - F - A 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 ENTITÀ
REGOLE DI LETTURA
si inizia sempre con la parola OGNI
si scrive la prima ENTITÀ
si indica l’OPZIONALIÀ della relazione (deve-può)
si riporta il VERBO che descrive la relazione
si indica la CARDINALITÀ della relazione (uno solo-uno o più)
si scrive la seconda ENTITÀ
e poi viceversa
CONCLUSIONI
CORRETTEZZA
Non devono esserci errori (sintattici o semantici)
COMPLETEZZA
Tutti i dati di interessi sono specificati
LEGGIBILITÀ
Aspetto estetico dello schema
MINIMALITÀ
Capire se gli elementi ridondanti sono un problema o una scelta di progettazione
RISTRUTTURAZIONE AFFINAMENTO
TRASFORMAZIONE
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 gli attributi di entrambi
SEMPLIFICAZIONE
DIVIDERE le RELAZIONI N:M
due entità legate da una relazione N:M
Possono essere semplificate individuando un’ENTITÀ ASSOCIATIVA
ovvero si ottengono due relazioni N:1 e 1:M
ENTITÀ
per ogni entità viene generata una tabella che ha un attribuito per ogni attributi dell’entità
ELIMINAZIONE ATTRIBUTI
COMPOSTI
Considerare tutti i sottoattributi come attributi
Eliminare i sottoattributi considerando l’attributo composto come attributi semplice
MULTIVALORE
questi vengono promossi a ENTITÀ