Il modello er by Antonio Santoro

Il modello Entità-Relazioni Nella progettazione di un database bisogna, come in ogni attività di progettazione, partire dalla costruzione di un modello della realtà che sarà oggetto del nostro intervento progettuale. Un modello è sempre una rappresentazione astratta della realtà che si vuole studiare; astratta perché si estrapolano dall’oggetto del nostro studio solo gli elementi che si ritengono più significativi trascurando tutti quegli aspetti che riteniamo ininfluenti dal nostro punto di vista. In particolare, nella progettazione di un database, dobbiamo valutare quali sono gli oggetti rispetto ai quali vogliamo gestire le informazioni, quali sono queste informazioni in dettaglio, quali relazioni le regolano. Uno dei modelli più diffusi è il modello ER, dall’inglese Entity-Relationship tradotto in italiano con EntitàAssociazioni o anche Entità-Relazioni. In questo modello individuiamo anzitutto gli oggetti sui quali raccoglieremo informazioni. Tali oggetti sono detti Entità. Vengono rappresentati nel modello con un rettangolo del seguente tipo in cui nella parte superiore vi è il nome dell’entità; nella parte inferiore inseriremo le caratteristiche o informazioni parziali che riterremo necessario trattare per ogni entità: tali informazioni sono dette attributi.

Entità1 Chiave

{PK}

Attributo1 Attributo2 Attributo3 Attributo4

Procediamo operando su un esempio concreto: supponiamo di voler creare un database per gestire i ritardi degli allievi di una scuola. La prima entità da gestire sarà lo studente Studente Chiave

{PK}

Attributo1 Attributo2 Attributo3 Attributo4

I dati che riteniamo gestire sono sicuramente quelli anagrafici Studente Matricola Nome Cognome Attributo3 Attributo4

{PK}

Notiamo che abbiamo inserito un campo matricola: per evitare problemi di omonimia abbiamo bisogno di individuare un’informazione che individui in maniera univoca ogni singolo studente. Utilizzeremo una matricola, ogni allievo avrà una matricola diversa da quella degli altri. Un attributo che consente di individuare in modo univoco ogni singola istanza di una entità viene detto chiave primaria (in inglese Primary Key da cui il simbolo PK nel simbolo dell’entità). Occorrono poi informazioni sull’indirizzo dell’allievo: è preferibile non scegliere mai come attributo un’informazione complessa cioè composta da più sottoinformazioni. Suddivideremo all’ora l’informazione relativa all’indirizzo in più attributi elementari. Studente Matricola

{PK}

Nome Cognome Via Numero civico Città Provincia CAP

Certamente occorre un recapito telefonico: useremo un attributo per il telefono fisso ed uno per il cellulare. Raccogliamo anche l’email Studente Matricola Nome Cognome Telefono fisso Cellulare E-mail Via Numero civico Città Provincia CAP

{PK}

Notiamo come questi tre attributi siano un esempio tipico di informazioni che possono essere non reperibili, sia perché ad esempio non esistono (non è detto che lo studente abbia un indirizzo di posta elettronica) sia perché potrebbe rifiutarsi di fornirle. Non è detto dunque che un attributo vada necessariamente valorizzato. Abbiamo certamente bisogno dei dati sui suoi genitori: in una prima ipotesi potremmo essere tentati di inserire i dati dei genitori come attributi dell’entità studente. Ciò porta ad alcuni problemi. Ad esempio una persona può essere genitore di più allievi per cui avremmo più istanze dell’entità studente contenenti le stesse informazioni inutilmente replicate (ridondanza) con inutile occupazione di spazio, possibilità di errori a causa della necessità di dover ripetere la immissione degli stessi dati. Un altro problema della ridondanza deriverebbero dalla necessità di dover aggiornare i dati. Supponiamo che un genitore comunichi il cambio del numero di cellulare. L’impiegato della segreteria dovrebbe ricordarsi di aggiornare la relativa registrazione per ogni allievo: una dimenticanza porterebbe alla conservazione in alcuni casi di dati non aggiornati ; errori del genere porterebbero rapidamente alla inconsistenza dei dati registrati. Per queste motivazioni decidiamo di inserire un’entità genitore separata.

Studente Matricola

{PK}

Genitore Codice genitore {PK}

Nome

Cognome

Telefono fisso

Cellulare

E-mail

Via

Numero civico

Città

Provincia

CAP

Siamo costretti a replicare gli attributi relativi a recapiti telefonici e indirizzo perché non è detto che studente e genitore convivano. Come facciamo per i ritardi? Abbiamo certamente bisogno di registrare dati relativi ad ogni ritardo (data, motivazione, entità ritardo, accompagnamento da parte del genitore) ma è difficile pensare che possano essere attributi dell’entità studente poiché non sappiamo a priori quanto spazio riservare per ogni allievo: potrebbe essere un allievo virtuoso che non avrà mai bisogno di registrazioni relative a ritardi o invece essere una persona indisciplinata che farà registrare molte assenze. Da cui la necessità di avere un’entità a parte.

Ritardo Chiave

{PK}

data Motivazione Accompagnato Attributo4

Si pone ora il problema che l’entità del ritardo sia un concetto troppo ambiguo che potrebbe portare a registrazione di diversa natura con libera interpretazione da parte dei singoli operatori e conseguente possibile inconsistenza dei dati. Per evitare ciò si vuole che i vari operatori si conformino alle stesse regole per cui le tipologie di entità del ritardo vengono congelate in varie istanze di una entità Tipologia ritardo. Tipologia Ritardo Codice Tipologia

{PK}

gravità

Abbiamo dunque suddiviso le informazioni fra le varie entità. E’ necessario però che queste entità siano in relazione fra loro, relazione che imporrà di prevedere dei meccanismi nel database che consentiranno di risalire dai dati dell’ allievo a quelli del genitore e così via. Evidenzieremo queste relazioni congiungendo le varie entità con delle linee Verbo

Una freccia indica il verso della relazione ed un verbo dà generalmente il nome all’associazione.

Ritardo Chiave

{PK}

Tipologia Ritardo data

avere

Codice tipologia

{PK}

Motivazione gravità Accompagnato Attributo4

Studente Matricola

Genitore

{PK}

Codice genitore {PK}

Nome

Cognome

Telefono fisso

Cellulare

E-mail

Via

Numero civico

avere

Numero civico

Città

Provincia

CAP

Un’altra informazione che può essere fornita con il simbolismo delle associazioni è quella relativa alla cardinalità della relazione: ovvero il numero delle istanze della entità di partenza e il numero delle istanze della entità di destinazione che possono essere associate. Ad esempio un singolo studente si può rendere protagonista di più ritardi mentre un ritardo andrà attribuito ad un solo allievo: si dice che le due entità sono legate da una relazione uno a molti: un solo allievo più ritardi (attenzione a non fraintendere: molti non significa che debbano essere molte istanze , basta che siano più di una).

Inoltre si esprime anche la obbligatorietà o facoltatività dell’associazione: una istanza di una entità deve necessariamente essere associata ad una istanza dell’altra entità nel primo caso mentre nel secondo caso è solo un eventualità possibile. Nell’esempio dello studente uno studente può far registrare ritardi (ma non è necessario: un allievo potrebbe essere virtuoso e presentarsi sempre puntuale), invece se c’è la registrazione di un ritardo questa deve essere necessariamente associata ad uno degli studenti. Scriveremo 1 ed N sulla linea di collegamento per indicare la relazione una a molti e suddivideremo la linea in tre sottolinee nei pressi dell’entità che presenta più istanze associate. Per la obbligatorietà disegneremo una linea continua e per la facoltatività useremo una linea tratteggiata come nell’esempio seguente.

Studente

Ritardo

fare

Per verificare la bontà del lavoro di individuazione delle associazioni si procede spesso ad esprimerle in linguaggio naturale usando delle regole di lettura. Nel nostro caso “lo studente può fare uno o più ritardi, viceversa un ritardo deve essere fatto da un solo studente”. Le regole di lettura sono semplici:    

