Esfera de datos de SAP

SAP Datasphere es la nueva generación del producto en la nube de SAP para Data Warehousing, que se publicó en marzo de 2023. Es el sucesor de SAP Data Warehouse Cloud (DWC) y, por lo tanto, sirve como contraparte de la solución local establecida. productos SAP BW en HANA y SAP BW/4HANA. El alcance de las funciones aún está algo restringido, pero está creciendo de manera constante, por lo que Datasphere tiene potencial para ser un producto de análisis para más y más empresas.

SAP considera que Datasphere es el producto futuro en el entorno de análisis al que todos los clientes deberían migrar para 2040 a más tardar, el fin planificado del soporte para BW/4HANA. Queda por ver si esto realmente sucederá.

El Modelo Analítico y su posicionamiento

El modelo analítico se ha agregado a Data Builder como un nuevo objeto de modelado que combina las funciones de los objetos existentes y que SAP llama «LA entidad de consumo analítico de referencia tanto para la capa de datos como para la capa empresarial» (fuente: SAP).

El Generador de datos consta principalmente de tablas y vistas a las que se les asigna un uso semántico. El «Conjunto de datos analíticos» semántico describe el uso para informes analíticos, por ejemplo, con aplicaciones de informes como SAC. El «Conjunto de datos relacionales», por el contrario, debe considerarse simplemente una tabla para usar en otros modelos o transmitir a sistemas externos. Mientras el Conjunto de datos relacionales siga existiendo, las funciones del Conjunto de datos analíticos se transferirán al nuevo «Modelo analítico» y, por lo tanto, el Conjunto de datos analíticos quedará obsoleto en un futuro próximo.

Business Builder está diseñado para hacer posible que ciertos usuarios comerciales con experiencia técnica puedan crear y editar modelos de datos y combinar datos centrales de la empresa con sus propios datos. Los objetos en Business Builders generalmente se basan en objetos en Data Builder. Los siguientes objetos están actualmente disponibles: Dimensión, Conjunto de datos analíticos (que no debe confundirse con el Conjunto de datos analíticos semánticos en el Generador de datos), Modelo de hechos, Modelo de consumo y Perspectiva. De estos, el modelo de hechos y el modelo de consumo se transferirán al nuevo modelo analítico, lo que significa que estos objetos también quedarán obsoletos en un futuro previsible. La Perspectiva como interfaz para Reporting también será reemplazada por el Modelo Analítico.

El nuevo modelo analítico, por lo tanto, es el sucesor de un total de cuatro tipos de objetos en Data Builder y Business Builder.

El modelo analítico se creará en Data Builder y puede combinar sus objetos. Sin embargo, el plan es que los objetos en Business Builder también puedan usarse como fuente en el futuro. Por lo tanto, la arquitectura anterior que considera que Business Builder está por encima de Data Builder se reemplazará en el sentido de que los objetos de Business Builder pueden, a su vez, usarse en Data Builder. Queda por ver cómo afectará esto al escenario planificado en el que los usuarios comerciales editan objetos en Business Builder. Si cada cambio en el Business Builder requiere un ajuste a la TI en el Modelo Analítico correspondiente, esto no promoverá el impulso hacia la agilidad y restringirá significativamente el autoservicio.

Las funciones del Modelo Analítico

Esta sección abordará primero las funciones significativas del modelo analítico e ilustrará su uso.

1. Definición de cifras clave restringidas y calculadas

Las columnas calculadas son una opción de modelado de uso frecuente y están disponibles en vistas gráficas y SQL de todo tipo. Sin embargo, en comparación con las Vistas en el Generador de datos, el cálculo en el Modelo analítico no se realiza en el nivel de una sola fila, sino que se basa en los datos agregados, según el informe detallado y cualquier agregación de excepción establecida. Dependiendo del modelo de datos específico, esto puede tener diferentes resultados. Es importante verificar cuidadosamente en el diseño qué cálculo se completa y dónde. La opción para definir figuras clave restringidas es completamente nueva en Data Builder.

Sin embargo, para los usuarios de Business Builder, las cifras clave restringidas y calculadas no son nada nuevo; estas funciones ya estaban y siguen estando disponibles allí.

2. Vista previa de datos analíticos en el diseño familiar de SAC Data Analyzer

La vista previa de los datos está disponible en Vistas del Generador de datos. Esta opción incluso está disponible en cada nodo individual en las vistas gráficas. Esta vista previa es, sin embargo, siempre en el nivel de conjunto único sin la opción de agregación. La vista previa de datos en el modelo analítico, por el contrario, se basa en el analizador de datos, que es bien conocido de SAC, y es adecuado para obtener una vista previa de datos agregados, por lo que también es posible profundizar en el nivel de conjunto individual.

Ya existe la opción de previsualizar datos agregados en el Business Builder, aunque esta previsualización está muy restringida en comparación con el nuevo Modelo Analítico. El Modelo Analítico ofrece una verdadera ventaja sobre los objetos anteriores en este sentido.

Figura 1: Vista previa de datos del modelo analítico

3. Unir con textos y atributos, a través de múltiples niveles y con dependencia del tiempo

