Basi di dati - Riassunto esame, prof. Coccoli
Anteprima
ESTRATTO DOCUMENTO
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
I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher Exxodus di informazioni apprese con la frequenza delle lezioni di Basi di dati e Sistemi Informativi e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Genova - Unige o del prof Coccoli Carlo.
Acquista con carta o conto PayPal
Scarica il file tutte le volte che vuoi
Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato