Introducción

En realidad, las dimensiones en un InfoCube suelen ser diseñadas por términos comerciales (como material, cliente, etc.). Esto a menudo da la impresión de que las dimensiones del InfoCube deberían ser diseñadas en función de las restricciones comerciales. Sin embargo, esto no debería ser el criterio principal y no debería guiar la decisión.

Aparte del volumen de datos, que depende de la granularidad de los datos en el InfoCube, el rendimiento depende en gran medida de cómo se organizan los InfoObject en las dimensiones. Aunque esto no tiene impacto en el tamaño de la tabla de hechos, definitivamente tiene uno en el tamaño de las dimensiones.

¿Cómo se diseña entonces una dimensión?

El objetivo principal al distribuir los InfoObjects en sus dimensiones debe ser mantener las dimensiones lo más pequeñas posible. La decisión sobre cuántas dimensiones y qué InfoObjects van dónde está impulsada puramente por consideraciones técnicas. En algunos casos, esto coincide con la vista organizativa, pero esto sería solo una coincidencia y no el objetivo.

Hay algunas pautas que se deben considerar al asignar InfoObjects a dimensiones:

• Utilizar tantas dimensiones como sea necesario, pero es más importante minimizar el tamaño de la dimensión que el número de dimensiones.
• Dentro de la dimensión, solo se deben agregar características que tengan una relación 1:n (por ejemplo, material y jerarquía de productos)
• Dentro de una dimensión no debería haber relaciones n:m. (por ejemplo, jerarquía de productos y cliente)
• Los InfoObjects a nivel de documento o características grandes deben diseñarse como dimensiones de ítems de línea. Las dimensiones de ítems de línea no son dimensiones reales, tienen un enlace directo entre la tabla de hechos y la tabla SID.
• Las características más selectivas deben estar en la parte superior de la tabla de dimensiones
• No mezclar características con valores que cambien con frecuencia, lo que puede causar tablas de dimensiones grandes. (por ejemplo, material y promociones)
• También considerar combinar características no relacionadas puede mejorar el rendimiento al reducir el número de uniones de tablas. (solo tienes 13 dimensiones, así que combina las pequeñas)

Para ayudar, se puede utilizar el informe (SE38) SAP_INFOCUBE_DESIGNS

Esta dimensión marcada en amarillo debería convertirse en una dimensión de ítems de línea si contiene una característica a nivel de documento o si es simplemente un mal diseño.

El número máximo de entradas que una dimensión puede tener potencialmente se calcula a través del producto cartesiano de todos los SID. (por ejemplo, 10,000 clientes y 1,000 jerarquías de productos conducen a 10,000,000 combinaciones posibles en la tabla de dimensiones. Es poco probable que esto suceda y al diseñar la dimensión también se debe considerar esto: analizar las posibilidades de que todos los clientes compren todos los productos en este caso.

En los casos en que hay una relación m:m, generalmente significa que falta una entidad entre esas dos y, por lo tanto, deben almacenarse en dimensiones diferentes.

Una vez que los datos se cargan en el InfoCube, se debe hacer una verificación de la cantidad real de registros cargados en la tabla de dimensiones frente a la cantidad de registros en la tabla de hechos. Como regla general, la proporción debería estar entre 1:10 y 1:20.

Dimensiones Degeneradas

Si una tabla de dimensión grande alcanza casi el tamaño de la tabla de hechos al medir la cantidad de filas en las tablas, es una dimensión degenerada. El procesador OLAP tiene que unir dos tablas grandes, lo cual es malo para el rendimiento de la consulta. Dichas dimensiones pueden marcarse como Dimensiones de Ítems de Línea causando que la base de datos no cree una tabla de dimensión real. Al verificar la tabla /BIC/F, se mostrará que en lugar de la clave de dimensión DMID, se coloca el SID de la tabla de dimensión degenerada en la tabla de hechos. (Nombre de campo RSSID). Con esto, se elimina la unión de las dos tablas. Esas dimensiones solo pueden contener un InfoObject, ya que debe existir una relación 1:1 entre el valor SID y el DIMID.

Las dimensiones con muchas valores únicos pueden configurarse como Alta Cardinalidad lo que cambia el método de indexación de las dimensiones. (Solo ORA DB) Esto resulta en un cambio de un índice de bitmap a un índice B-Tree.

Pedro Pascal

Se unió el 07/03/2018