Flusso di progettazione

La progettazione di un database avviene tramite un processo che prevede le seguenti fasi:

• Dalla realtà di riferimento al modello concettuale: in questa fase si analizza il contenuto della richiesta/specifica e si produce un modello grafico, chiamato diagramma Entità/Relazione (E/R) che descrive il modello concettuale dei dati del sistema informatico;
• Dal modello concettuale al modello logico: dal diagramma E/R si fa discendere il diagramma logico, che va a rappresentare le tabelle corrispondenti alle entità e le loro relazioni.
• Dal modello logico al modello fisico: dal modello logico è possibile derivare direttamente le tabelle fisiche del database.

Qui lo schema di tutto il processo di progettazione:

Come si può vedere, lo sviluppo del modello concettuale non è in realtà la prima attività, ma viene svolta a seguito di una analisi della realtà di riferimento, della definizione ad alto livello dei requisiti del progetto attraverso un progetto svolto dall’analista funzionale e per i progetti con interfaccia utente, dallo UX designer. Quello che riceve quindi l’analista tecnico/programmatore è una descrizione di questo dominio, da cui parte la progettazione vera e propria del database.

Questo tipo di progettazione per gradi consente di concentrarsi su un problema alla volta, ed affinare/ottimizzare la soluzione verso un database concreto. Inoltre ci consente di essere indipendenti dalla tecnologia usata: la tecnologia infatti non deve costituire un vincolo alla modellizzazione, ma deve essere uno strumenti al servizio di essa.

Useremo questo processo anche per comprendere dettagliatamente come è fatto un database, cosa è una entità, cosa sono le chiavi primarie, come si creano relazioni tra tabelle.

Il diagramma E/R

Il diagramma Entità/Relazione è un formalismo grafico, ideato sin dagli anni 70 da Peter Chen, per risolvere il problema di realizzare un modello concettuale semplice ma efficace per descrivere la quasi totalità dei problemi esistenti.
Il modello è un grafo che mostra, per uno specifico problema, i seguenti ideogrammi:

• il rettangolo, per descrivere una entità, con un sostantivo
• da esso partono una serie di archi terminanti con un cerchio/ellisse ed una label, gli attributi dell’entità
• due entità sono collegate tra loro da un rombo, con un nome, che descrive, con un verbo, la relazione

Estrazione di entità, attributi e relazioni tramite il metodo di Abbott

Partiamo da questa descrizione del dominio del problema. “Si vuole realizzare un sistema informatico per gestire una libreria musicale. La musica è composta da album che hanno un titolo ed un anno di pubblicazione, disponibili su diversi tipo di supporto. Ogni album è creato da un autore, con nome e cognome, ed è composto da canzoni che hanno un titolo, gli album inoltre appartengono ad un genere musicale che ha una descrizione e sono pubblicati da una casa discografica che ha un nome. La casa discografica è legata a ciascun autore mediante un contratto di una certa durata. Un album può avere infine un booklet, che ha un certo numero di pagine”.

La descrizione del modello è in linguaggio naturale. Tramite una tecnica euristica (cioè basata per tentativi) ideata negli anni ’80 da Abbott, un informatico americano, è possibile tradurre questa descrizione in un modello E/R, in sostanza permette di tradurre le parole in entità, attributi e relazioni. Col metodo di Abbott usiamo una tabella di traduzione come questa:

Parola chiave	Componente di modello	Esempio
Sostantivo	Entità o Attributo	entità: Album, Canzone, Autore, ecc. attributi: titolo, descrizione, ecc.
Verbo	Relazione	Crea, è composto, appartengono

In base a questa tabella identifichiamo le seguenti entità (tra parentesi attributi):

• Album (titolo, anno)
• Genere (descrizione)
• Canzone (titolo)
• Casa discografica (nome)
• Supporto (descrizione)
• Autore (nome, cognome)
• Contratto (durata)

E le seguenti relazioni:

• Casa discografica PUBBLICA Album
• Album APPARTIENE a Genere
• Album COMPRENDE Canzone
• Autore CREA Album
• Supporto MEMORIZZA Album
• Contratto REGOLA Autore
• Casa discografica GESTISCE Contratti

Entità e attributi

Come facciamo a capire se un sostantivo è una entità o un attributo? E’ un problema molto comune, specie se non si ha una certa esperienza nella progettazione. Vi sono tuttavia alcuni criteri di facile individuazione:

