Introducción

Optim Development Studio (ODS) V2.2 e InfoSphere Data Architect (IDA) V7.5.2 incluyen mejoras que brindan soporte específico de roles con el fin de asegurar que su información confidencial e identificable a nivel personal quede adecuadamente privatizada cuando se generan entornos de prueba de tamaños adecuados. Optim Test Database Management (TDM) ofrece esta funcionalidad, así como la capacidad de trabajar con objetos de negocios completos para asegurar que las bases de datos dentro de los entornos de prueba del desarrollo se generen como entidades intactas en lo referencial. Las mejoras en IDA y ODS le brindan las características de integración que usted necesita para crear trabajos que se puedan ejecutar con TDM (versiones 6.5 o 7.1), lo cual amplía la base de usuarios de su instalación TDM.

En numerosos entornos, los administradores de datos implementan y administran la solución TDM. En consecuencia, es probable que la solución no esté disponible para que los desarrolladores creen entornos de prueba desde la base de datos de producción. A menudo, los desarrolladores crean bases de datos según sus necesidades, e incluso copian bases de datos directamente de las bases de datos de producción, sin darse cuenta de la necesidad de privatizar la información confidencial o personal que se incluye en las mismas. El uso de datos reales y no privatizados para desarrollos y pruebas coloca a las empresas en una situación de riesgo, y puede llegar a violar las disposiciones empresariales en materia de control y cumplimiento de los datos. Más aún, las bases de datos creadas manualmente que no incluyen datos confidenciales o personales por lo general no aseguran que los datos de prueba estén intactos en el aspecto referencial y sean una representación consistente de la aplicación. Estos datos no confidenciales no permiten a los desarrolladores reproducir un defecto de manera exacta ni realizar pruebas realistas y adecuadas.

Con el nuevo soporte de IDA, los arquitectos de datos y los administradores de bases de datos pueden definir las políticas y reglas adecuadas de privacidad de datos necesarias para proteger los datos confidenciales e identificables a nivel personal. Los desarrolladores pueden usar ODS para aprovechar al máximo estos metadatos de privacidad de los datos con el fin de generar una solicitud de TDM en Optim. Dentro de ODS, este soporte de IDA se encuentra integrado con la nueva funcionalidad de copia de objetos datos para copiar los objetos bases de datos y los datos de bases de datos homogéneas y heterogéneas, como se describe en el artículo "What's new and cool in Optim Development Studio" [Qué hay de nuevo y qué hay de bueno en Optim Development Studio] (ver Recursos).

Al usar las características de integración de Optim TDM, ODS copia las definiciones de las tablas y los objetos referencialmente relacionados de las bases de datos seleccionadas. ODS genera un archivo de exportación en Optim (OEF) que contiene metadatos sobre:

• Las tablas seleccionadas
• El criterio de selección del subconjunto de datos
• Los metadatos de privacidad de los datos

El resultado que se obtiene es el conjunto completo de objetos de base de datos necesarios creados en la base de dato destino con un subconjunto referencialmente completo de datos privatizados que se copiaron de la base de datos de origen. Los desarrolladores cuentan con un entorno más seguro y completo en el cual realizar sus pruebas.

Este artículo supone que usted cuenta con un conocimiento básico sobre la terminología de las bases de datos. Es conveniente, aunque no necesario, estar familiarizado con los productos IDA, ODS, y TDM. Este artículo muestra el proceso con suficiente detalle como para que no sea necesario un conocimiento completo de los productos.

La siguiente sección, Diagramación del proceso, examina el flujo del proceso con un alto nivel. Las secciones siguientes describen un ejemplo de escenario que ilustra los pasos de manera más detallada.

Diagramación del proceso

El ejemplo de escenario supone un conjunto típico de roles dentro de una organización, aunque es posible que la suya tenga una división de responsabilidades diferente.

1. Con IDA, el arquitecto de datos crea un modelo de datos físicos para una conexión particular entre bases de datos. Luego, el arquitecto de datos crea un modelo de dominio, con un conjunto de dominios atómicos, cada uno de los cuales describe los métodos de enmascaramiento para privacidad de datos requeridos para un dominio en particular, como por ejemplo, datos de tarjetas de créditos Entonces, el arquitecto de datos puede asociar estos dominios atómicos a las columnas físicas del modelo de datos físicos.
   
   
2. Los desarrolladores que usan ODS pueden entonces asociar su modelo de datos físicos a las conexiones de sus bases de datos particulares. Observe que esta asociación también permite a los desarrolladores ver cuáles son las columnas que requieren un manejo especial en la aplicación debido a la naturaleza privada de los datos incluidos en ellas.
   
   
3. Para crear una base de datos de prueba, los desarrolladores pueden usar la funcionalidad copiar y pegar del objeto dato de ODS de la base de datos de producción de origen (que contiene datos privados) a sus bases de datos de prueba destino (que contiene solamente datos privados desidentificados). Con la operación de copiar y pegar se genera la nueva base de datos destino y el archivo exportar de Optim que contiene información en forma de metadatos que usa Optim TDM para generar los datos adecuadamente privatizados.
   
   
4. El archivo exportar se importa a Optim TDM. El administrador de bases de datos usa TDM para copiar los datos adecuados de la base de datos de producción a la base de datos de prueba que creó el desarrollador..
   
   
5. De este modo, el desarrollador puede estar seguro de que los datos de prueba constituyen un subconjunto intacto y adecuadamente desidentificado.

