Basi di dati - Riassunto esame, prof. Coccoli

 rappresenta un certo aspetto del mondo reale (dominio od universo del discorso): i cambiamenti in tale dominio si

riflettono sulla Base di Dati;

 è una collezione di dati logicamente coerenti con un significato intrinseco: questo significa che un assortimento

casuale di dati non può essere considerato una Base di Dati;

 è progettata, costruita e popolata con dati per uno scopo specifico: una Base di Dati è sempre associata ad un

determinato gruppo ed alcune applicazioni a cui questi sono interessati.

In altre parole una Base di Dati presenta una sorgente da cui derivano i dati, un certo grado di interazione con gli

eventi del mondo reale, ed un pubblico che è attivamente interessato al suo contenuto.

La definizione precedentemente restringe perciò l'insieme delle collezioni di dati che possono essere considerati Basi di

Dati. Esempi più significativi sono perciò: l'insieme delle informazioni che sono gestite dall'anagrafe comunale per tenere

traccia degli abitanti, l'insieme dei dati associati ad ogni contribuente per il pagamento delle tasse, oppure l'insieme delle

schede che catalogano i libri di una biblioteca. Osserviamo che in tal caso non è il volume dei dati che caratterizza l'essere

o meno una Base di Dati ma il fatto che sussistano le proprietà precedentemente elencate: in tutti gli esempi è infatti

possibile individuare il dominio del discorso, la coerenza logica delle informazioni in esame, e l'insieme di utenti ed

Detto questo una Base di Dati può essere composta soltanto da pochi elementi (quale può

applicazioni in gioco.

essere la propria collezione di CD e DVD) o da milioni di elementi (quali possono essere le informazioni storiche

sull'andamento del meteo in una regione). Sistema di Gestione delle Basi di Dati (DBMS –

Le Basi di Dati sono rese accessibili attraverso i sistemi opportuni. Un

Database Management System) è un insieme di programmi che permettono agli utenti di creare e mantenere una Base di

sistema software con scopi generali

Dati. Un DBMS è perciò un che permette di definire, costruire, manipolare e

condividere Basi di Dati per varie applicazioni. Vediamo ora più nel dettaglio quale sia il significato di queste attività:

 Definire una Base di Dati implica specificare i tipi di dati che questa ospiterà al suo interno le loro strutture ed i

vincoli a cui devono sottostare.

 Costruire una Base di Dati significa immagazzinare i dati stessi in un supporto di memorizzazione controllato dal

DBMS.

 Manipolare una Base di Dati vuol dire effettuare delle ricerche sulla collezione dei dati per estrarne delle

informazioni e dei prospetti (report), aggiornare la Base di Dati per renderla coerente con il dominio a cui è

associata ed eventualmente cambiarne la struttura quando il dominio muta.

 Condividere una Base di Dati significa consentire a più utenti e programmi di accedere contemporaneamente ad

essa.

La figura 1 fornisce uno schema di massima di come sia organizzato un sistema di gestione per di Basi di Dati o più

semplicemente DBMS.

In un sistema come quello descritto in figura vi sono diverse figure professionali che giocano un ruolo importante:

 della Base di Dati:

l'amministratore l'amministratore è la figura che gestisce e mantiene la Base di Dati e si

occupa del corretto funzionamento del DBMS. Il DBA (Database Administrator) è il garante del funzionamento

della Base di Dati e quindi deve rispondere delle violazioni di sicurezza e di eventuali rendimenti scadenti del

sistema. Nel caso di Basi di Dati di grandi dimensioni il DBA è supportato da uno staff di persone;

 progettisti della Base di Dati:

i sono coloro che si occupano di definire la strutture adeguate per rappresentare i

dati e di individuare i dati stessi da memorizzare. I progettisti delle Basi di Dati interagiscono con tutti i potenziali

utenti del sistema per individuare e quindi definire in maniera precisa il dominio del discorso associato alla Base

di Dati;

 utenti della Base di Dati:

gli questi sono quelle persone le cui attività lavorative richiedono l'accesso alla Base di

Dati per interrogazioni, aggiornamenti e generazioni di prospetti. Di fatto, la Base di Dati è stata realizzata per

loro;

 analisti di sistema programmatori di applicazioni:

gli e sono coloro che Facoltà di Scienze della

rispettivamente determinano le esigenze degli utenti finali, sviluppano le specifiche per le operazioni che verranno

3

i .

più frequentemente svolte sulla Base di Dati e implementano i programmi che effettuano queste operazion

Figura 1: Architettura di un Sistema di Basi di Dati

3 Questa ultima classe di utenti non deve essere confusa con i progettisti delle Basi di Dati. I primi infatti determinano la struttura ed il dominio associato alla Base di Dati, i secondi

intervengono in un momento successivo per fornire degli strumenti di alto livello agli utenti finali e rendere più efficiente l'interazione con la Base di Dati

2

Esiste una classe di applicazioni per la gestione delle Basi di Dati che in realtà non presenta tutte le caratteristiche

elencate. Tali applicazioni sono normalmente orientate alla gestione delle Basi di Dati ad uso personale. Le Basi di Dati ad

uso personale rappresentano un caso particolare delle Basi di Dati in quanto l'insieme degli utenti interessati ai dati è

normalmente molto ridotto e nella maggior parte composto da una sola persona: le figure professionali precedentemente

elencate sono di fatto coperte da un unico individuo che l'utente finale della Base di Dati. Tali Basi di Dati spesso

immagazzinano un numero di dati relativamente ridotto e costituiscono un esempio su piccola scala di quello che sono le

Basi di Dati in generale. Le applicazioni che gestiscono le Basi di Dati ad uso personale, di cui alcuni esempi sono

OpenOffice.org Base e Microsoft Access, hanno un insieme di funzionalità ridotte rispetto ai DBMS ad esempio non sono

pensati per gestire l'accesso concorrente di più utenti, non devono sottostare a determinati requisiti di performance, ne

presentano strumenti sofisticati per l'analisi dei dati. Tali applicazioni sono maggiormente orientate ad offrire uno

strumento semplice per la gestione di piccole Basi di Dati per persone non esperte. Nonostante ciò sono un ottimo esempio

di Base di Dati e verranno utilizzate nell'ambito di questo corso come strumento per la progettazione e l'utilizzo della Base

di Dati di esempio.

1.3.2 Un Esempio

È possibile ora fornire un primo esempio più significativo di una Base di Dati. L'esempio qui riportato è adatto sia per

modellare una Base di Dati sofisticata sia una Base di Dati ad uso personale. In tal caso si sceglierà un livello di dettaglio

inferiore e si trascureranno tutti quegli aspetti associati alla gestione dell'insieme di utenti associati alla Base di Dati, ai

requisiti di performance ed all'accesso concorrente. L'esempio presentato sarà inoltre l'esempio guida che verrà utilizzato

per illustrare i diversi concetti associati alle Basi di Dati.

Consideriamo un esempio a noi familiare cercando di modellare uno scenario reale con cui abbiamo a che fare

quotidianamente: vogliamo costruire una Base di Dati in grado di modellare con buona approssimazione l'attività di una

Facoltà Universitaria. L'attività è determinata da coloro che la frequentano ovvero gli studenti, i professori, i dottorandi, i

ricercatori, ed il personale amministrativo. Una facoltà è costituita da più dipartimenti ai quali appartengono i professori, i

ricercatori ed il personale amministrativo ed ogni dipartimento ha un direttore. I professori tengono dei corsi che sono

frequentati dagli studenti. Gli studenti hanno un piano di studi che individua i corsi che devono frequentare ed hanno una

media voti. Il personale accademico della facoltà oltre ad insegnare porta avanti dei progetti di ricerca, un progetto

normalmente prevede un responsabile ed ha un dipartimento di riferimento.

La caratterizzazione di una facoltà universitaria effettuata con la precedente descrizione ci permette di individuare a grandi

linee quali siano i dati e le informazioni di interesse per rappresentare tale realtà con una Base di Dati. In un primo

momento si potrebbe pensare di organizzare questo insieme di informazioni in un insieme di file che contengono tali dati.

Con riferimento alle sole informazioni riguardanti lo studente potremmo definire i seguenti file:

 il file degli studenti: questo memorizza l'elenco degli studenti con i dati anagrafici di interesse per l'università;

 il file degli insegnamenti: questo mantiene l'elenco degli insegnamenti disponibili in una facoltà e le informazioni

che li qualificano;

 il file dei moduli: un modulo identifica un particolare insegnamento tenuto da un particolare docente in un

determinato anno e semestre. Il file dei moduli mantiene l'elenco dei moduli;

 il file delle votazioni: una voto è associato ad un particolare studente ed u determinato modulo. Il file delle

votazioni mantiene l'elenco di tutte le votazioni di tutti i moduli e di tutti gli studenti;

 il file dei docenti: mantiene l'elenco dei docenti che lavorano in una facoltà con il dipartimento di appartenenza;

 il file dei dipartimenti: il file mantiene l'elenco dei dipartimenti registrando per ognuno alcune informazioni di

carattere burocratico ed ad esempio il direttore.

I file precedentemente introdotti saranno organizzati con una struttura a record: informalmente possiamo pensare ad una

struttura tabellare in cui ogni riga rappresenta appunto le informazioni associate ad un record. I record presenti in un file

hanno tutti gli stessi attributi (le colonne della tabella) in quanto modellano sempre la stessa entità. Ad esempio il file degli

studenti conterrà un record per ogni studente e per ogni studente ci interesserà memorizzare gli stessi attributi (matricola,

nome, cognome...). La figura 7 illustra una possibile organizzazione dei file sopra elencati.

Possiamo in questo caso riscontrare le differenti proprietà che caratterizzano una base di dati. In questo caso il dominio

del discorso scelto è quello della facoltà universitaria con tutto ciò che ne consegue: al mutare delle entità di questo

dominio la Base di Dati deve essere aggiornata di conseguenza. Le entità che abbiamo preso in esame costituiscono una

collezione di dati logicamente coerente: studenti, professori, ricercatori, corsi, dipartimenti, etc sono tutti collegati tra loro

(non abbiamo ad esempio preso in considerazione i tipi di piante presenti nel giardino della facoltà, o l'insieme dei bar

presenti nella giostra della città). Esiste un insieme di utenti che sono interessati alla base dati: questo personalmente

costituito dal personale amministrativo, ma anche dai professori o dagli studenti che vogliono visualizzare il proprio

percorso accademico. Ognuna di queste categorie di utenti sarà interessata ad una diversa vista della Base di Dati ed

utilizzerà diversi strumenti per interagire con essa: il computer degli uffici amministrativi, l'accesso via web od i terminali

self service. 3

Figura 2: Organizzazione dei file e struttura dei record con alcuni dati inseriti

Parimenti se vogliamo individuare le attività che caratterizzano il DBMS associato a questa Base di Dati potremmo

osservare che definire la Base di Dati in tal caso consiste nell'identificare le entità da associare ai record e definirne gli

attributi. Costruire la Base di Dati comporta realizzare i file presi in esame ed inserirvi tutti i record necessari.

Manipolare la Base di Dati consiste effettuare delle ricerche all'interno di questi file per avere ad esempio l'elenco dei

moduli tenuti in un semestre o semplicemente aggiornarne il contenuto. Condividere la Base di Dati significa rendere

accessibile questo insieme di file ai diversi gruppi di utenti con gli opportuni profili di sicurezza: lo studente potrà ad

esempio consultare il proprio status da un terminale self service ma non dovrà essergli consentito di modificare il voto

preso ad un esame.

In questo primo esempio, non si è tenuto conto del ruolo e delle relazioni che sono associate ai piani di studi, ai ricercatori,

ai progetti ed al personale amministrativo. Pur senza l'introduzione di tali elementi l'esempio riportato è di fatto

sufficientemente articolato per costituire un prima stesura della base dati. In particolare è utile osservare come il livello di

dettaglio che si sceglie di utilizzare e la precisione con cui si vuole rappresentare il dominio di riferimento possano rendere

più o meno complessa la progettazione di una Base di Dati.

La modellazione dell'insieme delle entità del dominio associato alla realtà che si vuole rappresentare e delle relazioni che

progettazione concettuale

intercorrono tra queste fa parte della di una Base di Dati ed assume un ruolo fondamentale

nella realizzazione di una Base di Dati. Vedremo più in dettaglio nel caso del modello relazionale come si affronta

un'attività di questo tipo.

1.3.3 Caratteristiche dell'Approccio con Basi di Dati

L'approccio tradizionale basato sulla gestione di file presenta significative differenze rispetto all'approccio fornito da una

Base di Dati. Nel caso precedente utilizzando il normale approccio basato sulla programmazione di file ogni gruppo di

utenti avrebbe avuto una copia separata dei file su cui devono lavorare: l'ufficio per la registrazione dei voti potrebbe

gestire i file degli studenti; l'ufficio contabilità terrebbe traccia principalmente dei file degli studenti. Per ognuno di questi

gruppi di utenti si sarebbe dovuto progettare un diverso tipo di applicazioni per modificare, visualizzare e stampare

prospetti dei file.

È evidente che questo approccio può funzionare quando l'insieme dei file da gestire è molto ridotto. In ogni caso risulta

dispendioso replicare più volte le stesse informazioni ma cosa ancora più importante risulta difficile mantenere la

consistenza tra i diversi file che contengono le stesse informazioni: se uno studente si ritira o termina il suo percorso di

centralizza

studi tutti i file degli studenti devono essere aggiornati coerentemente. L'approccio proposto dalle Basi di Dati

la collezione dei dati a cui accedono tutti gli utenti. L'approccio proposto dalle Basi di Dati prevede non solo la presenza

di un repository centrale che memorizza la collezione dei dati ma richiede necessariamente l'utilizzo di un Sistema per la

Gestione della Base di Dati o DBMS. L'utilizzo congiunto di una Base di Dati e di un DBMS porta ad un sistema con le

seguenti proprietà:

 natura autodescrittiva di un sistema di Basi di Dati: un sistema di Basi di Dati contiene non solo la collezione

dei dati ma anche la definizione o la descrizione completa della sua struttura e dei vincoli a cui deve sottostare.

metadati catalogo

Queste informazioni vengono dette e sono memorizzate nel del sistema. Il catalogo viene

utilizzato sia dal DBMS sia dagli utenti per interagire con la Base di Dati. Questa è una caratteristica molto

importante in quanto permette al DBMS di lavorare con qualsiasi Base di Dati. Osserviamo che nell'esempio

precedentemente proposto non vi è stata introdotta alcuna struttura atta a descrivere i file e quindi il software

per la gestione della Base di Dati risulta di fatto vincolato alla Base di Dati stessa;

 separazione tra programmi e dati ed astrazione dei dati: nella tradizionale gestione file la struttura dei file di

dati è inserita nei programmi che devono accedervi, e pertanto qualsiasi cambiamento nella struttura dei file si

