Sei sulla pagina 1di 10

1

DBMS - DAL MODELLO LOGICO A QUELLO RELAZIONALE (MODELLO TAPIOCA A SUBSTRATO CONCETTUALE)

Dopo aver individuato le entità che descrivono le informazioni della realtà di cui si vuole creare un modello, i loro attributi e le associazioni che le legano, e avere rappresentato i risultati ottenuti in uno schema E/R, si può considerare conclusa la fase di progettazione concettuale del database. Si passa quindi alla fase di progettazione logica, in cui il risultato ottenuto dalla precedente fase progettuale è ulteriormente trasformato, per ricavare l’elenco delle strutture dei dati (come devono essere organizzati i dati che formano il database) che devono poi essere fisicamente implementate in memoria di massa (fase di progettazione fisica).

La fase di progettazione logica consiste nell’analisi delle informazioni riguardanti le entità, gli attributi e le associazioni fornite dallo schema concettuale E/R, per trasformarle, attraverso un procedimento di conversione chiamato MAPPING, in un insieme di strutture dati chiamato schema logico. Riassumendo, lo scopo della fase di progettazione logica è quello di produrre uno schema logico, in accordo al modello dei dati scelto, che rappresenti fedelmente l’informazione descritta da uno schema E-R (prodotto nella fase di progettazione concettuale)

Mentre la progettazione concettuale focalizza la sua attenzione sul modello astratto dei dati (non ci importa come i dati devono essere organizzati, in che modo devono essere messi insieme e memorizzati), ed è quindi del tutto indipendente dal tipo di tecnologia utilizzata dal DBMS scelto per l’implementazione del database, la progettazione logica ne fa invece esplicito riferimento, con particolare riguardo al modello logico di rappresentazione dei dati associato. Il modello logico di rappresentazione dei dati che in questo momento è adottato dalla quasi totalità dei DBMS in commercio, sia per PC che per Mainframe, è il modello logico relazionale e noi ci occuperemo solo di questo modello logico di rappresentazione dei dati. SQL Server, Oracle, MySQL, Access, sono tutti DBMS relazionali, cioè programmi per la gestione dei database che gestiscono le informazioni secondo le proprietà e le caratteristiche del modello logico relazionale. Poiché, come abbiamo appena detto, la fase di progettazione logica si adatta al modello dei dati al quale si riferisce il DBMS a disposizione, nel nostro caso relazionale, d’ora in poi indicheremo lo schema logico che otterremo al termine della progettazione logica come schema logico relazionale. Il modello relazionale struttura la realtà come un insieme di RELAZIONI che noi rappresentiamo, per semplicità, come tabelle costituite da tante righe, chiamate ennuple o tuple, in cui ogni riga è costituita da un insieme di valori semplici, appartenenti ognuno ad un certo dominio, che corrispondono agli attributi della tabella. Per ogni Relazione, o Tabella, si definisce un grado ed una cardinalità:

Il grado di una relazione, o tabella, è il numero di domini su cui è costruita. La cardinalità di una relazione, o tabella, indica il numero di ennuple che la costituiscono in un certo istante.

Riferendoci alla relazione rappresentata come una tabella, possiamo dire che il grado è il numero d’attributi, di colonne, che compongono la tabella, mentre la cardinalità è il numero di righe che compongono la tabella in un certo istante.

-
-
di righe che compongono la tabella in un certo istante. - Il Dominio di un attributo

Il Dominio di un attributo D i è l’insieme dei possibili valori dell’attributo D i

-
-

ad esempio nella tabella Studenti (Corso, Matricola, Voto) Dim (Voto) = {18,19,…,30}

L’ordine delle ennuple in una relazione, o tabella, è irrilevante. Nel modello relazionale, per convenzione, una relazione è descritta attraverso il suo identificatore seguito, tra parentesi tonde, dall’elenco degli identificatori dei suoi attributi, sottolineando con una linea continua gli attributi che costituiscono la sua chiave primaria.

dei suoi attributi, sottolineando con una linea continua gli attributi che costituiscono la sua chiave primaria

