[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]


188. Introduzione ai DBMS

Un DBMS (Data Base Management System) è, letteralmente, un sistema di gestione di basi di dati, che per attuare questa gestione utilizza il software. Queste «basi di dati» sono dei contenitori atti a immagazzinare una grande quantità di dati, e il «sistema di gestione» è necessario per permettere la fruizione di questi (diverso è il problema della semplice archiviazione dei dati).

188.1 Caratteristiche fondamentali

Un DBMS, per essere considerato tale, deve avere caratteristiche determinate. Le più importanti che permettono di comprenderne il significato sono elencate di seguito.

188.1.1 Livelli di astrazione dei dati

I dati gestiti da un DBMS devono essere organizzati a diversi livelli di astrazione. Generalmente si distinguono tre livelli: esterno, logico e interno.

188.1.2 Ruoli e sigle standard

Lo studio sui DBMS ha generato degli acronimi che rappresentano persone o componenti essenziali di un sistema del genere. Questi acronimi devono essere conosciuti perché se ne fa uso abitualmente nella documentazione riferita ai DBMS.

L'organizzazione di una base di dati è compito del suo amministratore, definito DBA (Data Base Administrator). Eventualmente può trattarsi anche di più persone; in ogni caso, chi ha la responsabilità dell'amministrazione di uno o più basi di dati è un DBA.

La definizione della struttura dei dati (sia a livello logico che a livello esterno) viene fatta attraverso un linguaggio di programmazione definito DDL (Data Definition Language), la gestione dei dati avviene attraverso un altro linguaggio, detto DML (Data Manipulation Language), infine, la gestione della sicurezza viene fatta attraverso un linguaggio DCL (Data Control Language). Nella pratica, DDL, DML e DCL possono coincidere, come nel caso del linguaggio SQL.

188.2 Modello relazionale

Una base di dati può essere impostata secondo diversi tipi di modelli (logici) di rappresentazione. Quello più comune, e anche il più semplice dal punto di vista umano, è il modello relazionale. In tal senso, un DBMS relazionale viene anche definito semplicemente come RDBMS.

Nel modello relazionale, i dati sono raccolti all'interno di relazioni. Ogni relazione è una raccolta di nessuna o più tuple di tipo omogeneo. La tupla rappresenta una singola informazione completa, in rapporto alla relazione a cui appartiene, e questa informazione è suddivisa in attributi. Una relazione, nella sua definizione, non ha una «forma» particolare, tuttavia questo concetto si presta a una rappresentazione tabellare: gli attributi sono rappresentati dalle colonne e le tuple dalle righe. Si osservi l'esempio della figura 188.1.

+==============================================================+
|Indirizzi                                                     |
+--------------------------------------------------------------+
|Cognome        |Nome           |Indirizzo      |Telefono      |
+---------------+---------------+---------------+--------------+
|Pallino        |Pinco          |Via Biglie 1   |0222,222222   |
|Tizi           |Tizio          |Via Tazi 5     |0555,555555   |
|Cai            |Caio           |Via Caini 1    |0888,888888   |
|Semproni       |Sempronio      |Via Sempi 7    |0999,999999   |
+===============+===============+===============+==============+

