Guida [GUIDA] Basi di dati - Il modello relazionale

Stato
Discussione chiusa ad ulteriori risposte.

syscall

Utente Emerald
21 Settembre 2013
683
43
581
475
Ultima modifica da un moderatore:
Salve popolo di inforge :rulz:,

c'eravamo lasciati a discutere di cose brutte, basi di dati, abbiam scritto un'introduzione e una panoramica generale su cosa sono e come funzionano, facendo un po di chiarezza sulle differenze fra dato e informazione e quant'altro e, se non ricordo male, era arrivato il momento di trattare un argomento che si potrebbe definire carino quanta piu' attenzione si presta nel capirlo, ovvero il modello relazionale.

Premetto subito che non so se qualcuno si legga veramente sti poemi che scrivo... per sistemi operativi penso di si, viste le due e tre stelline che piovono a gogo dal cielo :matto: LOL ma vabeh, ma se qualcuno ha comunque intenzione di farlo, almeno per basi di dati, e' necessario un minimo di ripasso alla matematica "base base", teoria degli insiemi e simili per intenderci, in modo da non star li a rileggere le cose cento volte.

Ah, ringrazio inoltre @murdercode, o chiunque sia stato, che mi ha fatto una sezione "apposita" per le mie boiate :rulzz:, anche se definirli "manuali" mi sembra un po' troppo eccessivo, veramente gentilissimi comunque ! Bene, basta cosi' e iniziamo subito ad introdurre il nuovo argomento, buona lettura ragazzi!

Il modello relazionale e' il modello piu' usato per la rappresentazione dei dati e garantisce l'indipendenza dei dati che abbiamo visto si tratta della proprieta' piu' importante dei DBMS.

Si basa su due concetti fondamentali, un concetto semplice e intuitivo, quale e' quello della tabella, ed il concetto di relazione, che e' un concetto che discende dalla matematica, ed in particolare, dalla teoria degli insiemi.

Relazione e tabella sono due concetti riconducibili l'uno all'altro.

Consideriamo il concetto di relazione matematica e prendiamo in considerazione due insiemi:

A={a,b,c}
B={1,2}


Il prodotto cartesiano AxB e' dato dalle coppie {(a1),(a2),(b1),(b2),(c1),(c2)}

Ogni elemento del prodotto cartesiano e' una coppia costituita da un elemento di A e da un elemento di B, in particolare, poiche' gli elementi di A sono tre e gli elementi di B due, il prodotto cartesiano ha un totale di sei elementi.

Possiamo generalizzare la definizione dicendo che:

dati due insiemi D1, D2, il prodotto cartesiano D1xD2 e' dato dalle coppie ordinate
(v1,v2) dove, v1 appartiene a D1 e v2 appartiene a D2.

Dal prodotto cartesiano dell'esempio, possiamo estrarre dei sottoinsiemi, un possibile sottoinsieme del prodotto cartesiano AxB potrebbe essere, ad esempio:

{(a1),(b1),(c2)}

Un sottoinsieme di un prodotto cartesiano e' detto RELAZIONE!

Quindi, {(a1),(b1),(c2)}, e' una relazione sul prodotto cartesiano, o su insiemi, A e B.

Ovviamente possiamo generalizzare i concetti facendo riferimento ad n insiemi, ed in particolare potremmo dire che dati n insiemi (n>0) D1, D2,...,Dn non necessariamente distinti, il prodotto cartesiano di D1xD2x...xDn e' costituito dall'insieme di n-uple (v1,v2,...,vn) tali che vi appartiene a Di per 1<=i<=n.

E concludiamo dicendo che una relazione matematica su D1,D2,...,Dn, e' un sottoinsieme del prodotto cartesiano D1xD2x...,xDn.

Una relazione puo' essere rappresentata in formato tabellare, data appunto {(a1),(b1),(c2)}, possiamo rappresentarla come:

a 1
b 1
c 2

Le tabelle, di fatto, servono proprio per rappresentare relazioni, tuttavia, non tutte le tabelle rappresentano relazioni..

Consideriamo quella in figura:
2r4lao5.jpg
Questa tabella potrebbe rappresentare, ad esempio, l'orario dei voli che da una citta' arrivano in un'altra.

Ma il problema di questa rappresentazione e' che in effetti noi non conosciamo la citta' di partenza, quella d'arrivo ne' quale sia l'ora di partenza ne' quella d'arrivo.

Potrebbe essere comunque una relazione su quattro domini:

string x string x double x double

Per cui e' una relazione matematica in quanto e' un sottinsieme del prodotto cartesiano fra i domini che abbiam appena visto.

