Chegamos, finalmente, em nossa décima oitava aula! Saímos, praticamente, do zero em relação aos conhecimentos sobre Banco de Dados e, aos poucos, nós evoluímos nessa trilha de aprendizagem. 

Vimos, inicialmente, as diferenças entre dados e informações, em seguida, passamos a entender o que são Banco de Dados, com foco naqueles que seguem o modelo relacional. Compreendemos como os relacionamentos acontecem dentro da base de dados e trabalhamos, ainda, com os conceitos de integridade de dados, segurança e otimização. 

Nesta lição, vamos conhecer um conceito muito importante, quando fazemos referência ao uso simultâneo do Banco de Dados, por mais de uma pessoa, que é o conceito de transação.

Ao final dessa aula, você conhecerá os conceitos de como os SGBDs controlam os acessos simultâneos aos dados e, principalmente, como é garantido que as atualizações do Banco de Dados, que aparecem para os usuários, sejam sempre a última versão dos dados que foram atualizados na base. Então, vamos lá?

Todos os conceitos que trabalhamos, até o momento, sempre, visaram atender às necessidades de apenas um usuário. Ou seja, sempre pensamos em apenas uma pessoa acessando a base de dados, sem considerar o que podemos chamar de concorrência, quando temos mais de um usuário solicitando acesso ao mesmo registro, dentro do Banco de Dados.

Considere que você tem uma conta bancária em conjunto com uma outra pessoa e, em determinado momento, você e a outra pessoa desejam fazer saque na conta corrente. Vamos considerar que você tem R$300,00 de saldo na sua conta e que você está em um caixa eletrônico para efetuar um saque de R$290,00; ao mesmo tempo, a outra pessoa está em um outro caixa eletrônico para fazer um saque de R$100,00.

Olhando de forma isolada, ambos podem fazer o saque, pois o saldo é de R$300,00, mas, ao mesmo tempo, se você e a outra pessoa efetivarem o saque, certamente, quem efetuar o saque primeiro vai conseguir, mas outro vai receber uma mensagem de saldo insuficiente, o que, certamente, irá trazer uma preocupação.

Quando trabalhamos em bancos de dados, o processo de atualização dos dados é semelhante. Há uma transação bancária, conforme citado acima, pois se mais de um usuário atualizar seus dados simultaneamente, sem nenhum controle, a integridade dos dados, ou, utilizando o exemplo, poderíamos ficar com um “saldo negativo”, caso o banco permita.

Mas o que fazer quando isso ocorre? Como evitar que se torne um problema para a integridade do Banco de Dados? Basicamente, para resolver precisamos implementar o conceito de transação, que existe em Banco de Dados,  quando o primeiro usuário efetua uma alteração nos dados e o segundo usuário somente vai conseguir fazer o mesmo, após o primeiro usuário terminar o seu processo de atualização. Nesta lição, vamos aprender com maior detalhamento todo esse processo, fique ligado(a)!

O conceito de transação, inicialmente, parece ser algo fora da nossa realidade diária. Existem, porém, várias comparações que podemos fazer em relação à nossa realidade, que servem para ilustrar e justificar o conceito de transações dentro dos nossos sistemas, principalmente, dentro dos Bancos de Dados.

O primeiro exemplo simples é o do uso de um banheiro público. Você já deve ter observado que, em banheiros públicos, existem várias cabines, mas cada cabine é utilizada por apenas uma pessoa de cada vez, pois os recursos que estão dentro da cabine são projetados apenas para uso individual. 

Ao entrar na cabine, podemos dizer que a pessoa iniciou uma transação ao trancar a porta. A partir daquele momento, dentro da cabine, a pessoa pode fazer diversas atividades, desde atender a necessidades fisiológicas, como trocar de roupa, retocar a maquiagem etc. Algumas pessoas, inclusive, entram na cabine para tirar um rápido cochilo.

O importante é que, enquanto existe uma pessoa dentro da cabine, a porta está trancada e o que ocorre dentro da cabine é algo privativo. Ao encerrar a atividade, a pessoa abre a porta e, nesse momento, libera a cabine para uso de outra pessoa. 

