# Database - Analisi Concettuale ## Modellare i Dati La **progettazione di un database** ha lo scopo di modellare e organizzare nelle memorie di massa del computer i dati necessari per gestire una specifica attività del mondo reale, come avviene, per esempio, nel caso della gestione di un’officina, di un reparto ospedaliero o del sistema contabile di un’azienda.L’attività di progettazione consente prima di tutto di costruire una rappresentazione astratta della realtà in modo indipendente dalla struttura dei dati. **Modellare i dati** significa realizzare una rappresentazione semplificata della realtà osservata o di un problema, individuandone gli elementi caratterizzanti e i legami che intercorrono tra essi. La progettazione di un modello di dati avviene a diversi **livelli di astrazione** dal problema considerato. * Il **livello concettuale** (o livello di oggetti) rappresenta la realtà dei dati e le relazioni tra essi attraverso uno schema. * Il **livello logico** (o livello di record) rappresenta il modo in cui i dati sono organizzati negli archivi: descrive quindi la composizione e il formato dei dati secondo la loro struttura logica. Il livello logico viene derivato dal livello concettuale applicando alcune semplici regole di trasformazione. * Il **livello fisico** rappresenta l’effettiva installazione degli archivi su disco: esso indica l’ubicazione dei dati nelle memorie di massa. Il livello fisico è quindi l’implementazione del livello logico sui supporti per la registrazione fisica dei dati. Il **modello concettuale** viene definito attraverso lo **schema** dei dati, cioè una rappresentazione sintetica (di solito presentata in forma grafica) degli elementi fondamentali che caratterizzano la realtà osservata. Questa rappresentazione è indipendente dai valori che verranno assegnati ai dati e dalle applicazioni che li utilizzano. Con il passaggio al **modello logico**, l’insieme dei dati viene dotato di una struttura che deve facilitare: * la **manipolazione** o il trattamento dei dati, cioè la possibilità di inserirli, modificarli e cancellarli; * l’**interrogazione**, cioè la possibilità di ritrovare i dati, richiesti da un’applicazione, in modo semplice e veloce. Queste strutture logiche di dati vengono poi implementate sulle memorie di massa, realizzando in pratica il **modello fisico**, rappresentato dai file registrati sul supporto di memoria.  Quindi, a partire dalla realtà considerata, si individuano i dati che sono significativi, in quanto la caratterizzano, e viene definito lo schema concettuale rappresentativo di tale realtà; le strutture logiche dei dati, derivate dallo schema concettuale, sono poi implementate e memorizzate negli archivi su un supporto fisico di registrazione (memorie di massa). ## Livello concettuale e modello entità/relazione La **progettazione concettuale**, cioè il primo livello di astrazione di una realtà, è la sintesi tra la visione degli **utenti** e la visione dei progettisti dell’applicazione. Essa deve possedere due caratteristiche opposte: da una parte deve essere assolutamente precisa per non lasciare dubbi in merito alle caratteristiche della base di dati che si sta progettando; dall’altra deve essere espressa con formalismi sufficientemente semplici da permetterne la lettura e la comprensione anche da parte di utenti non tecnici. Il modello entità/relazione ha queste caratteristiche. Il modello **entità/relazione**, introdotto nel 1976 dal matematico Peter P. Chen, è uno **strumento** per analizzare le caratteristiche di una realtà in modo indipendente dagli eventi che in essa accadono, cioè per costruire un modello concettuale dei dati indipendente dalle applicazioni che li usano. Si concretizza in una rappresentazione grafica, detta **schema E/R** *(Entity/Relationship).* <ex> Un esempio di modello entità/relazione è lo schema in figura, che descrive i prodotti forniti e i relativi fornitori.  </ex> Il pregio di questa rappresentazione risiede anche nel fatto che può essere descritta con frasi del linguaggio naturale. Come si vedrà, il modello dell’esempio precedente permette di affermare che: ogni fornitore può fornire uno o più prodotti; ogni prodotto deve essere fornito da un solo fornitore. Il modello entità/relazione, pur essendo di gran lunga il più utilizzato nella progettazione concettuale, non ha una rappresentazione standardizzata. In questo Capitolo sarà utilizzata una forma di rappresentazione che, in larga parte, fa riferimento ai simboli dell’UML, ma saranno indicati anche gli altri formalismi maggiormente diffusi. L’**UML** (*Unified Modeling Language*, “linguaggio unificato di modellazione”) è un linguaggio grafico per visualizzare, definire, specificare e documentare tutte le costruzioni di sistemi software. Gli **elementi di un modello entità/relazione** sono le entità, le relazioni e gli attributi. ### Entità L’**entità** è un oggetto (concreto o astratto) che ha un significato anche quando viene considerato in modo isolato ed è di interesse per la realtà che si vuole modellare. <ex> Sono entità una persona, un modello di automobile, un movimento contabile, una prova sostenuta da uno studente o una studentessa. </ex> Le entità possono essere classificate secondo un criterio di omogeneità definendo il tipo di entità attraverso un nome. <ex> Gli studenti e le studentesse di una scuola sono classificabili nel tipo di entità *Studente*, i diversi modelli di automobile sono classificabili nel tipo di entità *Automobile*. Il singolo studente e la singola automobile rappresentano un’**istanza** del tipo di entità *Studente* o *Automobile*: l’istanza non è altro che un esemplare di un tipo di entità. </ex> Nella rappresentazione grafica le entità sono identificate con un rettangolo contenente all’interno il nome dell’entità. ### Relazione La **relazione** è un legame che stabilisce un’interazione tra le entità. <ex> Nello schema sono rappresentate le due entità *Persona* (con le istanze *P1, P2, P3*) e *Automobile* (con le istanze *A1, A2, A3*) e un insieme di archi che rappresentano la relazione di possesso che si viene a stabilire tra le persone e le automobili. La relazione ha nome *Possedere* e ha un verso che è specificato dalle frecce che collegano l’entità *Persona* con l’entità *Automobile*.  Dall’esame della figura si può dire che: * *P1* possiede le automobili *A1* e *A2*; * *P2* non possiede alcuna automobile; * *P3* possiede l’automobile *A3*; * tra *Persona* e Automobile sussiste la relazione *Possedere*. Si possono inoltre generalizzare queste considerazioni esprimendole in linguaggio naturale con le seguenti frasi: * una persona può possedere una o più automobili; * un’automobile è posseduta da una sola persona. </ex> Nella **rappresentazione grafica** convenzionalmente usata, e adottata dal linguaggio UML, per indicare una relazione si usa una linea che unisce le due entità interessate; il nome della relazione compare sulla linea con il simbolo della punta di una freccia per indicare il senso di lettura della relazione. Di norma i nomi delle entità sono **sostantivi** mentre i nomi delle relazioni sono **verbi**: in questo modo si cerca di stabilire una corrispondenza tra la rappresentazione delle relazioni e le frasi del linguaggio naturale che le descrivono. Il nome della relazione rappresenta uno solo dei due versi della relazione, quello nel quale la lettura ha senso; il verso è precisato con il simbolo a forma di punta di freccia posto accanto al nome. Si conviene che il nome della relazione non rappresentata sia (nella maggior parte dei casi) lo stesso verbo posto nella forma passiva <ex> La relazione tra Persona e Automobile dell’esempio precedente può essere indicata secondo la rappresentazione UML in questo modo:  Tra l’entità Persona e l’entità Automobile esiste la relazione **Possedere**; la relazione tra l’entità Automobile e l’entità Persona può essere descritta mediante la forma passiva del verbo che rappresenta la precedente relazione. Quindi tra l’entità Automobile e l’entità Persona esiste la relazione **EsserePosseduta**, che di solito non è rappresentata esplicitamente nel grafico.  Un altro simbolismo usato per descrivere una relazione è dato da una linea che unisce le due entità con l’aggiunta, a metà della linea, di un **rombo** che contiene la descrizione della relazione.  </ex> Le relazioni hanno un **grado**, dato dal numero di entità che partecipano alla relazione. La relazione tra *Automobile* e *Persona* degli esempi precedenti è una relazione di grado 2, detta **relazione** **binaria**, ma naturalmente esistono relazioni di grado 1, 3 e di grado superiore. Le relazioni binarie sono le più diffuse ## Attributi di entità e relazioni Le proprietà delle entità e delle relazioni sono descritte attraverso gli **attributi**. <ex> Attributi per l’entità ***Automobile*** sono *Modello, Produttore, Cilindrata, Potenza, PrezzoDiListino*. </ex> Le principali caratteristiche di un attributo di un’entità sono: * il **formato**, che indica il tipo di valori che assume (i tre formati di base sono carattere, numerico, data/ora); * la **dimensione**, che indica la quantità massima di caratteri o cifre inseribili quando si valorizza l’attributo; * **l’opzionalità**, cioè l’attributo è obbligatorio se deve avere valore non nullo, come il nome di una persona in un’anagrafica, oppure facoltativo se sono accettabili valori nulli, come il titolo di studio. Il valore **nullo** (da non confondere con la stringa di caratteri *blank* o con un numero di valore zero) rappresenta un’informazione mancante in quanto inapplicabile (per esempio il numero del certificato elettorale di una persona minorenne) o sconosciuta (la data di consegna della merce ordinata ma non ancora arrivata in magazzino). I valori assunti dagli attributi determinano le diverse **istanze** dell’entità. L’insieme dei possibili valori assumibili da un attributo si chiama **dominio** dell’attributo. I valori appartenenti al dominio sono omogenei tra loro, cioè sono dello stesso tipo. <ex> La figura rappresenta l’entità **Automobile** con i relativi attributi. </ex> Anche le relazioni possono avere attributi. <ex> La rappresentazione degli attributi della Relazione **Acquisto** è la seguente.  </ex> La presenza di una reazione con attributi potrebbe essere indicativa della presenza di un’altra entità oltre a quelle già identificate. <ex> Un diverso progettista di dati potrebbe modellare la precedente situazione per mezzo delle entità *Persona*, *Automobile*, *Acquisto* e di due relazioni che collegano le tre entità: una tra *Persona* e *Acquisto* e una tra *Acquisto* e *Automobile*  </ex> La differente visione del problema non porta a una rappresentazione corretta in un caso ed errata nell’altro. Non solo: come si vedrà, applicando le regole di passaggio dal modello concettuale al modello logico, le due rappresentazioni portano alle stesse strutture di dati. Una regola molto importante richiede di definire in questa fase **solo gli attributi elementari** e quindi di non definire gli attributi che si ottengono con le elaborazioni, cioè gli attributi derivati. Il mancato rispetto della regola provoca inefficienza dovuta alle elaborazioni necessarie per aggiornare questo tipo di attributi. <ex> L’età di una persona è un attributo derivato dall’attributo elementare della data di nascita; il saldo di un conto corrente è derivato dalla somma algebrica degli importi dei movimenti effettuati sul conto. </ex> ### Chiave primaria Si indica con il termine **chiave** o **chiave primaria** un attributo, o un insieme minimale di attributi, che permette di distinguere le istanze di una stessa entità. <ex> Esempi di chiavi sono il codice di un prodotto, la matricola di un dipendente, la chiave composta dal codice studente insieme alla data e al codice della materia per le prove scolastiche. Nel caso delle due entità *Persona* e *Automobile* degli esempi precedenti, gli attributi *CodiceFiscale* e *Modello* sono rispettivamente le chiavi primarie. </ex> ## Relazioni tra entità La **molteplicità** di una relazione è il numero di possibili istanze di un'entità, messo in corrispondenza con un’istanza dell’altra entità che partecipa alla relazione. Il numero minimo e massimo di possibili istanze viene rappresentato mediante una coppia di valori separati da due punti o da virgola: 1..1, 0..1, 1..N. Al valore minimo e massimo sono associati gli importanti concetti di **obbligatorietà** e **cardinalità** della relazione. * Il **valore** **minimo** assume, in genere, uno dei due valori 0 e 1. Lo 0 indica che la partecipazione alla relazione è **facoltativa**, mentre il valore 1 indica che la partecipazione è **obbligatoria**. * Il **valore massimo** definisce la **cardinalità** della partecipazione alla relazione. Esso assume in genere uno dei due valori 1 oppure N per indicare una o molte partecipazioni alla relazione. La cardinalità può quindi essere a **uno** oppure a **molti** e pertanto le relazioni tra due entità si classificano nei seguenti tipi: * **relazione uno a uno** o **biunivoca**, indicata con **1:1**, quando ogni istanza della prima entità si deve associare a una sola istanza della seconda entità e viceversa; <ex> La relazione tra l’entità *Studente* e *Diploma* in una scuola superiore è biunivoca perché a ogni studente corrisponde un solo diploma e viceversa a un diploma corrisponde un solo studente. </ex> * **relazione uno a molti** o **semplice**, indicata con **1:N**, quando ogni istanza della prima entità si può associare a una o più istanze della seconda entità, mentre a ogni istanza della seconda entità si deve associare una sola istanza della prima; <ex> La relazione tra l’entità *Classe* e l’entità *Studente* in una scuola è di tipo uno a molti perché a ogni classe possono appartenere più studenti, mentre ogni studente appartiene a una sola classe. </ex> * **relazione molti a molti** o **complessa**, indicata con **N:N** (oppure con N:M), quando a ogni istanza della prima entità si possono associare una o più istanze della seconda entità e a ogni istanza della seconda entità si possono associare una o più istanze della prima. <ex> La relazione tra l’entità *Studente* e l’entità *Corso* in un’università è di tipo molti a molti perché uno studente può iscriversi a più corsi e ogni corso può essere frequentato da più studenti. </ex> Non è sempre facile attribuire questi valori e solo un attento esame della specifica situazione permette di definirli con esattezza. Un metodo utile per risolvere i dubbi consiste nel rappresentare la relazione con insiemi di istanze delle entità collegate con archi.