• 1 a N nella seconda tabella inseriamo il codice della prima, la cosiddetta CHIAVE ESTERNA
• N a N si crea una terza tabella in cui andremo a mettere le chiavi primarie delle due tabelle e una chiave primaria della tabella stessa

Se invece l'approccio utilizzato è stato di tipo BOTTOM-UP si procede alla conversione attraverso la normalizzazione.

NORMALIZZAZIONE: procedimento che consente di verificare se la definizione dello schema corrisponde a dei canoni standard e, in caso necessario, riportare le tabelle in quelle che sono definite le forme normali delle tabelle relazionali.

• 1 FORMA NORMALE: rispetta requisiti del modello relazionale e ogni campo sia un campo semplice, quindi non composto.
• 2 FORMA NORMALE: se è in 1 forma normale e ogni attributo non chiave dipende dalla chiave primaria funzionalmente e completamente.
• 3 FORMA NORMALE: se è in 2 forma normale e se ogni attributo non chiave dipende direttamente dalla chiave primaria, cioè ogni attributo non chiave non dipende funzionalmente da altri attributi non chiave.

Una volta definite le tabelle potranno essere effettuate le seguenti operazioni:

OPERAZIONI INSIEMISTICHE

• Unione:  relazione che si ottiene dall'unione insiemistica di due relazioni quindi non ci sono duplicati.
• Intersezione:  restituisce la relazione contenente tutte le tuple presenti sia in A che in B.
• Sottrazione: relazione data dalla differenza insiemistica delle due relazioni

OPERAZIONI RELAZIONALI

• Selezione: Relazione contenente le tuple che soddisfano una determinata condizione
• Proiezione: Relazione che si ottiene considerando solo le colonne di A relative agli attributi contenuti in B eliminando i duplicati
• Congiunzione (join): Relazione con le informazioni di A e B con un attributo in comune

Le principali problematiche che possono causare stati di errore in un DATABASE:

L'INTEGRITA'

LA SICUREZZA

IL RECUPERO DA SITUAZIONI DI ERRORE (recovery)

LA CONCORRENZA DI ACCESSO

• Integrità: un componente che controlli gli aggiornamenti dei dati, cioè non permetta aggiornamenti non validi.(cancellazione e modifica) e segnali incongruenze. Le regole e i vincoli sono:

Vincoli di integrità di entità: questo vincolo viene mantenuto assicurandosi che la chiave primaria di una relazione sia unica e non nulla

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

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.

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:

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.

Effetto RESTRIZIONE: la cancellazione o l'aggiornamento devono essere inibite se sono presenti occorrenze per il valore prescelto nelle tabelle correlate

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 si hanno su delete, insert e update.

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:

identificazione dell'utilizzatore( USERID)

autenticazione dell'utilizzatore(PASSWORD)

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.

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:

il DATABASE è danneggiato fisicamente; allora partendo dall'ultima copia disponibile, si utilizza il LOG per riproporre tutte le variazioni fino al momento dell'errore

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