Il problema e' che si', possiamo immaginare che la prima colonna rappresenti la citta' di partenza, la seconda la citta' d'arrivo, la terza l'orario di partenza e la quarta l'orario di arrivo, ma cosi' facendo facciamo riferimento ad un sistema posizionale, ecco, in un contesto informatico questo e' inconcepibile, ed e' necessario individuare quindi una soluzione!

La relazione deve possedere delle "intestazioni"!

Se infatti, realizziamo una roba del genere:

25svkid.jpg
... le informazioni incominciano ad essere piu' chiare e il sistema non e' piu' posizionale, scambiando infatti le colonne, riusciamo ad ottenere le medesime informazioni.

Questa tabella rappresenta in effetti il concetto di relazione nel modello relazionale e in sostanza e' una relazione matematica a cui sono stati associati dei nomi ai domini di riferimento, che poi e' stata appunto la soluzione per trasformare il nostro sistemino da posizionale a non posizionale.

Le tabelle sono quindi un metodo molto pratico ed intuitivo per rappresentare relazioni matematiche, tuttavia non tutte le tabelle le rappresentano, poiche' la tabella non deve avere infatti delle righe duplicate, cio' discende direttamente dalla definizione di prodotto cartesiano.

Il prodotto cartesiano di piu' insiemi, infatti, contiene degli elementi fra loro differenti.

Una tabella, ovviamente, non e' sufficiente per rappresentare un'intera base di dati, che invece ne conterra' piu di una... ma vediamo un esempio molto "light" ... che potrebbero rappresentare una gestione aeroportuale.

2gsoj09.png

La base di dati e' costituita quindi dalle tabelle:


  • partenze
  • passeggeri
  • aerei


  • La tabella partenze e' costituita dai campi: Da, A, Partenza, Arrivo, Volo

  • la tabella passeggeri ha come attributi: Nome, Cognome, Data di nascita, Documento, Volo

  • la tabella aerei infine ha i campi: Codice, Compagnia, Nazionalita', Modello

La prima riflessione da fare sulle tre tabelle e' che alcuni valori si ritrovano nelle tre tabelle, in particolare si fa riferimento ai valori contenuti nella colonna volo delle tre colonne e al campo codice.

Questa ripetizione, sostanzialmente, e' il cuore del modello relazionale, infatti il modello si basa su valori e, tali ripetizioni, non fanno altro che tradurre le associazioni tra le varie tabelle.

In pratica, se io volessi conoscere il volo sul quale sara' imbarcato Mario Rossi andro' ad individuare all'interno del campo volo il relativo codice e lo individuero' successivamente all'interno del campo volo della tabella partenze.

Quindi, Mario Rossi prendera' il volo XY678Z e al volo XY678Z corrisponde un volo da Reggio Calabria a Milano che parte alle 7,30 e arriva alle 9!

Questo sistema quindi ci fa comprendere che il modello relazionale si basa sui valori.

I modelli precedenti invece, gerarchico e reticolare (di cui abbiamo accennato durante la guida precedente), sono basati su record e puntatori.

Questo sistema di ripetere dei valori, ci garantisce la proprieta' fondamentale di dipendenza fisica, in particolare ci concentriamo sui valori e non dobbiamo quindi preoccuparci di come sono memorizzati fisicamente i dati. Questo significa che la base di dati potrebbe esser trasferita tranquillamente da un DBSM ad un altro e puo' continuare a funzionare senza problemi.

Diamo comunque alcune definizioni (che potete trovare un po ovunque):

Uno schema di relazione e' costituito da un nome R, su un insieme di attributi X, dove X sono gli attributi a1,a2,...,an.

R(x) dove X={A1, A2...,An}

Uno schema di basi di dati R e' invece un insieme di schemi di relazioni:

R={R1(X1),R2(X2),Rn(Xn)}

Un'istanza di relazione su uno schema R(X) e' un insieme r di tuple su X

Istanza di basi di dati su R={R1(X1), R2(X2),*Rn(Xn)}: insieme di relazioni r={r1,r2,..,rn} dove ogni ri e' una relazione sullo schema Ri(Xi).

Nota: Dire istanza di relazione o dire relazione e' la stessa cosa

Facendo riferimento allo schema precedente, notiamo che lo schema di basi di dati e' costituito da tre schemi di relazione: aerei, passeggeri e partenze, dove appunto i nostri attributi, A1,A2,An, sono per quanto riguarda aerei: codice, compagnia, nazionalita', modello, per passeggeri: nome, cognome, data di nascita, documento, volo e per quanto riguarda partenze: da, a, partenza, arrivo, volo.

