Brook Preloader

La prima relazione in ER, Molti-a-Molti

Molti a Molti

Immaginiamo di ricevere la seguente richiesta:

Si richiede lo sviluppo di un DataBase per la facoltà di Ingegneria in cui poter tracciare i dati relativi agli studenti, gli esami e le iscrizioni degli studenti agli esami.
Si ponga l’attenzione sul fatto che uno studente può essere iscritto ad uno o più esami ma anche a nessun esame (ad esempio una matricola appena iscritta).

L’approccio di sviluppo del diagramma ER parte sempre dall’individuazione delle entità:

  • Studente
  • Esame

Una volta individuate le entità immettiamo qualche attributo caratterizzante:

Analizzando il testo balza subito all’occhio che l’iscrizione può essere interpretata come la relazione che intercorre tra queste due entità.

Una particolarità di questo scenario è la possibilità di introdurre un attributo all’interno della relazione. La data di iscrizione, che ne identifica l’istante in cui uno studente effettua l’iscrizione all’esame, può essere esplicitata graficamente in questo modo:

Tutti gli attributi fin ora associati alle entità quindi possono essere associati anche ad una relazione. Cerchiamo però di porre molta attenzione su questa procedura poiché a livello di traduzione in SQL del diagramma potrebbe impattare sul livello di difficoltà della procedura.

Passiamo ora a stabilire le cardinalità di ogni relazione partendo da sinistra e quindi allo Studente.

Il diagramma, partendo da Studente, potrà essere letto quindi come “lo studente può essere iscritto ad uno o più esami”, specificando che può avere una, più di una oppure nessuna iscrizione all’esame selezionato.

Completiamo il diagramma introducendo la relazione inversa che collega Esame con Studente:

Il diagramma, partendo da Esame, può essere letto come ad un esame possono essere scritti uno o più studenti.

 

Gli attributi sulla relazione

Il diagramma appena illustrato ha come peculiarità la presenza di un attributo sulla relazione, idealmente dobbiamo pensare che, a livello fisico le uniche strutture capaci di immagazzinare dati sono le entità, quindi una relazione teoricamente non potrebbe contenerne.

Per ovviare a questo problema possiamo trasformare la relazione in una entità spezzando il diagramma in due sotto diagrammi indipendenti.

Per ristrutturare il diagramma riposizioniamo quindi le entità come se dovessimo iniziare da zero:

Il nostro diagramma quindi si comporrà di tre entità che dovranno essere collegate, a coppie di due, con una relazione.

Selezioniamo prima le entità Studente e Iscrizione per esplicitare la seguente relazione:

 

Il diagramma, partendo da Studente, potrà essere letto quindi come “lo studente può essere iscritto ad uno o più esami”, specificando che può avere una, più di una oppure nessuna iscrizione.

Percorrendo il diagramma al contrario come “una iscrizione viene effettuata da uno studente” ponendo l’attenzione sul fatto che questa relazione è obbligatoria poiché un’iscrizione non può esistere senza lo studente a cui si riferisce.

Componiamo adesso l’altra coppia di entità, Esame ed Iscrizione ed esplicitiamone la relazione:

Il diagramma, partendo da Esame, potrà essere letto quindi come “un esame può essere coinvolto in una o più iscrizioni”, specificando che può avere una, più di una oppure nessuna iscrizione all’esame selezionato.

Percorrendo il diagramma al contrario come “una iscrizione coinvolge un solo esame” ponendo l’attenzione sul fatto che questa relazione è obbligatoria poiché un’iscrizione non può esistere senza l’esame a cui si riferisce.

 

Quando usare le due notazioni

Le diverse vesti grafiche dei diagrammi presentati presentano due diversi approcci a livello realizzativo. Se ogni entità corrisponde ad una tabella, il secondo approccio incrementa di uno il numero di tabelle che verranno posizionate sul DataBase.

Il secondo approccio è preferibile, come giù illustrato, quando una relazione possiede un attributo, in caso contrario la relazione può essere lasciata come tale senza necessariamente introdurre (a livello grafico) una nuova entità.

Nel seguente diagramma (dove vengono omessi gli attributi per semplicità), la relazione non contiene attributi.