Júlio Battisti Livros e Cursosa sua sala de aula na internet

Conforme descrevemos no Capítulo 2, uma transação representa um conjunto de operações, sendo que todas as operações devem ser executadas com sucesso. Caso uma única operação venha a falhar, as operações restantes serão canceladas e as que já foram executadas serão “revertidas”.

Quando todas as operações são executadas com sucesso dizemos que a transação sofreu um Commit. Quando a transação falha (pelo fato de uma de suas operações ter falhado), dizemos que a transação sofreu um Roll Back. Quando a transação sofreu um roll back, os dados estarão no mesmo estado, isto é, com os mesmos valores, que estavam antes do início da transação.

O exemplo mais típico é o que envolve a transferência entre duas contas correntes em um banco. Para ilustrar o conceito, vamos repetir o exemplo colocado no Capítulo 2. Utilizando a terceira maior invenção do milênio passado, que na minha opinião é o Copiar e Colar (Ctrl+C, Ctrl+V), transcrevo abaixo o exemplo de transação apresentado no Capítulo 2:

“O pagamento pode ser feito, por exemplo, através de uma transferência da conta corrente da concessionária, para a conta corrente do fornecedor. Neste ponto, precisamos introduzir o conceito de transação, o qual será bastante detalhado em outros capítulos deste livro. (...)”

Para entender, na prática, o conceito de transações, vamos voltar ao exemplo anterior. Ao efetuar um pagamento, o sistema deve transferir valores da conta corrente da concessionária para a conta corrente do fornecedor. Estas duas ações devem acontecer no contexto de uma transação, conforme indicado abaixo:

Início da Transação.

      Ação 1: Debita o valor da conta corrente da Concessionária.

      Ação 2: Credita o valor na conta corrente do Fornecedor.

Final da Transação.

A primeira ação efetua o débito na conta corrente da Concessionária. Vamos supor que a Ação 1 ocorra com sucesso, porém na hora de fazer o crédito na conta corrente do Fornecedor, ocorra um problema, o que devemos fazer? O valor deve ser estornado para a conta da Concessionária, ou seja, a Ação 1 deve ser revertida, uma vez que nem todas as ações dentro da transação puderam ser concluídas com êxito. Vejam a importância do conceito de transação, pois neste caso, se não usássemos transação, o valor seria debitado da conta corrente da Concessionária, porém não teria sido creditado na conta corrente do fornecedor.”

Revisado o conceito de transação, vamos analisar as características que definem uma transação. Existem quatro características que toda transação deve apresentar:

1. Atomicidade
2. Consistência
3. Isolação
4. Durabilidade

Estas quatro características são resumidas pela sigla ACID. Vamos ver o que significa cada uma destas características.

• Atomicidade: A transação deve representar uma unidade de trabalho “atômica”, isto é, indivisível. Com isso ou todas as operações de uma transação devem ser executadas com sucesso, ou nenhuma delas deve ser executada. Esta característica parece se confundir com o próprio conceito de transação: ou tudo ou nada. O “nada” conforme descrito anteriormente, é garantido pelo mecanismo de roll back, isto é, se uma das operações que faz parte da transação falhar, as operações já executadas serão revertidas. No SQL Server 2005, o mecanismo de log apresenta exatamente este comportamento.
• Consistência: Ao ser finalizada a transação, todos os dados devem estar em um estado consistente. Estar em um estado consistente, em um Banco de Dados Relacional, significa que todas as regras e a integridade referencial foram respeitadas. Por exemplo, uma transação não deve ser capaz de cadastrar um pedido na tabela Pedidos, para um cliente que ainda não foi cadastrado na tabela Clientes. Se isto acontecer, os dados não estarão em um estado consistente. Ao final de uma transação, estruturas auxiliares, como por exemplo os índices, também deverão ter sido atualizadas. Com o SQL Server 2005, a consistência dos dados é garantida, quer a transação tenha sido realizada com sucesso ou tenha sofrido um roll back.
• Isolamento: Em um ambiente com muitos usuários, diversas transações serão executadas simultaneamente. O mecanismo de isolamento garante que uma determinada transação não utilizará dados em um estado intermediário. Vamos supor que uma transação que chamaremos TR1 tenha iniciado. Antes que TR1 tenha terminado inicia-se uma segunda transação TR2. Agora imagine que uma das operações de TR2 precise acessar dados que estejam sendo modificados por TR1. Pelo mecanismo do isolamento, TR2 terá acesso aos dados no estado em que estes encontravam-se antes do início de TR1 – caso TR1 ainda não tenha sido encerrada – ou no estado após o encerramento de TR1 – caso TR1 já tenha sido encerrada. Desta maneira uma transação (no nosso exemplo TR2) não será afetada por valores que tenham sido alterados por outra transação (no nosso exemplo TR1), enquanto estas alterações não tenham se tornado definitivas, isto é, a transação tenha sido completada com sucesso. Existem diferentes níveis de isolamento, os quais serão estudados no Capítulo 10: Read uncommitted, Read committed, Repeatable read e Serializable.
• Durabilidade: Uma vez encerrada a transação, as alterações por ela efetuadas serão definitivas. Mesmo que ocorra alguma falha com o SQL Server, o Sistema Operacional ou o equipamento, quando o SQL Server 2005 for reinicializado as transações que estão no log e ainda não foram “aplicadas” ao Banco de Dados serão aplicadas, fazendo com que as modificações tornem-se permanentes.