riflette nei programmi stessi che devono essere cambiati. Al contrario nella maggior parte dei casi i programmi di

accesso al DBMS non richiedono cambiamenti se la Base di Dati si modifica, è il DBMS stesso utilizzando il

catalogo a gestire la struttura della Base di Dati modificandola se necessario, fornendo, quando possibile,

un'interfaccia immutata per i programmi. Questa proprietà viene appunto definita separazione tra programmi e

dati. Ciò che di fatto permette tale separazione è l'astrazione dei dati: il DBMS fornisce infatti agli utenti una

rappresentazione concettuale dei dati limitando i dettagli su come questi sono memorizzati e su come sono

implementati le operazioni su di essi

 supporto di viste multiple dei dati: una Base di Dati ha generalmente molti utenti, ognuno dei quali può

vista.

richiederne una diversa prospettiva o Una vista può contenere un sottoinsieme della collezione dei dati od

anche contenere dati virtuali che non sono direttamente memorizzati nella Base di Dati ma derivati da essi

attraverso opportuni processi di calcolo (ad esempio tramite qualche funzione di aggregazione). La disponibilità di

4

differenti viste rende di fatto la Base di Dati utilizzabile da diversi gruppi di utenti pur mantenendo la centralità

della collezione dei dati;

 condivisione dei dati e gestione delle transazioni con utenti multipli: il DBMS deve consentire l'accesso a

più utenti contemporaneamente ed in particolare deve occuparsi del controllo della concorrenza ovvero evitare

che molteplici accessi contemporanei rendano la collezione dei dati inconsistente. In tal senso assume particolare

transazioni.

importanza la gestione delle Una transazione è una sequenza di operazioni che deve essere eseguita

in maniera atomica. Con il termine atomica si fa riferimento al fatto che la sequenza deve essere eseguita in

maniera completa oppure non deve essere assolutamente eseguita. Nel momento in cui vi sono più utenti che

eseguono transazioni il DBMS deve garantire che le transazioni non vengano eseguite parzialmente rendendo la

collezione dei dati inconsistente.

Nel caso delle Basi di Dati ad uso personale alcune di queste caratteristiche vengono meno in particolare assumono meno

importanza il supporto alle viste multiple, la condivisione dei dati e la gestione delle transazioni con utenti multipli. In

questo tipo di applicazioni essendo l'utente molto spesso uno solo non è necessaria una gestione della concorrenza.

Rimangono però valide le altre proprietà in quanto grazie a queste gli applicativi per la gestione delle Basi di Dati ad uso

personale possono essere utilizzati per gestire differenti Basi di Dati. OpenOffice.org Base e Microsoft Access permettono

infatti di definire ed utilizzare differenti Basi di Dati che vengono poi memorizzate in singoli file e utilizzate all'occorrenza.

1.3.4 Vantaggi dell'Utilizzo di un DBMS

Un sistema con le proprietà precedentemente descritte offre differenti vantaggi. In questo paragrafo vedremo brevemente

quali sono i vantaggi nell'utilizzare un approccio basato sulle Basi di Dati e quindi un DBMS. Osserviamo che tali vantaggi

sono più strettamente collegati ai servizi offerti dal DBMS piuttosto che dalla Base di Dati stessa , questi sono:

4

 controllo della ridondanza: poiché una Base di Dati centralizza la collezione dei dati e quindi evita la

duplicazione dei dati. La centralizzazione dei dati permette di eliminare le inconsistenze dovute alla mancanza di

sincronizzazione delle diverse copie degli stessi dati e di ridurre lo spazio di memoria utilizzato. Può però capitare

che molto spesso venga richiesta una certa ridondanza di alcuni dati per migliorare le prestazioni delle

interrogazioni: questa ridondanza è controllata dal DBMS che garantisce comunque la consistenza dei dati;

 controllo degli accessi: un DBMS fornisce naturalmente un sistema per la gestione degli utenti, dei diversi ruoli

che ricoprono e dei differenti diritti che questi hanno sulla Base di Dati. Ogni accesso alla Base di Dati è

controllato dal DBMS che garantisce che i singoli utenti possano eseguire solo le operazioni che gli sono

consentite dai loro profili di sicurezza;

 rappresentazione di associazioni complesse tra i dati: una Base di Dati può contenere numerose tipologie di

dati associati in molti modi. Il DBMS deve perciò essere in grado di rappresentare una varietà di associazioni

complesse tra i dati, e di recuperare e aggiornare facilmente ed efficientemente i dati correlati;

 imposizione di vincoli di integrità: molte applicazioni di Basi di Dati presentano dei vincoli di integrità che

devono valere per i dati. Un DBMS fornisce servizi per definire ed imporre tali vincoli che riguardano ad esempio

l'insieme dei valori considerati validi per un tipo di dato o generalmente vincoli dedotti dal significato o semantica

dei dati e del dominio che rappresentano;

 flessibilità: un DBMS permette di modificare agevolmente la struttura della Base di Dati quando il dominio che

questa rappresenta cambia. Tale operazione viene normalmente eseguita senza coinvolgere i dati memorizzati ed i

programmi applicativi esistenti;

 tempi di sviluppo ridotti: una ragione di successo fondamentale dell'approccio con Basi di Dati è che lo

sviluppo di una nuova applicazione richiede molto poco tempo (se la Base di Dati è ovviamente la stessa). La

progettazione ex-novo di una Base di Dati può richiedere molto tempo, ma una volta che questa è stata realizzata

ed è in funzione introdurre operazioni aggiuntive sulla collezione dei dati richiede molto meno tempo.

L'implementazione di tali operazioni utilizza i servizi del DBMS;

 disponibilità di numerose interfacce utente: un DBMS fornisce una molteplicità di interfacce utente atte a

soddisfare le diverse esigenze dei diversi gruppi di utenti che interagiscono con la Base di Dati. Queste

comprendono i linguaggi di interrogazione, linguaggi di programmazione ed interfacce grafiche;

 strutture di memorizzazione per l'esecuzione efficiente di interrogazioni: uno dei principali requisiti dei

sistemi delle Basi di Dati è quello di eseguire efficientemente interrogazioni ed aggiornamenti. Il DBMS fornisce

solitamente strutture interne a supporto di queste operazioni utilizzando indici, tecniche di buffering e

componenti per l'ottimizzazione delle interrogazioni;

 backup e recovery: un DBMS fornisce funzioni di ripristino da guasti hardware e software. Ogni DBMS che si

rispetti dispone infatti di un sottosistema di backup (salvataggio) e recovery (ripristino) che si occupa di

mantenere la Base di Dati sempre in uno stato consistente: ad esempio si occupa di completare una transazione

rimasta a metà a causa di un guasto.

Anche in questo caso alcuni dei vantaggi elencati non vi sono nel caso degli applicativi pensati per le Basi di Dati ad uso

personale. In particolare le funzionalità di backup e recovery non sono implementate o lo sono parzialmente: essendovi un

solo utente è d'altronde un'esigenza meno sentita. Allo stesso modo l'utilizzo di strutture per l'esecuzione efficiente di

interrogazioni non è cruciale in quanto la Base di Dati è normalmente contenuta e sottoposta ad una pressione minore.

Rimangono la flessibilità, i tempi di sviluppo ridotti, e la possibilità di rappresentare strutture dati complesse ed imporre

vincoli di integrità sui dati. La naturale mono-utenza delle Basi di Dati non richiede inoltre un controllo della ridondanza

sofisticato né un controllo d'accesso.

2. Basi di Dati Relazionali

2.1 Introduzione

4 Un DBMS non sussiste di fatto senza una Base di Dati per cui i vantaggi offerti da un DBMS sono in ultima analisi derivati dall'approccio orientato sulle Basi di Dati.

5

In questa sezione verranno descritti gli elementi principali del modello Entità – Relazione che costituisce il modello

concettuale maggiormente utilizzato per la modellazione delle Basi di Dati. Verrà successivamente descritto come sia

possibile tradurre i Modelli concettuali elaborati in una Base di Dati reale utilizzando il modello relazionale. Il modello

Entità - Relazione e quello Relazionale con le loro eventuali estensioni costituiscono di fatto uno standard rispettivamente

nella progettazione e nell'implementazione delle Basi di Dati.

Figura 3: Fasi della progettazione di una Base di Dati

La realizzazione completa di una Base di Dati segue il processo descritto in figura 3. Gli strumenti che descriveremo in

questa sezione si occupano rispettivamente della progettazione concettuale e logica di una Base di Dati e costituiscono

perciò una significativa componente dell'intero processo di realizzazione di una Base di Dati.

2.2 Il Modello Entità – Relazione

Entità – Relazione (ER)

Il modello ci permette di descrivere i dati che modellano uno scenario reale in termini di oggetti

od entità e delle relazioni che intercorrono tra loro. Il modello relazionale fornisce dei concetti utili che ci permettono di

passare da una descrizione informale di come gli utenti vedono il mondo per cui viene modellata la Base di Dati ad una più

dettagliata e precisa descrizione che può essere utilizzata per costruire una Base di Dati. Per tal motivo il modello ER viene

utilizzato a valle della fase di analisi e raccolta dei requisiti durante la progettazione concettuale. Il prodotto principale

della progettazione concettuale è uno schema concettuale che fornisce una descrizione formale di tutti gli elementi ed i

legami di interesse nel dominio; in questo caso lo schema concettuale sarà costituito da uno od una sequenza di modelli

ER che descrivono il dominio .

5

2.2.1 Entità, Attributi entità

Il modello ER introduce il concetto di ovvero un oggetto del mondo reale che è distinguibile da altri oggetti. Un

entità può avere un'esistenza fisica – ad esempio uno studente, un professore, etc.. – oppure un'esistenza puramente a

livello concettuale – ad esempio un corso universitario, un esame etc.. Le entità costituiscono l'elemento base per

modellare il dominio associato alla Base di Dati e sono utilizzate per identificare una collezione di elementi simili e

rappresentano un modello (c'è il concetto di studente, dipartimento, progetto, etc..).

attributi.

Un'entità è definita da un'insieme di Un attributo è definito da un nome e da un tipo: il nome è una stringa con

cui ci si riferisce all'attributo mentre il tipo definisce quali valori sono accettabili per esso. L'attributo matricola dell'entità

studente è nel nostro caso di tipo numerico. Gli attributi caratterizzano un tipo di entità e la scelta degli attributi per una

determinata entità riflette il livello di dettaglio con cui si vuole rappresentare l'oggetto del mondo reale. Ad esempio l'entità

studente possiede gli attributi matricola, nome, cognome, l'anno ed il riferimento al corso di laurea a cui è iscritto. Questa

è una particolare scelta degli attributi per l'entità studente ed ovviamente dettata dagli scopi per i quali si progetta una

Base di Dati. In altri contesti si sarebbe potuto modellare l'entità studente con un insieme diverso di attributi o

semplicemente avremmo potuto non separare gli attributi nome e cognome. Per ogni attributo viene inoltre specificato

dominio dell'attributo 6

l'insieme dei valori possibili che possono essere assunti da questo; tale insieme prende il nome di .

Nel caso portato ad esempio il dominio dell'attributo matricola dell'entità studente è l'insieme di tutti i numeri a 7 cifre che

sono considerate matricole valide dall'università. Si osservi che il dominio dell'attributo è generalmente un sottoinsieme del

tipo e può anche coincidere con esso.

Tipologie di Attributi

Gli attributi presentano altre qualità che li caratterizzano. In particolare possono essere, semplici o composti, memorizzati

o derivati, a valore singolo o multi-valore, attributi chiave, attributi a valore nullo. Un attributo può avere più d'una delle

qualità introdotto ad esempio potremmo avere un attributo chiave composto. Vediamo più nel dettaglio quale sia il

significato di queste qualità:

 attributi semplici e composti: gli attributi composti sono scomponibili in elementi più piccoli che costituiscono

degli attributi di base con dei significati indipendenti. Per gli attributi semplici non è invece possibile effettuare

questa operazioni in quanto non sono ulteriormente scomponibili. Un esempio di attributo composto è l'indirizzo

questo normalmente può essere scomposto in un numero civico, nel nome della piazza o via e nel nome della

5 Lo schema concettuale non presenta una forma stabilita ma dipende fortemente dagli strumenti utilizzati durante la progettazione concettuale. Nel caso in esame avendo scelto

come modello quello Entità – Relazione la forma dello schema concettuale sarà dettata dalle convenzioni adottate dal modello ER

6 Il dominio dell'attributo non deve essere confuso con il dominio del discorso o semplicemente dominio che individua lo scenario reale modellato dalla Base di Dati

6

città. Un esempio di attributo semplice può essere l'anno a cui uno studente è iscritto. Gli attributi composti sono

utili quando si fa riferimento ad una caratteristica di un'entità sia considerandola come un tutt'uno sia

considerandone le componenti. Se non vi è questa esigenza anche attributi che sono naturalmente composti

possono essere considerati e modellati come attributi semplici (in tal caso l'indirizzo sarebbe modellato come una

stringa);

 attributi memorizzati o derivati: gli attributi memorizzati sono quelli il cui valore viene specificato

esplicitamente e conservato nella base dati, mentre gli attributi derivati sono attributi che hanno una dipendenza

da altri attributi per cui il loro valore non deve essere esplicitamente mantenuto nella Base di Dati ma il loro

valore può essere dedotto da quello da cui dipendono. Se consideriamo l'entità studente e vogliamo modellarlo

mantenendo anche informazioni sulla sua anagrafica potremmo introdurre gli attributi data di nascita ed età. Se

manteniamo la data di nascita l'età diventa un attributo derivato in quanto il suo valore può essere derivato dalla

data di nascita;

 attributi a singolo valore e multivalore: la maggior parte degli attributi presenta un unico valore per data

entità, questi vengono definiti attributi a valore singolo. In alcuni casi è possibile avere più valori per un

attributo, in tal caso si parlerà di attributi multi-valore. Un esempio di attributo a valore singolo è la matricola

mentre un attributo a valore multiplo potrebbe essere il numero di telefono;

 attributi a valore nullo: gli attributi possono spesso avere un valore non definito o nullo. Tali attributi assumono

null.

un valore particolare che è il valore Questo valore può avere diversi significati, ad esempio semplicemente

non vi può essere alcun valore adatto tra quelli possibili per una particolare istanza di un'entità, oppure vi

potrebbe essere un valore adatto ma questo non è noto. In generale perciò il significato che assume tale valore è

rispettivamente quello di non applicabile o non noto.

2.2.2 Tipi di Entità e Chiavi

Le entità rappresentano i singoli oggetti nel mondo reale. Durante la progettazione concettuale si individuano non tanto le

singole entità ma i gruppi di entità che sono simili; con l'accezione simili ci si riferisce al fatto che tali entità presentano gli

stessi tipi di attributi ma possono assumere valori diversi per essi. La progettazione concettuale è perciò maggiormente

interessata ad individuare e definire tali gruppi piuttosto che le singole entità: ci si riferisce a tali gruppi con il termine

tipo di entità. Figura 4: Relazione tra intensione ed estensione

schema intensione

Un tipo di entità descrive lo o per un insieme di entità che condividono la stessa struttura. La raccolta

estensione

delle entità di un particolare tipo è raggruppata in un insieme di entità che è chiamato del tipo di entità. La

figura 4 chiarisce il rapporto tra le quantità definite.

Dato un insieme di entità simili si richiede spesso di poter individuare univocamente una singola entità. Le entità definite

dallo stesso schema si differenziano per i valori assunti dagli attributi per cui la possibilità di poter individuare

vincolo di univocità vincolo di chiave

univocamente un'entità comporta l'introduzione di un o su uno più attributi

dell'entità. Solitamente un tipo di entità ha un attributo i cui valori sono distinti per tutte le entità dello stesso tipo, tale

attributo chiave.

attributo viene detto Ad esempio l'attributo matricola è un attributo chiave sia per il tipo di entità

studente che per il tipo di entità professore. Non sempre le entità possiedono un attributo che le individua univocamente

ma a volte sono necessari più attributi in tal caso l'univocità è data dalla combinazione dei valori di questi attributi. Per

chiave composta.

questo tipo di entità la chiave è definita dalla combinazione di tali attributi e viene detta Con

riferimento all'esempio in esame se modellassimo con delle entità il concetto di votazione per il tipo di entità che le

definisce avremmo una chiave composta definita dagli attributi modulo e studente.

Esistono tipi di entità che possono avere più attributi chiave e/o più chiavi composte, in tal caso assume particolare

chiave minimale

importanza il concetto di ovvero la chiave composta dal numero minimo di attributi (ovviamente vi

potrebbero essere più chiavi minimali). Altri tipi di entità possono non presentare nessuna chiave ovvero non esiste un

attributo od una combinazione di attributi i cui valori siano unici per ciascuna entità.

entità deboli.

In tal caso si fa riferimento alle entità di questo tipo con il termine di

2.2.3 Associazioni, Relazioni e Vincoli

Le associazioni o relazioni modellano i legami tra i tipi di entità. Si ha un'associazione ogni qual volta un tipo di entità si

riferisce ad un altro tipo di entità. Con l'accezione “si riferisce” si intende che un tipo di un'entità presenta un attributo il

cui insieme di valori ammissibili è stabilito dai valori assunti da un attributo del tipo di entità a cui si riferisce.

Ad esempio se consideriamo l'entità modulo questa presenta un attributo insegnamento che fa riferimento all'attributo

codice del tipo di entità insegnamento. Ciò significa che data un'entità modulo il valore assunto dall'attributo

insegnamento deve essere uguale al valore assunto dall'attributo codice per almeno una delle entità di tipo insegnamento.

Allo stesso modo l'attributo docente si riferisce all'attributo matricola del tipo di entità docente.

7 associazioni relazioni:

Nel modello ER il legame tra gli attributi nelle entità vengono modellati o durante la progettazione

concettuale nella fase iniziale di definizione dei tipi di entità le associazioni sono colte come attributi di particolari tipi di

entità; successivamente tali attributi sono convertiti in associazioni tra tipi di entità.

tipo di associazione R

Un tra n tipi di entità E1,E2,...En definisce un insieme di legami – od insieme di associazioni – tra

entità di questi tipi. L'istanza rk di un tipo di associazione può essere espressa nella forma (e1,e2,...,en) dove il generico ei

partecipa

è un'entità appartenente al tipo Ei. Diremo inoltre che ciascun tipo di entità Ei alla relazione R.

Informalmente questo vuol dire che le entità che partecipano alla relazione sono correlate in qualche mondo nello scenario

grado

reale associato alla Base di Dati. Indicheremo con il numero dei tipi di entità che partecipano ad una relazione (se vi

partecipano più volte verranno contati più volte). Normalmente si hanno associazioni binarie o ternarie.

Le associazioni sono come abbiamo già visto realizzate utilizzando gli attributi delle entità, spesso di associano a tali

ruolo

attributi dei nomi di ruolo che individuano appunto il che l'entità (tramite l'attributo coinvolto) ricopre nella

