Introducción
SortCL, el lenguaje IRI de definición y manipulación de datos estructurados, ha tenido durante mucho tiempo la capacidad de extraer valores de reemplazo de archivos de conjuntos externos que contienen dos o más columnas de valores. Esta capacidad se utiliza para transformaciones de búsqueda en operaciones ETL de Voracity impulsadas por CoSort, funciones de seudonimización y restauración de FieldShield y selección de datos de pares válidos/aleatorios en trabajos de síntesis de datos de prueba de RowGen.
Estos archivos establecidos son excelentes para la información que no cambia con frecuencia. Pero debido a que los archivos establecidos deben ordenarse por contenido de columna, pueden ser engorrosos de usar cuando es necesario agregar filas, especialmente cuando el archivo establecido está abierto/en uso.
Además, el contenido de un archivo establecido a menudo se origina en una base de datos. En esos casos, se tuvo que agregar un paso adicional (como ejecutar el asistente 'Establecer archivo desde columna' de IRI Workbench o una operación SQL) al flujo de trabajo para extraer valores de una tabla en un archivo establecido.
Para abordar estos inconvenientes, se ha habilitado la búsqueda directa de valores de reemplazo de tablas de bases de datos existentes. Las búsquedas de una tabla de base de datos usan la misma sintaxis y estructura que las búsquedas de tablas que ya existen para los archivos establecidos. Esto mantiene la consistencia funcional en los trabajos de SortCL y brinda acceso a más valores (en múltiples bases de datos y archivos establecidos) a la vez.
Sintaxis
La sintaxis de atributo de campo SortCL para acceder a los datos en un archivo de conjunto ha sido tradicionalmente:
SET="<Set_Source>"[<[ Search List ]>] [DEFAULT="string"] [ORDER=<Order Option>] [SELECT=<Select Option>] [SEARCH=<Search Option>]
donde
Su programa SortCL (o compatible) buscará una coincidencia entre el valor de este campo y la columna de búsqueda en la base de datos. Si hay una coincidencia, el valor de la columna de reemplazo en esta fila se usará como el valor final para el nuevo campo, que debe tener un nombre diferente al campo al que se hace referencia en una de las fuentes de entrada.
Las columnas de la tabla utilizadas en la búsqueda se especifican en un solo elemento de idioma adicional a la implementación inicial del subatributo SET: LOOKUP=”<lvalue>,<rvalor>”.
El parámetro lvalue es el nombre de la columna de la tabla que contiene el valor que se va a buscar. Esto corresponde a la columna de la izquierda, o primera, en un archivo de configuración. El valor part corresponde a la columna de la derecha en un archivo de conjunto de dos columnas, y es la columna que contiene el valor que se devolverá como reemplazo.
Al igual que con las búsquedas de archivos de conjuntos tradicionales, se debe especificar un valor predeterminado si no hay ninguna coincidencia. Se utiliza la sintaxis DEFAULT=”cadena”, donde “cadena” es el valor predeterminado especificado manualmente. No debe haber comas entre ninguno de los parámetros de archivo establecidos.
Poniéndolo todo junto, un posible ejemplo de la sintaxis para una búsqueda en una tabla podría ser:
SET=”nuevo_esquema.info;DSN=Nuevo MySQL;” [NÚMERO_DE_CUENTA] BUSCAR=”NÚMERO DE CUENTA, NÚMERO DE TELÉFONO”
Este debería ser un parámetro dentro de una definición de campo SortCL. La tabla "info" debe tener columnas denominadas ACCOUNTNUM y PHONENUM en este caso.
¿Cómo se podrían usar estas nuevas búsquedas de conjuntos en producción? Considere estos ejemplos de secuencias de comandos de trabajo de IRI:
Ejemplos
Ejemplo 1 :Pseudonimizar datos usando valores de reemplazo de una base de datos.
Este trabajo de FieldShield busca valores de la columna "id" en la tabla denominada "tabla de búsqueda" a la que se accede a través del DSN "Mangled". Si el campo ID es el mismo en la entrada (un archivo de texto) que en la columna ID de la tabla de la base de datos a la que se hace referencia, entonces todos los campos en la salida (también un archivo de texto) se reemplazarán con valores de reemplazo falsos pero realistas también del misma tabla referenciada. Si no hay ninguna coincidencia, se mostrarán los valores predeterminados especificados en el script.
/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")
Ejemplo 2 :Pseudonimizar tres columnas de una tabla de base de datos utilizando valores de reemplazo de una base de datos diferente y cifrar la columna restante.
Este script realiza una búsqueda basada en el campo de ID tomado de la tabla de la base de datos llamada "inputTable", mirando la columna "id" de la tabla llamada "lookuptable" a la que se accede a través del DSN "Mangled". Los valores coincidentes en las columnas "fakeid", "fakename", "fakessn" y "fakeaddress" se tomarán si hay una coincidencia entre el campo de ID de datos de entrada y la columna "id" en la tabla. Si no hay ninguna coincidencia, se generarán los valores predeterminados.
La salida se enviará a una tabla de destino separada. La salida también podría enviarse a la misma tabla que la entrada, lo que enmascararía los datos en su lugar.
/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")
Ejemplo 3 :Protección de la información de identificación personal (PII) utilizando reemplazos realistas de un conjunto diverso de métodos de enmascaramiento.
El archivo de entrada contiene PII en varias columnas (campos). Si hay una coincidencia entre el campo de nombre en el archivo CSV de entrada y la columna "FIRST_NAME" en la tabla "NAMES", entonces se generará un apellido de reemplazo desde la columna "LAST_NAME" en esa misma tabla. Los apellidos difieren en la tabla “NOMBRES” de los propios datos personales.
/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)
La misma secuencia de comandos de trabajo, el esquema de un diagrama de asignación, junto con la tabla de nombres original se muestra en mi IRI Workbench IDE, construido en Eclipse, a continuación:
Ejemplo 4 :Generación de datos de prueba referencialmente correctos con IRI RowGen
Considere una tabla de base de datos o, en otros casos potenciales, varias tablas que contengan datos que correspondan a una fecha determinada. Con IRI RowGen y la funcionalidad de búsqueda de tablas, es posible tomar una selección de fechas (de un archivo establecido o generadas aleatoriamente) y agregar más campos en la salida que correspondan a valores realistas basados en la entrada de fecha proporcionada.
En este ejemplo, todos los datos correspondientes a la fecha se mantienen en la tabla de búsqueda que se muestra a continuación (aunque se pueden tomar de cualquier cantidad de tablas). La tabla tiene las fechas correspondientes a un año y los valores relacionados correspondientes:
Desde el archivo establecido en el campo de entrada FECHA, se seleccionan 3 fechas que están dentro del rango de fechas incluidas en la tabla.
El archivo de configuración incluye tres entradas:2019-10-11, 2019-11-11 y 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")
El resultado de este ejemplo es un archivo XML estándar que contiene los valores de búsqueda:
Ejemplo 5 :Realización de una transformación de búsqueda en un trabajo de generación de informes y ETL de IRI Voracity
En este ejemplo, tenemos un archivo CSV que contiene números de cuenta y montos vencidos de varios clientes. Se usará una búsqueda de tabla en dos campos en la salida para obtener información coincidente adicional de una tabla de hechos de clientes maestros en MySQL, con esa tabla sirviendo como tabla de clientes maestros.
La tabla maestra no tiene información sobre el monto adeudado y contiene muchos más clientes que el archivo de entrada que solo muestra cuentas de clientes morosos. Esto busca el nombre y el número de teléfono de la tabla en función del número de cuenta y genera una hoja de cálculo .XLSX en un formato de informe práctico con la información de contacto del cliente.
Ingresar CSV
Fragmento de la tabla maestra de clientes para consultar
/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")
Generar informe de "Vencimiento"
Soporte de banco de trabajo IRI
Las búsquedas en la tabla de la base de datos se pueden configurar como regla desde el Asistente para regla de campo nuevo. Este tipo de regla se denomina "Búsqueda de tabla" en Reglas de generación, pero se puede usar en varios orígenes o destinos como regla de campo en otros trabajos.
Al seleccionar una búsqueda de tabla como regla, un perfil de conexión ya debe estar configurado o creado cuando se le solicite para acceder a las tablas de la base de datos y los nombres de columna para elegir.
Desde allí, seleccione la tabla, la columna de búsqueda y la columna de valor de reemplazo para usar en la búsqueda. Ahora, esta tabla de búsqueda se puede establecer como una regla que se aplicará en función de los emparejadores.
Los conjuntos se pueden modificar desde el tipo de transformación de valor Conjunto:Búsqueda de tabla dentro del cuadro de diálogo del editor de campos.
Esto no es necesario si ya se ha configurado y aplicado una regla de campo de búsqueda de tabla. Sin embargo, este cuadro de diálogo permite la edición manual de componentes de búsqueda de tablas, como DSN, tabla, campo de búsqueda, columna de búsqueda y columna de resultados. Aquí también se puede especificar un valor predeterminado.
Resumen
Las búsquedas establecidas ahora tienen una nueva fuente posible en SortCL que puede expandirse y facilitar la obtención de los datos necesarios para una búsqueda. Esto es útil en operaciones de enmascaramiento o generación de datos para proporcionar valores de reemplazo realistas que preservan las relaciones.
En el futuro, es posible que los conjuntos se amplíen para incluir aún más fuentes de datos. Comuníquese con su representante de IRI para obtener más información.
- Tenga en cuenta que actualmente, los usuarios de RowGen aprovechan los archivos establecidos para la selección aleatoria de valores sin un parámetro de búsqueda. Esta funcionalidad no se admite en la primera implementación de búsquedas en tablas de base de datos. Esto se debe a que cada base de datos tiene un método o sintaxis específicos para seleccionar una fila aleatoria de una tabla; algunas bases de datos pueden no admitir la selección aleatoria en absoluto.