Figura 188.1: Relazione `Indirizzi(Cognome,Nome,Indirizzo,Telefono)'.

In una relazione, le tuple non hanno una posizione particolare, sono semplicemente contenute nell'insieme della relazione stessa. Se l'ordine ha una rilevanza per le informazioni contenute, questo elemento dovrebbe essere aggiunto tra gli attributi, senza essere determinato da un'ipotetica collocazione fisica. Osservando l'esempio, si intende che l'ordine delle righe non ha importanza per le informazioni che si vogliono trarre; al massimo, un elenco ordinato può facilitare la lettura umana, quando si è alla ricerca di un nome particolare, ma ciò non ha rilevanza nella struttura che deve avere la relazione corrispondente.

Il fatto che la posizione delle tuple all'interno della relazione non è importante, significa che non è necessario poterle identificare: le tuple si distinguono in base al loro contenuto. In questo senso, una relazione non può contenere due tuple uguali: la presenza di doppioni non avrebbe alcun significato.

A differenza delle tuple, gli attributi devono essere identificati attraverso un nome. Infatti, il semplice contenuto delle tuple non è sufficiente a stabilire di quale attributo si tratti. Osservando la prima riga dell'esempio,

|Pallino        |Pinco          |Via Biglie 1   |0222,222222   |

diventa difficile distinguere quale sia il nome e quale il cognome. Attribuendo agli attributi (cioè alle colonne) un nome, diventa indifferente la disposizione fisica di questi all'interno delle tuple.

188.2.1 Relazioni collegate

Generalmente, una relazione da sola non è sufficiente a rappresentare tutti i dati riferiti a un problema o a un interesse della vita reale. Quando una relazione contiene tante volte le stesse informazioni, è opportuno scinderla in due o più relazioni più piccole, collegate in qualche modo attraverso dei riferimenti. Si osservi il caso delle relazioni rappresentate dalle tabelle che si vedono nella figura 188.2.

+============================================+
|Articoli                                    |
+--------------------------------------------+
|Codice|Descrizione    |Fornitore1|Fornitore2|
+------+---------------+----------+----------+
|vite30|Vite 3 mm      |       123|       126|
|vite40|Vite 4 mm      |       126|       127|
|dado30|Dado 3 mm      |       122|       123|
|dado40|Dado 4 mm      |       126|       127|
|rond50|Rondella 5 mm  |       123|       126|
+======+===============+==========+==========+
+==============================================+
|Movimenti                                     |
+----------------------------------------------+
|Codice|Data      |Carico|Scarico|CodFor|CodCli|
+------+----------+------+-------+------+------+
|vite40|01/01/1999|  1200|       |   124|      |
|vite30|01/01/1999|      |    800|      |   825|
|vite30|02/01/1999|      |   1000|      |   954|
|vite30|03/01/1999|  2000|       |   127|      |
|rond50|03/01/1999|      |    500|      |   954|
+======+==========+======+=======+======+======+
+=====================================================+
|Fornitori                                            |
+-----------------------------------------------------+
|CodFor|Ditta          |Indirizzo      |Telefono      |
+------+---------------+---------------+--------------+
|   127|Vitoni spa     |Via Ferri 2    |0123,45678    |
|   122|Ferroni spa    |Via Metalli 34 |0234,5678     |
|   126|Nuova Metal    |Via Industrie  |0345,6789     |
|   123|Viti e Bulloni |Via di sopra 7 |0567,9875     |
+======+===============+===============+==============+
+=====================================================+
|Clienti                                              |
+-----------------------------------------------------+
|CodCli|Ditta          |Indirizzo      |Telefono      |
+------+---------------+---------------+--------------+
|   925|Tendoni Max    |Via di sotto 2 |0113,44578    |
|   825|Arti Plus      |Via di lato 45 |0765,23456    |
+======+===============+===============+==============+

Figura 188.2: Relazioni di un'ipotetica gestione del magazzino.

La prima tabella, `Articoli', rappresenta l'anagrafica del magazzino di un grossista di ferramenta. Ogni articolo di magazzino viene codificato e descritto, e inoltre vengono annotati i riferimenti ai codici di possibili fornitori. La seconda tabella, `Movimenti', elenca le operazioni di carico e di scarico degli articoli di magazzino, specificando solo il codice dell'articolo, la data, la quantità caricata o scaricata e il codice del fornitore o del cliente da cui è stato acquistato o a cui è stato venduto l'articolo. Infine seguono le tabelle che descrivono i codici dei fornitori e quelli dei clienti.

Si può intendere che una sola tabella non avrebbe potuto essere utilizzata utilmente per esprimere tutte queste informazioni.

È importante stabilire che, nel modello relazionale, il collegamento tra le tuple delle varie relazioni avviene attraverso dei valori e non attraverso dei puntatori. Infatti, nella relazione `Articoli' l'attributo `Fornitore1' contiene il valore 123, e questo significa solo che i dati di quel fornitore sono rappresentati dal quel valore. Nella relazione `Fornitori', la tupla il cui attributo `CodFor' contiene il valore 123 è quella che contiene i dati di quel particolare fornitore. Quindi, «123» non rappresenta un puntatore, ma solo una tupla che contiene quel valore nell'attributo «giusto». In questo senso si ribadisce l'indifferenza della posizione delle tuple all'interno delle relazioni.