relazione. Come abbiamo precedentemente accennato un tipo di entità può partecipare più volte ad una relazione in tale

caso vi parteciperà utilizzando ruoli diversi. In tal caso il nome del ruolo diventa fondamentale per distinguere il significato

associazioni ricorsive

delle entità dello stesso tipo. In tal caso parleremo di ovvero associazioni in cui entità di un tipo

sono associate ad entità dello stesso tipo.

Vincoli sui Tipi di Associazione

I tipi di associazione hanno generalmente dei vincoli che limitano le possibili combinazioni di entità che possono far parte

del corrispondente insieme di associazioni.

Tali vincoli sono estratti dall'analisi dei legami che intercorrono tra gli oggetti nello scenario associato alla Base di Dati, tali

vincoli normalmente fanno riferimento a regole implicite. Ad esempio nel caso dell'entità studente possiamo definire un

tipo relazione “è iscritto a” che lo associa all'entità corso di laurea: uno studente può essere iscritto ad un solo corso di

laurea. Questo vincolo deve poter essere tradotto e rappresentato nel modello ER.

Possiamo distinguere due tipi di vincoli di associazione:

 rapporto di cardinalità (per associazioni binarie): il rapporto di cardinalità per un'associazione binaria

specifica il numero massimo di istanze di associazione a cui può partecipare un'entità. Nel rappresentare il

rapporto di cardinalità si utilizza il formalismo A:B che può assumere i seguenti valori 1:1, 1:N (uno a molti), N:1

(molti a uno), N:M (molti a molti). La relazione “afferenza” definita tra l'entità docente e l'entità dipartimento è ad

esempio una relazione N:1 in quanto più docenti possono avere uno stesso dipartimento di afferenza, ma per ogni

docente vi è un solo dipartimento di afferenza. La relazione “insegna” tra i tipi di entità docente ed insegnamento

(corso) è invece una relazione M:N in quanto più docenti possono insegnare lo stesso corso e viceversa un docente

può insegnare corsi diversi ;

7

 partecipazione: il vincolo di partecipazione specifica se l'esistenza di un'entità dipende dal suo essere correlata a

un'altra entità attraverso un tipo di associazione. Questo vincolo specifica il numero minimo di istanze di

totale parziale.

associazione a cui ogni entità può partecipare. Vi sono due tipi di vincoli di partecipazione: e Nel

caso di vincoli di partecipazione totale ogni entità di un tipo di entità che partecipa ad tipo di relazione deve

partecipare almeno ad una relazione di quel tipo, ciò non è vero se il vincolo di partecipazione è parziale. Ad

esempio la relazione “è iscritto a” tra studente e corso di laurea è soggetta ad un vincolo di partecipazione totale

in quanto non è possibile nello scenario di riferimento avere uno studente che non sia iscritto ad un corso di

laurea. Se invece definissimo la relazione “sostiene” tra studente ed esame questa sarebbe soggetta ad un vincolo

di partecipazione parziale in quanto esiste uno stato nello scenario di riferimento in cui uno studente non ha mai

sostenuto un esame (pensate ad esempio agli studenti iscritti al primo anno). vincoli strutturali

Il rapporto di cardinalità ed il vincolo di partecipazione vengono definiti in generale di un tipo di

associazione.

2.2.4 Diagrammi Entità – Relazione diagrammi entità –

I modelli ER sono normalmente rappresentati utilizzando dei diagrammi che prendono il nome di

relazione diagrammi ER.

o semplicemente I diagrammi ER forniscono una rappresentazione grafica delle entità e delle

relazioni che intercorrono nel dominio in esame. Un diagramma ER stabilisce delle convenzioni grafiche per rappresentare

i diversi elementi di un modello ER. Un classico diagramma ER si presenta come una rete di elementi in cui i tipi di entità

rappresentate con rettangoli sono connesse tra di loro attraverso tipi di associazioni rappresentate tramite rombi. I

diagrammi ER stabiliscono per ogni differente elemento del modello entità relazione una precisa rappresentazione grafica e

la figure 5 ed 6 descrivono il significato di ogni elemento grafico utilizzato.

Ogni elemento grafico presente nel diagramma ER è etichettato con un nome che lo individua nel contesto in cui è inserito,

tale nome è identico al nome che si da al corrispondente elemento nel modello ER.

7 In tal caso la parola corso è riferita all'entità insegnamento e non all'entità modulo dell'esempio presentato. Un modulo presenta infatti un unico docente.

8

Figura 5: Simboli utilizzati per rappresentare entità, attributi ed Associazioni

In aggiunta a queste regole che sono valide per ogni diagramma ER si possono stabilire delle ulteriori convenzioni come ad

esempio le convenzioni dei nomi. Queste sono normalmente stabilite dai progettisti del modello ER. È buona norma

utilizzare uno stesso stile per gli stessi oggetti nell'ambito di queste dispense utilizzeremo le seguenti convenzioni: i nomi

dei tipi di entità saranno espressi da nomi propri al singolare mentre per descrivere le associazioni utilizzeremo dei verbi.

Figura 6: Descrizione delle molteplicità con cui le entità partecipano ad un'associazione

La figura 17 descrive il diagramma ER associato all'esempio presentato nel precedente capitolo. Sulla base di questo

esempio costruiremo il modello relazionale che ci permetterà di creare fisicamente la Base di Dati utilizzando un DBMS od

applicativi per la gestione di Basi di Dati ad uso personale.

2.3 Il Modello Relazionale

Il modello relazionale è stato introdotto nel 1970 da Ted Codd. Questo modello si è subito diffuso per la sua semplicità e le

sue basi matematiche. Il modello usa il concetto di relazione matematica – spesso assimilata ad una tabella di valori –

come suo componente elementare e ha il suo fondamento teorico nella teoria degli insiemi e nella logica dei predicati del

primo ordine.

Le prime implementazioni commerciali del modello relazionale furono disponibili all'inizio degli anni ottanta. Attualmente i

maggiori prodotti commerciali per la realizzazione ed il mantenimento delle Basi di Dati utilizzano come base il modello

relazionale. Tale modello viene poi introdotto in uno schema interno proprio del DBMS e che normalmente non è noto

all'utente della Base di Dati. Il modello relazionale insieme al linguaggio SQL costituiscono i due strumenti principali per

fornire un'interfaccia semplice ed efficace agli utenti delle Basi di Dati: il modello relazionale è il modello concettuale con

cui l'utente “ragiona” per interagire con la Base di Dati, mentre SQL è il linguaggio che utilizza per modificarla od

conoscerne lo stato.

Figura 7: Modello ER (semplificato) che descrive la Facoltà Universitaria

In questo capitolo introdurremo gli elementi di base del modello relazionale e mostreremo come sia possibile tradurre un

modello ER in un modello relazionale. Il modello relazionale è ancora un modello concettuale sebbene fornisca delle

astrazioni molto più adatte ad essere direttamente tradotte in un modello logico che è quello che viene utilizzato da un

DBMS per implementare la Base di Dati. Il DBMS fornisce infatti un'interfaccia per definire un modello logico e si occupa

poi di costruire lo schema interno ed implementare la Base di Dati. È prassi comune specificare il modello logico

9

utilizzando il linguaggio SQL che di fatto costituisce ormai uno standard per la definizione e l'interazione con le Basi di

Dati. Il legame tra il linguaggio SQL ed il modello relazionale è molto stretto in quanto avere a disposizione un'interfaccia

basata SQL di fatto presuppone quasi sempre rappresentare una Base di Dati basandosi sul modello relazionale. Vedremo

nel prossimo capitolo quali siano le corrispondenze tra il modello relazionale e le strutture fornite dal linguaggio SQL.

2.3.1 Concetti di Base

Il modello relazionale rappresenta la Base di Dati come una collezione di relazioni. Informalmente la relazione è

tabella

considerata come una di valori; in tal caso ogni riga della tabella rappresenta una collezione di valori di dati

collegati. Il nome della tabella ed i nomi delle colonne aiutano ad interpretare il significato dei valori presenti in ogni riga.

Facendo riferimento all'esempio trattato potremmo modellare uno studente con una relazione ed in tal caso l'insieme delle

informazioni che abbiamo scelto per caratterizzare uno studente può essere organizzato in una tabella come mostrato in

figura 7. In tal caso con studente ci si riferisce al nome della relazione, i nomi delle colonne individuano gli attributi della

relazione studente e le righe della tabella sono istanze della relazione che correlano gli attributi che definiscono uno

specifico studente.

Parimenti si può procedere per gli altri oggetti del dominio. Il modello relazionale si basa sui concetti di dominio, relazione

ed attributo. Vediamo ora più nel dettaglio cosa rappresentano tali concetti:

 dominio: un dominio D è un insieme di valori atomici. Con il termine atomico si intende che ogni valore del

dominio non è ulteriormente scomponibile in altri valori più semplici almeno per quanto concerne il modello

relazionale . Un dominio può essere specificato indicando il tipo dei dati da cui sono tratti i valori dei dati che

8

formano il dominio. Ad esempio per quanto riguarda la relazione studente la proprietà matricola ha un dominio

che è rappresentato dall'insieme dei numeri di 7 cifre che sono considerate delle matricole valide. Ad un dominio

viene inoltre attribuito un nome che aiuta ad definire il significato dei suoi valori. Un dominio può inoltre essere

definito fornendo una specifica più precisa, ovvero definendo il formato del tipo di dato. Nel caso della relazione

studente una specifica di formato per la proprietà corso di laurea è “stringa alfanumerica con due caratteri

alfabetici seguiti da due numeri”. Concludendo possiamo dire che gli elementi che caratterizzano un dominio

sono il nome, il tipo di dato ed il formato del tipo di dato;

 schema di relazione attributi: schema di relazione R(A1,...,An)

ed uno è costituito da un nome di relazione R

attributo

e da un elenco di attributi A1,...,An. Ogni Ai fornisce il nome del ruolo interpretato da un certo dominio

D nello schema di relazione R. D è il dominio dell'attributo Ai ed è spesso indicato con la forma dom(Ai). Uno

grado

schema di relazione descrive una relazione: oltre al nome per una relazione è importante il suo od parità

che individua il numero degli attributi presenti nello schema di relazione. Per l'entità STUDENTE possiamo

definire lo schema di relazione seguente: STUDENTE(Matricola, Nome, Cognome, Anno, CodiceCorsoDiLaurea). È

possibile specificare per ogni attributo anche il tipo facendo seguire l'attributo dai due punti e dal nome del

dominio (ad es.: Matricola: MatricoleValide). Come nel caso nel modello ER – e come mostrato nella relazione

studente – vi possono essere attributi che hanno lo stesso dominio. In tal caso tali attributi assumeranno un