2

Riassumendo, nel modello relazionale dei dati, una relazione gode delle seguenti proprietà:

È costituita da un insieme di lunghezza finita di elementi detti ennuple (tuple o righe)

Le ennuple sono tra di loro omogenee, presentano cioè la stessa struttura

Gli attributi sono tutti di tipo semplice, definiti su un determinato dominio

Tutte le ennuple sono diverse tra loro e quindi deve essere definita una chiave primaria

L’ordine delle ennuple nella relazione è irrilevante

GESTIONE DELLE ASSOCIAZIONI TRA ENTITA’ NEL MODELLO RELAZIONALE.

Abbiamo detto che il modello relazionale struttura la realtà in un insieme di relazioni; lo schema logico relazionale che si ricava al termine della progettazione logica è esattamente costituito dall’insieme delle relazioni, o tabelle, che modellano la realtà in esame. Dovremmo pertanto avere, tante Relazioni, o Tabelle, quante sono le Entità individuate nello schema concettuale E/R. Ma attenzione, come faccio nel modello logico a tener conto (a prendere in considerazione) delle associazioni tra le Entità presenti nel modello E/R? In che modo ne teniamo conto nel modello logico relazionale? Nel modello logico relazionale, le associazioni tra le Entità sono implementate attraverso l’introduzione del concetto di chiave esterna, il cui utilizzo ed impiego è fondamentale durante il processo di MAPPING.

Una chiave esterna (foreign key) di una Relazione, o Tabella, è un attributo o un insieme di attributi che non ha solitamente funzione di chiave primaria della relazione in cui compare, ma è invece chiave primaria in un’altra relazione alla quale è legata attraverso un’associazione nello schema concettuale E/R. La chiave esterna e la chiave primaria devono essere definite su dominio comune.

LE REGOLE DI DERIVAZIONE DELLO SCHEMA LOGICO RELAZIONALE

Passiamo adesso ad esaminare ed elencare alcune semplici regole a cui attenerci per passare dal modello concettuale E/R al modello logico relazionale attraverso l’operazione che abbiamo chiamato di MAPPING. Cominceremo dalla conversione delle entità e dei rispettivi attributi, con particolare attenzione agli attributi non semplici. Quindi passeremo in rassegna le regole di derivazione per le associazioni 1:1, 1:N, N:M

Mapping delle Entità e degli attributi: le Entità che fanno parte dello schema concettuale vengono trasformate in Relazioni, o Tabelle; per quanto riguarda la chiave, la chiave primaria dell’Entità diventa anche chiave primaria della Relazione, o Tabella. Per quanto riguarda

gli Attributi, solo quelli semplici (o elementari) sono automaticamente elencati tra quelli che costituiscono la Relaziona, o Tabella. Per gli attributi non semplici (o non elementari) si procede nel seguente modo:

o Attributi composti: sono sostituiti con l’elenco degli attributi semplici componenti

o Attributi multipli: sono sostituiti con la creazione di una o più nuove relazioni Per capire meglio facciamo i seguenti esempi. Consideriamo per prima l’Entità STUDENTI con un attributo composto:

