Il modello Relazionale

Definizioni

Questo modello, definito come abbiamo detto da Edgar Codd nel suo celebre articolo "A Relational Model of Data for Large Shared Data Banks" pubblicato su Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377-387 è basato sul concetto algebrico di relazione e sulla teoria degli insiemi, che viene applicata agli insiemi di dati.

Supponiamo di avere N = 3 insiemi di dati, per esempio un insieme di Cognomi (C), un insieme di Date di nascita (D), un insieme di numeri di Telefono (T).
L'algebra definisce come prodotto cartesiano di questi insiemi CxDxT l'insieme di tutte le possibili triple ottenute prendendo il primo dato da C, il seconda da D e il terzo da T.
CxDxT = { (c,d,t) / c e C, d e D, t e T}

Naturalmente di questo insieme caotico di dati non ce ne faremmo niente: noi abbiamo bisogno che ad ogni cognome venga associata la giusta data di nascita e numero di telefono: in questo ci viene in aiuto il concetto di relazione, che in algebra si definisce come sottoinsieme del prodotto cartesiano:
R sottoinsieme di CxDxT

In pratica di tutte le possibili terne ottenute combinando a caso cognomi, date e numeri di telefono, sceglieremo solo quelle in cui i dati sono effettivamente in relazione tra loro.
In questo modo una relazione definita su questi insiemi dominio, può essere interpretata come un archivio che contiene una rubrica telefonica. (la data di nascita non è in questo caso particolarmente utile ma si tratta solo di un esempio).

Gli elementi della relazione (in pratica i record del nostro archivio) nell'esempio fatto sono terne di dati, ma possono avere un numero qualunque di elementi e vengono chiamati t-ple (o tuple), e la relazione stessa viene detta tabella.
Il numero di colonne della tabella è uguale al numero degli insiemi dominio, e viene detto grado della relazione.
Il numero di righe della tabella viene invece detto cardinalità della relazione.

Nel modello relazionale la relazione implementa quindi il concetto di entità del Data Base.

Nello stesso tempo, se vogliamo associare delle entità tra di loro, possiamo sempre creare delle relazioni in cui compaiano i dati che ci interessano insieme: per esempio i dati di un articolo e quello del suo fornitore.
Per cui la relazione implementa anche il concetto di associazione tra entità.

Regole

Una base di dati relazionale può quindi definirsi come un insieme di relazioni (o tabelle)

Le relazioni devono rispettare le seguenti regole:

Chiavi

Il concetto di chiave in quanto fattore di ordinamento e di ricerca è estraneo alla teoria dei DB relazionali; anzi è detto esplicitamente che l'ordine delle t-ple non è rilevante all'interno della tabella.
Dato che però nella pratica le tabelle vengono realizzate con la tecnica degli archivi indicizzati, bisogna fare i conti con vari concetti legati alle chiavi, che qui riassumiamo brevemente perchè fanno più strettamente parte dela teoria degli indici.

Una chiave (o indice) è un dato composto da uno o più attributi della entità, che viene utilizzato per riordinare o per velocizzare l'accesso alle t-ple.

Chiave univoca (unique key)
identifica senza ambiguità un record: quindi all'interno dell'archivio i valori assunti da questo dato sono tutti diversi
Chiave duplicata
al contrario della precedente, questa chiave può avere lo stesso valore in due record diversi
Chiave parlante
viene scelta in modo da ricordare il contenuto di un record, magari abbreviando in qualche modo il nome dell'entità rappresentata.
Il codice fiscale è un esempio di chiave parlante
Chiave anonima
al contrario della precedente, non contiene alcuna informazione utile: in genere si tratta di un numero progressivo (autoincrement), e si usa per esempio quando serve una chiave univoca, ma le ricerche e gli accessi vengono poi fatti tramite altre chiavi
Chiave semplice
è composta da un solo campo del record
Chiave composta
è composta da più campi del record
Chiave primaria (primary key)
è: una chiave univoca scelta come chiave principale. E' obbligatoria negli archivi indicizzati, perchè ci deve essere appunto almeno un indice.
Chiave secondaria (alternate key)
viene affiancata alla chiave primaria per consentire ricerche tramite altri dati; può essere duplicata, e ce ne possono essere più di una.
Chiave esterna (foreign key)
richiama dati da un altro archivio: di questo tipo di chiave parleremo più diffusamente nei prossimi paragrafi.
Chiave candidata
E' una possibile chiave primaria, quindi una chiave univoca. Fra tutte le chiavi candidate ne verra' poi scelta una.
Il criterio deve tenere in considerazione anche la lunghezza della chiave stessa. Qualora una chiave candidata sia composta da più attributi, e un sottoinsieme di questi costituisca a sua volta una chiave candidata, quest'ultima deve essere preferita alla prima