• un sostantivo che ha delle proprietà (ad esempio “un album ha un titolo ed un anno”) è una Entità, altrimenti è presumibilmente un attributo.
• un sostantivo è una Entità solo se ha una sua identità e che non dipende dal valore dei suoi dati. Un supporto è una entità che ha un significato indipendentemente dal valore dei suoi attributi (es. il valore descrizione può essere cambiato da “CD” a “Compact Disc”) mentre la descrizione stessa è solo una etichetta con un valore. Se cambia, cambia il suo significato.
• un sostantivo è un Attributo se il suo valore è significativo solo nel contesto in cui viene nominato: ad esempio come facciamo a decidere se il supporto non possa essere un semplice attributo dell’album? Prima di tutto perché stiamo gestendo una libreria musicale, ed il tipo di supporto determina quindi una organizzazione prima degli album nel contesto fisico di riferimento. Inoltre abbiamo un criterio ancora più forte: lo stesso album potrebbe essere registrato su due supporti differenti, e dobbiamo evitare di avere due istanze dello stesso album che hanno un solo attributo differente (il supporto).

Relazioni

Una relazione tra due entità A e B indica che esiste una associazione di una specifica istanza di A con una specifica istanza di B. Ad esempio l’album ‘Dark side of the Moon’ ha una relazione con la canzone ‘Money’, pubblicato dalla casa discografica Harvest Records. La relazione consente di mantenere legami tra concetti distinti, al fine di ricostruire i dati che effettivamente ci servono quando li utilizziamo.

Le relazioni possono essere di questo tipo:

• uno a molti: una istanza dell’entità A può essere associata a più istanze dell’entità B, mentre una istanza di B è associata ad una sola istanza di A. E’ il caso dell’album, che contiene più canzoni, ma una canzone appartiene ad un solo album.
• molti a molti: una istanza dell’entità A può essere associata a più istanze di B, ma anche una istanza di B può essere associata a più istanze di A. E’ il caso del genere: un album può avere più generi, ed un genere è associabile a più di un album.
• uno a uno: una istanza di A è associata ad una sola istanza di B, e viceversa. E’ il caso del contratto, ne esiste uno per ogni autore e viceversa.

Le relazioni indicano anche dei vincoli: il diagramma deve descrivere quali relazioni sono obbligatorie (ovvero per una istanza di A ci deve essere ALMENO una istanza di B) o facoltative (una istanza di A non ha necessariamente una relazione con una istanza di B). Ad esempio alcuni album hanno il booklet, altri no.

Le associazioni tra entità permettono quindi di definire in modo chiaro ed efficiente i singoli concetti che strutturano i dati e le relazioni tra loro, e questo permetterà di inserire i dati in modo ordinato ed organizzato. In fase di ricerca dei dati sarà poi possibile usare le associazioni per estrarre i dati che ci interessano. Ad esempio:

• se vogliamo sapere tutti gli album pubblicati da un certo autore, useremo l’entità Autore e l’entità Album creando una lista coi soli dati che ci interessano.
• se vogliamo tutti gli autori contrattualizzati da una certa casa discografica, useremo Autore, Contratto e Casa Discografica
• Se vogliamo sapere tutte le canzoni pubblicate da una certa casa discografica, useremo Casa Discografica, Album e Canzone

E così via.

Mettendo insieme tutte le convenzioni grafiche e concettuali possiamo mettere insieme l’intero diagramma E/R di Chen:

Il Metodo di Abbott non va comunque considerato un metodo infallibile: il linguaggio naturale presenta interpretazioni ed ambiguità, che possono portare a schemi differenti, tutti concettualmente “validi”, anche se non tutti corretti per la realtà di riferimento.

Il testo dell’analisi inoltre può tacere di elementi, che vanno desunti dal contesto di riferimento, e non solo: l’esperienza dell’analista tecnico va ad aggiungere proprie considerazioni di natura tecnica, legate alle caratteristiche e le possibilità tecnologiche a disposizione nel database relazionale.

Infine, è molto frequente l’ambiguità nelle analisi funzionali: requisiti impliciti e ritenuti ovvi, richieste mal formulate, interpretazioni errate dell’analista funzionale o richieste del cliente non del tutto chiare, incoerenti o impossibili da realizzare. E’ un problema ben noto agli informatici, che sono causa della maggior parte dei problemi progettuali, che se non ben gestiti, vengono scoperti a valle talvolta al primo UAT (fase in cui il prodotto finale viene presentato al cliente). Non esiste una soluzione generale in Ingegneria del Software a questo problema: l’informatica resta ancora oggi “un’arte” e non una scienza esatta, e solo l’esperienza e la capacità degli architetti del software possono prevenire errori progettuali significativi.

Per questa ragione, anche a livello didattico, è fondamentale giustificare le scelte progettuali esplicitando sempre tutte le eventuali ipotesi aggiuntive, ed altre considerazioni, senza dare nulla per scontato. Questa “best practice” consente di dare validità concettuale al modello e permettere, sia a monte (l’analisi funzionale) che a valle (i programmatori) di evitare errori anche madornali di progettazione.

