Tópicos Avançados em Banco de Dados Gerenciamento de Transações em Banco de Dados Prof. Hugo Souza
Até agora vimos como é formada a infraestrutura física e lógica das bases de dados com os principais componentes físicos e lógicos e suas características; Foi mostrado em sala que as relações existentes dentre esses componentes é de fundamental importância para configurar a comunicação existente de uma ou mais bases provida por um SGBD; A partir de agora, descendo na hierarquia de funcionamento estudaremos como essas estruturas se comunicam lógica e fisicamente para garantir independência local na movimentação das informações; Tudo isso sendo provido pelo que denomina-se de transações
Uma transação nada mais é do que uma unidade lógica de trabalho que contém uma ou mais instruções SQL com o objetivo de empenhar a movimentação dos dados com uma ou mais relações de objetos; A transação é conhecida como unidade atômica à abrangência que pode ocasionar com os efeitos das instruções, sendo de caráter físico, envolvendo critérios técnicos, e mais comumente lógico, para atualização, por exemplo, dos dados nas bases; A formução de comandos é descrita através de chamadas formuladas pela sintaxe e semântica dos dicionários de dados e finalizada com instruções COMMIT ou ROLLBACK;
Para ilustrar o conceito de transações, considere uma base de dados bancários. Quando um banco realiza transferências financeiras do cliente de uma conta poupança para uma conta corrente: Diminua o valor x da conta poupança; Incremente o valor x na conta corrente; Registre a transação y no diário de transações; Se todas as três instruções SQL podem ser executadas para manter as contas em equilíbrio, os efeitos da transação podem ser aplicada na base manipulada; No entanto, se um problema, tais como insuficiência de saldo ou conta inválida impede uma ou duas das transações serem realizadas com sucesso;
Fluxo de início, incremento e término transações SQL;
Analisando a figura anterior, é importante destacarmos dois principais aspectos das transações: a declaração e ocontrole; Uma instrução é um pouco diferente das transações que estamos acostumadas a ver em aplicações cotidianas. Quando uma transação está prestes de ser realizada, três fatores básicos são levados em conta anteriormente: Sintaxe da requisição (construtos do comando); Semântica da requisição (objetivo do comando); Além também das relações que o controle exercerá com o resultado da transação; Entretanto, até a transação ser confirmada, a declaração pode ser revertida - committing;
A operação de Commiting significa que um usuário solicitou explicitamente ou implicitamente que as mudanças na operação tornem-se permanentes; Um pedido explícito ocorre quando o usuário emite uma instrução COMMIT por instruções no próprio código SQL e um pedido implícito ocorre após o término normal de uma aplicação ou cumprimento de uma linguagem de definição de dados DDL; As mudanças realizadas pelas instruções de uma transação se tornam permanentes e visíveis à outros usuários só depois que a transação é realizada com sucesso. As consultas que são emitidas após a operação comprometem possíveis alterações confirmadas;
Você pode nomear uma transação usando o comando SET TRANSACTION... NOME antes que a mesma esteja ativa; Isto torna mais fácil o monitoramento das transações de longa duração e resolve eventuais problemas de transações compostas ou distribuídas; Caso uma ou mais declarações que já tenham sido tomadas como definitivas, há um processo simples de desfazer a todo custo eventuais correções e prevenções na estrutura dos comandos e transações; Para isso são adotados procedimentos de Rollback que tem como função reverter declarações executadas com erros, ou que até mesmo geraram erros;
O efeito da reversão é como se essa declaração nunca tivesse sido executada. Esta operação é chamada de reversão de nível de instrução para possibilitar a correção de erros descobertos durante a execução de instruções SQL; Um exemplo de um erro deste tipo é tentar inserir um valor duplicado em uma chave primária. O choque de instruções gera conflitos nos parâmetros (competição para os mesmos dados) provocando uma reversão; Os erros descobertos durante a análise da instrução, pela sintaxe ainda não foi executado, para que eles não causem danos maiores, sem a proteção rollback existente para os registros e dados das bases de dados;
Para compatibilizar o uso de commit e rollback e evitar danos maiores para as bases de dados, ao nível de usuário, muitos SGBDS possuem complexos módulos de gerenciamento de instruções; Em cada software específico a série de passos para realizar essas operações é baseada na infraestrutura física e lógica e na disposição de seus componentes em relação aos objetos; Em poucos passos, basicamente, o processo de execução de uma transação ocorre da seguinte maneira: Uma instrução SQL é interpretada pelo compilador do SGBD e o mesmo interpreta o comando como uma chamada para uma instância;
Após a instância ser detectada e armazenada pela, rotina, o objeto específico, a base inicia a leitura da transação e executa as relações existentes pela sintaxe e semântica relacionando os objetos envolvidos; Ao término da execução [caso não haja erros], o commit é invocado para autenticar as novas atualizações de registros, e dos dados informados, para que a base se autogerencie; Caso aparecçam erros, ou o usuário deseja voltar a ação realiza, o comando rollback é invocado para instanciar novamente todo o processo descrito; O processo e realizado por operações DDL (pesquisar);
Após o ciclo de leitura, correção e liberação ser realizado, a transação é efetuada com sucesso de acordo com os requisitos e parâmetros evidenciados; Há também a possibilidade de salvar transações em um determinado momento através de uma função denominada de savepoint. Essa função quebra a transações em partes menores para facilitar o processamento dos dados de acordo com o balanceamento e carga atuais da base; Um exemplo comum, do uso de savepoints, são as atualizações realizadas em intervalos de tempos programados de acordo com o reenvio de dados; São utilizadas constatemente em bases densas ;
Por fim, é importante destacar as transações autônomas que são transações invocadas a partir de outras transações; Uma transação autónoma permite-lhe sair do contexto da transação de chamada, realizar algumas operações SQL, confirmar ou desfazer as operações, e depois voltar para o contexto da operação de chamada e continuar com essa mesma operação; Após um certo tempo, uma operação deste tipo tornase independente para executar seus comandos sem quaisquer problemas que alterem seu funcionamento e o funcionamento das demais transações aninhadas anteriormente;
Para encerrarmos, alguns exemplos de códigos que iniciam as transações são os seguintes: SET TRANSACTION; COMMIT; ROLLBACK; SAVEPOINT; ROLLBACK TO SAVEPOINT; Todos afetando diretamente o contexto físico e lógico dos componentes das bases de dados;
Acessem o Disco Virtual da Disciplina no endereço: http://migre.me/3spr1 Baixem a Aula 05 na pasta Slides; Próxima aula veremos Regime e Controle de Objetos em Banco de Dados Parte I Dúvidas? Estejam a vontade!