Estás son las nuevas funcionalidades de ABA Framework:

1. Patrón recarga hechos con dimensiones tipo 2, también incremental

En esta versión se incorpora un sabor de la generación de tablas de hechos, que tanto de forma completa como de forma incremental es capaz de encontrar la versión adecuada en la dimensión.

Para usarlo es prerrequisito tener configuradas dimensiones con algún atributo con cambios tipo2, e informar una columna de tipo datetime en la tabla md.load_phase_info_columns indicando que fecha del hecho es la que hay que comparar con él desde hasta de las dimensiones.

2. Direct Inserts

Hasta ahora, para cargar las tablas de hechos, tablas de dimensiones o sincronizaciones desde DW era obligatorio que los registros pasen por la tabla $changes. Esto hacía que, en tablas muy grandes, o incluso no tan grandes simplemente se “paseen” registros por una tabla con el único propósito de llegar a su destino final. Desde esta versión, a través de un campo de configuración llamado DirectInserts con valores Y y N, se puede decidir si se usa o no la tabla $changes (por ejecución) y unida a la funcionalidad que con running totals almacena el último valor leído suponen una mejora en la eficiencia de los paquetes generados.

3. Pre y Post Script

Esta funcionalidad permite mediante una tabla identificar el objeto de sincronización sobre el que se ejecutarán los scripts correspondientes, entendiendo script como por ejemplo un procedimiento almacenado.

Pueden existir N tareas distintas tanto de Pre-ejecución como de Post-ejecución permitiendo así ejecutar tareas antes y/o después de la sincronización.

4. Patrón Full para hechos y dimensiones

Se ha añadido el patrón Full para carga de hechos y dimensiones. Este patrón actúa de la misma manera que en Staging, truncando la tabla y volviendo a cargar los datos.

5. Añadidos nuevos campos al $xcs de LOG

El campo $xcs de la tabla de log nos mostraba información de las filas insertadas, borradas y actualizadas. Ahora también se ha añadido información sobre cuál es el nombre del proyecto, nombre del paquete, desde que origen (HLPid o STGid) y hacia qué destino (STGid o DWHid) y en el caso de que se realice la sincronización de forma incremental, desde y hasta que valor, a cargado de datos.

6. $Deleted Table

Cuando se eliminan registros hasta ahora no se guardaban los registros borrados. Se han creado unas nuevas tablas $deleted que almacenan los registros que se eliminan en cualquiera de las fases de Framework.

7. Variables para inferir tablas

Cuando se desean cargar todos los datos de origen es sencillo. Sin embargo, si se quiere añadir un subconjunto de las mismas se deben cambiar dos scripts como mínimo, tarea que añade una gran probabilidad de fallo en la carga de metadatos. Se ha solucionado añadiendo dos variables (schema y tables) en la que se guarde un asterisco si se quieren cargar todas o un conjunto de tablas separadas por coma para seleccionar únicamente las que interesen.

8. md.Configuration table

Por defecto, cuando filtramos metadatos las claves primarias deben de empezar por pk y la columna incremental debe ser de tipo bigint y llamarse incremental. Con esta nueva tabla podemos configurar estos parámetros de manera que si queremos filtrar la columna incremental por otro nombre y tipo de dato lo podemos hacer fácilmente desde esta tabla. A su vez, podemos establecer si al crear los paquetes de SSIS la columna active_for_creation se establezca a ‘N’ o ‘Y’.

Además, también podemos configurar cuantos logs queremos que muestre la documentación cuando la creemos con TestingAndDocumentation.

9. Lookup de dimensiones a otras

Ahora framework es capaz de relacionar una o varias dimensiones entre sí, creando un modelo de copo de nieve (snowflake). Además, se permite traer columnas de la dimensión relacionada a la primera dimensión.

10. Date Control

Cuando tenemos una dimensión con atributos tipo 2 y hay un cambio en un registro, al sincronizar de nuevo los datos habrá un cierre de versión y se creará otra tupla con el nuevo valor desde ese momento. El valor del cierre de versión y el comienzo de la nueva es el momento en el que se ejecuta el paquete de SSIS.

Mediante esta funcionalidad podemos especificar en qué momento se hizo el cambio para hacer el cierre de versión y el comienzo de la nueva.

11. Ordered

Esta funcionalidad se encarga de añadir un order by por las claves primarias de la tabla en la fase E sobre el helper de origen. Este order by mejorará la eficiencia al traer ordenados todos los datos a sincronizar.

12. QueryHLP, QueryDeletes & DeletedBehaviour

Estas funcionalidades se utilizan para especificar cuál va a ser la query en el origen de datos y cuál será la query para detectar borrados.

queryHLP

Cuando se especifica una queryHLP, ésta se genera como una common table expression en el origen.

queryDeletes & DeletedBehaviour

ABA Framework tiene la funcionalidad de detectar borrados. La manera de detectarlos es copiando las claves primarias en la tabla $DeletedSupport y haciendo un left join con la tabla en STG donde la clave primaria sea nula y todas las filas que se encuentren se marcan para ser borradas posteriormente.

