Scarica Database - Definizione modello E-R e più Dispense in PDF di Database Relazionali solo su Docsity!
Definizione modello E-R
Database designer Responsabile astrazione dati del mondo reale a partire dell’analisi dei requisiti fino ad ottenere la corretta modellazione degli stessi dapprima dello schema concettuale e poi nello schema logico. ● Realizzazione “provvisoria” del modello E-R (modello base) ● Raffinazione e ristrutturazione del modello E-R Realizzazione modello di base ● Definire gli oggetti che comporanno il diagramma ● Si completano le entità con gli attributi ● Si individuano le relazioni esistenti tra le entità Modellatore (database designer) classifica gli oggetti vome entità o come attributi partendo dalla documentazione del progetto. Indivuazione oggetti del diagramma ● Raccolta analisi documentazione ● Definizione glossario dei termini (precisione e non ambiguità) Analisi documentazione ● Analisi dei requisiti produce documenti del progetto del database, prima versione in requisiti in linguaggio naturale ● Analizzare le frasi, eliminare ambiguità create da pluralismo di percezione, incompletezza di descrizione, omonimie, sinonimie, conflitti di descrizione, similitudini Sinonimi : docente, insegnante, istruttore decido un unico termine Omonimi : posto di lavoro, posto di nascita meglio impiego e città natale Glossario dei termini
Definizione entità e attributi ● Riorganizzare le frasi e definire oggetti ● Nominare gli oggetti ● Documentare progetto realizzando matrice entità e attributi Concetto viene rappresentato come : ● Entità : proprietà significative e descrive oggetti cin esistenza autonoma ● Attributo : se semplice, non ha proprietà e serve a descrivere entità ● Relazione (associazione) : se correla due o più concetti/entità Riorganizzare le frasi e definire oggetti ● Raggruppa le frasi in base al concetto
Individuare entità
-qualunque oggetto per il quale è necessario salvare attributi -qualsiasi oggetto che deve essere rappresentato in un database In particolare : -persone, luoghi, cose, eventi o concetti distinguibili -qualsiasi cosa per cui salviamo informazioni
Definire gli attributi
Gli attributi sono gli oggetti che descrivono un’entità: corrispondono ai campi dei record. Gli attributi devono essere atomici, ovvero presentare un singolo fatto o una singola informazione, dove per singola informazione si intende proprio la più piccola informazione salva-bile. Aggregazioni semplici
l’esempio precedente, che concatena il nomee il cognome, è un caso di aggregazione semplice. Un altro errore da aggregazione semplice viene fatto sull’attributo Indi-rizzo, dove spesso si concatena la via, la città e il codice postale. È bene invece separare questi dati anche quando l’utente finale li usa solo assieme, per aumentarne la flessibilità di utilizzo (si possono ordinare i dati per CAP). Codici complessi: alcuni attributi hanno per valore codici composti di parti di informazioni concatenate che nella vita quotidiana sono utilizzate assieme, ma che risulta opportuno scomporre nei database. Un esempio di codice complesso è il numero telefonico completo di prefisso, che deve essere spezzato in due attributi. Attributi testuali: ci sono attributi che vengono definiti erroneamente di tipo testo perché questa modalità di rappresentazione risulta essere la più semplice. A volte questo errore non genera problemi immediati, soprattutto se su questi attributi non sono previste elaborazioni; esigenze successive potrebbero tuttavia richiedere operazioni non previste su questi campi che, essendo in formato testo, genererebbero sicuramente gravi problemi (richiedendo, per esempio, la completa conversione “di tipo” su tali campi, operazione a volte di difficile realizzazione). Un esempio classico è quello di definire le date(GG-MM-AAAA) con attributi di tipo testo, e dover poi eseguire su di esse delle operazioni Attributi numerici: ci sono attributi che vengono definiti erroneamente di tipo numerico perché questa modalità di rappresentazione “sembra essere” la più indicata. Un esempio classico è quello di definire di tipo intero il CAP, la partita IVA, il numero civico, il numero di telefono ecc., quando invece andrebbero definiti di tipo testo, in quanto su di essi non verranno mai effettuate operazioni matematiche! Gli attributi derivati non dovrebbero essere memorizzati. Gli attributi derivati sono quelli ottenuti come risultati dall’applicazione di una formula o da operazioni di elaborazione su altri attributi. Le argomentazioni contro l’inclusione dei dati derivati sono basate sulla premessa che, in
risolvere qualsiasi istanza individuando i casi nei quali una singola entità rappresenti effettivamente due concetti diversi (omonimia) o dove due diverse entità rappresentano effettivamente la stessa cosa (sinonimia). Questa situazione tipicamente si verifica quando vengono intervistate più persone con compiti e livelli operativi diversi all’interno della stessa organizzazione, perché ciascuno ha conoscenza solo del proprio “ambito di lavoro” e pensa a eventi o processi secondo il “proprio personale punto di vista”. Scelta dei nomi Tutti gli oggetti che fanno parte del nostro modello “dovrebbero” avere un nome e anche questo aspetto deve essere regolato da una serie di proprietà. I nomi degli oggetti devono:
- essere unici;
- avere un significato per l’utente finale;
- contenere un numero minimo di parole di cui si ha bisogno per descrivere univocamente e accuratamente l’ oggetto. Per le entità e gli attributi i nomi sono usati generalmente al singolare, mentre le relazioni sono tipicamente descritte attraverso verbi. È sconsigliato usare abbreviazioni o acronimi perché possono ingenerare confusione circa il loro significato, tranne per quelli “universalmente riconosciuti e utilizzati” come il CAP, l’I VA, l’ISBN, la TASI, la TARI, l’indirizzo IP ecc. Il rischio, in ogni caso, è di utilizzare nomi uguali per rappresentare concetti diversi: in questo caso, ci si troverebbe di fronte a degli omonimi che renderebbero inutilizzabile il modello date che, come ben sappiamo, in informatica “non si può essere ambigui”! Documentare il progetto: matrici tra entità e attributi Oltre al glossario, per tenere traccia degli oggetti che faranno parte del database si possono usare due schemi: la matrice entità-entità e la matrice entità-attributo. Nel dettaglio:
- la matrice entità-entità è un tabella bidimensionale per indicare le relazioni tra le entità. Inomi di tutte le entità identificate sono elencate sui due assi (verticale e orizzontale). Una re-lazione viene indicata con una “X” posizionata nelle caselle di intersezione tra due entità. Questa tabella sarà il punto di partenza per la fase di progettazione concettuale dove ogni relazione deve essere descritta mediante uno schema E-R;
- la matrice entità-attributo viene usata per indicare l’ assegnazione degli attributi alle entità. È simile nella forma alla matrice entità-entità, tranne che i nomi degli attributi sono elencati in righe: questa tabella viene utilizzata successivamente, in fase di definizione del modello logico, dove per ogni tabella vengono indicati i singoli campi ( tracciato record ). Individuazione delle relazioni Come abbiamo già detto, per individuare le relazioni si analizzano i verbi che figurano nelle frasi scritte in fase di analisi, dato che ogni relazione è indicata generalmente da un verbo che permette di connettere due o più entità. Tra tutte le entità individuate nella prima fase di progetto è necessario individuare almeno una relazione che le lega, altrimenti risultano isolate. A partire dalla matrice entità-entità si deve:
- definire e individuare tutte le relazioni. classificare le relazioni in termini di:
- cardinalità , per quantificare le relazioni tra le entità misurando come molte istanze di una entità sono relazionate a singole istanze di un’altra entità;
- opzionalità , per verificare se la relazione deve esistere oppure è opzionale;
- direzione , per individuare la direzione della relazione (per esempio da studente a voto);
- dipendenza, per stabilire se una relazione dipende da una o più altre relazioni. Una volta individuate le entità, si definiscono le possibili gerarchie in termini di:
