Progettazione ER: perché è importante e come pianificarla

Come pianificare bene tramite l'ER



Per chi frequenta l’affascinante mondo della programmazione da un po’ sicuramente il concetto di “progettazione” è ormai ben radicato fra le necessità basilari di pianificazione dei progetti. Per chi invece fosse ancora un po’ nuovo, o semplicemente abbia appreso nozioni in maniera autodidatta, il concetto di “progettazione concettuale” è uno dei punti più importanti per poter organizzare bene il lavoro da svolgere.

In particolare il modello ER della progettazione concettuale permette di rendere “fisico” l’astratto di un procedimento logico, o di poter rendere in forma visiva le fasi di un progetto.

Progettazione ER: cosa significa e come si usa

ER sta per “Entity-Relationship”, che viene spesso tradotto in italiano con il modello “Entità-Relazione”. La Relazione però è un concetto diverso da quello che in realtà è quello dell’ER: modello “Entità-Associazione” è la traduzione più affine al vero significato.

Come si usa l’ER, però? In quali circostanze e in che modalità? Su questo è bene riflettere un momento sul più semplice “diagramma di flusso”, tipico degli algoritmi più basilari.

Il diagramma di flusso funziona con uno start, o inizio: si segue il senso delle frecce in uscita, si raggiunge il blocco successivo eseguendo l’azione al suo interno e si ripete questo processo fino ad arrivare all’end, o blocco finale. L’uso di un diagramma di flusso è semplice da capire: qualsiasi cosa che richieda la descrizione di un procedimento, ragionamento o semplice rapportare fisicamente un concetto astratto, può essere descritto tramite un diagramma di flusso.

Per la progettazione ER il modello riesce a distinguere le “entità” (ovvero un elemento dei dati, quindi cose, siano esse astratte o concrete) dagli “attributi”, ovvero le particolarità dell’entità (le qualità, gli aggettivi) e mette in evidenza le “associazioni”, ovvero i legami logici fra le entità nominate.

A qualcuno fra i più navigati potrebbe venire in mente la struttura di un database relazionale, dove le singole tabelle sono relazionate fra loro da connessioni logiche. In questo senso, il modello ER è molto simile e risulta estremamente utile proprio nell’uso con questo tipo di database, per ovvi motivi.

Come pianificare una progettazione ER

Immaginiamo di dover rendere su carta la progettazione di un database relazionale per una serie di corsi di formazione. Dovremo innanzitutto valutare le entità, ovvero i corsi, i quali saranno scritti all’interno un rettangolo, con possibilmente degli attributi collegati: high-end, low-end, principianti, intermedi, avanzati, con certificazione ecc. Ogni “categoria” e qualità che il corso avrà sarà dunque un attributo e, a differenza dell’entità, dovrà essere scritta in un’ellisse da collegare poi all’entità interessata. Nel caso di un database relazionale, ad esempio, ci sarà una tabella con la lista di tutti i corsi e una tabella rappresentante le caratteristiche del corso, ovvero gli eventuali attributi, collegate fra loro.

Infine, dovremo ovviamente rendere visibile l’inserimento dei corsi in un database di ricerca, quindi dovremo necessariamente avere un’altra entità chiamata “database” (nuovamente, anche questa in un rettangolo) e almeno un’altra entità chiamata “utenti”, nel caso si voglia suddividere la ricerca in base al numero di utenti, o la loro provenienza, o altri tipi di dati relativi a chi frequenta.

Abbiamo dunque 3 tipi di entità: corsi, database, utenti. Semplificando molto, sicuramente lo schema somiglierà a qualcosa come:

I KPI sono dei misuratori che danno l’idea precisa ed essenziale dello stato dell’arte della nostra iniziativa.

Questo è uno schema ovviamente molto semplificato.

Immaginando di dover interagire con un database contenente anche il linguaggio utilizzato o la materia insegnata nei corsi (per favorire magari una ricerca relativa a delle ricette contenenti “CSS”, oppure “Sviluppo front-end”) dovrà essere specificato ogni linguaggio da inserire nel database e successivamente collegare. In questo caso, il particolare oggetto dell’entità viene definito istanza dell’entità e non necessita di accortezze.

Manca soltanto lo spiegare quindi in che parte appare l’associazione: osservando le frecce dello schema sopra, sarà possibile capire che “stabilire il tipo di corso” e “inserire corso e utenti nel database” sono associate dall’ovvio collegamento fra il corso e la necessità d’inserire il numero di utenti attualmente iscritti o i posti ancora disponibili per prenotarsi nella pagina che verrà interessata. L’associazione logica sarà, in questo caso, far vedere che il corso è tuttora aperto (o meno, nel caso fosse pieno) all’iscrizione.

Come già detto, le associazioni non sono altro che i legami logici e vengono raffigurati dentro un rombo, collegato alle entità che l’associazione collega.

Qualche piccolo accorgimento sulle associazioni

Le associazioni possono essere fra più elementi ed è importante capire quale sia la loro cardinalità, ovvero l’entità verso cui l’associazione viene svolta. Nel caso del corso e del database, la domanda implicita è “il corso dove va inserito?” e dunque si parla di Corso -> Database come associazione (potete anche rappresentarle con delle lettere se vi aiuta, quindi parliamo di corsi come C e di Database come D) ovvero “C a D”. Se invece la domanda posta fosse stata “cosa va dentro il database?” l’associazione sarebbe stata Database -> Corso, con cardinalità invertita, ovvero “D a C”.

Altro elemento molto importante: anche le associazioni possono avere gli attributi. Si pensi ad esempio di dover inserire il corso nel database interno e in un database esterno, magari collegato ad altri siti o inserito in un macro database di tutti i corsi d’Italia. In questo caso l’associazione potrà avere le due accezioni di “database interno” e “database esterno”, le quali rappresenterebbero gli attributi dell’associazione.

Persino gli stessi attributi possono avere altri attributi collegati, come nel caso dell’attributo “con certificazione” che può avere come ulteriori attributi “nazionale”, “internazionale” e via dicendo.

In conclusione

La progettazione ER è estremamente utile in moltissime occasioni, specie nei casi dove è presente un Database Relazionale e può sia semplificare il lavoro che snellirlo e renderlo più chiaro. Specie in progetti multiteam, o dove sono presenti più persone, l’ER rende chiaro a tutti quali procedimenti attuare e permette di far “visualizzare” i ragionamenti dietro un determinato modo di agire anche ad altri.

Imparare a pianificare bene tramite l’ER è una delle basi su cui costruire tutto il resto.

Prenota un appuntamento