A partir desse ato, podemos fazer uma analogia com o processo de término da transação em um Banco de Dados, quando os dados são liberados para o uso de outros usuários do sistema. Com essa explicação simples, comparativa ao mundo real, observamos que temos 3 estágios básicos de uma transação: o bloqueio do recurso, o uso do recurso e a liberação do recurso para que outras pessoas o utilizem. 

Agora, com esse exemplo em mente, vamos entender, de forma técnica, os conceitos que envolvem uma transação em Banco de Dados.

Para iniciar o entendimento do conceito de transação, antes, temos que retomar que o uso de recursos computacionais é realizado, na maioria das vezes, de forma concorrente, ou melhor, várias pessoas utilizam, ao mesmo tempo, os mesmos recursos que estão guardados dentro do Banco de Dados, ou seja, os registros que estão armazenados nas tabelas e relacionamentos.

Uma transação pode ser, apenas, um processo dentro do sistema, ou pode ser um conjunto de processos, dependendo da regra de negócio que existe. Para exemplificar, vamos fazer uma transação simples, responder a uma prova com 5 questões. Se considerarmos uma rotina do sistema, interagindo com o Banco de Dados, seria a seguinte transação:

Você acabou de acompanhar uma rotina simples, em português, que apresenta o processo simplificado que um desenvolvedor utilizaria para possibilitar a um aluno a realização de uma prova no computador. 

Para entender, vamos observar, inicialmente, as linhas 1 e 27, nas quais estão as marcas de início da transação e fim da transação. Para o SGBD, o sistema que vai gerenciar tudo o que acontece com os dados, essa marcação indica que ele deve considerar que tudo o que acontece entre os passos 2 e 26 são privados. 

Isso significa que, apenas, o usuário que iniciou essa transação tem acesso ao que está acontecendo até o final da transação, que ocorre na linha 27, ou, na linha 4, caso o aluno já tenha feito a prova. As linhas 6 e 7 são importantes também, pois a linha 6 vai ler no Banco de Dados a prova e a linha 7 vai travar os dados que estão relacionados a essa prova. 

Isso é importante, pois imagine que você iniciou a prova e o professor queira mudar a questão 2, por exemplo. Isso não será possível, pois ela estará bloqueada até que você termine a prova, garantindo, assim, a integridade dos dados que foram apresentados a você.

Após responder as 5 questões — linhas 9 a 22 —, o sistema calcula a nota, contando todas as respostas corretas e dividindo por 5, que é a quantidade de questões da prova. O resultado será um número entre 0 e 1, que representa a porcentagem de acertos da prova, ou a sua nota. Somente após gravar a sua nota no Banco de Dados (linha 26), é que a prova e as questões são liberadas para que possa ser efetuada qualquer alteração, se a regra de negócios permitir. 

Por último, após finalizar a transação, o sistema enviará o resultado ao professor e ao aluno. Uma representação gráfica da transação seria:

Na representação, podemos visualizar que a transação está, efetivamente, entre as tarefas 2 e 26. O que ocorre dentro da transação é tratado de forma privada pelo SGBD, seria semelhante a trancar a porta da cabine do banheiro público, conforme o exemplo que utilizei anteriormente. 

A outra característica — a garantia de que todos os dados alterados foram atualizados no Banco de Dados — é realizada por dois comandos, ou rotinas, que os SGBDs possuem, que são o COMMIT e ROLLBACK. No mundo dos SGBDs, são termos comuns e não são traduzidos para o português. 

Agora, vamos considerar que, durante a realização da prova, após responder a segunda questão, caia a conexão com a Internet ou acabe a energia elétrica. Será que a prova poderia ficar aberta até voltar a energia, com todos os dados relacionados travados, impedindo o acesso dos demais programas dentro do sistema da escola? 

Com certeza não, pois, como houve uma falha dentro da transação, o correto é que ela seja completamente desfeita e deixe os dados exatamente com o conteúdo que estavam antes da transação iniciar, ou seja, o SGBD deve voltar tudo ao estado original, garantindo que não há dados parciais gravados no Banco de Dados. 

No exemplo da prova, observe as linhas 28 e 29, que enviam a mensagem do resultado da prova ao professor e ao aluno, respectivamente. Você consegue responder o porquê estes dois processos estão fora da transação?

