Histórico da Página

...

• Mapeamento de Tabelas por Vínculo de Titular a partir da tela LOG10004.

Neste mapeamento existem queries no padrão SQL que são cadastradas para cada Tabela X Tipo de Informação com objetivo de permitir que o LOGIX possa rastrear as informações de registros de dados gravados na base de dados ligados a uma pessoa física, seja por meio de um número do CPF, endereço de e-mail, número de CNH, RG, ou outros dados que são conhecidos como IDENTIFICADORES. 

• Mapeamento de Campos por Vínculo de Titular a partir da tela LOG10003.

Neste mapeamento existem as mesmas queries registradas no LOG10004, no entanto este mapeamento de campos também permite registrar as condições também no padrão SQL utilizadas para indicar permissão ou não para anonimizar o conteúdo de campos protegidos registrados na base de dados Logix, onde o sistema acaba utilizando a query de consulta registrada no LOG10004 juntamente com a condição de anonimização informada.

O que são os IDENTIFICADORES no controle de dados protegidos?

...

• CPF
• RG
• CNH
• TITULO DE ELEITOR
• PIS
• TELEFONE
• NOME
• E-MAIL
• ENDEREÇO PESSOAL
• entre outros.

No programa Nos programas LOG10003 e LOG10004, disponíveis no produto a partir do pacote LOGIX 12.1.2205, esta informação aparece no campo Tipo de Informação e também é usada nas queries SQL de consulta e condição de anonimização.

...

A QUERY SQL para consulta de dados é a parte inicial de todo o processo de procura pesquisa no banco de dados e com isso é como se fosse , que funciona como uma instrução SELECT completa, no entanto ela segue alguns critérios e padrões para registro no Mapeamento de Campos por Vínculo do Titular (LOG1003) que estão registrados abaixo demostrando demonstrando Formato, Exemplos e Regras de uso.

...

{SELECT} FROM [<tabela1, tabela2, ..., tabelaN>] WHERE tabela1.codigo = tabela2.codigo AND tabela2.coluna = {<IDENTFICADOR>}

Exemplos:

Regras de uso para toda QUERY SQL de consulta de dados:

• Deve sempre iniciar com a TAG {SELECT} pois durante a execução das buscas de dados, o sistema irá automaticamente identificar a lista de colunas que será selecionada de acordo com o Vínculo de Titular que estiver sendo feita a busca de dados. Portanto, nunca preencha nomes de colunas antes ou depois da TAG {SELECT}.
• Respeitar o nome do IDENTIFICADOR exatamente da forma como está descrito na lista padrão de todos identificadores disponíveis.
• Todo IDENTIFICADOR deve obrigatoriamente estar escrito SEMPRE em caixa ALTA, entre chaves { } e SEM ESPAÇOS em branco no início e final. Exemplos:  {CPF} {RG} {CNH}
• NUNCA usar ASPAS DUPLAS. Neste caso SEMPRE utilize ASPAS SIMPLES para delimitar conteúdos de tipo alfanumérico.
• Tente seguir as regras de caixa ALTA e baixa, para manter uma visualização mais hamônica das instruções. Isso trará um efeito visual muito mais bonito quando for realizar a consulta em tela destas instruções.
• Observe que de ambos IDENTIFICADORES representados em AZUL nos exemplos acima, um deles está escrito diferente que é {CPF:formatOnlyNumeric}. O motivo deste conteúdo diferenciado após o IDENTIFICADOR CPF é que os identificadores sempre chegam nas queries em um formato padrão, ou seja, no caso do CPF, por exemplo, o valor sempre chegará com o conteúdo de um número de CPF contendo os caracteres de máscara onde existem pontos e hífen. No entanto, caso a informação deste IDENTIFICADOR precise ser formatado para garantir a correta pesquisa do dado com o qual foi comparado na QUERY, basta informar o nome de uma função 4GL disponível no RPO do produto Logix que irá realizar a formatação ou até transformar este valor em outro valor que seja necessário para a consulta e que não seja possível buscá-la utilizando instrução SQL. Com isso o formato de um IDENTIFICADOR na query passa a ter 2 formatos possíveis sendo:

...

AND tabela1.dat_conclusao IS NULL OR tabela1.dat_conclusao > {TEMPO}

Exemplos:

OBS: A query de exemplo não reflete necessariamente uma condição real registrada no sistema, apenas foi usada para exemplificar o padrão das regras de uso.

Regras de uso para toda QUERY de condição de anonimização de dados:

• Pode usar o mesmo padrão da query de consulta onde pode iniciar com a TAG {SELECT} pois durante a execução das buscas de dados, o sistema irá automaticamente ignorar a query de consulta e refazer a pesquisa usando apenas a QUERY registrada na condição de anonimização.
• Pode iniciar com uma condição AND ou OR, que neste caso o sistema irá utilizar como um complemento da QUERY de consulta de dados registrada para o mesmo Vínculo de Titular.
• O uso de IDENTIFICADORES, quando utilizados, segue o mesmo padrão da query de consulta de dados.
• NUNCA usar ASPAS DUPLAS. Neste caso SEMPRE utilize ASPAS SIMPLES para delimitar conteúdos de tipo alfanumérico.
• Tente seguir as regras de caixa ALTA e baixa, para manter uma visualização mais hamônica das instruções. Isso trará um efeito visual muito mais bonito quando for realizar a consulta em tela destas instruções.
• No exemplo acima temos o uso de um TAG chamado {TEMPO}. Neste caso ele NÃO É UM IDENTIFICADOR mas sim um TAG que assumirá o valor de uma data que é calculada automaticamente pelo sistema com base na data corrente onde está sendo realizado o processamento, onde no ato de uma validação de anonimização de dados considerando o TEMPO DE GUARDA registrado no cadastro da condição SQL de anonimização do dado de acordo com a Classificação do Dado registrada para a Tabela / Campo e Vínculo do Titular.
• Observe que de ambos TAGS representados em VERMELHO ESCURO nos exemplos acima, um deles está escrito diferente que é {TEMPO:formatDateAsDBDttimeY2S}. O motivo deste conteúdo diferenciado após o TAG TEMPO é que a data calculada automaticamente com base no TEMPO DE GUARDA chegará na querie de condição de anonimização em um formato padrão de DATA, respeitando o formato de data do banco de dados que estiver em uso. No entanto, caso a informação deste TAG de  precise ser formatado em outro formato, como por exemplo DATETIME YEAR TO SECOND para garantir que não ocorrerá falha na comparação com a coluna de tabela do banco de dados por conflito de formato da coluna, basta informar o nome de uma função 4GL disponível no RPO do produto Logix que irá realizar a formatação ou até transformar este valor em outro valor que seja necessário para a consulta e que não seja possível buscá-la utilizando instrução SQL, lembrando apenas de retornar o valor no formato aceito para o banco de dados em uso. Com isso o formato do TAG TEMPO na query passa a ter 2 formatos possíveis sendo:

...