Cubos de BI

a3ERP BI es la herramienta de análisis de Wolters Kluwer: una aplicación aparte que, en la práctica, es un pivot grid de DevExpress conectado al resultado de la consulta SQL que le pases. Cada cubo es esa consulta: un dataset denormalizado — un único SELECT ancho, sin GROUP BY — que cruza las tablas operacionales de a3ERP y devuelve una tabla con dimensiones (cliente, fecha, estado...) y medidas (importes, unidades, horas) listas para pivotar. Las agregaciones no las hace tu SQL: las hace el usuario al arrastrar columnas en el pivot. En las plantillas hay un esqueleto completo para empezar.

Sin parámetros ni intérprete#

Los cubos no pasan por el intérprete de a3ERP: a3ERP BI ejecuta la consulta tal cual y recibe el conjunto completo. No hay parámetros runtime ni de usuario — los filtros los aplica la propia herramienta, con sus desplegables y las áreas del pivot.

Eso también significa que las restricciones del intérprete desaparecen: aquí se puede usar : en los comentarios y corchetes como alias de columna sin que nada pete.

Convenciones#

• WITH (NOLOCK) en todos los joins. Un cubo recorre tablas operacionales enteras — facturas, líneas, partes — mientras la empresa sigue trabajando sobre ellas; es la consulta con más papeletas de chocar con transacciones en curso.
• Alias de columna en castellano, con espacios y tildes ([Cliente], [Cód. Proyecto], [VCA Enero]...). Son los nombres que el usuario ve al pivotar, así que merecen el mismo cuidado que una etiqueta de pantalla. Como no hay marcadores de parámetro, valen tanto 'Nombre' como [Nombre] — a diferencia de las vistas y parrillas, donde los corchetes rompen la consulta —; la convención es usar corchetes.

Diseñar un buen cubo#

Decide la granularidad y mantenla. Qué es una fila — una línea de oferta, un ticket, una cuota-mes — es la primera decisión del cubo, y todo el SELECT debe respetarla. El error típico es mezclar niveles: traer a un cubo de granularidad línea un importe que pertenece a la cabecera. Por ejemplo, en un cubo donde cada fila es una línea de factura, añadir el total de la factura como medida:

Cada fila repite el total de su factura, porque el total es de un nivel superior a la fila. [Importe línea] suma 100 y va bien; pero si el usuario arrastra [Total factura] al área de datos, el pivot suma 300 — el total contado tres veces, una por línea. Y no hay aviso ninguno: el cubo da cifras infladas con toda normalidad. Por eso las medidas deben ser siempre del nivel de la fila; lo que venga de niveles superiores solo puede bajar al cubo como dimensión (textos, códigos, fechas), nunca como importe sumable.

Separa dimensiones y medidas, con nombres claros. El usuario arrastra unas a las áreas de filas/columnas y otras al área de datos; que el nombre de cada columna deje claro cuál es cuál.

Si traduces códigos a texto, asume su mantenimiento. Un código crudo (ESTADO = 'A') pivota mal, así que es habitual traducirlo a texto legible en el propio SELECT:

CASE C.ESTADO
    WHEN 'A' THEN 'Abierta'
    WHEN 'C' THEN 'Cerrada'
    ELSE ''
END [Estado]

El coste es que ese CASE se convierte en un catálogo paralelo al de la base de datos: el día que el campo empiece a usar un valor nuevo (un estado 'P' de pendiente, por ejemplo), las filas nuevas saldrán con [Estado] vacío hasta que alguien actualice el cubo.

Elige bien el nombre del cubo y su categoría, porque no se pueden cambiar. Son los que el usuario ve en a3ERP BI al elegir el cubo, y una vez creados no hay forma de renombrarlos — la alternativa es crear un cubo nuevo y rehacerlo.