per prima l’Entità STUDENTI con un attributo composto : Essa si trasforma nella Relazione STUDENTI (Matricola,

Essa si trasforma nella Relazione

STUDENTI (Matricola, Cognome, Nome, Classe, Sezione, Specializzazione)

L’attributo composto ClasseFRequentata è stato sostituito con la coppia di attributi semplici Classe e Sezione. Come secondo esempio, consideriamo l’Entità INSEGNANTI con un attributo multiplo:

l’Entità INSEGNANTI con un attributo multiplo : Essa si trasforma nelle Relazioni INSEGNANTI

Essa si trasforma nelle Relazioni

INSEGNANTI (CodiceInsegnante, Cognome, Nome, Indirizzo, AnniServizio) INSEGNANO (CodiceInsegnante, CodiceMateria) MATERIE (CodiceMateria, NomeMateria)

L’attributo Materie dell’Entità INSEGNANTI è di tipo multiplo, in quanto uno stesso insegnante può insegnare più di una materia. Nello schema logico quest’attributo non compare più nella Relazione INSEGNANTI ma si trasforma nelle nuove Relazioni INSEGNANO e MATERIE. La Relazione MATERIE è costituita dall’attributo CodiceMateria che ha la funzione di chiave primaria e dall’attributo NomeMateria; la Relazione INSEGNANO (CHE NASCE DALLASSOCIAZIONE M:N CHE SI GENERA TRA INSEGNANTI E MATERIE) è costituita dalla coppia di attributi (CodiceInsegnante, CodiceMateria) con funzione di chiave primaria composta e, singolarmente, di chiavi esterne per il collegamento logico con le rispettive relazioni.

Mapping delle associazioni 1:1 : Nello schema logico relazionale, un’associazione 1:1 tra due Entità porta, nella maggior parte dei casi, alla creazione di un’unica Relazione, cioè gli attributi di una delle 2 Entità migrano nella Relazione più importante dal punto di vista della progettazione e la chiave primaria diventa quindi unica. Per capire meglio facciamo il seguente esempio, consideriamo le Entità IMPIEGATI e CONIUGI, collegate tramite l’Associazione ConiugatiCon

3

3 Esse si trasformano nella Relazione IMPIEGATI (CodiceImpiegato, Cognome, Nome, Mansione, CognomeConiuge, NomeConiuge)

Esse si trasformano nella Relazione

IMPIEGATI (CodiceImpiegato, Cognome, Nome, Mansione, CognomeConiuge, NomeConiuge)

Gli attributi dell’Entità CONIUGI sono migrati in IMPIEGATI e si è mantenuta come chiave primaria quella sull’Entità IMPIEGATI. La PARZIALITÀ dell’Associazione ConiugatiCon , dovuta al fatto che un impiegato può anche non essere coniugato, è implementata

RENDENDO GLI ATTRIBUTI COGNOMECONIUGE E NOMECONIUGE OPZIONALI, in modo che possano assumere anche un valore nullo.

Questo è quello che avviene quasi sempre quando abbiamo Associazioni 1:1. Non sempre però il MAPPING di un’Associazione binaria 1:1 porta alla creazione di un’unica Relazione; può infatti essere utile, al fine dell’ottimizzazione del modello logico, mantenere nello schema logico le due Relazioni derivanti dalle due Entità associate, accomunate dalla stessa chiave primaria che funge anche da chiave esterna per entrambe le Relazioni. Per capire meglio facciamo un esempio. Consideriamo le Entità PAZIENTI e CARTELLECLINICHE, collegate tramite l’associazione Posseggono

collegate tramite l’associazione Posseggono Esse si trasformano nelle Relazioni: PAZIENTI (

Esse si trasformano nelle Relazioni:

PAZIENTI (CodicePaziente, Cognome, Nome, …. ) CARTELLE CLINICHE (CodicePaziernte, DataRicovero, …. )

In questo caso visto che entrambe le Entità (PAZIENTI e CARTELLECLINICHE) potrebbero presentare un numero elevato di attributi e la gestione della Relazione (o Tabella) unica potrebbe quindi pesante, è preferibile mantenere distinte le Entità in 2 Relazioni diverse con gli stessi valori di chiave primaria / chiave esterna CodicePaziente (CodicePaziente in entrambe le Relazioni è sia chiave primaria che chiave esterna). Di seguito vediamo altri due esempi

che chiave esterna). Di seguito vediamo altri due esempi ∑ Mapping delle associazioni 1:N : Nello

Mapping delle associazioni 1:N : Nello schema logico relazionale, le Associazioni binarie di grado 1:N sono convertite nelle corrispondenti 2 Relazioni relative alle 2 Entità collegate, aggiungendo, nella Relazione relativa all’Entità che si trova sul lato N dell’Associazione, un attributo con funzione di chiave esterna, corrispondente alla chiave primaria dell’altra Relazione collegata. Per capire meglio facciamo il seguente esempio. Consideriamo le Entità STUDENTI e FACOLTA’ collegate tramite l’associazione Frequentano

e FACOLTA’ collegate tramite l’associazione Frequentano Si trasforma nelle Relazioni STUDENTI (Matricola, Cognome,

Si trasforma nelle Relazioni

STUDENTI (Matricola, Cognome, Nome, Indirizzo, CodiceFacoltà) FACOLTA’ (CodiceFacoltà, Denominazione, Preside)

STUDENTI (Matricola, Cognome, Nome, Indirizzo, CodiceFacoltà ) FACOLTA’ (CodiceFacoltà, Denominazione, Preside)

4

L’Entità che si trova sul lato N dell’Associazione è STUDENTI, quindi la Relazione corrispondente vedrà aggiunta ai suoi attributi la chiave esterna CodiceFacoltà, che serve per implementare nel modello logico relazionale il collegamento della Tabella (o della Relazione) STUDENTI con la Tabella (o con la Relazione) FACOLTA’.

STUDENTI con la Tabella (o con la Relazione) FACOLTA’. Facciamo adesso un altro esempio di chiave

Facciamo adesso un altro esempio di chiave esterna

Facciamo adesso un altro esempio di chiave esterna consideriamo infine il caso di sotto in cui

consideriamo infine il caso di sotto in cui l’associazione 1:N contiene un attributo:

di sotto in cui l’associazione 1:N contiene un attributo : Chiave composta Si trasforma nello schema
di sotto in cui l’associazione 1:N contiene un attributo : Chiave composta Si trasforma nello schema

Chiave

composta

Si trasforma nello schema logico seguente

: Chiave composta Si trasforma nello schema logico seguente Ritorniamo adesso al caso di rappresentazione di

Ritorniamo adesso al caso di rappresentazione di un attributo multiplo (trattato e sviluppato in precedenza a pagina 2) quando passiamo dal modello concettuale al modello logico

2) quando passiamo dal modello concettuale al modello logico ∑ Mapping delle associazioni M:N : Nello

Mapping delle associazioni M:N : Nello schema logico relazionale, le Associazioni binarie di grado M:N sono convertite nelle corrispondenti 2 Relazioni relative alle 2 Entità collegate, aggiungendo, una nuova Relazione in cui migrano le chiavi primarie delle 2 Entità associate che svolgeranno il ruolo di chiavi esterne e, nella gran parte dei casi, anche di chiave primaria composta della nuova Relazione. La nuova Relazione prenderà il nome dell’Associazione implementata. Se l’Associazione inoltre presenta degli attributi, anch’essi migreranno nella nuova Relazione. Per capire meglio facciamo il seguente esempio. Consideriamo le Entità DOTTORI e PAZIENTI collegate tramite l’associazione Curano

meglio facciamo il seguente esempio. Consideriamo le Entità DOTTORI e PAZIENTI collegate tramite l’associazione Curano

5

Si trasforma nelle Relazioni

DOTTORI (CodiceDottore, CognomeD, NomeD, Specializzazione) PAZIENTI (CodicePaziente, CognomeP, NomeP, Indirizzo) CURANO (CodiceDottore, CodicePaziente)

Esaminando lo schema logico ricavato, notiamo l’introduzione di una Relazione aggiuntiva, CURANO, in cui sono migrati gli attributi chiave delle 2 Entità collegate dall’Associazione M:N . Questi attributi avranno non solo la funzione di chiavi esterne ma, nel caso considerato, costituiranno la sua chiave composta. Attenzione !!!!!!!! guardiamo la Relazione CURANO e pensiamo ad un archivio storico, che succede in questo caso? Se parliamo d’archivio storico vuol dire che è importante mantenere traccia anche delle cure precedenti e la Relazione CURANO diventa

CURANO (CodiceDottore, CodicePaziente, DataInizioCura)

In questo caso si potrebbe verificare la situazione in cui i valori della coppia CodiceDottore + CodicePaziente si ripetano uguali più di una volta nella tabella (nella Relazione), in quanto un paziente potrebbe essere stato curato dallo stesso dottore più volte in date diverse.

Dottori

CodiceDottore

CognomeD

NomeD

Specializzazione

   

D001

Baracco

Michele

 

 

D002

Bessone

Fabia

 

 

D003

 

Gallo

Lorella

 

 

Pazienti

CodicePaziente

CognomeP

NomeP

Indirizzo

 
 

P001

DellaCasa

Luisa

P002

Vallauri

Sandra

P003

Boffetti

Carlo

P004

Tropeano

 

Elisa

 

Curano

CodiceDottore

CodicePaziente

DataInizioCura

 

D001

P002

   

17/06/2006

D003

P003

   

19/06/2006

D003

P002

   

19/06/2006

D001

P002

   

21/06/2006

D001

P004

   

21/06/2006

D002

P003

   

22/06/2006

In questo caso, la coppia di attributi CodiceDottore + CodicePaziente non è assolutamente più utilizzabile come chiave primaria composta della Relazione CURANO. L’unica chiave candidata possibile è quella composta da tutti e 3 gli attributi CodiceDottore + CodicePaziente + DataInizioCura, ma è troppo lunga ed in questi casi, per motivi di praticità, è consigliabile aggiungere come chiave primaria della Relazione CURANO una chiave artificiale, ad esempio un attributo progressivo identificato da NumeroCura, che consente così di avere lo storico delle cure. La nuova soluzione sarà pertanto:

DOTTORI (CodiceDottore, CognomeD, NomeD, Specializzazione) PAZIENTI (CodicePaziente, CognomeP, NomeP, Indirizzo) CURANO (NumeroCura, CodiceDottore, CodicePaziente, DataInizioCura)

Vediamo un altro esempio

Partecipare
Partecipare

6

elemento che avvengono su una base di dati, devono essere eseguite rispettando un insieme di regole che servono a non compromettere l’integrità dei dati (con integrità dei dati intendiamo la validità, la significatività dei dati). L’integrità dei dati è assicurata dal DBMS (da Access) che prevede la possibilità di dichiarare opportune regole di validazione. Per capire meglio consideriamo la relazione (la tabella) Studente che contiene le informazioni anagrafiche relative ad uno studente. Supponiamo che l’attributo Matricola sia un numero progressivo che identifica esattamente quello studente.

STUDENTE

Nominativo

Matricola

EsamiSvolti

 

Rossi

2345

17

Bianchi

7628

2500

Neri

7628

15

Notiamo che l’attributo EsamiSvolti del nominativo Bianchi ha un valore pari a 2500 (cosa impossibile, in nessuna facoltà gli esami da svolgere per conseguire la laurea potrà essere in numero 2500). Dal punto di vista delle definizioni, questa relazione è corretta (2500 è un numero, quindi è un valore appartenente al dominio degli interi), ma non ha molto senso da un punto di vista pratico nella realtà presa in esame (gli esami svolti da uno studente universitario). Nella relazione Studente ci sono, inoltre, due tuple che hanno lo stesso valore per il numero di matricola: anche qui dal punto di vista strutturale è tutto lecito, ma non è possibile poiché ogni studente deve avere un PROPRIO UNICO numero di matricola (Matricola è la CHIAVE PRIMARIA della relazione). Per specificare il fatto che alcune relazioni sono corrette dal punto di vista di chi sviluppa l’applicazione e altre non lo sono,dobbiamo introdurre il concetto di VINCOLO DI INTEGRITÀ:

Possiamo definire vincolo di integrità una proprietà che deve essere soddisfatta dalle istanze (dalle tuple, dalle righe, dai record) che rappresentano informazioni corrette per l’applicazione che utilizza la base di dati. I vicoli di integrità sono regole che devono essere verificate, che devono essere soddisfatte, affinché siano ritenute valide le informazioni memorizzate nella base di dati.

Esempi di vincoli di integrità sono:

- Il voto deve essere compreso tra 18 e 30

- La lode può apparire solo se voto = 30

- Ogni studente deve avere un numero di matricola

- Il numero di matricola di uno studente deve essere univoco

Una istanza di una relazione pertanto, per essere corretta, non basta che sia sintatticamente corretta rispettando le proprietà dei campi che la costituiscono, ma deve essere corretta anche per l’applicazione particolare che utilizza quella base di dati non assumendo valori non significativi per l’applicazione e questo lo facciamo attraverso i vincoli di integrità: nel nostro esempio di sopra dovremmo quindi specificare un vincolo di integrità che ci dica che EsamiSvolti non può essere 2500 (per esempio se per il Corso di Laurea che stiamo considerando gli Esami complessivi da sostenere sono 24 allora EsamiSvolti < 25), analogamente un altro vincolo di integrità imporrà che non possono esserci due studenti con lo stesso numero di matricola (questo è quello che facciamo automaticamente quando diciamo che Matricola è chiave primaria).Possiamo classificare i vincoli di integrità in:

Vincoli intrarelazionali o VINCOLI INTERNI, che sono quei vincoli DEFINITI ALLINTERNO di una singola relazione. Possono essere divisi in:

 

o

Vincoli su singola ennupla

 

Sul dominio degli attributi: sono quei vincoli che coinvolgono un solo attributo il cui soddisfacimento può essere verificato facendo riferimento ad un singolo valore alla volta; Su più attributi: sono quei vincoli che coinvolgono più attributi, ma sempre di ciascuna ennupla indipendentemente dalle altre;

 

o

Vincoli su più ennuple, che coinvolgono i valori di più ennuple. Rientrano in questo tipo i vincoli di chiave primaria (cioè le tuple presenti in una relazione devono essere tutte diverse tra loro).

Vincoli interrelazionali o VINCOLI ESTERNI, che sono quei vincoli DEFINITI TRA più relazioni. Rientrano in questa categoria i vincoli referenziali.

Per capire meglio facciamo adesso alcuni esempi, consideriamo per prima la seguente relazione:

Dipendente (Matricola, StipendioLordo, Trattenute, DataAssunzione, DataNascita)

Possiamo individuare i seguenti vincoli intrarelazionali su singola ennupla:

1. StipendioLordo > 0 2. DataAssunzione > DataNascita 3. Trattenute > 0 I vincoli 1 e 3 sono vincoli di dominio (come lo era EsamiSvolti < 25 dell’esempio precedente); il vincolo 2 è invece un vincolo su più attributi (DataAssunzione e DataNascita). Consideriamo ora la seguente base di dati:

7

7 ∑ Nella prima tupla della relazione ESAMI abbiamo un voto pari a 36 che, nel

Nella prima tupla della relazione ESAMI abbiamo un voto pari a 36 che, nel sistema italiano non è ammissibile, in quanto i voti universitari devono essere compresi tra 18 e 30. Dobbiamo quindi introdurre nella relazione ESAMI il vincolo interno sulla singola ennupla sul dominio dell’attributo (18<=Voto<=30)

Nella seconda tupla ancora della relazione ESAMI viene indicato che è stata attribuita la lode in un esame il cui voto è 28, ma la lode può essere attribuita solo se il voto è 30. Dobbiamo quindi introdurre nella relazione ESAMI il vincolo interno sulla singola ennupla su più attributi (NOT(Lode=’lode’))OR(Voto=30) , cioè è ammissibile la lode solo se il voto è pari a 30 (dicendo che o non c’è la lode, oppure il voto è pari a 30)

Le ultime due tuple della relazione STUDENTI contengono informazioni su 2 studenti diversi con lo stesso numero di matricola:

impossibile in quanto matricola chiave primaria, vincolo di chiave primaria

La quarta tupla della relazione ESAMI presenta per l’attributo Studente, un valore che non compare fra i numeri di matricola nella relazione STUDENTI: anche questa è una situazione indesiderabile, poiché i numeri di matricola ci forniscono informazioni solo come tramite verso le corrispondenti tuple della relazione STUDENTI (vincoli esterni, vincoli referenziali). Analogamente, la prima tupla presenta un codice di corso che non compare nella relazione CORSI.

Consideriamo infine questi altri esempi:

Un esempio di vincolo intrarelazionale su più ennuple è stato visto nell’esempio iniziale: uno studente non può avere lo stesso numero di matricola di un altro studente. Questo è un vincolo di chiave primaria.

Consideriamo l’attributo NumeroPagine dell’entità Libro, in questo caso abbiamo la presenza di un vincolo interno sul dominio dell’attributo (NumeroPagine > 0), il vincolo d’integrità consiste nell’impossibilità di assegnare all’attributo NumeroPagine un valore negativo o uguale a 0.

Consideriamo l’attributo ClasseFrequentata dell’entità Studenti e supponiamo che le tipologie di classi presenti nella scuola in esame (supponiamo si tratti di una scuola media) siano solo I, II, III; anche in questo caso siamo in presenza di un vincolo interno sul dominio dell’attributo (ClasseFrequentata può essere solo I oppure II oppure III), il vincolo d’integrità consiste nell’impossibilità di assegnare all’attributo ClasseFrequentata un valore che non rispetta la regola specificata.

Supponiamo come ultimo esempio di avere due distinte entità: l’entità Clienti, le cui istanze descrivono le informazioni sui clienti di una banca, con l’attributo Saldo, corrispondente alla cifra ala momento disponibile sul conto corrente del cliente, e l’entità Movimenti, le cui istanze descrivono le informazioni riguardanti i prelievi e i depositi dei clienti, con l’attributo ImportoMovimentato corrispondente alla cifra oggetto del movimento bancario. Introducendo una nuova istanza di tipo Prelievo nell’entità Movimenti (cioè se faccio un nuovo prelievo), deve essere rispettato il vincolo di integrità sull’attributo ImportoMovimentato, per cui il valore della cifra che si vuole prelevare deve essere inferiore al valore corrente dell’attributo Saldo che però è presente nell’istanza corrispondente al cliente nell’entità Clienti. In altre parole, il vincolo di integrità (vincolo di integrità esterno) impone che la cifra prelevata da un cliente non superi il suo capitale depositato in banca al momento attuale. Come si può constatare, questo vincolo di integrità coinvolge 2 attributi appartenenti a due entità diverse.

I vincoli di integrità ricavati dall’analisi di una situazione reale, vengono elencati in allegato allo schema E/R che si ricava al termine

della progettazione concettuale. SARANNO POI UTILIZZATI DURANTE LE SUCCESSIVE FASI, NELLA FASE DI DICHIARAZIONE DELLE TABELLE,

quando occorrerà fornire al DBMS tutte le informazioni necessarie alla loro creazione (il tipo di dato, il dominio, l’obbligatorietà o l’opzionalità, …), compresi eventuali vincoli di integrità da rispettare nella future gestione dei dati.

RAPPRESENTAZIONE DEI VINCOLI DI INTEGRITA’ Per rappresentare i vincoli di chiave primaria, sottolineiamo i relativi attributi (così come abbiamo fatto nel diagramma E/R). Per rappresentare gli altri vincoli ricorriamo ad un pseudolinguaggio ed usiamo la seguente sintassi

V<NumeroProgressivo>(<NomeRelazione>):<Espressione>

Dove

<NumeroProgressivo> è il numero progressivo del vincolo relativo alla relazione <NomeRelazione>

<Espressione> è una qualsiasi espressione in pseudolinguaggio che serve per specificare il vincolo che deve essere rispettato.

Se facciamo riferimento all’esempio di pag 2, quello dei vincoli sulla relazione Dipendente, scriveremo:

8

V2(Dipendente) : DataAssunzione > DataNascita V3(Dipendente) : Trattenute > 0 Per altri vincoli più complessi possiamo fare uso degli operatori aritmetici e logici come abbiamo fatto negli esempi di sopra, oppure nei casi più intricati al linguaggio naturale vero e proprio.

Infine per rappresentare i vincoli di integrità esterni, che sono quei vincoli definiti tra più relazioni (cioè i vincoli referenziali che abbiamo quando si introduce una chiave esterna) per capire meglio come rappresentarli facciamo riferimento al seguente schema relazionale

ARTICOLO (CodArt, Descrizione, Prezzo) FORNITORE (CodForn, Indirizzo, PartitaIva, Provincia, Tel) FORNISCE (CodFornitore, CodArticolo) Con VINCOLO DI INTEGRITÀ REFERENZIALE fra CodFornitore e la relazione FORNITORE, fra CodArticolo e la relazione ARTICOLO.

Con la frase di sopra, nella rappresentazione logica relazionale, abbiamo espresso con la giusta sintassi il VINCOLO ESTERNO DI INTEGRITÀ REFERENZIALE esistente tra la relazione FORNISCE e le relazioni FORNITORE ed ARTICOLO (abbiamo cioè detto che CodFornitore è la chiave esterna per collegare la relazione Fornisce con la relazione FORNITORE, CodArticolo è la chiave esterna per collegare la relazione Fornisce con la relazione ARTICOLO). Un articolo può essere fornito da più fornitori ed un fornitore fornisce più articoli.

da più fornitori ed un fornitore fornisce più articoli. Un esempio di inconsistenza dei dati si

Un esempio di inconsistenza dei dati si ha se dalla relazione Fornitori si cancella il fornitore con chiave F03. Nella relazione Fornisce infatti avremo la chiave esterna F03 alla quale non corrisponde alcun fornitore. Stesso discorso se si cancella un articolo. Per assicurare l’integrità referenziale, prima di cancellare una tupla occorre verificare che non ci siano tuple in altre relazioni che facciano riferimento alla tupla da cancellare. L’integrità referenziale è assicurata direttamente dal DBMS (per esempio da Access), che prevede la possibilità di dichiarare le regole di validazione attraverso appositi linguaggi dichiarativi. Tali regole vengono mantenute su sperciali archivi detti cataloghi delle regole (vincoli referenziali in cancellazione e modifica).

ESEMPIO FINALE

Per capire meglio facciamo, alla fine, un semplice esempio: analizziamo il database relativo ad una videoteca. Si vuole progettare una base di dati per una videoteca. La videoteca gestisce il noleggio di videocassette, dove ogni cassetta è caratterizzata da alcune informazioni generali e dai dati relativi agli attori con i rispettivi ruoli. Ogni videocassetta inoltre appartiene ad una o più categorie (film d’azione, romantico, …). Le cassette vengono noleggiate dai clienti, i quali devono aver richiesto ed ottenuto precedentemente una tessera che vale fino al termine dell’anno solare di emissione; i clienti sono pertanto identificati, in modo univoco, dal numero della tessera. Quando un cliente richiede una tessera, non è obbligato a noleggiare subito una cassetta. Nel momento in cui il cliente noleggia delle cassette, si apre un contratto di noleggio al quale sono associati il cliente e le cassette (almeno una) noleggiate. Si vuole avere disponibile sia la situazione dello stato di noleggio delle cassette, sia la descrizione completa di tutti i noleggi effettuati. Un cliente può restituire in date diverse le videocassette noleggiate con un unico contratto. Il modello E/R proposto dopo la fase di analisi, ottenuto dopo una attenta lettura del testo (cioè dopo una attenta fase di analisi dei dati significativi e delle richieste a cui deve soddisfare il database), è il seguente:

9

9 Vediamo, ora, lo schema logico relazionale derivante dal diagramma E/R di sopra : Tessera) Infine,

Vediamo, ora, lo schema logico relazionale derivante dal diagramma E/R di sopra:

Tessera)
Tessera)

Infine, sotto la relazione NOLEGGIO, va inserito il vincolo di integrità referenziale:

Con VINCOLO DI INTEGRITÀ REFERENZIALE fra Tessera e la relazione CLIENTE.

10

10