Volver arriba

Presentación del ejemplo de escenario

Tom, arquitecto de datos ficticio de Great Outdoors Company, realiza un modelado de datos para la organización. Ha definido las reglas y los métodos de enmascaramiento de privacidad de datos para la base de datos GSDB usada por sus desarrolladores. Tom usa InfoSphere Data Architect (IDA) para sus tareas de modelado.

Roslyn, desarrolladora de Great Outdoors, brinda soporte a una aplicación para bases de datos que se ejecuta con una base de datos de ventas clave denominada GSDB en DB2® para las plataformas Linux®, UNIX®, y Windows®. Ella usa ODS para ayudar a modificar la aplicación y la base de datos de manera que puedan ejecutarse también en la plataforma Oracle. Roslyn hizo algunos cambios en el punto de partida de su DB2 LUW V9.7, y ahora debe copiar los objetos actualizados de su base de datos DB2 a la base de datos de prueba Oracle 11g para verificarlos y validarlos en esa plataforma. Usa Optim Development Studio para llevar a cabo las tareas de desarrollo de la base de datos.

Tom ha determinado que en base a los requerimientos de Roslyn, ella trabajará con el esquema GOSALECT en GSDB. En la base de datos de prueba de Roslyn, se deberán enmascarar los siguientes campos de dicho esquema:

• Número de Seguridad Social
• Número de tarjeta de crédito
• Dirección de correo electrónico del cliente
• Apellido del cliente

Eric, administrador de bases de datos de Great Outdoors, es responsable del mantenimiento de la aplicación GSDB. Una de las tareas que debe realizar consiste en crear y actualizar las instancias de las bases de datos de prueba para los desarrolladores de GSDB. Usa Optim TDM con la Opción Data Privacy (privacidad de datos).

Volver arriba

Definición de los dominios de privacidad y su asociación con el modelo de datos físicos

1. Con InfoSphere Data Architect, Tom crea un nuevo proyecto de diseño de datos para incluir todos los artefactos (modelos de datos y metadatos) de este proyecto particular. En Data Project Explorer, presiona New>Data Design Project para abrir la ventana del nuevo proyecto de diseño de datos, como se muestra en la Figura 1. Luego, da un nombre al proyecto.

2. Tom crea un nuevo modelo de datos físicos (PDM por su denominación en inglés) dentro del nuevo proyecto de diseño de datos seleccionando Create > New > Physical Data model, como se muestra en la Figura 2. Observe que no es absolutamente necesario crear un nuevo PDM, debido a que los artefactos pueden agregarse a un modelo existente. En este escenario, Tom elige crear un nuevo modelo que incluya sólo los dominios que contienen estos metadatos de enmascaramiento de privacidad en particular. La lógica que aplica es que él sólo desea presentar estos metadatos en particular a los desarrolladores.

3. Por medio del asistente virtual, Tom da un nombre al nuevo PDM, y establece que deberá ser compatible con su instancia de base de datos DB2 LUW V9.7. Desea generar el modelo mediante una ingeniería inversa de la base de datos GSDB existente. Selecciona esta base de datos en el recuadro de conexión, como se muestra en la Figura 3.

4. El nuevo PDM se crea dentro del proyecto actual. Ahora, Tom puede manejar el PDM con Data Project Explorer, como se muestra en la Figura 4. Los objetos de la base de datos seleccionados de la pestaña Database Elements (Elementos de la base de datos) aparecen en el orden jerárquico. Tom puede verificar los esquemas GOSALES y GOSALESCT importantes desde la base de datos GSDB.

5. Ahora, Tom puede crear un nuevo modelo de dominio, como se muestra en la Figura 5.

6. Luego de hacer clic en Finish, aparecerá el nuevo modelo de dominio en el Data Project Explorer. Además, se crea un paquete predeterminado, Package1.
   
   
7. En este momento, Tom define un nuevo dominio atómico para cada una de las definiciones de privacidad que desea crear seleccionando la opción Data Models > New > Domain Model, como se muestra en la Figura 6. De manera iterativa, crea las definiciones del dominio atómico seleccionando AddData Object del menú de Package1.