Progettazione di DB relazionali

Per progettare un DB relazionale è necessario prima di tutto definire le entità che lo compongono. A ciascuna di queste entità corrisponde una relazione, cioè un archivio; nel linguaggio dei DB relazionali di solito questa struttura viene chiamata tabella.
Successivamente si passerà ad esaminare quali associazioni (o collegamenti) ci sono fra queste entità.

Ci sono solo tre possibili tipi di relazioni tra due entità

Associazione 1-1
Si verifica quando ad una entità del primo tipo ne corrisponde 1 e 1 sola del secondo.
Es: i pazienti di un ospedale e i posti letto.
pazienti -letti
La presenza di una linea tratteggiata indica che non tutti i letti sono occupati, in alcuni non c'è nessun paziente.
Associazione 1-N
Si verifica quando ad una entità del primo tipo possono corrispondere più entità del secondo, ma ogni entità del secondo tipo può avere un solo corrispondente del primo.
Es: le classi di una scuola e gli alunni
classi-alunni
Notare che in questo caso non ci sono linee tratteggiate, perchè tutti gli alunni sono iscritti ad una classe, e tutte le classi hanno almeno un alunno.
Associazione N-M
Si verifica quando ad una entità del primo tipo possono corrispondere più entità del secondo, e viceversa (cioè anche ogni entità del secondo tipo può avere più corrispondenti del primo).
Es: le classi e gli insegnanti di una scuola
alunni-insegnanti

Lo schema concettuale di un Data Base si rappresenta graficamente tramite il diagramma Entità-relazione.

Regole di derivazione

Una volta definito lo schema concettuale, nella stesura dello schema logico per realizzare le associazioni tra entità si usano le cosiddette chiavi esterne (foreign keys). Una chiave esterna è la chiave primaria di un'altra entità : dato che la chiave primaria identifica univocamente una singola istanza dell' entità, in questo modo si crea un collegamento ad un determinato record.

Per realizzare correttamente le associazioni bisogna seguire alcune semplici regole :

Associazione 1-1
In genere si attribuisce la stessa chiave primaria alle due entità.
E' possibile anche inserire la chiave primaria di una delle due come chiave esterna tra gli attributi dell' altra. Dato che la relazione è simmetrica, si può creare anche un collegamento incrociato inserendole entrambe.
Es: LETTI (CodPosto, Reparto, Piano, Stanza, Paziente)
       PAZIENTI (CodSanitario, Nome, Indirizzo, Citta, DataNascita, Posto)
La chiave esterna Posto deve contenere uno dei valori della chiave primaria CodPosto, e indica quale posto letto occupa il paziente, mentre la chiave esterna Paziente deve assumere il valore del codice sanitario del paziente che occupa quel letto.
Associazione 1-N
La chiave primaria dell' entità principale va inserita come chiave esterna tra gli attributi dell' entità dipendente.
Attenzione! la relazione NON è simmetrica, quindi è sbagliato inserire la chiave esterna nell' entità dipendente.
Es: CLASSI (Anno+Sezione, Collocazione)
       ALUNNI (Codice, Nome, Classe)
La chiave esterna Classe indica a quale classe appartiene un alunno. Dato che non ci sono alunni che non sono iscritti in nessuna classe, l'inserimento della chiave esterna è, obbligatorio.
Associazione N-M
Per realizzare la relazione bisogna creare una tabella contenente le chiavi primarie delle due entità interessate.
In questo modo nella tabella sono presenti due chiavi esterne.
Es: INSEGNANTI (Codice, Nome, ClasseConcorso)
       CLASSI (Anno+Sezione, Collocazione)
       INSEGNAMENTI (Num, Insegnante, Classe, Materia)
Notare la tabella INSEGNAMENTI: contiene due chiavi esterne, che indicano in quale classe insegna un insegnante (entrambi identificati dalle loro chiavi primarie). Queste tabelle di collegamento possono avere anche degli attributi propri: in questo caso l'attributo Materia indica che materia insegna quell'insegnante in quella classe.
Se un insegnante insegna in più classi, il suo codice si troverà ripetuto più volte nella tabella affiancato a quello di diverse classi.
La chiave primaria in questo caso non è particolarmente significativa, quindi si può usare anche un numero progressivo.

Associazioni non binarie

A volte si possono incontrare associazioni che coinvolgono una sola entità (ricorsive o riflessive)
In questo caso si seguono comunque le regole di derivazione usando una chiave esterna se il collegamento è 1-1 o 1-N, oppure creando una nuova relazione se l'associazione è di tipo N-M.