Caso o envio das mensagens estivesse dentro da transação e houvesse uma falha no envio da mensagem ao aluno, seria acionado o processo de rollback, mas o professor teria recebido a mensagem de que o aluno realizou a prova, o que não seria verdade, pois, com o rollback, a prova seria descartada. Por esse motivo, todas as confirmações são realizadas, somente, após a confirmação do término da transação.

Como já falamos anteriormente, quando fazemos referências às dependências funcionais, a 1ª Forma Normal, a atomicidade, é a propriedade que garante que a transação que está ocorrendo é única, ou melhor, do ponto de vista lógico, cada transação tem que ter a garantia de ser tratada de forma única e indivisível e deve sempre ser executada na sua totalidade, mesmo que haja falha do sistema no decorrer do processo. 

A consistência é a propriedade que indica que a transação deve manter a consistência do banco de dados, sempre transformando um estado consistente para outro estado consistente, independentemente do que ocorre durante o processamento da transação.

O isolamento prevê que as transações sejam processadas sem serem visíveis para outras transações; assim, as atualizações de uma transação T1 não serão visíveis por outra transação T2 até que a transação T1 encerre com um commit executado com sucesso.

Como citamos anteriormente, o commit é a operação realizada dentro do Banco de Dados e, efetivamente, grava as alterações dentro das tabelas, liberando-as para uso pelas demais transações. Somente, após o commit, podemos confirmar que as atualizações foram concretizadas e não serão mais desfeitas ou canceladas. Ao contrário, caso haja qualquer falha durante a transação, será executada uma operação de rollback, desfazendo e cancelando todas as operações realizadas dentro da transação, voltando o Banco de Dados ao estado do início da transação.

O princípio da durabilidade prevê que as transações ocorram dentro de uma determinada duração no sentido de que, uma vez que seja executado um processo de commit, a transação pode ser considerada encerrada e descartada. Ou seja, a transação é viva, apenas, no momento que ela ocorre e não é mais considerada, após o seu encerramento.

De forma simplificada, entendemos, nesta lição, a importância das transações nos Bancos de Dados e como elas ocorrem, com a finalidade de garantir que a integridade dos dados seja sempre mantida. 

Para finalizar nossa lição, vamos buscar um exemplo clássico de transação, que tem se tornado popular dentro da nossa rotina diária. Com certeza, você já ouviu o termo: “Me mande um PIX”, não é mesmo? Mas, o que é o PIX na verdade?

O PIX é um processo de transferência de dinheiro, que ocorre entre contas correntes de diferentes instituições bancárias e de forma instantânea, ou seja, o dinheiro é debitado em uma conta corrente e, no instante seguinte, é creditado em uma outra conta corrente destino. Vamos considerar, a seguir, as etapas do processo:

Essa rotina está simplificada para efeito didático, mas, nela, você consegue observar que a transação está ocorrendo entre as etapas 2 e 15. Observe que, nos passos 4 e 12, há a efetiva movimentação com o saldo da conta do cliente. A transação, também, prevê que, caso haja algum erro no processo, por falha do cliente, por cancelamento ou por falha técnica, todo o processo será desfeito, devolvendo o valor à conta do cliente. Efetivamente, o valor é debitado apenas quando a transação termina (16) e, então, é emitido um comprovante do envio do dinheiro. 

Todo esse processo é realizado dessa forma, pois estamos falando de diversas instituições, com milhares de clientes utilizando aplicativos diferentes e, em diversos locais do Brasil (ou até mesmo fora do Brasil), ou seja, há muitas possibilidades de falhas. O processo de transação garante que o valor somente seja debitado do cliente caso a transação termine com sucesso, ou seja, caso o destinatário efetivamente receba o valor na sua conta corrente.

Espero que você tenha evoluído bastante com os seus conhecimentos sobre Banco de Dados, nessa nossa primeira etapa de estudos. Terminamos, aqui, a primeira fase, mas ainda temos bastante assunto para explorar. Espero poder encontrar você em outras unidades do curso, ou, quem sabe, como um profissional de Banco de Dados no futuro. Até mais!