8. La ventana de Dominio Atómico describe la información clave sobre privacidad de datos para cada una de las columnas de datos. En la pestaña General, Tom escribe el nombre del dominio, el tipo de base, la extensión de la base, la precisión y la escala. Debido a que Roslyn usará una tabla determinada de la base de datos, esta información deberá corresponder a la definición de las columnas de la base de datos subyacente. En este momento, el dominio no se encuentra asociado con ninguna conexión, de modo que esta información no se encuentra precargada con la información de la base de datos.

   La pestaña Data Privacy incluye la información y los metadatos de privacidad de los datos reales. Para clasificarlos, Tom puede especificar si el dominio atómico en particular representa información personal identificable (PII por su denominación en inglés) o información confidencial. Para su aplicación, Tom puede elegir si la política de aplicación es Necesaria, No necesaria, o Mejor ráctica. El tipo de política de privacidad contiene numerosas categorías comunes de PII, que incluyen número de tarjeta de crédito, número de Seguridad Social, número aleatorio, etc. Estas categorías ayudan a determinar cuáles de los algoritmos de enmascaramiento de privacidad de datos se deben usar para los datos especificados. Basado en el tipo de política de privacidad, existen numerosas políticas que se pueden usar para realizar el enmascaramiento. Según la aplicación, puede resultar preferible cierto nivel de autenticidad, como por ejemplo un número de Seguridad Social aleatorio con un número de área de origen válido.

   Tom crea el dominio atómico para el número de Seguridad Social (SSN), identificándolo como un campo numérico (DOUBLE). Es posible que algunas aplicaciones, en cambio, representen los SSN como un carácter. Tom sabe que GSDB realiza una validación numérica en este campo, y lo marca como DOUBLE. La ventana de dominio atómico general para SocialSecurityNumber (Número de Seguridad Social) se muestra en la Figura 7.

9. En la pestaña Data Privacy, Tom indica lo siguiente para el número de Seguridad Social, como se muestra en la Figura 8:
   • Este dominio contiene Información personal identificable .
   • La aplicación es Necesaria.
   • Los datos se tratan como Social Security Number (SSN).
   • Use el algoritmo que genera un SSN aleatorio con un número de área de origen válido (primeros 3 dígitos).

10. Tom crea un dominio atómico para el número de tarjeta de crédito, identificándolo como un campo de caracteres (CHAR 19). La Figura 9 muestra la ventana de dominio atómico general para CreditCardNumber (número de tarjeta de crédito).

11. En la pestaña Data Privacy, Tom indica los siguientes datos para el número de tarjeta de crédito, como se muestra en la Figura 10:
    • Este dominio contiene Información personal identificable.
    • La aplicación es Necesaria.
    • Los datos se tratan como un Credit Card Number (CCN).
    • Use el algoritmo que genera un CCN aleatorio con los primeros cuatro dígitos del emisor identificados.
    Tom sabe que la aplicación GSDB realiza una validación del número de tarjeta de crédito, y quiere asegurarse de que la lógica de la aplicación identificará correctamente los números de tarjetas de crédito generados de manera aleatoria.

12. En la pestaña Data Privacy, Tom indica lo siguiente para la dirección de correo electrónico del cliente, identificándola como un tipo de datos VARCHAR (128), como se muestra en la Figura 11:
    • Este dominio contiene Información personal identificable.
    • La aplicación es Necesaria.
    • Use el algoritmo que genera una dirección de correo electrónico aleatoria en minúscula para este tipo de datos.

13. Por último, Tom crea el dominio atómico para el apellido del cliente. En la pestaña Data Privacy, Tom indica lo siguiente para el apellido del cliente, identificándolo como un tipo de datos VARCHAR (128), como se muestra en la Figura 12:
    • Este dominio contiene Información personal identificable .
    • La aplicación es Necesaria.
    • Use el algoritmo que genera un algoritmo de reordenamiento aleatorio para generar nombres de usuarios al azar.

14. A medida que se crean los nuevos dominios atómicos, los mismos se agregan al paquete y al modelo de dominio. El modelo de dominio actualizado aparece en Data Project Explorer, como se muestra en la Figura 13.

15. Tom se asegura de guardar el modelo, como se muestra en la Figura 14.

16. Ahora, Tom asocia los modelos de dominio con las columnas específicas en el modelo de datos físicos que representan el esquema GSDB. En primer lugar, ubica las columnas deseadas en el modelo de datos físico (previamente creado), DatabaseModel.dbm. Tom ubica la columna GOSALESCT.CUST_SSN en el PDM, como se muestra en la Figura 15.

17. En la vista Properties (Propiedades) de esta columna, Tom selecciona la pestaña Type (Tipo). Para el campo Domain (Dominio), Tom selecciona la elipsis (marcada con un círculo). Aparece una ventana que muestra los dominios atómicos que se han creado en el proyecto. Tom puede ver los cuatro dominios atómicos que ha creado. Selecciona el modelo de dominio SocialSecurityNumber, y hace clic en OK.

Observe que este dominio atómico se define como DOUBLE, mientras que el tipo de datos para la columna de la base de datos (determinada mediante ingeniería inversa) es BIGINT. DOUBLE es el tipo genérico que se usa en diversos modelos. BIGINT es el tipo para DB2. Distintos DBMS poseen distintos tipos de bases de datos. En algunos casos, tienen el mismo nombre, pero en otros (como en este caso) no. Para este escenario en particular, estos tipos de datos son compatibles.

