Equipe Geokrigagem
Chegou o quarto texto da série “Data Quality” produzida por Scott McManus.
Documento, Procedimento, Treinamento
“Já ouvi diversas vezes: “os dados estão ‘beleza’ em nosso banco, estão salvos e seguros”. No meu dia-a-dia, na prática de auditoria, consigo encontrar vários pequenos erros. Na inspeção, apesar do cliente possuir o mais forte e o mais caro pacote de banco de dados, ninguém ativa os bloqueios de dados; as pessoas entram e saem do banco de dados, utilizam o banco o dia inteiro. Acontecem digitação ‘frenética’, erros e até gatos em cima dos teclados. Adicione a isso, os usuários bem-intencionados com pouco de conhecimento, achando que estão fazendo a coisa certa, e, então, temos edições imprudentes ou sem cuidado. São edições que não são mal-intencionadas, apenas acidentais. É difícil dizer quanto erro pode ser atribuído às edições imprudentes.
É um tema de pesquisa que sempre quis fazer. Um conjunto de dados que é usado diariamente, sem bloqueios, e, então, medir sua decadência. A maioria das empresas que percebem que têm um problema está disposta a eliminá-lo e bloqueá-lo, ao invés de reunir os dados e disponibilizá-los para um trabalho de pesquisa. Também é difícil de avaliar, porque muitos dos bancos de dados que possuem um problema de dados ‘errados’, também têm falta de verificação na entrada dos dados ou falta geral de cuidados que podem ter contribuído para erros.
Não importa o quão bom seja o seu sistema de banco de dados, se você permitir que as pessoas usem os dados nele, sem um mecanismo de bloqueio de dados ou tornando-os somente como leitura (read-only), pode-se esperar que a qualidade dos dados caia.
Estratégias para preservar a qualidade dos dados incluem o uso de logs de usuários de nível SQL Server ou WindowsNT, logins de usuários de nível de software e exportações de dados. Os logs do SQL Server e do Windows geralmente significam que certas pessoas só podem fazer certas coisas, através de software e através do backdoor diretamente no banco de dados. O nível de software significa que os usuários só podem fazer certas coisas através do software, mas a entrada pelo backdoor é insegura. Ambos os métodos podem proporcionar um sentimento de segurança que pode não existir.
Um login de um geólogo sênior pode ser autorizado a editar e excluir dados. Esse mesmo geólogo sênior deve usar um login diferente que só permita acesso ‘somente leitura’ ao fazer uso diário dos dados. Só porque eles podem ser mais responsáveis (um cargo mais alto) ou ter mais acesso, os erros causados por falta de cuidado no banco de dados não cessam. Um bom conjunto de logins de usuários oferece um usuário que ‘edita-adiciona-exclui’ e também uma conta de usuário que ‘só-lê’ (read-only). Os sistemas inteligentes de banco de dados que bloqueiam dados, uma vez que alcançam um certo nível de qualidade, adicionam ainda mais segurança, para que o usuário sênior, com privilégios de edição, não possa alterar acidentalmente os dados bons e bloqueados, ao lidar com novos dados que não foram verificados e validados.
Um método simples de remover os erros devidos a uma digitação rápida é a exportação de dados, em um formato fácil de importar ou se conectar diretamente em pacotes de terceiros para uso dos dados. Neste caso, eu recomendaria exportações diárias ou regulares para garantir que o conjunto de dados de trabalho seja o mais atual (e que se remova qualquer erro do conjunto), e tenha um método claro para o usuário final obter os problemas arrumados ou editados de forma rápida e eficiente no banco de dados.
A Precisão é Suficiente?
Esta não é uma questão regulamentada, alguns gostam da abordagem de estatísticas de frequência e aplicam um limite superior de confiança, como 95% ou 97,5%. Seja qual for a abordagem que você tomar, ela precisará ser modificada pelo orçamento, pelos recursos disponíveis e a maneira que a empresa adota para armazenar os dados. Alguns métodos precisam de mais trabalho. Um sistema que bloqueia o dado, uma vez que é assinalado, precisa de pouca verificação, apenas verificações pontuais ao longo do tempo. Um texto, uma planilha ou um banco de dados que não bloqueia dados precisará de verificação constante, para garantir que a qualidade dos dados seja preservada, especialmente se eles são usados todos os dias dentro desse sistema de dados.
Minha primeira tarefa é descobrir todas as regras de validação do banco de dados e garantir que nenhum dado esteja fora delas. Problemas são sempre um mau sinal, seja no arranjo ou configuração incorreta do banco de dados, ou nas pessoas que não tomam o devido cuidado. Existem algumas coisas que são requeridas, como os furos de sondagem caírem dentro de uma determinada área ou local, sendo que alguns valores nunca devem ser ‘vazios’. Fazendo consultas entre listas de referências ou tabelas de códigos e tabelas de dados, deveriam existir somente códigos usados nessas bibliotecas.
Por vezes, nos campos categóricos, as diferenças serão devidas a dados históricos que não se encaixam novos códigos. Neste caso, não existe um problema nos dados em si, porém é um problema de que os dados não são tão úteis para a empresa sem que os geólogos façam um exercício mental e os traduzam, sempre que tenham que usá-los.
Todos as minhas requisições e a velocidade com que são atendidas responderão muitas perguntas sobre se o processo é bom para armazenar os dados, se o sistema é organizado e se as pessoas entendem o sistema que utilizam.
Apesar de eu utilizar os backups para conseguir ver possíveis diferenças nos dados ao longo do tempo, a principal razão de pedi-los é que a maioria dos protocolos de backup nunca são testados – até que algo dê errado. Então, se os backups solicitados são entregues a mim, mostra que, como parte dos protocolos de administração de banco de dados, existe um sistema de backup forte, que funciona. Este bom sinal demonstra que a maioria das tarefas de administração de banco de dados também estão sendo bem-sucedidas. Que existe um pessoal que se preocupa com os dados da empresa.
Então, faço verificações rápidas sobre os dados atuais em relação aos dados originais. Eu uso uma abordagem de freqüência e contagem dos erros em relação aos bits de dados. Se eu encontrar 1 em 100 erros, não fico muito preocupado; se estou encontrando 10 em 100 erros, começo a verificar mais a fundo e a me preocupar; com mais do que isso, sei que há sérios erros. Muitas vezes, faço mais verificações para ver se o nível de porcentagem de erro é sobre o mesmo período geral de coleta de dados ou durante apenas alguns programas ou em apenas alguns funcionários.
Eu verifico se pode ser um erro sistemático, como abaixo dos limites de detecção, usando diferentes métodos de armazenamento ao longo do tempo ou códigos de litologia mudando ao longo do tempo. Em seguida, verifico com os responsáveis dos dados, aponto os problemas e vejo o que respondem. Às vezes, nós recebemos um memorando relatando que está ok, que esses códigos foram alterados para estes outros ou essas coordenadas foram ajustadas em 3m devido ao erro de topografia/perfilagem. Às vezes, essas mudanças só são suportadas por boca a boca ou relatos e, outras vezes, com documentação de apoio.
Uma vez organizado, eu começo a ver as fotos dos testemunhos, os chips ou os testemunhos e me asseguro de que o registro, os dados categóricos e os ensaios estejam razoáveis, quando checo contra a prova física.
Então checo as polpas e os rejeitos de laboratório. Além de amostrar, muitas vezes busco coisas simples, como se o testemunho é oxidado ou intemperizado, mas as polpas correspondentes são ricas em sulfeto e de cor cinza – eu sei, então, que pode haver erros de número de amostra ou trocas de amostras/etiqueta. É um bom indício se os técnicos de galpão e laboratório conseguem rapidamente colocar suas mãos nos testemunhos, polpas e rejeitos, e dizer até que ponto o sistema é bom e se a equipe está orgulhosa do que está fazendo. O estado físico dessas polpas armazenadas, bem como as caixas de testemunho, também aponta para a forma como os dados e o controle de qualidade são adotados pela empresa e seus funcionários. Um galpão de testemunhos bem organizado é muitas vezes uma manifestação física de uma boa limpeza no banco de dados.
Na maioria das vezes, encontramos problemas. É muito raro não encontrar ao menos um erro. Mas encontrar alguns erros não é um mau sinal, especialmente se existe uma boa documentação, bons procedimentos seguidos no local e se existem funcionários capacitados para lidar com problemas e com vontade de melhorar continuamente a qualidade de seus dados.”
Referências
Scott McManus é geólogo de recursos na Skandus Pty Ltd, e nos autorizou a transcrição do texto.
Fernanda Nishiyama é geóloga especialista em banco de dados geocientíficos e consultora na GEOM3.
Portuguese