Especificar migração e reconciliação de dados

Começar pelas perguntas que os dados devem responder

Antes de escolher tabelas ou escrever uma transformação, explicita as perguntas de negócio que o destino terá de responder. No exercício fictício desta aula, uma equipa precisa de identificar as posições de cada conta, os participantes e as quantidades com sinal por unidade numa data de referência. Também precisa de explicar quais as identidades de origem que contribuem para um total por participante e unidade. “Copiar o ficheiro” não especifica nenhuma destas capacidades. Um resumo com totais pode responder à segunda pergunta apenas parcialmente: mostra o resultado, mas pode ter perdido os contributos que o explicam.

Define a granularidade de cada conjunto. Uma linha de origem representa uma posição na data de efeito indicada. O pequeno conjunto fornecido não contém várias revisões da mesma posição. Uma conta pode ter várias posições e uma posição pode ser repartida por vários participantes. No destino, uma linha de posição e uma linha de alocação representam coisas diferentes. Por isso, quatro posições não exigem quatro linhas em todas as tabelas. A comparação útil começa pelo objeto ou relação que cada linha representa.

Produz um dicionário curto com entidade, significado de cada atributo, identidade, referências, unidade, datas e consultas obrigatórias. Para cada campo eliminado ou agregado, pergunta que consulta deixa de poder ser respondida. Regista a resposta com um exemplo concreto antes de aprovar o desenho dos requisitos. O produto desta atividade de Análise é uma especificação justificável para uma futura migração; ainda não existe aqui uma solução entregue a avaliar.

Preservar identidade e cardinalidade

No contrato pedagógico, uma conta é identificada pelo par ordenado entidade e account_id. Assim, N/0012, S/0012 e N/12 são três contas diferentes. Os identificadores são texto e os zeros iniciais fazem parte da identidade. Converter account_id em inteiro colapsaria duas contas de N. Associar só pelo código textual 0012 misturaria N e S. O destino pode criar uma chave técnica própria, desde que conserve uma correspondência inequívoca com a identidade composta e use essa correspondência nas referências das posições.

A identidade de uma posição é entidade e position_id. N/P1 e S/P1 são posições distintas. Uma ocorrência repetida do mesmo par é entrada inválida neste exercício; não existe autorização para deduplicar pela ordem, pela quantidade ou pelo nome apresentado. Uma regra de unicidade protege a identidade, mas não determina sozinha a relação correta. A posição N/P2 refere a conta N/12. Ligá-la a N/0012 produziria uma referência existente e, ainda assim, diferente da que a origem especifica.

Desenha separadamente contas, posições e alocações por participante. N/P1 tem dois participantes, G1 e G2: mantém uma posição e origina duas alocações. Cada alocação guarda a identidade da posição e a identidade do participante. A multiplicação de linhas é uma consequência prevista da relação, não a criação de outra posição. A especificação deve dizer quais os pares permitidos e exigir a sua preservação, em vez de pedir que todas as contagens físicas sejam iguais.

Escrever um dicionário com significado

Um mapeamento precisa de explicar o que se conserva, além de indicar nomes de colunas. O exercício usa magnitude inteira não negativa, direção IN ou OUT e unidade UNIT-A ou UNIT-B. IN corresponde a uma quantidade positiva e OUT a uma quantidade negativa. São convenções inventadas para a aula, sem significado contabilístico universal. A quantidade 30 com direção OUT e unidade UNIT-B torna-se -30 UNIT-B. A presença de um sinal não autoriza trocar a unidade ou converter uma medida noutra.

Especifica o conjunto admitido de unidades e a ausência de conversão entre UNIT-A e UNIT-B. Não existe um total conjunto com significado definido. Para os estados das contas, A corresponde a ACTIVE e D a DORMANT; um código diferente fica sem correspondência autorizada. Para as posições, o código K depende da validade da regra, desenvolvida na secção seguinte. Copiar o rótulo K ou escolher um estado pelo nome mais semelhante não explica a condição de negócio a preservar. Neste contrato, uma posição READY exige uma conta ACTIVE.