Associazioni ricorsive

Consideriamo le relazioni di parentela che possono verificarsi tra le persone registrate in una anagrafe

Associazioni multiple

Se l'associazione invece è multipla, cioè coinvolge 3 o più tabelle, si ricorre sempre ad una nuova relazione che contiene come chiavi esterne tutte le chiavi primarie della relazioni associate.

Esempio

Consideriamo la relazione tra docenti, materie e classi

Derivazione:
DOCENTI(CodiceFiscale, Cognome, Nome, DataNascita,Indirizzo, Citta)
MATERIE(Codice, Descrizione)
CLASSI(Numero, AnnoCorso, Indirizzo, Sezione, Sede, Piano, Aula)
ORGANICO(Contatore,Docente, Materia, Classe, Ore)

Le forme normali

Prima forma normale
Una relazione si dice in prima forma normale quando tutti i suoi attributi sono semplici
Questo significa che non ci devono essere campi composti nè campi multipli
La prima forma normale deve essere obbligatoriamente rispettata nella costruzione di un DB relazionale.
Seconda forma normale
Una relazione si dice in seconda forma normale quando è in prima forma normale e tutti i suoi attributi dipendono dall' intera chiave primaria
Questo significa che se la chiave è composta, tutti gli attributi devono dipendere da tutte le parti della chiave.
Terza forma normale
Una relazione è in terza forma normale quando è in seconda forma normale e tutti i suoi attributi dipendono direttamente dalla chiave primaria.
Questo significa che non ci sono dati che dipendono da altri all'interno della relazione, ma solo dalla chiave primaria

Normalizzazioni

Passaggio in prima forma normale

Il passaggio in prima forma normale è obbligatorio per soddisfare la coerenza e la correttezza delle tabelle di un DB relazionale
Dopo aver progettato lo schema concettuale e quello logico, bisogna quindi accertarsi che tutti gli attributi delle varie entità siano in forma semplice.
Se non lo sono, possono verificarsi due casi:

Passaggio in seconda forma normale

Il passaggio in seconda forma normale avviene solo se ci sono tabelle con chiavi composte.
In questo caso bisogna eliminare le dipendenze parziali dalla chiave, separando in due tabelle distinte gli attributi che dipendono solo da una parte della chiave.
Nella nuova tabella viene riportata come chiave primaria la parte della chiave interessata alla dipendenza
Es: RIGHE (Numero, CodArticolo, Descrizione, Prezzo, Quantita)
      RIGHE (Numero, CodArticolo, Quantita)
      ARTICOLI (CodArticolo, Descrizione, Prezzo)

Passaggio in terza forma normale

Con questo passaggio, simile al precedente , si eliminano le dipendenze indirette dalla chiave primaria. E' in genere da questo passaggio che scaturiscono le cosiddette tabelle di look-up, che contengono i dati che dipendono indirettamente dalla chiave primaria; il dato da cui dipendono viene usato come chiave primaria nella nuova tabella.
Es: FATTURA (Numero, Data, CodCliente, Denominazione, Indirizzo, Cap, Citta)
      FATTURA (Numero, Data, CodCliente)
      CLIENTE (CodCliente, Denominazione, Indirizzo, Cap, Citta)

Vincoli di integrità

Vincoli di dominio

Sono anche detti vincoli di colonna.

Si tratta di condizioni che vengono imposte a seconda del tipo di informazione: per esempio, se si tratta di una temperatura, si può imporre il vincolo che sia compresa tra -20 e +50, se il dato rappresenta l'età, di una persona, che sia inferiore a 110, se contiene un giorno della settimana che sia lunedì, o martedì,  ecc...

Un tipico vincolo di dominio è costituito anche dalla clausola not null.

Vincoli di t-pla

Detti anche vincoli di riga, sono condizioni che riguardano i dati di una stessa t-pla

Per esempio, se in una stessa riga abbiamo la data di nascita e la data di morte di una persona, la prima dovrà essere inferiore alla seconda-

Vincoli di tabella

Sono condizioni che riguardano l'intera tabella.

Tipicamente, la clausola unique, applicata a una chiave, che specifica che all'interno della tabella il valore della chiave non può comparire più di una volta.

N.B.: Anche la clausola primary key implica un vincolo di unicità

Vincoli di integrità referenziale

Sono detti anche vincoli interrelazionali e riguardano i collegamenti tra i dati di diverse tabelle.
Vengono usati per legare il valore di una colonna (chiave esterna) in una tabella, a quelli di una colonna corrispondente in un'altra tabella, in modo che non sia possibile inserire valori inesistenti.

Tali vincoli vengono imposti con la clausola foreign key ...references


Avanti