Introdução
SortCL, a linguagem IRI de definição e manipulação de dados estruturados, há muito tem a capacidade de extrair valores de substituição de arquivos de conjuntos externos contendo duas ou mais colunas de valores. Esse recurso é usado para transformações de pesquisa em operações Voracity ETL com tecnologia CoSort, pseudonimização FieldShield e funções de restauração e seleção de dados aleatórios/par válido em trabalhos de síntese de dados de teste RowGen.
Esses arquivos de conjunto são ótimos para informações que não mudam com frequência. Mas como os arquivos de conjunto devem ser classificados pelo conteúdo da coluna, eles podem ser complicados de usar quando as linhas precisam ser adicionadas - especialmente enquanto o arquivo de conjunto está aberto/em uso.
Além disso, o conteúdo de um arquivo de conjunto geralmente se origina em um banco de dados. Nesses casos, uma etapa extra (como executar o assistente 'Set File from Column' do IRI Workbench ou uma operação SQL) precisava ser adicionada ao fluxo de trabalho para extrair valores de uma tabela em um arquivo de conjunto.
Para resolver essas desvantagens, a pesquisa direta de valores de substituição de tabelas de banco de dados existentes foi habilitada. As pesquisas de uma tabela de banco de dados usam a mesma sintaxe e estrutura para pesquisas de tabela já existentes para arquivos de conjunto. Isso mantém a consistência funcional em trabalhos SortCL e fornece acesso a mais valores (em vários bancos de dados e arquivos de conjunto) de uma só vez.
Sintaxe
A sintaxe do atributo de campo SortCL para acessar dados em um arquivo de conjunto tem sido tradicionalmente:
SET="<Set_Source>"[<[ Search List ]>] [DEFAULT="string"] [ORDER=<Order Option>] [SELECT=<Select Option>] [SEARCH=<Search Option>]
onde o
Seu programa SortCL (ou compatível) procurará uma correspondência entre o valor desse campo e a coluna de pesquisa no banco de dados. Se houver uma correspondência, o valor da coluna de substituição nessa linha será usado como o valor final para o novo campo, que deve ter um nome diferente do campo referenciado em uma das fontes de entrada.
As colunas da tabela usadas na pesquisa são especificadas em um único elemento de idioma adicional à implementação inicial do subatributo SET: LOOKUP="<lvalue>,<rvalor>”.
O parâmetro lvalor é o nome da coluna na tabela que contém o valor a ser pesquisado. Isso corresponde à coluna da esquerda, ou primeira, em um arquivo de conjunto. O rvalor parte corresponde à coluna da direita em um arquivo de conjunto de duas colunas e é a coluna que contém o valor a ser retornado como substituição.
Assim como nas pesquisas de arquivo de conjunto tradicionais, um valor padrão deve ser especificado se não houver correspondência. A sintaxe DEFAULT=”string”, em que “string” é o valor padrão especificado manualmente, é usada. Não deve haver vírgulas entre nenhum dos parâmetros do arquivo definido.
Juntando tudo, um possível exemplo da sintaxe para uma pesquisa de tabela pode ser:
SET=”new_schema.info;DSN=Novo MySQL;” [ACCOUNT_NUMBER] LOOKUP="ACCOUNTNUM,PHONENUM"
Este deve ser um parâmetro dentro de uma definição de campo SortCL. A tabela “info” deve ter colunas denominadas ACCOUNTNUM e PHONENUM neste caso.
Como essas novas pesquisas de conjunto podem ser usadas na produção? Considere estes exemplos de script de trabalho IRI:
Exemplos
Exemplo 1 :pseudonimiza dados usando valores de substituição de um banco de dados.
Este trabalho do FieldShield procura valores da coluna “id” na tabela chamada “lookuptable” acessada por meio do DSN “Mangled”. Se o campo ID for o mesmo na entrada (um arquivo de texto) e na coluna ID da tabela de banco de dados referenciada, todos os campos na saída (também um arquivo de texto) serão substituídos por valores de substituição falsos, mas realistas, também do mesma tabela referenciada. Se não houver correspondência, os valores padrão especificados no script serão exibidos.
/INFILE=sensitiveData.txt /PROCESS=DELIMITED /INCOLLECT=200 # limit to 200 records /FIELD=(ID, TYPE=ASCII, POSITION=1, SEPARATOR="|") /FIELD=(NAME, TYPE=ASCII, POSITION=2, SEPARATOR="|") /FIELD=(SSN, TYPE=ASCII, POSITION=3, SEPARATOR="|") /FIELD=(ADDRESS, TYPE=ASCII, POSITION=4, SEPARATOR="|") /REPORT /OUTFILE=pseudonymizedData.txt /PROCESS=RECORD /FIELD=(PSEUDO_ID, TYPE=ASCII, POSITION=1, SEPARATOR="|", SET="lookuptable;DSN=Mangled;" [ID] DEFAULT=”0123456789” LOOKUP="id,fakeid") /FIELD=(PSEUDO_NAME, TYPE=ASCII, POSITION=2, SEPARATOR="|", SET="lookuptable;DSN=Mangled;" [ID] DEFAULT=”John” LOOKUP="id,fakename") /FIELD=(PSEUDO_SSN, TYPE=ASCII, POSITION=3, SEPARATOR="|", SET="lookuptable;DSN=Mangled;" [ID] DEFAULT=”555-55-5555” LOOKUP="id,fakessn") /FIELD=(PSEUDO_ADDRESS, TYPE=ASCII, POSITION=4, SEPARATOR="|", SET="lookuptable;DSN=Mangled;" [ID] DEFAULT=”583 West Ridge Rd” LOOKUP="id,fakeaddress")
Exemplo 2 :pseudonimiza três colunas de uma tabela de banco de dados usando valores de substituição de um banco de dados diferente e criptografa a coluna restante.
Este script faz uma pesquisa com base no campo ID obtido da tabela do banco de dados denominada “inputTable”, observando a coluna “id” da tabela denominada “lookuptable” acessada através do DSN “Mangled”. Os valores correspondentes nas colunas "fakeid", "fakename", "fakessn" e "fakeaddress" serão obtidos se houver uma correspondência do campo ID de dados de entrada para a coluna "id" na tabela. Se não houver correspondência, os valores padrão serão exibidos.
A saída será enviada para uma tabela de destino separada. A saída também pode ser enviada para a mesma tabela que a entrada, o que mascararia os dados no local.
/INFILE=”inputTable;DSN=Mangled;” /PROCESS=ODBC /FIELD=(ID, TYPE=ASCII, POSITION=1, SEPARATOR="|") /FIELD=(NAME, TYPE=ASCII, POSITION=2, SEPARATOR="|") /FIELD=(SSN, TYPE=ASCII, POSITION=3, SEPARATOR="|") /FIELD=(ADDRESS, TYPE=ASCII, POSITION=4, SEPARATOR="|") /REPORT /OUTFILE=”outputTable;DSN=Mangled;” /PROCESS=ODBC /FIELD=(PSEUDO_ID, TYPE=ASCII, POSITION=1, SEPARATOR="|", SET="lookuptable;DSN=Mangled;" [ID] DEFAULT=”0123456789” LOOKUP="id,fakeid") /FIELD=(PSEUDO_NAME, TYPE=ASCII, POSITION=2, SEPARATOR="|", SET="lookuptable;DSN=Mangled;" [ID] DEFAULT=”John” LOOKUP="id,fakename") /FIELD=(ENCRYPT_SSN=enc_fp_aes256_alphanum(SSN,”EPWD:p4PagGZq9k7JFaj6/J1/JQ==”, TYPE=ASCII, POSITION=3, SEPARATOR="|") /FIELD=(PSEUDO_ADDRESS, TYPE=ASCII, POSITION=4, SEPARATOR="|", SET="lookuptable;DSN=Mangled;" [ID] DEFAULT=”583 West Ridge Rd” LOOKUP="id,fakeaddress")
Exemplo 3 :Protegendo informações de identificação pessoal (PII) usando substituições realistas de um conjunto diversificado de métodos de mascaramento.
O arquivo de entrada contém PII em várias colunas (campos). Se houver uma correspondência entre o campo de nome no arquivo CSV de entrada e a coluna "FIRST_NAME" na tabela "NAMES", um sobrenome de substituição será gerado na coluna "LAST_NAME" nessa mesma tabela. Os sobrenomes diferem na tabela “NAMES” dos próprios dados pessoais.
/INFILES=personalData.csv /PROCESS=CSV /ALIAS=PERSONALDATA_CSV /FIELD=(FIRST_NAME, TYPE=ASCII, POSITION=1, SEPARATOR=",", FRAME="\"") /FIELD=(LAST_NAME, TYPE=ASCII, POSITION=2, SEPARATOR=",", FRAME="\"") /FIELD=(SSN, TYPE=ASCII, POSITION=3, SEPARATOR=",", FRAME="\"") /FIELD=(BIRTH_DATE, TYPE=AMERICAN_DATE, POSITION=4, SEPARATOR=",", FRAME="\"") /FIELD=(ADDRESS, TYPE=ASCII, POSITION=5, SEPARATOR=",", FRAME="\"") /REPORT /OUTFILE=maskedData.csv /PROCESS=RECORD /FIELD=(FIRST_NAME, TYPE=ASCII, POSITION=1, SEPARATOR=",") /FIELD=(LAST_NAME_DB_SET, TYPE=ASCII, POSITION=2, SEPARATOR=",", SET="NAMES;DSN=mangled;" [FIRST_NAME] LOOKUP="FNAME,LNAME") /FIELD=(SSNENC=enc_fp_aes256_alphanum(SSN), TYPE=ASCII, POSITION=3, SEPARATOR=",") /FIELD=(BIRTH_DATEPLUS=BIRTH_DATE + 30, TYPE=AMERICAN_DATE, POSITION=4, SEPARATOR=",") /FIELD=(ADDRESSSET, TYPE=ASCII, POSITION=5, SEPARATOR=",", SET="C:/IRI/cosort100/sets/addresses.set" SELECT=ANY)
O mesmo script de trabalho, delineando um diagrama de mapeamento, juntamente com a tabela de nomes original, é mostrado no meu IRI Workbench IDE, construído no Eclipse, abaixo:
Exemplo 4 :Gerando dados de teste referencialmente corretos com IRI RowGen
Considere uma tabela de banco de dados ou, em outros casos potenciais, várias tabelas, que contêm dados que correspondem a uma determinada data. Com a funcionalidade IRI RowGen e pesquisa de tabela, é possível selecionar uma seleção de datas (de um arquivo definido ou gerado aleatoriamente) e adicionar mais campos na saída que correspondem a valores realistas com base na entrada de data fornecida.
Neste exemplo, todos os dados correspondentes da data são mantidos na tabela de pesquisa mostrada abaixo (embora possam ser obtidos de qualquer número de tabelas). A tabela tem o valor de um ano de datas e os valores relacionados correspondentes:
A partir do arquivo definido no campo de entrada DATA, são selecionadas 3 datas que estão dentro do intervalo de datas incluído na tabela.
O arquivo de conjunto inclui três entradas:2019-10-11, 2019-11-11 e 2019-12-11.
/INFILE=random_file_placeholder /PROCESS=RANDOM /INCOLLECT=3 /FIELD=(DATE, TYPE=ALPHA_DIGIT, POSITION=1, SEPARATOR=",", SET="C:/Users/Devon/Downloads/dates.set" SELECT=ALL) /REPORT /OUTFILE=testPriceData.xml /PROCESS=XML /FIELD=(DATE, TYPE=ALPHA_DIGIT, POSITION=1, SEPARATOR=",") /FIELD=(OPEN, TYPE=ALPHA_DIGIT, POSITION=2, SEPARATOR=",", SET="new_schema2.pricedata;DSN=New MySQL;" [DATE] DEFAULT="170" LOOKUP="Date,Open") /FIELD=(HIGH, TYPE=ALPHA_DIGIT, POSITION=3, SEPARATOR=",", SET="new_schema2.pricedata;DSN=New MySQL;" [DATE] DEFAULT="171" LOOKUP="Date,High") /FIELD=(LOW, TYPE=ALPHA_DIGIT, POSITION=4, SEPARATOR=",",SET="new_schema2.pricedata;DSN=New MySQL;" [DATE] DEFAULT="169" LOOKUP="Date,Low") /FIELD=(CLOSE, TYPE=ALPHA_DIGIT, POSITION=5, SEPARATOR=",",SET="new_schema2.pricedata;DSN=New MySQL;" [DATE] DEFAULT="170.5" LOOKUP="Date,Close") /FIELD=(ADJ_CLOSE, TYPE=ALPHA_DIGIT, POSITION=6, SEPARATOR=",",SET="new_schema2.pricedata;DSN=New MySQL;" [DATE] DEFAULT="170.5" LOOKUP="Date,Adj_Close") /FIELD=(VOLUME, TYPE=ALPHA_DIGIT, POSITION=7, SEPARATOR=",",SET="new_schema2.pricedata;DSN=New MySQL;" [DATE] DEFAULT="523210182" LOOKUP="Date,Volume")
A saída deste exemplo é um arquivo XML padrão contendo os valores de pesquisa:
Exemplo 5 :Executando uma transformação de pesquisa em um trabalho de relatório e ETL do IRI Voracity
Neste exemplo, temos um arquivo CSV contendo números de contas e valores vencidos de vários clientes. Uma pesquisa de tabela será usada em dois campos na saída para obter informações correspondentes adicionais de uma tabela de fatos do cliente mestre no MySQL, com essa tabela servindo como a tabela do cliente mestre.
A tabela mestre não possui informações sobre o valor devido e contém muito mais clientes do que o arquivo de entrada que mostra apenas contas de clientes inadimplentes. Isso procura o nome e o número de telefone da tabela com base no número da conta e gera uma planilha .XLSX em um formato de relatório prático com informações de contato do cliente.
Inserir CSV
Snippet da tabela mestre do cliente a ser consultado
/INFILE=C:/Users/Devon/Downloads/accountnumsandamountDue.csv /PROCESS=CSV /ALIAS=accountnumsandamountDue /FIELD=(ACCOUNT_NUMBER, TYPE=ASCII, POSITION=1, SEPARATOR=",", FRAME="\"") /FIELD=(AMOUNT_DUE, TYPE=ASCII, POSITION=2, SEPARATOR=",", FRAME="\"") /REPORT /OUTFILE="'Past Due',HEADER;report.xlsx" /PROCESS=XLSX /FIELD=(ACCOUNT_NUMBER, TYPE=ASCII, POSITION=1, SEPARATOR="\t") /FIELD=(LOOKUP_NAME,TYPE=ASCII,POSITION=2, SEPARATOR="\t",SET="new_schema2.info;DSN=New MySQL;" [ACCOUNT_NUMBER] LOOKUP="ACCOUNTNUM,NAME") /FIELD=(LOOKUP_PHONE,TYPE=ASCII,POSITION=3, SEPARATOR="\t",SET="new_schema2.info;DSN=New MySQL;" [ACCOUNT_NUMBER] LOOKUP="ACCOUNTNUM,PHONENUM") /FIELD=(AMOUNT_DUE, TYPE=ASCII, POSITION=4, SEPARATOR="\t")
Saída do relatório "Atrasado"
Suporte do IRI Workbench
As pesquisas de tabela de banco de dados podem ser configuradas como uma regra no Assistente de Nova Regra de Campo. Esse tipo de regra é chamado de "Pesquisa de tabela" em Regras de geração, mas pode ser usado em várias origens ou destinos como uma regra de campo em outros trabalhos.
Ao selecionar uma pesquisa de tabela como regra, um perfil de conexão já deve estar configurado ou criado quando solicitado para acessar as tabelas do banco de dados e os nomes das colunas para escolher.
A partir daí, selecione a tabela, coluna de pesquisa e coluna de valor de substituição para usar na pesquisa. Agora esta pesquisa de tabela pode ser definida como uma regra a ser aplicada com base nos correspondentes.
Os conjuntos podem ser modificados a partir do tipo de transformação de valor Set:Table Lookup na caixa de diálogo do editor de campo.
Isso não é necessário se uma regra de campo de pesquisa de tabela já tiver sido configurada e aplicada. No entanto, esta caixa de diálogo permite a edição manual de componentes de pesquisa de tabela, como DSN, tabela, campo de pesquisa, coluna de pesquisa e coluna de resultado. Um valor padrão também pode ser especificado aqui.
Resumo
As pesquisas de conjunto agora têm uma nova fonte possível no SortCL que pode expandir bastante e facilitar a obtenção dos dados necessários para uma pesquisa. Isso é útil em operações de mascaramento ou geração de dados para fornecer valores de substituição realistas que preservam relacionamentos.
No futuro, os conjuntos podem ser expandidos para incluir ainda mais fontes de dados. Entre em contato com seu representante IRI para obter mais informações.
- Observe que, atualmente, os usuários do RowGen aproveitam os arquivos de conjunto para a seleção aleatória de valores sem um parâmetro de pesquisa. Essa funcionalidade não é suportada na primeira implementação de pesquisas de tabela de banco de dados. Isso ocorre porque cada banco de dados possui um método ou sintaxe específica para selecionar uma linha aleatória de uma tabela; alguns bancos de dados podem não suportar a seleção aleatória.