diverso ruolo nella relazione (vedi Nome e Cognome);

 relazione istanza di relazione:

od una relazione r di uno schema di relazione R(A1,...,An) è un'insieme di n-tuple

n-tupla

r = {t1,t2,....tm}. Ogni è un elenco ordinato di n valori t = <v1,...,vn> dove ogni valore vi è un elemento di

null.

dom(Ai) oppure è uno speciale valore Il valore vi è spesso indicato con t[Ai]. Comunemente si utilizza la

intensione estensione

coppia di termini ed di relazione per indicare rispettivamente i relazione e schema di

.

relazione

Figura 8: Interpretazione secondo il modello relazionale del concetto di studente

La figura 8 mostra nel dettaglio la relazione studente evidenziando graficamente quali sono gli elementi che la definiscono

secondo il modello relazionale.

Interpretazione Matematica

Il modello relazionale si è potuto diffondere non solo per la semplicità con cui si può modellare il mondo reale ma anche

per la solida base matematica su cui è fondato che permette di evincere delle proprietà e soprattutto definire un insieme di

operazioni applicabili al modello. La possibilità di definire delle operazioni è quella che di fatto rende il modello relazionale

un modello più adatto da cui partire per realizzare effettivamente una Base di Dati. L'insieme delle operazioni definite sul

algebra relazionale

modello relazionale prende il nome di e verrà illustrata brevemente nel seguito di questo capitolo .

9

8 Come nel caso degli attributi semplici e composti per il modello ER anche in questo caso la scelta dell'atomicità è spesso data dal livello di dettaglio con cui si vogliono

.

caratterizzare gli oggetti dello scenario reale che si vuole rappresentare 10

La definizione di relazione precedentemente data può essere riformulata fornendo un'interpretazione matematica: Una

relazione matematica

relazione (o stato di relazione) r(R) è una sui domini dom(A1), dom(A2), ... dom(An), cioè è un

sottoinsieme del prodotto cartesiano dei domini che definiscono R: r(R) (dom(A1) x dom(A2) x ... x dom(An)).

Il prodotto cartesiano specifica tutte le possibili combinazioni dei valori dei domini indicati dallo schema di relazione. Una

relazione è una sequenza di tuple ognuna delle quali specifica una determinata combinazione di valori che sono quelli

caratterizzano le entità che appartengono alla relazione. Per tal motivo la relazione individua un sottoinsieme del prodotto

stato corrente della relazione

cartesiano. Lo individua tutte quelle combinazioni del prodotto cartesiano che in un dato

istante appartengono alla relazione.

2.3.2 Caratteristiche delle Relazioni

La definizione matematica di relazione precedentemente data utilizza il concetto di tupla e di insieme. Dal punto di vista

matematico un insieme non presenta un ordinamento, per tal motivo le tuple che identificano una relazione non

presentano un ordinamento prestabilito. In realtà poiché a queste tuple saranno associati dei record memorizzati su un

disco è possibile prevedere un ordinamento sulla base del valore di un qualche

attributo. Ad esempio nel caso della relazione studente potremmo utilizzare l'attributo matricola come criterio di

ordinamento. L'ordinamento di una relazione non fa parte della sua definizione: il modello relazionale infatti attraverso la

definizione di relazioni

tenta di rappresentare i fatti a livello logico.

Quello che invece è implicito nella definizione della relazione è l'ordinamento degli attributi che sono definiti nello schema

di relazione. L'essenza di un attributo viene colta principalmente utilizzando una specifica posizionale, ovvero si specifica

la posizione dell'attributo nello schema per conoscerne il valore in una tupla. Alternativamente è possibile utilizzare un

nome per individuare il valore di un attributo: questo è anche il metodo maggiormente usato anche se, formalmente,

risulta essere superfluo essendo la posizione sufficiente.

Le tuple di una relazione presentano dei valori per gli attributi che sono definiti nello schema di relazione. Tali attributi o

sono valori atomici o sono nulli. Gli attributi multivalore o gli attributi composti definiti per il modello ER non risultano

quindi essere direttamente rappresentabili: gli attributi multivalore verranno modellati con ulteriori relazioni mentre quelli

composti verranno esplosi nelle loro componenti atomiche. Per tal motivo il modello relazionale viene anche chiamato

modello relazionale piatto (flat relational model) in quanto non permette la presenza di strutture annidate .

10

Il modello relazionale a differenza del modello ER non presenta strutture differenti per rappresentare gli oggetti ed i legami

che intercorrono tra loro, ma utilizza sempre l'astrazione di relazione. Uno schema di relazione indica genericamente un

tipo di asserzione

tipo di fatto o quindi il modello relazionale rappresenta uniformemente, attraverso relazioni, fatti su

entità ed associazioni. Per tal motivo le relazioni possono assumere significati differenti ed è importante comprendere quali

relazioni rappresentano delle entità e quali delle associazioni.

2.3.3 Vincoli del Modello Relazionale e Schemi di Basi di Dati Relazionali

Una Base di Dati viene modellato utilizzando un insieme di relazioni. Tali relazioni non sono indipendenti tra di loro ma vi

saranno diverse relazioni, e quindi le tuple in esse contenute, che saranno in qualche modo collegate. I legami tra le

vincoli

relazioni sono esplicitati introducendo nel modello che si costruisce dei sui valori effettivi che caratterizzano uno

stato della Base di Dati . Ci sono diversi tipi di vincoli che possono essere modellati:

11

 vincoli intrinseci basati sul modello: questi sono vincoli che derivano naturalmente del modello dei dati. A

questa categoria appartengono le caratteristiche delle relazioni descritte nel precedente paragrafo: il fatto che una

relazione non contenga dei duplicati è un vincolo intrinseco del modello relazionale;

 vincoli basati sullo schema: questi sono vincoli che possono essere direttamente espressi sugli schemi del

modello dei dati e sono normalmente specificati nel linguaggio di descrizione dei dati (DDL – Data Definition

Language);

 vincoli basati sull'applicazione: questi sono vincoli che non possono essere direttamente specificati nello

schema del modello dei dati e per cui sono codificati all'interno dei programmi applicativi che interagiscono con la

base di dati. Questi sono vincoli di carattere più generale.

In questo paragrafo ci occuperemo dei vincoli basati sullo schema che possono ulteriormente essere suddivisi in vincoli di

dominio, vincoli di chiave, vincoli sui valori nulli, vincoli di integrità delle entità e vincoli di integrità referenziale. Esiste

infine un'altra categoria di vincoli che è quella delle dipendenze dei dati che comprende le dipendenze funzionali e le

dipendenze multivalore: questi vincoli vengono utilizzati per valutare la qualità della progettazione di una Base di Dati ed

utilizzati in un processo che si chiama normalizzazione che non tratteremo in queste dispense.

Vincoli di Dominio

vincoli di dominio

I stabiliscono che all'interno di ciascuna tupla il valore di ogni attributo A deve essere un valore

atomico del dominio dom(A). In precedenza abbiamo già descritto come sia possibile definire l'insieme dei valori validi per

un determinato attributo. I vincoli di dominio stabiliscono semplicemente che i valori assunti dagli attributi devono essere

coerenti con la specifica definita per il dominio a cui appartengono. Stabilire che l'attributo CorsoDiLaurea della relazione

STUDENTE debba essere composto da quattro caratteri in cui i primi due sono alfabetici mentre i successivi sono

numerici è un vincolo di dominio.

I tipi di dato ammissibili comprendono di solito i tipi di dati numerici standard per i numeri interi (short-integer, integer,

long-integer) e numeri reali (float, doubleprecision).

9 Vedremo poi nel dettaglio come le operazioni definite dall'algebra relazionale sia tradotta naturalmente in alcune operazioni definite dal linguaggio SQL. Il modello relazionale e

l'algebra ad esso associato costituiscono un sistema completo per la rappresentazione della Base di Dati non solo definiscono infatti le strutture per rappresentare una Base di Dati

ma anche le operazioni che si possono fare su di essa. Tali specifiche permettono una traduzione quasi automatica, tramite il linguaggio SQL, in una specifica operativa

della Base di Dati. Ciò invece non accade se si utilizza come punto di partenza il modello ER: questo infatti fornisce un modello concettuale meno vicino all'implementazione e

soprattutto non definisce operazioni su di esso.

10 Questo è un ulteriore esempio di come il modello relazionale sia un modello più orientato all'implementazione di una Base di Dati in quanto predilige l'utilizzo di strutture semplici

direttamente implementabili.

11 Lo stato di una Base di Dati è costituito dagli stati di tutte le relazioni in essa contenute.

11

Sono inoltre disponibili: caratteri, valori booleani, stringhe di lunghezza fissa e variabile. Si possono definire tipi come

sottoinsieme dei tipi elementari (ad esempio un tipo numerico che può assumere valori che vanno da 1 a 10) oppure

introducendo delle condizioni aggiuntive come visto per l'attributo CorsoDiLaurea.

Vincoli di Chiave e sui Valori Nulli

Le relazioni sono definiti come un insieme di tuple che hanno lo stesso schema di relazione. Come già sappiamo il modello

relazionale non permette che in una relazione vi siano dei duplicati, per tal motivo se consideriamo una tupla valutando

tutti i suoi attributi siamo sempre in grado identificarla in quanto la combinazione dei valori dei suoi attributi è unica.

Molto spesso però, data una relazione, è possibile individuare un sottoinsieme degli attributi della tupla per cui la

superchiave (SK –

combinazione dei valori è unica ed identifica univocamente la tupla tale sottoinsieme viene detto

superkey) dello schema di relazione. Vi possono essere più combinazioni di attributi che presentano questa proprietà e

quindi in genere vi possono essere più superchiavi.

Nel caso peggiore la superchiave coincide con la combinazione di tutti gli attributi della tupla. Una superchiave SK

vincolo di univocità vincolo di chiave

definisce un o secondo il quale nessuna coppia di tuple distinte in uno stato r

della relazione R può avere lo stesso valore per SK.

Una superchiave può avere attributi ridondanti per cui risulta essere più utile il concetto di chiave che non presenta

chiave (K – key)

ridondanze. Una di uno schema di relazione R è una superchiave di R con la proprietà aggiuntiva che la

rimozione di qualsiasi attributo da K non la rende più una superchiave. Una superchiave soddisfa perciò i seguenti vincoli:

 due tuple distinte di un qualsiasi stato della relazione non possono avere valori uguali per tutti gli attributi della

chiave;

 è una superchiave minimale cioè una superchiave da cui non è possibile rimuovere alcun attributo mantenendo il

vincolo di univocità. chiave candidata.

In generale uno schema di relazione può avere più di una chiave. In questo caso una chiave è detta

chiave primaria.

Risulta comune indicare tra le chiavi candidate una chiave preferita che viene definita Normalmente si

sceglie la chiave candidata con il minimo numero di attributi. Nel caso della relazione STUDENTE l'attributo Matricola è

una chiave primaria.

Un altro vincolo sugli attributi specifica se un attributo può assumere valore nullo.

vincoli sui valori non nulli.

Questo tipo di vincolo viene definito

Vincoli di Integrità d'Entità e Referenziale

I vincoli che abbiamo definito si riferiscono alle singole relazioni. In realtà una Base di Dati è un insieme di relazioni e le

tuple in esse contenute sono collegate in modi diversi. Vi sono vincoli che trascendono le singole relazioni, in tal caso

schema di

occorre definire i concetti di uno stato di Base di Dati relazionale e schema di Base di Dati relazionale. Uno

Base di Dati relazionale S è costituito da un'insieme di schemi di

vincoli di integrità stato o istanza di una

relazione S = { R1,.....,RN} e da un'insieme di (IC – Integrity Constraint). Uno

Base di Dati relazionale è costituito da un'insieme di stati di relazione tali che ogni stato di relazione sia consistente e che

soddisfino i vincoli definiti in IC. Nel considerare una Base di Dati di tipo relazionale ci interesserà valutare sia lo schema

stato non valido,

che lo stato. Uno stato che non soddisfa i vincoli definiti in IC viene detto mentre uno che verifica i

stato valido.

vincoli viene detto

Il modello relazionale definisce due tipologie di vincoli di integrità:

 vincolo di integrità sull'entità: tale vincolo stabilisce che nessun valore di chiave primaria può essere nullo.

Questo è un vincolo ragionevole in quanto la chiave primaria è utilizzata per identificare le tuple: se più tuple

hanno un valore nullo per le chiavi non è più possibile garantire che queste siano distinguibili. Il vincolo di

univocità è infatti garantito sugli attributi che compongono la chiave, per gli altri attributi non vi è alcun

controllo. Per tal motivo se due tuple hanno per gli attributi non chiave valori identici con una chiave una di

queste tuple andrebbe persa;

 vincolo di integrità referenziale: il vincolo di integrità referenziale è specificato per mantenere la consistenza tra

tuple di due relazioni.

Informalmente il vincolo stabilisce che una tupla in una relazione che fa riferimento a un'altra relazione deve far

riferimento ad una tupla esistente in quella relazione. Il vincolo di integrità referenziale si basa sul concetto di chiave

esterna. Le condizioni che definiremo per la chiave esterna modellano di fatto il vincolo di integrità referenziale tra due

chiave esterna

schemi di relazione R1 ed R2. Un insieme di attributi FK (Foreign Key) nello schema relazionale R1 è una

di R1 che riferisce la relazione R2 se soddisfa le seguenti proprietà:

 gli attributi presenti in FK hanno gli stessi domini degli attributi di chiave primaria PK (Primary Key) di R2. Si

dice che gli attributi FK riferiscono o fanno riferimento alla relazione R2;

 un valore FK in una tupla t1 dello stato corrente di R1 o è presente come valore di PK di una qualche tupla t2

dello stato corrente di R2 oppure è nullo.

relazione referenziante relazione riferita.

In questa definizione, R1 è detta ed R2 Se le proprietà sopra definite sono

verificate allora tra R1 ed R2 sussiste un vincolo di integrità referenziale. Osserviamo che R1 ed R2 possono rappresentare

lo stesso schema di relazione in tal caso gli attributi FK riferiranno una tupla sulla stessa relazione.

Osserviamo che i vincoli di integrità referenziale normalmente nascono per modellare delle associazioni tra entità: se

consideriamo le relazioni MODULO, CORSO e PROFESSORE possiamo individuare ben 2 vincoli di integrità referenziale in

cui la relazione MODULO gioca sempre il ruolo di relazione referenziante. Un primo vincolo di integrità referenziale

sussiste tra CORSO e MODULO e modella il legame in base al quale un modulo ha associato sempre un insegnamento: per

tale vincolo l'attributo Insegnamento è FK e referenzia la PK Codice di Corso. Un secondo vincolo sussiste tra

PROFESSORE e MODULO e rappresenta l'associazione “un docente insegna un modulo”: in questo caso l'attributo