Inclui no dicionário entrada, condição de seleção, saída, exceção e informação conservada. A linha de posição no destino mantém identidade composta, referência da conta, datas de efeito e receção, código original, direção, magnitude, unidade, estado mapeado e identificador da regra escolhida. Estes campos permitem explicar a transformação. Se outra representação conseguir responder às mesmas consultas com evidência equivalente, pode ser discutida na revisão dos requisitos; a equivalência tem de ser demonstrada, não presumida a partir de tipos compatíveis.

Separar efeito, receção e validade da regra

A população de entrada é a extração congelada de 2 de julho de 2026, com oito posições. O retrato de negócio é 30 de junho. Todas as linhas fornecidas pertencem à extração, mas só as posições com data de efeito até 30 de junho inclusive são elegíveis para esse retrato. A receção tem de ocorrer até à data de extração. N/P1 tem efeito em 30 de junho e foi recebida em 1 de julho: pertence ao retrato conhecido em 2 de julho. N/P5 tem efeito em 1 de julho: recebe exclusão autorizada FUTURE_EFFECTIVE. Não desaparece da contabilidade da extração.

O contrato usa datas de calendário, sem horas nem fusos. Se o projeto real precisar de instantes, correções retroativas ou revisões sucessivas, essas regras terão de ser especificadas separadamente. Aqui, a data de efeito da posição escolhe a versão do mapeamento. K-before-june é válida desde 1 de janeiro inclusive até 1 de junho exclusive e produz OPEN. K-from-june começa em 1 de junho inclusive, termina em 1 de janeiro de 2027 exclusive e produz READY. S/P1, com efeito em 31 de maio, usa a primeira regra, mesmo tendo sido recebida em junho.

Acrescenta exemplos exatamente na fronteira e fora dos intervalos. Exige uma única regra aplicável: zero correspondências gera UNKNOWN_MAPPING e várias geram AMBIGUOUS_MAPPING. A especificação não permite resolver uma sobreposição escolhendo a regra mais recente. A seleção pelo tempo de execução também alteraria o significado histórico. Estas condições pertencem ao contrato de transformação antes de existir qualquer execução em produção.

Definir repartições e resumos sem perder contributos

Cada posição migrada mantém uma linha de detalhe e origina uma alocação por participante declarado. Os pesos têm de ser inteiros positivos, somar 100 e referir participantes conhecidos, sem repetição dentro da posição. A quantidade com sinal multiplicada pelo peso e dividida por 100 tem de resultar num inteiro. Não existe arredondamento autorizado. Uma repartição de quantidade 1 em duas metades não cabe neste contrato: a especificação deve encaminhá-la como exceção ou ser revista por quem pode alterar a regra, sem inventar uma tolerância durante a implementação.

Para N/P1, +100 UNIT-A com pesos 60 para G1 e 40 para G2 produz +60 e +40 UNIT-A. S/P1 contribui +50 UNIT-A para G1; N/P6 contribui outros +50 UNIT-A para G1. N/P2 contribui -30 UNIT-B para G2. O detalhe contém quatro posições e cinco alocações. O resumo derivado contém G1/UNIT-A = 160, G2/UNIT-A = 40 e G2/UNIT-B = -30. O conjunto fornecido não tem outras alocações migradas. Não se calcula um saldo único somando UNIT-A com UNIT-B.

A ordem tem significado: resolver a identidade e a regra aplicável, validar as relações exigidas e só então formar alocações elegíveis para o resumo. Agregar por participante antes de conservar posição e regra perderia a explicação dos contributos. Uma vista resumida pode ser útil e irreversível por si só, desde que o detalhe necessário permaneça disponível. O requisito de conservação refere-se às consultas e às relações acordadas, não à capacidade de reproduzir cada byte do ficheiro original.

Dar um resultado explícito a cada exceção