R={AEREI (Codice, Compagnia, Nazionalita', Moello),
PASSEGGERI (Nome, Cognome, Data di Nascita, Documento, Volo),
PARTENZE (Da, A, Partenza, Arrivo, Volo)}

Ma modifichiamo un attimo l'esempio della base di dati e aggiungiamo due campi nuovi, tempo e lunch

2u4neio.jpg



Concentriamoci intanto sul campo lunch. Osserviamo che nella colonna abbiamo un campo "particolare".

Immaginiamo che il campo lunch sia un'informazione che andra' fornita alla compagnia aerea affinche' essa possa fornirci qualcosa da mangiare, in base ai nostri gusti :sisi:

In pratica dobbiamo fornire alla compagnia aerea l'informazione relativamente al fatto se un ipotetico passeggero sia vegetariano o meno.

In alcuni casi tale informazione e' inutile, quando ad esempio la tratta non prevede l'erogazione di un pasto. In tal caso, fornire un'informazione di questo tipo potrebbe essere superflua e, pertanto, si aggiunge ad ogni dominio la possibilita' di mettere un valore nuovo, il valore NULL (che pronunciamo nall).

NULL e' un valore preciso, che indica l'impossibilita' di indicare un valore contenuto del dominio.

L'uso pero' di troppi campi NULL puo' diventare "pericoloso" e non bisogna abusarne. In un singolo record l'uso di troppi campi NULL potrebbero inficiare l'intera tupla o addirittura l'intera relazione, tante' che comunque molti DBMS, nel momento in cui si specifica la struttura della base dati, richiedono di indicare se su un determinato campo sono ammissibili valori NULL o meno, non tutti i valori quindi sono ammessi sulle tuple, ci sono alcuni valori che non possono essere inseriti.

Le varie tuple devono rispettare dei vincoli, introduciamo quindi i vincoli di integrita' di tipo:


  • Intrarelazionale (quando il soddisfacimento del vincolo coinvolge una sola relazione)
  • Interrazionale (quando il soddisfacimento del vincolo coinvolge piu' relazioni.

Il vincolo intrarelazionale, inoltre, puo' essere diviso in:


  • Vincolo di tupla;
  • Vincolo su valori (o di dominio)

... ma chiariamo con un esempio i due vincoli:

Il vincolo di dominio: il singolo campo deve avere un valore contenuto all'interno del dominio.

Consideriamo ad esempio il campo Arrivo.

(Arrivo >= 00,00) and (Arrivo <= 23.59)

Ovvero, il campo arrivo puo' essere valido solo se e' maggiore della mezzanotte e minore delle 23,59...
Un valore esterno a questo range chiaramente rendera' insignificante il contenuto di quel campo.

(Naturalmente anche la partenza ha lo stesso vincolo di dominio)

Un vincolo di tupla invece, si risolve all'interno della singola tupla, ad esempio:

I valori attribuiti al campo tempo devono inevitabilmente essere pari all'arrivo meno la partenza, quindi:

Tempo= Arrivo-Partenza (Solo quei valori saranno validi!)

Riusciamo comunque ad individuare altri vincoli di tupla, come ad esempio che l'arrivo deve essere maggiore della partenza, oppure dovrebbe esserci una data di partenza o di arrivo (che potrebbero anche coincidere ma comunque la data di partenza dovrebbe essere minore o uguale alla data di arrivo), ma comunque visto l'esempio "light" ho volutamente tralasciato alcuni aspetti e dettagli.

Ma non esistono solo questi come vincoli di tipo intrarelazionale, anzi, a tal proposito, diciamo che Il principale vincolo di questo tipo e' il vincolo di chiave.

Prendiamo ad esempio in considerazione la tabella passeggeri:



nxt6dh.png


Possiamo individuare l'insieme dei campi nome cognome e data di nascita.

L'insieme di questi tre campi, ci permette di recuperare gli altri valori della singola tupla!

Senza questi non avremmo potuto recuperare correttamente gli altri valori, poiche' ad esempio, se ci fate caso, Mario Rossi si ripete sia sulla prima che sulla quarta riga, ma notiamo subito che si trattano di persone diverse poiche' hanno due date di nascita diverse.

Per cui e' fondamentale individuare all'interno di una tabella un insieme di campi dati i quali si riesce a risalire a tutte le altre informazioni contenute le singolo record.

Possiamo quindi introdurre una definizione fondamentale, introduciamo la superchiave.

K e' superchiave della relazione r se in r non esistono due tuple distinte t1 e t2 tale che t1[k] sia uguale a t2[k]

Una superchiave ci permette quindi di risalire a tutti gli altri elementi della tupla.

Se quindi andiamo a considerare appunto l'esempio precedente , nome conogme e data di nascita e' quindi superchiave.

Potremmo anche estrarre un sottoinsieme costituito dagli attributi cognome e data di nascita e riuscire ancora a risalire alle stesse informazioni, infatti i due Rossi hanno date di nascita diverse (come anche il resto delle altre informazioni), possiamo estrarre quindi un'altra superchiave. La precedente quindi, ricorsivamente, puo' essere "attraversata" e da essa possono essere estratte ulteriori superchiavi.

Definiamo quindi:

K e' chiave di r se K e' una superchiave minimale di r, in altre parole, data una superchiave, se da essa non e' possibile estrarre ulteriori superchiavi, siamo di fronte ad una chiave!

Nella fattispecie dell'esempio precedente quindi, da nome cognome e data di nascita siamo arrivati a cognome e data di nascita, e da cognome e data di nascita possiamo estrarre data di nascita, che sara' quindi un'ulteriore superchiave ma, siccome non e' possibile andar oltre, possiamo dire che data di nascita e' una chiave della nostra relazione!

Tuttavia e' solo "un caso" che sia una chiave, cioe' nel nostro esempio non esistono due record che abbiano la stessa data di nascita, e' possibile quindi che a breve prenotera' un passeggero nato lo stesso giorno di un altro e quindi lo status di chiave dell'attributo data di nascita' decadra'.

E' fondamentale, nel contesto delle basi di dati, individuare delle chiavi che non siano legate all'istanza ma siano legate all'attributo, ad esempio, per chiarire meglio possiamo fare riferimento all'attributo documento.

L'attributo documento intanto e' superchiave, e certamente anche chiave, in quanto unico attributo si tratta di una superchiave minimale.

Per come e' concepito documento, noi sappiamo che il codice del documento contraddistingue univocamente ogni singola persona, quindi dato uno specifico documento questo sara' comunque diverso da qualsiasi altro.

Quindi documento e' chiave, indipendentemente dal valore, ma e' fondamentale che documento non assuma valori NULL.

Se ci fossero due righe con valori NULL nel campo documento quest'ultimo non sarebbe neppure chiave :lol:, per cui e' fondamentale che su alcuni chiavi non siano ammessi valori NULL.

Definiamo quindi, chiave primaria, una chiave su cui non sono ammessi valori NULL!

Per esempio, nel caso della tabella aerei, abbiamo il campo codice che e' il campo chiave.

qowolj.png

Se per definizione, per scelta, decidiamo che nella tabella aerei il suddetto campo non potra' assumere valori NULL, allora il campo codice sara' la nostra chiave primaria.

E' fondamentale all'interno di ogni tabella individuare una chiave primaria, proprio per definizione del modello relazionale, che si puo' applicare solo grazie all'uso delle chiavi.

Ma adesso andiamo adesso a definire:


  • Vincolo di integrita' referenziale fra un insieme di attributi X di una relazione R1 e un'altra R2, e' soddisfatto se i valori su X di ciascuna tupla dell'istanza R1 compaiono come valori della chiave primaria dell'istanza R2

Questo e' il principale vincolo di tipo interrelazionale, che coinvolge piu' tabelle, ed e' quello che ci permette di tradurre l'associazione tra le tabelle.

Per capire meglio quello che abbiamo appena scritto, riprendiamo in considerazione le tabelle:

nxt6dh.png

Immaginiamo che passeggeri sia relazione R1 e aerei R2
qowolj.png

Vediamo che i valori contenuti nel campo volo, sono in effetti i codici della tabella aerei, cioe' compaiono come valori della chiave primaria dell'istanza R2, quindi c'e' un vincolo di integrita' referenziale fra l'insieme di attributi di volo e la relazione R2.

Il modello relazionale si concretizza appunto grazie a questo vincolo, senza il quale non avrebbe alcun senso e magari non esisterebbe neanche!

Bene dai, puo' bastare per adesso, la prossima volta, se riesco, vedremo la progettazione di una base di dati anche se c'e' comunque da dire che sto notando che, rispetto a sistemi operativi, scrivere di basi di dati (in maniera semplice e quasi "terra terra"), e' molto piu' dispendioso e oneroso, poiche' serve piu' tempo per chiarire meglio quei concetti matematici che ci stan dentro e per realizzare le piccole grafiche che ci servono per capire meglio quello che leggiamo, pertanto ci mettero' un po' di piu' a rilasciare ogni guida, ma non temete, sicuramente riusciremo, come per sistemi operativi, a portare a termine quest'argomento ;-)

Ciao, ciao o/
 
Stato
Discussione chiusa ad ulteriori risposte.