La funcionalidad de queryDeletes permite escribir la query para detectar los borrados. Aquí entra otra de las funcionalidades con contiene ABA Framework que se llama DeletedBehaviour. Esta funcionalidad nos permite decirle a framework que en $DeletedSupport se van a encontrar todas las filas para después hacer el proceso descrito anteriormente o bien, que solo se encuentren las filas que han sido borradas en origen y hemos detectado mediante la query que hemos especificado queryDeletes.

13. Patrón NAV con dos incrementales

El patrón NAV con dos columnas incrementales fue implementado para cuando en una tabla tenemos datos de diferentes compañías. De esta manera, podemos iterar por cada una de éstas y teniendo la incrementalidad bien definida para cada una de ellas.

14. Primary Key Sensitive

Cuando realizamos una sincronización con claves primarias tipo nvarchar, nchar… puede darse el caso que los datos difieran por mayúsculas y minúsculas. Con esta funcionalidad se añade un UPPER a las claves primarias para que sean comparadas de igual manera y no se produzcan problemas posteriores por temas de sensibilidad.

15. Test Framework

El objetivo fundamental es la ejecución de test que responda a las necesidades de la construcción y mantenimiento de un DataWarehouse.

Se utiliza JSON para la definición de pruebas y para generarlas, utilizamos una plantilla y un software de mezcla de plantillas llamado DotLiquiqMarkup. Esto nos permite que mediante una plantilla de test pre-definidos podamos crearlos automáticamente sin ningún tipo de esfuerzo.

Actualmente, los test que estamos creando son:

  • Test que comprueban tabla a tabla que los orígenes de datos tienen las mismas claves primarias que los objetos de destino
  • Test que comprueba que las tablas de error (donde se derivan los registros en caso de que no cumplan alguna de las restricciones que marca la tabla) estén vacías, es decir que no haya ningún registro.
  • También hemos incluido en estos metadatos la posibilidad de que se generen test de agregado, especificando campos que irán en la cláusula group by y campos que irán como selectores. Estos test se escriben totalmente manuales en unas tablas de metadatos.

La funcionalidad más importante sin duda de este desarrollo es la de ejecutar test dependientes y en cascada.

Establecemos dependencia jerárquica entre pruebas, básicamente cada prueba contiene un conjunto de pruebas, es una especie de relación padre-hijo, en la que una prueba puede tener muchos hijos, pero solamente puede depender de un padre, lo que permiten que un test hijo se ejecute siempre o solo en función de si su padre acabó con éxito o con fracaso, incluso el éxito o fracaso de un test puede condicionarse al éxito de todos sus hijos o al fracaso de alguno de ellos.

Como funcionalidad añadida, además, un test puede pasar parámetros en cascada a sus hijos.

Si un test tiene hijos y contiene algún registro que no cumple las condiciones, puede pasar los valores de ese registro a su hijo en forma de cascada. De esta forma, podemos bajar el nivel de granularidad hasta el nivel de buscar los registros completos de venta en el día en que se han encontrado diferencias, encontrando así las claves primarias que tienen errores de sincronización.

Por último, a través del objeto OnErrorStoreProcedureCall podríamos llamar a un procedimiento almacenado que realizara las operaciones que sean necesarias para resincronizar los registros que hemos encontrado como erróneos, cerrando de esta forma el círculo y permitiendo no solamente ejecutar pruebas completas y que tienen sentido desde el punto de vista de negocio (ventas por año) sino encontrando en el máximo nivel de granularidad los registros que provocan las diferencias e incluso pudiendo lanzar eventos que permitan la resolución de esos problemas

16. Generación de cubos

Para construir la fase L (Load) de un DataWarehouse, la forma más común de mantener un histórico de los cambios de una entidad es añadiéndole una clave subrogada y unos campos de periodo de validez, al estilo Desde-Hasta. Es la forma en la que Kimball recomienda en la literatura (aunque hay muchas más alternativas) y resulta de las más comprensibles.  Es de hecho, la fórmula que SolidQ ABA implementa el control de estos cambios.

Aprovechando la información de los metadatos que usa SolidQ ABA Framework y enriqueciendo el modelo ya existente con metadatos necesarios para generar el modelo TOM, podemos generar también los cubos, o estructuras ya sean multidimensionales o tabulares que van a servir para una explotación eficaz de la información

Para generar cubos, hemos usado también DotLiquidMarkup y unas plantillas para generar un lenguaje llamado Tabular Model Scripting language, que no es otra cosa que la serialización en JSON del modelo de objetos TOM (Tabular Object Model), al que se le han añadido una serie de comandos como “créate”, “drop” o “alter” también en modo JSON.

Este modelo de objetos implementa todo lo necesario para crear los cubos que pueden ser explotados desde herramientas de visualización como Microsoft Power BI o Microsoft Excel.