Auditoria com PostgreSQL

Este artigo apresenta o desenvolvimento de uma solução de auditoria para operações de insert, update e delete no PostgreSQL.

Auditoria para operações de insert, update e delete no PostgreSQL

Em muitas organizações, o administrador de dados atende a solicitações diretas de intervenção no estado do banco e geralmente o faz através de um terminal interativo. Nesse cenário, é útil responder a questões como “é possível saber qual o estado anterior à modificação do banco?” ou “qual foi a consulta que gerou esses resultados?” e até mesmo “é possível desfazer a transação após sua confirmação?”. Esse artigo se propõe responder a esses pontos e demonstrar como será simples fazê-lo.

O processo de auditoria existe para examinar e confirmar fatos e operações sobre negócios em determinado contexto organizacional, e está pautado na verificação da aderência entre dados e demandas por controles, procedimentos, registros e regras impostas pelas rotinas de trabalho. Nos locais onde existem sistemas de informação que auxiliam na realização das tarefas tanto operacionais quanto de tomada de decisão, é desejável que a lógica de armazenamento dos dados seja provida de mecanismos que assegurem sua qualidade.

Falaremos aqui sobre a possibilidade de desenvolver uma ferramenta básica que permita avaliar internamente aspectos transacionais entre a aplicação e o banco de dados. Inclusive essa é uma nota importante: a responsabilidade pela auditoria é da aplicação que manipula os dados até mesmo em um banco de dados ativo.

Relacionado: Guia Completo de PostgreSQL

Independentemente da estratégia arquitetural do projeto, dos processos de engenharia ou das ferramentas case adotadas pela organização, ou seja, sua metodologia específica de desenvolvimento de software, sempre existirão os papéis desempenhados por diferentes usuários quanto ao uso de banco de dados, interagindo de forma particular com esse ambiente.

Usuários do banco de dados

Inicialmente, como critério de identificação dos usuários, vale considerar sua relação com o uso do banco de dados. Isso é necessário para ilustrar exatamente a qual usuário a solução proposta é mais interessante, isto é, quem vai consumir seus dados e manter seu ciclo de vida. Nesse contexto, os perfis apresentados na Figura 1 podem ser identificados.

Figura 1. Usuários de bancos de dados.

Percebemos o destaque dado a um dos tipos de usuário, o Administrador de Dados, que é o profissional responsável por especificar, modelar, implementar e documentar as operações de negócio no que se refere à persistência dos registros, de tal sorte que a iniciativa pela proposição desta ferramenta renderia melhores resultados com sua participação devido à natureza da atividade.

Relacionado: Curso de PostgreSQL

As rotinas de sua função envolvem aspectos como o projeto de banco de dados, imposição de restrições que garantam a qualidade dos dados, criação de domínios e visões, bem como de funções armazenadas que auxiliem no processamento de alterações no estado do banco de dados, manutenção sobre as representações conceitual, lógica e física das estruturas de armazenamento, sugerir e manter padrões de nomenclatura, e dar suporte gerencial e operacional às equipes através da confecção de relatórios e consultas ad hoc.

Admitindo que esse técnico desempenhe suas atividades sobre um banco relacional, é razoável supor que seu contato com as diferentes sublinguagens do SQL seja intensivo. Portanto, esse artigo focaliza ainda mais sua orientação: somente serão contempladas as instruções, ou consultas, do tipo Manipulação de Dados (DML – Data Manipulation Language). O leitor pode questionar: “como seria registrar os dados alterados por um ‘select’”? O ‘select’ que não altera o estado do banco é considerado como instrução da sublinguagem DQL ("

[...] continue lendo...

Artigos relacionados