A especificação distingue entrada estruturalmente inválida de uma linha válida na estrutura que não satisfaz uma regra de negócio. Neste modelo, um tipo incorreto ou uma identidade primária repetida impede validar a entrada. Uma posição estruturalmente válida e elegível pode seguir para quarentena por código sem correspondência, conta ausente ou em quarentena, participante ou repartição inválida, ou estado READY ligado a conta DORMANT. Estes resultados foram definidos para o exercício; não são regras obrigatórias de um fornecedor de certificação ou de uma instituição real.

No conjunto base, N/P3 usa Z, para o qual não existe mapeamento. N/P4 depende da conta N/0099, cujo estado X não tem correspondência autorizada e coloca essa conta em quarentena. S/P2 refere S/9999, que não existe. As três posições ficam em quarentena e não produzem posição de destino nem alocações. A exclusão por efeito futuro é avaliada antes das regras semânticas; N/P5 tem o resultado de exclusão já definido. O resultado deve guardar identidade de origem e todos os motivos aplicáveis segundo o contrato, sem substituir uma conta desconhecida por outra existente.

Documenta também o efeito nas relações dependentes. “Conta rejeitada” é insuficiente se a especificação deixar uma posição apontar para uma conta que não foi criada. Mantém as exceções na população reconciliada, com saída e motivo verificáveis. Quem poderá autorizar uma correção de correspondência e que evidência precisa de consultar são perguntas para a preparação do processo; esta aula especifica a informação necessária e não executa nem aprova essas correções.

Reconciliar identidades, relações e quantidades

O contrato de reconciliação começa por fixar a população e a granularidade de cada comparação. As oito identidades da extração têm exatamente um resultado cada: quatro migradas, três em quarentena e uma exclusão autorizada. Esta partição não significa oito posições de destino. Para as quatro migradas, exige uma posição por identidade e o conjunto exato de participantes declarado. A soma das alocações de cada posição, na sua unidade e com o seu sinal, deve igualar a quantidade de origem. A tolerância é zero porque o contrato usa inteiros e proíbe arredondamento.

Constrói uma contraprova concreta ao desenho. Se uma proposta substituir N/P6 por uma segunda cópia de S/P1, continua a apresentar quatro posições e +200 UNIT-A. Até o resumo por participante permanece igual, pois ambas contribuem +50 UNIT-A para G1. Contudo, falta N/P6, repete-se S/P1 e a proveniência passa da regra K-from-june para K-before-june. O requisito deve comparar as identidades e a regra escolhida, além das somas. Noutra variante, ligar N/P2 a N/0012 satisfaz a existência da conta, mas falha a associação exigida a N/12.

Relações também podem exigir quantidades nos próprios pares. Num exemplo separado, A contribui 30 para X e 10 para Y; B contribui 10 para X e 50 para Y. Alterar esses quatro contributos para 20, 20, 20 e 40 conserva os totais de A, B, X e Y. Perde, porém, o valor de cada relação. Se a consulta acordada pede quem contribuiu quanto para cada destino, o critério precisa de comparar os pares e os seus valores. Esta escolha decorre da informação exigida, não de acrescentar verificações genéricas.

Validar a especificação antes de implementar

Leva o dicionário, o modelo de relações e um registo de resultados esperados para uma revisão com os utilizadores que precisam das consultas e com quem conhece os dados. Pede que expliquem N/P1, S/P1, N/P2 e uma exceção sem recorrer a inferências não escritas. Para cada passo, identifica o requisito, os campos usados, o resultado esperado e a razão. Se o modelo só devolver um total por participante, a equipa consegue ainda mostrar a conta, a posição e a versão do mapeamento que contribuíram? A ausência dessa resposta identifica uma lacuna de especificação antes de haver uma falha operacional.

