La relazione
uno-a-molti (1:N) si verifica quanto una istanza della tabella A ha 0 o più legami con la tabella B, quindi nell’esempio precedente (seconda figura) una persona può avere 0 o più libri.La relazione
molti-a-molti (M:N) si verifica invece quando 0 o più istanze della tabella A possono avere relazioni con 0 o più istanze della tabella B. La terza figura quindi, rappresenta un relazione molti a molti, dove più persone possono avere lo stesso libro, o un libro può essere stato comprato o letto da più persone.In tutto questo discorso, sebbene non sia proprio un vero tipo di relazione, rientra la cosìdetta
self-join relation, ovvero una auto-relazione.La relazione
uno-a-uno (1:1) si verifica quando almeno una istanza di una entità A è associata ad una istanza dell’entità B. Per esempio la Persona dell’esempio precedente ha un legame con la Tabella B perchè possiede un libro.In sostanza la self-join relation non fa altro che prendere come presupposto la stessa entità, mettendo in relazione due attributi diversi della stessa tabella.Esistono fondamentalmente 3 valori di cardinalità che sono “uno-a-uno”, “uno-a-molti” e “molti-a-molti”.Ora senza starmi troppo a soffermare sul grado delle relazioni, piuttosto che sulla direzione, il tipo o l’esistenza, passiamo direttamente al sodo, ovvero la cardinalità della relazione.
Il modello relazionale venne inizialmente proposto da Edgar F. Codd nel 1970, approfondito da Peter nel 1976 e iniziato ad utilizzare come base nei sistemi DBMS nel 1981.
Si tratta quindi di un sistema abbondantemente collaudato, sulla cui base oggi si basano moltissimi database in circolazione.
Il motivo di tale successo è perchè i dati vengono atomizzati in piccole particelle e legati tra di loro all’occorrenza con le relazioni esattamente come avviene con il concetto di insieme che costituisce l'elemento fondante di tutta la matematica moderna.
Questo articolo non vuole essere nulla di esaustivo, nulla di tecnico, ne tantomeno un trattato scientifico sull'argomento. Cercherò di spiegare al meglio cosa sia una relazione all'interno di un database. D'altronde ognuno ha i suoi limiti. Il mio è quello che devo imparare ancora molto.
Per essere più preciso: una tabella bidimensionale costituita da righe (tuple) e colonne (attributi) viene legata ad una seconda tabella mediante un vincolo al quale corrispondo attributi comuni.
Ovvero, si supponga di avere la classica tabella Persona, dove nella riga avremo gli attributi della persona stessa, ma al contempo volessimo sapere, per esempio, quanti libri ha questa persona. Sarebbe impensabile estendere la tabella Persona aggiungendo x attributi progressivi per sapere quanti libri questa persona possiede.
Creeremo allora una seconda tabella nella quale avremo a questo punto più spazio per ulteriori attributi e legheremo le varie righe di libri alla persona, semplicemente aggiungendo un ulteriori attributo che relaziona il libro alla persona.
Meglio ancora sarebbe una terza tabella di legame, che consentirebbe una astrazione logica minuziosa e completamente riciclabile, qualunque sia il contesto lavorativo.
Le relazioni, quindi, rappresentano le entità che si ritiene essere interessanti nel database. Ogni istanza dell'entità troverà posto in una tupla della relazione, mentre gli attributi della relazione rappresenteranno le proprietà dell'entità.
Prima di proseguire oltre con la spiegazione dei vari tipi di relazione, approfondiamo alcuni concetti con un breve dizionario.
Entità: sono l’oggetto principale dove le informazioni sono memorizzate. In poche parole sono le tabelle.
Le entità si possono definire indipendenti, quando, i loro dati sono autoesplicativi, e dipendenti, quando necessariamente ci deve essere una entità di supporto che spieghi a cosa servono quei dati.
Una instanza di una entità è la singola riga presa in considerazione in un dato momento.
Relazione: la relazione è un collegamento tra due o più entità. Questo collegamento viene fatto per mezzo di chiavi o Foreign Key che dir si voglia. Le Foreign Key possono assumere la forma di Primary Key (chiave principale, univoca per definizione) o Alternate Key, ovvero uno o più attributo di una tupla reso identificatori della tupla stessa ma non per questo univoci.
Attributi: gli attributi descrivono l’entità alla quale sono associati. L’istanza di attributo è invece il singolo valore.
L’attributo può essere a sua volta distinto in chiave, o descrittore. La chiave è l’attributo che rende univoca la tupla, il descrittore è semplicemente una informazione aggiuntiva.
La cardinalità di una relazione descrive il modo in cui le varie entità sono associate tra di loro. Il valore che la cardinalità può assumere è “uno” o “molti”.
In realtà, per essere precisi, nel modello relazionale, questo approccio viene visto come un particolare tipo di entità definito sottoinsieme di entità, ma a mio avviso era forse meglio includerlo come un sottoinsieme di relazione uno-a-uno.
La relazione uno-a-uno, ovviamente, vale solo per la singola tupla; quindi all'interno della tabella vigerà sempre e comunque una relazione di tipo uno-a-molti, ma per il singolo record (tupla) solo una relazione uno-a-uno.
Per capirci. La classica tabella gerarchica padre/figlio, dove un figlio può esistere solo se c’è un padre. Se volessimo fare in modo che il padre debba sempre e comunque esistere, l’unico sistema che c’è è quello di creare una relazione che prende come cardine l’attributo padre e lo metta in relazione con l’attributo figlio. Questo ci darà la certezza matematica che non sarà mai possibile inserire una tupla la cui relazione non venga rispettata.
Un esempio può essere quello qui sotto riportato, dove viene creata una relazione self-join nell’entità persona, per creare un vincolo sull’attributo “Coniugato_Con” e l’ID della stessa tabella. Questo ci darà la certezza che la persona coniugata debba essere stata inserita prima di venire relazionata.