188.2.2 Tipi di dati, domini e informazioni mancanti

Nelle relazioni, ogni attributo contiene una singola informazione elementare di un certo tipo, per il quale esiste un dominio determinato di valori possibili. Ogni attributo di ogni tupla deve contenere un valore ammissibile, nell'ambito del proprio dominio.

Spesso capitano situazioni in cui i valori di uno o più attributi di una tupla non sono disponibili, e questo per motivi imprecisati (nel senso che il motivo non è importante). In tal caso si pone il problema di attribuire a questi attributi un valore che definisca in modo non ambiguo questo stato di indeterminatezza. Questo valore viene definito come `NULL' ed è ammissibile per tutti i tipi di attributi possibili.

188.2.3 Vincoli di validità

I dati contenuti in una o più relazioni sono utili in quanto «sensati» in base al contesto a cui si riferiscono. Per esempio, considerando la relazione `Movimenti', vista precedentemente, questa deve contenere sempre un codice valido nell'attributo `Codice'. Se così non fosse, la registrazione data da quella tupla che dovesse avere un riferimento a un codice di articolo non valido, non avrebbe alcun senso, perché mancherebbe proprio l'informazione più importante: l'articolo caricato o scaricato.

Il controllo sulla validità dei dati può avvenire a diversi livelli, a seconda della circostanza. Si possono distinguere vincoli che riguardano:

  1. il dominio dell'attributo stesso -- quando si tratta di definire se l'attributo può assumere il valore `NULL' o meno, e quando si stabilisce l'intervallo dei valori ammissibili;

  2. gli altri attributi della stessa tupla -- quando dal valore contenuto in altri attributi della stessa tupla dipende l'intervallo dei valori ammissibili per l'attributo in questione;

  3. gli attributi di altre tuple -- quando dal valore contenuto negli attributi delle altre tuple della stessa relazione dipende l'intervallo dei valori ammissibili per l'attributo in questione;

  4. gli attributi di tuple di altre relazioni -- quando altre relazioni condizionano la validità di un attributo determinato.

I vincoli di tupla, ovvero quelli che riguardano i primi due punti dell'elenco appena indicato, sono i più semplici da esprimere perché non occorre conoscere altre informazioni esterne alla tupla stessa. Per esempio, un attributo che esprime un prezzo potrebbe essere definito in modo tale che non sia ammissibile un valore negativo; nello stesso modo, un attributo che esprime uno sconto su un prezzo potrebbe ammettere un valore positivo diverso da zero solo se il prezzo a cui si riferisce, contenuto nella stessa tupla, supera un valore determinato.

Il caso più importante di un vincolo interno alla relazione, che coinvolge più tuple, è quello che riguarda le chiavi. In certe situazioni, un attributo, o un gruppo particolare di attributi di una relazione, deve essere unico per ogni tupla. Quindi, questo attributo, o questo gruppo di attributi, è valido solo quando non è già presente in un'altra tupla della stessa relazione.

Quando le informazioni sono distribuite fra più relazioni, i dati sono validi solo quando tutti i riferimenti sono validi. Volendo riprendere l'esempio della gestione di magazzino, visto precedentemente, una tupla della relazione `Movimenti' che dovesse contenere un codice di un fornitore o di un cliente inesistente, si troverebbe, in pratica, senza questa informazione.

188.2.4 Chiavi

