En anteriores posts hemos visto como nuestra herramienta es capaz de transformar datos reales en datos que no son reales pero sí lo parecen para poder utilizarlos en entornos no productivos como QA o desarrollo. Ahora presentaremos una nueva funcionalidad que, de acuerdo con nuestra experiencia, es de gran utilidad cuando las bases de datos tienen grandes volúmenes de información, gran parte de ella innecesaria para determinados propósitos.

Para entender por qué es tan útil esta funcionalidad, primero debemos comprender la problemática que deseamos atacar. Supongamos que estamos trabajando con bases de datos de clientes que compran o contratan servicios en una empresa y queremos preparar un entorno disociado para que trabajen sobre él los equipo de QA y desarrollo. Entonces, dentro de la base de datos de producción tendremos numerosos clientes cada uno con sus productos/servicios y otros datos asociados. Sin embargo, es probable que para los entornos no productivos no sea necesaria la base de datos completa, sino que con tener clientes que cumplan ciertas casuísticas es suficiente, además, es posible que tampoco se necesiten todos los registros de esta selección de clientes.

Veamos un ejemplo, en un caso de prueba en el que es necesario un cliente con sólo un servicio contratado para probar la funcionalidad de adherirle un servicio adicional con cierto descuento por ser cliente, no es necesario que la base de datos de QA tenga todos los clientes que cumplan con esta condición, ni mucho menos todos los clientes cumplan o no la condición. Así, teniendo uno o un subconjunto de ellos será suficiente.

Consecuentemente, nuestra propuesta consiste en mover un subconjunto coherente de la base de datos (o parte de ella) partiendo de una tabla o entidad raíz desde la cual se obtienen los datos relacionados del resto de las entidades de la base de datos y se transfieren a otra con la misma estructura. Además, durante la transferencia de datos coherentes se realiza el proceso de disociación de información sensible para asegurar la protección de la información de los clientes.

Así, la nueva base de datos tiene datos disociados y no posee un volumen mayor al necesario, generando así ventajas como: mayor velocidad al replicar y/o restaurar sus datos, menor tiempo de llenado a través del proceso de disociación selectiva, menores volúmenes de datos, mayor facilidad para encontrar datos útiles, etc.

Imágen. Configurando la senda de extracción.

Ahora, esta solución parece una buena alternativa hasta que nos encontramos con entidades de catálogo a las que hacen referencia otras entidades. En este punto llamamos entidades de catálogo a entidades que pueden ofrecer información general como el catálogo de productos o servicios ofrecidos por la empresa, por lo cual es necesario que se transfieran de forma completa y no es necesario hacerlo a través del recorrido de las relaciones del esquema que disminuye la performance del proceso si se lo compara con la de la transferencia completa de la tabla. Como resultado, nuestra aplicación no solo permite definir diferentes árboles a partir de raíces, sino que también permite indicar aquellas entidades que deben transferirse en su totalidad.

Llevando la disociación selectiva al extremo, en icaria TDM hemos implementado una funcionalidad adicional, el buzón. Es una herramienta pensada para la ejecución del subsetting para un número muy reducido de semillas. Es decir, imaginando que se ha encontrado un cliente en producción que se desea mover al otro entorno, en lugar de ejecutar el proceso completo podríamos crear una petición dentro de icaria TDM de mover y disociar este cliente, con una interfaz muy amigable para cualquier usuario independientemente de su formación en la plataforma. Además, cuenta con la ventaja de ser un método muy acotado que posibilita a los responsables de datos a darle acceso a mayor cantidad de usuarios.

Como hemos visto, estas opciones son útiles y necesarias en función de las características de la instalación y de las preferencias de los usuarios. La limitación de espacio es uno de los mayores inconvenientes que habitualmente encontramos, y la segmentación es la solución idónea para afrontar este obstáculo, consiguiendo el máximo aprovechamiento de los recursos disponibles. Dos de cada tres proyectos de disociación con icaria TDM lo requieren. Habitualmente lo probamos sobre la prueba de concepto, por lo que buena parte de la información necesaria ya está disponible y en manos del equipo del cliente para su revisión. Sin embargo, es necesario afinar las rutas que deben usarse para obtener datos coherentes.

Conceptualmente esta idea es sencilla, pero la definición es relativamente laboriosa, no se conoce habitualmente el modelo de datos ni se dispone de la documentación adecuada. Quizá podamos ofrecer algo de ayuda a nuestros clientes. Es momento de crear y poner a prueba un nuevo plugin de icaria TDM cuyo objetivo es el descubrimiento de relaciones entre datos.