DESIGNAZIONE:
Rappresenta una relazione tra due entità di tipo 1 ad M.
Esempio tipico è :
REPARTO ------- IMPIEGATO
(designata)
(designante)
Viene rappresentata inserendo, nella tabella dell’entità designante, una chiave esterna
che corrisponde alla chiave primaria della tabella della entità designata.
CARATTERISTICA:
Questa relazione ha lo scopo di “caratterizzare” un’entità tramite un’altra entità.
Tra le entità correlate esiste un rapporto di dipendenza-esistenza tra l’entità che
caratterizza e l’entità caratterizzata, dove esiste un rapporto di di 949g69j
pendenza-esistenza
Viene rappresentata inserendo nella tabella dell’entità designante una chiave esterna,
sempre significativa, che corrisponde alla chiave primaria della tabella designata.
Esempio tipico è:
FATTURA--------- MOVIMENTO
(designata)
(designante)
NOTA:
La differenza tra i due tipi di relazione è che nella caratteristica non si possono avere
valori nulli nella chiave esterna.
CONGRUENZA DEL DATABASE
Le principali problematiche che possono causare stati di errore in un DATABASE:
1.
L’INTEGRITA’
2.
LA SICUREZZA
3.
IL RECUPERO DA SITUAZIONI DI ERRORE (recovery)
4.
LA CONCORRENZA DI ACCESSO
E’ necessario introdurre i concetti di transazione, commit e rollback.
Lo scopo principale di un DBMS è quello di servire delle TRANSAZIONI.
Per transazione si intende un’unità logica elementare di elaborazione; è costituita da
una sequenza di istruzioni che formano una unità significativa di lavoro, cioè che
hanno significato se vengono eseguite globalmente. La sequenza di istruzioni che
compongono una transazione sono delimitate da due particolari istruzioni che
individuano l'inizio e la fine, che a sua volta può essere corretta e non corretta.
Questi due punti sono detti PUNTI DI SINCRONIZZAZIONE.
i comandi di commit e rollback sono comandi di sincronizzazione.
Un programma quindi può essere visto come una sequenza di transazioni
L’istruzione di Commit è una istruzione di convalida della istruzione o delle istruzioni
eseguite dall’ultimo commit e quindi prevede il vero aggiornamento sui dati (viene
eseguito a completamento della transazione , se ogni istruzione è completata
correttamente e si vogliono apportare le modifiche sul database).E’ chiamato “punto
di sincronizzazione”.
Al contrario l’istruzione di Rollback è lo storno delle istruzioni con ritorno automatico
tramite il LOG ai dati dell’ultimo commit (stato validato), è, quindi, il ripristino dei
vecchi valori, annullando tutte le variazioni apportate dall’ultimo punto di
sincronizzazione(viene effettuata a fine transazione se non si vogliono apportare le
modifiche sui dati).
Il DBMS gestisce un archivio dove vengono memorizzate tutte le variazioni sui dati
del DB ( dove sono registrate tutte le operazioni di modifica dei dati, cioè i valori
vecchi e nuovi);
viene chiamato file di LOG.
Per consistenza si intende la congruenza, la correttezza e la validità dei valori
presenti in un database ( cioè i dati devono essere significativi)
La consistenza dei dati è minacciata ogni volta che si verificano interventi sulla base
dei dati che danno luogo a modifiche dei valori: aggiornamenti, inserimenti o
cancellazioni. Valori non validi possono essere introdotti:
·
accidentalmente( guasti hardware o interventi dannosi da parte di utenti o
programmi) e quindi involontariamente
·
oppure deliberatamente ( da interventi dolosi sui dati dovuti ad accessi non
autorizzati)
Impedire aggiornamenti non validi, derivanti da errori non voluti, rientra nel problema
dell’ integrità.
Impedire che una operazione dolosa provochi un aggiornamento non valido dei dati
rientra nel problema della sicurezza.
L’INTEGRITA’ DEI DATI
Il DBMS deve contenere una componente che governi l'attività di corretto
aggiornamento dei dati .
La componente deve:
1.
Controllare le transazioni nell'attività di aggiornamento e verificare che non
avvengano violazioni della congruenza;
2.
Produrre effetti (segnalare) di ritorno nel caso in cui si origini uno stato di
incongruenza.
Per fare questo si devono dare una serie di regole (o vincoli), che saranno mantenute
su archivi speciali (dizionari dati tabelle di catalogo) sempre facenti parte del DBMS(
come un DB a parte getibile dal DBMS); in tali regole sono definiti quali errori è
necessario controllare, quando il controllo deve essere effettuato e quali azioni è
necessario intraprendere nel caso in cui si verifichino tali situazioni. Quindi nella fase
di progettazione si devono prevedere tali regole.
Le regole o vincoli sono:
1)
Vincoli di integrità di entità: questo vincolo viene mantenuto assicurandosi che
la chiave primaria di una relazione sia unica e non nulla
2)
Vincoli di integrità semantica o di dominio: riguarda il significato attribuito
ai dati, significato determinato dall’utente, la tipologia del dato, il range di
appartenenza, il formato
3)
Vincoli di integrità referenziale: che non riguardano un solo attributo o una
sola relazione, bensì i legami tra diverse relazioni, vincoli di aggiornamento di un
campo condizionato dai valori di altri campi. L'integrità referenziale viene
rispettata quando per ogni valore non nullo della chiave esterna esiste un valore
corrispondente della chiave primaria nella tabella associata.
Qualora i record fossero dipendenti da un altro record, non si possa annullare il
record padre se vi sono dei figli.
Vi sono due possibilità per mantenere questo vincolo:
·
Impedendo gli aggiornamenti che porterebbero ad uno stato non corretto
·
Accettando gli aggiornamenti ma eseguendo automaticamente, se necessario,
operazioni aggiuntive per il rispetto delle regole
INTEGRITA’ REFERENZIALE
E’ uno degli aspetti più importanti del modello relazionale.
L’integrità referenziale viene rispettata quando: per ogni valore non nullo della chiave
esterna, deve esistere un valore corrispondente della chiave primaria, nella tabella
associata (qualora i record fossero dipendenti da un altro record, non si può annullare
il record padre se vi sono dei figli).
Gli effetti che possono derivare da una cancellazione o da un aggiornamento di una
chiave primaria , presente come chiave esterna in altre tabelle, possono essere
ricondotte a tre tipologie:
1)
Effetto CASCATA: una cancellazione o un aggiornamento della chiave primaria
provoca la cancellazione o l’aggiornamento delle occorrenze presenti nelle tabelle
referenziate tramite chiave esterna.
2)
Effetto RESTRIZIONE: la cancellazione o l’aggiornamento devono essere inibite
se sono presenti occorrenze per il valore prescelto nelle tabelle correlate
3)
Effetto ANNULLAMENTO: la cancellazione o l’aggiornamento di un valore della
chiave primaria provoca un annullamento dei corrispondenti valori presenti nelle
chiavi esterne delle tabelle correlate. (da non utilizzare nel caso di caratteristica)
Gli effetti che possono derivare da una operazione di inserimento o di aggiornamento
di una chiave esterna possono essere:
1) se il valore della chiave esterna non è presente come chiave primaria nella tabella
correlata non sarà permessa
2)
se il valore della chiave esterna è nullo allora sarà possibile effettuarla ( da non
usare nel caso di caratteristica )
ESEMPIO IN DB2: quando si crea la tabella
.......PRIMARY KEY (...)
FOREIGN KEY(...)
ON DELETE
Oppure ON UPDATE ......
Oppure ON INSERT .......
DELETE: nel caso di cancellazione di chiavi primarie, le chiavi ad esse riferite possono
essre soggette ad uno degli effetti Cascata, restrizione, annullamento.
INSERT: nel caso di inserimento su tabelle contenenti chiavi esterne, i valori che
queste possono assumere o sono già presenti come chiavi primarie, nelle tabelle
riferite, oppure devono essere NULL
UPDATE: si devono distinguere due casi:
·
se viene aggiornata una chiave esterna, questo aggiornamento deve soddisfare
gli stessi vincoli della regola INSERT
·
se viene aggiornata una chiave primaria, le chiavi esterne ad essa riferite
possono essere soggette ad uno degli effetti Cascata, Restrizione, Annullamento
LA SICUREZZA (SECURITY)
Protezione da interventi accidentali o non autorizzati che potrebbero portare ad
aggiornamenti non validi.
Il sottosistema di gestione della sicurezza di un DBMS si deve basare sulle seguenti
funzioni:
1.
identificazione dell'utilizzatore( USERID)
2.
autenticazione dell'utilizzatore(PASSWORD)
3.
controllare le regole di autorizzazione dell'operazione richiesta(autorizzazioni)
Quindi il DBMS avrà al suo interno tabelle dove sono inserite tali regole(tabelle di
catalogo). Nella fase di progettazione si dovranno considerare tali regole. Come si
danno le autorizzazioni: le istruzioni di GRANT e REVOKE.
GRANT privilegi TO authid (WITH GRANT OPTION)
Privilegi:
·
di sistema (SYSADM,CREATE DBA,…)
·
di utilizzo (USE OF BUFFERPOOL, STOGROUP, TABLESPACE,…)
·
di accesso (ALTER, SELECT, INSERT, …. ON TABLE….)
·
di gestione (CREATE TAB , LOAD,…. ON DATABASE…)
LA CONCORRENZA DI ACCESSO
Nel caso di multiutenza il DBMS deve governare la concorrenza di più accessi da parte
di transazioni differenti.
Per garantire una costante integrità del Database in multiutenza, il sottosistema che
controlla gli accessi deve realizzare una serializzazione delle transazioni, che
riconduce la multiutenza ad una monoutenza. La tecnica è quella di forzare dei blocchi
temporali sui record oggetto di aggiornamento (LOCKING). Il blocco (LOCK) quindi
determina l'attesa da parte di altre transazioni che vogliono fare aggiornamenti su
tali record.
Ci sono due tipi di blocco:
·
blocco per aggiornamento (EL=exclusive lock)
·
blocco per sola lettura (SL=Shared lock)
RECUPERO DA SITUAZIONI DI ERRORE
Un DBMS deve avere una componente che permette di superare il verificarsi di
situazioni di errore.
Il recovery viene realizzato tornando all'ultimo stato valido del DB, quindi si basa
sulla possibilità di ricordare tutte le informazioni che hanno determinato variazioni
Inoltre devono esistere copie logiche del DB (image copy) che devono essere fatte
periodicamente (es: ad inizio e fine giornata).
Oltre a queste copie logiche devono esistere anche copie fisiche(backup) periodiche
dei dischi che contengono il DB.
Se si verifica un errore le possibili cause sono:
1.
il DATABASE è danneggiato fisicamente; allora partendo dall’ultima copia
disponibile, si utilizza il LOG per riproporre tutte le variazioni fino al momento
dell’errore
2.
il DATABASE ha riportato errori logici: non è danneggiato fisicamente ma
presenta incongruenza nei valori a causa di aggiornamenti non validi; allora il
DATABASE può essere riportato, utilizzando l’archivio di LOG , all’ultima
situazione di congruenza.( il LOG viene utilizzato all'indietro facendo i rollback
necessari fino a tornare ad una situazione valida es. dando il giorno e l'ora)
Se durante l'esecuzione di una transazione si verifica un errore (es. errore nella
operazione di registrazione) allora verrà mandato un messaggio di errore e verrà
applicato il LOG per ripristinare il contenuto del DB.
Con il meccanismo del (TWO-FASE COMMIT), cioè istruzione di commit ad inizio e
fine transazione, si possono evitare gli stati non validi nel caso che la transazione non
è stata ultimata per errori hardware
PROGETTAZIONE DATABASE IN AMBIENTE RELAZIONALE
La progettazione può essere distinta in due fasi:
1)
progettazione logica= disegno della struttura logica del DB, come modello della
realtà
2)
progettazione fisica= scelta e messa a punto del tipo di archiviazione fisica dei
dati
PROGETTAZIONE LOGICA
Vi sono due fasi:
1) disegno dello schema concettuale(modello entità-relazioni)
2) disegno delle schema logico (definizione delle tabelle, attributi, chiavi, domini delle
entità e delle relazioni individuate nella fase precedente)
PROGETTAZIONE DELLO SCHEMA CONCETTUALE
La definizione delle schema concettuale può essere realizzata analizzando la realtà
che si
vuole schematizzare secondo due approcci:
1)
APPROCCIO SINTETICO ; TOP-DOWN
2)
APPROCCIO ANALITICO; BOTTOM-UP
L’APPROCCIO TOP-DOWN
I passi :
1)
individuazione delle entità di base
2)
individuazione delle associazioni (N:M)
3)
individuazione delle designazioni (1:M)
4)
individuazione delle caratteristiche (1:M)
5)
individuazione delle proprietà( attributi, domini, chiavi, ..ecc)
6)
iterazione sui passi precedenti fino ad ultimazione del disegno.
Il passaggio dallo schema concettuale allo schema logico verrà effettuato come già
visto per il passaggio dallo schema concettuale al disegno degli archivi nella
programmazione tradizionale.
L’APPROCCIO BOTTOM-UP
Questo tipo di approccio, proposto da Codd, parte da un’analisi dei dati elementari e
attraverso un processo di aggregazione, arriva alla formulazione delle tabelle che
rappresentano le entità e le possibili correlazioni.
Attraverso il meccanismo della NORMALIZZAZIONE si potrà passare dai dati
elementari alle tabelle.
METODOLOGIA MISTA
Proposta da Date, prevede due fasi:
1)
2)
progettazione TOP-DOWN per il disegno dello schema concettuale
verifica del disegno concettuale attraverso il processo di
Normalizzazione(BOTTOM-UP)
Documentazione della progettazione:
Una forma standard di documentazione di ciò che si progetta è fondamentale e deve
soddisfare le seguenti esigenze:
·
evidenziare in dettaglio i risultati della progettazione
·
contenere un ridotto numero di forme di evidenziazione
·
essere molto vicina al formalismo della progettazione fisica
