Please enable JavaScript.
Coggle requires JavaScript to display documents.
PROGGETTO DI UN DATABASE 2a - Coggle Diagram
PROGGETTO DI UN DATABASE 2a
FASI DI SVILUPPO
INDIVIDUAZIONE DELLE ENTITA'E DEFINIZIONE DEGLI ATTRIBUTI
INDIVIDUARE LE ENTITA'
SONO I PRIMI ELEMENTI DA INDIVIDUARE: un entità è una cossa, un conccetto o oggetto, sono oggetti che contengono informazioni descrittive, edd ogni entità è rappresenta alcune cose che condividono proprietà.
DEFINIRE GLI ATTRIBUTI:REGOLE FINDAMNTALI
2-DERIVATI
sono quei dati derivanti da un algoritmo o da una formula che per molti è bene non inserire in un DB. Un esempio è a mio parere è l'età della persona calcolata in base ad un algoritmo semplicissimo.
3-CODICI
insieme di simboli o segni, questi hanno la stessa origine e una funzione già determinata. il codice Morsa stabilisce un ordine specifico delle diverse combinazioni di trattini e punti.
1-ATOMICO (un singolo fatto, una singola informazione)
aggregazioni complesse
tipo il numero di telefono che è composto dal prefisso che è bene spezzare dal vero e proprio numero
aggregazioni semplici
salvare nome e cognome di un utente
aggregazioni testuali
ad esempio le date (gg.mm.aaaa) con attributi di tipo testuale
SCELTA DEI NOMI
Tutti gli oggetti che fanno parte del nostro modello "dovrebbero " avere un nome 1.Essere unici 2.avere un significato per l'utente finale ecc.
Non è consigliato usare abbrevazioni e accronimi perchè posso portare a fare confusione sul loro significato, tranne per quelli "universalmente riconosciuti e utilizzati
I nomi sono usati generalmente al singolare, mentre i nomi delle relazioni sono tipicamente dei verbi
individuare le RELAZIONI esistenti tra le ENTITA'
REGOLE DI LETTURA
Si inizia sempre con la parola "ogni", si indica il nome dell'entità di partenza, si indica l'obbligatorietà deve o può, dopodichè si riporta il verbo che descrive la relazione, si indica la cardinalità uno solo o uno o più e infine il nome della seconda entità
definizione degli OGGETTI che andranno a comporre il diagramma
ANALISI DELLA DOCUMENTAZIONE
DOCUMENTAZIONE ESISTENTE
le procedure aziedali
i regolamenti interni
le normative generali del settore
SISTEMA ESISTENTE
Le specifiche di integrazione con sistemi esistenti
Il sistema da rimpiazzare
DOCUMENTAZIONE SPECIFICA PRODOTTA PER IL PROGETTO:
la documentazione scritta predisposta appositamente
gli appunti sulle interviste agli utenti finali
Le note delle riunioni tecniche richiese dal cliente
AMBIGUITA'
il plurarismo di percezione
le incompletezze di descrizione
STRATEGIE
BOTTOM UP
Si suddividono le specifiche così da sviluppare semplici schemi parziali ma dettagliati, che poi vengono inntegrati tra loro
INSIDE OUT
"a macchia d'olio", parte dei concetti più importanti a quelli a essi correlati
TOP DOWN
spesso meglio usare la bottom up
si parte da uno schema iniziale molto astratto ma completo a uno finale
CONCLUSIONI
COMPLETEZZA
tutti i dati di interesse sono specificati
LEGGIBILITA'
riguarda anche aspetti prettamente estetici dello schema
CORRETTEZZA
non devono essere presenti errori sintattici o semantici
MINIMALITA'
NO elementi ridondanti tutto ridotto alla minimalità se porta a ridondanze cambiare strada
RISTRUTTURAZIONE AFFINAMENTO
TRASFORMAZIONE
ENTITA'
per ogni entità viene generata una tabella che ha un attributo per ogni attributo dell'entità
RELAZIONI
RIDONDANZA
UNIFICARE LE RELAZIONI 1:1
Due entità legate da una relazione uno ad uno possono essere ridotte ad un unica entità
SEMPLIFICAZIONE
DIVIDEE LE RELAZIONI N:M
Le relazioni molti a molti devono essere risolte nelle fasi di ristrutturazione del modello sostituendole con un entità associativa
ELIMINAZIONE ATTRIBUTI
COMPOSTI
Un attributo composto si può procedere in due modi alternativi:
1.considerare tutti i sottoattributi come attributi
2.eliminare i sottoattributi e considerare l' attributo composto come un attributo semplice
MULTIVALORE
Gli eventuali attributi multivalore presenti devono essere "promossi" a entità
Contiene i valori dell'attributo e la si collega all' entità che possedeva all'attributo mediante
DATABASE DESIGNER
Colui che ha il compito di definire, assieme all'utente all' prodotto , il database
è responsabile dell' ASTRAZIONE dei dati dal mondo reale