Database relazionali

Materie:Appunti
Categoria:Informatica
Download:522
Data:04.07.2007
Numero di pagine:8
Formato di file:.doc (Microsoft Word)
Download   Anteprima
database-relazionali_1.zip (Dimensione: 9.88 Kb)
trucheck.it_database-relazionali.doc     42.5 Kb
readme.txt     59 Bytes



Testo

DATABASE RELAZIONALI
DESIGNAZIONE:
Rappresenta una relazione tra due entità di tipo 1ad 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 dipendenza-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 { RESTRICT o CASCADE o SET NULL}
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) progettazione TOP-DOWN per il disegno dello schema concettuale
2) 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

Esempio