Présentation
SortCL, le langage IRI de définition et de manipulation de données structurées, a depuis longtemps la capacité de tirer des valeurs de remplacement à partir de fichiers d'ensembles externes contenant deux ou plusieurs colonnes de valeurs. Cette capacité est utilisée pour les transformations de recherche dans les opérations Voracity ETL alimentées par CoSort, les fonctions de pseudonymisation et de restauration FieldShield, et la sélection de données aléatoires / valides dans les tâches de synthèse de données de test RowGen.
Ces fichiers d'ensemble sont parfaits pour les informations qui ne changent pas souvent. Mais comme les fichiers d'ensemble doivent être triés par contenu de colonne, ils peuvent être fastidieux à utiliser lorsque des lignes doivent être ajoutées, en particulier lorsque le fichier d'ensemble est ouvert/en cours d'utilisation.
De plus, le contenu d'un fichier d'ensemble provient souvent en réalité d'une base de données. Dans ces cas, une étape supplémentaire (comme l'exécution de l'assistant IRI Workbench "Définir le fichier à partir de la colonne" ou une opération SQL) devait être ajoutée au flux de travail pour extraire les valeurs d'une table dans un fichier défini.
Pour remédier à ces inconvénients, la recherche directe des valeurs de remplacement à partir des tables de base de données existantes a été activée. Les recherches à partir d'une table de base de données utilisent la même syntaxe et la même structure que les recherches de table déjà en place pour les fichiers d'ensemble. Cela maintient la cohérence fonctionnelle dans les travaux SortCL et permet d'accéder à plus de valeurs (dans plusieurs bases de données et fichiers d'ensemble) à la fois.
Syntaxe
La syntaxe d'attribut de champ SortCL pour accéder aux données dans un fichier d'ensemble était traditionnellement :
SET="<Set_Source>"[<[ Search List ]>] [DEFAULT="string"] [ORDER=<Order Option>] [SELECT=<Select Option>] [SEARCH=<Search Option>]
où
Votre programme SortCL (ou compatible) recherchera alors une correspondance entre la valeur de ce champ et la colonne de recherche dans la base de données. S'il y a une correspondance, la valeur de la colonne de remplacement sur cette ligne sera utilisée comme valeur finale pour le nouveau champ, qui doit avoir un nom différent de celui du champ référencé à partir de l'une des sources d'entrée.
Les colonnes de table utilisées dans la recherche sont spécifiées dans un seul élément de langage supplémentaire à la mise en œuvre initiale du sous-attribut SET : LOOKUP="<lvalue>,<rvaleur>".
Le paramètre lvalue est le nom de la colonne de la table qui contient la valeur à rechercher. Cela correspond à la colonne de gauche ou à la première colonne d'un fichier d'ensemble. La rvalue part correspond à la colonne de droite dans un fichier d'ensemble à deux colonnes et correspond à la colonne contenant la valeur à renvoyer en remplacement.
Comme pour les recherches de fichiers d'ensemble traditionnelles, une valeur par défaut doit être spécifiée s'il n'y a pas de correspondance. La syntaxe DEFAULT=”chaîne”, où “chaîne” est la valeur par défaut spécifiée manuellement, est utilisée. Il ne doit y avoir aucune virgule entre les paramètres de fichier définis.
En mettant tout cela ensemble, un exemple possible de la syntaxe d'une recherche de table pourrait être :
SET=”new_schema.info;DSN=Nouveau MySQL;” [ACCOUNT_NUMBER] RECHERCHE=”NUMÉRO DE COMPTE,NUMÉRO DE TÉLÉPHONE”
Il doit s'agir d'un paramètre dans une définition de champ SortCL. La table "info" doit avoir des colonnes nommées ACCOUNTNUM et PHONENUM dans ce cas.
Comment ces nouvelles recherches d'ensembles pourraient-elles être utilisées en production ? Considérez ces exemples de script de travail IRI :
Exemples
Exemple 1 :pseudonymisez les données à l'aide des valeurs de remplacement d'une base de données.
Cette tâche FieldShield recherche les valeurs de la colonne "id" dans la table nommée "lookuptable" accessible via le DSN "Mangled". Si le champ ID est le même dans l'entrée (un fichier texte) que dans la colonne ID de la table de base de données référencée, alors tous les champs de la sortie (également un fichier texte) seront remplacés par des valeurs de remplacement fausses mais réalistes également à partir du même tableau référencé. S'il n'y a pas de correspondance, les valeurs par défaut spécifiées dans le script seront générées à la place.
/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")
Exemple 2 :pseudonymisez trois colonnes d'une table de base de données en utilisant des valeurs de remplacement provenant d'une base de données différente, et chiffrez la colonne restante.
Ce script effectue une recherche basée sur le champ ID extrait de la table de base de données nommée "inputTable", en regardant la colonne "id" de la table nommée "lookuptable" accessible via le DSN "Mangled". Les valeurs correspondantes dans les colonnes « fakeid », « fakename », « fakessn » et « fakeaddress » seront prises s'il existe une correspondance entre le champ d'ID de données d'entrée et la colonne « id » dans le tableau. S'il n'y a pas de correspondance, les valeurs par défaut seront générées à la place.
La sortie sera envoyée à une table cible distincte. La sortie pourrait également être envoyée à la même table que l'entrée, ce qui masquerait les données en place.
/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")
Exemple 3 :Protéger les informations d'identification personnelle (PII) en utilisant des remplacements réalistes à partir d'un ensemble varié de méthodes de masquage.
Le fichier d'entrée contient des PII dans plusieurs colonnes (champs). S'il y a une correspondance entre le champ du prénom dans le fichier CSV d'entrée et la colonne "FIRST_NAME" dans la table "NAMES", alors un nom de famille de remplacement sera généré à partir de la colonne "LAST_NAME" dans cette même table. Les noms de famille diffèrent dans le tableau "NAMES" des données personnelles elles-mêmes.
/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)
Le même script de travail, décrivant un diagramme de mappage, ainsi que la table de noms d'origine sont présentés dans mon IRI Workbench IDE, construit sur Eclipse, ci-dessous :
Exemple 4 :Générer des données de test référentiellement correctes avec IRI RowGen
Considérez une table de base de données ou, dans d'autres cas potentiels, plusieurs tables contenant des données correspondant à une certaine date. Avec IRI RowGen et la fonctionnalité de recherche de table, il est possible de prendre une sélection de dates (à partir d'un fichier défini ou généré aléatoirement) et d'ajouter plus de champs dans la sortie qui correspondent à des valeurs réalistes basées sur l'entrée de date fournie.
Dans cet exemple, toutes les données correspondantes à partir de la date sont conservées dans la table de recherche illustrée ci-dessous (bien qu'elles puissent provenir de n'importe quel nombre de tables). Le tableau contient les dates d'une année et les valeurs associées correspondantes :
À partir du fichier défini dans le champ de saisie DATE, 3 dates sont sélectionnées dans la plage de dates incluses dans le tableau.
Le fichier d'ensemble comprend trois entrées :2019-10-11, 2019-11-11 et 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")
La sortie de cet exemple est un fichier XML standard contenant les valeurs de recherche :
Exemple 5 :Exécution d'une transformation de recherche dans un ETL de voracité IRI et une tâche de création de rapports
Dans cet exemple, nous avons un fichier CSV contenant des numéros de compte et des montants en souffrance pour plusieurs clients. Une recherche de table sera utilisée dans deux champs de la sortie pour obtenir des informations correspondantes supplémentaires à partir d'une table de faits client principale dans MySQL, cette table servant de table client principale.
La table principale ne contient pas d'informations sur le montant dû et contient beaucoup plus de clients que le fichier d'entrée qui ne montre que les comptes clients en souffrance. Celui-ci recherche le nom et le numéro de téléphone dans le tableau en fonction du numéro de compte et les génère dans une feuille de calcul .XLSX dans un format de rapport pratique avec les coordonnées du client.
Entrée CSV
Extrait de la table principale des clients à consulter
/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")
Sortie du rapport "Past Due"
Prise en charge de l'atelier IRI
Les recherches de table de base de données peuvent être configurées en tant que règle à partir de l'assistant Nouvelle règle de champ. Ce type de règle est appelé "Table Lookup" sous Generation Rules, mais il peut être utilisé dans plusieurs sources ou cibles en tant que règle de champ dans d'autres travaux.
Lors de la sélection d'une recherche de table en règle générale, un profil de connexion doit être déjà configuré ou créé lorsque vous y êtes invité afin d'accéder aux tables de base de données et aux noms de colonne parmi lesquels choisir.
À partir de là, sélectionnez la table, la colonne de recherche et la colonne de valeur de remplacement à utiliser pour la recherche. Désormais, cette recherche de table peut être définie comme une règle à appliquer en fonction des correspondances.
Les ensembles peuvent être modifiés à partir du type de transformation de valeur Ensemble :Consultation de table dans la boîte de dialogue de l'éditeur de champ.
Cela n'est pas nécessaire si une règle de champ de recherche de table a déjà été configurée et appliquée. Cependant, cette boîte de dialogue permet l'édition manuelle des composants de recherche de table tels que DSN, table, champ de recherche, colonne de recherche et colonne de résultat. Une valeur par défaut peut également être spécifiée ici.
Résumé
Les recherches d'ensemble ont désormais une nouvelle source possible dans SortCL qui peut considérablement étendre et faciliter l'obtention des données nécessaires à une recherche. Ceci est utile dans les opérations de masquage ou de génération de données pour fournir des valeurs de remplacement réalistes qui préservent les relations.
À l'avenir, les ensembles pourraient être élargis pour inclure encore plus de sources de données. Contactez votre représentant IRI pour plus d'informations.
- Notez qu'actuellement, les utilisateurs de RowGen exploitent les fichiers d'ensemble pour la sélection aléatoire de valeurs sans paramètre de recherche. Cette fonctionnalité n'est pas prise en charge dans la première implémentation des recherches de table de base de données. En effet, chaque base de données a une méthode ou une syntaxe spécifique pour sélectionner une ligne aléatoire dans une table ; certaines bases de données peuvent ne pas prendre en charge la sélection aléatoire du tout.