Docente di modulo è la chiave esterna e referenzia la chiave primaria di PROFESSORE Matricola.

E' possibile rappresentare le relazioni ed i vincoli di integrità referenziale utilizzando in modo grafico utilizzando degli archi

orientati che collegano gli attributi della chiave esterna nella relazione referenziante con gli attributi della chiave primaria

nella relazione referenziata. I senso dell'arco segue del riferimento la punta della freccia indica la colonna che viene riferita.

La figura 9 mostra le relazioni e dei vincoli di integrità che sussistono nell'esempio trattato in queste dispense, in

particolare sono evidenziati i vincoli di integrità referenziale prima discussi.

12

Figura 9: Relazioni presenti nell'esempio e esplicitazione dei vincoli d'integrità

2.3.4 Operazioni

Il modello relazionale definisce una serie di operazioni che possono essere effettuate su di una Base di Dati relazionale.

Queste possono essere classificate in operazioni di recupero (retrieval) ed operazioni di aggiornamento (update). Le

operazioni di recupero sono quelle che permettono di effettuare le interrogazioni su una Base di Dati relazionale e si

basano sull'algebra relazionale. Le interrogazioni sono definite utilizzando delle espressioni dell'algebra relazionale. Le

espressioni definiscono una relazione nei termini di trasformazioni di altre relazioni: l'interrogazione viene formulata

specificando i dati di interesse; l'effetto è la creazione di una nuova relazione ottenuta applicando operazioni relazionali per

operazioni relazionali di aggiornamento

recuperare i dati. In questo paragrafo tratteremo le mentre le operazioni

relazionali di

recupero verranno descritte nel prossimo paragrafo.

Esistono tre operazioni di aggiornamento: l'inserimento, la modifica, la cancellazione:

 l'inserimento: fornisce un elenco di valori di attributi per una nuova tupla t che deve essere inserita in una

relazione R. L'inserimento può violare tutti i tipi di vincoli definiti precedentemente: i vincoli di dominio possono

essere violati se viene fornito un valore per un attributo che non rispetta la specifica di tipo richiesta; i vincoli di

chiave possono essere violati se viene fornita per gli attributi chiave una combinazione che identifica una tupla

già esistente; i vincoli di integrità di entità possono essere violati se vengono forniti valori nulli per gli attributi

della chiave; i vincoli di integrità referenziale possono essere violati se per attributi che sono chiavi esterna

vengono forniti valori che non riferiscono alcuna tupla. Le operazioni di inserimento che violano i vincoli sono

invalidate e non accettate dalla Base di Dati;

 cancellazione:

la elimina una o più tuple da una relazione R. La cancellazione può violare il vincolo di integrità

referenziale: se le tuple cancellate erano riferite in altre relazioni la relazione referente possiede delle tuple che

presentano chiavi esterne non valide. Di fronte alla violazione di questo tipo di vincolo ci si può comportare in

modi differenti: si può rifiutare la cancellazione evidenziando le tuple dipendenti, si può propagare l'effetto della

cancellazione. In questo secondo caso vi sono due possibilità: propagare la cancellazione alle tuple referenziano la

tuple cancellate oppure impostare gli attributi che compongono la chiave esterna a null per le tuple che

referenziano quella cancellata. Questa seconda opzione non è applicabile se alcuni degli attributi che definiscono

la chiave esterna costituiscono parte (od addirittura tutta) della chiave primaria. La scelta sul comportamento da

intraprendere nel caso di violazione del vincolo di integrità referenziale normalmente è lasciata a chi definisce il

modello relazionale che specificherà nel vincolo l'azione da intraprendere;

 modifica:

la è utilizzata per cambiare i valori di uno o più attributi di tuple presenti in una qualche relazione R.

La modifica come l'inserimento può violare tutti i vincoli definiti precedentemente, inoltre come la cancellazione

può violare il vincolo di integrità referenziale con modificando una chiave primaria referenziata da altre tuple. La

modifica in questo caso non elimina delle tuple ma le tuple che referenziavano quella modificata dopo la modifica

presentano un valore della chiave esterna non esistente. Anche in questo caso viene lasciata scegliere a chi

modella il vincolo di integrità quale azione intraprendere per mantenere la Base di Dati in uno stato consistente

dopo la modifica. Normalmente la modifica di attributi che non sono ne chiavi primarie ne chiavi esterne non

comportano problemi se sono rispettati i vincoli di dominio.

Le operazioni sono strutture che non sono presenti nel modello ER e che sono direttamente tradotti in strutture del

linguaggio SQL come vedremo in seguito.

2.3.5 Algebra Relazionale relazionale

L'algebra relazionale come il calcolo relazionale è un linguaggio formale per il modello relazionale. L'algebra

costituisce l'insieme principale di operazioni per i modello relazionale. Nel precedente paragrafo è stata fornita una

13

descrizione informale di alcune operazioni che si possono fare sul modello relazionale, l'algebra relazionale permette di

fornire una descrizione più rigorosa e più precisa di tali operazioni. L'algebra

relazionale è molto importante non solo perché fornisce un fondamento formale per il modello relazionale ma anche perché

è utilizzata come base per implementare ed ottimizzare le interrogazioni nei sistemi di Basi di Dati relazionali (RDBMS –

Relational Database Management System). espressioni dell'algebra relazionale

L'algebra relazionale utilizza delle espressioni dette per definire le operazioni sul

modello relazionale. Proprietà comune delle espressioni dell'algebra relazionale è che queste trasformano delle relazioni:

hanno come argomenti delle relazioni ed restituiscono come risultato una relazione .

12

L'algebra relazionale definisce diverse tipologie di operazioni base con cui comporre le espressioni. Queste possono essere

classificate come segue:

 operazioni relazionali unarie;

 operazioni insiemistiche;

 operazioni relazionali binarie;

 altre operazioni.

Illustreremo brevemente in seguito le principali operazioni di ogni gruppo.

Operazioni Relazionali Unarie

La operazioni relazionali unarie sono quelle maggiormente utilizzate nelle interrogazioni.

Questo possono operano su una sola relazione e possono essere pensate come delle funzioni che trasformano una

relazione in un'altra. Le operazioni relazioni unarie sono tre:

 selezione:

. operazione di l'operatore di selezione seleziona un determinato sottoinsieme di tuple di una relazione

condizione di selezione.

in base ad una La condizione di selezione esprime normalmente dei vincoli sugli

attributi della relazione e, nella loro forma semplice , hanno una delle seguenti due forme:

13

<nome attributo> <operatore di confronto> <valore costante>

<nome attributo j> <operatore di confronto> <nome attributo k>

Se utilizziamo l'analogia della tabella per rappresentare una relazione, l'operatore di selezione opera una partizione

orizzontale della tabella ovvero seleziona solo quelle righe che soddisfano la condizione di selezione. L'operatore di

selezione>(R).

selezione assume la seguente forma: σ<condizione Ad esempio considerando la relazione STUDENTE

potremmo specificare l'interrogazione che seleziona tutti gli studenti che si chiamano Maria nel modo seguente:

σNome=Maria(STUDENTE). Poiché l'operazione di selezione non altera la struttura della relazione come risultato

avremo una relazione che è un sottoinsieme della relazione studenti composta da quelle sole istanze per cui l'attributo

Nome assume il valore Maria;

 proiezione:

operazione di l'operazione di proiezione proietta una relazione su un sottoinsieme degli attributi che

ne definiscono lo schema. Continuando l'analogia con la tabella possiamo dire che l'operatore di proiezione

seleziona solo alcune colonne della tabella e quindi effettua una partizione verticale della relazione. L'operazione

di proiezione è definita dalla lettera p seguita dalla lista degli attributi da includere nella proiezione e dal nome

attributi>(R).

della relazione su cui deve essere applicata:π<lista L'operazione di proiezione è operazione che

trasforma la struttura della relazione in quanto permette di modificare il numero e l'ordine degli attributi che

devono comporre la relazione risultato . Se si volessero selezionare solo il nome ed il cognome degli studenti

14 Nome ,

potremmo specificare tale interrogazione utilizzando l'operatore di selezione nel modo seguente: π

Cognome(STUDENTE);

 ridenominazione:

operazione di l'operatore di ridenominazione permette di rinominare il nome di una relazione

e/o di alcuni degli attributi che la definiscono. L'operazione di ridenominazione lascia la relazione

sostanzialmente invariata ma sostanzialmente cambia il nome della tabella e/o di alcune delle colonne di cui è

composta. L'operazione di ridenominazione è definita dalla lettera . seguita dalla lista degli oggetti da

ridenominare e dal nome della relazione tra parentesi. La forma è la seguente: ρS(B1,....Bm)(R) oppure

ρ(B1,....Bm)(R). Nel primo caso viene rinominata anche la relazione che si chiamerà S. In entrambi i casi

B1,...,Bm è la lista dei nuovi nomi degli attributi. La corrispondenza tra i nomi originali e quelli nuovi è basata

sulla posizione di questi nella schema della relazione .

15

Le operazioni relazionali unarie possono facilmente essere composte per realizzare interrogazioni sofisticate. La possibilità

di comporre tali operazioni in un'espressione algebrica complessa è data dal fatto che tali funzioni hanno come argomento

e risultato sempre una relazione. La composizione delle operazioni relazionali unarie segue gli stessi criteri che si

applicano alle funzioni composte nel campo dell'analisi matematica.

In riferimento all'esempio in esame potremmo specificare un'interrogazione che restituisce tutti e soli i nomi ed i cognomi

degli studenti che sono iscritti al corso di laurea identificato dal codice CD34 rinominando la relazione StudentiCD34.

L'espressione relazionale che esprime quanto sopra è la seguente:

StudentiCD34(Nome,Cognome)( (σCorsoDiLaurea=CD34(STUDENTE)))

ρ πNome,Cognome

In riferimento alla relazione descritta in figura 8 possiamo applicare l'espressione relazionale sopra descritta ed il risultato

è mostrato in figura 10. La relazione STUDENTE presenta solo due tuple che hanno l'attributo CD34, l'operazione di

selezione restituisce una relazione con queste due tuple, successivamente l'operazione di proiezione restituisce una

relazione con i soli attributi Nome e Cognome. Infine l'operazione di

ridenominazione rinomina la tabella in StudentiCD34.

12 Questa è una proprietà molto importante in quanto, come vedremo nel prossimo capitolo, l'operatore SELECT definito nel linguaggio SQL presenta la stessa proprietà. Questa

particolare caratteristica permette di avere un modello semplice in grado di rappresentare operazioni anche complesse. Anche in questo caso è possibile notare come vi sia una

corrispondenza diretta tra alcuni concetti del modello relazionale e le strutture fornite dal linguaggio SQL

13 Utilizzando gli operatori della logica booleana (AND,OR,NOT) le condizioni di selezione in forma semplice possono essere composte per formare condizioni di selezione più

articolate.

14 L'operazione di proiezione è anche un'operazione che causa una perdita di informazioni, non solo perché riduce il numero degli attributi – cosa per altro voluta – ma anche

perché qualora non sia presente un attributo chiave nella relazione risultato le eventuali righe duplicate sono eliminate tenendone una sola copia. Questo non è vero invece per

l'operatore SELECT che mantiene le righe duplicate.

15 La corrispondenza tra i nomi degli attributi originali e quelli nuovi avviene utilizzando la posizione dell'attributo. Dallo schema della relazione si conosce la posizione di ogni

attributo all'interno della relazione e l'operatore di ridenominazione basandosi su questa sequenza ordinata sostituirà al nome del primo attributo il primo nome specificato tra le

parentesi e cosi via. 14

Figura 10: Risultato dell'operazione di proiezione

Operazioni Insiemistiche

Le operazioni insiemistiche sono costituite dalle usuali operazioni matematiche sugli insiemi ovvero l'unione, l'intersezione

e la differenza: Tali operazioni si applicano a due o più relazioni che presentano lo stesso schema di relazione o schemi di

relazione compatibili. In particolare tali relazioni devono avere lo stesso tipo di tuple, diremo in tal caso che le relazioni

compatibili all'unione.

sono Vediamo più nel dettaglio come si comportano queste operazioni:

 l'unione: genera una relazione le cui tuple sono costituite dall'unione delle tuple presenti nelle due relazioni (R υ

S). Le tuple duplicate sono eliminate;

 l'intersezione: genera una relazione le cui tuple sono presenti in entrambe le relazioni (R Π S);

 differenza:

la il risultato indicato come R – S è una relazione le cui tuple sono presenti in R ma non in S.

Le operazioni unione e differenza sono commutative mentre l'operazione differenza non è commutativa. prodotto

A differenza delle operazioni precedenti che possono essere effettuate tra relazioni compatibili all'unione il

cartesiano è un'operazione che può essere effettuata su qualunque coppia di relazioni. Il prodotto cartesiano – noto anche

prodotto incrociato (cross product) join incrociato (cross join)

come o – è un'operazione insiemistica binaria utilizzata

per unire tuple prese da due relazioni in modo combinatorio. Il prodotto cartesiano produce tuple con tutti gli attributi

propri delle due relazioni.

La figura 11 mostra il risultato del prodotto cartesiano tra le relazioni INSEGNAMENTO e VOTAZIONE. L'applicazione del

prodotto cartesiano in tal caso ha dato una relazione priva di senso. Questo è quello che normalmente accade con il

prodotto cartesiano: ogni tupla di una relazione viene combinata con le tuple dell'altra relazione giustapponendo gli

attributi delle due relazioni. Nel caso presentato non vi alcun legame diretto tra le due relazioni per cui tutte le tuple che

sono ottenute come risultato sono prive di senso, se invece effettuiamo il prodotto cartesiano tra le relazioni STUDENTE e

VOTAZIONE otteniamo una relazione che presenta alcune tuple che sono significative, in particolare quelle che presentano

l'attributo Matricola di STUDENTE identico all'attributo Studente di VOTAZIONI, applicando perciò l'operazione di

selezione imponendo l'uguaglianza tra questi due attributi si ottiene in tal caso il sottoinsieme di tuple significative. In

questo caso le tuple selezionate indicano costruiscono una relazione che associa i dati anagrafici

dello studente ai voti che ha ottenuto sostenendo gli esami associati ai moduli. Il risultato può essere visualizzato in figura

12. Figura 11:

Prodotto

cartesiano tra le

relazioni

INSEGNAMENTO

e VOTAZIONE

In generale il prodotto

cartesiano produce

una relazione priva di

senso se si

giustappongono

tabelle scorrelate, nel

caso si effettui il

prodotto cartesiano

tra tabelle correlate

(esplicitamente tramite un vincolo di integrità referenziale od implicitamente) si genera invece una relazione che, previa

un'opportuna operazione di selezione, può contenere informazioni significative.

Operazioni Relazionali Binarie

Come visto in precedenza il prodotto cartesiano se non controllato da un'operazione di selezione produce generalmente

