3. Extração de Dados dos Legados

Processos que leem os sistemas origens e geram arquivos com um layout padrão para cada um dos assuntos da camada STG do modelo MDM.

3.1. Estratégia de Views

3.1.1. Views

Com a intenção de simplificar o desenvolvimento de processos extratores concebemos a estratégia de extração por meio de views. O objetivo é permitir que os responsáveis pelas áreas de negócio, e suas diversas regras e lógicas,  possam gerar os dados para extração, evitando dessa forma a necessidade de customizações e processos de desenvolvimento custosos para essa atividade.

A camada STG já recebe os dados como é desejado que sejam extraídos, para que então sejam processados pelo motor MDM.

As VIEWS contêm os dados para cada domínio específico da camada STG, além das informações de rastreabilidade do assunto no legado, e também a rastreabilidade com outro domínio do qual tenha dependência ou relacionamento. Exemplo: Para o assunto endereço, além dos campos de carga (logradouro, número, etc.), teremos a rastreabilidade de endereço (nome tabela e chaves do legado de endereço), além da rastreabilidade de pessoa (nome tabela e chaves do legado de pessoa), pois na camada STG, a tabela de endereço está associada à tabela de pessoa.

Abaixo a relação de Views:

# Tabela Descrição  Dependência
1 VIEW_PESSOA Dominio:  VIEW  que contém as informações  de pessoas Não se aplica
2 VIEW_DOCUMENTO Dominio:  VIEW  que contém as informações  de documento VIEW_PESSOA
3 VIEW_ENDERECO Dominio:  VIEW  que contém as informações  de endereco VIEW_PESSOA
4 VIEW_TELEFONE Dominio:  VIEW  que contém as informações  de telefone VIEW_PESSOA
5 VIEW_CONTATO_ELETRONICO Dominio:  VIEW  que contém as informações  de contato eletronico VIEW_PESSOA
6 VIEW_EVENTO Dominio:  VIEW  que contém as informações dos eventos associados a pessoa VIEW_PESSOA (Não obrigatório)
7 VIEW_CONTRATO Dominio:  VIEW  que contém as informações  de contato VIEW_PESSOA
8 VIEW_FISCAL Dominio:  VIEW  que contém as informações  de fiscal VIEW_PESSOA
9 VIEW_PERFIL Dominio:  VIEW  que contém as informações  de perfil VIEW_PESSOA
10 VIEW_UNIDADE_NEGOCIO Dominio:  VIEW  que contém as informações  de unidade de negocio VIEW_PESSOA
11 VIEW_CONTA Dominio:  VIEW  que contém as informações  de conta VIEW_PESSOA
12 VIEW_CONTATO Dominio:  VIEW  que contém as informações  de contato VIEW_PESSOA
13 VIEW_MARCACAO Dominio:  VIEW  que contém as informações  de marcacao VIEW_PESSOA
14 VIEW_RELACIONAMENTO Dominio:  VIEW  que contém as informações  de relacionamento VIEW_PESSOA para as duas pessoas relacionadas
15 VIEW_FUNCIONARIO Dominio:  VIEW  que contém as informações  de funcionario VIEW_PESSOA para as duas pessoas relacionadas
16 VIEW_SOCIO Dominio:  VIEW  que contém as informações  de socio VIEW_PESSOA para as duas pessoas relacionadas
17 VIEW_RELACAO_CONTATO_ELE Dominio:  VIEW  que contém as informações  da relacao contato x contato eletronico VIEW_PESSOA, VIEW_CONTATO_ELETRONICO,VIEW_CONTATO
18 VIEW_RELACAO_CONTATO_END Dominio:  VIEW  que contém as informações  da relacao contato x endereco VIEW_PESSOA, VIEW_ENDERECO,VIEW_CONTATO
19 VIEW_RELACAO_CONTATO_TEL Dominio:  VIEW  que contém as informações  da relacao contato x telefone VIEW_PESSOA, VIEW_TELEFONE,VIEW_CONTATO
20 VIEW_PESSOA_INFO_ADICIONAL Dominio:  VIEW  que contém as informações adicionais da pessoa VIEW_PESSOA
21 VIEW_LOG_COMPARTILHAMENTO Dominio:  VIEW  que contém as informações de registro de compartilhamento dos dados da pessoa Não se aplica
22 VIEW_CONSENTIMENTO Dominio:  VIEW  que contém as informações de registro de consentimento da pessoa Não se aplica

Como descrito acima, cada uma das views possuem atributos próprios pertinentes ao assunto, porém para dar maior liberdade ao cliente e permitir a inclusão de novos atributos sem a necessidade de novos desenvolvimentos, disponibilizamos no modelo, a view VIEW_PESSOA_INFO_ADICIONAL. Fazendo uso da mesma, o cliente poderá incluir quantos outros atributos desejar.

3.1.2. Cadastro de Views

Visando tornar o processo de extração de dados das Views automático, de tal forma que seja possível adicionar novas Views ao processamento sem a necessidade de desenvolver ou alterar processos, foi criada a tabela de parâmetro CTR_CADASTRO_VIEW para armazenar as informações sobre as Views, tais como, servidor, porta, nome do banco de dados, nome da conexão, nome da View.

Antes de realizar a carga na STG é necessário cadastrar as informações das origens na tabela CTR_CADASTRO_VIEW e criar as conexões com as bases de dados origem no servidor DataStage.

3.2. Camada STG

Processos responsáveis por realizar a leitura dos dados das Views e carregar os dados na camada Staging (STG). Para realizar a carga da STG, basta executar o processo 08_CONTROLECARGA\JM0400_ExecucaoViewSTG, a depender do indicador do tipo de banco de dados da base MDM.

O processo inicia a extração de dados das Views de origem executando os processos do diretório 03_STG\ Extratores\VIEWS.

image-1658769600975.png

Em seguida executam os processos genéricos do diretório 03_STG\Generico, que leem os arquivos gerados nos processos
extratores e carregam as tabelas STG.

image-1658769642251.png

3.3. Camada BCR De-Para Domínio

Conforme é de se esperar, as empresas possuem inúmeros sistemas, alguns desenvolvidos internamente, outros adquiridos de terceiros. E consequentemente cada um desses sistemas possui uma forma de representar uma mesma informação.

Com o objetivo de garantir uma padronização e criar uma visão corporativa, é preciso definir os domínios válidos. Com essa finalidade, existe na solução processos próprios com o objetivo de traduzir essas inúmeras representações para os domínios definidos nas BCRs específicas. Dessa forma é garantido que o MDM consiga interpretar a informação recebida e que a processe conforme esperado.

OBS: Os processos de De-Para de domínio serão executados sob demanda a partir do momento que a camada STG for carregada com novos sistemas ou novos domínios, ou novas traduções sejam verificados pelos responsáveis. Caso contrário, não existe a necessidade da execução desse processo.

3.4. Domínio de Classificação dos Atributos MDM

A solução MD2 MDM contempla uma camada para armazenar as informações acerca da classificação dos atributos e seus respectivos dados. Entende-se que essa é uma forma de garantir para a organização que as aplicações consumidoras dos dados mestres conheçam o domínio de classificação dos atributos MDM e dessa forma possam garantir que somente usuários com o devido perfil de acessem o dado íntegro.

O objetivo dessa camada é permitir que o administrador de dados, ou qualquer profissional responsável pelas regras de acesso aos dados, realize a classificação dos atributos do MDM de acordo com seu perfil (pessoal, sensível) e seu respectivo grau de sigilo.

Ex.: Atributo nome é classificado como Dado Pessoal, e para o grupo de acesso Especialista em Qualidade de Dados é Restrito.