Nella sezione precedente si è accennato alle chiavi. Questo concetto merita un po' di attenzione. In precedenza si era detto che una relazione contiene una raccolta di tuple che contano per il loro contenuto e non per la loro posizione. In questo senso non è ammissibile una relazione contenente due tuple identiche. Una chiave di una relazione è un gruppo di attributi che permette di identificare univocamente le tuple in essa contenute; per questo, questi attributi devono contenere dati differenti per ogni tupla.

Stabilendo quali attributi devono costituire una chiave per una certa relazione, si comprende intuitivamente che questi attributi non possono mai contenere un valore indeterminato.

Nella definizione di relazioni collegate attraverso dei riferimenti, l'oggetto di questi riferimenti deve essere una chiave per la relazione di destinazione. Diversamente non si otterrebbe un riferimento univoco a una tupla particolare.

188.3 Gestione delle relazioni

Prima di affrontare l'utilizzo pratico di una base di dati relazionale, attraverso un linguaggio di manipolazione dei dati, è opportuno considerare a livello teorico alcuni tipi di operazioni che si possono eseguire con le relazioni.

Inizialmente si è detto che una relazione è un insieme di tuple... Dalla teoria degli insiemi derivano molte delle operazioni che riguardano le relazioni.

188.3.1 Unione, intersezione e differenza

Quando si maneggiano relazioni contenenti gli stessi attributi, hanno senso le operazioni fondamentali sugli insiemi: unione, intersezione e differenza. Il significato è evidente: l'unione genera una relazione composta da tutte le tuple distinte delle relazioni di origine; l'intersezione genera una relazione composta dalle tuple presenti simultaneamente in tutte le relazioni di origine; la differenza genera una relazione contenente le tuple che compaiono esclusivamente nella prima delle relazioni di origine.

L'esempio rappresentato dalle tabelle della figura 188.3 dovrebbe chiarire il senso di queste affermazioni.

+=================================+  +=================================+
|Laureati                         |  |Magazzinieri                     |
+---------------------------------+  +---------------------------------+
|Codice|Nominativo        |...    |  |Codice|Nominativo        |...    |
+------+------------------+-------+  +------+------------------+-------+
|  1245|Tizi Tizio        |...    |  |  1745|Cai Caio          |...    |
|  1745|Cai Caio          |...    |  |  1986|Pallino Pinco     |...    |
|  1655|Semproni Sempronio|...    |  |  1245|Tizi Tizio        |...    |
+======+==================+=======+  +======+==================+=======+
+=================================+
|Laureati UNITO Magazzinieri      |
+---------------------------------+
|Codice|Nominativo        |...    |
+------+------------------+-------+
|  1245|Tizi Tizio        |...    |
|  1745|Cai Caio          |...    |
|  1655|Semproni Sempronio|...    |
|  1986|Pallino Pinco     |...    |
+======+==================+=======+
+=================================+
|Laureati INTERSECATO Magazzinieri|
+---------------------------------+
|Codice|Nominativo        |...    |
+------+------------------+-------+
|  1245|Tizi Tizio        |...    |
|  1745|Cai Caio          |...    |
+======+==================+=======+
+=================================+
|Laureati MENO Magazzinieri       |
+---------------------------------+
|Codice|Nominativo        |...    |
+------+------------------+-------+
|  1655|Semproni Sempronio|...    |
+======+==================+=======+

Figura 188.3: Unione, intersezione e differenza tra relazioni.

188.3.2 Ridenominazione degli attributi

L'elaborazione dei dati contenuti in una relazione può avvenire previa modifica dei nomi di alcuni attributi. La modifica dei nomi genera di fatto una nuova relazione temporanea, per il tempo necessario a eseguire l'elaborazione conclusiva.

Le situazioni in cui la ridenominazione degli attributi può essere conveniente possono essere varie. Nel caso delle operazioni sugli insiemi visti nella sezione precedente, la ridenominazione può rendere compatibili relazioni i cui attributi, pur essendo compatibili, hanno nomi differenti.

188.3.3 Selezione, proiezione e join