18. Una vez seleccionado OK, la columna CUST_SSN se mostrará ahora en Data Project Explorer con un ícono de candado, lo cual indica que ahora cuenta con atributos de privacidad, como se muestra en la Figura 17.

19. Tom repite este proceso con los otros tres dominios atómicos que ha creado:
    • El dominio CustEmail se asocia con la columna CUST_EMAIL de la tabla GOSALESCT.CUST.
      
      
    • El dominio CreditCardNumber se asocia con la columna CRDTCRD_PRIM_ACCT_NBR de la tabla GOSALESCT.CUST_CRDTCRD .
      
      
    • El dominio CustLastName se asocia con la columna CUST_LAST_NAME de la tabla GOSALESCT.CUST.

    Cuando Tom completa la asociación de dominios correspondiente a los cuatro nuevos dominios atómicos, Data Project Explorer muestra cuatro columnas en el modelo físico con atributos de enmascaramiento de privacidad, como se muestra en la Figura 18.

20. Tom desea que estos cambios se hagan visibles cuando otros usuarios utilicen este modelo. Por lo tanto, guarda los cambios en el modelo de datos físicos haciendo clic con el botón derecho del Mouse sobre Database Models.dbm*, y seleccionando Save (Guardar), como se muestra en la Figura 19.

Volver arriba

Generación de una base de datos de prueba

Tom ha creado un modelo de datos físicos que contiene dominios de enmascaramiento de privacidad para enmascarar los datos incluidos en las cuatro columnas de la base de datos GSDB que él ha establecido para que contenga información sensible personal identificable. Ahora, los desarrolladores de Great Outdoors, como por ejemplo Roslyn, pueden usar este modelo para generar bases de datos de prueba con Optim Development Studio y la solución Optim Test Data Management.

1. Antes deasociartel modelo físico con su conexión a GSDB, Roslyn examina su conexión a GSDB y observa las tablas de los esquemas GOSALES y GOSALESCT. En el Data Source Explorer de Optim Development Studio, las columnas que han sido identificadas para su enmascaramiento no muestran ahora el ícono del candado, lo cual significa que los datos contenidos en estas columnas no han sido enmascarados, como se muestra en la Figura 20. Si ella quisiera copiar los datos en este momento, los mismos no contarían con metadatos de privacidad asociados, de manera que los datos no estarían adecuadamente desidentificados. Ella deberá completar la asociación del modelo para asegurar que las subsiguientes solicitudes de copia de datos que realice generen datos desidentificados.

2. Debido a que Tom indicó su especificación de datos privados, Roslyn debe asegurarse de que su trabajo se implemente correctamente asociando su conexión a la base de datos con el modelo de Tom. Ella importa el proyecto guardado por Tom desde el repositorio de proyectos. Usa la opción Import de Data Project Explorer, y selecciona Existing Project into Workspace (Proyecto existente en el espacio de trabajo), como se muestra en la Figura 21. Por último, consulta la ubicación del proyecto, lo selecciona y presiona sobre Finish (Finalizar). Entonces, el proyecto será importado a su espacio de trabajo.

3. Roslyn asocial el modelo físico del proyecto importado con su conexión a la base de datos GSDB. En Data Source Explorer, hace clic con el botón derecho del mouse sobre la conexión a la base de datos y selecciona Properties, como se muestra en la Figura 22.

4. En la pestaña Data Privacy Modeling (Modelado de privacidad de datos) de la pantalla Properties, Roslyn busca el modelo de datos físicos que acaba de importar y presiona OK para asociar este modelo de datos físicos con la conexión, como se muestra en la Figura 23.

5. Cuando Roslyn visualiza el esquema GOSALESCT, las columnas CUST, CUST_CRDT_CHK, y CUST_CRDTCRD se encuentran ahora marcadas con el ícono de candado, lo cual muestra que poseen metadatos de privacidad asociados, como se muestra en la Figura 24.

   La asociación de metadatos de privacidad debe realizarse una vez por cada conexión, a menos que cambie el modelo de datos físicos. En el ejemplo de escenario, si Tom decide que haya otras columnas que requieran enmascaramiento, podrá actualizar este modelo y luego notificar a los desarrolladores que se vean afectados. Roslyn, entonces, debería también actualizar su modelo. Ahora que ella ha asociado el modelo físico con la conexión a la GSDB de este espacio de trabajo, sin embargo, no deberá repetir la actividad. La Figura 24 muestra las columnas actualizadas en Data Source Explorer.

6. Roslyn modifica la estructura de las tablas CUST, CUST_CRDT_CHK, y CUST_CRDTCRD de su base de datos GSDB dentro de su instancia DB2. Crea un esquema de prueba, DEMO, en su instancia de base de datos de Oracle 11 para continuar su desarrollo sobre dicha plataforma. Desea copiar estas tablas a su base de datos de prueba en Oracle con el fin de determinar si los cambios que ha realizado en la estructura y las aplicaciones se adecuan a dicho entorno. Usa la nueva funcionalidad copiar y pegar para el objeto datos de ODS para copiar y pegar desde la conexión DB2 a la conexión Oracle. Elige las tablas de origen que copiará y selecciona Copy (Copiar), como se muestra en la Figura 25.

