DDBMS - Sistemi di elaborazione delle transazioni

Questo capitolo discute i vari aspetti dell'elaborazione delle transazioni. Studieremo anche le attività di basso livello incluse in una transazione, gli stati della transazione e le proprietà di una transazione. Nell'ultima parte, esamineremo le pianificazioni e la serializzabilità delle pianificazioni.

Transazioni

Una transazione è un programma che include una raccolta di operazioni di database, eseguite come unità logica di elaborazione dei dati. Le operazioni eseguite in una transazione includono una o più operazioni di database come inserire, eliminare, aggiornare o recuperare dati. È un processo atomico che viene eseguito completamente o non viene eseguito affatto. Una transazione che coinvolge solo il recupero dei dati senza alcun aggiornamento dei dati è chiamata transazione di sola lettura.

Ogni operazione di alto livello può essere suddivisa in una serie di attività o operazioni di basso livello. Ad esempio, un'operazione di aggiornamento dei dati può essere suddivisa in tre attività:

• read_item() - legge l'elemento di dati dalla memoria alla memoria principale.

• modify_item() - modificare il valore dell'articolo nella memoria principale.

• write_item() - scrive il valore modificato dalla memoria principale alla memoria.

L'accesso al database è limitato alle operazioni read_item () e write_item (). Allo stesso modo, per tutte le transazioni, leggere e scrivere costituisce le operazioni di base del database.

Operazioni di transazione

Le operazioni di basso livello eseguite in una transazione sono:

• begin_transaction - Un indicatore che specifica l'inizio dell'esecuzione della transazione.

• read_item or write_item - Operazioni del database che possono essere interfogliate con le operazioni della memoria principale come parte della transazione.

• end_transaction - Un indicatore che specifica la fine della transazione.

• commit - Un segnale per specificare che la transazione è stata completata con successo nella sua interezza e non verrà annullata.

• rollback- Un segnale per specificare che la transazione non è andata a buon fine e quindi tutte le modifiche temporanee nel database vengono annullate. Una transazione confermata non può essere annullata.

Stati di transazione

Una transazione può passare attraverso un sottoinsieme di cinque stati, attiva, parzialmente confermata, confermata, fallita e interrotta.

• Active- Lo stato iniziale in cui entra la transazione è lo stato attivo. La transazione rimane in questo stato durante l'esecuzione di operazioni di lettura, scrittura o altre operazioni.

• Partially Committed - La transazione entra in questo stato dopo che è stata eseguita l'ultima istruzione della transazione.

• Committed - La transazione entra in questo stato dopo il completamento con successo della transazione e i controlli di sistema hanno emesso il segnale di commit.

• Failed - La transazione passa dallo stato parzialmente confermato o attivo allo stato non riuscito quando si scopre che la normale esecuzione non può più procedere o che i controlli di sistema falliscono.

• Aborted - Questo è lo stato dopo che è stato eseguito il rollback della transazione dopo un errore e il database è stato ripristinato allo stato precedente all'inizio della transazione.

Il seguente diagramma di transizione di stato descrive gli stati nella transazione e le operazioni di transazione di basso livello che provocano il cambiamento negli stati.

Proprietà desiderabili delle transazioni

Qualsiasi transazione deve mantenere le proprietà ACID, vale a dire. Atomicità, coerenza, isolamento e durata.

• Atomicity- Questa proprietà afferma che una transazione è un'unità atomica di elaborazione, ovvero viene eseguita nella sua interezza o non viene eseguita affatto. Non dovrebbe esistere alcun aggiornamento parziale.

• Consistency- Una transazione dovrebbe portare il database da uno stato coerente a un altro stato coerente. Non dovrebbe influire negativamente su alcun elemento di dati nel database.

• Isolation- Una transazione dovrebbe essere eseguita come se fosse l'unica nel sistema. Non dovrebbe esserci alcuna interferenza dalle altre transazioni simultanee in esecuzione simultaneamente.

• Durability - Se una transazione confermata determina una modifica, tale modifica deve essere durevole nel database e non deve essere persa in caso di errore.

Orari e conflitti

In un sistema con un numero di transazioni simultanee, a scheduleè l'ordine totale di esecuzione delle operazioni. Data una schedulazione S composta da n transazioni, diciamo T1, T2, T3 ……… ..Tn; per qualsiasi operazione Ti, le operazioni in Ti devono essere eseguite come previsto dallo schema S.

Tipi di orari

Esistono due tipi di pianificazioni:

• Serial Schedules- In una pianificazione seriale, in qualsiasi momento, solo una transazione è attiva, ovvero non vi è alcuna sovrapposizione di transazioni. Questo è illustrato nel grafico seguente:

• Parallel Schedules- Nelle pianificazioni parallele, più di una transazione è attiva contemporaneamente, ovvero le transazioni contengono operazioni che si sovrappongono nel tempo. Questo è illustrato nel grafico seguente:

Conflitti negli orari

In una pianificazione che comprende più transazioni, a conflictsi verifica quando due transazioni attive eseguono operazioni non compatibili. Si dice che due operazioni siano in conflitto, quando tutte le seguenti tre condizioni esistono simultaneamente:

• Le due operazioni fanno parte di transazioni diverse.

• Entrambe le operazioni accedono allo stesso elemento di dati.

• Almeno una delle operazioni è un'operazione write_item (), cioè cerca di modificare l'elemento di dati.

Serializzabilità

UN serializable scheduledi "n" transazioni è una pianificazione parallela che è equivalente a una pianificazione seriale che comprende le stesse "n" transazioni. Una pianificazione serializzabile contiene la correttezza della pianificazione seriale mentre si accerta un migliore utilizzo della CPU della pianificazione parallela.

Equivalenza degli orari

L'equivalenza di due programmi può essere dei seguenti tipi:

• Result equivalence - Si dice che due programmi che producono risultati identici siano equivalenti.

• View equivalence - Due pianificazioni che eseguono un'azione simile in modo simile sono considerate equivalenti alla visualizzazione.

• Conflict equivalence - Due pianificazioni sono considerate equivalenti al conflitto se contengono lo stesso insieme di transazioni e hanno lo stesso ordine di coppie di operazioni in conflitto.