La selezione e la proiezione sono operazioni che si eseguono su una sola relazione e generano una relazione che contiene una porzione dei dati di quella di origine. La selezione permette di estrarre alcune tuple dalla relazione, mentre la proiezione estrae parte degli attribuiti di tutte le tuple. Il primo caso, quello della selezione, non richiede considerazioni particolari, mentre la proiezione ha delle implicazioni importanti.

Attraverso la proiezione, utilizzando solo parte degli attributi, si genera una relazione in cui si potrebbero perdere delle tuple, a causa della possibilità che risultino dei doppioni. Per esempio, si consideri la relazione mostrata nella figura 188.4.

+==============================================================+
|Utenti                                                        |
+--------------------------------------------------------------+
|UID   |Nominativo|Cognome        |Nome          |Ufficio      |
+------+----------+---------------+--------------+-------------+
|     0|root      |Pallino        |Pinco         |CED          |
|   515|rmario    |Rossi          |Mario         |Contabilità  |
|   501|bbianco   |Bianchi        |Bianco        |Magazzino    |
|   502|rrosso    |Rossi          |Rosso         |Contabilità  |
+======+==========+===============+==============+=============+

Figura 188.4: Relazione `Utenti(UID,Nominativo,Cognome,Nome,Ufficio)'.

La tabella mostra una relazione contenente le informazioni sugli utenti di un centro di elaborazione dati. Si può osservare che sia l'attributo `UID' che l'attributo `Nominativo' possono essere da soli una chiave per la relazione. Se da questa relazione si vuole ottenere una proiezione contenente solo gli attributi `Cognome' e `Ufficio', non essendo questi due una chiave della relazione, si perdono delle tuple.

+---------------+-------------+
|Cognome        |Ufficio      |
+---------------+-------------+
|Pallino        |CED          |
|Rossi          |Contabilità  |
|Bianchi        |Magazzino    |
+===============+=============+

Figura 188.5: Proiezione delle colonne `Cognome' e `Ufficio' della relazione `Utenti'.

La figura 188.5 mostra la proiezione della relazione `Utenti', in cui sono stati estratti solo gli attributi `Cognome' e `Ufficio'. In tal modo, le tuple che prima corrispondevano al numero `UID' 515 e 502 si sono ridotte a una sola, quella contenente il cognome «Rossi» e l'ufficio «Contabilità».

Da questo esempio si dovrebbe intendere che la proiezione ha senso, prevalentemente, quando gli attributi estratti costituiscono una chiave della relazione originaria

La congiunzione di relazioni, o join, è un'operazione in cui due o più relazioni vengono unite a formare una nuova relazione. Questo congiungimento implica la creazione di tuple formate dall'unione di tuple provenienti dalle relazioni di origine. Se per semplicità si pensa solo alla congiunzione di due relazioni: si va da una congiunzione minima in cui nessuna tupla della prima relazione risulta abbinata ad altre tuple della seconda, fino a un massimo in cui si ottengono tutti gli abbinamenti possibili delle tuple della prima relazione con quelle della seconda. Tra questi estremi si pone la situazione tipica, quella in cui ogni tupla della prima relazione viene collegata solo a una tupla corrispondente della seconda.

Il join naturale è un tipo particolare di congiunzione in cui le relazioni oggetto di tale operazione vengono collegate in base ad attributi aventi lo stesso nome. Per osservare di cosa si tratta, vale la pena di riprendere l'esempio della gestione di magazzino già descritto in precedenza. Nella figura 188.6 ne viene mostrata nuovamente solo una parte.

+===========================+
|Articoli                   |
+---------------------------+
|Codice|Descrizione    |... |
+------+---------------+----+
|vite30|Vite 3 mm      |... |
|vite40|Vite 4 mm      |... |
|dado30|Dado 3 mm      |... |
|dado40|Dado 4 mm      |... |
|rond50|Rondella 5 mm  |... |
+======+===============+====+
+=====================================+
|Movimenti                            |
+-------------------------------------+
|Codice|Data      |Carico|Scarico|... |
+------+----------+------+-------+----+
|vite40|01/01/1999|  1200|       |... |
|vite30|01/01/1999|      |    800|... |
|vite30|02/01/1999|      |   1000|... |
|vite30|03/01/1999|  2000|       |... |
|rond50|03/01/1999|      |    500|... |
+======+==========+======+=======+====+

Figura 188.6: Le relazioni `Articoli' e `Movimenti' dell'esempio sulla gestione del magazzino.

