Un’entità può essere definita come una cosa capace di un’esistenza indipendente che può essere identificata in modo unico. Un’entità è un’astrazione dalle complessità di un dominio. Quando parliamo di un’entità, normalmente parliamo di qualche aspetto del mondo reale che può essere distinto da altri aspetti del mondo reale.
Un’entità è una cosa che esiste fisicamente o logicamente. Un’entità può essere un oggetto fisico come una casa o un’automobile (esistono fisicamente), un evento come la vendita di una casa o il servizio di un’automobile, o un concetto come una transazione o un ordine di un cliente (esistono logicamente come concetto). Anche se il termine entità è quello più comunemente usato, seguendo Chen dovremmo davvero distinguere tra un’entità e un’entità-tipo. Un’entità-tipo è una categoria. Un’entità, in senso stretto, è un’istanza di un dato tipo di entità. Di solito ci sono molte istanze di un tipo di entità. Poiché il termine entità-tipo è un po’ ingombrante, la maggior parte delle persone tende ad usare il termine entità come sinonimo di questo termine
Le entità possono essere pensate come sostantivi. Esempi: un computer, un impiegato, una canzone, un teorema matematico, ecc. Le relazioni possono essere pensate come verbi che collegano due o più nomi. Esempi: una relazione di proprietà tra un’azienda e un computer, una relazione di supervisione tra un impiegato e un dipartimento, una relazione di esecuzione tra un artista e una canzone, una relazione di prova tra un matematico e una congettura, ecc.
L’aspetto linguistico del modello sopra descritto è utilizzato nel linguaggio dichiarativo di interrogazione di database ERROL, che imita i costrutti del linguaggio naturale. La semantica e l’implementazione di ERROL sono basate sull’algebra relazionale rimodellata (RRA), un’algebra relazionale che è adattata al modello entità-relazioni e cattura il suo aspetto linguistico.
Le entità e le relazioni possono entrambe avere attributi. Esempi: un’entità dipendente potrebbe avere un attributo Social Security Number (SSN), mentre una relazione provata potrebbe avere un attributo data.
Tutte le entità eccetto quelle deboli devono avere un insieme minimo di attributi che identificano in modo univoco e che possono essere usati come chiave unica/primaria.
I diagrammi entità-relazione non mostrano singole entità o singole istanze di relazioni. Piuttosto, mostrano insiemi di entità (tutte le entità dello stesso tipo di entità) e insiemi di relazioni (tutte le relazioni dello stesso tipo di relazione). Esempi: una particolare canzone è un’entità; l’insieme di tutte le canzoni in un database è un insieme di entità; la relazione mangiata tra un bambino e il suo pranzo è una relazione singola; l’insieme di tutte queste relazioni bambino-pranzo in un database è un insieme di relazioni.In altre parole, un insieme di relazioni corrisponde ad una relazione in matematica, mentre una relazione corrisponde ad un membro della relazione.
Possono essere indicati anche alcuni vincoli di cardinalità sugli insiemi di relazioni.
Mappatura del linguaggio naturaleModifica
Chen ha proposto le seguenti “regole empiriche” per la mappatura delle descrizioni in linguaggio naturale nei diagrammi ER: “Inglese, cinese e diagrammi ER” di Peter Chen.
| Struttura grammaticale inglese | Struttura ER |
|---|---|
| Nome comune sostantivo | Tipo di entità |
| Sostantivo perfetto | Entità |
| Verbo transitivo | Tipo di relazione |
| Verbo intransitivo | Tipo di attributo |
| Aggettivo | Attributo per entità |
| Avverbio | Attributo per relazione |
La vista fisica mostra come i dati sono effettivamente memorizzati.
Relazioni, ruoli e cardinalitàModifica
Nel documento originale di Chen dà un esempio di una relazione e dei suoi ruoli. Descrive una relazione “matrimonio” e i suoi due ruoli “marito” e “moglie”.
Una persona gioca il ruolo di marito in un matrimonio (relazione) e un’altra persona gioca il ruolo di moglie nel (medesimo) matrimonio. Queste parole sono sostantivi. Non è una sorpresa; dare un nome alle cose richiede un sostantivo.
La terminologia di Chen è stata applicata anche a idee precedenti. Le linee, le frecce e le zampe di gallina di alcuni diagrammi devono più ai precedenti diagrammi di Bachman che ai diagrammi di relazione di Chen.
Un’altra estensione comune al modello di Chen è quella di “nominare” relazioni e ruoli come verbi o frasi.
Role namingEdit
È anche diventato prevalente nominare i ruoli con frasi come is the owner of e is owned by. I sostantivi corretti in questo caso sono proprietario e possesso. Così persona gioca il ruolo di proprietario e auto gioca il ruolo di possesso piuttosto che persona gioca il ruolo di, è il proprietario di, ecc.
L’uso dei sostantivi ha un beneficio diretto quando si generano implementazioni fisiche da modelli semantici. Quando una persona ha due relazioni con l’automobile, allora è possibile generare nomi come owner_person e driver_person, che sono immediatamente significativi.
CardinalitiesEdit
Le modifiche alla specifica originale possono essere utili. Chen ha descritto le cardinalità look-across. Per inciso, la notazione Barker-Ellis, usata in Oracle Designer, usa same-side per la cardinalità minima (analoga all’opzionalità) e il ruolo, ma look-across per la cardinalità massima (la zampa di gallina).
In Merise, Elmasri & Navathe e altri c’è una preferenza per same-side per i ruoli e le cardinalità sia minime che massime. Ricercatori recenti (Feinerer, Dullea et al.) hanno dimostrato che questo è più coerente quando applicato a relazioni n-arie di ordine maggiore di 2.
In Dullea et al. si legge “Una notazione ‘look across’ come quella usata nell’UML non rappresenta efficacemente la semantica dei vincoli di partecipazione imposti alle relazioni dove il grado è superiore a quello binario.”
In Feinerer si dice “I problemi sorgono se operiamo sotto la semantica look-across come usata per le associazioni UML. Hartmann indaga questa situazione e mostra come e perché diverse trasformazioni falliscono”. (Anche se la “riduzione” menzionata è spuria in quanto i due diagrammi 3.4 e 3.5 sono di fatto gli stessi) e anche “Come vedremo nelle prossime pagine, l’interpretazione look-across introduce diverse difficoltà che impediscono l’estensione di semplici meccanismi da associazioni binarie a n-arie.”
La notazione di Chen per la modellazione delle relazioni tra entità usa rettangoli per rappresentare gli insiemi di entità, e diamanti per rappresentare le relazioni appropriate agli oggetti di prima classe: essi possono avere attributi e relazioni proprie. Se un insieme di entità partecipa ad un insieme di relazioni, sono collegati con una linea.
Gli attributi sono disegnati come ovali e sono collegati con una linea ad esattamente un’entità o un insieme di relazioni.
I vincoli di cardinalità sono espressi come segue:
- una doppia linea indica un vincolo di partecipazione, totalità o surjettività: tutte le entità dell’insieme di entità devono partecipare ad almeno una relazione nell’insieme di relazioni;
- una freccia dall’insieme di entità all’insieme di relazioni indica un vincolo di chiave, cioè iniettività: ogni entità dell’insieme di entità deve partecipare ad almeno una relazione nell’insieme di relazioni.e. iniettività: ogni entità dell’insieme di entità può partecipare al massimo ad una relazione nell’insieme di relazioni;
- una linea spessa indica entrambe, cioè bijettività: ogni entità dell’insieme di entità è coinvolta esattamente in una relazione.
- un nome sottolineato di un attributo indica che è una chiave: due diverse entità o relazioni con questo attributo hanno sempre valori diversi per questo attributo.
Gli attributi sono spesso omessi perché possono ingombrare un diagramma; altre tecniche di diagrammi spesso elencano gli attributi delle entità all’interno dei rettangoli disegnati per gli insiemi di entità.
Tecniche di convenzione di diagramma correlate:
- notazione di Bachman
- notazione di Barker
- EXPRESS
- IDEF1X
- notazione a piede di porco (anche notazione Martin)
- (min, max)-notazione di Jean-Raymond Abrial nel 1974
- Diagrammi di classeUML
- Merise
- Modellazione oggetto-ruolo
Notazione piede di corvoModifica
La notazione piede di corvo, il cui inizio risale ad un articolo di Gordon Everest (1976), è usato nella notazione di Barker, Structured Systems Analysis and Design Method (SSADM) e nell’ingegneria informatica. I diagrammi a zampa di gallina rappresentano entità come caselle, e le relazioni come linee tra le caselle. Forme diverse alle estremità di queste linee rappresentano la cardinalità relativa della relazione.
La notazione del piede di corvo è stata usata nello studio di consulenza CACI. Molti dei consulenti di CACI (incluso Richard Barker) si sono successivamente trasferiti a Oracle UK, dove hanno sviluppato le prime versioni degli strumenti CASE di Oracle, introducendo la notazione ad un pubblico più ampio.
Con questa notazione, le relazioni non possono avere attributi. Dove necessario, le relazioni sono promosse a entità a sé stanti: per esempio, se è necessario catturare dove e quando un artista ha eseguito una canzone, viene introdotta una nuova entità “performance” (con attributi che riflettono il tempo e il luogo), e la relazione di un artista a una canzone diventa una relazione indiretta attraverso la performance (artist-performs-performance, performance-features-song).
Tre simboli sono usati per rappresentare la cardinalità:
- l’anello rappresenta “zero”
- il trattino rappresenta “uno”
- la zampa di gallina rappresenta “molti” o “infinito”
Questi simboli sono usati in coppia per rappresentare i quattro tipi di cardinalità che un’entità può avere in una relazione. Il componente interno della notazione rappresenta il minimo, e il componente esterno rappresenta il massimo.
- anello e trattino → minimo zero, massimo uno (opzionale)
- trattino e trattino → minimo uno, massimo uno (obbligatorio)
- anello e zampa di gallina → minimo zero, massimo molti (opzionale)
- trattino e zampa di gallina → minimo uno, massimo molti (obbligatorio)
Problemi di usabilità del modelloModifica
Nell’uso di un database modellato, gli utenti possono incontrare due problemi ben noti in cui i risultati restituiti significano qualcosa di diverso dai risultati assunti dall’autore della query.
Il primo è la ‘trappola a ventaglio’. Si verifica con una tabella (master) che si collega a più tabelle in una relazione uno-a-molti. Il problema deriva il suo nome dal modo in cui il modello appare quando è disegnato in un diagramma entità-relazioni: le tabelle collegate “si estendono a ventaglio” dalla tabella principale. Questo tipo di modello è simile ad uno schema a stella, un tipo di modello usato nei magazzini di dati. Quando si cerca di calcolare somme su aggregati usando SQL standard sulla tabella principale, possono verificarsi risultati inaspettati (ed errati). La soluzione è aggiustare il modello o l’SQL. Questo problema si verifica soprattutto nei database per i sistemi di supporto alle decisioni, e il software che interroga tali sistemi a volte include metodi specifici per gestire questo problema.
Il secondo problema è una “trappola dell’abisso”. Una trappola dell’abisso si verifica quando un modello suggerisce l’esistenza di una relazione tra tipi di entità, ma il percorso non esiste tra certe occorrenze di entità. Per esempio, un edificio ha una o più stanze, che contengono zero o più computer. Ci si aspetterebbe di poter interrogare il modello per vedere tutti i computer dell’edificio. Tuttavia, i computer che non sono attualmente assegnati ad una stanza (perché sono in riparazione o da qualche altra parte) non sono mostrati nella lista. Un’altra relazione tra Edificio e Computer è necessaria per catturare tutti i computer nell’edificio. Quest’ultimo problema di modellazione è il risultato di un fallimento nel catturare nel modello tutte le relazioni che esistono nel mondo reale. Vedere Entity-Relationship Modelling 2 per i dettagli.