Modello E-R
Da Wikipedia, l'enciclopedia libera.
Nel contesto della progettazione dei database, il modello entity-relationship (anche detto modello entità-relazione, modello entità-associazione o modello E-R) è un modello per la rappresentazione concettuale dei dati ad un alto livello di astrazione. Viene spesso utilizzato nella prima fase della progettazione di una base di dati in cui è necessario tradurre le informazioni risultanti dall'analisi di un determinato dominio in uno schema concettuale. Il modello E-R si basa su un insieme di concetti molto vicini alla realtà di interesse: quindi facilmente intuibili dai progettisti (e in genere considerati sufficientemente comprensibili e significativi anche per i non-tecnici), ma non non implementabili sugli elaboratori. Infatti, pur essendo orientato alla progettazione di basi di dati, il modello prescinde dai criteri specifici di organizzazione fisica dei dati persistenti nei sistemi informatici. Esistono tecniche per la traduzione dei concetti ad alto livello (meglio comprensibili per gli umani) in concetti di più basso livello tipici dei vari modelli logici (ad esempio il modello relazionale) implementati nei diversi DBMS esistenti.
Il modello E-R ha rappresentato per lungo tempo (e forse ancora oggi) uno degli approcci più solidi per la modellazione di domini applicativi in ambito informatico; per questo motivo, è stato spesso usato anche al di fuori del contesto della progettazione di database, ed è stato utilizzato come modello di riferimento per numerose altre notazioni per la modellazione. Al modello E-R era ispirata, tra l'altro, la notazione OMT poi confluita in UML.
Indice |
[modifica] I costrutti principali del modello
Analisi dei principali costrutti del modello E-R: entità, associazioni e attributi.
[modifica] Entità
Rappresentano classi di oggetti (fatti, cose, persone,...) che hanno proprietà comuni ed esistenza autonoma ai fini dell'applicazione di interesse. Un'occorrenza di un'entità è un oggetto della classe che l'entità rappresenta. Non si parla qui del valore che identifica l'oggetto ma l'oggetto stesso. Un'interessante conseguenza di questo fatto è che un'occorrenza di entità ha un'esistenza indipendente dalle proprietà a esso associate. In questo il modello E-R presenta una marcata differenza rispetto al modello relazionale nel quale non possiamo rappresentare un oggetto senza conoscere alcune sue proprietà.
In uno schema ogni entità ha un nome che la identifica univocamente e viene rappresentata graficamente tramite un rettangolo con il nome dell'entità all'interno.
[modifica] Associazioni
Le associazioni rappresentano un legame tra due o più entità . Il numero di entità legate è indicato dal grado dell'associazione, un buono schema E/R è caratterizzato da una prevalenza di associazioni con grado 2. È possibile legare una entità con sé stessa (attraverso un'associazione ad anello), sia legare le stesse entità con più associazioni.
Di norma viene rappresentata graficamente da un rombo contenente il nome dell'associazione.
[modifica] Attributi
Un'entità è descritta usando una serie di attributi. Tutti gli oggetti della stessa classe entità hanno gli stessi attributi: questo è ciò che si intende quando si parla di oggetti simili. La scelta degli attributi riflette il livello di dettaglio con il quale vogliamo rappresentare le informazioni sulle entità. Per ogni attributo associato ad una classe entità, dobbiamo definire un dominio di possibili valori. Ad esempio, per l'attributo nome, il dominio potrebbe essere l'insieme delle stringhe di 15 caratteri. Per ciascuna classe entità, dobbiamo definire anche una chiave. La chiave è un insieme minimale di attributi che identificano univocamente una tupla all'interno del database. Potrebbe esserci più di una chiave, in questo caso si parla di chiavi candidate. La scelta però deve ricadere solo su una chiave candidata, detta chiave primaria. L'attributo si identifica con un ellisse al cui interno viene specificato il nome dell'attributo o anche semplicemente, nel caso di diagrammi complessi, indicandone solo il nome. In caso di chiave primaria, il nome dell'attributo viene sottolineato.
[modifica] Costruzioni dei schemi con i costrutti base
[modifica] Altri costrutti del modello
[modifica] Cardinalità delle associazioni
Vengono specificate per ciascuna entità che partecipa a un'associazione e dicono quante volte, in una relazione tra entità, un'occorrenza di una di queste entità può essere legata ad occorrenze delle altre entità coinvolte nell'associazione (indica il minimo e il massimo delle occorrenze).
[modifica] Cardinalità degli attributi
È possibile definire vincoli di cardinalità anche sugli attributi, con due scopi:
- indicare opzionalità
- indicare attributi multivalore
Se la specifica del vincolo manca, come avviene nella maggioranza dei casi, la cardinalità dell'attributo è (1,1). Consideriamo il seguente esempio:
Nome
\------------- / (0,1)NumeroPatente
| IMPIEGATO |
------------- \ (0,n)NumeroTelefono
/
(1,n)
TitoloStudio
Poiché sul Nome manca la specifica del vincolo di cardinalità, vuol dire che la cardinalità è (1,1).
(0,1)NumeroPatente, vuol dire che un impiegato può avere una patente ma anche non averla, o meglio un impiegato può avere al più una patente.
(0,n)NumeroTelefono, vuol dire che un impiegato può avere molti numeri di telefono, ma può anche non aver alcun numero di telefono.
(1,n)TitoloStudio, vuol dire che un impiegato può avere molti titoli di studio, ma deve averne almeno uno.
[modifica] Identificatori delle entità
Costituiscono un sottoinsieme degli attributi di un'entità che identificano in maniera univoca ogni occorrenza della stessa entità. Un esempio può essere costituito dall'attributo 'CodiceFiscale' dell'entità 'CittadinoItaliano'. E' infatti noto che ogni occorrenza dell'entità 'CittandinoItaliano', ossia ogni cittadino residente nel territorio della Repubblica Italiana, può essere inequivocabilmente identificato dal suo codice fiscale. Questo significa che non possono esistere due cittadini italiani aventi lo stesso codice fiscale.
[modifica] Generalizzazioni
Rappresentano dei legami logici esistenti tra due o più entità. Tra le entità coinvolte si distinguono:
- una ed una sola entità padre
- una o più entità figlie
Le entità figlie costituiscono dei 'casi particolari' dell'entità padre. Ogni attributo dell'entità padre è anche attributo delle entità figlie, ma le entità figlie possono avere degli attributi che le differenziano dal padre e dai fratelli. Nell'esempio seguente si evidenzia che
- ogni persona è identificata da un codice fiscale ed è caratterizzata da un cognome, un nome e un'età
- ogni persona si distingue in uomo o donna
- nel caso particolare di un uomo può essere valutata anche la posizione militare, cosa che non avrebbe senso valutare per una donna.
Le generalizzazioni si distinguono in totali e parziali. Una generalizzazione è totale quando l'unione dei sottoinsiemi dei figli costituisce l'insieme del padre. Ad esempio la generalizzazione presentata in figura è totale poiché tutte le persone sono o uomini o donne, quindi, unendo i sottoinsiemi degli uomini e delle donne si ottiene l'insieme delle persone. Una generalizzazione è parziale quando invece l'unione dei sottoinsiemi dei figli non identifica globalmente l'insieme del padre. Ad esempio Un'entità padre 'MezzoDiLocomozione' con le entità figlie 'Bicicletta' ed 'Automobile' è una generalizzazione parziale, in quanto oltre alle biciclette ed alle automobili esistono altri mezzi di locomozione come ciclomotori, treni, navi, ecc. L'unione dei sottoinsiemi 'Bicicletta' e 'Automobile' non è quindi sufficiente per identificare l'insieme padre 'MezziDiLocomozione'.
Una generalizzazione può essere inoltre esclusiva o sovrapposta. Una generalizzazione è esclusiva quando l'intersezione dei sottoinsiemi dei figli è vuota; è invece sovrapposta quando l'intersezione dei sottoinsiemi dei figli non è vuota. La generalizzazione della figura è esclusiva poiché una persona può essere solo o uomo o donna e non entrambe le cose. Invece un'entità padre 'Lavoratore' con le entità figlie 'Impiegato' e 'Studente' identifica una generalizzazione sovrapposta in quanto possono esistere degli impiegati che sono contemporaneamente studenti. in conclusione una generalizzazione può essere:
- totale esclusiva (t,e)
- totale sovrapposta (t,s)
- parziale esclusiva (p,e)
- parziale sovrapposta (p,s)
[modifica] Documentazione di schemi E-R
Uno schema E-R non è quasi mai sufficiente da solo a rappresentare nel dettaglio tutti gli aspetti di un'applicazione per varie ragioni. Innanzitutto in uno schema E-R compaiono solo i nomi dei vari concetti in esso presenti ma questo può essere insufficiente per comprenderne il significato. Nel caso di schemi particolarmente complessi può accadere di non riuscire a rappresentare in maniera comprensibile ed esaustiva i vari concetti.
Per questo motivo risulta indispensabile corredare ogni schema E-R con una documentazione di supporto che possa servire a facilitare l'interpretazione dello schema stesso e a descrivere proprietà dai dati rappresentati che non possono essere espressi direttamente dai costrutti del modello. Ecco quindi l'esigenza di avere degli strumenti a completamento dello schema.
[modifica] Regole aziendali
Uno degli strumenti più usati dagli analisti di sistemi informativi per la descrizione di proprietà di un'applicazione che non si riesce a rappresentare direttamente con modelli concettuali è quello delle regole aziendali o business rules. Questa accezione deriva dal fatto che nella maggior parte dei casi quello che si vuole esprimere è proprio una regola del particolare dominio applicativo che stiamo considerando.
Il termine regola aziendale viene usato dagli analisti con un'accezione più ampia per indicare una qualunque informazione che definisce o vincola qualche aspetto di una applicazione. In particolare in base a una classificazione piuttosto consolidata, una regola aziendale può essere:
- la descrizione di un concetto rilevante per l'applicazione ovvero la definizione precisa di un'entità di un attributo o di un'associazione del modello E-R.
- un vincolo di integrità sui dati dell'applicazione , sia esso la documentazione di un vincolo espresso con qualche costrutto del modello E-R- (come la cardinalità di un'associazione o la descrizione di un vincolo non esprimibile direttamente con i costrutti del modello
- una derivazione ovvero un concetto che può essere ottenuto attraverso un'inferenza o un calcolo aritmetico da altri concetti dello schema
Per le regole del primo tipo è chiaramente impossibile definire una sintassi precisa e si fa in genere ricorso a frasi in linguaggio naturale. Queste regole vengono tipicamente rappresentate tramite forma di glossari, raggruppando le descrizioni in maniera opportuna.
Le regole che descrivono vincoli di integrità e derivazioni sono invece più adatte a definizioni formali con sintassi più o meno complesse. Dato però che non esistono standardizzazioni e che ogni formalismo scelto rischia di non essere sufficientemente espressivo faremo ricorso ancora a definizioni in linguaggio naturale avendo però cura di strutturare in maniera adeguata tali definizioni. In particolare le regole che descrivono vincoli di integrità possono essere espresse sotto forma di asserzioni ovvero affermazioni che devono essere sempre verificate nella nostra base di dati. Per motivi di chiarezza e per favorirne la costruzione tali affermazioni devono essere atomiche non possono essere decomposte in frasi che costituiscono ancora delle asserzioni. Inoltre poiché vengono usate per documentare uno schema E-R- le asserzioni vanno enunciate in maniera dichiarativa in una forma cioè che non suggerisca un metodo per soddisfarle. Questo è infatti un problema realizzativo e pertanto non pertinente alla rappresentazione concettuale. Quindi notazioni del sito se <condizione> allora <azione> non sono adatte a esprimere regole aziendali quando queste documentano uno schema E-R. Una struttura predefinita per enunciare regole aziendali sotto forma di asserzioni potrebbe essere invece la seguente:
- <concetto> deve / non deve <espressioni su concetti>
dove i concetti citati possono corrispondere o a concetti che compaiono nello schema E-R a cui si fa riferimento oppure a concetti definibili da essi.
Le regole aziendali che esprimono derivazioni possono essere espresse specificando operazioni (aritmetiche o di altro genere) che permettono di ottenere il concetto derivato. Una possibile struttura è quindi:
- <concetto> si ottiene <operazione su concetti>
[modifica] Tecniche di documentazione
La documentazione dei vari concetti rappresentati in uno schema ovvero le regole aziendali di tipo descrittivo può essere prodotta facendo uso di un dizionario dei dati. Esso è composto da due tabelle: la prima descrive le entità dello schema con il nome una definizione informale in linguaggio naturale, l'elenco di tutti gli attributi (con eventuali descrizioni associate) e i possibili identificatori. L'altra tabella descrive le associazioni con il nome, una loro descrizione informale, l'elenco degli attributi (con eventuali descrizioni) e l'elenco delle entità coinvolte insieme alla loro cardinalità di partecipazione.
Per quel che riguarda altre regole aziendali si può far ricorso ancora ad una tabella nella quale vengono elencate le varie regole specificando di volta in volta la loro tipologia. Risulta importante rappresentare tutte le regole che descrivono vincoli non espressi dallo schema ma risulta a volte utile rappresentare anche regole che documentano vincoli già espressi nello schema.
[modifica] Bibliografia
- Atzeni, Ceri, Paraboschi, Torlone. Basi Di Dati (Modelli e Linguaggi di Interrogazione). McGraw Hill, 2003
- Atzeni, Ceri, Fraternali, Paraboschi, Torlone. Basi Di Dati (Architetture e Linee Di Evoluzione). McGraw Hill, 2003
- Ramez Elmasri, Shamkant B. Navathe. Sistemi di basi di dati, fondamenti. Pearson - Addison Wesley, 2003