Il join naturale delle relazioni `Movimenti' e `Articoli', basato sulla coincidenza del contenuto dell'attributo `Codice', genera una relazione in cui appaiono tutti gli attributi delle due relazioni di origine, con l'eccezione dell'attributo `Codice' che appare una volta sola (figura 188.7).

+------+----------+------+-------+----+---------------+----+
|Codice|Data      |Carico|Scarico|... |Descrizione    |... |
+------+----------+------+-------+----+---------------+----+
|vite40|01/01/1999|  1200|       |... |Vite 4 mm      |... |
|vite30|01/01/1999|      |    800|... |Vite 3 mm      |... |
|vite30|02/01/1999|      |   1000|... |Vite 3 mm      |... |
|vite30|03/01/1999|  2000|       |... |Vite 3 mm      |... |
|rond50|03/01/1999|      |    500|... |Rondella 5 mm  |... |
+======+==========+======+=======+====+===============+====+

Figura 188.7: Il join naturale tra le relazioni `Articoli' e `Movimenti'.

Nel caso migliore, ogni tupla di una relazione trova una tupla corrispondente dell'altra; nel caso peggiore, nessuna tupla ha una corrispondente nell'altra relazione. L'esempio mostra che tutte le tuple della relazione `Movimenti' hanno trovato una corrispondenza nella relazione `Articoli', mentre solo alcune tuple della relazione `Articoli' hanno una corrispondenza dall'altra parte. Queste tuple, quelle che non hanno una corrispondenza, sono dette «penzolanti», o dangling, e di fatto vengono perdute dopo il join.

Quando un join genera corrispondenze per tutte le tuple delle relazioni coinvolte, si parla di join completo. La dimensione (espressa in quantità di tuple) della relazione risultante in presenza di un join completo è pari alla dimensione massima delle varie relazioni.

Quando si vuole eseguire la congiunzione di relazioni che non hanno attributi in comune si ottiene il collegamento di ogni tupla di una relazione con ogni tupla delle altre. Si può osservare l'esempio della figura 188.8 che riprende il solito problema del magazzino, con delle semplificazioni opportune.

+======================================+
|Articoli                              |
+--------------------------------------+
|Codice|Descrizione    |Fornitore1|... |
+------+---------------+----------+----+
|vite30|Vite 3 mm      |       127|... |
|vite40|Vite 4 mm      |       127|... |
|dado30|Dado 3 mm      |       122|... |
+======+===============+==========+====+
+===========================+
|Fornitori                  |
+---------------------------+
|CodFor|Ditta          |... |
+------+---------------+----+
|   127|Vitoni spa     |... |
|   122|Ferroni spa    |... |
+======+===============+====+

Figura 188.8: Le relazioni `Articoli' e `Fornitori' dell'esempio sulla gestione del magazzino.

Nessuno degli attributi delle due relazioni coincide, quindi si ottiene un «prodotto» tra le due relazioni, in pratica, una relazione che contiene il prodotto delle tuple contenute nelle relazioni originali (figura 188.9).

+------+---------------+---------------+------+---------------+----+
|Codice|Descrizione    |Fornitore1|... |CodFor|Ditta          |... |
+------+---------------+----------+----+------+---------------+----+
|vite30|Vite 3 mm      |       127|... |   127|Vitoni spa     |... |
|vite40|Vite 4 mm      |       127|... |   127|Vitoni spa     |... |
|dado30|Dado 3 mm      |       122|... |   127|Vitoni spa     |... |
|vite30|Vite 3 mm      |       127|... |   122|Ferroni spa    |... |
|vite40|Vite 4 mm      |       127|... |   122|Ferroni spa    |... |
|dado30|Dado 3 mm      |       122|... |   122|Ferroni spa    |... |
+======+===============+==========+====+======+===============+====+