Relazioni ternarie e unarie

Di norma le relazioni tra entità sono binarie, cioè associano tra loro le entità a coppie. Quando vogliamo poi ricostruire insiemi di dati da entità non immediatamente collegate usiamo le relazioni per unire insieme quello che ci serve, tramite relazioni dirette o indirette, come visto nell’esempio precedente.

Tuttavia ci sono scenari dove è necessario mettere in relazione diretta tre entità. Un esempio è quello visto nella struttura vista nella prima lezione, quella tra docente, materia, classe.Qui si vede bene che docente, materia e classe sono collegati tra loro, e deve essere ternaria:

• un docente infatti può insegnare più di una materia nella stessa classe (es. storia e filosofia);
• una materia può essere insegnata da due docenti (es. informatica ha docente ed ITP);
• una classe ha più materie ed insegnanti, in molte combinazioni possibili.

la relazione è quindi ternaria:

Un altro tipo di relazione speciale è la relazione unaria, ovvero quando una entità ha una relazione con se stessa. Ciò avviene quando si vogliono gestire associazioni non tra istanze di due entità diverse, ma tra istanze della stessa entità.

Ad esempio se vogliamo indicare una relazione di amicizia tra persone, avremo:

Alcuni pattern molto comuni

Ogni progetto richiede una sua modellazione specifica della realtà di riferimento, e quindi non esiste una regola generale, almeno a livello macroscopico. Invece, in termini di singole relazioni, progetti diversi anche di contesti diversi possono avere, a livello di dettaglio, delle relazioni che possono essere modellizzate secondo pattern comuni. Eccone alcuni di molto diffusi:

IS-A

Questa relazione indica che l’entità A è un sottotipo dell’entità B, ovvero è una forma di ereditarietà. Ad esempio Impiegato e Studente ereditano da Persona, ovvero “Studente IS-A Persona”, “Impiegato IS-A Persona”. Per realizzare un IS-A si possono usare queste strategie:

• entità unica: se i figli non hanno attributi propri distinti, conviene creare una entità unica con gli attributi comuni, più un attributo che disambigua il sottotipo.
• entità distinte: se i figli sono molto diversi tra loro, conviene creare entità distinte
• entità padre ed entità figli: si crea una entità padre con attributi comuni, in relazione 1 a molti con ciascuna delle entità figlie, ognuna con gli attributi specifici.

HAS-A

Questa relazione indica che l’entità A appartiene/è associata all’entità B. Ad esempio una casa discografica pubblica (HAS-A) degli album. Essa può essere realizzata con:

• relazione 1 a molti: quando l’associazione non è reciproca. A ha molti B, ma non viceversa.
• relazione molti a molti: quando la relazione HAS-A è reciproca, ad esempio quella tra genere ed album.

PART-OF

Si tratta di una relazione HAS-A dove però l’entità A è parte dell’entità B. Ad esempio la canzone è PART-OF dell’album. Di norma il suo ciclo di vita è collegato all’entità a cui appartiene. Come si può vedere c’è differenza con HAS-A: ad esempio una casa discografica HAS-A molti album, ma questi godono di vita propria dopo la pubblicazione, anche se la casa discografica fallisse. Viceversa se si cancella un album, si eliminano anche le sue canzoni, in quanto sono PART-OF dell’album stesso.

Si realizza di norma con una relazione 1 a molti.

USES-A

Si tratta di una relazione di utilizzo, ovvero una istanza dell’entità A usa una istanza dell’entità B. Ad esempio l’album USES-A supporto. Di norma è una relazione molti-a-molti.

MEMBER-OF

Si tratta di una relazione di classificazione, ovvero una istanza di A appartiene ad una classificazione descritta dall’entità B. Ad esempio un Prodotto è MEMBER-OF di Categoria. Non è una relazione PART-OF perché il prodotto ha un ciclo di vita proprio. Di norma è una relazione uno-a-molti.

Conclusioni

Lo schema E/R è uno strumento efficace perché consente di rappresentare efficace la quasi totalità dei problemi ad alta intensionalità, usando un modello dati rappresentabile con un grafo di entità, relazioni ed attributi, che identifica in modo rigoroso e puntuale la struttura concettuale dei dati di una realtà di riferimento.

Il diagramma E/R non fa nessuna assunzione sul modo in cui i dati saranno effettivamente rappresentati nel sistema informatico. Rappresenta un modello concettuale ad alto livello.

Sarà lo schema logico la prima rappresentazione concreta, sotto forma di tabelle, a fare assunzioni sulla forma finale del database.