una relazione con alcune delle tuple non significative. Il modello relazionale fornisce uno strumento più efficace per unire

join.

le tuple logicamente correlate questa è l'operazione di Di fatto l'operazione di join può essere espressa come la

composizione dell'operazione prodotto cartesiano e l'operazione di selezione.

L'operazione di join richiede una condizione di join che di fatto è la condizione di selezione che viene applicata dopo il

prodotto cartesiano. 15

Figura 12: Prodotto cartesiano con condizione (join)

Il modello relazionale offre diversi tipi di join:

 theta join: il theta join è l'operazione di join più generica ovvero quella che presenta una condizione di selezione

generica: in tal caso la condizione di join è costituita un'espressione booleana in cui ogni atomo dell'espressione

assume la forma A θ B dove A e B sono riferimenti ad attributi o valori costanti mentre θ è uno dei seguenti

operatori { =, >, <, >=, <=, <> }. Le tuple i cui attributi espressi nella condizione di join sono nulli non sono incluse

nella relazione risultato. L'operazione precedentemente proposta può essere più semplicemente espressa con il

theta join nel modo seguente: STUDENTE T Studente = Matricola VOTAZIONI

 equijoin join naturale:

e l'equijoin è un'operazione di join che pone ulteriori restrizioni sulla condizione di join.

Nel caso dell'equijoin la condizione di join è un'espressione booleana i cui atomi utilizzano il solo operatore di

uguaglianza. Il risultato di un'operazione di equijoin presenta una ridondanza negli attributi della relazione:

poiché viene utilizzato come operatore di confronto il solo l'operatore di uguaglianza nella relazione risultato vi

saranno coppie di attributi che presentano esattamente gli stessi valori. In particolare si avrà una coppia di

attributi ridondanti per ogni condizione elementare di uguaglianza espressa nella condizione di join . Onde

16

join naturale

evitare questa ridondanza il modello relazionale ha introdotto un'altra operazione di join chiamata

che sostanzialmente è un equijoin che rimuove uno degli attributi ridondanti per ogni coppia di attributi che

devono assumere valori identici. La definizione standard di join naturale richiederebbe inoltre che gli attributi su

cui si impone il vincolo di uguaglianza abbiano anche lo stesso nome (oltre che ovviamente essere compatibili nel

tipo) in entrambe le relazioni. Se gli attributi hanno nome differente si può applicare prima del join un'operazione

di ridenominazione ad una delle due relazioni.

 join esterno (outer join): le operazioni di join fino ad ora elencate tende a restituire tutte e sole le tuple delle due

join interni (inner

relazioni che presentano delle corrispondenze. Tali tipi di operazioni di join vengono detti

join) join.

o semplicemente Allo scopo di poter modellare interrogazioni sofisticate, il modello relazionale ha

join esterni:

introdotto delle estensioni alle operazioni di join che sono state denominate in particolare sono stati

join esterno destro (right outer join) join esterno sinistro (left outer join).

definiti il ed il Il join esterno è

un'operazione di join che produce una relazione con tuple i cui attributi sono ottenuti giustapponendo quelli degli

schemi di relazione coinvolti secondo la condizione di join specificata ma mantiene tutte le tuple presenti in una

delle due relazioni: se il join è esterno destro vengono mantenute tutte le tuple della relazione alla destra

dell'operatore di join, se il join è esterno sinistro quelle della relazione alla sinistra. Poiché date due relazioni

correlate vi possono essere tuple nella relazione R1 che non sono legate a tuple nella relazione R2 si pone il

problema di come assegnare gli attributi dipendenti dalla relazione R2 per quelle tuple della relazione R1 quando

il join esterno mantiene le tuple di R1. In tal caso la relazione risultato presenterà per gli attributi di quelle tuple i

join esterno completo

valori null. Il modello relazionale specifica infine un'ulteriore join esterno che si chiama

(full outer join): con il join esterno completo vengono mantenute tutte le tuple di entrambe le relazioni e per i

valori degli attributi che non hanno corrispondenze viene inserito il valore null. L'operazione di join esterno

completo è quindi ottenibile effettuando separatamente i join esterni destro e sinistro e quindi effettuando

l'operazione di unione alle due relazioni risultanti.

divisione,

Il modello relazionale introduce anche l'operazione di tale operazione non verrà presa in considerazione in

queste dispense in quanto non ha una diretta traduzione in strutture del linguaggio SQL. Per tal motivo risulta di fatto

poco usata: i DBMS non forniscono generalmente un supporto aggiuntivo per realizzare tale operazione e normalmente,

qualora necessaria, viene implementata nei programmi applicativi che accedono alla Base di Dati.

Altre Operazioni

Il modello relazione è normalmente arricchito con altre operazioni che ne aumentano la capacità espressiva dell'algebra

relazionale. In particolare in questo paragrafo vedremo alcune tra le più comuni operazioni che integrano l'algebra

relazionale: le funzioni aggregate, le operazioni di raggruppamento e le operazioni di chiusura ricorsiva. Le funzioni di

aggregate e le operazioni di raggruppamento hanno una traduzione più o meno diretta in strutture che sono messe a

16 Ricordiamo che l'operazione di join giustappone gli attributi delle tuple delle relazioni coinvolte per costruire una tupla della relazione risultato. Utilizzando solo vincoli di

uguaglianza nell'equijoin vi saranno tuple giustapposte con valori identici e quindi inutili. Oltre ad essere una ridondanza strutturale si ha anche una ridondanza semantica: essendo

la relazione ottenuta ponendo un vincolo di uguaglianza su almeno un attributo è sufficiente riportare solo uno dei due attributi che intervengono nel confronto di uguaglianza il valore

dell'altro sarà naturalmente ottenuto considerando quello dell'attributo riportato. 16

disposizione dal linguaggio SQL (o sue estensioni). Le operazioni di chiusura ricorsiva non hanno invece una controparte

nel linguaggio SQL ma risultano utili a livello logico concettuale per esprimere alcune interrogazioni di tipo ricorsivo.

funzioni

Il primo tipo di richiesta che non può essere espressa nell'algebra relazionale di base consiste nello specificare

aggregate matematiche su collezioni di valori della Base di Dati. Ad esempio non esiste un'espressione dell'algebra

relazionale che ci permette di calcolare la media dei voti di uno studente, sebbene sia possibile recuperare tutti i voti che

ha ottenuto. Parimenti non è possibile esprimere con l'algebra relazionale un'interrogazione che restituisca il massimo ed il

minimo valore della matricola degli studenti. In generale tutte quelle interrogazioni di tipo statistico che riassumono

informazioni provenienti dalle tuple della Base di Dati. Le funzioni più comuni che si considerano sono la somma (sum), la

media (average), il minimo (minimum) ed il massimo (maximum): tali funzioni sono ad esempio applicate ad un particolare

attributo di una relazione per tutte le tuple. Un'altra funzione utile è la funzione count che conta le tuple di una relazione.

raggruppamento

Un altro tipo comune di richiesta prevede il delle tuple presenti in una relazione sulla base del valore di

alcuni loro attributi e quindi l'applicazione di una funzione aggregata indipendentemente ad ogni gruppo. Ad esempio

vorremmo effettuare un'interrogazione che restituisce una relazione che presenta la lista di tutti i moduli di un semestre

(ad esempio Primavera, Anno 1) e per ogni modulo vorremmo sapere il voto medio, il numero di studenti che hanno

sostenuto l'esame, il voto massimo ed il voto minimo. In base all'esempio in esame tale interrogazione si traduce in un

equijoin tra la tabella dei moduli e la tabella delle votazioni. Otteniamo cosi una relazione che presenta una relazione con

gli attributi delle tabelle MODULO, VOTAZIONE: le quali sono state correlate tramite il codice del modulo. Le tuple cosi

ottenute possono essere ordinate utilizzando come attributo di ordinamento il codice del modulo. Ma con l'algebra

relazionale non saremmo in grado di andare oltre. La funzione di raggruppamento ci permette di estrarre una tupla per

ogni modulo differente e di riempire gli altri attributi con il risultato di funzioni di aggregazione applicate agli attributi

corrispondenti per ogni gruppo di tuple. Effettuando una proiezione che mantiene solo gli attributi di Codice di MODULO e

Voto di VOTAZIONE, possiamo applicare la funzione media, minimo, e massimo all'attributo Voto e raggruppare

utilizzando come attributo di raggruppamento il codice del modulo. Otteniamo così la relazione richiesta. Il processo

descritto è rappresentato in figura 13. chiusura ricorsiva.

Un altro tipo di operazione che non può essere specificata nell'algebra relazionale è la Questa

operazione è applicata ad una associazione ricorsiva tra tuple dello stesso tipo. Associazioni di questo tipo sono modellate

con relazioni che presentano una chiave esterna che referenzia la chiave primaria della stessa relazione.

Un esempio di questo tipo di operazioni assume significato in scenari in cui il vincolo di integrità referenziale che modella

l'associazione ricorsiva rappresenta un generico rapporto figlio – padre : ad esempio una chiusura ricorsiva ci

17

permetterebbe di recuperare tutte le tuple che sono direttamente ed indirettamente dipendenti da una data tupla .

18

Figura 13: Calcolo dei valori sintetici per gli esami sostenuti nel semestre di primavera dell'anno 1

17 Con il termine rapporto figlio – padre si fa riferimento a quelle relazioni che modellano alberi in cui è possibile definire un nodo che ha dei nodi figli e così continuando per ogni

figlio. In tal caso se ogni nodo è identificato da una chiave primaria è possibile definire una relazione che modella questa struttura ad albero in cui ogni tupla rappresenta un nodo e vi

sarà un attributo chiave primaria che identifica il nodo ed un attributo chiave esterna che referenzia un'altra tupla della stessa relazione ed individua il padre del nodo.

18 Se si riflette sulle operazioni fino ad ora introdotte risulta evidente come l'interrogazione appena descritta sia impossibile da ottenere con i soli strumenti dell'algebra relazionale.

17

2.3.6 Calcolo Relazionale

calcolo relazionale

Il è un linguaggio formale che permette di specificare in modo dichiarativo un'interrogazione

relazionale. Una specifica dichiarativa definisce le proprietà delle istanze di relazione che devono essere incluse nel

risultato di un'interrogazione.

L'algebra relazionale fornisce invece una specifica operativa in quanto specifica la sequenza di operazioni che si devono

effettuare sulla Base di Dati per selezionare le istanze di relazione che soddisfano l'interrogazione.

Il potere espressivo del calcolo relazionale è identico a quello dell'algebra relazionale, quello che cambia è l'approccio che

propone per specificare un'interrogazione sulla Base di Dati. In queste dispense non approfondiremo oltre tale argomento

in quanto il calcolo relazionale richiede, per essere compreso agevolmente, una buona conoscenza della logica dei predicati

del primo ordine. Il calcolo relazionale costituisce una formulazione equivalente e quindi alternativa all'algebra relazionale.

Come vedremo entrambi i linguaggi hanno la loro importanza in quanto il principale strumento di interazione con le Basi

di Dati relazionali (SQL) si basa su entrambi.

2.4 Traduzione del Modello ER nel Modello Relazionale

2.4.1 Introduzione

Il modello ER è un modello molto adatto durante la progettazione concettuale in quanto è in grado di rappresentare in

maniera molto efficace la realtà su cui si vuole modellare la Base di Dati, caratterizzarne gli oggetti che la costituiscono ed

individuare i legami che intercorrono tra questi. D'altra parte il modello relazionale, meno intuitivo da questo punto di

vista , permette di essere facilmente tradotto in strutture del linguaggio SQL.

19

Poiché il linguaggio SQL è l'interfaccia maggiormente utilizzata dai DBMS per creare, manipolare ed interagire con una

Base di Dati, poter esprimere tutto quello che concerne una Base di Dati in linguaggio SQL ci permette di implementare

effettivamente la Base di Dati. Il passaggio dal modello ER alle strutture del linguaggio SQL non è però immediato mentre

dato un modello relazionale la sua traduzione in linguaggio SQL è ben definita e quasi automatica. In questo capitolo

descriveremo un processo di traduzione del modello ER in un equivalente modello relazionale: è possibile stabilire delle

regole di traduzione che permettono di tradurre tutti i costrutti del modello ER (entità attributi associazioni) in equivalenti

strutture del modello relazionale (relazioni, attributi, vincoli).

Il processo di traduzione si articola in una serie di passi che descriveremo in seguito. A scopo di esempio tradurremo il

modello entità relazione realizzato che descrive l'esempio in esame nell'equivalente modello relazionale.

2.4.2 Passo 1: Traduzione dei Tipi di Entità

Per ogni tipo di entità (forte) E nello schema ER è possibile costruire una relazione R che contiene tutti gli attributi

semplici di E. Per gli attributi composti si inserirà l'equivalente combinazione di attributi semplici. Per identificare le tuple

della relazione si costruisca inoltre la chiave primaria scegliendo uno degli attributi chiave di E: se la chiave è composta da

più attributi l'equivalente combinazione di attributi costituirà la chiave in R.

Nell'esempio presentato per l'entità STUDENTE costruiremo una relazione che presenta lo stesso nome e gli stessi attributi

e utilizzeremo come chiave l'attributo Matricola.

2.4.3 Passo 2: Traduzione dei Tipi di Entità Deboli

Per ogni tipo di entità debole W dello schema ER con tipo di entità proprietario E si definisce una relazione R che presenta

tutti gli attributi semplici e le componenti di quelli composti di W (come ne caso precedente). Poiché l'entità debole non ha

un attributo chiave occorre aggiungere gli attributi di chiave primaria della relazione associata all'entità proprietaria

dell'entità debole. Tali attributi costituiranno una chiave esterna per W, e saranno anche parte della sua chiave primaria

in quanto necessari ad identificare le tuple di W.

La modellazione di un'entità debole costruisce in modo implicito un vincolo di integrità referenziale tra la relazione che

descrive l'entità proprietaria e la relazione che descrive l'entità debole. Per tale vincolo occorre quindi specificare come

comportarsi nei confronti di operazioni di modifica e cancellazione di tuple corrispondenti ad entità proprietarie: in

generale in questi casi si sceglie di propagare l'effetto delle operazioni di aggiornamento indicate procedendo

rispettivamente alla modifica e alla cancellazione delle tuple dipendenti (opzione cascade).

2.4.4 Passo 3: Traduzione dei Tipi di Associazioni Binarie 1:1

Per ogni tipo di associazione R binaria 1:1 nello schema ER si individuano le relazioni S e T che corrispondono alle entità

collegate dall'associazione. Il modello relazionale fornisce in questo caso tre approcci:

 approccio basato su chiavi esterne: con questo approccio si stabilisce un vincolo di integrità referenziale tra le

due relazioni in gioco. In tal caso si sceglie una delle due relazioni coinvolte nell'associazione e si aggiungono al