7. Con el botón derecho del mouse, Roslyn hace clic sobre el esquema DEMO de su conexión Oracle 11 y selecciona Paste (Pegar), como se muestra en la Figura 26.

8. Se abrirá la ventana Pegar Paste Database Objects (Pegar objetos de la base de datos). Esta ventana se usa para especificar las siguientes opciones:
   • Si el pegado se producirá directamente del origen al destino. Los objetos datos se crean de inmediato, y los datos se copian directamente desde el origen hasta el destino. Esta opción no utiliza los metadatos de privacidad establecidos ni genera el archivo de exportación de Optim TDM.
     
     
   • Si se debe crear un subconjunto de datos de prueba con enmascaramiento opcional. Esta opción indica que se usarán los metadatos de privacidad y que se generará un archivo de exportación para ser usado con Optim TDM.
     
     
   • Si se debe pegar usando la funcionalidad Change Management (Gestión de cambios) del Optim Database Administrator (ODA). Esta opción se encuentra disponible cuando ODS y ODA comparten el shell, y cuando la combinación origen-destino puede procesarse con la funcionalidad de gestión de cambios de ODA. En el entorno del ejemplo, Roslyn no tiene ODA instalada, y debido a que cuenta con una base de datos de origen DB2 y una base de datos de destino Oracle, la combinación no tendrá soporte en ODA.

   El vínculo Upgrade (Actualizar) brinda información sobre otros productos de IBM que se pueden usar para realizar la operación de copiar y pegar solicitada.

   Roslyn elige Pegar con un subconjunto de datos de prueba y enmascaramiento de privacidad opcional, como se muestra en la Figura 27.

   Observe que, si bien no es necesario en el ejemplo de escenario, la opción de pegar directamente en un destino está limitada en cuanto a la cantidad de objetos de base de datos y de datos que se pueden copiar en una única operación. El límite es actualmente de 100 objetos y 10.000 filas de datos. Cuando se usa Optim TDM para crear un subconjunto de datos de prueba, la aplicación no impone límite alguno a la cantidad de filas que se pueden copiar.

9. Roslyn presiona el botón Next (Siguiente) para iniciar el asistente virtual de Advanced Options (Opciones avanzadas), como se muestra en la Figura 28. Estas pantallas opcionales permiten cierta personalización de la operación copiar y pegar. Algunas de las opciones del asistente virtual incluyen:
   • En la sección Data and Object Options (Opciones de datos y objetos), sólo se encuentra disponible la opción Copy Database Objects and Data (Copiar objetos y datos de la base de datos), debido a que Roslyn ya eligió crear un subconjunto de prueba con enmascaramiento de privacidad. El enmascaramiento es para los datos, por lo cual resulta evidente que los datos de la tabla formarán parte de esta solicitud.
     
     
   • En la sección Other Options (Otras opciones), queda seleccionada de manera predeterminada la opción de copiar objetos dependientes de la base de datos. Esto se debe a que para crear un conjunto de datos referencialmente intacto, los objetos de los cuales dependen los objetos seleccionados también deben ser copiados. Los objetos contenidos son aquellos que se encuentran totalmente incluidos en un objeto de base de datos seleccionado en Data Source Explorer. Por ejemplo, las activaciones, las restricciones, y los índices se encuentran incluidos en una tabla particular.
     
     
   • Si Roslyn desea usar un espacio de tabla para las nuevas tablas en la base de datos de destino, lo especificará en esta ventana. Si no se define ningún espacio de tabla, para las nuevas tablas se usará el espacio de tabla predeterminado. Si se marca la casilla de verificación Generate Tablespace Names (Generar nombres para espacios de tabla) pero no se coloca un nombre, se usará el nombre del espacio de tabla de origen al generar la tabla de destino.

10. En la pestaña Type Mapping (Mapeo de tipo), Roslyn puede personalizar el mapeo de tipo de datos que se usa al generar los enunciados DDL para la base de datos de destino, y presionar Next, como se muestra en la Figura 29. La primera columna representa el tipo de datos de origen (en el caso de Roslyn: DB2), y la segunda columna representa el tipo de datos de destino (Oracle). Los mapeos recomendados están fijados de manera predeterminada.

11. En la pestaña Error Handling (Manejo de errores), Roslyn puede personalizar el modo de informar los errores, como se muestra en la Figura 30. Ella elige informar tanto errores como advertencias, lo cual se encuentra predeterminado. El comportamiento transaccional se puede especificar en la sección Error Response (Respuesta a los errores). El comportamiento transaccional predeterminado es el auto-commit, en el cual cada uno de los enunciados se consigna cuando se envía al servidor de destino. Si Roslyn desea que la ejecución de DDL se detenga al encontrar el primer error, puede seleccionar esta opción. En base a las capacidades de la base de datos de destino, también puede retrocederse el DDL. Para el ejemplo de escenario, sin embargo, esta opción se encuentra inactiva, debido a que Roslyn está creando tablas en su instancia de Oracle, lo cual significa que no puede incluir el DDL de creación de tablas en una transacción.

