Resposta direta
Não se recupera o histórico que não foi registrado. O que se faz é reconstruir o rastro mínimo com as evidências que sobraram: data de criação, autor da última alteração, logs de sistema, versões de arquivo. Cada trecho recebe um grau de confiança declarado, confirmado, provável ou desconhecido, para que quem consulta saiba o que é fato e o que é inferência. Em paralelo, define-se o registro obrigatório daqui em diante: origem, data de entrada, responsável e regra de transformação. A base antiga continua utilizável, com confiança menor e explícita.
- Objetivo
- Orientar implementação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata da reconstrução do rastro em base já existente e da confiança declarada por trecho, não da integração entre sistemas.
As evidências que costumam sobrar
Antes de decidir qualquer coisa, vale listar o que existe de evidência. Em geral sobra alguma coisa: data de criação do registro, usuário da última alteração, sequência de identificadores, logs de aplicação, versões de planilha, mensagens que acompanharam o envio do arquivo. Nada disso é histórico de origem no sentido formal, mas permite inferir caminho.
Cada inferência precisa ser marcada como inferência. Um campo de origem declarada com três valores possíveis, confirmada, provável e desconhecida, evita que a reconstrução vire ficção. Quem consulta o dado depois precisa saber o quanto pode confiar nele sem refazer a investigação.
O que passa a ser obrigatório no registro
O registro mínimo daqui em diante tem quatro elementos: de onde o dado veio, quando entrou, quem responde por ele e qual regra o transformou. Se qualquer um falta, o problema volta na próxima migração. A definição é de processo, não de ferramenta; sistemas diferentes podem registrar os mesmos quatro elementos.
Vale separar o obrigatório do desejável. Origem, data e responsável são obrigatórios em qualquer carga. Regra de transformação é obrigatória quando o dado é calculado ou consolidado. O restante, como versão de código e parâmetro de execução, ajuda na investigação, mas não deve travar a operação quando ausente.
O que a reconstrução não resolve
A reconstrução não devolve o que nunca foi registrado. Ela produz uma explicação plausível e limitada, com grau de confiança declarado. Não serve como prova em auditoria, não substitui trilha de sistema e não corrige o dado em si, apenas informa o quanto ele é confiável.
Também não se aplica quando o custo da incerteza é maior que o custo de refazer a base. Em processos com exigência regulatória ou financeira, a resposta correta costuma ser recarregar o dado na fonte original, não reconstruir o caminho. Reconhecer isso cedo evita um trabalho longo com resultado que ninguém aceita.
Recurso prático
Reconstrução do rastro mínimo
- Levantar as evidências disponíveis por tabela: data de criação, autor da última alteração, logs de aplicação, versões de arquivo e mensagens que acompanharam o envio.
- Classificar cada registro em origem confirmada, provável ou desconhecida, registrando o critério usado nessa classificação.
- Definir os quatro campos obrigatórios de registro, origem, data de entrada, responsável e regra de transformação, e em quais cargas cada um se aplica.
- Aplicar o registro novo a todas as cargas a partir de uma data de corte, sem tentar preencher o passado.
- Publicar a base antiga com a confiança declarada visível para quem consulta.
O erro mais comum é preencher a lacuna com a suposição mais razoável e apresentá-la como fato. Isso resolve a aparência do problema e cria uma trilha falsa, que será citada como verdadeira na próxima auditoria.
Conceitos usados nesta página
- Trilha de auditoria — Trilha de auditoria é o conjunto de registros que permite reconstruir quem fez o quê, quando e com qual dado — inclusive depois que o resultado já foi usado.
Sobre o que está escrito aqui
Conceitos relacionados: rastro de origem · log de auditoria · metadado de criação · regra de transformação · confiança declarada. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Integrações, sistemas e qualidade de dados — Página central do tema
- Números que não batem: por que a divergência… — planilhas divergentes
- Falhas silenciosas em integrações: como perce… — falhas silenciosas
Páginas relacionadas
O mesmo problema em outro objetivo
- Dado sem origem: o que registrar a partir de agora — Organizar um processo
- Dado sem histórico de origem: o que a comparação pode afirmar — Comparar alternativas
- Dado sem histórico de origem: como medir mesmo assim — Explicar medição
- Dado de terceiro sem origem: o que checar antes de contratar — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Cópias de base sem versão: alternativas para conciliação — Critérios para confrontar cópias de bases sem histórico de alteração, os métodos de comparação disponíveis e os limites operacionais de cada escolha.
- Relatório mensal feito à mão: como estruturar a extração — Critérios e sequência de trabalho para transformar a consolidação manual de dados de fechamento em uma rotina operacional estável e rastreável.
- Correção no banco de produção: registro e quem autoriza — Define quem autoriza, o que registrar e como o ajuste volta para a origem quando a correção é feita direto no banco de produção.
- Histórico de alteração não registrado: alternativas possíveis — Compara os caminhos para lidar com alteração sem histórico registrado: reconstruir pelos vestígios, começar a registrar agora e conviver com a lacuna.
- Alterações sem registro: o que passa a ser rastreável — Define o que passa a ser registrado em alterações de dados, quem registra, onde fica e como tratar o período que ficou sem histórico.