corrispondente schema di relazione gli attributi che definiscono che costituiscono la chiave primaria nell'altra

relazione. Nella scelta della relazione a cui aggiungere gli attributi è opportuno scegliere quella che partecipa

totalmente all'associazione in tal modo si evita di avere valori nulli per tali attributi. Gli attributi aggiunti

costituiranno una chiave esterna per la relazione scelta. Nell'esempio preso in esame l'associazione DIRIGE che

lega DOCENTE a DIPARTIMENTO è un'associazione binaria 1:1: in tal caso DIPARTIMENTO è l'entità che

partecipa totalmente all'associazione. Aggiungeremo perciò l'attributo Direttore alla relazione DIPARTIMENTO il

quale riferirà l'attributo Matricola dell'entità DOCENTE ;

20

 approccio basato sull'unica relazione di fusione: una traduzione alternativa dell'associazione 1:1 è data dalla

fusione dei due tipi di entità in un'unica relazione. Questo approccio può essere adeguato quando entrambe le

partecipazioni sono totali. Questa infatti è la condizione che genera il minimo numero di tuple con valori nulli: se

una delle due entità non partecipa totalmente alla relazione le tuple nella relazione fusione vi saranno tuple che

19 Il fatto che il modello relazionale sia un modello meno intuitivo da utilizzare durante la progettazione concettuale non significa che abbia minor potere espressivo, ma soltanto che

le strutture utilizzate dal modello relazionale sono di più basso livello rispetto a quello fornito dal modello ER, per cui il processo di progettazione concettuale risulterebbe più

macchinoso. Di fatto i due modelli hanno la stessa capacità espressiva in quanto è possibile tradurre un modello relazionale in un modello ER e viceversa.

20 Osserviamo che il nome dell'attributo che viene aggiunto normalmente corrisponde al ruolo che questo assume nell'associazione. In questo caso il docente assume il ruolo

direttore nell'associazione DIRIGE ed è identificato univocamente da una matricola per cui introdurremo un attributo il cui dominio è quello dell'attributo Matricola di DOCENTE che

avrà il nome Direttore. 18

presentano valori nulli per tutti gli attributi di una delle due relazioni originarie. Se una delle due relazioni

partecipa totalmente alla relazione per alcune delle tuple della relazione risultante gli attributi corrispondenti

assumeranno valori nulli. Se entrambe le relazioni non partecipano totalmente allora vi potranno essere valori

nulli sia per gli attributi di una relazione che per quelli dell'altra; questo è il caso peggiore in quanto non permette

di stabilire una chiave sulla relazione risultante con i soli attributi ottenuti dalle relazioni originarie. Nel caso

invece entrambe le entità partecipano totalmente all'associazione non vi saranno tuple con valori nulli generati

dalla fusione delle relazioni;

 approccio basato su relazione associazione: una ulteriore alternativa è creare una terza relazione R che

relazione

rappresenta esplicitamente l'associazione tra T ed S. Tale relazione, che prende il nome di

associazione, presenterà come attributi le chiavi primarie di entrambe le relazioni e introduce due vincoli di

integrità referenziale: uno tra T ed R ed uno tra S ed R. Poiché la relazione è di tipo 1:1 è possibile scegliere come

chiave primaria una delle due chiavi esterne della relazione ottenuta.

Tra gli approcci presentati il primo è il più comodo ed elegante ed è quello da preferirsi se non esistono motivi particolari,

che spingano all'uso degli altri due. Nel caso in cui si utilizzi l'approccio basato su chiavi esterne si pone il problema di

come gestire le modifiche alla relazione riferita: in tal caso spesso non è semanticamente corretto cancellare le tuple nella

relazione referenziante quando vengono cancellate le tuple riferite, mentre normalmente si usa la propagazione per le

modifiche. Il caso della cancellazione di tuple riferite è di maggior interesse: in riferimento all'esempio precedente se

consideriamo l'associazione CONTROLLA tra DOCENTE e PROGETTO, l'eliminazione di una tupla in DOCENTE

provocherebbe l'eliminazione di tutte le tuple di PROGETTO che riferiscono la tupla eliminata qualora fosse stata scelta la

propagazione.

Questo è un comportamento che può avere più o meno senso ed è compito di chi modella la Base di Dati scegliere se

accettare di avere progetti “orfani”, impedire la cancellazione delle tuple in DOCENTE che sono referenziate da tuple in

PROGETTO o propagare la cancellazione.

2.4.5 Passo 4: Traduzione dei Tipi di Associazioni Binarie 1:N

Per i tipi di associazione binaria 1:N vengono individuate le relazioni S e T che corrispondono alle entità coinvolte

nell'associazione. Indichiamo S come la relazione che partecipa all'associazione lato-N, ovvero quello che vi partecipa con

molteplicità N. Allo schema di relazione corrispondente ad S vengono quindi aggiunti gli attributi che definiscono la chiave

primaria di T. Anche in tal caso avremo un vincolo di integrità referenziale tra T ed S e gli attributi aggiunti in S

costituiranno una chiave esterna. Se consideriamo la relazione MODULO nell'esempio in esame osserviamo che esiste

un'associazione binaria 1:N con DOCENTE e MODULO vi partecipa con molteplicità N in quanto lo stesso docente può

insegnare più moduli. In tal caso per modellare l'associazione INSEGNA si aggiunge l'attributo Docente alla relazione

MODULO che riferirà l'attributo Matricola della relazione DOCENTE. Osserviamo che nel caso di associazioni binarie 1:N

la relazione in cui aggiungere la chiave esterna è sempre quella che partecipa lato N all'associazione. Anche in questo caso

sono valide le considerazioni fatte al punto precedente su come gestire le tuple della relazione che partecipa lato-N

all'associazione in caso di operazioni di aggiornamento sulla relazione referenziata.

2.4.6 Passo 5: Traduzione dei Tipi di Associazioni Binarie M:N

Per ogni tipo di associazione binaria M:N tra S ed T si costruisce una relazione R che rappresenta tale relazione. Questa

relazione avrà come attributi di chiave esterna gli attributi di chiave primaria di entrambe le relazioni S e T. In tal caso

essendo l'associazione M:N la chiave primaria della relazione corrispondente sarà composta da tutti gli attributi che

compongono le due chiavi esterne della relazione. Ad esempio prendendo in considerazione l'associazione

SOSTIENE_ESAME che lega le entità STUDENTE e MODULO questa si traduce nella relazione VOTAZIONE. La relazione

votazione e chiaramente una relazione M:N in quanto più studenti possono sostenere l'esame per lo stesso modulo ed allo

stesso tempo un singolo studente può sostenere più esami per moduli differenti. Come possiamo notare dallo schema di

relazione associato a VOTAZIONE la chiave primaria è data dagli attributi Modulo e Studente che riferiscono

rispettivamente le chiavi primarie di MODULO e STUDENTE. Questo significa che per identificare una tupla di

VOTAZIONE sono necessari e sufficienti il codice del modulo e la matricola dello studente. Tale vincolo fa riferimento ad

uno scenario in cui uno studente può sostenere un solo esame per uno specifico modulo .

21

2.4.7 Passo 6: Traduzione degli Attributi Multivalore

Per ogni attributo multivalore di un'entità E si individua la relazione corrispondente all'entità E – che indicheremo con S –

e si definisce una nuova relazione R che sarà soggetta ad un vincolo di integrazione referenziale con S. Più in particolare R

sarà la relazione referenziante ed S quella referenziata. Poiché il modello relazionale non permette valori multipli per gli

attributi di una tupla occorre creare l'illusione di più valori per un attributo rappresentando tali valori con più tuple in

un'altra relazione. Di fatto si applica lo stesso procedimento che si è adottato per modellare le associazioni binarie 1:N: in

questo caso la relazione che contiene le tuple associate ai valori dell'attributo multivalore partecipa lato-N all'associazione.

In tal caso per entrambe le operazioni di aggiornamento (cancellazione e modifica) l'opzione più sensata è quella di

propagare gli effetti delle modifiche: la costruzione della relazione che mantiene i valori dell'attributo multivalore è

puramente un artefatto e tali attributi devono essere considerati come facenti parte della relazione che riferiscono. Per tal

motivo la cancellazione di una tupla in S comporta la cancellazione delle tuple dipendenti in R. Analogamente si propaga

la modifica. L'esempio preso in esame non presenta attributi multivalore possiamo però considerare di aggiungere

l'attributo NumeroDiTelefono all'entità DOCENTE: un docente può essere reperibile a più numeri di telefono. Tale modifica

al modello ER si traduce nella definizione di una nuova relazione NUMERI_TELEFONO e nell'introduzione di un vincolo di

integrità referenziale con DOCENTE in cui DOCENTE è la relazione riferita e NUMERI_TELEFONO è la relazione

referenziante. NUMERI_TELEFONO avrà come attributi il Numero e Docente: Numero rappresenta il numero di telefono

mentre Docente è la chiave esterna. La chiave primaria di NUMERI_TELEFONO è la coppia di attributi Docente,Numero.

2.4.8 Passo 7: Traduzione dei Tipi di Associazione N-arie

Il modello ER permette di rappresentare anche associazioni N-arie in cui partecipano più di due entità. Per tradurre tali

associazioni si definisce una relazione R i cui attributi sono costituiti da tutti gli attributi chiave delle entità che

coinvolgono. In particolare la relazione così definita presenterà tante chiavi esterne quante sono le entità che partecipano

21 .

In tal caso si far riferimento all'esame superato, non vengono registrati i tentativi che non hanno portato al superamento della prova

19

all'associazione e vi saranno altrettanti vincoli di integrità referenziale che legano la relazione con le relazioni che

modellano le entità in gioco. La scelta della chiave e delle operazioni da intraprendere in caso di operazioni di

aggiornamento delle relazioni riferite è da valutarsi caso per caso. Se esiste almeno una entità che partecipa totalmente

all'associazione allora la chiave esterna che riferisce la relazione corrispondente può anche essere usata come chiave

primaria, in generale la chiave primaria può essere definita come combinazione di tutte le chiave esterne. Per quanto

riguarda il comportamento da adottare a fronte di ogni operazione di aggiornamento occorre valutare ogni singolo vincolo

di integrità referenziale. Se però la chiave primaria della relazione di associazione è costituita da tutte le chiavi esterne

allora occorre propagare sia le cancellazioni che le modifiche.

2.4.9 Riepilogo

La tabella 1 fornisce un veloce riepilogo delle regole di traduzione discusse presentando per ogni costrutto del modello R

l'equivalente costrutto nel modello relazionale.

Una delle fondamentali differenze tra il modello relazione ed il modello ER è la rappresentazione delle associazioni: come

abbiamo visto il modello ER utilizza dei costrutti di prima classe per rappresentare le associazioni, mentre nel modello

relazionale le associazioni sono tradotte in relazioni, al pari delle entità, ed in una serie di vincoli di integrità referenziali

con altre relazioni. Come abbiamo già osservato in precedenza il modello relazionale costituisce un modello di più basso

livello rispetto a quello ER: il fatto che le associazioni vengano modellate al pari delle entità riflette questa caratteristica.

Analogamente accade per la traduzione degli attributi multivalore. Questa semplicità ha però il vantaggio di permettere

una più facile traduzione nel linguaggio SQL che costituisce lo strumento principale per definire, manipolare ed interagire

con una Base di Dati.

Modello ER Modello Relazionale

Tipo di entità Relazione “entità”

Tipo di associazione 1:1 o 1:N Chiave esterna (o relazione “associazione”)

Tipo di associazione M:N Relazione “associazione” e due chiavi

esterne

Tipo di associazione n-ario Relazione “associazione” ed n chiavi

esterne

Attributo semplice Attributo

Attributo composto Insieme di attributi componenti semplici

Attributo multivalore Relazione e chiave esterna

Insieme di valori Dominio

Attributo chiave Chiave primaria (o secondaria)

Tabella 1: Mapping tra modello ER e modello relazionale

Poiché le associazioni sono tradotte in relazioni nell'effettuare le interrogazioni atte a recuperare tutte le entità che sono

coinvolte in una associazione occorre necessariamente effettuare delle operazioni di equijoin. Le operazioni di equijoin sono

direttamente determinate dai vincoli di integrità referenziale associati alle operazioni. Chi interagisce con la Base di Dati

deve perciò conoscere come le relazioni siano tra loro connesse e quindi quante operazioni di join richieda una particolare

interrogazione. Il join normalmente è un'operazione che ha un'implementazione dispendiosa rispetto alle operazioni di

selezione o proiezione, per cui il conoscere il numero di operazioni di join coinvolte in un'interrogazione è utile per avere

un'idea del carico di lavoro richiesto per restituire le tuple che soddisfano l'interrogazione. Anche in questo caso questo

aspetto riflette come il modello relazionale sia un modello di più basso livello rispetto al modello ER e come sia

maggiormente orientato ad una rappresentazione della Base di Dati volta alla sua implementazione.

3. Fondamenti di SQL

3.1 Introduzione

In questo capitolo faremo una breve panoramica di SQL. SQL è un linguaggio per l'interazione con la Basi di Dati

relazionali. SQL è uno standard ed è diventato di fatto lo strumento univocamente accettato per l'interazione con le Basi di

Dati relazionali che si sono affermate anche grazie alla presenza di SQL. La specifica SQL è molto corposa e si è evoluta nel

tempo integrando sempre maggiori funzionalità: in questo capitolo tratteremo i fondamenti del linguaggio SQL ovvero i

concetti di base che sono sufficienti per definire una Base di Dati, manipolarla ed effettuare delle interrogazioni.

Tratteremo inoltre il processo di traduzione di un modello relazionale nella sua specifica in SQL: lo scopo di questa breve

introduzione è rendere lo studente familiare con il linguaggio SQL e dotarlo delle capacità necessarie per implementare e

gestire una semplice Basi di Dati ad uso personale. Argomenti avanzati come l'utilizzo di viste, trigger e la descrizione dei

pacchetti aggiuntivi per l'analisi dei dati, nonché l'embedded SQL non saranno oggetto di discussione, seppur facenti parte

dello standard SQL.

Forniremo infine la specifica SQL completa per realizzare la Base di Dati modellata in queste dispense. Tale specifica potrà

essere trasformata una Base di Dati reale utilizzando un qualunque DBMS o più semplicemente un'applicazione per la

gestione di Basi di Dati ad uso personale quali OpenOffice.org Base o Microsoft Access di cui verrà illustrato il

funzionamento.

3.1.1 Che cos'è

SQL (Structured Query Language)

Il linguaggio è uno strumento per la definizione e la manipolazione di Badi di Dati

relazionali. SQL è, per inciso, una delle ragioni del successo e della diffusione delle Basi di Dati relazionali: costituisce

infatti per esse uno strumento che permette di realizzare facilmente Basi di Dati relazionali senza però vincolarsi ad una

