✒️SAP BI / InfoCubos Por Milton Bravo
SAP BI InfoCubos
Clases de Infocubos
Estandar y en tiempo real. Ambos de diseño estrella ampliado, los infocubos en tiempo real estan optimizados para su actualizacion directa y no requieren el uso del proceso ETL.
Todos los infocubos BI constan de una serie de tablas relacionales agrupadas en esquema estrella:
- Tabla de Hechos: al activarse un infocubo genera dos tablas de hechos, la tabla F y la E
- Tabla de Dimension: un infocubo suele tener un minimo de 4 tablas dimensionales y un maximo de 16, 13 creadas por el cliente y 3 suministradas por SAP (tabla de dimension de unidades, de paquete de datos y de tiempo); las dimensiones del cliente contienen SID (vinculadas a un maximo de 248 infoobjetos de caracteristicas)
En un infocubo siempre hay tablas de dimension de paquetes de datos y de tiempo.
La tabla de dimension de unidades solo existe si uno de los ratios es del tipo 'importe' o 'cantidad', junto al cual se debe introducir una unidad/moneda fija/variable con el ratio.
Tablas de InfoCubo
Tablas de Dimansion: al seleccionar los infoobjetos caracteristicos a utilizar como componentes de infocubo y asignarles las dimensiones antes definidas, se activa el infocubo y se generan las tablas de dimension. Sus columnas comprenden las ID de datos maestros que pertenecen a las caracteristicas (no comprenden los infoobjetos). Las ID DIM tienen una clave unica INT4, al cargar datos transaccionales en un infocubo los valores ID DIM tienen una unica asignacion; la estructura de una tabla de dimension consiste en una columna de ID DIM y hasta 248 columnas de ID de datos maestros.
Tablas de Hechos: al activar el infocubo se generan 2 tablas de hechos: la tabla F y la tabla E (de datos comprimidos). ambas tablas tienen las mismas columnas. Las ID DIM (claves de las tablas de dimension) conforman las claves externas de la tabla de hecos y cada fila tiee un ID unica (combinacion de valores ID DIM).
La tabla F es optima para la carga de datos pues se fracciona automaticamente en la tabla de dimension de paquete entonces se puede gestionar cada solicitud de datos individual por separado. La tabla E esta optimizada para solicitudes de datos. Los registros de datos que tienen los mismos valores de clave se comprimen.
Compresion de infocubo: pasaje de datos de la tabla F a la tabla E, permite un mejor desempeño de los querys que usan el infocubo ya que reduce cierto porcentaje de info dentro del mismo. No se puede borrar una peticion especifica que haya sido comprimida.
Transaccion LISTSCHEMA permite ver un resumen del numero de tablas (excepto las tablas de jerarquia y de texto) que se tienen que crear o son necesarias para un infocubo o agregado BI. Tambien resaltando una fila y llamando a la transaccion SE16 se puede ver el contenido de la tabla.
Diseñar Dimensiones
Las tablas de dimensiones tienen una columna para el DIM ID y las demas contienen los ID de datos maestros (ID sustituto)para cada valor de caracteristica. El ID de datos maestros es el campo de valor de la tabla de ID de datos maestros, el valor de la caracteristica actual es la clave para la tabla de ID de datos maestros. Los valores de ID de datos maestros se asignan al valor de caracteristica cuando los datos maestros se cargan a las tablas de datos maestros, cuando los datos transaccionales se cargan en el InfoCubo, los valores de ID de datos maestros apropiados para los valores de caracteristica de la transaccion se colocan en las tablas de dimension.
Al diseñar un infocubo tomar en cuenta como asignar las caracteristicas a las tablas de dimension. La relacion ideal es 1 : N. En una dimension se asigna un nuevo DIMID para una combinacion unica de caracteristisca de valores ID de datos maestros, para cada posible dimension de valores de ID de datos maestros solamente hay un unico DIMID, si esta combinacion se modifica se generara una nueva fila con un nuevo DIMID en la tabla de dimension.
Si la relacion de caracteristicas es N:M se crearan amplias tablas de dimension, lo cual debe evitarse.
El numero de entradas maximas es el producto cartesiano de todas las ID de datos maestros, por ejemplo si hay 1000 clientes y 1000 materiales, las entradas posibles seran de 1000000 en la tabla de dimension. Se supone que los datos transaccionales se carguen para cada posible combinacion de caracteristicas, aunque esto no ocurre casi nunca.
Las relaciones M:N significan que las caracteristicas deberian almacenarse en dimensiones distintas (ej. cliente y material). El tipo de relacion se describe por hechos y ratios que producen transacciones (ej. pedidos de clientes). En muchos casos al momento de modelar una relacion M:N se debe observar el nro actual de registros en la tabla de dimension y sus ratios con el nro de registros de la tabla de hechos, como regla de aceptacion deberia haber un ratio entre 1:10 y 1:20 entre la tabla de dimension y la de hechos, provocando tablas de dimension mas pequeñas en tablas de hechos mas extensas.
Las caracteristicas con una relacion M:N se pueden combinar en la misma dimension si el numero maximo de registros esta definido claramente y el producto cartesiano de la caracteristica tiene como resultado una pequeña tabla de dimension.
Una tabla de hechos amplia y tablas de dimension mas pequeñas proporcionan el mejor rendimiento del sistema.
Escanear / Compartir
Sobre el autor
Publicación académica de Milton Ezequiel Bravo, en su ámbito de estudios para la Carrera Consultor SAP BI / BW BO Nivel Inicial.
SAP Master
Milton Ezequiel Bravo
Profesión: Project Manager en Newbitcrew - Argentina - Legajo: HQ58N
✒️Autor de: 50 Publicaciones Académicas
🎓Egresado de los módulos:
Disponibilidad Laboral: FullTime