Figura 188.9: Il prodotto tra le relazioni `Articoli' e `Fornitori'.

Quando si esegue un'operazione del genere, è normale che molte delle tuple risultanti siano prive di significato per gli scopi che ci si prefigge. Di conseguenza, quasi sempre, si applica poi una selezione attraverso delle condizioni. Nel caso dell'esempio, sarebbe ragionevole porre come condizione di selezione l'uguaglianza tra i valori dell'attributo `Fornitore1' e `CodFor'.

Fornitore1 = CodFor
+------+---------------+---------------+------+---------------+----+
|Codice|Descrizione    |Fornitore1|... |CodFor|Ditta          |... |
+------+---------------+----------+----+------+---------------+----+
|vite30|Vite 3 mm      |       127|... |   127|Vitoni spa     |... |
|vite40|Vite 4 mm      |       127|... |   127|Vitoni spa     |... |
|dado30|Dado 3 mm      |       122|... |   122|Ferroni spa    |... |
+======+===============+==========+====+======+===============+====+

Figura 188.10: La selezione delle tuple che rispettano la condizione di uguaglianza tra gli attributi `Fornitore1' e `CodFor'.

Generalmente, nella pratica, non esiste la possibilità di definire un join basato sull'uguaglianza dei nomi degli attributi. Di solito si esegue un join che genera un prodotto tra le relazioni, e quindi si applicano delle condizioni di selezione, come nell'esempio mostrato. Quando la selezione in questione è del tipo visto nell'esempio, cioè basata sull'uguaglianza del contenuto di attributi delle diverse relazioni (anche se il nome di questi attributi è differente), si parla di equi-join.

188.3.4 Gestione dei valori nulli

Si è accennato in precedenza alla possibilità che gli attributi di una relazione possano contenere anche il valore indeterminato, o `NULL'. Con questo valore indeterminato non si possono fare comparazioni con valori determinati, e di solito nemmeno con altri valori indeterminati. Per esempio, non si può dire che `NULL' sia maggiore o minore di qualcosa; una comparazione del genere genera solo un risultato indeterminato. `NULL' è solo uguale a se stesso ed è diverso da ogni altro valore, compreso un altro valore `NULL'.

Per verificare la presenza o l'assenza di un valore indeterminato si utilizzano generalmente operatori specifici, come in SQL:

Nel momento in cui si eseguono delle espressioni logiche, utilizzando i soliti operatori AND, OR e NOT, si pone il problema di stabilire cosa accade quando si presentano valori indeterminati. La soluzione è intuitiva: quando non si può fare a meno di conoscere il valore che si presenta come indeterminato, il risultato è indeterminato. Questo concetto deriva dalla cosiddetta logica fuzzy.

? AND ? = ?	? OR ? = ?
? AND F = F	? OR F = ?
? AND T = ?	? OR T = T
F AND ? = F	F OR ? = ?
F AND F = F	F OR F = F
F AND T = F	F OR T = T
T AND ? = ?	T OR ? = T
T AND F = F	T OR F = T
T AND T = T	T OR T = T

Figura 188.11: Tabella della verità degli operatori AND e NOT quando sono coinvolti valori indefiniti.

188.3.5 Relazioni derivate e viste

Precedentemente si è accennato al fatto che la rappresentazione finale dei dati può essere diversa da quella logica. Nel modello relazionale è possibile ottenere delle relazioni derivate da altre, attraverso una determinata funzione che stabilisce il modo con cui ottenere queste derivazioni. Si distingue fondamentalmente tra:

Il primo dei due casi è semplice da gestire, perché i dati sono sempre allineati correttamente, ma è pesante dal punto di vista elaborativo; il secondo ha invece i pregi e i difetti opposti. Con il termine «vista» si intende fare riferimento alle relazioni derivate virtuali.

188.4 Riferimenti

---------------------------

Appunti Linux 2000.04.12 --- Copyright © 1997-2000 Daniele Giacomini --  daniele @ pluto.linux.it


[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]