specifica implementazione fisica essendo così portabile su ogni DBMS che utilizza un modello relazionale. Il linguaggio

20

SQL fornisce elementi sia per definire i dati che le operazioni che devono essere eseguite su di essi: qualunque DBMS di

tipo relazionale è fornisce un'interfaccia che si basa SQL ed è perciò in grado di tradurre questi elementi in una Base di

Dati relazionale.

L'utilizzo maggiore di SQL è quello definire delle interrogazioni verso una Base di Dati allo scopo di reperire un'insieme di

dati che soddisfano determinate proprietà definite dall'utente. A tale scopo SQL fornisce un'interfaccia dichiarativa ad alto

livello che si basa su elementi sia del calcolo relazionale su tuple che dell'algebra relazionale, utilizzando però una sintassi

più semplice ed intuitiva. Un nome precedente di SQL era infatti SEQUEL che è l'acronimo di Structured English QUery

Language ovvero linguaggio inglese strutturato di interrogazione: con il termine inglese si fa appunto riferimento alla

somiglianza dei costrutti che questo presenta con quelli della lingua inglese. Da qui, la maggior intuitività e semplicità

rispetto all'uso di operatori ed espressioni dei linguaggi formali.

3.1.2 Lo Standard SQL

Come già accennato SQL nasce come SEQUEL: questo era un primo embrione di SQL sviluppato e progettato presso il

Centro di Ricerca dell'IBM come interfaccia verso un sistema di Basi di Dati relazionale sperimentale chiamato SYSTEM R.

Oggi SQL è il linguaggio standard per i più importanti DBMS relazionali commerciali ed è stato sottoposto ad un processo

di standardizzazione tramite gli sforzi congiunti dell'ANSI e dell'ISO che hanno prodotto una prima specifica del

22 23

linguaggio (SQL-86 od SQL1) e le sue successive revisioni ed estensioni (SQL-92 od SQL2 ed SQL-99 od SQL3). L'ultima

nucleo

versione dello standard SQL è SQL3 o SQL-99 ed è datata 1999. Tale specifica è divisa in un ed in una serie di

pacchetti specializzati opzionali: il nucleo definisce le funzionalità base dello standard che ogni DBMS che si dichiara

compatibile con SQL-99 deve supportare; i pacchetti possono invece essere invece implementati come moduli facoltativi e

sono orientati ad applicazioni specifiche come il data mining , il data warehousing25, l'elaborazione e l'analisi dei dati in

24

linea (OLAP – On Line Analitical Processing), la gestione dei dati multimediali, etc.. In queste dispense daremo una breve

panoramica di un sottoinsieme delle funzionalità definite nel nucleo. In particolare analizzeremo i costrutti fondamentali

del linguaggio di descrizione dei da e di quello di manipolazione dei dati.

25

3.2 Elementi di SQL tabella, riga colonna

SQL utilizza i concetti di e in luogo dei concetti di relazione, tupla ed attributo introdotte dal modello

tabella

relazionale. Una è lo strumento con cui si rappresenta una relazione: le righe individuano le tuple della relazione

mentre le colonne gli attributi definiti nello schema di relazione associato. Il concetto di tabella è centrale in tutto il

linguaggio SQL che comprende tre principali linguaggi:

 linguaggio di definizione dei dati

il (DDL – Data Definition Language): il linguaggio SQL contiene un

sottoinsieme di istruzioni per definire lo schema di una Base di Dati relazionale, una relazione ed i vincoli che

intercorrono tra di esse. Il DDL permette non solo di definire una Base di Dati relazionali ma anche di alterarne la

struttura;

 linguaggio di interrogazione dei dati

il (QL – Query Language): le operazioni del linguaggio di interrogazione dei

dati sono quelle più frequentemente utilizzate dagli utenti delle Basi di Dati relazionali. Le istruzioni del QL sono

basate sul calcolo relazionale su tuple per definire delle proprietà sui risultati e sulle operazioni di recupero

dell'algebra relazionale per guidare la ricerca dei dati;

 linguaggio di manipolazione dei dati

il (DML – Data Manipulation Language): alcune operazioni del linguaggio

SQL permettono di modificare lo stato di una Base di Dati. Le Basi di Dati evolvono attraverso le operazioni

definite dal DML che sono modellate sulla base delle operazioni di aggiornamento definite per l'algebra

relazionale.

Il linguaggio SQL come vedremo più nel dettaglio nei paragrafi successivi si presenta come una naturale traduzione del

modello relazionale ed eredita da esso molti dei suoi concetti espressi però in maniera più intuitiva. Si consideri uno dei

tabella.

concetti centrali nel linguaggio SQL: quello di La tabella pur essendo un'astrazione fornisce un modello intuitivo

per rappresentare fisicamente una relazione. Tutte le operazioni di recupero e manipolazione dei dati operano su tabelle ed

hanno come risultato una

tabella. La tabella costituisce un modello unificato con cui organizzare ogni tipo di informazione presente in una Base di

Dati relazionale allo stesso tempo però è un concetto familiare, semplice e comprensibile da tutti. Il concetto di relazione è

invece meno immediato e più astratto e soprattutto non fornisce alcuna indicazione pratica (se non tramite operazioni

definite secondo un modello matematico) su come organizzare le informazioni.

Analizzando i diversi linguaggi di cui si compone SQL vedremo più nel dettaglio come i concetti del modello relazionale

siano mappati nelle strutture del linguaggio e come tali strutture costituiscano uno strumento più semplice per effettuare

le stesse operazioni - o rappresentare le stesse astrazioni - definite nei linguaggi formali del modello relazionale.

3.2.1 Linguaggio per la Definizione dei Dati

SQL permette di rappresentare tutti i costrutti del modello relazionale attraverso il linguaggio di definizione dei dati. Il

linguaggio di definizione dei dati permette sia di creare che di modificare la struttura di una Base di Dati relazionale. In

particolare il DDL permette di definire schemi, cataloghi, tipi di dati, tabelle e vincoli . Il linguaggio SQL fornisce le

istruzioni CREATE, ALTER e DROP rispettivamente per creare, modificare ed eliminare tutti gli elementi che definiscono

un modello relazionale in un RDBMS. Lo standard permette inoltre di associare un insieme di utenti ad una Base di Dati

relazionale definendo per questi (tramite le istruzioni GRANT e REVOKE) i permessi di accesso ad ogni elemento della Base

di Dati.

Schemi e Cataloghi

22 ANSI è l'acronimo di American National Standard Institute ed il principale comitato di standardizzazione in America.

23 ISO è l'acronimo di International Standard Organization è un'organizzazione internazionale che produce standard a livello mondiale in ogni ambito dal controllo della qualità ai

formati dei CD, DVD etc….

24 Il termine mining deriva dal verbo to mine che in inglese ha il significato di scavare (in particolare l'attività di scavare realizzata dai minatori) e rappresenta perciò in modo figurato

l'atto di andare ad analizzare a fondo. Per tal motivo il termine data mining è associato all'atto di analizzare i grandi quantità di dati a fondo.

25 Il termine warehouse significa, in inglese, magazzino da cui data warehouse ovvero magazzino dI dati. Un data warehouse è un grande repository di dati che integra informazioni

provenienti da più Basi di Dati e da luogo ad una Base di Dati virtuale di enormi dimensioni. Classiche applicazioni che utilizzano un data warehouse sono volte ad effettuare analisi

storiche su grandi quantità di dati applicando tecniche di data mining allo scopo di estrarre delle proprietà dai dati

21 schema catalogo.

A partire dalla versione denominata SQL2 dello standard SQL vengono introdotti i concetti di e Uno

schema SQL permette di partizionare il contenuto di una Base di Dati: esso è infatti un sottoinsieme delle tabelle e di altri

costrutti che appartengono alla medesima applicazione di Base di Dati. Uno schema è descritto da un nome di schema ed

ad esso viene associato un identificatore di autorizzazione che individua l'utente proprietario dello schema. Lo schema può

contenere tabelle, viste, vincoli, domini, permessi su tali elementi e dei descrittori di questi elementi. Tali descrittori sono

metadati

detti ovvero dati che descrivono i dati e rendono lo schema autodescrittivo. Tramite l'utilizzo dei metadati si può

programmaticamente conoscere la struttura definita da uno schema, gli oggetti in esso contenuti e le relazioni che

intercorrono tra loro.

Una volta definito un modello relazionale che rappresenta un determinato scenario è possibile tradurre il modello in uno

schema SQL: tramite l'interfaccia SQL offerta dai

DBMS relazionali è possibile tradurre lo schema in un'implementazione fisica della Base

di Dati. I DBMS mantengono e rendono accessibile lo schema a coloro che devono

interagire con la Base di Dati. La creazione di uno schema avviene attraverso l'istruzione SQL:

CREATE SCHEMA nome_schema AUTHORIZATION nome_utente;

Ad esempio, volendo definire uno schema per modellare una facoltà universitaria utilizzeremo la seguente istruzione SQL:

CREATE SCHEMA FACOLTÀ AUTHORIZATION john_doe ;

La precedente istruzione assegna inoltre la proprietà dello schema all'utente john_doe.

ambiente SQL

Lo schema viene fisicamente ospitato all'interno di un ovvero un'installazione di un RDBMS con interfaccia

SQL su di un sistema di elaborazione. catalogo.

L'ambiente SQL permette di mantenere una collezione di schemi a cui viene associato un nome definita Ogni

catalogo contiene un particolare schema chiamato INFORMATION_SCHEMA: questo descrive la struttura del catalogo ed

effettuando delle interrogazioni sulle relazioni definite nell'INFORMATION_SCHEMA è possibile conoscere il contenuto del

catalogo stesso. In particolare le informazioni mantenute nell'INFORMATION_SCHEMA riguardano le tabelle, le viste, le

colonne delle tabelle, i vincoli, i tipi di dato, gli utenti ed i privilegi degli utenti. Il catalogo definisce una sorta di unità

logica autoconsistente: i vincoli di integrità possono trascendere i confini degli schemi, ma non possono essere definiti tra

relazioni che appartengono a schemi mantenuti in cataloghi diversi. Schemi definiti nello stesso catalogo oltre a intrecciare

relazioni possono condividere alcuni elementi come ad esempio i domini per gli attributi.

I Tipi di Dato di SQL

Il linguaggio SQL dispone una serie di tipi di dato built-in in ogni implementazione dello standard SQL che l'utente può

26

utilizzare per caratterizzare gli attributi delle relazioni. Il linguaggio DDL permette inoltre la creazione di nuovi tipi di dato

con cui definire gli attributi di una relazione. I nuovi tipi di dato possono essere espressi come sottoinsieme dei tipi di dato

built-in o come loro composizioni. La definizione di nuovi tipi di dato può essere sia implicita che esplicita. Nel primo caso

la definizione del tipo di dato viene data nel momento in cui si modella l'attributo a cui è associato: in tal caso il tipo non

ha un nome e di fatto viene ridefinito ogni volta che si definisce un attributo di tale tipo. È possibile invece specificare un

dominio:

nuovo tipo di dato in maniera esplicita creando un un dominio associa un nome ad un tipo di dato ed agisce da

segnaposto per esso. L'utilizzo dei domini permette di definire un tipo di dato una sola volta ed utilizzarlo per modellare

più attributi.

L'insieme dei tipi built-in definiti dallo standard SQL per modellare gli attributi di una relazione include i tipi numerici, le

stringhe di caratteri, le stringhe di bit, i valori booleani, la data e l'ora. In particolare:

 tipi di dati numerici: lo standard SQL dispone di tipi numerici interi di diverse dimensioni (INT o SMALLINT) e

di tipi numerici a virgola mobile in diversi formati (REAL o FLOAT e DOUBLE PRECISION). È inoltre possibile

definire tipi numerici la decidendone la precisione e la scala: la prima individua il numero massimo di cifre

decimali utilizzate per rappresentare il numero, mentre la seconda definisce il numero di cifre dopo la virgola

(NUMERIC(precisione,scala)) ;

27

 stringhe di caratteri: SQL permette di definire stringhe di caratteri a lunghezza fissa (CHAR(n) o

CHARACTER(n)) od a lunghezza variabile con la specifica di una lunghezza massima (VARCHAR(n) ed altri tipi di

nomi) . Le stringhe di caratteri sono delimitate da apici singoli e sono case-sensitive ;

28 29

 stringhe di bit: al pari delle stringhe di caratteri il linguaggio SQL permette di utilizzare stringhe di bit di

lunghezza fissa (BIT(n)) o di lunghezza variabile (VARYING BIT(n)). Una stringa di bit può essere definita senza

specificare la lunghezza in tal caso viene assunta la lunghezza di default che è 1. Le stringhe di bit sono espresse

come stringhe di caratteri nella forma B'bbbbb' dove b può assumere solo i valori 0 ed 1;

 tipi booleani: i tipi booleani assumono solo i valori TRUE e FALSE e molto spesso sono definiti utilizzando

stringhe di bit di lunghezza 1;

 tipi per la rappresentazioni di informazioni temporali: a partire da SQL2 sono stati introdotti tipi di dati per

rappresentare la data (DATE), l'ora (TIME) od un preciso istante di tempo (TIMESTAMP). La data viene

data

rappresentata specificando le componenti YEAR, MONTH e DAY. La viene espressa utilizzando una stringa

opportunamente formattata: si utilizza una stringa di dieci caratteri in cui le componenti sono separate da un

opportuno carattere. Il formato di tale stringa spesso dipende dalle impostazioni di lingua scelte per

l'implementazione. Ad esempio il formato di data inglese è definito come segue: 'YYYY–MM–DD' dove Y indica i

caratteri numerici usati per esprimere l'anno, M quelli per esprimere il mese e D quelli per il giorno. Il formato

italiano prevede italiano esprime la data in modo inverso ('DD–MM–YYYY'). Molto spesso al posto del separatore '–'

può essere usato il carattere di separazione '/'. L'ora al pari della data viene espressa utilizzando una stringa ma

26 L'accezione built-in significa letteralmente costruito dentro ovvero integrato. Una caratteristica built-in in un sistema è una caratteristica naturalmente presente nel sistema e che è

implicita alla definizione del sistema stesso. La maggior parte dei linguaggi permette di creare nuovi tipi per i dati che tratta i tipi definiti built-in sono quelli di cui naturalmente si

dispone utilizzando semplicemente il linguaggio, senza alcuna definizione aggiuntiva.

27 Questi tipi di dato vengono detti numeri a virgola fissa (fixed point) e spesso presentano una precisione ed una scala di default. Altri nomi con cui possono essere indicati questi

tipi sono DECIMAL(precisione,scala) o DEC(precisione,scala).

28 n indica la lunghezza della stringa dei caratteri.

29 L'accezione case-sensitive viene usata quando sussiste la proprietà per cui stringhe con la stessa combinazione di caratteri ma espressi diversamente nella loro forma maiuscola

o minuscola risultano differenti. 22