Vários Proprietários em um Único Banco de Dados

O processo de conversão depende da seguinte configuração de proprietário da tabela no banco de dados do sistema:

  • O proprietário de produção é vinculado às tabelas utilizadas pelo sistema de produção. Essas tabelas têm um ID de proprietário CISADM.

  • O proprietário intermediário é vinculado às tabelas em que você insere dados pré-validados. Essas tabelas têm um ID de proprietário CISSTG.

O esquema do proprietário da tabela intermediária é quase idêntico ao esquema de produção, com as seguintes exceções:

  • As tabelas de controle não são tabelas reais na tabela intermediária, mas são, em vez disso, visualizações das tabelas correspondentes na produção.

  • Tabelas de conversão específicas projetadas somente para dar suporte ao processo de conversão existem apenas no esquema da tabela intermediária. Por exemplo, tabelas que gerenciam atribuição de chave e resolução de XML.

Esta seção contém conceitos de nível alto relacionados aos proprietários da tabela.

A validação Sempre Usa Dados de Controle de Produção

Quando os processos em batch de validação são executados nos dados intermediários, eles validam esses dados aplicados às tabelas de controle de produção (e inserem os erros na tabela de erros intermediária). Isso significa que as instruções SQL que acessam/atualizam as entidades precisam usar o proprietário intermediário, enquanto as instruções SQL que acessam as tabelas de controle precisam usar o proprietário da produção. Observe, porém, que quando esses mesmos processos de validação em batch são executados na produção, as instruções SQL nunca acessam o proprietário intermediário. Em vez disso, todas apontam para o proprietário de produção.

Isso é feito da seguinte maneira:

  • Deve haver um servidor de aplicativos separado para cada proprietário. Cada servidor de aplicativos aponta para um ID de usuário do banco de dados específico.
    Observação: Em uma instalação na nuvem, o servidor do aplicativo pode apontar apenas para um ID de usuário do banco de dados específico de cada vez. Consulte "Suporte à Conversão de Dados para Implementações na Nuvem" para obter mais informações sobre como alternar entre proprietários.
  • O ID de usuário do banco de dados associado ao proprietário da tabela intermediária usa CISSTG como o proprietário das tabelas mestre e de transação, mas usa CISADM como proprietário das tabelas de controle de produção.
  • O ID de usuário do banco de dados associado ao proprietário da produção usa CISADM como o proprietário de todas as tabelas.

Talvez você esteja se perguntando por que tivemos todo esse trabalho. Há várias razões:

  • Queríamos reutilizar a lógica de validação que existe nos programas que validam os dados de produção. Para conseguir isso, esses programas às vezes devem apontar para o proprietário intermediário e outras vezes para o proprietário de produção (e isso deve ser transparente para os programas; caso contrário, dois conjuntos de SQL seriam necessários).
  • Queríamos permitir que você usasse o aplicativo para examinar e corrigir dados intermediários. Isso pode ser feito criando um servidor de aplicativos que aponta para o banco de dados da tabela intermediária com as características de propriedade descritas acima.
  • Queríamos que os programas de validação pudessem validar dados de produção (além dos dados intermediários). Por que validar os dados de produção se apenas os dados limpos podem ser adicionados à produção? Pense nas seguintes situações:
    • Após uma atualização, é possível validar os dados de produção para garantir que a lógica preexistente de saída do usuário ainda funciona.
    • É possível testar as ramificações de uma alteração na lógica de validação. Para fazer isso, você poderia introduzir uma alteração temporária na lógica de saída do usuário (na produção) e, em seguida, executar as tarefas de validação em modo de amostragem aleatória.
    • Você se esqueceu de executar um programa de validação antes de preencher a produção e quer ver quais foram os danos. Se você seguir as instruções deste documento, isso provavelmente nunca ocorrerá. Entretanto, acidentes acontecem. E, se acontecerem, pelo menos há uma maneira de determinar as ramificações.

Apenas a Validação Pode Funcionar em Ambos os Proprietários

Embora o redirecionamento do ID do proprietário seja uma técnica útil para o processo em batch de validação, ele não pode ser usado pela atribuição de chaves e pelo processo em batch de inserção de produção. Por quê? Porque esses processos precisam acessar as mesmas tabelas, mas com um proprietário diferente de cada vez. Eles também precisam fazer referência a tabelas de conversão específicas que não existem na produção. Por exemplo, o processo em batch que insere linhas em uma tabela na produção deve selecionar linhas da versão intermediária dessa tabela, resolver chaves das tabelas de mapeamento de chaves antigas/chaves novas e inserir os registros resolvidos na versão de produção da mesma tabela.

Isso é feito da seguinte maneira:

  • Na intermediária, uma visualização da produção existe para cada item elegível à tabela de conversão. O código-fonte dessas visualizações faz com que o proprietário do banco de dados aponte para a produção. Por exemplo, há uma exibição chamada CX_​PER que aponta para a tabela de pessoas na produção.
  • Os programas de atribuição de chave e inserção usam essas views sempre que precisam acessar dados de produção.