12. En la siguiente ventana, Roslyn establece las opciones de Optim TDM para generar un conjunto de datos referencialmente intactos, como se muestra en la Figura 31. Los campos de esta ventana incluyen:
    • Start table (Tabla de inicio): Este campo incluye la tabla clave que se usa como base para la selección del subconjunto de datos. Por ejemplo, si Roslyn desea que su subconjunto contenga datos para 1000 clientes, deberá seleccionar CUST como tabla de inicio. Los registros de las otras tablas se seleccionarán en base a la tabla de inicio.
      
      
    • Target Scheme (Esquema de destino): Este campo identifica dónde se copiarán el objeto de los datos y los datos. Tiene solamente propósitos informativos.
      
      
    • Tables (Tablas): Este campo consiste en la lista de tablas que se seleccionaron en la operación de copiado. ODS determina las relaciones entre las tablas seleccionadas y agrega las tablas dependientes a la lista, si fuera necesario. En el ejemplo de escenario, Roslyn no seleccionó la tabla CUST_STATE_TAX, sino que ODS determinó que se encontraba referencialmente relacionada con las tablas que se seleccionaron.
      
      
    • Reference tables (Tablas de referencia): Este campo muestra las tablas que se encuentran referencialmente relacionadas con la tabla de inicio. Inicialmente se seleccionan todas las tablas (con la casilla de verificación), pero luego de que se selecciona una tabla de inicio, las selecciones de tablas cambiarán.
      
      
    • Filter (Filtrar): Este campo es un enunciado en SQL que se usa para seleccionar las filas de esta tabla.
      
      
    • Row limit (Límite de filas): Este campo indica el máximo de filas sugerido para la selección en esta tabla. El valor 0 indica un valor ilimitado. Los límites a las tablas que no sean la de inicio pueden respetarse o no, debido a que los calores de la tabla de inicio determinan cuáles (y cuántas) filas se seleccionarán de las demás tablas.
      
      
    • Documentation (Documentación): Este campo muestra los comentarios asociados con esta tabla en el modelo físico. Tiene solamente propósitos informativos.
      
      
    • Export location (Exportar ubicación): Este campo consiste en el lugar donde se deberá guardar el archivo de exportación.
      
      
    • Physical Data Model: Este campo muestra el nombre del modelo asociado con esta conexión.

13. Roslyn completa la ventana Privacy Masking, como se muestra en la Figura 32. Selecciona CUST como tabla de inicio, y especifica c:\temp\GSDB_CustInfo.txt como la ubicación local en la cual se guardará el archivo de exportación. Revisa el PDM y el esquema de destino a fin de asegurarse de que sean correctos. Luego de revisar el código de su aplicación, acuerda en que también se deberá copiar la tabla CUST_STATE_TAX junto con las demás tablas que ha seleccionado. Deja esta tabla marcada como tabla de referencia.

14. Cuando Roslyn selecciona Next, los objetos de la base de datos DB2 seleccionados son traducidos a objetos de base de datos Oracle equivalentes, con lo cual se generan los enunciados en DDL que ella puede ver previamente en la pestaña Preview DDL (Vista previa en DDL), como se muestra en la Figura 33. Puede ejecutar los enunciados en DDL en el servidor de destino, abrir el archivo para editarlo, o puede hacer ambas cosas. Si abre el archivo para editarlo, aparecerá en el proyecto predeterminado (que se puede modificar con el botón Browse) usando el nombre de archivo que se muestra.

15. Cuando Roslyn selecciona Finish, se ejecutan los enunciados en DDL en la base de datos de destino de Oracle. Se crean cuatro tablas (CUST_STATE_TAX, CUST, CUST_CRDT_CHK, y CUST_CRDTCRD), junto con los índices y las restricciones correspondientes. Los resultados de esta operación pueden verificarse en la vista SQL Results (Resultados en SQL), como se muestra en la Figura 34.

16. Usando el Data Source Explorer, Roslyn también puede visualizar las nuevas tablas, los nuevos índices y las nuevas restricciones en el esquema DEMO de su conexión Oracle 11, como se muestra en la Figura 35.

17. Además, Roslyn tiene acceso a una vista previa del archivo de exportación que se genera en la ubicación especificada, como se muestra en la Figura 36. Este es un simple archivo de texto, pero no contiene instrucciones en lenguaje natural, debido a que el mismo será procesado por Optim TDM con el fin de copiar los datos de las tablas de origen especificadas (DB2) en las tablas de destino (Oracle) recientemente creadas.

Volver arriba

Implementación de los datos de prueba privatizados

Para poder completar el proceso de generación de datos de prueba, Eric, el administrador de la base de datos (DBA) que brinda soporte a GSDB en Great Outdoors debe importar el archivo OEF que Roslyn creó en ODS a Optim Test Data Manager. Los siguientes pasos ilustran el proceso de implementación de los datos de prueba con privacidad usando el archivo OEF generado en el escenario del ejemplo.