Las llamadas Asociaciones se pueden utilizar para asociar un campo en los datos de la transacción a un objeto de datos maestros (Dimensión o Texto) y, por lo tanto, proporcionar textos y atributos para el análisis. Esto corresponde al uso de objetos Info con textos y atributos en sistemas SAP BW, y ya era posible para los objetos existentes en Data Builder y Business Builder. Sin embargo, la nueva característica es que las Asociaciones también están disponibles como Atributos para los campos de una Dimensión asociada. Esto es posible en múltiples niveles y, por lo tanto, es una ventaja significativa sobre los objetos DWC anteriores e incluso sobre SAP BW, que permite esto solo en dos niveles en forma de atributos transitivos. La siguiente figura, por ejemplo, muestra una tabla de hechos «Prueba de SalesView», en la que Dimension Products está asociada a través del campo PRODUCTID. La Dimensión Producto, a su vez, tiene asociada la Dimensión Usuario con el campo CREADO POR y CAMBIADO POR con los datos maestros del usuario.

Figura 2: Asociación de datos maestros en 2 niveles.

Se pueden crear textos y atributos con intervalos de validez correspondientes en función del tiempo. La fecha de validez se define mediante una variable correspondiente al ejecutar el informe.

Lamentablemente, hasta ahora no es posible cambiar el nombre de los campos, por lo que el ejemplo contiene los campos «Nombre» y «Apellido» dos veces: una para el creador y otra para la última persona que realizó cambios.

4. Eliminación de datos de dimensiones asociadas: solo se ejecutan las uniones realmente necesarias

Esta es también una función familiar del Business Builder, que ahora también está disponible en el Data Builder. Independientemente de qué dimensiones estén asociadas en el modelo de datos, si corresponde en muchos niveles, solo las tablas de dichas dimensiones se leen y vinculan a los datos de transacción que son necesarios para el informe detallado solicitado.

En otros objetos de Data Builder, las dimensiones asociadas rápidamente dan como resultado un rendimiento deficiente, en particular con grandes cantidades de datos, porque todas las dimensiones siempre se cargan y se unen entre sí.

Dado que el Modelo Analítico se ejecuta en el MDS Engine, lamentablemente no es fácil crear y analizar una Declaración SQL en el entorno de desarrollo, como es el caso de las Vistas. Sin embargo, diferentes vistas de cálculo son visibles a través del explorador de la base de datos que reflejan el modelo analítico y se pueden usar para análisis de rendimiento (consulte la Figura 3). Alternativamente, la función SQL SYS.EXECUTE_MDS puede transferir la declaración JSON correspondiente como un parámetro y luego se pueden analizar los resultados.

Figura 3: las vistas generadas de un modelo analítico

Para probar la función de poda, primero se crea una consulta que solo muestra el valor bruto por período. El archivo PlanViz asociado confirma que solo se leen las tablas SalesOrders y SalesOrderItems (cf. Figura 4).

Figura 4: Tablas utilizadas para la consulta 1

La tabla de productos o usuarios solo se lee si los atributos de las dimensiones asociadas se incluyen en la consulta.

Figura 5: Tablas utilizadas para consulta con atributos de producto

Esto confirma que en realidad solo se accede a las dimensiones requeridas; en comparación con los objetos anteriores del Data Builder, ya no es perjudicial asociar todas las fuentes entre sí.

Con base en las cuatro funciones clave, hemos demostrado que el modelo analítico ofrece múltiples funciones nuevas para el generador de datos. Sin embargo, en comparación con Business Builder, las ventajas son muy limitadas y las desventajas son fundamentales, en forma de funciones faltantes. SAP es consciente de esto y planea integrar todas las funciones del Modelo de Consumo en el Modelo Analítico, para reemplazar el Modelo de Hecho y Consumo de Business Builder después del Conjunto de Datos Analíticos de Data Builder.

Actualmente, las funciones que faltan incluyen:

• Integración de múltiples fuentes de datos para datos de transacciones
• Uso del modelo analítico como fuente para otros modelos analíticos
• Compartir el modelo analítico con otros espacios

En el momento en que el modelo analítico cubra todas las funciones de los objetos de la capa empresarial, a más tardar, será el objeto central para la generación de informes. Para mantener el trabajo de migración posterior al mínimo posible, es importante considerar implementar nuevos modelos de datos con el modelo analítico ahora.

¿Qué será del Business Builder?

No es posible responder completamente a esta pregunta aquí. En opinión del autor, el modelo analítico mejora en gran medida el Data Builder y deja muchos signos de interrogación cuando se trata de Business Builder. En un futuro próximo, el alcance completo de las funciones de los objetos Business Builder estará disponible en el modelo analítico, por lo que los modelos de datos también se pueden implementar sin un Business Builder. También existe la ventaja de una diferenciación de responsabilidades entre TI y departamento. Pero, ¿qué ventaja tiene para el departamento crear Dimensiones y Conjuntos de datos analíticos si cada cambio estructural debe ser actualizado por TI en el Modelo analítico? Una posibilidad sería un espacio separado en el que el departamento cree sus propios modelos analíticos con lógicas específicas del negocio basadas en modelos analíticos compartidos por TI. Por tanto, el fin del Business Builder parece previsible.

Este post se publicó por primera vez en https://www.nagarro-es.com/es/analytics/the-sap-datasphere-analytic-model