Varia uma condição de cada vez. Usa a data de 1 de junho para a fronteira temporal; cria uma sobreposição de regras para testar a exigência de unicidade; troca uma referência por outra conta existente para distinguir integridade estrutural de associação correta; remove a ligação entre posição e participante para verificar se o resumo continua explicável. Uma variante é outro exemplo declarado, não uma alteração silenciosa aos oito registos base. Regista primeiro o resultado esperado. Assim, uma execução futura do modelo pode ser comparada com uma expectativa elaborada fora do programa.

Fecha a revisão indicando consultas preservadas, regras ainda em aberto e quem precisa de decidir cada uma. Um esquema tabular bem formado pode continuar insuficiente para a necessidade de negócio. Os casos pequenos ajudam a encontrar omissões, mas não demonstram que todos os dados reais foram representados, que a implementação escala ou que a produção pode ser autorizada. As referências públicas apoiam a análise de requisitos e qualidade dos dados; as identidades, quantidades e políticas aqui usadas são originais e fictícias.

Oficina: tempo, repartição e informação preservada

Resolve estes quatro pequenos casos antes de escrever critérios de migração.

1. Tempo. Para a mesma entidade, A cobre [1 março, 1 abril), foi recebido em 1 março, revisão 1, valor 50. B cobre [15 março, 1 abril), chegou em 3 abril, revisão 2, valor 70. C cobre esse mesmo intervalo, chegou em 7 abril, revisão 3, valor 60. D cobre [1 abril, 1 maio), chegou em 2 abril, revisão 4, valor 80. A consulta de 31 março com conhecimento até 5 abril devolve 70; com conhecimento até 2 abril devolve 50. A consulta efetiva de 1 abril com conhecimento até 5 abril devolve 80. Filtra a vigência e o conhecimento antes de ordenar revisões. A chegada de C não altera retroativamente a consulta com K=5 abril.

2. Repartição. Divide +9 e −9 por J1, J2, J3 com pesos 50%, 30%, 20%. Trabalha na magnitude, usa partes inteiras, atribui restos maiores primeiro e só depois repõe o sinal. As quotas são (4,5;2,7;1,8), as partes inteiras (4,2,1) somam 7 e as duas unidades restantes vão para J3 e J2. Resultados: (+4,+3,+2) e (−4,−3,−2). Permutar linhas não deve mudar a atribuição. Os totais globais cancelam, mas as duas origens não desaparecem.

3. Relações. Uma configuração tem triplos (E1, R1, Z1), (E1, R2, Z2), (E2, R1, Z2), (E2, R2, Z1). Guardar todos os pares equipamento/regra, regra/zona e equipamento/zona ainda não permite recuperar os quatro triplos: inverter Z1 e Z2 em todos eles conserva cada tabela de pares e muda a configuração. A junção admite oito combinações. Escreve um teste que rejeite as quatro combinações adicionais. Conservar triplos ou uma chave de correlação reversível resolve esta perda; ordenar tabelas não resolve.

4. Reconciliação. A população é {A, B, C, D}. Migradas={A, B}, excluídas={C}, quarentena={D}; só C tem exclusão autorizada. A e B têm 30 e 20 unidades. O destino apresenta A=30 e D=20, sem saída de B. A partição e o total 50 passam, mas os critérios por origem falham: B não foi transformada e D gerou saída proibida. Não corrijas a filiação só para fazer passar o total; reconstrói a transformação autorizada com os participantes e unidades certos.

No trabalho, usa uma matriz que liga cada requisito à informação necessária e ao contraexemplo que deteta a sua perda. Testa fronteiras temporais, sinais, restos, permutações, relações e exceções separadamente. Dados que passam uma dimensão podem falhar outra. Resumo: cobertura da população, igualdade de totais e validade de campos são evidências úteis; o contrato completo exige também contexto temporal, semântica e filiação.

Armadilhas comuns

Confundir posição com movimento ou alocação; perder zeros de identificadores; associar só por parte da chave; usar receção ou execução para escolher a validade; fundir unidades distintas; agregar antes de guardar os contributos; aceitar uma referência apenas porque existe; retirar exceções do denominador; comparar apenas margens quando a consulta exige valores por relação.