1. En la consola TDM (Versión 6.5), Eric selecciona Utilities>Import, como se muestra en la Figura 37.

El asistente de importación permite al usuario de TDM importar una cantidad de artefactos a un repositorio. El OEF de Roslyn contiene definiciones de acceso (Access Definition - AD) y solicitud de extracción. La solicitud de extracción contiene los metadatos sobre las tablas de las bases de datos de origen seleccionadas. La AD contiene metadatos adicionales sobre las relaciones y dependencias entre estas tablas, información sobre otras tablas e información sobre el enmascaramiento de privacidad.

2. Usando el asistente de importación, Eric carga el archivo de ingreso buscando el archivo OEF en el sistema de archivos. En las lista Definitions (Definiciones), Eric elige importar la Access Definition y solicitar Extract (Extracción). Presiona sobre el ícono Run (Ejecutar) (ícono del hombre corriendo). El estado de la importación se muestra en el casillero de la lista Import Progress (Progreso de la importación). Eric selecciona el OEF y elige importar una definición de acceso, como se muestra en la Figura 38.

3. Eric desea trabajar la solicitud de extracción que se acaba de importar. En la consola de Optim, selecciona la opción Extract del menú Actions (Acciones), como se muestra en la Figura 39.

4. Eric se encuentra con la ventana Open an Extract Request (Abrir una solicitud de extracción) en donde puede especificar cuál es la solicitud de extracción del repositorio con la cual desea trabajar, como se muestra en la Figura 40. Él sabe que Roslyn está trabajando con los esquemas GOSALES y GOSALESCT en GSDB, de modo que especifica el comodín GOSALES.% para ubicar la solicitud de extracción. Encuentra la solicitud de extracción GOSALES en el casillero de la lista Identifier (Identificador).

5. Eric presiona sobre Open (Abrir) para abrir esta solicitud de extracción. La solicitud de extracción se encuentra ahora abierta en el repositorio, y la ventana del Extract Request Editor (Editor de solicitudes de extracción) correspondiente a la solicitud de extracción de GOSALES aparece con las opciones predeterminadas, como se muestra en la Figura 41. Esta ventana permite a Eric gestionar una solicitud de extracción en particular. La siguiente lista describe algunas de las opciones de la pestaña General:
   • El nombre de la solicitud de extracción actual se encuentra en la barra de título.
     
     
   • Se puede asociar una descripción de texto con una solicitud determinada con el fin de ayudar a diferenciar las solicitudes en solicitudes de extracción similares.
     
     
   • A medida que se procesa el OEF, se divide lógicamente en objetos de repositorio independientes. El archivo de extracción muestra el objeto de repositorio que contiene la información sobre la extracción.
     
     
   • La sección Access Definition Options (Opciones de definición de acceso) indica ya sea definiciones Locales (generadas de manera local) o definiciones Con nombre (según lo especificado en la definición de acceso). El Access Definition Name (Nombre de la definición de acceso) muestra el nombre del objeto del repositorio que contiene los metadatos de la definición de acceso.
     
     
   • El campo Items to Extract (Artículos a extraer) muestra los datos y/u objetos a extraer.
     
     
   • El campo Row Limit muestra el límite de filas que se deberá aplicar a la tabla de inicio.
     
     
   • Las demás casillas de verificación especifican el comportamiento a seguir luego de la extracción.

6. En lugar de elegir la opción predeterminada de extraer datos y objetos, Eric sólo desea extraer datos debido a que Roslyn ya ha copiado los objetos de la base de datos de su instancia DB2 a la base de datos de destino Oracle. Luego de validar todas las opciones, Eric selecciona el ícono Run para iniciar el proceso de extracción.

   La solicitud de extracción genera un informe detallado sobre los datos de origen extraídos. Eric verifica el proceso de extracción a fin de encontrar errores graves. Si Eric encuentra cualquier error, lo arregla y luego vuelve a ejecutar la solicitud de extracción.

Volver arriba

Inserción de datos de prueba en el destino con enmascaramiento de privacidad

Luego de que Eric extrae exitosamente los datos de la base de datos de origen DB2, el paso siguiente consiste en cargarlos en la base de datos de destino Oracle de Roslyn. Observe que en TDM, los procesos de extracción e inserción son diferentes. Una de las ventajas de este enfoque es que Eric puede usar el mismo conjunto de datos extraídos para cargar en múltiples bases de datos de destino.

1. En la consola Optim, Eric selecciona Actions > Insert, como se muestra en la Figura 42.

2. Se abre la ventana Open an Insert Request (Abrir una Solicitud de inserción), que comprensiblemente es similar a la ventana de solicitud de extracción que Eric acaba de completar. Selecciona el identificador GOSALES del repositorio e ingresa el nombre INSERT como patrón para identificar a la solicitud de inserción. Selecciona entonces Open para abrir la solicitud de inserción, como se muestra en la Figura 43.

