Please enable JavaScript.
Coggle requires JavaScript to display documents.
PROGETTO DI UN DATA BASE_2 - Coggle Diagram
PROGETTO DI UN DATA BASE_2
(2) FASI DI SVILULPPO
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 ENTITA'
RICHIAMO: cosa - concetto - oggetto che contiene le informazioni descrittive
definizione degli OGGETTI che andranno a comporre il diagramma
ANALISI DELLA
DOCUMENTAZIONE
Documentazione esistente:
normative generali e di settore
regolamenti interni
procedure aziendali
Sistema esistente:
sistema da** rimpiazzare e le sue integrazioni
documentazione specifica prodotta per il progetto:
note delle riunioni tecniche
richieste del cliente
appunti di interviste all'utente finale
documentazione scritta appositamente
AMBIGUITA'
Omonimie
sinonimie
similitudini
conflitti di descrizione
DEFINIRE GLI ATTRIBUTI
1 - ATOMICO
(un singolo fatto, una singola informazione)
aggregazioni semplici
esempio: INDIRIZZO
contiene il tipo di via;
il nome della via;
il numero civico
codici complessi
esempio: NUM DI TELEFONO
contiene il prefisso nazionale (0039);
il prefisso dell'operatore (0474 BK - 070 CA);
il numero del cliente (0435......)
attributi testuali
definiti erroneamente di "tipo testo" quando in realtà sono altre tipologie.
Esempio: CAP
39031 BK - 09040 CA
sono attributi testuali, anche se numeri, tutto ciò che non è oggetto a operazioni matematiche
2 - DERIVATI
sono ottenuti come risultato di un'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 e non maschio - femmina - altro)
Codice Fiscale --> Cod_Fis (CodFis)
Num Carta d'Identità --> n_CI (nCI)
Num Patente --> n_Patente (nPatente)
INDIVIDUARE LE
RELAZIONI ESISTENTITA'
REGOLE DI LETTUIRA:
si inizia sempre con la parola OGNI;
si scrive la prima ENTITA';
verbo PUO' o DEVE + verbo scelto;
UN SOLO o UNO O PIU';
si scrive l'altra ENTITA
CONCLUSIONI
COMPLETEZZA
tutti i dati di interessi sono specificati
LEGGIBILITA'
capire se gli elementi riordinati sono un problema o una scelta di progettazione
CORRETTEZZA
non ci devono essere errori (sintattici o sistematici)
MINIMALITA'
aspetto estetico dello schema
(1) DATABASE DESIGNER
colui che ha il compito di definire, assieme all'utente del prodotto, il DATABSE
è responsabile dell'astrazione dei dati dal mondo reale (analisi dei requisiti) fino ad ottenere la modellazione dei dati (dallo schema concettuale a quello logico)
(3) RISTRUTTURAZIONE
AFFINAMENTO
ENTITA'
per ogni entità viene generata una tabella che ha un attributo per ogni attributo dell'entità
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
ENTITA'
RELAZIONI
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
DIVIDERE le RELAZIONI N:M
due entità legate da una relazione N:M possono essere semplificate individuando una ENTITA' ASSOCIATIVA (p. 29) ovvero si ottengono due relazioni --> N:1 e 1:M