Que el propietario del dominio tenga cada vez más peso en las nuevas aproximaciones de datos como Data Mesh está genial porque él mismo comienza a «sufrir», en primera persona, los errores de diseño de sus tablas transaccionales al moverse del operacional a la analítica. Suele suceder que, en la mayor parte de soluciones de analítica avanzada, queremos disponer siempre del dato actualizado, e incluso dejar traza de la validez de los estados anteriores. Es por ello que se aplica «Slow Changing Dimensions» que como ya hemos anticipado, no es otra cosa que actualizar (e historificar o no) los registros de tu operacional en la solución de analítica. Como sabes (o deberías saber si estás en este mundo de los datos) hay varios tipos de SCD.
NOTA: Hablaré acerca de estos tipos en otra entrada más técnica donde incorporaré ejemplos de TSQL para cada uno de ellos.
Pues resulta que el SCD es muy sencillo de implementar gracias a «Merge Statement» que, para quien no esté al corriente, es un conjunto de instrucciones SQL donde se aplican un conjunto de instrucciones a realizar si el registro:
- No está en el destino
- No está en la fuente, pero si en el destino
- Está en el destino, pero alguna (o todas) de sus observaciones ha cambiado
Con este simple script se permite adaptar fácilmente el proceso a cada uno de los tipos de SCD. Sin embargo, lo que realmente quiero poner de manifiesto es que, si la tabla implicada no dispone de un identificador, no se podrá ejecutar dicho script puesto que necesita al menos un campo que permita identificar cada uno de los registros tanto en la fuente como en el destino.
También puede suceder que la tabla disponga de un identificador único, por ejemplo un UNIQUE ID. Aquí vemos como el escenario cumple con la necesidad de disponer de un identificador para cada registro tanto en la fuente como en el destino. El inconveniente está en que en función del tipo de dato y si además es compuesto (combinación de varias columnas) el rendimiento del proceso de Merge se verá impactado, reduciendo el performance considerablemente. Siempre peor cuanto más campos conformen el UNIQUE ID y también peor si pasamos de NUMERIC a String, por ejemplo.
Con lo que la forma de obtener el mejor performance en el proceso de SCD no es otra que disponer de una PRIMARY KEY a poder ser de tipo NUMERIC (por ejemplo BIGINT). De esta manera, el proceso de Merge será tremendamente más eficiente y dejaremos de «sufrir» problemas en el proceso.
CONCLUSIÓN
Como he comentado al principio de la entrada, en aproximaciones modernas de datos, el peso cada vez más recae sobre los sistemas fuentes y es por ello que realizar un buen trabajo en el desarrollo de los objetos de la base de datos es crucial para los procesos de analítica avanzada. Así que pasar la «responsabilidad» de proveer entidades corporativas en vez del dato en raw, hace que los equipos del sistema fuente tomen conciencia de los «dolores» que provocaban ciertas «prácticas» en los equipos centralizados de ingeniería de datos. Esto es algo que ayuda a eficientar las organizaciones desde el punto de vista de generación de información empresarial, algo que sin duda alguna, redunda en un mejor servicio a los Analistas de Datos y expertos de Negocio. Es decir, ¡a tus compañeros!
Foto de portada gracias Ann H: https://www.pexels.com/es-es/foto/amarillo-azulejos-carta-creatividad-1887992/
Alb3rto Alonso 