3. La solicitud de inserción se encuentra ubicada en el repositorio y está abierta. Aparece el Insert Request Editor (Editor de solicitudes de inserción), muy similar al Extract Request Editor. El editor se completa con metadatos predeterminados basados en la operación y los nombres provistos en la solicitud. Eric revisa las configuraciones predeterminadas y selecciona el ícono Run. Se abre una ventana de estado, que se actualiza a medida que se inicia y ejecuta la inserción, como se muestra en la Figura 44.

4. La solicitud de inserción genera además un informe al finalizar el proceso. Eric verifica que no haya errores, y en caso de descubrirlos, los soluciona para luego volver a ejecutar la solicitud de inserción.
   
   
5. Luego de completada la operación de inserción, la ventana de estado mostrará cuántas filas se han procesado, cuántas se han insertado y cuántas han fallado. Eric revisa esta información. Debido a que el uso de TDM en este escenario de bases de datos cruzadas con IDA y ODS es algo nuevo, usa también el Comparison Editor para realizar una comparación entre algunos de los datos de origen privados sin enmascaramiento y los datos desidentificados de las tablas de destino con el fin de asegurar que la operación se ha desarrollado con éxito.

   El Comparison Editor muestra los resultados de la comparación de los datos de la columna DB2 GOSALESCT.CUST.CUST_LAST_NAME con la nueva columna CUST.CUST_LAST_NAME en la base de datos de destino Oracle de Roslyn, como se muestra en la Figura 45. Además, muestra la comparación entre las columnas CUST_EMAIL de las mismas tablas. La comparación se realiza por fila. La fila de origen se muestra en el primer lugar de la tabla (identificada como 1 en la columna de Origen), seguida de la fila de destino(identificada como 2 en la columna de Origen).

Volver arriba

Conclusión

Este artículo describió en detalle el proceso de utilización de IDA y ODS para establecer dominios de enmascaramiento de privacidad, asociarlos con las columnas del modelo (físico) de base de datos, y luego usar ese modelo cuando se copian y pegan objetos de la base de datos y datos entre fuentes de datos heterogéneas (DB2 y Oracle). Luego, el artículo mostró cómo se usa TDM para usar los metadatos de la función copiar y pegar, incluyendo la información de enmascaramiento de privacidad con el fin de copiar las filas adecuadas de la DB2 GSDB de origen (producción) a la base de datos (de prueba) Oracle. Esta es una funcionalidad muy útil para cualquier organización dispuesta a mantener la información identificable de su personal como privada al tiempo que se brinda un mecanismo para que los desarrolladores y verificadores de software usen subconjuntos de datos de producción realistas y referencialmente intactos para sus actividades de desarrollo.

Reconocimientos

Gracias a Sailaja Navvluru por su ayuda en la descripción de las interacciones con Optim TDM. Gracias a Rick Buglio por su revisión y sus ediciones. Un agradecimiento muy especial a Kathryn Zeidenstein por su aporte en todos los aspectos de este artículo.

Recursos

Aprender

• Obtenga un buen panorama general y vínculos a más soluciones de Optim en "Integrated Data Management: Managing data across its lifecycle " [Integrated Data Management: gestión de datos en todo el ciclo de vida] (developerWorks, julio de 2008).
  
  
• Conozca más sobre productos y soluciones en la Página Web de soluciones de Integrated Data Management.
  
  
• Encuentre información acerca del soporte pureQuery para Oracle y otras características en "What's new and cool in Optim Development Studio 2.2 " [¿Qué hay de nuevo y bueno en Optim Development Studio 2.2?] (developerWorks, junio de 2009).
  
  
• Conozca más sobre Gestión de la Información en la zona de Gestión de la Información de developerWorks. Encuentre información técnica, instructivos, capacitación, descargas, información sobre productos, y más.
  
  
• Manténgase actualizado con los eventos técnicos y webcasts de developerWorks.
  
  

Obtener los productos y tecnologías

• Descargue la versión de prueba por 30 días de Optim Development Studio o la versión de prueba por 30 días de InfoSphere Data Architect.
  
  
• Descargue la base de datos de muestra GSDB para DB2.
  
  

Comentar

• Participar en el foro de debate.
  
  
• Vea el blog de IDM Experts Managing the data lifecycle (Gestión del ciclo de vida de los datos) e involúcrese en el Espacio de la comunidad Integrated Data Management (Data Studio y Optim).
  
  
• Formule sus preguntas en el foro de discusión de Optim Development Studio, el foro de discusión de soluciones Optim LUW, o el foro de discusión de InfoSphere Data Architect.
  
  
• Vea los developerWorksblogs e involúcrese en la comunidad de developerWorks.
  
  

Sobre el autor

Califique este artículo

Comentario

Volver arriba

Tabla de contenidos

• Introducción
• Diagramación del proceso
• Presentación del ejemplo de escenario
• Definición de los dominios de privacidad y su asociación con el modelo de datos físicos
• Generación de una base de datos de prueba
• Implementación de los datos de prueba privatizados
• Inserción de datos de prueba en el destino con enmascaramiento de privacidad
• Conclusión
• Recursos
• Sobre el autor
• Comentarios