ho usato può quando l’entità di destinazione era collegata con una linea tratteggiata, ho usato deve quando l’entità di destinazione era collegata con una linea intera ho usato uno o più se la entità di destinazione presentava la simbologia della molteplicità ho usato un solo se la entità di destinazione presentava la simbologia della singolarità

Nel caso della relazione fra entità Ritardo ed entità Tipologia è chiaro che un ritardo sarà di un solo tipo, non può ricadere contemporaneamente in più tipologie, mentre una tipologia di gravità potrà riferirsi a più ritardi. Inoltre un ritardo sarà necessariamente associato ad una tipologia mentre una tipologia di ritardo potrebbe non verificarsi mai quindi non deve necessariamente essere associata a qualche registrazione di ritardo.

Ritardo

Tipologia Ritardo

Un ritardo deve avere una ed una sola Tipologia, una Tipologia può essere di uno o più ritardi. Nel caso di Studente e genitore, uno studente ha uno o più genitori (padre e madre) mentre un genitore può avere più figli iscritti a scuola. In tal caso abbiamo una relazione molti a molti (ricordate che molti significa più di uno).

Per quanto riguarda obbligatorietà/facoltatività un genitore deve avere necessariamente degli allievi iscritti nella scuola altrimenti le registrazioni relative non hanno senso nel database mentre un allievo potrebbe non essere associato ad un genitore ( non perché è orfano poiché in tal caso ci sarebbe comunque una persona che esercita la patria potestà ma perché l’allievo può essere un maggiorenne).

studente

genitore

avere

Un allievo può avere uno o più genitori, un genitore deve avere uno o più allievi. In generale, per motivi di efficienza ed efficacia si preferisce evitare le associazioni molti a molti scomponendole in due associazioni 1 a molti mediante l’introduzione di una ulteriore entità. Ad esempio potremmo introdurre un’entità Patria Potestà

studente

Patria potestà

riferirsi

1 genitore

esercitare

Una patria potestà deve riferirsi ad un solo studente mentre uno studente può essere riferito ad una o più patrie potestà; un genitore deve esercitare una o più patrie potestà mentre una patria potestà deve essere esercitata da un solo genitore. Notate come in questo caso la entità Patria potestà serve solo a legare le altre due entità e non ha attributi propri ma in altri casi può essere utilizzata per gestire altre informazioni mediante l’individuazioni di ulteriori attributi per l’entità di separazione. Consideriamo ad esempio la seguente situazione

Attore

Film

avere

Potremmo introdurre l’entità Partecipazione

Attore

Partecipazione

avere

1 Film

avere

Nell’entità partecipazione possiamo individuare l’attributo Protagonista per memorizzare se la partecipazione di un artista in un film è stata da protagonista o da comprimario. Aggiungiamo un’entità classe per registrare quale classe è frequentata dall’allievo e poiché la classe è composta dal numero dell’anno , una lettera per la sezione ed una sigla per l’indirizzo, per le medesime motivazioni che hanno portato all’individuazione dell’entità ritardo introduciamo l’entità Indirizzo che conterrà le denominazioni fra le quali l’operatore che registra dovrà scegliere. Adesso possiamo completare il modello ER del nostro esempio nella figura seguente.

Ritardo 1

fare

Chiave

Tipologia Ritardo

{PK}

data

Codice tipologia

{PK}

gravità

appartenere

Motivazione Accompagnato Attributo4

Genitore

Studente Patria potestà Matricola

{PK}

Codice ritardo

riferirsi

Nome

Codice genitore {PK}

{PK}

esercitare

gravità

Nome Cognome

Cognome Telefono fisso Telefono fisso Cellulare Cellulare E-mail E-mail

Classe

Via N Numero civico Città

appartenere

Anno

Indirizzo Codice{PK}

Numero civico

Denominazione

Città

appartenere Sezione

Via

Provincia Provincia CAP CAP