ACID em Banco de Dados Transacionais
Compreendendo transações a nível de banco de dados e suas propriedades fundamentais.
Transação
Transação em banco de dados nada mais é que um bloco único e indivisível de comandos a serem executados em um SGBD. Esses blocos são reconhecidos e interpretados, tendo a finalidade de executar ações dentro do banco.
Para o sucesso da execução de uma transação (que chamamos de commit), todas as propriedades do modelo ACID devem acontecer perante as transações. No caso da ocorrência de algum tipo de falha, um rollback é acionado e desfaz os comandos até então utilizados.
Para atribuir características as transações, em 1983 foi consolidado o ACID, um acrônimo para Atomicidade, Consistência, Isolamento e Durabilidade. O Acid é um modelo base das propriedades que devem ser saciadas para a execução de um transação.
Vamos ver individualmente o conceito de cada palavra e sua aplicação no modelo transacional de banco de dados:
Atomicidade:
Na época da antiga Grécia Clássica entre 500a.C.e 338a.C, os grandes filósofos Demócrito de Abdera e Leucipo de Mileto compuseram a teoria de que todas as coisas no universo são feitas de uma única partícula que não se reparte, e essa partícula veio a ganhar o nome átomo que significa indivisível.
Com o passar dos anos o conceito foi aplicado na química e logo na computação, mais especificamente em banco de dados, compondo a característica de Atomicidade de uma transação, que basicamente expressa a ideia de total execução. Por exemplo, em um banco de dados, uma transação pode ser executada por completo ou não será executada.
Isso significa que em caso de sucesso deve ser executada totalmente e em casos de erros ou falhas deve ser abortada por completo.
Consistência:
Consistência aplicada no conceito ACID é a coerência, a capacidade e a integridade referente aos dados utilizados. É a propriedade do modelo de transação que garante que os dados estejam íntegros antes e após a execução de uma transação e que também todos os dados transcritos sejam validados em conformidade a suas respectivas regras de definição. Incluindo nesse processo o uso de restrictions, cascades, triggers e qualquer outra forma/combinação de modificadores dados em uma base.
Isolamento:
Em uma base de dados a propriedade de isolamento é um conjunto de técnicas que se é aplicado em um banco para que múltiplas transações simultâneas, para que não interfiram umas nas outras.
Exemplo: em um determinado site, 2 usuários distintos sem se comunicar um com o outro, estão alterando os mesmo dados em uma tabela no banco de dados. Para não haver inconsistências e para que as transações executadas por um dos usuário não cause interferência na de outro usuário, as técnicas de isolamento são aplicadas.
O conceito de proporcionar isolamento é controlar as concorrências entre as múltiplas transações.
Durabilidade:
Ao final da execução de uma transação bem sucedida (chamamos de commit), os dados que foram gravados ou alterados em um banco de dados por essa transação devem se manter lá de forma definitiva e inalterada até que outra transação à modifique, independente de picos de luz, falhas ou mesmo desligamentos.
A durabilidade é a propriedade que possibilita a garante de que, o que já se foi registrado não será mais perdido, corrompido ou modificado sem motivos.
Controle de Transações
O controle de transações, é a aplicação do ACID na execução de simultâneas transações com a finalidade de gerenciar e garantir a execução individual sem perda de funcionamento mesmo que haja concorrência entre as transações.
Concorrência:
Para a aplicação da propriedade de isolamento vinda do ACID na execução de uma transação, alguma gestão obrigatoriamente deve ser imposta.
Comumente em banco de dados, existe a implementação do controle de concorrências que visa o impedimento de múltiplas transações em um mesmo objeto, tabela ou registro, visando garantir a integridade dos dados nesses momentos.
Existem no geral quatro modos que são usados no auxílio dessa tarefa de manter a integridade dos dados, sendo eles:
- Serializable: Esse é o modo de comportamento mais restrito. Ele gera um lock (bloqueio) para qualquer outro processo que seja executado concorrentemente a uma transação.
- Read Commited: Para evitar problemas de informações sujas, os SGBDs costuma adotar essa opção pois permite a leitura apenas de informações já confirmadas, logo após um commit.
- Read Uncommited: Não usa o conceito de lock. É o modo menos restritivo. É permitido que os valores de uma tabela sejam lidos por uma transação enquanto são alterados por outra.
- Repeatable Read: Permite a inserção de novos registros enquanto lidos, mas bloqueia os dados até o fim da transação, impossibilitando que estes sejam modificados durante um processo de leitura por exemplo.
DeadLock:
Lock é quando uma ação está sendo tomada em um banco de dados e para evitar a concorrência de 2 comandos em cima do mesmo registro ou tabela, um lock (travamento) é executado. Quando um lock é ativo a transação por sua vez aguarda o unlock (destravamento) da tarefa que estava a sua frente para assim poder ser executada. A execução de cada tarefa em um banco gera um lock ao ser iniciada e um unlock ao ser finalizada.
Já o DeadLock, traduzido do inglês significa impasse ou travamento por completo. É um caso que ocorre nos bancos de dados quando são feitos muitos lock’s que dependem de outros lock’s para prosseguirem, causando uma fila eterna de bloqueio.
Exemplo: quando uma primeira tarefa a ser executada, depende de uma segunda, mas a segunda depende da primeira para poder ocorrer. Isso causa um ciclo de dependências (dependência cíclica) e assim impedindo que qualquer tarefa possa ser executada. Geralmente em casos assim, os SGBD’s cancelam ambas as transações para que as próximas possam ser realizadas.
Fim!
Esse foi uma apresentação com detalhes mais técnicos para pessoas que trabalham com banco de dados. Espero que tenha somado em algo!
