Este será um artigo dividido em três partes.
Trata-se de algo muito importante, um dos principais motivos pelo grande
sucesso dos gerenciadores de banco de dados (SGBD/DBMS). |
 |
Você irá ver como o PostgreSQL permite juntar diversas alterações a serem efetuadas na base de dados como uma unidade única de trabalho, ou seja, quando você tem um conjunto de mudanças que devem ser todas executadas ou, se ocorrer algum problema, não será feito nada.
O QUE SÃO AS TRANSAÇÕES
Antes de mais nada precisamos saber como os dados são atualizados
no PostgreSQL. Geralmente quando mostramos exemplos de alterações
de dados em uma base, usamos uma única declaração para que esta
alteração seja feita. Porém, no mundo real, encontramos diversas
situações onde precisamos fazer diversas mudanças às quais seriam
impossíveis de serem efetuadas em uma única declaração. Você ainda
precisa que todas estas alterações obtenham sucesso, ou nenhuma
delas deve ser efetuada, caso surja algum problema em qualquer
ponto deste grupo de mudanças.
Um exemplo clássico é a transferência de dinheiro entre duas contas
bancárias, podendo serem representadas até mesmo em tabelas distintas,
e precisamos que uma conta seja debitada e a outra, creditada.
Se debitarmos um valor de uma conta e ocorrer algum problema ao
tentarmos creditar este valor, qualquer que seja o motivo, precisamos
retornar o valor à primeira conta, ou sendo sendo mais coerente,
este valor nunca chegou a ser debitado da primeira conta. Nenhum
banco poderia manter-se no negócio caso eventualmente "perdesse"
o dinheiro durante uma transação financeira entre duas contas
(ou qualquer outra, logicamente).
Em bancos de dados relacionais baseados no ANSI SQL, como o PostgreSQL, isto é possível graças ao recurso de nome TRANSAÇÃO.
Uma transação é uma unidade lógica de trabalho que não deve ser subdividida.
Mas o que sabemos sobre unidade lógica de trabalho?
Isto é simplesmente um conjunto de mudanças a serem efetuadas
na base de dados onde todas devem ter sucesso, ou todas devem
falhar. Exatamente como a transferência de dinheiro entre contas
bancárias como mencionado acima. No PostgreSQL, estas mudanças
são controladas por três instruções:
|
OBS: Tanto
COMMIT WORK e ROLLBACK WORK
podem omitir a palavra WORK, mas,
em BEGIN WORK é obrigatório.
A padronização ANSI / ISO SQL não define a instrução BEGIN WORK,
define que as transações iniciam-se automaticamente, mas
esta é uma extensão muito comum presente - e requerida - em muitos
bancos de dados relacionais.
Um segundo aspecto sobre as transações é que qualquer transação
no banco de dados é isolada de outras transações que estão ocorrendo
ao mesmo tempo. De uma forma ideal, cada transação se comportaria
como se tivesse acesso exclusivo ao banco de dados. Infelizmente,
como veremos nos próximos artigos, existem níveis de isolamento
que, na prática, para atingir melhores performances algo será
comprometido.
ACID
: ÁCIDO, AGRE, AZEDO,... ?!!!
Não.. não tem nada haver com culinária...
ACID é um mneumônico (uma sigla) que descreve as propriedades
que uma transação deve possuir.
| Atomic Atômica |
Uma transação, mesmo sendo um conjunto de ações, deve ser executada como uma unidade única.Uma transação deve ser executada exatamente uma única vez, sem nenhuma dependência. Em nosso exemplo bancário, a movimentação financeira deve ser atômica. O débito em uma conta e o crédito em outra devem ambos acontecer como sendo uma única ação, mesmo se diversas instruções consecutivas em SQL fossem requeridas. |
| Consistent Consistente |
Ao término de uma transação, o sistema deve ser deixado em um estado consistente, respeitando as integridades de dados e relacional da base sendo manipulada. No exemplo da movimentação bancária, ao final da transação, ambas as contas devem ter sido atualizadas com os montantes corretos. |
| Isolated Isolada |
Isto significa que cada transação, não importando quantas transações estão sendo executadas neste momento no banco de dados, deve parecer ser independente de todas as outras transações. Imagine caixas eletrônicos separados, onde, diferentes pessoas querem executar a mesma operação bancária para a mesma conta. Transações processando duas ações concorrentes devem comportar-se como se cada uma delas estivessem operando com acesso exclusivo à base de dados. Na prática, nós sabemos que as coisas não são tão simples assim. Nós trataremos deste tópico nos próximos artigos. |
| Durable Durável |
Uma vez que a transação seja completada, ela deve permanecer completada. Uma vez que o dinheiro tenha sido transferido com sucesso entre as contas, ele deve permanecer transferido, mesmo que a máquina que está rodando o gerenciador de banco de dados pare por falta de energia elétrica. No PostgreSQL, assim como na maioria dos bancos de dados relacionais, isto é conseguido através de um arquivo que descreve as transações (transaction logfile). A maneira este arquivo funciona é bastante simples. Assim que uma transação é executada, as ações não são somente executadas na base de dados, mas também gravadas neste arquivo. Assim que a transação é completada, uma marca é gravada para dizer que a transação foi finalizada, e os dados gravados no arquivo logfile são forçados a permanecerem armazenados, então isto torna o banco de dados seguro mesmo que ele "caia". A durabilidade da transação acontece sem a intervenção do usuário, ou seja, é uma operação executada pelo próprio banco de dados. |
OK? Até a próxima coluna com a segunda
parte deste artigo.
Dúvidas, críticas e sugestões podem ser enviadas diretamente para
meu e-mail, colocando no assunto (subject) "iMasters-PSQL".
Um abraço a todos.
