BW430

Modelado de datos de SAP

BW/4HANA

.
.
MANUAL DEL PARTICIPANTE
FORMACIÓN CON INSTRUCTOR
.
Versión del curso: 18
Duración del curso: 5 Días
Número de material: 50157950

Tenga en cuenta que este curso se ha traducido por una máquina y, por lo tanto, puede
no tener la misma precisión de traducción que una traducción humana. En caso de
incertidumbre, consulte la versión en inglés.
Copyrights, marcas registradas y
responsabilidades de SAP

© 2022 SAP SE o una empresa filial de SAP. Reservados todos los derechos.

Queda prohibida la reproducción o transmisión de cualquier parte de esta publicación, en cualquier

forma o para cualquier fin, sin el permiso expreso de SAP SE o de una empresa filial de SAP.
La información que aquí se incluye puede modificarse sin previo aviso. Algunos productos de software
comercializados por SAP SE y sus distribuidores contienen componentes de software con derechos de
autor de otros proveedores de software. Las especificaciones de producto nacionales pueden variar.
Es posible que estos materiales se hayan traducido automáticamente y puedan contener errores
gramaticales o imprecisiones.
SAP SE o una empresa filial de SAP proporcionan estos materiales con fines meramente informativos,
sin manifestación ni garantía de ningún tipo. Ni SAP ni sus empresas filiales se hacen responsables de
los errores u omisiones en relación con los materiales. Las únicas garantías para los productos y
servicios de SAP o de sus empresas filiales son aquellas especificadas en las cláusulas expresas de
garantía que acompañan a dichos productos y servicios, si las hubiera. Nada de lo que aparezca en este
documento debe interpretarse como garantía adicional.
En concreto, ni SAP SE ni sus empresas filiales tienen obligación alguna de emprender las actividades
empresariales indicadas en este documento o en cualquier presentación relacionada, o de desarrollar o
lanzar ninguna de las funcionalidades mencionadas en el presente. Este documento, o cualquier
presentación relacionada, así como la estrategia y posibles desarrollos futuros, productos y/o
direcciones de plataforma y funcionalidades de SAP SE o de sus empresas filiales, están sujetos a
posibles cambios y pueden ser modificados por SAP SE o sus empresas filiales en cualquier momento y
por cualquier motivo, sin previo aviso. La información incluida en este documento no constituye ningún
compromiso, promesa u obligación legal de proporcionar ningún material, código o funcionalidad.
Cualquier afirmación referente al futuro está sujeta a diversos riesgos e incertidumbres que pueden
provocar que los resultados reales difieran de forma significativa de los previstos. Se advierte a los
lectores que no deben depositar una confianza excesiva en estas afirmaciones referentes al futuro y que
no deben basarse en ellas a la hora de tomar decisiones de compra.
En concreto, ni SAP SE ni sus empresas filiales tienen obligación alguna de emprender las actividades
empresariales indicadas en este documento o en cualquier presentación relacionada, o de desarrollar o
lanzar ninguna de las funcionalidades mencionadas en el presente. Este documento, o cualquier
presentación relacionada, así como la estrategia y posibles desarrollos futuros, productos y/o
direcciones de plataforma y funcionalidades de SAP SE o de sus empresas filiales, están sujetos a
posibles cambios y pueden ser modificados por SAP SE o sus empresas filiales en cualquier momento y
por cualquier motivo, sin previo aviso. La información incluida en este documento no constituye ningún
compromiso, promesa u obligación legal de proporcionar ningún material, código o funcionalidad.
Cualquier afirmación referente al futuro está sujeta a diversos riesgos e incertidumbres que pueden
provocar que los resultados reales difieran de forma significativa de los previstos. Se advierte a los
lectores que no deben depositar una confianza excesiva en estas afirmaciones referentes al futuro y que
no deben basarse en ellas a la hora de tomar decisiones de compra.https://www.sap.com/
corporate/en/legal/copyright.html para obtener información y avisosadicionales sobremarcas
comerciales.

© Copyright. Reservados todos los derechos. iii

Convenciones Tipográficas

El idioma estándar usado en este manual es Español ( España ).

También se usan las siguientes convenciones tipográficas.

Esta información se visualiza en la presentación del instructor.

Demostración

Procedimiento

Advertencia o aviso

Consejo

Información relacionada o adicional

Discusión con moderador

Control de interfaz de usuario Texto ejemplo

Título de ventana Texto ejemplo

iv © Copyright. Reservados todos los derechos.

Contenido

ix Resumen del curso

1 Capítulo 1 : Desafíos para el modelado de datos

3 Lección: Introducción al modelado de datos

9 Lección: Resolución de conflictos de requisitos

17 Capítulo 2 : Resumen del caso de negocio

19 Lección: Conocer el caso práctico de ItelO

27 Lección: Comprensión del modelo de datos del sistema fuente

33 Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

35 Lección: Opciones de almacenamiento de datos

41 Lección: Aspectos clave del modelado de SAP HANA
47 Lección: Aspectos clave del modelado de SAP BW/4HANA
61 Lección: Comparación del enfoque de SAP BW/4HANA, el enfoque
de SAP HANA y las estrategias mixtas
75 Lección: Aspectos clave de la analítica integrada de S/4HANA

97 Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/

4HANA

99 Lección: Comprender las opciones de modificación de objetos en la

infraestructura del sistema
105 Lección: Separación de datos maestros y datos transaccionales
117 Lección: Historial de seguimiento
125 Lección: Asignación y transformación de datos
137 Lección: Diseño de una arquitectura escalable en capas de SAP
BW/4HANA (LSA++)
161 Lección: Comprender la partición física y lógica

175 Capítulo 5 : Proceso de modelado

177 Lección: Definición de la secuencia de proyectos de SAP BW/

4HANA
185 Lección: Planificación de las fases de un proyecto de SAP BW/
4HANA
197 Lección: Desarrollo de un modelo de datos de SAP BW/4HANA

227 Capítulo 6 : Complemento de contenido de SAP BW/4HANA

229 Lección: Trabajar con SAP Business Content

239 Lección: Introducción a las vistas CDS ABAP proporcionadas por
SAP BW/4HANA

© Copyright. Reservados todos los derechos. v

251 Capítulo 7 : Implementación de modelos basados en campos de SAP BW/
4HANA

253 Lección: Implementación de modelado basado en campos con

vistas Open ODS
265 Lección: Comprender los modelos de memoria corporativa y de
instantánea

279 Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de

SAP BW/4HANA

281 Lección: Modelado e implementación de datos maestros de SAP

BW/4HANA
301 Lección: Modelado de jerarquías de SAP BW/4HANA

319 Capítulo 9 : Implementación de modelos de datos transaccionales de SAP

BW/4HANA

321 Lección: Modelado e implementación de objetos DataStore

avanzados (ADSO)
345 Lección: Modelado e implementación de InfoFuentes y conversiones
en transformaciones
359 Lección: Modelado e implementación de CompositeProviders

383 Capítulo Gestión del ciclo de vida de los datos de SAP BW/4HANA
10 :

385 Lección: Descripción de la gestión de datos de varias temperaturas

393 Lección: Presentación de SAP BW/4HANA Data Tiering
Optimization (DTO)

411 Capítulo Implementación de vistas nativas de SAP HANA

11 :

413 Lección: Introducción a SAP Web IDE para SAP HANA

419 Lección: Modelado de datos maestros en vistas SAP HANA
431 Lección: Modelado de datos transaccionales en vistas de SAP HANA
445 Lección: Diferencias entre SAP HANA 1.0 y SAP HANA 2.0

453 Capítulo Implementación de escenarios mixtos

12 :

455 Lección: El objetivo de los escenarios mixtos

465 Lección: Integración de vistas de cálculo de SAP HANA en BW/
4HANA
467 Lección: Generar vistas SAP HANA externas desde objetos SAP
BW/4HANA
477 Lección: Modelado e implementación de escenarios mixtos

vi © Copyright. Reservados todos los derechos.

483 Capítulo Otros temas de modelado en SAP BW/4HANA
13 :

485 Lección: Introducción al proceso de análisis de SAP HANA (HAP)

491 Lección: Definición de escenarios de inventario
507 Lección: Cobertura de stock
511 Lección: Modo de planificación

517 Capítulo Apéndice

14 :

519 Lección: Implementación de áreas de trabajo de SAP BW/4HANA

535 Lección: Gestión del ciclo de vida de SAP BW/4HANA - Información
adicional
539 Lección: Fuentes de información adicionales para SAP BW/4HANA

545 Capítulo Glosario

15 :

547 Lección: Glosario

548 Glosario

© Copyright. Reservados todos los derechos. vii

viii © Copyright. Reservados todos los derechos.
Resumen del curso

PÚBLICO OBJETIVO
Este curso está dirigido al siguiente público objetivo:

© Copyright. Reservados todos los derechos. ix

x © Copyright. Reservados todos los derechos.
CAPÍTULO 1 Desafíos para el modelado de
datos

Lección 1
Introducción al modelado de datos 3

Lección 2
Resolución de conflictos de requisitos 9

OBJETIVOS DEL CAPÍTULO

● Comprender los problemas de modelado

● Resolución de conflictos de requisitos

© Copyright. Reservados todos los derechos. 1

Capítulo 1 : Desafíos para el modelado de datos

2 © Copyright. Reservados todos los derechos.

 Capítulo 1
Lección 1
Introducción al modelado de datos

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Comprender los problemas de modelado

Desafíos analíticos

Figura 1: Símbolos utilizados en diapositivas

En este entrenamiento, estos símbolos se utilizarán en las diapositivas para los fines
enumerados.

Figura 2: Introducción al modelado de datos

Su empresa ha decidido mejorar sus procesos empresariales utilizando SAP BW/4HANA

como solución de almacén de datos. Está asignado para desarrollar e implementar una
directiva de modelado. En esta unidad, aprenderá a ordenar y priorizar las expectativas.

© Copyright. Reservados todos los derechos. 3

Capítulo 1 : Desafíos para el modelado de datos

Figura 3: Motivación: Comprender los conflictos en las reuniones...

Calidad de los datos: un problema importante

Las decisiones empresariales a menudo son impulsadas por valores recopilados de sistemas
de procesamiento de información. Por lo tanto, se distribuyen numerosos informes. Pero, ¿de
dónde proceden los valores y cuán confiables son?
En las grandes empresas, es común que diferentes equipos recopilen sus propios datos o
calculen sus propios valores. Cuando representantes de diferentes equipos se reúnen en
reuniones para analizar la estrategia de la empresa, se presentan hechos para respaldar una
estrategia sugerida. Otros podrían estar en desacuerdo y pedir a los hechos que apoyen su
objeción. Pero, ¿todo el mundo utiliza la misma base de hechos?
Imagine que el responsable de la toma de decisiones solicita la cantidad total de estaño que
se ha entregado a un cliente específico, obteniendo tres respuestas diferentes:
● El departamento de almacenamiento afirma que vendieron 15 m².
● El departamento de estrategia afirma que la compañía vendió 15 KG.
● El departamento de CRM afirma que la empresa vendió 14 kg.

Sin una estrategia de recopilación de datos central, cada departamento se basa en sus
propios cálculos. Si cada departamento mantiene su propia base de datos independiente,
basada en el mismo proceso empresarial original, esto se denomina silo.
Los silos son múltiples copias de la misma fuente de datos con diferentes pasos
independientes de consolidación, armonización y mejora.
Los problemas con los silos son los siguientes:
● Malentendidos en los debates
● Agregación de errores
● Diferentes creencias sobre la verdad y el comportamiento recomendado
● Diferencias de valores entre los diferentes informes públicos

4 © Copyright. Reservados todos los derechos.

 Lección: Introducción al modelado de datos

Figura 4: Motivación: Escenarios de negocio y desafíos analíticos

¿Por qué los diferentes departamentos obtienen resultados diferentes? Veamos un ejemplo
con posibles fuentes de diferencias:
● Base de datos diferente: diferentes tablas fuente (como una tabla fuente agregada frente a
una tabla fuente de detalles), diferentes valores de filtro, diferentes tiempos o diferentes
sistemas fuente llevan regularmente a diferentes resultados de extracción.
● Actualidad diferente de los valores: Si, en una etapa temprana, se extrajeron datos
erróneos del sistema fuente que se corrigió más tarde. Es importante actualizar los valores
en el sistema de informes
● Distintos tiempos de extracción: Los valores en la fuente varían. Es posible que se añadan
nuevos pedidos o que se modifique la información de estado. A continuación, los valores
pueden diferir si se extraen por la mañana o por la noche.
● Diferentes definiciones de cálculo: ¿Cómo se define un margen? ¿Qué costes deben
distraerse? ¿Un valor % se basa en kg o litros?
● Diferentes pasos de cálculo: ¿Se calcula una agregación entre diferentes productos antes
de que se calcule una conversión de unidades en un factor de conversión promedio? ¿O la
conversión se ejecuta con un factor de conversión específico de producto antes de que se
agreguen los valores? ¿Se calcula una participación (% valor) antes o después de que se
ejecute una conversión de unidades?
● Diferentes tiempos de cálculo: Si los factores de conversión cambian, los diferentes
factores de conversión conducen a resultados diferentes.
● Sin buena gestión de calidad: no hay control de la fiabilidad de la salida.

Directiva de modelado de datos

Directiva de modelación
Muchas empresas deciden implementar un almacén de datos, como SAP BW/4HANA, con un
almacenamiento central de toda la información empresarial y un rápido procesamiento de la
información.

© Copyright. Reservados todos los derechos. 5

Capítulo 1 : Desafíos para el modelado de datos

Sin embargo, incluso la mejor solución de software debe ir acompañada de una buena
directiva de modelado de datos.

Figura 5: Definición: Aspectos de una Directiva de Modelado de Datos

Una directiva de modelado de datos es una directriz sobre lo que se debe hacer, dónde,
cuándo, con qué datos y de qué manera.
Una directiva de modelado de datos debe abordar lo siguiente:
● ¿Qué procesos empresariales están en el centro de atención?
● ¿Se necesitan valores para toda la empresa o para una subsidiaria local?
● ¿Qué campos de gestión de datos están previstos? ¿Se pueden generar informes sobre los
valores reales, el análisis predictivo y la planificación de operaciones?
● ¿Hasta qué nivel de detalle se necesitan los valores?
● ¿Son esenciales los valores actuales (hasta el último segundo)? ¿O es aceptable una
latencia, es decir, un retraso? ¿Es suficiente procesar los datos uno por día?
● ¿Se requieren valores históricos? ¿Cuánto tiempo atrás? ¿Qué se debe hacer si los valores
cambian? ¿Es necesario identificar los valores obsoletos?
● En los cálculos, ¿también se necesitan resultados intermedios?

Una directiva de modelado de datos debe abordar lo que se debe hacer con los datos:
● ¿Se leen los valores? ¿Copiado? ¿Procesado? ¿Presentado?
● ¿Se utilizan procesos de selección para reducir el conjunto de datos?
● ¿Las tablas están combinadas con otras tablas?
● ¿Los valores se transforman y armonizan?

6 © Copyright. Reservados todos los derechos.

 Lección: Introducción al modelado de datos

● ¿Qué valores deben verificarse, por ejemplo, para la integridad referencial, frente a
duplicados, para el formato de datos correcto, frente a errores matemáticos como una
suma de más del 100%?
● ¿Se presenta un resultado como resultado en la pantalla o se almacena de forma
permanente?
● ¿Los datos se archivan o se borran?

Una directiva de modelado de datos debe abordar cuándo y con qué frecuencia se producen
estos procesos:
● ¿A petición? (Siempre que un usuario empresarial esté interesado en los valores)
● ¿En un momento predefinido?
● Periódicamente, por ejemplo, diariamente o mensualmente,
● ¿Cada vez que los datos han cambiado en la fuente?

Una directiva de modelado de datos debe direccionar dónde se leen y procesan los datos:
● ¿Qué sistemas fuente se utilizan como base de datos, qué sistemas destino se utilizan
para almacenar valores?
● ¿Qué tablas o vistas contienen la base de datos?
● ¿Los cálculos se ejecutan en la base de datos o en el nivel de aplicación?
● ¿Qué base de datos se utiliza?
● ¿Qué objetos BW son necesarios para cumplir con los requisitos aprobados?

Por último, una directiva de modelado de datos debe abordar cómo se tratan los datos:
● ¿Los valores se importan mediante archivos sin formato, una conexión de base de datos u
otras tecnologías?
● ¿Cuáles son las condiciones de conexión?
● ¿Cuáles son las condiciones de filtro?
● ¿Qué cálculos deben realizarse?
● ¿Cómo se derivan los valores plan?
● Qué monedas o unidades se utilizan y cómo se pueden convertir valores de una moneda a
otra.
● ¿Cómo se agregan los valores?

Por ejemplo, debe definir cómo se ponen a disposición los ratios de la fuente. Por ejemplo,
una directiva podría sugerir un hub sin procesar con ratios básicos a medida que se importan
de la fuente de datos, y los usuarios empresariales pueden crear sus propios cálculos y
restricciones sobre ellos.
Un concentrador central es otra solución que proporciona ratios calculados predefinidos o
restringidos para casos de uso típicos. En este caso, un modelo de datos debe definir cómo se
derivan los nuevos ratios.
También es posible proporcionar ambas opciones.

© Copyright. Reservados todos los derechos. 7

Capítulo 1 : Desafíos para el modelado de datos

Figura 6: Definición: Modelado de datos para BW/4HANA

En concreto, sus tareas principales como modelador de datos para un proyecto de SAP BW/
4HANA incluyen lo siguiente:
● Definir una estrategia general de generación de informes y almacenamiento de datos
● Selección de los sistemas fuente y las tablas que deben estar conectados
● Elegir qué hacer ya en el sistema de origen y qué hacer en el sistema de informes
● Planificación de cómo extraer valores
● Considerando qué procesos de datos se pueden ejecutar directamente en la base de datos
de SAP HANA y cuáles se ejecutan en la capa de aplicación de SAP BW/4HANA
● Definir objetos de SAP HANA y SAP BW/4HANA para almacenar y procesar estos valores,
especialmente diseñando las propiedades y relaciones de los objetos de SAP BW/4HANA
y SAP HANA

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Comprender los problemas de modelado

8 © Copyright. Reservados todos los derechos.

 Capítulo 1
Lección 2
Resolución de conflictos de requisitos

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Resolución de conflictos de requisitos

Resolución de conflictos de requisitos

Figura 7: Escenario de caso

Figura 8: Motivación: desafíos de los requisitos de análisis (1)

Cuando se modelan objetivos de estrategia, diferentes usuarios empresariales requieren

diferentes conjuntos de datos, por ejemplo, un historial detallado que se remonta a varios
años atrás, un análisis detallado con todos los campos de la fuente o actualizaciones en
tiempo real de las últimas modificaciones.

© Copyright. Reservados todos los derechos. 9

Capítulo 1 : Desafíos para el modelado de datos

Sin SAP BW/4HANA, la realización de todos estos requisitos diferentes resultaría en un

sistema de gestión de informes lento.

Figura 9: Motivación: desafíos de los requisitos de análisis (2)

Diferentes usuarios empresariales esperan diferentes características en los informes. Por

ejemplo, algunos usuarios buscan informes rápidos y estandarizados, otros usuarios buscan
cálculos complejos y otros usuarios buscan informes flexibles que permitan el análisis por
parte del usuario empresarial sin la necesidad de tickets de TI.
Es imposible programar una herramienta que funcione de forma óptima para todos estos
requisitos conflictivos.
SAP BI proporciona una cartera de diferentes herramientas de gestión de informes, cada una
de las cuales se centra en una o dos de estas necesidades.

Figura 10: Motivación: desafíos de los requisitos de análisis (3)

Diferentes usuarios empresariales enumeran diferentes requisitos cuando se trata de cómo

se transforman y actualizan los valores. Por ejemplo, un usuario puede requerir que se

10 © Copyright. Reservados todos los derechos.

 Lección: Resolución de conflictos de requisitos

actualice un único valor fiable dentro de toda la empresa. Otro usuario podría requerir valores
dinámicos integrados de fuentes volátiles como internet, twitter, redes sociales. Por último,
es posible que otro usuario requiera la aceptación de ajustes individuales.
No todos estos requisitos pueden estar en el mismo informe.

Figura 11: Estrategia: Combinación de diferentes opciones

En algunos casos, existen buenas maneras de permitir la coexistencia de dos opciones

diferentes:

1. Entregue un informe estándar con verdad confiable, pero permita a los usuarios de
negocio crear una copia local con sus cambios. SAP proporciona varias herramientas con
funciones de autoservicio flexibles.

● En Analysis for Office, es posible seleccionar características para el desglose, agregar

cálculos, crear filtros para los resultados de N principales o crear resaltado para
valores por debajo de un valor de destino definido individualmente.

● En SAP BusinessObjects Lumira, los usuarios empresariales pueden influir en la

visualización gráfica.

2. Proporcione diferentes opciones dentro del mismo proyecto y área de nombres, como:

● Proporcione un informe estratégico con un historial largo y otro informe con más
detalles para el año o mes actual.

● Permita que los usuarios elijan una de las dos versiones de jerarquía diferentes en un
informe.

● Enumere dos ratios alternativos, como la cantidad en kg y la cantidad en número de

unidades.

3. En algunos casos, podría ser necesario establecer diferentes proyectos con sus propios
informes locales. Sin embargo, se recomienda encarecidamente utilizar ratios separados
o valores de filtro diferentes para evitar conflictos sobre la interpretación correcta de los
valores. Algunos ejemplos de estos informes son los siguientes:

© Copyright. Reservados todos los derechos. 11

Capítulo 1 : Desafíos para el modelado de datos

● Proporcione un informe de RR. HH. alemán sin información sobre el número de días de
enfermedad por empleado y un informe estadounidense que ordene a los empleados
por número de días de vacaciones.

● En un proyecto de gestión de relaciones con el cliente, proporcione un informe local

que muestre el número de pedidos recurrentes; en un proyecto de ventas, cree otro
informe local que muestre el número de pedidos abiertos. Sin embargo, una estrategia
global debe detectar que ambos utilizan el número de pedidos y proporcionar una base
común con ratios de pedido armonizados para ambos.

Figura 12: Estrategia: Priorización de destino

En algunos casos, puede haber decisiones estratégicas para excluir cierto contenido o
mantenerlo fuera del enfoque del proyecto. Puede haber diferentes motivos, como:
● Sería imposible cumplir ambos objetivos. Por ejemplo, es imposible tener algoritmos
complejos que sean fáciles de entender a primera vista.
● Sería lento y costoso producir tales resultados.
● Existen barreras legales o de cumplimiento.
● Existen estándares BW globales. Por ejemplo, si la decisión global se tomó a favor de
mostrar una categorización de producto estándar basada en los primeros dígitos de sus
nombres técnicos, no se admiten otras categorizaciones.
● Sería confuso para los usuarios finales tener diferentes versiones.
● Las fuentes de datos no son de confianza.
● Otros objetivos tienen una prioridad más alta.

En caso de conflictos, estas deberían ser sus prioridades:

1. Valores correctos (verdadero, de acuerdo con los requisitos legales, comprensible)

2. Funcionalidad requerida

3. Flexibilidad (estar abierto a necesidades futuras)

12 © Copyright. Reservados todos los derechos.

 Lección: Resolución de conflictos de requisitos

4. Rendimiento de informes

5. Rendimiento de staging (se correlaciona con un volumen de datos bajo)

Si las condiciones cambian, los objetivos pueden volver a evaluarse y se pueden establecer
proyectos posteriores para adaptarlos a los objetivos que se han omitido.

Figura 13: Estrategia: Objetivos de la estrategia de modelado de datos

Una buena estrategia de modelado debería evitar confusiones sobre los valores correctos.
Incluso la forma más rápida, económica y flexible de almacenar y recuperar valores no es
buena si los valores son incorrectos o incomprensibles.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Resolución de conflictos de requisitos

© Copyright. Reservados todos los derechos. 13

Capítulo 1 : Desafíos para el modelado de datos

14 © Copyright. Reservados todos los derechos.

 Capítulo 1

Evaluación de la formación

1. ¿Cuáles son los silos de datos y cuáles son sus desventajas?

2. Debe implementar todos los requisitos empresariales.

Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

© Copyright. Reservados todos los derechos. 15

 Capítulo 1

Respuestas a la Evaluación de la formación

1. ¿Cuáles son los silos de datos y cuáles son sus desventajas?

Los silos son extracciones aisladas y no coordinadas de (parcialmente) los mismos

conjuntos de datos por diferentes proyectos o unidades de negocio. Esto provoca una
carga de datos innecesaria, un consumo excesivo de espacio de almacenamiento,
inconsistencias e incluso conflictos en las reuniones porque no hay un "único punto de
verdad".

2. Debe implementar todos los requisitos empresariales.

Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

Tienes razón. Hay razones para rechazar los requisitos de aplicación. Por ejemplo, digan
cortésmente que no si no se puede confiar en las fuentes de datos, si una sugerencia no se
puede implementar técnicamente, si otros objetivos tienen mayor prioridad, o si se
necesitaría demasiado espacio de almacenamiento. Leer más en el módulo Resolución de
conflictos de requisitos, en el curso BW430.

16 © Copyright. Reservados todos los derechos.

CAPÍTULO 2 Resumen del caso de negocio

Lección 1
Conocer el caso práctico de ItelO 19

Lección 2
Comprensión del modelo de datos del sistema fuente 27

OBJETIVOS DEL CAPÍTULO

● Conozca el caso práctico de ItelO

● Comprender cómo el modelo de datos del sistema fuente separa los datos

© Copyright. Reservados todos los derechos. 17

Capítulo 2 : Resumen del caso de negocio

18 © Copyright. Reservados todos los derechos.

 Capítulo 2
Lección 1
Conocer el caso práctico de ItelO

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Conozca el caso práctico de ItelO

Conocer el caso práctico de ItelO

Figura 14: Escenario de negocio: El caso práctico de ITelO

En este caso práctico, usted es el jefe del departamento de TI de una empresa vendedora de
hardware y software llamada ITelO. Esta empresa se enfrenta a problemas con informes
inconsistentes para diferentes segmentos empresariales.
Primero, identifique y comprenda los procesos empresariales que se reflejarán en su almacén
de datos. ¿Cuáles son las principales cuestiones? Considere la filosofía de modelado óptimo
para cada uno de estos casos de negocio por separado.

© Copyright. Reservados todos los derechos. 19

Capítulo 2 : Resumen del caso de negocio

Figura 15: Motivación: Comience desde el proceso de negocio

¿Cuáles son sus procesos empresariales? ¿Qué problemas experimentan los usuarios
empresariales para encontrar información relevante en sus informes? ¿Cuáles son los
principales requisitos de generación de informes de cada empresa? ¿Dónde son relevantes
los informes estratégicos, dónde se centra la información estratégica en tiempo real y dónde
es un problema la armonización entre sistemas? ¿Los propios usuarios introducen o cargan
valores?
En el ejemplo de la figura, Motivación: Inicio del proceso empresarial, se identifica la
planificación empresarial, la producción, el almacenamiento y las ventas como segmentos
empresariales con solicitudes urgentes para nuevos informes. Para encontrar los requisitos
de gestión de informes, empiece analizando el proceso empresarial del segmento empresarial
y los problemas.
La planificación es un área que implica incertidumbre y datos introducidos manualmente. En
diferentes ciclos, los valores se introducen en un nivel superior, como el volumen de ventas
por trimestre. Deben existir diferentes variantes de plan en paralelo. Sin embargo, el
problema sigue siendo que una suma de valores de diferentes versiones no tiene sentido.
Esto lleva al requisito de gestión de informes de mantener diferentes versiones separadas.
En el proceso empresarial, el gestor que introduce el segundo plan solo puede leer los valores
del primer plan. Los informes deben permitir la entrada de valores plan y la verificación de sus
autorizaciones.
El siguiente paso del proceso empresarial es publicar los volúmenes de negocios planificados
como valores mensuales. Sin embargo, ¿cómo puede derivar un valor mensual a partir de un
valor introducido para todo el trimestre? ¿Divide el valor del trimestre entre tres, distribuye el
valor según el número de días naturales o utiliza una función compleja que tenga en cuenta el
número de días laborables?
A partir de este problema, se deriva el requisito de gestión de informes de calcular valores
detallados.
Además, el proceso empresarial implica la supervisión de la diferencia entre los valores
planificados y de pronóstico. Esto lleva a la cuestión de cómo se derivan los valores de
previsión y el requisito de reporting de calcular fórmulas.
En las áreas de fabricación y almacenamiento, el proceso empresarial implica una entrada y
salida de mercancías controladas automáticamente. Es posible que no se dé cuenta con
antelación de que existe el peligro de que el suministro de material sea insuficiente. Sin

20 © Copyright. Reservados todos los derechos.

 Lección: Conocer el caso práctico de ItelO

embargo, debe tomar decisiones inmediatas en casos de errores de producción, falta de

materia prima o cualquier otra situación excepcional. Se requiere una alerta generada
automáticamente en cuanto se produce el problema (tratamiento de excepciones basado en
valores umbral). Existe la necesidad de un análisis de datos en tiempo real con un buen
rendimiento a un nivel detallado.
El equipo de ventas desea integrar datos de planificación empresarial estratégica, FI y CRM y,
por lo tanto, desea utilizar SAP BW/4HANA como una herramienta para generar datos
armonizados fiables. En el proceso empresarial de ventas, los clientes piden mercancías.
Realizan sus pedidos en diferentes monedas. Si no todas las mercancías están en stock, se
necesitan diferentes transportes con diferentes pedidos de reparto por pedido de cliente.
Finalmente, se emite y se paga una factura y, a continuación, se cierra el pedido de cliente; de
lo contrario, permanece abierto. Los representantes de ventas verifican que las cantidades de
la factura y del pedido coincidan.
Además, desean reaccionar a las tendencias de ventas. Para los informes de ventas
estratégicos necesarios, se deben reunir los valores de diferentes fuentes y tablas. Las
diferentes monedas deben convertirse a la moneda de la empresa. El resultado debe grabarse
de forma permanente. Esto garantiza una base de datos fiable.

Figura 16: Caso práctico: ITelO Business Objects

Para demostrar la asignación de los procesos empresariales a las unidades técnicas y lógicas,
y para desarrollar directrices de modelado, utilizamos un caso práctico. Se basa en una
empresa ficticia llamada ITelO que compra y vende computadoras y accesorios. Esta
empresa no tiene unidad de producción.
ITelO es un actor global, con varias filiales y ubicaciones en todo el mundo, vendiendo sus
productos a través de canales de distribución directa. La empresa tiene varios revendedores
y clientes estándar, así como diferentes proveedores. Algunos interlocutores comerciales
aparecen solo como proveedores, otros solo como clientes y, en algunos casos, ambos. ITelO

© Copyright. Reservados todos los derechos. 21

Capítulo 2 : Resumen del caso de negocio

tiene varios empleados en diferentes ubicaciones que pueden gestionar procesos de ventas o
compras, es decir, crear y modificar pedidos o pedidos de cliente.
ITelO tiene un almacén por ubicación, y el mismo producto se puede almacenar en diferentes
ubicaciones. La unidad de almacén más pequeña es la ubicación. Una ubicación se encuentra
en una ubicación y (en un momento dado) contiene exactamente un producto.
Estas relaciones se reflejan en tablas y referencias clave llamadas EPM SAP NetWeaver Demo
Model. EPM significa modelo de aprovisionamiento empresarial. Los datos generados se
aprueban y se pueden utilizar en los sitios del cliente con fines de demostración o formación.
En este modelo simple, existen tres áreas de negocio principales:
● Aprovisionamiento (compra de productos)
● Ventas (venta de los mismos productos)
● Almacenamiento (almacenamiento de estos productos)

Si bien el alcance de EPM es lo suficientemente complejo como para ser utilizado como base
para realizar pruebas y demostraciones de las tecnologías de SAP NetWeaver, no es una
aplicación completa para un entorno de sistema productivo. Este modelo simple no implica
procesos de producción y no existe un enlace automático entre la salida de mercancías y una
modificación del contenido de la ubicación de stock correspondiente. Imagine que todas las
mercancías se entregan directamente desde las tiendas sin acceder al almacenamiento
central, y las mismas cantidades se vuelven a pedir a las tiendas directamente de los
proveedores.

Figura 17: Caso práctico: Cómo generar pedidos individuales

La imagen, Caso práctico: Cómo generar pedidos individuales, muestra una aplicación
modelo, la tienda Web ITelO.
La aplicación de plantilla simula el siguiente escenario: un cliente accede a la tienda web con
la intención de comprar un portátil. El cliente busca en la tienda Web el producto correcto, lo
coloca en la cesta de la compra y realiza el pedido (pedido de cliente). Como el producto no
está en stock, ITelO se pone en contacto con un proveedor para el producto y realiza un

22 © Copyright. Reservados todos los derechos.

 Lección: Conocer el caso práctico de ItelO

pedido. Cuando ITelO recibe el producto del proveedor, envía el producto al cliente junto con
la factura. Se emite una entrada de mercancías al llegar al ordenador portátil y se genera una
salida de mercancías cuando se transfiere el portátil desde el almacén. En este escenario, las
cantidades de salida y entrada de mercancías son iguales, por lo que no hay efecto en las
cantidades en stock.

Figura 18: Caso práctico: Cómo trabajar con órdenes existentes

Todos los empleados ITelO pueden buscar todas las entradas (pedidos de cliente, pedidos,
datos maestros) en su portal empresarial o en SAP NetWeaver Business Client.
Existen informes estándar basados en el modelo EPM.

Nota:
Puede encontrar información adicional aquí: http://scn.sap.com/docs/
DOC-31458.

© Copyright. Reservados todos los derechos. 23

Capítulo 2 : Resumen del caso de negocio

Figura 19: Caso práctico: Cómo generar datos en masa

Para dar soporte a un escenario realista, existen formas de generar datos en masa. Esto
permite la simulación de volúmenes de datos reales para datos maestros, como productos y
entidades empresariales, como pedidos y pedidos de cliente. Para algunos pedidos de cliente
o compras, se pueden generar las salidas de mercancías correspondientes o los documentos
de entrada de mercancías. El generador de datos en masa se llama con la transacción
SEPM_DG.
Esto ya se ha hecho en nuestro entorno de formación. Vemos una larga lista de pedidos
existentes de años anteriores.
El generador de datos puede proporcionar conjuntos de datos genéricos, pero también se
puede personalizar si, por ejemplo, desea excluir determinados productos al generar datos
maestros. Los datos existentes se pueden borrar y volver a crear. También es posible tomar
instantáneas del estado actual y almacenarlas para su uso posterior. También puede ajustar
la generación de datos transaccionales para que los pedidos sean creados por empleados
específicos o dentro de un período de tiempo específico.

24 © Copyright. Reservados todos los derechos.

 Lección: Conocer el caso práctico de ItelO

Figura 20: Caso práctico: Razones para utilizar SAP BW/4HANA

Para nuestro caso práctico, imagine que ITelO ha adquirido otro minorista llamado Retailer
King 3000. El comerciante King 3000 tiene exactamente los mismos procesos
empresariales, vende los mismos productos (incluso con el mismo ID de producto) pero
utiliza diferentes datos maestros, como categorías o precios de producto.
La junta desea implementar una gestión de informes en toda la empresa para verificar si
existe una posible reducción de costes y para juzgar el negocio en general.
Su tarea es armonizar las diferentes fuentes utilizando SAP BW/4HANA.
¿Cuáles son los problemas que han llevado a la decisión de implementar SAP BW/4HANA?
Un problema fue la latencia entre los cambios y la visibilidad en los informes. Cuando la
demanda aumenta para un producto, los representantes de almacenamiento deben
reaccionar inmediatamente. Para verificar si se puede aceptar un pedido, necesitan la
disponibilidad real del producto en este momento.
Por lo tanto, ITelO necesita un almacén de datos con funcionalidad en tiempo real. Debido a la
base de datos de SAP HANA, la gestión de informes en tiempo real es rápida con SAP BW/
4HANA.
Para los informes de ventas estratégicos, establezca una asignación común de productos a
categorías en todos los sistemas de origen. Por ejemplo, la junta de ITelO desea ver la suma
de todos los volúmenes de ventas para cada categoría de producto. Sobre la base de estas
sumas, se calcula una clasificación para ver los productos o categorías más vendidos y más
vendidos.
Sin embargo, los representantes de ventas que trabajan con las categorías tradicionales
quieren ceñirse a las diferentes categorizaciones del clásico ItelO y Retailer King 3000.
Por lo tanto, ITelO necesita una gestión de datos maestros flexible y una integración estrecha
de los datos maestros con los datos de ventas. Con SAP BW/4HANA, el usuario empresarial
puede seleccionar los atributos y jerarquías a utilizar. La estandarización en toda la empresa
es posible con SAP BW/4HANA durante las cargas de datos periódicas o en tiempo real sin
cargar datos.

© Copyright. Reservados todos los derechos. 25

Capítulo 2 : Resumen del caso de negocio

Algunos usuarios empresariales tienen información que no debería estar disponible para
todos. Anteriormente, tenían que descargar o copiar datos de informes globales en sus
propios documentos de hoja de cálculo y unir su información individual allí.
Con SAP BW/4HANA, es posible definir diferentes objetos para datos locales y globales y
generar combinaciones en ambos conjuntos de datos en la memoria.
Verá más ejemplos de cómo ItelO puede beneficiarse de SAP BW/4HANA en los ejercicios del
curso.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Conozca el caso práctico de ItelO

26 © Copyright. Reservados todos los derechos.

 Capítulo 2
Lección 2
Comprensión del modelo de datos del sistema
fuente

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Comprender cómo el modelo de datos del sistema fuente separa los datos

Comprender el modelo de datos del sistema fuente

Figura 21: Escenario empresarial: Comprender el modelo de datos ERP

En este curso, seguirá un caso práctico. En este caso práctico, usted es el jefe del
departamento de TI de ITelo, que vende hardware y software. La empresa se enfrenta a
problemas con informes faltantes o inconsistentes para algunos procesos empresariales.
Debe comprender la infraestructura de TI actual y verificar qué datos están disponibles en
cada tabla. Debe tener en cuenta cómo se separan los datos en las fuentes y cómo deben
separarse en la gestión de informes. Esta es la base para los requisitos de armonización y la
infraestructura de TI de destino.

© Copyright. Reservados todos los derechos. 27

Capítulo 2 : Resumen del caso de negocio

Figura 22: Estudio de caso: Segmentos de negocio separados

Para empezar, identifique los procesos empresariales que son relevantes para el reporting
global. En este caso práctico, el almacenamiento y las ventas son las dos áreas de actividad
de interés.
En segundo lugar, defina cómo se divide la organización. En este caso práctico, la distinción
principal es el origen de los datos. Esta distinción es importante porque ITelO, Minorista King
3000 y otras fuentes externas como equipos locales u organizaciones de compras tienen
diferentes modelos de datos. Además, cada organización consta de diferentes unidades
organizativas. Cada unidad organizativa opera diferentes almacenes (que es especialmente
importante para el almacenamiento, pero también para las ventas).
El tercer paso es investigar cómo se representa esta separación en los sistemas técnicos.
Cada segmento empresarial almacena sus datos en un conjunto de tablas de base de datos.
Anote las tablas que se utilizan en más de un segmento empresarial. En nuestro caso
práctico, tanto el almacenamiento como las ventas utilizan las tablas de datos maestros de
producto.
Identifique qué campo representa la unidad organizativa. Si desea extraer valores solo para
una unidad organizativa, aplique un filtro en este campo.
Al inspeccionar las tablas relevantes, hágase las siguientes preguntas:
● ¿Qué campos siempre tienen valores únicos? ¿Qué campos contienen valores que podrían
repetirse en diferentes filas?
● ¿Existe una tabla de verificación para un campo? ¿Solo puede introducir valores que estén
listados en otras tablas?
● ¿Qué valores pueden cambiar y cuándo?

La definición de tabla es la fuente principal de información y puede encontrarla mediante la

transacción SE11 o en la base de datos subyacente (si está autorizado). Los diferentes
registros se distinguen por diferentes valores clave. Algunas tablas tienen una clave técnica
que corresponde a una clave semántica. Por ejemplo, la tabla de posiciones de pedido de
cliente SNWD_SO_I tiene un campo clave técnico NODE_KEY y corresponde a una

28 © Copyright. Reservados todos los derechos.

 Lección: Comprensión del modelo de datos del sistema fuente

combinación de número de pedido de cliente y número de posición. El mismo número de

posición, como 10, aparece en diferentes pedidos de cliente. El mismo número de pedido de
cliente puede aparecer en registros diferentes con diferentes números de posición. Sin
embargo, las entradas en el campo NODE_KEY son unívocas. Almacenar datos para una
combinación existente de número de pedido de cliente y número de posición significa
modificar el registro existente para esta combinación.

Figura 23: Estudio de caso: unir segmentos separados

En un cuarto paso se define una infraestructura de destino. En el caso práctico de ITelO, la

tarea principal es combinar los valores de almacenamiento y de ventas de diferentes fuentes.
Por ejemplo, ITelO desea ver la suma de todos los volúmenes de ventas de la misma
categoría.
Para definir esta tarea a nivel empresarial, verifique qué separación debe quedar y qué nivel
de integración está previsto.
Para comprender la tarea de integración, primero verifique qué diferencias existen entre los
procesos empresariales correspondientes. A continuación, verifique las diferencias en el
modelo de datos (nombres de tabla, campos de tabla, valores permitidos y comportamiento
cuando se modifican los datos).
Después de investigar las diferencias, puede diseñar un modelo para integrar los datos
siguiendo estos pasos (este proceso se definirá con más detalle más adelante en este curso):

1. Homogeneizar los datos maestros.

En este caso práctico, es fácil integrar datos maestros de producto porque el comerciante
King 3000 vende los mismos productos y utiliza el mismo ID de producto. Sin embargo, el
comerciante King 3000 utiliza diferentes datos maestros como categorías y precios de
producto. Decida qué sistema es el principal, es decir, de qué sistema se toma la
información de precio y categoría. Como alternativa, ambas opciones se pueden
presentar como una opción para el usuario empresarial.

2. Preparar datos de transacción.

© Copyright. Reservados todos los derechos. 29

Capítulo 2 : Resumen del caso de negocio

En este caso práctico, el almacenamiento y las ventas siguen siendo áreas de gestión de
informes separadas. Para el almacenamiento, ambas fuentes tienen tablas de diseño
similar y basta con una vista que reúna ambas fuentes. Para los datos de ventas, es
necesario cargar valores armonizados. Asigne datos de diferentes sistemas al mismo
formato y, a continuación, añada un campo distintivo de origen a la clave de cada tabla.

3. Defina una consulta, una vista o un informe.

Defina una consulta, una vista o un informe que agregue los valores de ventas en ambas
fuentes y que combine los datos maestros y otros datos externos.

Las tareas adicionales incluyen la integración de fuentes poco relacionadas. En nuestro caso
práctico, desea comparar los importes de ventas y compras. Los usuarios empresariales
también desean enriquecer los datos de ventas globales con información sobre los equipos
de ventas. Por lo tanto, debería configurarse un área de trabajo separada.
Es una tarea importante analizar las relaciones entre las tablas y el formato de datos de
origen existente. En el siguiente ejercicio, identifique cómo se utilizan con frecuencia los
objetos de tratamiento, como el producto y el empleado, se enumeran en tablas de referencia
y se utilizan en otras tablas. Obtenga un resumen del modelo de origen y sus tablas.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Comprender cómo el modelo de datos del sistema fuente separa los datos

30 © Copyright. Reservados todos los derechos.

 Capítulo 2

Evaluación de la formación

1. Si se añade un campo nuevo a la definición de clave de una tabla de base de datos, se

pueden distinguir menos registros.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

2. Uno de los objetivos de la investigación de los modelos fuente de diferentes sistemas

fuente es verificar qué homogeneización de los datos maestros es necesaria.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

© Copyright. Reservados todos los derechos. 31

 Capítulo 2

Respuestas a la Evaluación de la formación

1. Si se añade un campo nuevo a la definición de clave de una tabla de base de datos, se

pueden distinguir menos registros.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

Tienes razón. Si hay más campos que forman parte de la definición de clave de una tabla
de base de datos, existen más criterios para distinguir registros y se pueden distinguir
más registros diferentes. Leer más en el módulo Comprender cómo el modelo ERP separa
los datos, en el curso BW430.

2. Uno de los objetivos de la investigación de los modelos fuente de diferentes sistemas

fuente es verificar qué homogeneización de los datos maestros es necesaria.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

Tienes razón. La homogeneización de datos maestros y la preparación de datos

transaccionales de diferentes fuentes son tareas típicas de proyectos BW. Para juzgar los
pasos requeridos, se requiere investigar los modelos de origen. Leer más en el módulo
Comprender cómo el modelo ERP separa los datos, en el curso BW430.

32 © Copyright. Reservados todos los derechos.

CAPÍTULO 3 Enfoques de modelado en SAP
BW/4HANA

Lección 1
Opciones de almacenamiento de datos 35

Lección 2
Aspectos clave del modelado de SAP HANA 41

Lección 3
Aspectos clave del modelado de SAP BW/4HANA 47

Lección 4
Comparación del enfoque de SAP BW/4HANA, el enfoque de SAP HANA y las estrategias mixtas 61

Lección 5
Aspectos clave de la analítica integrada de S/4HANA 75

OBJETIVOS DEL CAPÍTULO

● Comprender los conceptos de almacenamiento de datos

● Comprender las ventajas y características del modelado de SAP HANA
● Comprender las ventajas y características del modelado de SAP BW/4HANA
● Compare el enfoque de SAP BW/4HANA, el enfoque de SAP HANA y las estrategias
mixtas
● Comprender la analítica integrada de S/4HANA

© Copyright. Reservados todos los derechos. 33

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

34 © Copyright. Reservados todos los derechos.

 Capítulo 3
Lección 1
Opciones de almacenamiento de datos

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Comprender los conceptos de almacenamiento de datos

Introducción a los conceptos de almacenamiento de datos

Figura 24: Escenario empresarial: Resumen

Su empresa, ITelO, desea instalar una aplicación de almacén de datos. Las cuestiones clave
son las siguientes:
● Procesamiento de grandes volúmenes de datos
● Integrar aplicaciones de SAP y de terceros, aplicaciones basadas en la nube y lagos de
datos
● Cumplir con las expectativas de alto desempeño
● Dar soporte a analíticas predictivas y en tiempo real ágiles
● Uso de datos no utilizados anteriormente

Conozca cómo SAP da soporte al futuro del almacenamiento de datos.

© Copyright. Reservados todos los derechos. 35

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Figura 25: Soluciones de almacén de datos de SAP HANA

Dentro del nuevo concepto de almacén de datos de SAP HANA, se pueden operar dos tipos
de almacén de datos en paralelo. SAP BW/4HANA, tal como se ha presentado hasta ahora en
esta unidad, es una aplicación de SAP. El almacén de datos SQL nativo de SAP HANA es un
enfoque basado en SQL.
Ambos utilizan los servicios de SAP HANA. Ambos proporcionan funciones para el acceso
virtual a datos de fuentes SAP y no SAP, para procesos ETL (extracción, transformación,
carga) y también para datos de streaming. Ambos tipos de almacén de datos se pueden
utilizar como proveedor de datos para herramientas analíticas.

Como enfoque de almacenamiento de datos adicional, se puede acceder a Big Data Lakes
utilizando Apache Hadoop y SAP Vora.

Figura 26: Enfoque de SAP BW/4HANA

36 © Copyright. Reservados todos los derechos.

 Lección: Opciones de almacenamiento de datos

Como enfoque basado en aplicaciones, SAP BW/4HANA sigue siendo la aplicación premium
data warehouse (DW) con servicios integrados. En la imagen "Enfoque de SAP BW/4HANA"
se enumeran sus herramientas, funciones, ventajas, desventajas y una recomendación.

Ventajas del enfoque de SAP BW/4HANA

● SAP BW/4HANA ofrece todos los servicios de almacenamiento de datos necesarios
utilizando un repositorio integrado.
● SAP BW/4HANA ofrece muchas herramientas, como Query Designer y herramientas de
modelado BW para modelar, supervisar y gestionar el almacén de datos.
● No se requiere ninguna herramienta adicional, pero se puede integrar.
● SAP BW/4HANA admite una amplia gama de sistemas fuente utilizando ODP y otras
opciones de aprovisionamiento de datos.
● Se mejorarán aún más 20 años de desarrollo de funciones relacionadas con el diseño del
modelo, la transformación de datos, la carga de datos programada, la supervisión de la
carga de datos, la gestión del transporte y la autorización de análisis.

Desventajas del enfoque de SAP BW/4HANA

● El conjunto predefinido de tipos de objeto y la tecnología de flujo de datos estandarizados
restringen la libertad y la flexibilidad en comparación con el enfoque basado en SQL.

Nota:
SAP BW/4HANA es adecuado para clientes con sistemas BW (ABAP) existentes
que utilizan principalmente sistemas de software de SAP. Pueden crecer
gradualmente hacia el enfoque de almacén de datos de SAP HANA.

Figura 27: Enfoque nativo de almacén de datos SQL

© Copyright. Reservados todos los derechos. 37

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Como enfoque basado en SQL, el almacén de datos SQL nativo requiere varias herramientas
acopladas de forma flexible con repositorios separados para completar las tareas necesarias.
Se utiliza una combinación de herramientas (como la mejor de su clase) para crear el
almacén de datos SQL. Principalmente, los datos se seleccionan y se transforman mediante
scripts y funciones basados en SQL o SQL. La imagen "Enfoque de almacén de datos nativo
SQL" enumera sus herramientas, funciones, ventajas, desventajas y una recomendación.

Ventajas del enfoque Native SQL Data Warehouse

● Con los servicios de SAP HANA EIM, SAP ofrece una variedad de funciones para extraer y
procesar datos, incluida la minería de datos y las funciones de negocio.
● Un IDE basado en la web está disponible para diseñar y publicar objetos. Con SQL, puede
definir libremente los modelos de datos y transformaciones y realizar escenarios
complejos y grandes.

Desventajas del enfoque Native SQL Data Warehouse

● Altos esfuerzos de gobernanza y desarrollo para la integración de diferentes herramientas.

Nota:
SAP BW/4HANA es adecuado para clientes que desean sustituir un almacén de
datos de terceros o ampliar el alcance de un modelo SAP HANA nativo existente,
utilizar principalmente sistemas de software que no sean de SAP y tener
conocimientos suficientes de SQL.
Actualmente, puede integrar estrechamente ambos enfoques en un escenario
mixto. SAP invierte en el desarrollo de herramientas para gestionar escenarios
mixtos de punta a punta: modelado, mecanismos de transporte, interfaces de
consumo. La visión es converger ambos conjuntos de herramientas en una pila de
tecnología que satisfaga las necesidades de BW/4HANA y el almacén de datos
basado en SQL.

SAP Data Warehouse Cloud

SAP Data Warehouse Cloud es una solución complementaria dirigida a los usuarios de una
línea de negocio. Proporciona una GUI de modelado simple y basada en la web, y requiere
poco esfuerzo administrativo. Como DWC se basa en la plataforma SAP HANA, se puede
integrar una amplia gama de fuentes.

38 © Copyright. Reservados todos los derechos.

 Lección: Opciones de almacenamiento de datos

Figura 28: DWC_features_Image.pptx

Con la gestión de espacios, se pueden administrar usuarios y conexiones. El monitor de

integración de datos muestra todas las conexiones y permite cambiar entre la replicación de
datos y la federación. El Generador de datos proporciona la capa técnica en DWC, donde
puede crear tablas y modelar las vistas. Los modelos existentes se pueden ampliar. Con el
generador de historias, se pueden definir dashboards e historias. El catálogo empresarial da
acceso a la capa empresarial de DWC. (La capa empresarial contiene el objetivo empresarial y
los metadatos de los modelos.)

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Comprender los conceptos de almacenamiento de datos

© Copyright. Reservados todos los derechos. 39

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

40 © Copyright. Reservados todos los derechos.

 Capítulo 3
Lección 2
Aspectos clave del modelado de SAP HANA

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Comprender las ventajas y características del modelado de SAP HANA

Comprensión de las ventajas y las características del modelado de SAP HANA

Figura 29: Escenario empresarial: Ventajas y características del modelado de SAP HANA

Como modelador de SAP BW/4HANA, necesita una comprensión básica de las ventajas y los
conceptos de SAP HANA. Para tomar una decisión sobre el conflicto entre la consistencia de
datos y los costes de almacenamiento y para desarrollar una estrategia de almacenamiento
de datos, debe hacer lo siguiente: verificar las tablas de datos existentes y verificar cuántos
KB se utilizan en la memoria principal. También debe comprender los conceptos de
almacenamiento de datos y conocer las alternativas, como las vistas de SAP HANA para el
acceso remoto y el almacenamiento ampliado de SAP HANA en disco.

© Copyright. Reservados todos los derechos. 41

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Figura 30: Ventajas de SAP HANA: cálculo en memoria

Con SAP HANA, los valores agregados se calculan en memoria, en los mismos medios de
almacenamiento en los que se almacenan los datos. Este proceso de almacenamiento es 10
veces más rápido que otras soluciones. El almacenamiento en SAP HANA está optimizado
para la generación de informes y proporciona cálculos más rápidos para la suma de columnas
y otros valores agregados. Por lo tanto, no es necesario rellenar tablas separadas con valores
agregados o precalculados.
Para las tablas con un tipo de almacenamiento basado en columnas, SAP HANA almacena
valores comprimidos. El tamaño de almacenamiento requerido es aproximadamente del 20%
del tamaño no comprimido. Los procesos de filtrado y agregación de datos se ejecutan a gran
velocidad, directamente en los valores comprimidos en la memoria.

SAP HANA: Almacenamiento de datos

SAP HANA proporciona tres tipos de almacenamiento:
● CPU
Para el procesamiento de datos, los datos se cargan en unidades centrales de
procesamiento (CPU). Se trata de un espacio de almacenamiento temporal.
● RAM
Para conservar datos y aprovechar las ventajas en memoria.
● Discos de almacenamiento
Para mantener los datos de forma permanente, incluso en caso de fallo de alimentación,
los discos de almacenamiento realizan un seguimiento de todos los datos y los cambios.

El tipo de almacén en filas es principalmente para tablas pequeñas y tablas a las que se
accede principalmente por operaciones en un solo registro.
En SAP BW/4HANA, el tipo de columna es más importante. Se utiliza automáticamente para
la mayoría de las tablas que están relacionadas con objetos de SAP BW/4HANA como ADSO
e InfoObjetos. Las nuevas tablas definidas por el cliente son tablas de almacenamiento en
columnas a menos que se especifiquen individualmente.
El tipo de almacenamiento en columnas tiene las siguientes ventajas:

42 © Copyright. Reservados todos los derechos.

 Lección: Aspectos clave del modelado de SAP HANA

● Compresión: en lugar de almacenar texto, se almacenan sustitutos binarios de valores

internos. Los filtros y las operaciones de unión son mucho más rápidos en estos valores
internos.
● Partición y paralelización: Una tabla se puede dividir en muchas particiones. Cada
partición se almacena físicamente como una sola tabla y todas las particiones de una tabla
de base de datos se pueden leer en paralelo.
● Solo inserción en delta: cuando se modifican valores o se introducen nuevos valores, el
nuevo valor se almacena en una memoria delta pequeña y separada sin compresión de
datos. De vez en cuando, un job de fusión delta fusiona el almacenamiento en columnas
delta y principal. Durante este job de fondo, la compresión de datos se ajusta para incluir
todos los valores nuevos.

El modelador de datos puede utilizar el concepto de almacenamiento de SAP HANA de

diferentes maneras:
● La caché de CPU se puede aprovechar reutilizando las mismas vistas.
● La cantidad de datos a buscar se puede limitar definiendo particiones para campos
extraídos o filtrados regularmente.
● El tamaño del almacenamiento delta se puede mantener pequeño definiendo las opciones
de fusión delta inteligente, especialmente en los procesos de carga (DTP o cadenas de
procesos) de SAP BW/4HANA.
● El tiempo de acceso se puede reducir seleccionando el tipo de almacenamiento correcto
de las tablas definidas por el cliente.

El administrador de la base de datos puede hacer lo siguiente:

● Defina las opciones de fusión delta predeterminadas para especificar las condiciones de
umbral cuando se ejecuta el job de fusión delta.
● Planifique periódicamente una copia de seguridad externa.

Figura 31: Modelado de SAP HANA: Ventajas

© Copyright. Reservados todos los derechos. 43

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

¿Cómo puede un modelador utilizar las funciones de SAP HANA?

La combinación de datos en la CPU es rápida, por lo tanto, un modelador de datos no necesita
almacenar conjuntos de resultados de operaciones de cálculos, combinaciones o unión en
nuevas tablas. En su lugar, se pueden definir vistas con joins o unión de tablas físicas
existentes durante un diseño de modelo. Solo la definición debe almacenarse como vista de
cálculo de SAP HANA. Esto se denomina modelo nativo de SAP HANA.
Incluso los valores de diferentes tablas físicas se pueden combinar en un resultado durante la
ejecución de la consulta. Si una consulta accede a una vista, la sentencia select se divide en
varias sentencias que se leen desde las tablas subyacentes.
La vista se crea normalmente en el mismo sistema SAP HANA que las tablas de datos físicos.
Cuando se deben combinar datos de diferentes fuentes, los datos de otros sistemas fuente se
pueden copiar a SAP HANA. Puede copiar datos de las siguientes maneras:
● Importar a través de lote con un retraso en la disponibilidad. Esto se puede hacer una vez o
periódicamente.
● Replicación en tiempo real utilizando un método de captura de datos de modificación (ya
sea basado en desencadenante o en log) de una tabla fuente.

No solo es posible leer de tablas físicas del mismo sistema SAP HANA. En lugar de copiar
datos, es posible crear una tabla virtual. Para una tabla virtual, solo se importan la estructura
de tabla y otros metadatos, y se genera una referencia a los datos remotos.
Una tabla virtual se puede utilizar en una vista. Cuando se lee la vista, los datos se leen desde
la fuente remota, siguiendo la referencia de la tabla virtual.
En una vista, se pueden crear definiciones de filtro adicionales para restringir el contenido de
la tabla. Se pueden definir cálculos y métodos de agregación de anulación de utilización.
Todos estos cálculos se ejecutan con gran velocidad en la memoria.

Ventajas del modelo de datos virtual (VDM)

● Reducir la huella de datos
Los datos se pueden combinar en un modelo de datos virtual utilizando vistas de cálculo
SAP HANA (vistas de columna) con filtros y cálculos. Se necesita menos espacio físico de
almacenamiento de datos.
● Reducir el número de objetos
En lugar de un objeto de destino, transformación y procesos de fondo, solo se debe crear
el objeto de destino (la tabla virtual o la vista).
● Obtener valores actualizados
Los datos se pueden replicar constantemente en tiempo real o leer de forma remota (tabla
virtual).
● Flexibilidad
El modelado se vuelve más flexible. Sin impacto en el almacenamiento o el tiempo de
ejecución de otros modelos, se puede definir una nueva vista siempre que sea necesaria.
Puede definir consultas complejas utilizando el lenguaje de consulta estructurado (SQL).
● Comprensibilidad
Los datos se leen tal cual, por lo que el riesgo de cálculos ofuscados es bajo.
● Reducir el cuello de botella

44 © Copyright. Reservados todos los derechos.

 Lección: Aspectos clave del modelado de SAP HANA

SAP HANA está optimizado para calcular valores en la capa de base de datos. Esto reduce
la necesidad de transportar datos entre la base de datos y la aplicación porque solo se
presenta el resultado a la capa de aplicación. Esto significa que se procesa menos lógica
empresarial en la capa de aplicación. El número de programas ejecutados en la capa de
aplicación se puede reducir.

Directrices para un buen rendimiento del tiempo de ejecución

● Importar o replicar datos para los valores que se necesitan con frecuencia
● Seleccione solo los campos necesarios para el siguiente nivel
● Filtrar anticipadamente
● Preferir la unión sobre la combinación
● Calcular después de agregación

Figura 32: Detalles de SAP HANA: esquemas de SAP HANA

SAP HANA puede contener tablas para diferentes aplicaciones, incluso si tienen los mismos
nombres de tabla. Cada aplicación tiene su propia conexión a la base de datos de SAP HANA.
Para el sistema SAP XYZ, el nombre de la conexión de base de datos primaria suele ser el
usuario de base de datos de SAP HANA SAPXYZ. Para cada usuario y, por lo tanto, para cada
conexión, existe una sección lógica correspondiente de la base de datos, llamada esquema.
Los nombres de tabla y de objeto son únicos dentro de un esquema, pero pueden repetirse
entre diferentes esquemas. Las autorizaciones se pueden otorgar por objeto o por esquema.
Todas las vistas de cálculo se publican en el esquema* _SYS_BIC. Este esquema y todos sus
objetos pertenecen a un usuario de base de datos estándar, _SYS_REPO. La herramienta de
front end para los usuarios de administración de BD y el modelado de vistas de SAP HANA es
SAP HANA Studio o SAP Cloud Platform Web IDE (entorno de escritorio integrado).

© Copyright. Reservados todos los derechos. 45

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Figura 33: Estrategia de almacenamiento de datos: acceso a datos

La memoria sigue siendo más cara que el espacio en disco, pero tiene varias posibilidades de
reducir los costes de almacenamiento.

Estrategia de almacenamiento de datos

1. Para datos muy relevantes, seleccione el almacenamiento en columnas como el tipo de
almacenamiento y conserve los valores en la memoria. (Esto se denomina datos activos).
La compresión de datos automática reduce la huella de datos.

2. Para los datos en masa en esta instancia de SAP HANA, almacene los datos en el disco. A
continuación, el precio es comparable a los costes de almacenamiento de las bases de
datos clásicas. Esto se denomina datos de acceso frecuente.

3. Para los datos externos menos importantes, deje los datos en el almacenamiento externo
para evitar el almacenamiento redundante de los datos. Acceda a los valores necesarios
como contenido de tabla virtual mediante Smart Data Access. Esto se denomina datos
geniales.

Directrices para reducir los costes de almacenaje

● Evite el almacenamiento redundante.
● Seleccione el nivel de almacenamiento correcto. Utilice el espacio de memoria solo para
datos importantes y de lectura frecuente (datos calientes).
● Desarrollar un concepto de archivo para datos históricos y obsoletos. Esto a veces se
denomina datos grabados.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Comprender las ventajas y características del modelado de SAP HANA

46 © Copyright. Reservados todos los derechos.

 Capítulo 3
Lección 3
Aspectos clave del modelado de SAP BW/
4HANA

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Comprender las ventajas y características del modelado de SAP BW/4HANA

Comprender las características de SAP BW/4HANA

Figura 34: Escenario empresarial: Ventajas y problemas del modelado de SAP HANA

Su empresa, ITelO, ha instalado una aplicación de almacén de datos de SAP BW/4HANA.

Desea comprender las ventajas de SAP BW/4HANA, explorar la herramienta de modelado
BW y aprender los principios de la arquitectura de SAP BW/4HANA.

© Copyright. Reservados todos los derechos. 47

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Figura 35: Motivación: Objetivos de una solución de almacén de datos

La evaluación de datos es posible con vistas de cálculo nativas de SAP HANA. Sin embargo,
hay casos de uso en los que una aplicación específica para la gestión de informes es más
potente y conveniente. Una solución de este tipo se denomina almacén de datos. El objetivo
de un almacén de datos es estructurar y visualizar toda la información de la empresa
necesaria para salvaguardar las ventajas estratégicas y operativas de una empresa frente a
otras empresas.
SAP Business Information Warehouse (SAP BW/4HANA) es la solución de almacén de datos
de SAP. Los principales motivos para introducir un almacén de datos son el análisis de datos,
el almacenamiento de datos redundantes, la preparación de datos para la generación de
informes y la integración de datos de muchas fuentes, de forma programada periódicamente,
con excelentes posibilidades de supervisión.
Para los usuarios empresariales, la ventaja más visible es que SAP BI proporciona
herramientas de front end intuitivas que mejoran las posibilidades de autoservicio de los
usuarios empresariales y las hacen independientes de TI. Estas herramientas están
estrechamente integradas con SAP BW/4HANA.
Tradicionalmente, sin un almacén de datos, los informes tenían que realizarse en el sistema
operativo utilizando informes programados por TI o entregados previamente por SAP a
través de transacciones específicas de un sistema de información. Sin embargo, la posibilidad
de influir en dichos informes se limita a los filtros integrados y las posibilidades de desglose.
No es posible ampliar estas posibilidades sin la ayuda del equipo de soporte al usuario de TI.
Echemos un vistazo a las diferentes ventajas en más detalle, como se enumera en la figura,
Destinos de una solución de almacén de datos.

Herramientas de análisis de datos

Existen herramientas para diferentes tareas de análisis de datos:
● Herramientas flexibles de análisis de autoservicio como SAP Business One Analysis,
edición para Microsoft Office, con funciones para modificar las propiedades de
visualización, para mejorar las propiedades de selección y desglose y para añadir cálculos
locales.

48 © Copyright. Reservados todos los derechos.

 Lección: Aspectos clave del modelado de SAP BW/4HANA

● Empresa estandarizada con calidad de información garantizada (como SAP Crystal

Reports para SAP Business One) con funcionalidad de autoservicio restringida.
● Dashboards para análisis interactivos (como aplicaciones de Design Studio) que guían a
los usuarios empresariales a través de opciones predefinidas para ajustar y personalizar el
informe.
● Reporting de alto rendimiento (ad hoc) como BI Explorer o SAP BusinessObjects Lumira
para filtros rápidos y visualización gráfica de valores seleccionados.
● Servicios analíticos (para minería de datos, planificación, etc.) que le permiten ejecutar
modelos de minería de datos predefinidos como el análisis ABC.

Almacenamiento de datos
● Los datos se almacenan de forma redundante fuera del sistema fuente en un
almacenamiento de datos separado. Por lo tanto, el acceso a datos para fines analíticos no
consume los recursos del sistema fuente, y lo contrario también es verdadero.
● El historial de datos se puede mantener independiente de, pero refleja los cambios en el
sistema fuente, normalmente cargando los valores modificados cada noche.
● El almacenamiento está optimizado para el acceso de lectura, especialmente con SAP
BW/4HANA powered by SAP HANA, y todas las tablas relevantes para la generación de
informes se almacenan en formato de almacenamiento en columnas.

Preparación de datos
Los datos se preparan en el almacén de datos específicamente para la gestión de informes:
● Si diferentes sistemas fuente suministran valores en diferentes tipos de datos, monedas o
con diferentes textos o atributos, la homogeneización puede tener lugar durante el
proceso de staging.
● Las técnicas de limpieza evitan duplicados, mantienen solo la información de estado más
reciente y garantizan la integridad referencial.
● Las definiciones de jerarquías y el cálculo de valores totales garantizan resultados
matemáticos correctos.

Aprovisionamiento de datos
El aprovisionamiento de datos en diferentes sistemas fuente permite lo siguiente:
● La programación distribuida permite la extracción de datos durante períodos de actividad
baja tanto en el sistema fuente como en el sistema de informes. Además, es posible una
distribución equitativa de los recursos a lo largo de la noche.
● SAP BW/4HANA proporciona funcionalidades detalladas de supervisión y simulación que
ayudan a identificar y evitar errores, y le permite volver a cargar solicitudes de datos con
valores incorrectos sin obtener valores totales incorrectos.
● La integración (ensamblaje) de datos de diferentes fuentes se puede gestionar cuando
distintas fuentes proporcionan diferentes ratios o atributos.

© Copyright. Reservados todos los derechos. 49

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Figura 36: Motivación: Decisiones para una solución de almacén de datos

La imagen "Decisiones para una solución de almacén de datos" enumera las decisiones de
modelado para cada uno de estos objetivos.

Figura 37: Objetos de SAP BW/4HANA (InfoObjetos)

Un informe siempre se centra en algún aspecto de su empresa, por ejemplo, los detalles de
producción o un resumen de ventas en toda la empresa. Un sujeto empresarial es una entidad
lógica que se utiliza para describir algún aspecto de su empresa, independientemente de
cualquier implementación técnica. Los ejemplos incluyen el volumen de ventas, la cantidad de
almacenamiento, el cliente, el producto, la categoría de producto, la gestión de nivel medio y
la unidad organizativa.

50 © Copyright. Reservados todos los derechos.

 Lección: Aspectos clave del modelado de SAP BW/4HANA

En SAP BW/4HANA, los objetos técnicos se utilizan para representar información sobre
objetos de tratamiento. Para unir diferentes escenarios de manera eficiente, las propiedades
formales deben estar bien definidas.
En SAP BW/4HANA, un InfoObjeto es una definición de campo para un sujeto empresarial,
similar a un dominio DDIC ABAP. La figura, Objetos de SAP BW/4HANA (InfoObjetos)
muestra los diferentes tipos de InfoObjetos.
Algunos objetos de tratamiento tienen un significado solapado. Si existen diferentes roles de
interlocutor comercial, como proveedor y cliente, se pueden modelar como InfoObjetos
separados (0VENDOR, 0CUSTOMER) o como un InfoObjeto genérico 0BUS_PARTNER.
Cada InfoObjeto o objeto SAP BW/4HANA se identifica por su nombre técnico. Se utilizan
diferentes InfoObjetos para diferentes sujetos, incluso si tienen las mismas propiedades
formales. Por ejemplo, 0AMOUNT es un valor de importe genérico. 0D_NW_GAMT representa
el importe bruto, el importe neto 0D_NW_NAMT y el importe del impuesto 0D_NW_TAMT.
También puede tener diferentes InfoObjetos para los mismos objetos empresariales si
pertenecen a diferentes áreas de nombres o si los detalles técnicos son diferentes. Por
ejemplo, 0D_NW_TAMT representa el importe del impuesto en los escenarios de
demostración, 0TAX_VALUE en los informes en vivo de ventas y distribución.
El modelador de datos crea un modelo de datos para una implementación de SAP BW/
4HANA. Los modeladores de datos definen qué objetos se necesitan y cómo deben
configurarse.
El modelador de datos debe definir los siguientes detalles técnicos para cada InfoObjeto:
● Formato de datos
● Visualizar propiedades (por ejemplo, el número de decimales)
● Propiedades de almacenamiento (¿Qué tablas de texto existen?)
● Propiedades de cálculo (por ejemplo, conversión de unidades)

Subtipos de InfoObjetos
● Ratios
Los ratios son InfoObjetos de valores matemáticos con características de cálculo o
agregación. El modelador de datos debe definir el tipo de agregación, la unidad o moneda
de referencia y el formato de número.
● Características
Las características son InfoObjetos de listas de valores (sin las características de cálculo o
agregación). Las características proporcionan dos funciones en SAP BW/4HANA:
- Definen un tipo de datos, por ejemplo, una cadena de caracteres numéricos con 10
dígitos.
- Se utilizan como una lista de valores permitidos para datos maestros almacenados, ya
que son objetos de tratamiento con la tabla de datos maestros correspondiente.

El modelador de datos debe definir las opciones para clave, texto, atributos y jerarquías
como idioma, versión o dependencia temporal. Además, las rutinas se pueden definir
como la transformación estándar del contenido.
● Características de tiempo
● Unidades

© Copyright. Reservados todos los derechos. 51

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Las unidades son InfoObjetos para unidades de medida o información de moneda.

La definición de estos tipos de objetos suele ser estándar y rara vez cambia.

Figura 38: Objetos de SAP BW/4HANA (reporting)

La figura, Objetos de SAP BW/4HANA (reporting), muestra otros objetos BW relevantes para
reporting.
Una consulta es una definición multidimensional predefinida de una selección de datos.
Contiene propiedades para la presentación predeterminada y la agregación de valores como
jerarquías, definiciones de fila total, texto y formatos de número.
Un modelador de datos define las características de desglose para filas y columnas, muestra
propiedades, fórmulas, condiciones y una definición de filtro (por ejemplo, mediante variable
= parámetros de entrada).
Un InfoSitio es un objeto para el que se pueden crear o ejecutar queries. Los InfoSitios son los
objetos o vistas que son relevantes para el reporting.

Tipos de InfoSitios
● Vista Open ODS
Permite el acceso virtual a una fuente sin transformación
● aDSO
Contiene datos
● Proveedor compuesto
Combina vistas con otros InfoSitios o vistas nativas de SAP HANA
● Proveedor BAdI
Permite ejecutar el código de programa
.

52 © Copyright. Reservados todos los derechos.

 Lección: Aspectos clave del modelado de SAP BW/4HANA

Decisiones de modelado clave

Las decisiones de modelado clave implican opciones de navegación, campos disponibles o
InfoObjetos, como
● Campos clave y dependientes (para aDSO con compresión definida por el usuario de
datos)
● Campos de proveedores art con asignaciones de campo (para InfoSitios lógicos)

Cada InfoSitio se asigna exactamente a una InfoÁrea, al igual que se asigna un fichero a un
directorio. Normalmente, una InfoÁrea corresponde a un área de responsabilidad.

Figura 39: Objetos de SAP BW/4HANA (staging)

La figura, Objetos de SAP BW/4HANA (staging), muestra los objetos de datos

transaccionales dependientes del sistema fuente.
Un sistema fuente es el nombre lógico de un sistema (aplicación o base de datos o incluso
una conexión de fichero) al que se puede acceder desde SAP BW/4HANA.
Una fuente de datos (DS) es una definición de estructura para extraer datos. Se puede definir
en sistemas SAP ECC y los metadatos se replican en SAP BW/4HANA. Para otros tipos de
conexión, se puede crear como una lista de campos con propiedades específicas en SAP BW/
4HANA.
La fuente de datos contiene información sobre la ubicación de los datos necesarios y la
estructura de los datos.
De forma similar a una InfoFuente, se pueden definir campos clave. Un campo se puede
definir como un campo de selección, donde los valores de filtro se pueden aplicar durante la
extracción para reducir la cantidad de datos. Además, las propiedades del mecanismo delta
se definen y, en algunos casos, se pueden modificar.
Un flujo de datos contiene los objetos que se utilizan para cargar en un destino
Una InfoFuente es una estructura para combinar datos sin almacenamiento físico. Un
modelador de datos puede definir los campos o InfoObjetos y, opcionalmente, marcar
algunos campos como campos clave.

© Copyright. Reservados todos los derechos. 53

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Una transformación es un conjunto de reglas para transformar datos entre capas lógicas en
SAP BW/4HANA. Un proceso de transferencia de datos (DTP) es una definición de un
proceso de carga de datos entre capas físicas en SAP BW/4HANA. El modelador de datos
puede definir valores de filtro, grupos semánticos y opciones de rendimiento. El DTP se basa
en una secuencia de transformaciones.

SAP BW/4HANA proporciona conexiones para sistemas SAP y ficheros planos, a Apache
Hadoop y SAP HANA. Con una conexión a SAP HANA, puede recuperar valores de diferentes
esquemas u otras fuentes conectadas a la base de datos de SAP HANA. La imagen "Sistemas
fuente BW/4HANA" muestra sus interfaces correspondientes.

Figura 40: Sistemas fuente de SAP BW/4HANA

Las siguientes tecnologías se utilizan para cargar datos en SAP BW/4HANA y se ordenan de
la más recomendada a las posibilidades exóticas en casos poco frecuentes:
● SAP HANA
Si se necesitan datos de otro esquema de la misma base de datos HANA, utilice un
sistema fuente local SAP HANA. Muchas fuentes SAP y no SAP se pueden implementar
utilizando el adaptador SDI y el sistema fuente HANA. Incluso los sistemas SAP
NetWeaver (ECC, SAP S/4HANA, otros sistemas BW) se pueden conectar mediante
adaptadores SDI, pero recomendamos más bien Operational Data Provisioning (ODP).
Ambos mecanismos soportan los mecanismos Delta en general.
● Aprovisionamiento de datos operativos (ODP)
Se utiliza para proporcionar datos mediante la interfaz de programación de aplicaciones
(API) de replicación de datos ODP de diferentes fuentes, como SAP ERP Extractors, SAP
BW/4HANA, SAP HANA Views, SAP Business ByDesign, SAP Landscape Transformation
Replication Server (SLT). Se trata de un método de acceso rápido recomendado que toma
valores delta. Puede conectarse a muchos sistemas diferentes.
● Interfase de fichero
SAP BW/4HANA admite la importación automática de archivos en formato CSV, ASCII y
XLS para archivos planos. Es un buen método para generar datos de muestra para un
sistema de desarrollo. Si nada más funciona, casi todas las herramientas le permiten
generar archivos de texto con datos. Por lo tanto, también se utiliza como método de
conexión para aplicaciones exóticas.

54 © Copyright. Reservados todos los derechos.

 Lección: Aspectos clave del modelado de SAP BW/4HANA

● Interfaz de Big Data

Para grandes cantidades de datos, puede acceder a un clúster de Apache Hadoop a través
de un sistema fuente de Big Data.

El modelador de datos debe decidir qué conexión debe utilizarse para un sistema fuente.
Para sistemas SAP como SAP S/4HANA, ECC u otros sistemas BW/4HANA, se recomienda
ODP.
Para otros sistemas, intente conectarlo a Apache Hadoop o SAP HANA. En el peor de los
casos, se debe utilizar una conexión lenta a través de un archivo plano.
Para extraer de las vistas de cálculo de SAP HANA, utilice ODP.

Figura 41: Decisión de modelado para BW/4HANA: ¿staging de datos o acceso virtual?

Como regla general simple, siempre que los datos históricos tengan que estar disponibles
después de los cambios, es necesaria alguna forma de tecnología de carga de datos.
Con SAP HANA como base de datos, no es necesario cargar datos solo por motivos de
agregación previa. La agregación y la unión de datos se pueden realizar en la memoria.
Si no se producen modificaciones y el rendimiento de lectura de datos es aceptable, puede
evitar almacenar información redundante.
Con SAP BW/4HANA, almacene los datos a los que se ha accedido o los resultados de un
cálculo solo en las siguientes circunstancias:
● Si necesita un historial del conjunto de datos
● Si necesita un historial de modificaciones
● Si necesita comparar versiones antiguas y nuevas
● Si tiene cálculos que no se pueden realizar en la memoria con un buen rendimiento

© Copyright. Reservados todos los derechos. 55

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

● Si accede a fuentes que no son de SAP HANA sin computación in-memory

● Si necesitas una verdad armonizada reproducible y fiable

Evite cargar valores en las siguientes circunstancias:

● Si solo agrega valores detallados
● Si necesita los valores más recientes varias veces durante un día, y cada modificación en la
fuente debe reflejarse inmediatamente
● Si se deben calcular diferentes fórmulas que sean lo suficientemente simples como para
llevarse a cabo en la memoria

Para el reporting en tiempo real, puede empezar por acceder a los datos de forma remota
utilizando proveedores virtuales SDA o SAP BW/4HANA. Si el acceso a los datos es
demasiado lento, piense en utilizar tecnologías de importación y replicación de datos en su
lugar.
La imagen, Decisión de modelado para BW/4HANA: ¿Qué InfoSitios?, presenta esta
recomendación.

Figura 42: Decisión de modelado para SAP BW/4HANA: ¿Qué InfoSitios?

La imagen, Decisión de modelado para BW/4HANA: ¿Qué InfoSitios?, muestra los casos de
utilización del InfoSitio BW/4HANA.
El modelador de datos decide qué tipo de InfoSitio es el más adecuado para cada objeto.
Si se requiere la persistencia de datos, utilice un InfoObjeto (característica de tipo) para datos
maestros y un ADSO para datos transaccionales.
Si no se requiere la persistencia de datos, existen dos opciones para los datos maestros:
● InfoObjeto (característica) con datos virtuales
Seleccione esta opción si desea integrar la característica con otro InfoSitio o como
atributo de otro InfoObjeto.

56 © Copyright. Reservados todos los derechos.

 Lección: Aspectos clave del modelado de SAP BW/4HANA

● Vista Open ODS de textos de tipo o atributos

Seleccione esta opción cuando los datos maestros se deban combinar con otras vistas
Open ODS.

Para los datos de transacción sin persistencia de datos, también hay diferentes opciones:
● Seleccione un proveedor compuesto si existen InfoSitios de SAP BW/4HANA o vistas de
información de SAP HANA y el requisito se puede modelar como una unión o unión sobre
objetos existentes.
● Seleccione los hechos de tipo de vista Open ODS si se requiere el acceso directo de una
tabla o vista fuente, posiblemente con asociaciones con otras.

Figura 43: Decisión de modelado para SAP BW/4HANA: ¿Qué técnica de acceso a datos?

El proceso de extracción, transformación y carga (ETL), a veces llamado flujo de datos, es una
lista de los pasos que deben seguir los datos brutos (fuente) para extraerlos, transformarlos y
cargarlos en el destino de SAP BW/4HANA.
El modelador de datos decide cuál de los métodos de flujo de datos se debe utilizar para cada
mecanismo de carga. Las opciones se muestran en la figura, Decisión de modelado para BW/
4HANA: ¿Qué técnica de acceso a datos?
Si se necesitan los mismos valores en varios destinos o si se debe extraer una gran cantidad
de datos, se recomienda almacenar datos brutos en una tabla PSA. A continuación, las
transformaciones y otras actualizaciones dentro de SAP BW/4HANA no bloquean los
recursos en el sistema fuente.
Si la extracción es lo suficientemente rápida, especialmente con fuentes SAP S/4HANA, es
posible cargar valores en aDSOs directamente sin utilizar PSA. Esto evita el almacenamiento
redundante de datos.
Si no se requiere ningún historial o instantánea, pero se necesitan valores en tiempo real en
un informe, defina un proveedor de BAdI (para el acceso virtual) en SAP BW/4HANA. Si la
fuente lo admite, basta con una vista Open ODS. Este escenario no se recomienda para el

© Copyright. Reservados todos los derechos. 57

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

acceso frecuente no filtrado a datos brutos debido al impacto en el sistema fuente. (Cada
acceso a consulta necesita un proceso en el sistema fuente).

Figura 44: Decisión de modelado para BW/4HANA: ¿Qué transformaciones?

La clave de la tarea de integración es la transformación de datos. La imagen, Decisión de

modelado para BW/4HANA: ¿Qué transformaciones?, muestra diferentes opciones. Con la
tecnología en memoria SAP HANA, toma el control de un nuevo paradigma de modelado en la
capa de base de datos.
El enfoque clásico de la programación ABAP era el siguiente:

1. Conservar la carga de la base de datos.

2. Obtenga todos los datos que necesita en el servidor de aplicación.

3. Haga su procesamiento en ABAP, incluso para operaciones intensivas de datos.

Para beneficiarse de las capacidades de SAP HANA, es mejor realizar cálculos costosos y
agregaciones en la propia base de datos, en lugar de transferir grandes cantidades de datos al
servidor de aplicación ABAP. Se trata de un cambio fundamental en el paradigma de
programación ABAP. Se conoce como código a datos en contraposición al enfoque clásico de
datos a código.
Con las vistas de información de SAP HANA, los datos se combinan desde varias tablas. Se
pueden aplicar filtros, condiciones de conexión, cálculos y agregaciones. Las vistas de
información se desarrollan en SAP HANA utilizando herramientas de modelado fáciles de
utilizar y estas vistas de información se almacenan en SAP HANA junto a las tablas de base de
datos en el catálogo de base de datos.
Se puede acceder a ellos tan fácilmente como una tabla. Solo el resultado de los cálculos de la
vista se transporta a la capa de aplicación.
Tenga en cuenta que SAP BW/4HANA sigue este enfoque: Al activar los InfoSitios de BW/
4HANA, los escenarios de cálculo de SAP HANA se crean automáticamente. Puede decidir
manualmente crear vistas de cálculo SAP HANA visibles cada vez que se activan los
InfoSitios, pero esta función solo es necesaria si necesita crear más vistas sobre ellas en un

58 © Copyright. Reservados todos los derechos.

 Lección: Aspectos clave del modelado de SAP BW/4HANA

escenario híbrido. Con las opciones estándar, las transformaciones y las consultas de BW/
4HANA se calculan en SAP HANA.

Figura 45: Decisión de modelado para BW/4HANA: ¿Qué opciones de navegación?

La imagen, Decisión de modelado para BW/4HANA: ¿Qué opciones de navegación?, muestra

diferentes métodos de desglose. Seleccione el nivel estándar de un informe y los niveles de
detalle adicionales necesarios. Puede organizar los detalles según sea necesario.
Para obtener una visión más detallada de un nivel agregado a uno detallado, puede hacer lo
siguiente:
● Abrir nodos en una jerarquía.
● Filtre el valor de una línea y agregue una característica de desglose dentro de un informe.
● Saltar con RRI (interfaz informe-informe) a otro informe. A continuación, el valor de la
celda marcada actualmente se transfiere como valor de filtro. A menudo, el salto lleva de
los data marts con arquitectura a la capa EDW principal (EDW = Enterprise Data
Warehouse).

El filtrado de un valor y la agregación de un desglose a una característica libre es más flexible

porque no se especifica la vía de desglose.
Dentro de una jerarquía y dentro de la interfaz informe-informe, la ruta de desglose está
predefinida.
Con la asignación emisor-receptor de la transacción RSBBS se realizan las parametrizaciones
necesarias, por ejemplo, para conectar un query BW a la interfase informe-informe (RRI) en
Analysis for Office. Puede asignar informes receptores a un informe emisor, es decir, una
consulta en BW, dentro de BW, así como a otro sistema SAP.

Cómo crear asignaciones de emisor/receptor

1. En el menú SAP Easy Access del sistema BW, seleccione Menú SAP → Business
Explorer → Consulta → Saltar destino.
Aparece la pantalla Actualización de asignación emisor-receptor.

© Copyright. Reservados todos los derechos. 59

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

2. Seleccione una de las dos etiquetas e introduzca los datos necesarios.

3. En la ficha Consulta, introduzca el nombre técnico de la consulta emisora o seleccione una

consulta mediante la ayuda para entradas.
(Si desea asignar el mismo destino de salto a todos los queries para un InfoSitio,
introduzca el nombre técnico del InfoSitio necesario en la etiqueta InfoSitio o selecciónelo
mediante la ayuda para entradas.)

4. Seleccione Crear.
Accederá a la ventana de diálogo Actualizar asignación emisor-receptor.

5. Tipo de informe inferior, seleccione un receptor. Tiene las siguientes opciones:

● Consulta BW (otra consulta, como en el ejemplo anterior)

● Informe de BW Crystal

● Query InfoSet (consultas en InfoSets clásicos)

● Transacción

● Informe ABAP/4

● Dirección web

6. Seleccione un sistema destino. Tiene las siguientes opciones:

● Local: El destino de salto se encuentra dentro del sistema BW.

● Sistema fuente: el destino de salto está fuera del sistema BW.

- Un sistema fuente como sistema de destino:

Especifique el nombre del sistema fuente. También puede seleccionar el sistema
fuente mediante la ayuda para entradas.

- Todos los sistemas fuente como sistemas de destino:

Seleccione Todos los sistemas fuente. Especifique el sistema fuente en el que desea
seleccionar primero el informe necesario

7. En el campo Informe, introduzca una descripción para el informe receptor. Una vez
guardada la entrada, esta descripción se visualiza como Título del informe.

8. Seleccione Copiar. Accederá a la pantalla Actualización de asignación emisor-receptor.

9. Guarde las entradas.

10. Para casos especiales, aún puede actualizar los detalles de asignación.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Comprender las ventajas y características del modelado de SAP BW/4HANA

60 © Copyright. Reservados todos los derechos.

 Capítulo 3
Lección 4
Comparación del enfoque de SAP BW/4HANA,
el enfoque de SAP HANA y las estrategias
mixtas

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Compare el enfoque de SAP BW/4HANA, el enfoque de SAP HANA y las estrategias
mixtas

Comparar SAP HANA y SAP BW/4HANA Enfoque

Figura 46: Escenario empresarial: Ventajas y problemas del modelado de SAP HANA

Su empresa, ITelO, ha instalado una aplicación de almacén de datos de SAP BW/4HANA.

Desea comprender las ventajas de una filosofía de modelado centrada en SAP BW/4HANA,
una filosofía de modelado centrada en SAP HANA y un escenario mixto.

© Copyright. Reservados todos los derechos. 61

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Figura 47: Comparación de SAP HANA y SAP BW/4HANA Focus

Con SAP BW/4HANA, tiene la opción de crear modelos de SAP HANA o modelos de SAP BW/
4HANA. Si puede ceñirse a un tipo de modelo, es más fácil comprender el modelo y puede
ahorrar costes de formación y soporte. Por otro lado, cuando se enfrenta a una amplia gama
de requisitos, puede aprovechar la implementación de lo mejor de ambos mundos. Sin
embargo, recomendamos encarecidamente seleccionar la filosofía de modelado como el
enfoque de modelado: si se deben implementar nuevos requisitos, primero verifique si las
características del área de enfoque son suficientes. Por ejemplo, si SAP HANA es su enfoque
de modelo y se requiere un nuevo cálculo, verifique si esto se puede realizar dentro de una
vista de SAP HANA.
Incluso si SAP HANA es su enfoque de modelado, los objetos de SAP BW/4HANA se pueden
utilizar como suplemento. Puede acceder a las tablas de base de datos con valores que se
han generado en SAP BW/4HANA y realizar un cálculo en una vista de SAP HANA. El
resultado de una vista de SAP HANA se puede poner a disposición en SAP BW/4HANA
utilizando un proveedor compuesto o consumiendo directamente en las herramientas de
reporting de SAP BI.

Enfoque de modelo de SAP HANA

Utilice el enfoque de modelo de SAP HANA para los siguientes destinos:
● Procesamiento rápido de datos a pedido
Cuando utiliza vistas en lugar de almacenar resultados, los resultados de la consulta se
calculan solo si es necesario y según los valores más recientes. A continuación, las
fórmulas que rara vez se ejecutan solo deben evaluarse en los últimos registros de datos
seleccionados en un informe. La conversión de moneda y unidad se procesa con el factor
de conversión actual.
● Aplicaciones analíticas
Cree sus modelos analíticos en SAP HANA como base para las nuevas aplicaciones
analíticas enviadas por SAP para SAP Business Suite powered by SAP HANA, o en
aplicaciones creadas por los clientes.

62 © Copyright. Reservados todos los derechos.

 Lección: Comparación del enfoque de SAP BW/4HANA, el enfoque de SAP HANA y las estrategias mixtas

● Modelos flexibles basados en SQL

Si se utiliza para generar nuevos valores mediante sentencias SQL, continúe creando
vistas y procedimientos con toda la potencia del script SQL. Puede ir más allá de las
técnicas estándar de SAP BW/4HANA, incluso sin conocimientos de ABAP.
● Contenido de SAP HANA
Si desea utilizar modelos de SAP HANA existentes, puede descargar y activar modelos
existentes de SAP HANA Live basados en tablas estándar de SAP ECC y ampliarlos en sus
vistas de cálculo. Cuando se utiliza SAP S/4HANA, un conjunto de modelos predefinido
similar está disponible como vistas de Core Data Services (CDS).
● Agregación en tablas existentes
Si desea habilitar la agregación de resultados en cualquier nivel de granularidad, puede
almacenar los valores en el nivel más detallado sin redundancia y dejar que SAP HANA
calcule los valores totales en la memoria. Esto se denomina modelado ligero y consumo.
Puede acceder al resultado sin herramientas intermedias basadas en estándares abiertos
(SQL, MDX, ODATA).

SAP HANA y BW/4HANA

Los siguientes objetivos se pueden alcanzar mediante un enfoque de modelo o un enfoque de
modelo:
● Acceder a diferentes fuentes
Para armonizar datos de entornos heterogéneos, implemente diferentes formas de
transformación en función del sistema fuente. SAP BW/4HANA se diseñó específicamente
para la integración, armonización y consistencia en todos los sistemas de los sistemas
empresariales, incluidos los datos de terceros.
● Generación de informes operativos en tiempo real
Si necesita información inmediata sobre los detalles, inicie su análisis en tiempo real
directamente sobre los datos transaccionales originales sin latencia. Existen opciones
para el acceso remoto en SAP BW/4HANA, pero SAP HANA está diseñado
específicamente para este destino.

Enfoque de modelo de SAP BW/4HANA

Se recomienda el enfoque del modelo de SAP BW/4HANA para los siguientes destinos:
● Planificación
Utilice la planificación integrada de SAP BW/4HANA para permitir a los usuarios
empresariales introducir manualmente valores plan y utilizar modelos estándar para
distribuir valores plan en diferentes niveles de agregación o fracciones de datos.
Proporciona funciones de distribución para desglosar los valores plan de alto nivel a los de
nivel inferior. En SAP BW/4HANA, puede definir niveles de agregación para valores plan y
combinarlos con valores reales cargados. Puede introducir manualmente nuevos valores
en un informe que muestre los valores reales. SAP BW/4HANA está diseñado
específicamente para este destino.
● Informes estratégicos y tácticos en un almacén de datos empresariales
Si desea presentar una tendencia histórica para dar soporte a decisiones estratégicas o
tácticas, recopile instantáneas diarias o mensuales, enriqueciéndolas y acumularlas como
datos de resumen. Los aDSO en SAP BW/4HANA están diseñados para la persistencia de

© Copyright. Reservados todos los derechos. 63

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

datos históricos, series de tiempo largo, incluida la gestión del ciclo de vida de los datos
(prioridades de almacenamiento, almacenamiento nearline, archivo).
● Valores estables
Si la base de valor para la gestión de informes debe ser reproducible, defina el
almacenamiento en toda la empresa de los valores correctos (punto único de verdad).
● Cargar instantáneas y datos delta de forma periódica
BW/4HANA tiene objetos como aDSO que admiten escenarios delta y de instantánea,
técnicas de automatización como cadenas de procesos y buenas funciones de
supervisión, especialmente para, entre otras, las fuentes de SAP.
● Informes de datos maestros
Cree consultas e informes en InfoSitios de datos maestros de SAP BW/4HANA cuando
necesite proporcionar un resumen de los datos maestros disponibles, incluidos los
cambios históricos. En SAP BW/4HANA, se pueden crear y almacenar jerarquías. Para
una jerarquía, se pueden mantener diferentes versiones disponibles.
● Escenarios complejos y de mejora de la calidad de los datos
SAP BW/4HANA permite aplicar una lógica compleja. Esto significa que puede armonizar
datos maestros de diferentes sistemas, verificar la integridad referencial, omitir valores
duplicados, generar valores delta en caso de modificaciones y definir sofisticados
indicadores de rendimiento clave (KPI). Con SAP BW/4HANA, defina la gestión de stocks,
que distingue los valores iniciales, la entrada y la salida.
● Reporte de un conjunto armonizado de datos
BW/4HANA proporciona capacidades de transformación para la armonización durante los
procesos de carga de datos. Los resultados armonizados se pueden almacenar y
proporcionar para la gestión de informes mediante el InfoSitio BW/4HANA. Además,
existen técnicas de armonización que se aplican durante la generación de informes, como
la conversión de moneda.
● Uso del contenido de SAP BI
Utilice los modelos estándar en SAP BW/4HANA para la tabla SAP ECC estándar. Este
contenido configurado se denomina contenido de BI y los clientes pueden ampliarlo.

En general, si ya ha invertido en vistas SAP HANA o en un modelo de datos SAP BW/4HANA,

con SAP BW/4HANA puede seguir utilizando la inversión existente. Defina su enfoque de
modelo basado en el sistema con un mayor grado de desarrollo.

64 © Copyright. Reservados todos los derechos.

 Lección: Comparación del enfoque de SAP BW/4HANA, el enfoque de SAP HANA y las estrategias mixtas

Figura 48: Decisión de modelado para BW/4HANA: Elegir un enfoque de modelado

Al integrar diferentes fuentes, se deben realizar las siguientes tareas:

1. Armonice los datos maestros en todos los sistemas de origen.

Por ejemplo, el mismo producto podría tener diferentes ID que deben asignarse o la
asignación del ID de categoría es diferente.

2. Integración de datos maestros y datos de movimiento.

Por ejemplo, añadir información de categoría a los datos de ventas.

En principio, la integración de datos de diferentes tablas o fuentes se puede modelar de tres

maneras diferentes:

1. Utilizar vistas de bases de datos o módulos de funciones

Cuando un sistema fuente ya contiene todos los datos necesarios para generar el
resultado deseado, defina vistas de base de datos o módulos de funciones en el sistema
fuente. A continuación, defina fuentes de datos genéricas para la extracción a SAP BW/
4HANA.
Utilice la transacción SE11 para generar vistas de base de datos y añadir valores que
faltan de otra tabla.
Para transformaciones complejas, utilice módulos de funciones en lugar de vistas de base
de datos simples y benefíciese de toda la gama de características ABAP. Los valores
originales se recopilan durante la extracción.
Si la ejecución de un join o módulo de funciones ralentiza el proceso de extracción, ejecute
un programa en el sistema fuente para rellenar una tabla nueva en el sistema fuente. A
continuación, lea solo de este conjunto de valores más pequeño durante la extracción. Si
este es su área principal de modelado, utilice el sistema fuente como foco de modelado.

© Copyright. Reservados todos los derechos. 65

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Los modelos de SAP BW/4HANA se pueden mantener simples y los datos se pueden
verificar en el sistema fuente. Esto significa que el sistema fuente es responsable de
proporcionar datos consistentes.

2. Crear vistas de cálculo

Al armonizar datos entre sistemas, los datos deben recopilarse en un sistema. Si los
valores de diferentes fuentes se pueden ensamblar en la misma plataforma SAP HANA en
el nivel de base de datos mediante SLT o acceso a datos inteligentes, los modelos se
pueden crear en SAP HANA.
Cree vistas CDS para calcular el resultado deseado siempre que sea necesario. Los
valores están disponibles inmediatamente. Esta vista se puede utilizar directamente en
informes o como base para la extracción a SAP BW/4HANA. En este caso, SAP HANA es
el foco de modelado.
La generación de informes en tiempo real está disponible y la integración de datos es
rápida. No es necesario almacenar más resultados si el cálculo se realiza sobre la marcha.
Necesita SQL para casos complejos y la armonización con datos históricos debe
implementarse manualmente.

3. Crear InfoObjetos e InfoSitios

Utilice SAP BW/4HANA como enfoque de modelado en las siguientes circunstancias:

● Cuando no todos los valores se cargan en SAP HANA

● Si desea utilizar ABAP para la integración

● Cuando desea tomar instantáneas de los datos de origen en momentos exactos

● Cuando quiera mantener un historial

Utilice InfoObjetos para almacenar datos maestros dependientes del tiempo.

Utilice aDSO como almacenamiento persistente para instantáneas y para generar datos
delta después de las modificaciones.
Este es el enfoque de este curso de formación.
Mientras no se utilice ABAP, los valores de transformación se procesan en la base de
datos de SAP HANA. ABAP se puede utilizar para casos especiales. Existen excelentes
opciones de supervisión y programación.
Debe esperar a que se lleven a cabo los mecanismos de carga antes de poder evaluar
valores nuevos o modificados.

Nota:
SAP BW/4HANA proporciona excelentes opciones para programar la carga de
datos periódica. Los mecanismos de carga se tratan en el curso de formación
BW/4HANA350H.

66 © Copyright. Reservados todos los derechos.

 Lección: Comparación del enfoque de SAP BW/4HANA, el enfoque de SAP HANA y las estrategias mixtas

Figura 49: Eclipse: Una herramienta front-end para un enfoque de modelado diferente

Eclipse es un entorno de desarrollo integrado (IDE) de código abierto y se puede utilizar para
combinar modelos de SAP HANA y SAP BW/4HANA. Contiene un área de trabajo base y un
sistema de plug-in ampliable para personalizar el entorno.
Eclipse se utiliza principalmente para desarrollar aplicaciones Java, pero también se puede
utilizar para desarrollar aplicaciones en otros lenguajes de programación (incluyendo ABAP
mediante el uso de plug-ins).
SAP utiliza estos plug-ins para mejorar Eclipse con herramientas para admitir modeladores
de metadatos de SAP BW/4HANA en entornos BI complejos. SAP admite la gestión y el
mantenimiento de objetos de metadatos de SAP BW/4HANA ofreciendo herramientas de
modelado SAP BW/4HANA flexibles, eficientes y de última generación (BW/4HANAMT).
Estas herramientas se utilizan para definir o redefinir InfoObjetos, vistas Open ODS, aDSO y
CompositeProviders. Las herramientas se integran con las herramientas de desarrollo ABAP
disponibles en SAP HANA Studio. También se integran con el modelado de SAP HANA y el
consumo de elementos de SAP HANA en objetos de metadatos de SAP BW/4HANA.
Una perspectiva de Eclipse es una disposición predefinida de vistas Eclipse (ventanas). La
perspectiva de Eclipse a utilizar depende del enfoque de modelado.

1. Para el modelado en el sistema fuente, utilice la perspectiva de desarrollo ABAP. Cree un

enlace al sistema ABAP como proyecto ABAP.

2. Para el modelado en SAP HANA, utilice la perspectiva SAP HANA Modeler. Crear vistas de
cálculo.

3. Para el modelado en SAP BW/4HANA, utilice la perspectiva de modelado de SAP, que

está diseñada para BW/4HANAMT. Crear InfoSitios.

© Copyright. Reservados todos los derechos. 67

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Figura 50: Entorno de formación: Herramientas front end y conexiones al sistema

En nuestra infraestructura de formación, existen diferentes herramientas de front end para el

consumo de informes.
SAP Business One Analysis Edition for MS Excel es una herramienta basada en Excel para el
análisis flexible de autoservicio.
Otras herramientas como DesignStudio/Lumira están disponibles mediante la plataforma
SAP BI (anteriormente conocida como SAP Business One Enterprise Server).
Para consumir datos de áreas de trabajo BW, se puede utilizar BW Workspace Query
Designer o SAP NetWeaver Business Client.
Las herramientas basadas en Eclipse para modelado y gestión de datos son SAP HANA
Studio con la perspectiva de SAP HANA Modeler, la herramienta de modelado BW (BWMT) en
la perspectiva de modelado BW y la perspectiva ABAP para acceder a otros sistemas ABAP,
especialmente el sistema SAP S/4HANA T41.
Establezca conexiones desde el front end de Eclipse, el sistema back end con el sistema SAP
BW/4HANA CIA (cliente 003), con el sistema SAP S/4HANA T41 (cliente 400) y la
plataforma SAP HANA.
SAP BW/4HANA y la plataforma SAP HANA están instalados en el mismo host, wdflbmt7211.
wdf.sap.corp, en diferentes instancias. Esto acelera la comunicación.

68 © Copyright. Reservados todos los derechos.

 Lección: Comparación del enfoque de SAP BW/4HANA, el enfoque de SAP HANA y las estrategias mixtas

Figura 51: Ejemplo: enfoque de modelado BW/4HANA

Una ventaja de un flujo de datos de SAP BW/4HANA es que los datos se pueden transformar
en varios pasos y se pueden guardar los resultados intermedios.

Homogeneización de datos
Los datos de diferentes fuentes se pueden homogeneizar. El resultado se almacenaría en un
aDSO. La homogeneización puede implicar varias de las siguientes tareas:
● Modificar el formato de un formato interno a un formato BW/4HANA
● Asignación de valores de números de cliente específicos de fuente a números de cliente
globales válidos en todo BW/4HANA
● Añadir una moneda o unidad que no estaba disponible en el sistema fuente
● Añadir el sistema fuente

La calidad de los datos se puede mejorar de las siguientes maneras:

● Agregando la fecha actual
● Omitir valores que están fuera del alcance
● Verificación de la integridad referencial

En la imagen, Ejemplo: Enfoque de modelado BW/4HANA, los valores de los datos brutos se
almacenan en un formato estándar. El contenido del campo Cliente se modifica de acuerdo
con un programa de asignación de valores. El campo Ingresos numéricos está asignado a un
ratio con una moneda fija.
En un paso posterior, en otra transformación o una consulta BW, obtenga una perspectiva
nueva que sea interesante para los usuarios empresariales, como el número de clientes
diferentes y el valor fiscal. Como puede ver, se pueden calcular valores totalmente nuevos.

© Copyright. Reservados todos los derechos. 69

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Figura 52: Decisiones de modelado para un modelo centrado en SAP BW/4HANA: ¿Qué niveles y
combinaciones?

Utilice el modelado basado en SAP BW/4HANA para la integración, armonización e

historización en diferentes sistemas.
Los InfoSitios de BW/4HANA son módulos de la arquitectura BW/4HANA. Permiten la
integración en niveles basados en campos y en objetos info.
Si el modelado basado en campos es suficiente, puede crear enlaces y asociaciones entre
vistas Open ODS en BW/4HANA.
Con las vistas Open ODS, puede crear vistas complejas entre tablas de base de datos. No es
necesario iniciar sesión en la base de datos, se puede crear el modelo completo desde BW/
4HANA con un usuario de BW/4HANA.
Utilice InfoObjetos cuando necesite una definición estándar de atributos y textos,
propiedades de visualización y un conjunto estandarizado de datos maestros.
SAP recomienda utilizar objetos de SAP BW/4HANA con almacenamiento de datos
persistentes, especialmente InfoObjetos y aDSOs, para la integración, armonización e
historización. Mantenga los modelos lo más simples posible. Utilice el modelado basado en
campos sin InfoObjetos siempre que sea suficiente.
Cree siempre un CompositeProvider sobre un aDSO que proporcione datos del reporting.
Utilice CompositeProvider para asociar InfoObjetos o datos maestros virtuales (vistas Open
ODS). Cree consultas siempre en la parte superior de un CompositeProvider. Si es necesario
modificar el modelo de datos, puede intercambiar el aDSO con el proveedor compuesto con
poco o ningún efecto en el query BW.
En el modelado central de SAP HANA, los modelos se pueden crear con vistas nativas de SAP
HANA, vistas Open ODS, proveedores compuestos y consultas. Utilice este modelado basado
en SAP HANA, si el proyecto se centra en la integración en tiempo real, principalmente desde
un sistema SAP HANA, y en funciones específicas de SAP HANA, especialmente la
clasificación o los joins. Incluso las transformaciones complejas son posibles utilizando
procedimientos dentro de SAP HANA.

70 © Copyright. Reservados todos los derechos.

 Lección: Comparación del enfoque de SAP BW/4HANA, el enfoque de SAP HANA y las estrategias mixtas

Si no se requiere ningún historial de datos, tales modelos de datos virtuales pueden sustituir
el almacenamiento redundante físico. Las transformaciones, como cálculos, unificaciones y
unificaciones, se basan en diferentes fuentes que se pueden modelar en vistas nativas de SAP
HANA. El resultado se puede poner a disposición de los usuarios de BW mediante la vista
Open ODS y los proveedores compuestos. En ambos niveles, los campos se pueden
identificar con InfoObjetos y se pueden asociar vistas Open ODS de datos maestros.

Figura 53: Decisiones de modelado para el modelado centrado en SAP HANA: ¿Qué niveles y combinaciones?

Con el modelado basado en SAP HANA, el enfoque está en los modelos de datos virtuales en
el sistema SAP HANA. En un modelo de datos virtual de este tipo, no tiene lugar ninguna
carga física. Si los datos se cargan físicamente, se transportarán entre las tablas de la base de
datos mediante funciones que se tratan en cursos especiales de SAP HANA: SLT, integración
de datos inteligentes, modelos de gráficos de flujo y procedimientos almacenados.
Se pueden mezclar dos conceptos de modelado, si corresponde:
● El concepto de join en estrella (lado izquierdo de la figura) se puede utilizar si no se
necesita una transformación compleja. A continuación, los datos maestros y los datos de
texto se almacenan en vistas de SAP HANA de tipo de dimensión especial. Se unen desde
una vista de la infraestructura de datos central con ratios. En este concepto, algunas
dimensiones se pueden reutilizar en diferentes vistas de hechos. Se presentarán más
detalles en la unidad Implementación de vistas nativas de SAP HANA.
● Se puede utilizar un modelo de varias capas (a la derecha) si los datos se pueden filtrar,
calcular, unir y agregar en varios pasos posteriores. Si los hechos y los datos maestros se
encuentran en la misma tabla o vista de base de datos, toda la vista se puede extraer y
ampliar en una vista.

Debes decidir qué concepto te das cuenta. Para el concepto de varios niveles, decida qué
capas necesita. Finalmente, decida si el usuario empresarial tiene permiso para acceder a las
vistas de forma nativa o si las consultas se basan necesariamente en CompositeProviders.

El modelado de un escenario con armonización e integración de datos sin almacenamiento

adicional se denomina DataWarehouse virtual.

© Copyright. Reservados todos los derechos. 71

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Figura 54: Decisión de modelado para SAP BW/4HANA: Combinación de vistas de SAP HANA y capas de BW/
4HANA

En el enfoque de modelado centrado en SAP BW/4HANA, los datos se transforman mediante

transformaciones de SAP BW/4HANA. Si es necesaria la programación, se puede
implementar una rutina (ABAP o AMDP) como primer, intermedio o último paso de una
transformación de SAP BW/4HANA.
En un enfoque de modelado centrado en SAP HANA, los cálculos simples y las
transformaciones se pueden implementar como columnas calculadas en vistas de cálculo de
SAP HANA o vistas CDS. Para transformaciones más complejas, el script SQL de lenguaje se
puede utilizar dentro de las funciones y procedimientos de tabla. Con el script SQL, puede
combinar consultas SQL, funciones SAP HANA almacenadas existentes y procedimientos
SAP HANA almacenados.
Las funciones de tabla se pueden integrar en las vistas de cálculo de SAP HANA. Los
procedimientos SAP HANA almacenados se pueden utilizar en funciones de tabla o
directamente en transformaciones BW/4HANA.

Dos escenarios de integración

Imaginemos una tarea empresarial que consiste en cargas regulares de instantáneas de
datos de volumen de ventas de fuentes a las que se puede acceder desde SAP HANA y BW/
4HANA. La fuente proporciona datos transaccionales con diferentes monedas y tablas de
datos maestros separadas.
Para las ventas T41 y las ventas de la CIA, se necesitan informes estratégicos basados en el
historial de valores totales en euros y los datos maestros de producto deben integrarse en los
datos transaccionales. ¿Cuál es el mejor escenario de integración?
Supongamos que, para el negocio de ventas de la CIA, es esencial una visión inmediata de los
cambios. Por este motivo, los valores de ventas de la CIA se combinan con los datos
maestros de producto y las monedas se convierten a euros dentro de SAP HANA. Esto ofrece
la posibilidad de visualizar valores actualizados en los clientes BI.
La vista SAP HANA está disponible directamente, pero se puede poner a disposición de un
sistema SAP BW/4HANA utilizando una vista Open ODS o un proveedor compuesto. Desde
allí, los extractos completos se pueden cargar en un aDSO para datos históricos. Un
proveedor compuesto basado en este aDSO es la interfaz de usuario final para presentar los
valores históricos.

72 © Copyright. Reservados todos los derechos.

 Lección: Comparación del enfoque de SAP BW/4HANA, el enfoque de SAP HANA y las estrategias mixtas

Supongamos que, para los datos de ventas T41, es muy importante poder realizar un
seguimiento de todas las transformaciones. A continuación, se recomienda cargar datos
maestros y transaccionales en SAP BW/4HANA mediante fuentes de datos. Un primer aDSO
graba todos los valores originales. Los textos y atributos de producto se cargan en las tablas
de datos maestros de características. Un segundo aDSO debería contener valores
armonizados. En una transformación entre los dos objetos DataStore avanzados, se añaden
atributos de producto y la conversión de moneda se define en SAP BW/4HANA.
En ambos casos, el cálculo de conversión real se transfiere a la base de datos de SAP HANA.
Puede seleccionar uno de los dos principios de modelo. La ventaja del principio centrado en
BW/4HANA (escenario de ventas T41) es la posibilidad de controlar el momento del cálculo.
En el principio centrado en SAP HANA (escenario de ventas CIA), no se almacenan resultados
intermedios. Esto ahorra dinero y espacio en disco, pero es más difícil verificar o recalcular
los resultados. Además, se pierden las versiones históricas de los datos maestros. Como ves,
ambos conceptos tienen ventajas e inconvenientes.

Figura 55: Escenarios híbridos (mixtos): generar y consumir vistas de SAP HANA

Puede crear escenarios en los que los datos, modelados en el sistema BW/4HANA, se
fusionan con datos modelados en SAP HANA con herramientas de SAP HANA.
El sistema SAP BW/4HANA se ejecuta en SAP HANA y los datos se almacenan en un
esquema especial conocido como el esquema gestionado por BW/4HANA. En otros
esquemas de SAP HANA, los datos se pueden almacenar en tablas SAP HANA o en vistas de
modelado. Puede hacer que los datos estén disponibles desde cualquier esquema de base de
datos de SAP HANA en SAP BW/4HANA. También puede hacer que los datos de SAP BW/
4HANA (datos del esquema gestionado por BW/4HANA en la base de datos de SAP HANA)
estén disponibles en un esquema de SAP HANA diferente. Puede utilizar métodos de acceso
virtual y métodos de replicación de datos. La siguiente lista muestra las diferentes opciones y
proporciona enlaces a más información.
● Al activar objetos BW/4HANA, puede generar vistas SAP HANA con las mismas
estructuras.

© Copyright. Reservados todos los derechos. 73

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Esto le permite crear escenarios en los que los datos, modelados en el sistema BW/
4HANA, se fusionan con datos modelados en SAP HANA con herramientas de SAP HANA
(escenarios mixtos).
Se admiten los siguientes objetos: InfoObjeto, aDSO, CompositeProvider,
CompositeProviders locales en el área de trabajo BW y queries BW.
● Cuando se generan vistas SAP HANA, no se mueven datos BW/4HANA. Las vistas de SAP
HANA generadas consumen datos directamente de las tablas gestionadas por BW/
4HANA. Esto también proporciona una interfaz clara entre el esquema gestionado por
BW/4HANA y un área fuera del esquema BW/4HANA. Esta interfaz aclara dónde terminan
los servicios en el sistema BW/4HANA y dónde comienzan las mejoras o mejoras
manuales a través de herramientas de terceros. No modifique manualmente las vistas SAP
HANA generadas. El sistema puede sobrescribir en cualquier momento las vistas de SAP
HANA generadas por BW/4HANA, lo que significa que se perderían las modificaciones
manuales.
La generación de vistas SAP HANA desde el sistema BW/4HANA le permite generar vistas
SAP HANA sin utilizar el modelador SAP HANA. De este modo, puede acceder a los datos
de BW/4HANA a través de front ends SQL. Todas las aplicaciones que pueden leer vistas
de SAP HANA pueden procesar los datos, especialmente SAP BusinessObjects Analysis,
edición para Microsoft Office, SAP BusinessObjects Web Intelligence, SAP
BusinessObjects Explorer, SAP Lumira y clientes BI de proveedores externos.
Puede crear más vistas SAP HANA en la parte superior de estas vistas generadas. A
continuación, se almacenarán en otro paquete de contenido.
● Cuando se ejecuta una consulta en la vista SAP HANA, los datos se solicitan directamente
desde SAP HANA, sin que se aborde el sistema BW/4HANA.
Estas vistas de SAP HANA forman parte del ciclo de vida del InfoSitio de BW/4HANA. Se
transportan con los objetos BW/4HANA correspondientes. El sistema de destino debe
tener una base de datos SAP HANA. Si no lo hace, la propiedad de que el objeto tiene una
vista SAP HANA se perderá.
● Cuando se activa un objeto BW/4HANA con la vista SAP HANA, también se activan todas
las vistas SAP HANA dependientes. Si se produce un error con una vista de SAP HANA que
ha creado, solo se producirá un mensaje de advertencia y el objeto BW/4HANA se
activará.

Recomendación:
Para encontrar una buena solución, intente modelar un tema principalmente en un enfoque
de modelado. Sin embargo, si algunas funciones no se pueden establecer dentro de este
enfoque de modelado, tenga en cuenta un escenario híbrido.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Compare el enfoque de SAP BW/4HANA, el enfoque de SAP HANA y las estrategias
mixtas

74 © Copyright. Reservados todos los derechos.

 Capítulo 3
Lección 5
Aspectos clave de la analítica integrada de S/
4HANA

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Comprender la analítica integrada de S/4HANA

Resumen de la analítica integrada de SAP S/4HANA

Figura 56: Evolución de la solución SAP ERP

SAP S/4HANA es la suite de negocios de próxima generación de SAP y es la mayor

actualización de SAP a su estrategia y plataforma de SAP ERP en más de dos décadas. Trae
innovación nueva a los clientes, similar a la transición de SAP R/2 a SAP R/3. Es un nuevo
producto, completamente creado en la plataforma SAP HANA y diseñado con la experiencia
de usuario de SAP Fiori. El lanzamiento del producto se produjo en febrero de 2015 y es la
solución estratégica de SAP y, por lo tanto, tiene su soporte comprometido al menos hasta
finales de 2040.

© Copyright. Reservados todos los derechos. 75

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Figura 57: Evolución de SAP HANA de la base de datos pura a SAP BW/4HANA

SAP S/4HANA es el resultado de la innovación continua en memoria de toda la cartera de

productos de SAP basada en la plataforma SAP HANA.

Figura 58: Evolución de SAP ERP a SAP S/4HANA

SAP comenzó reescribiendo Business Suite desde cero y comenzó con el módulo para
Finanzas, que originalmente estaba disponible como componente complementario para
Business Suite powered by SAP HANA, también conocido como SAP S/4HANA Finance o
Simple Finance. El modelo de datos fue redesarrollado y el código de aplicación
completamente reescrito en este nuevo modelo de datos simplificado. Los clientes pueden
convertir sus aplicaciones existentes de SAP ERP Finance a Simple Finance y seguir
utilizando las aplicaciones ERP existentes, como ventas, aprovisionamiento y gestión de
stocks. SAP S/4HANA Finance y las aplicaciones ERP existentes se han integrado
completamente, de modo que todas las contabilizaciones financieras realizadas a partir de
las aplicaciones ERP existentes también están visibles inmediatamente en el nuevo módulo
Finanzas.
Como siguiente paso, SAP reescribió el núcleo ERP restante con nuevos modelos de datos y
código de aplicación, lo que dio como resultado SAP S/4HANA tal y como lo conocemos hoy.

76 © Copyright. Reservados todos los derechos.

 Lección: Aspectos clave de la analítica integrada de S/4HANA

Figura 59: Resumen de SAP S/4HANA

SAP S/4HANA es una oferta de Business Suite que se crea en la plataforma de computación
in-memory proporcionada por SAP HANA. Anteriormente, los productos de SAP se
diseñaban para ejecutarse en diferentes bases de datos, incluidas las de Oracle, Microsoft e
IBM. La plataforma SAP HANA está disponible desde 2011, y las aplicaciones SAP como SAP
BW y SAP Business Suite, incluido SAP ERP, han podido ejecutarse en la base de datos de
SAP HANA, así como en otras bases de datos en el pasado.
Sin embargo, SAP S/4HANA solo se ejecuta en la base de datos de SAP HANA y, por lo tanto,
se embala como un producto. El objetivo de la oferta es cubrir todos los procesos críticos
para la misión de una empresa. Integra funciones de líneas de negocio, así como soluciones
sectoriales. También vuelve a integrar partes de productos de SAP Business Suite como SAP
Supplier Relationship Management o SAP Supply Chain Management.
SAP S/4HANA proporciona una gran cantidad de innovaciones. Sin embargo, en el contexto
de esta formación de SAP BW/4HANA, solo nos centraremos en las siguientes dos áreas de
simplificación de modelo de datos 1 y 2. capacidades analíticas integradas:

1. Modelo de datos simplificado: el modelo de datos original se ha rediseñado y sustituido por

uno simplificado adaptado a SAP HANA. Se han eliminado las tablas agregadas y se ha
minimizado la redundancia.

© Copyright. Reservados todos los derechos. 77

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Figura 60: Modelo de datos simplificado - Modelo de datos original de SAP Business Suite

Figura 61: Modelo de datos simplificado - Nuevo modelo de datos de SAP S/4HANA

78 © Copyright. Reservados todos los derechos.

 Lección: Aspectos clave de la analítica integrada de S/4HANA

Figura 62: Simplificación de la lógica de aplicación de SAP S/4HANA

Un ejemplo típico está disponible en SAP S/4HANA Finance: en el pasado, los documentos
financieros y los documentos de controlling se separaban en diferentes tablas, y había un
gran grado de solapamiento y redundancia entre ellos. Además, se necesitaban tablas
agregadas e índices adicionales para proporcionar interfaces adecuadas para las aplicaciones
ERP.
Por el contrario, SAP S/4HANA gestiona todos los documentos financieros en una tabla
central llamada ACDOCA (Partidas individuales de entrada en diario universal). Solo se realiza
una contabilización individual en esta tabla central que contiene toda la información necesaria
para gestionar la contabilidad legal externa y la contabilidad de gestión interna. Las vistas de
SAP HANA generan sobre la marcha todas las vistas necesarias sobre estos datos y, como
resultado, todo el código de aplicación es menos complejo.
2. Analíticas integradas: SAP S/4HANA brinda informes operativos listos para usar, basados
en un modelo de datos virtual (VDM) proporcionado por SAP Core Data Services.

© Copyright. Reservados todos los derechos. 79

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Figura 63: Ejemplo empresarial 1: Ejecutivo de cuenta: análisis integrados que admiten pedidos de cliente SD en
SAP S/4HANA

El ejemplo anterior describe cómo las transacciones ERP (aquí pedidos de cliente SD) y los
análisis integrados funcionan de la mano en SAP S/4HANA. Antes de que el pedido de cliente
se contabilice en la aplicación SAP S/4HANA correspondiente (y no en la aplicación SAP GUI
Tr. VA01 como en el pasado), hay aplicaciones analíticas disponibles para que el gestor de
cuentas responsable verifique el stock actual de los productos solicitados, califique al cliente
en función de los pedidos históricos e identifique las oportunidades de cross-selling/up-
selling relacionadas con este contacto de cliente. Todo esto se puede hacer en un flujo, en un
sistema SAP S/4HANA sin análisis complejos y sin cambiar a otro sistema para realizar este
análisis. Solo después de aprovechar estas opciones analíticas integradas, el pedido de
cliente se completa y finalmente se contabiliza en el sistema para su procesamiento
posterior.

Figura 64: Ejemplo empresarial 2: Director de compras: Análisis integrados que admiten pedidos MM en SAP S/
4HANA

80 © Copyright. Reservados todos los derechos.

 Lección: Aspectos clave de la analítica integrada de S/4HANA

El segundo escenario empresarial describe cómo un director de compras aprovecha la

analítica integrada en SAP S/4HANA. Antes de que el pedido se contabilice en la aplicación
SAP S/4HANA correspondiente (y no en el campo Tipo de ME21N como en el pasado), hay
aplicaciones analíticas disponibles para que el gestor responsable verifique el presupuesto
interno disponible, compare proveedores y verifique su fiabilidad en base a pedidos
históricos. Todo esto se puede hacer en un flujo, en un sistema, en una pantalla. Solo después
de aprovechar estas opciones de análisis integradas, se completa la transacción.

Figura 65: El modelo de datos virtual (VDM) como base para las analíticas integradas

SAP S/4HANA proporciona modelos de datos virtuales (VDM) basados en muchas vistas
relacionadas entre sí. Es un modelo semántico de datos de aplicación SAP, expresado
técnicamente en el idioma de las vistas CDS ABAP. Es estable, ampliable y está disponible
para su reutilización. “Virtual” se refiere al hecho de que el modelo semántico VDM difiere del
modelo persistente tradicional de tablas de base de datos, lo que hace que sea más simple y
fácil de entender. Como se describió anteriormente en esta unidad, el VDM se puede
estructurar aproximadamente en tres capas que proporcionan una arquitectura estable para
el mantenimiento y el consumo.

Figura 66: Modelo de datos virtual (VDM) basado en vistas CDS ABAP

© Copyright. Reservados todos los derechos. 81

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

El VDM de SAP S/4HANA que admite casos de uso de análisis integrados consta de las
mismas tres capas que ya se han introducido:
● Las vistas privadas forman el modelo de baja redundancia directamente en la parte
superior de las tablas físicas de SAP S/4HANA (por ejemplo, SalesOrderHeader,
SalesOrderItem, BusinessPartner, Product, etc.).
● Las vistas de interfaz exponen la interfaz pública y estable para consumidores y
proporcionan semántica empresarial. Se crean seleccionando desde las vistas privadas y
otras vistas de interfaz, y explorando las relaciones entre ellas (por ejemplo, pedidos de
cliente).
● Las vistas de consumo normalmente consumen vistas de interfaz, las amplían con
capacidades analíticas y pueden crear consultas para aplicaciones o usuarios finales, por
ejemplo.

Figura 67: Consumo de contenido analítico integrado mediante BW integrado

SAP S/4HANA Embedded Analytics aprovecha el llamado motor analítico (también conocido
como motor OLAP de BW) para admitir la gestión de informes flexible por parte de los
clientes de SAP Analytics (local o en la nube). Este motor es un componente central del
componente SAP BW integrado, que forma parte de cada sistema SAP S/4HANA.
Proporciona servicios analíticos adicionales, como la agregación de excepciones o el
tratamiento de jerarquías, y otras funciones de gestión de informes y planificación flexibles
(consulte más detalles en el apéndice de esta lección).
OData y el servidor SAP Gateway proporcionan la segunda interfaz principal como base para
las aplicaciones SAP Fiori/UI5.

82 © Copyright. Reservados todos los derechos.

 Lección: Aspectos clave de la analítica integrada de S/4HANA

Figura 68: Ejemplos de consultas CDS disponibles en análisis integrados de SAP S/4HANA

El análisis integrado de SAP S/4HANA consta de un número creciente de vistas CDS. Las
primeras áreas que se cubrieron fueron Finanzas y Controlling, Gestión de materiales
(Inventario, Compras), Planificación de la producción y Comercial. Con cada versión de SAP
S/4HANA, el alcance del VDM está creciendo.

¿SAP S/4HANA Embedded Analytics sustituye a SAP BW/4HANA?

Figura 69: Comparación de las características principales de SAP S/4HANA con SAP BW/4HANA

¿Por qué necesitamos un almacén de datos externo separado como SAP BW/4HANA y cómo
complementa el análisis integrado de SAP S/4HANA? Bueno, sabemos que el análisis en
tiempo real de los datos operativos cuenta con el soporte de SAP S/4HANA y se logra el
objetivo de llevar la generación de informes operativos a los sistemas operativos. Sin
embargo, también sabemos que los datos operativos deben trasladarse a una ubicación
adecuada cuando su valor para las operaciones empresariales online diarias haya disminuido.
En este punto, se requieren soluciones para el archivo de datos. Es preferible que esta
solución proporcione un archivo inteligente y automatizado que se pueda integrar con datos
operativos en tiempo real y también de varias fuentes, por ejemplo, en un entorno compuesto
por varios sistemas SAP y no SAP. Un almacén de datos sofisticado como SAP BW/4HANA
proporciona los servicios correspondientes, incluida una sólida gobernanza de datos. La
planificación empresarial es otro escenario para, ya que requiere que los datos se almacenen
en varios niveles de agregación, y no en el nivel atómico típico de los datos de artículo en

© Copyright. Reservados todos los derechos. 83

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

línea, como prefiere SAP S/4HANA. Además, siempre que sea necesario un reporting
estratégico a largo plazo en niveles agregados, SAP BW/4HANA es la solución.
Es importante tener en cuenta que SAP BW/4HANA se está alejando del enfoque clásico de
adquirir todos los datos y almacenarlos en una persistencia gestionada por sí mismo. SAP
BW/4HANA proporciona nuevas capacidades para diseñar un almacén de datos lógico y
seguir los enfoques de federación de datos. Esto significa que los datos no siempre se
transfieren y almacenan en todos los casos, pero los datos gestionados en fuentes externas
también se pueden consumir de forma virtual.

Figura 70: Cambio de rol de SAP BW/4HANA con el surgimiento de SAP S/4HANA

En la unidad anterior se introdujo la analítica integrada de SAP S/4HANA, que proporciona

informes operativos en SAP S/4HANA. En el pasado, estos escenarios a menudo se
implementaban en SAP BW debido a la falta de capacidades de generación de informes
adecuadas, así como a las limitaciones de rendimiento de los sistemas ERP. Sin embargo, con
la analítica integrada en SAP S/4HANA, el rol de SAP BW (SAP NetWeaver BW o SAP BW/
4HANA) debe reevaluarse para cambiar el enfoque principal a los casos de uso del almacén
de datos empresariales, debido al hecho de que SAP S/4HANA puede proporcionar análisis
para gestionar el negocio diario sin redundancia en tiempo real.

84 © Copyright. Reservados todos los derechos.

 Lección: Aspectos clave de la analítica integrada de S/4HANA

Nota:
Para obtener más detalles, consulte también las siguientes fuentes:
● Blog: "Core Data Services in SAP S/4 HANA https://blogs.sap.com/
2016/09/26/core-data-services-cds-in-sap-s4-hana/"
● Blog: "Getting Started with S/4 HANA Embedded Analytics" https://
blogs.sap.com/2016/05/27/getting-started-with-s4-hana-embedded-
analytics/
● Blog: "S/4HANA Embedded Analytics: From Operational Reporting to Insight-
to-Action" https://blogs.sap.com/2016/01/26/s4hana-embedded-analytics-
from-operational-reporting-to-insight-to-action-sap-teched-lecture-of-the-
week/
● Blog: "Journey of Data: From Tables to Tiles – A sneak peek into the S/4HANA
Embedded Analytics Architecture" https://blogs.sap.com/2016/09/27/
journey-of-datafrom-tables-to-tiles-a-sneak-peek-into-the-s4-hana-
embedded-analytics-architecture/
● Presentación detallada sobre la integración de SAP S/4HANA Embedded
Analytics y SAP BW/4HANA https://archive.sap.com/documents/docs/
DOC-68337.
● Blog: Consulta BW en vista CDS, OData de BW y valor de consulta BW en S/
4HANA https://blogs.sap.com/2018/08/08/bw-query-on-cds-view-odata-
from-bw-and-value-of-bw-query-in-s4hana/
● Nota SAP 2535903: Cómo crear sus consultas CDS personalizadas y
aprovechar las consultas de informes CDS existentes en S/4HANA Cloud y
local 1709 y versiones OP subsiguientes
● Nota SAP 2579584: Recomendaciones para el uso de informes en informes
financieros en S/4HANA
● Wiki de SAP: Informes integrados en vistas CDS ABAP https://
wiki.scn.sap.com/wiki/display/BI/OT-CDS+Embedded+Reporting+on+ABAP
+CDS+views
● Blog: "Data Warehousing Is Not Dead with SAP S/4HANA!" https://
blogs.sap.com/2018/10/24/data-warehousing-is-not-dead-with-sap-
s-4hana/
● Blog: "SAP S/4HANA and SAP BW/4HANA: What to Do Where?" https://
blogs.sap.com/2017/08/15/sap-s4hana-and-sap-bw4hana-what-to-do-
where/
● Blog: ¡El final de SAP Business Warehouse en el contexto de SAP S/4HANA no
está a la vista! https://blogs.sap.com/2016/04/07/the-end-of-sap-business-
warehouse-in-the-context-of-sap-s4hana-is-not-in-sight/

Apéndice: SAP BW integrado

© Copyright. Reservados todos los derechos. 85

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

Figura 71: SAP BW integrado en SAP S/4HANA

Desde SAP NetWeaver 7.0, la tecnología SAP BW se incluye automáticamente dentro de una
instalación de SAP NetWeaver ABAP. Esto era cierto para los sistemas de SAP Business Suite
y sigue siendo el caso de SAP S/4HANA de última generación. El componente SAP BW que
existe dentro de un sistema basado en ABAP de este tipo se denomina BW integrado. Como
se ha explicado en la lección anterior, la analítica integrada de SAP S/4HANA utiliza este
componente para ofrecer un reporting operativo sofisticado. Las vistas CDS de analítica
integrada de SAP S/4HANA se generan como proveedores de datos operativos si se definen
con ciertas anotaciones (por ejemplo,@Analytics.dataCategory: #FACTS, #CUBE ).
Estos pueden servir como InfoSitios para la gestión de informes en el motor analítico a través
de las interfaces BICS/InA para los clientes de SAP Analytics.

Figura 72: Posicionamiento de SAP BW integrado

El objetivo principal de BW integrado en SAP S/4HANA es proporcionar un motor de informes

y planificación. Sin embargo, no se supone que se utilicen otros componentes clave que se
utilizan para casos de uso típicos de Data Warehousing, como adquisición de datos, gestión

86 © Copyright. Reservados todos los derechos.

 Lección: Aspectos clave de la analítica integrada de S/4HANA

de metadatos, autorizaciones de informes, transformación y gestión de datos, aunque estén

disponibles técnicamente.

Nota:

● BW integrado - Página de llegada https://archive.sap.com/documents/

docs/DOC-59751.
● SAP BW integrado forma parte de SAP NetWeaver y sigue este release y plan
de mantenimiento. Solo se realizará una inversión limitada en este
componente después de la versión 7.5 SP04. Tenga en cuenta que SAP BW
integrado no es SAP BW/4HANA. Ambos evolucionan de manera diferente.
● Además, tenga en cuenta que SAP NetWeaver 7.51 o versiones posteriores
solo están pensadas para SAP S/4HANA. Estas versiones admiten escenarios
de "SAP BW integrado", pero no admiten instalaciones de SAP BW
independientes (consulte las notas de SAP 1600929, 2733740, 2524430 y
2372388).
● El contenido BI de SAP BW no se admite en ningún SAP BW integrado,
consulte la nota SAP 2289424 (contenido de SAP S/4HANA y SAP Business
Warehouse)
● Nota SAP 2289865: Pasos de configuración para análisis integrados de SAP
S/4HANA
● Nota SAP 1972819: Configurar SAP BPC optimizado para S/4 HANA Finance
y reporting BW integrado (es decir, Integrated Business Planning for Finance)

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Comprender la analítica integrada de S/4HANA

© Copyright. Reservados todos los derechos. 87

Capítulo 3 : Enfoques de modelado en SAP BW/4HANA

88 © Copyright. Reservados todos los derechos.

 Capítulo 3

Evaluación de la formación

1. ¿Cuáles de las siguientes opciones son mejores prácticas para almacenar datos en un
sistema BW que se ejecuta en SAP HANA?
Seleccione las respuestas correctas.

X A Almacenar la mayor parte de los datos en el disco para recuperarlos cuando sea
necesario (datos de acceso frecuente)

X B Almacenar los datos más relevantes en un almacén de columnas comprimidas en

la memoria (datos activos)

X C Dividir los datos más relevantes por fecha y almacenarlos entre un almacén de
columnas sin comprimir y las tablas almacenadas en el disco (datos de acceso
frecuente)

X D Almacenar todos los datos en almacenes de columnas comprimidas para

maximizar el rendimiento (datos activos)

X E Trasladar datos menos importantes a un sistema de almacenamiento externo

(datos geniales)

2. Existen dos InfoSitios que permiten el acceso virtual con transformaciones.

Unir los elementos de la primera columna con el que corresponda de la segunda columna

InfoSitio Caso de utilización

Proveedor de badios Acceso virtual con una interfaz
de programa
Vista Open ODS
Acceso virtual sin transforma-
ción o con una transformación
de BW

© Copyright. Reservados todos los derechos. 89

Capítulo 3 : Evaluación de la formación

3. Según el enfoque de BW/4HANA, ¿cuál de las siguientes opciones debería tenerse en

cuenta al modelar datos maestros y datos de transacción?
Seleccione las respuestas correctas.

X A Si no es necesario replicar los datos maestros, se podría utilizar una vista Open
ODS para textos y atributos.

X B Si los datos de transacción deben almacenarse, se debe utilizar un objeto

DataStore (aDSO)

X C Para cargar datos de transacción de forma eficiente, se debe utilizar una vista
Open ODS del tipo Facts.

X D Sin carga de datos adicional, combine datos de InfoSitios existentes utilizando un

CompositeProvider.

X E Si los datos maestros deben grabarse de forma persistente, se deben utilizar

características

4. Debe especificar su sistema BW/4HANA como completamente centrado en SAP BW/

4HANA o completamente centrado en SAP HANA.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

5. ¿Qué enfoque de modelado utilizaría para los informes empresariales basados en datos
históricos estables que deben testificarse si es necesario armonizar datos de diferentes
fuentes?
Seleccione la respuesta correcta.

X A Enfoque de SAP BW/4HANA

X B Enfoque de SAP HANA

X C Enfoque de SAP S/4HANA

6. ¿Qué tecnología aprovecha la analítica integrada de SAP S/4HANA?

Seleccione la respuesta correcta.

X A Vistas de cálculo de SAP HANA

X B SAP ABAP Core Data Services

X C SAP BW integrado con InfoCubos en tiempo real

X D SAP HANA Core Data Services

90 © Copyright. Reservados todos los derechos.

 Capítulo 3 : Evaluación de la formación

7. ¿Cuál es el impacto de SAP S/4HANA en un sistema SAP BW existente?

Seleccione las respuestas correctas.

X A Después de la implementación de la analítica integrada de SAP S/4HANA, algunas

aplicaciones en el sistema SAP BW pueden quedar obsoletas.

X B La analítica integrada de SAP S/4HANA asume completamente el rol de los

entornos de SAP BW existentes. Los sistemas SAP BW se pueden inhabilitar.

X C La extracción al sistema SAP BW existente puede cambiar porque no todos los

extractores (fuentes de datos) están disponibles en SAP S/4HANA del mismo modo.

X D La conversión del sistema SAP BW existente a SAP BW/4HANA es una condición

previa para una implementación de SAP S/4HANA.

© Copyright. Reservados todos los derechos. 91

 Capítulo 3

Respuestas a la Evaluación de la formación

1. ¿Cuáles de las siguientes opciones son mejores prácticas para almacenar datos en un
sistema BW que se ejecuta en SAP HANA?
Seleccione las respuestas correctas.

X A Almacenar la mayor parte de los datos en el disco para recuperarlos cuando sea
necesario (datos de acceso frecuente)

X B Almacenar los datos más relevantes en un almacén de columnas comprimidas en

la memoria (datos activos)

X C Dividir los datos más relevantes por fecha y almacenarlos entre un almacén de
columnas sin comprimir y las tablas almacenadas en el disco (datos de acceso
frecuente)

X D Almacenar todos los datos en almacenes de columnas comprimidas para

maximizar el rendimiento (datos activos)

X E Trasladar datos menos importantes a un sistema de almacenamiento externo

(datos geniales)

¡Ha acertado! Existen tres alternativas para almacenar datos utilizando SAP HANA:
almacenar los más relevantes en memoria como datos "calientes"; almacenar datos
masivos en disco en BW como datos "tibios" y dejar los datos menos importantes en un
sistema externo como datos "frescos". No existe ninguna opción en SAP HANA para
dividir los datos por fecha para crear datos de acceso frecuente. Técnicamente es posible
almacenar todos los datos en la memoria, pero no sería una mejor práctica debido al coste
de hacerlo. Leer más en el módulo Aspectos clave del modelado de SAP HANA, en el curso
BW430.

2. Existen dos InfoSitios que permiten el acceso virtual con transformaciones.

Unir los elementos de la primera columna con el que corresponda de la segunda columna

InfoSitio Caso de utilización

Proveedor de badios Acceso virtual con una interfaz
de programa
Vista Open ODS
Acceso virtual sin transforma-
ción o con una transformación
de BW
Tienes razón. Leer más en el módulo Aspectos clave del modelado BW/4HANA, en el
curso BW430.

92 © Copyright. Reservados todos los derechos.

 Capítulo 3 : Respuestas a la Evaluación de la formación

3. Según el enfoque de BW/4HANA, ¿cuál de las siguientes opciones debería tenerse en

cuenta al modelar datos maestros y datos de transacción?
Seleccione las respuestas correctas.

X A Si no es necesario replicar los datos maestros, se podría utilizar una vista Open
ODS para textos y atributos.

X B Si los datos de transacción deben almacenarse, se debe utilizar un objeto

DataStore (aDSO)

X C Para cargar datos de transacción de forma eficiente, se debe utilizar una vista
Open ODS del tipo Facts.

X D Sin carga de datos adicional, combine datos de InfoSitios existentes utilizando un

CompositeProvider.

X E Si los datos maestros deben grabarse de forma persistente, se deben utilizar

características

¡Ha acertado! Todas las opciones enumeradas son adecuadas para BW 7.5, excepto para
la carga mediante una vista Open ODS. Las vistas Open ODS no se utilizan para cargar
datos, solo se utilizan para visualizar datos durante la ejecución de la consulta. Leer más
en el módulo Aspectos clave del modelado BW/4HANA, en el curso BW430.

4. Debe especificar su sistema BW/4HANA como completamente centrado en SAP BW/

4HANA o completamente centrado en SAP HANA.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! Puede implementar modelos centrados en SAP BW/4HANA uno al lado del
otro, otros modelos centrados en SAP HANA e incluso modelos mixtos. Leer más en el
módulo Comparación de enfoque de SAP BW/4HANA, enfoque de SAP HANA y
estrategias mixtas, en el curso BW430.

© Copyright. Reservados todos los derechos. 93

Capítulo 3 : Respuestas a la Evaluación de la formación

5. ¿Qué enfoque de modelado utilizaría para los informes empresariales basados en datos
históricos estables que deben testificarse si es necesario armonizar datos de diferentes
fuentes?
Seleccione la respuesta correcta.

X A Enfoque de SAP BW/4HANA

X B Enfoque de SAP HANA

X C Enfoque de SAP S/4HANA

¡Ha acertado! Utiliza un enfoque de SAP BW/4HANA para informes empresariales con
una base de datos histórica estable que debe testificarse si los datos de diferentes fuentes
deben armonizarse. Leer más en el módulo Comparación de enfoque de SAP BW/4HANA,
enfoque de SAP HANA y estrategias mixtas, en el curso BW430.

6. ¿Qué tecnología aprovecha la analítica integrada de SAP S/4HANA?

Seleccione la respuesta correcta.

X A Vistas de cálculo de SAP HANA

X B SAP ABAP Core Data Services

X C SAP BW integrado con InfoCubos en tiempo real

X D SAP HANA Core Data Services

Correcto. SAP S/4HANA incluye un gran número de vistas CDS ABAP para configurar un
modelo de datos virtual para la generación de informes operativa. Las vistas de cálculo de
SAP HANA se utilizaban para el análisis en SAP Business Suite powered by SAP HANA
(también conocido como SAP HANA Live). Pero en SAP S/4HANA, la tecnología se
cambió a SAP ABAP Core Data Services. Si es así, el componente SAP BW integrado solo
juega un papel menor para el caso de uso de analítica integrada a la hora de proporcionar
la interfaz BICS para consultas BW como interfaz de informes. No confunda HANA CDS
con ABAP CDS. Ambas son tecnologías existentes que comparten el mismo concepto. Sin
embargo, difieren en su aplicación. Dado que SAP S/4HANA se basa en SAP ABAP, son
las vistas CDS ABAP las que presentan el modelo de datos virtual para análisis integrados
en SAP S/4HANA.

94 © Copyright. Reservados todos los derechos.

 Capítulo 3 : Respuestas a la Evaluación de la formación

7. ¿Cuál es el impacto de SAP S/4HANA en un sistema SAP BW existente?

Seleccione las respuestas correctas.

X A Después de la implementación de la analítica integrada de SAP S/4HANA, algunas

aplicaciones en el sistema SAP BW pueden quedar obsoletas.

X B La analítica integrada de SAP S/4HANA asume completamente el rol de los

entornos de SAP BW existentes. Los sistemas SAP BW se pueden inhabilitar.

X C La extracción al sistema SAP BW existente puede cambiar porque no todos los

extractores (fuentes de datos) están disponibles en SAP S/4HANA del mismo modo.

X D La conversión del sistema SAP BW existente a SAP BW/4HANA es una condición

previa para una implementación de SAP S/4HANA.

Correcto. La analítica integrada de SAP S/4HANA proporciona informes operativos

dentro de SAP S/4HANA. Todos los demás casos de uso analíticos aún no están cubiertos
por SAP BW, pero los escenarios operativos en SAP BW deben volver a evaluarse en
cuanto a si deben inhabilitarse. No todas las fuentes de datos estándar de SAP están
disponibles de la misma manera, y las fuentes de datos de cliente también pueden verse
afectadas por el modelo de datos de SAP S/4HANA. Como consecuencia, algunas
interfaces para SAP BW pueden requerir ajustes. La analítica integrada de SAP S/4HANA
proporciona informes operativos dentro de SAP S/4HANA. Todos los demás casos de uso
analíticos aún no están cubiertos por SAP BW. Desde el punto de vista de la versión del
software, SAP S/4HANA es independiente de SAP BW/4HANA y viceversa.

© Copyright. Reservados todos los derechos. 95

Capítulo 3 : Respuestas a la Evaluación de la formación

96 © Copyright. Reservados todos los derechos.

CAPÍTULO 4 Estándares de mejores
prácticas en el modelado de
SAP BW/4HANA

Lección 1
Comprender las opciones de modificación de objetos en la infraestructura del sistema 99

Lección 2
Separación de datos maestros y datos transaccionales 105

Lección 3
Historial de seguimiento 117

Lección 4
Asignación y transformación de datos 125

Lección 5
Diseño de una arquitectura escalable en capas de SAP BW/4HANA (LSA++) 137

Lección 6
Comprender la partición física y lógica 161

OBJETIVOS DEL CAPÍTULO

● Comprender las opciones de modificación de objetos en la infraestructura del sistema

● Datos maestros y transaccionales separados
● Comprender el historial de seguimiento
● Mapee y transforme datos
● Diseñar una arquitectura escalable en capas con capas virtuales
● Comprender la partición física y lógica

© Copyright. Reservados todos los derechos. 97

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

98 © Copyright. Reservados todos los derechos.

 Capítulo 4
Lección 1
Comprender las opciones de modificación de
objetos en la infraestructura del sistema

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Comprender las opciones de modificación de objetos en la infraestructura del sistema

Comprender las opciones de modificación de objetos en la infraestructura del

sistema

Figura 73: Escenario empresarial: Opciones de modificación de objeto

Ha decidido utilizar SAP BW/4HANA. Usted es responsable de la planificación de la

infraestructura del sistema y del Customizing. Desea asegurarse de que los objetos con un
gran impacto en los datos se crean en un entorno de desarrollo que no afecta a los datos
productivos. Sin embargo, algunos usuarios empresariales deben poder crear nuevas
consultas en un entorno productivo de acuerdo con los nuevos requisitos sin un
procedimiento complicado.
¿Qué es una infraestructura de sistema recomendada?

© Copyright. Reservados todos los derechos. 99

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Figura 74: Mejores prácticas: Infraestructura del sistema

Recomendamos utilizar diferentes tipos de sistemas en una infraestructura de sistemas.

¿Cuál es el objetivo de cada sistema?
El sistema productivo SAP BW/4HANA (PRD) se utiliza para generar los informes necesarios.
Por lo general, sus datos se suministran desde uno o más sistemas fuente productivos.
Normalmente, un sistema fuente es una aplicación SAP S/4HANA o una aplicación de
componente central empresarial, pero también puede ser otro sistema SAP BW/4HANA o un
sistema externo.
Para cada sistema productivo, se recomienda una infraestructura de al menos tres sistemas
técnicos:
● Un sistema de desarrollo (DEV) para desarrollar objetos y realizar.
● Un sistema de control de calidad (QAS) para pruebas de calidad y rendimiento.
● El propio sistema productivo.

Por ejemplo, si el sistema HR, HRP, y el sistema de fabricación, M1P, son dos sistemas fuente
para el sistema SAP BW/4HANA BWP productivo, existen tres sistemas HR: HRD, HRQ, HRP,
tres sistemas de fabricación: M1D, M1Q, M1P y tres sistemas BW/4HANA: BWD, BWQ, BWP.
El motivo principal de los otros sistemas es proteger el entorno productivo de programas
dañinos y objetos mal definidos. Para mantener estable el sistema productivo, no cree ni
modifique objetos en el sistema productivo. Los usuarios empresariales solo inician sesión en
el sistema productivo y, para pruebas de calidad, en el sistema de gestión de calidad.
Para realizar nuevos requisitos, cree o modifique objetos como tablas, programas o
workflows en el sistema de desarrollo. Todas las modificaciones se escriben en órdenes de
transporte y, a continuación, se transportan a los sistemas subsiguientes en la serialización
correcta. El sistema de desarrollo contiene solo un pequeño conjunto de datos de muestra,
donde los problemas técnicos se resuelven rápidamente.
¿Cómo trata el programa el contenido vacío o los valores clave incorrectos?
Recomendación: Intente incluir casos típicos que posiblemente causen problemas en los
datos de muestra, como el valor 0, campos vacíos, etc. Asegúrese de que la base de datos

100 © Copyright. Reservados todos los derechos.

 Lección: Comprender las opciones de modificación de objetos en la infraestructura del sistema

para el sistema de desarrollo es pequeña. Garantice lo mismo para las actualizaciones y

parches de prueba.
Si los objetos se comportan correctamente en los datos de muestra, pueden causar
problemas en un entorno productivo. Por ejemplo, si un programa se rellena con datos reales,
el programa podría causar los siguientes problemas:
● Resultados erróneos en casos especiales
● Bloqueo de otras transacciones
● Alto consumo de recursos que ralentiza el sistema
● Errores y dumps breves

Estos problemas pueden deberse a los siguientes motivos:

● Faltan entradas de base de datos
● Valores incorrectos en el sistema fuente
● Actividad simultánea del usuario
● Valores matemáticos inusuales
● Problemas con las monedas que rara vez se utilizan

Existen muchos otros motivos que ocurren esporádicamente en un entorno productivo, pero
no en el sistema de desarrollo. Por lo tanto, pruebe el entorno productivo con datos reales.
Un sistema de control de calidad es un sistema independiente para tales pruebas de
rendimiento y calidad de datos. Pueden detectarse problemas con datos reales como los
siguientes:
● ¿Las fuentes proporcionan contenido problemático, por ejemplo, letras especiales
incorrectas, como la letra Ä?
● ¿Se entregan archivos con code pages incorrectos, números incorrectos, valores
faltantes? ¿Se producen errores en datos reales, como valores que son demasiado altos?

Verifique el comportamiento previsto:

● ¿Los programas y mecanismos de carga funcionan correctamente dentro del límite de
tiempo?
● ¿Se muestran grandes conjuntos de resultados según lo previsto?

El sistema de gestión de calidad contiene una copia de datos reales. Cada objeto debe
transportarse al sistema de gestión de calidad; no se permiten modificaciones.
Se recomienda resolver problemas de lista en el sistema de desarrollo. Después de
transportar las modificaciones al sistema de gestión de calidad, vuelva a realizar el test.
Si se resuelven todos los problemas técnicos y de calidad, los objetos se transportan al
sistema productivo. Los datos productivos de los procesos empresariales productivos se
almacenan en este sistema.
La infraestructura puede contener otros sistemas:
● Un sistema de prueba que no está conectado a transportes se puede utilizar para probar la
viabilidad técnica o la función de nuevas funciones. Consultarlo en caso de incertidumbre
antes de tomar decisiones de diseño.

© Copyright. Reservados todos los derechos. 101

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

● Se puede utilizar una copia del sistema productivo como sistema de formación en el que
se forma a los usuarios empresariales. Los objetos se pueden crear, pero no se pueden
transportar a ningún otro sistema.

Figura 75: Decisión de modelado: Opciones de modificación de objeto

Un sistema abierto es un sistema en el que se pueden modificar objetos y crear objetos

nuevos.
En un sistema cerrado, debe importar un transporte para modificar objetos.
Los sistemas ECC productivos suelen ser sistemas cerrados.
En BW, el concepto es diferente. Para cumplir con los nuevos requisitos, algunos objetos que
no pueden dañar se pueden definir como modificables. Defina qué tipos de objeto se definen
como modificables. Normalmente, estos objetos son consultas, vistas de consulta y opciones
de cálculo previo. Sin embargo, no defina InfoSitios, transformaciones y DTP como
modificables. Pruebe y transporte los objetos.

102 © Copyright. Reservados todos los derechos.

 Lección: Comprender las opciones de modificación de objetos en la infraestructura del sistema

Figura 76: Decisión de modelado: Áreas de nombres y autorizaciones

Si las consultas se pueden modificar en el sistema productivo, se recomienda restringir esta

opción a áreas de nombres especiales. Por ejemplo, defina un área de nombres, como objetos
que empiecen por U, para los que se permita la creación y modificación. Para otras áreas de
nombres, como las consultas que empiezan con P, deben crearse en el sistema de desarrollo
y, a continuación, transportarse.
Para obtener más información, consulte BW365 (gestión de autorizaciones de SAP BW/
4HANA) y HA240 (gestión de autorizaciones de SAP HANA).
Asegúrese de liberar los transportes en el orden correcto: Primero los transportes de versión
en el sistema de origen o los transportes para las vistas de SAP HANA antes de transportar
objetos BW que dependen de ellos.
Mantenga los transportes BW pequeños creando transportes separados para los siguientes
grupos de tipos de objeto:
● Fuentes de datos y vistas Open ODS
● InfoObjetos
● ADSO e InfoFuentes
● Transformaciones y DTP
● Áreas de trabajo de BW/4HANA
● Proveedores compuestos
● Consultas
● Aplicaciones front end.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Comprender las opciones de modificación de objetos en la infraestructura del sistema

© Copyright. Reservados todos los derechos. 103

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

104 © Copyright. Reservados todos los derechos.

 Capítulo 4
Lección 2
Separación de datos maestros y datos
transaccionales

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Datos maestros y transaccionales separados

Separación de datos maestros y datos transaccionales

Figura 77: Escenario empresarial: Separación de datos maestros

ITelO desea añadir información como la descripción, la categoría o el precio de los productos
o los proveedores para los informes de compras y ventas. Esta información está disponible en
diferentes fuentes, pero de vez en cuando cambia el precio, el texto o la categoría.
Desea visualizar el mismo producto con el mismo precio de lista en todos los informes, pero
con precios de venta divergentes para registros individuales.
Desea visualizar la categoría y el precio de la información del día de ventas para cada
producto.
Desea saber cuántos productos tiene en qué categoría.
Diferentes usuarios deberían ver la descripción en su idioma.

© Copyright. Reservados todos los derechos. 105

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Figura 78: Definición: ¿Qué son los datos maestros? ¿Qué son los datos transaccionales?

Los datos maestros hacen referencia a datos que cambian lentamente y hacen referencia a
objetos empresariales y sus propiedades como textos (descripciones), atributos (categorías,
valores estándar) y jerarquías (niveles de agregación). Los datos maestros se comparten en
toda la empresa.
Los datos transaccionales describen operaciones y procesos empresariales, generalmente
por información de estado y ratios (KPI).
Al modelar información, decida dónde necesita el valor individual de una transacción, como el
precio de venta real, o el valor estándar, como el precio de lista, o ambos. Esto significa que
debe decidir si desea tomar el valor de los datos maestros o de los datos transaccionales.
Cuando se modifican atributos estándar, como categoría o precio, se ajustan los datos
maestros. Los datos de transacción no se modifican y reflejan la verdad histórica.

Figura 79: Motivación: problemas sin separar datos maestros

106 © Copyright. Reservados todos los derechos.

 Lección: Separación de datos maestros y datos transaccionales

Al tratar los datos maestros, puede optar por almacenar los textos y atributos en campos
adicionales de las tablas de datos transaccionales o en tablas de datos maestros separadas.
Almacenar textos o atributos junto con datos transaccionales significa que para cada registro
se inserta el atributo o el valor de texto correspondiente. Una ventaja de este enfoque es que
no se necesita ninguna unión adicional para generar el conjunto completo de datos como se
desea en los informes. Sin embargo, con SAP HANA como base de datos, la generación de
uniones se puede realizar en la memoria y no es tan lenta como con otros sistemas de base
de datos. Otra ventaja es que la relación se conserva cuando se almacenan los datos
transaccionales. Esto es importante si no hay una manera fácil de recuperar esta relación
más adelante.
Sin embargo, almacenar atributos y textos en tablas de datos transaccionales tiene muchas
desventajas:
● Redundancia
Si el mismo producto aparece en varios registros en una tabla de datos transaccionales o
en diferentes tablas, se producirá un almacenamiento redundante de la misma relación.
● Inconsistencia
Es difícil corregir información cuando los textos o atributos difieren entre diferentes tablas
o diferentes entradas de una tabla.
● Confusión
Si hay errores en los valores originales, se almacenan en las grandes tablas de datos
transaccionales y no está claro por qué los valores son diferentes. Corregir los errores
sería difícil, e incluso sería difícil encontrar todas las ocurrencias.
● Tiempo de ejecución de staging incorrecto
Si se modifica la relación de atributos, debe modificarse en cada registro de la tabla de
datos transaccionales. Esto provoca tiempos de carga largos y, después de la ejecución de
modificación, solo es visible la versión nueva.
● Fijación
Para modificar atributos, solo es visible una versión. Por ejemplo, si un producto era nuevo
cuando se cargaron los datos de transacción, permanece catalogado como nuevo muchos
años más tarde incluso si el estado se ha modificado en el sistema de origen. Los textos se
fijan como cargados. Los textos también aparecen en un solo idioma. No hay ninguna
posibilidad de textos supeditados a clave de idioma o diferentes versiones de jerarquías de
datos maestros.

© Copyright. Reservados todos los derechos. 107

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Figura 80: Ventajas: Separar los datos maestros para reducir el espacio de almacenamiento

Con tablas de datos maestros separadas, puede reducir los costes de almacenamiento
porque cada relación se almacena solo una vez.
Es más fácil corregir y verificar los datos maestros en una tabla de datos maestros separada
más pequeña. Por ejemplo, en la tabla de datos maestros, cada identificador de producto
aparece solo una vez con texto y atributos (categoría, precio). Después de unir esta
información a los registros de datos transaccionales, cada fila de un producto específico
contiene el mismo texto y categoría.
Intente reducir el conjunto de columnas que se deben unir al definir un informe para un
escenario específico. En un escenario de aprovisionamiento, no se une al precio de venta.

Figura 81: Ventajas: Textos específicos de idioma

108 © Copyright. Reservados todos los derechos.

 Lección: Separación de datos maestros y datos transaccionales

El concepto de tabla de datos maestros de SAP permite textos dependientes de idioma, para
diferentes versiones de jerarquías de datos maestros, para atributos dependientes de tiempo,
jerarquías y textos.
Con el concepto de InfoObjeto de SAP BW/4HANA, para cada InfoObjeto, se generan tablas
separadas para sus textos, atributos dependientes del tiempo, atributos no dependientes del
tiempo y jerarquías. En SAP BW/4HANA, si define InfoObjetos con textos dependientes de
idioma, el texto correcto se selecciona automáticamente para visualizar textos en informes.
Si utiliza el modelado basado en SAP HANA, le recomendamos que utilice vistas de cálculo de
tipo dimensiones como vistas de datos maestros separadas. Técnicamente, los textos, los
atributos y las jerarquías se pueden modelar en la misma vista de cálculo de SAP HANA. Sin
embargo, verifique si puede ahorrar espacio de disco definiendo vistas separadas para
atributos y textos dependientes de idioma.
Para definir vistas SAP HANA con textos dependientes de idioma, incluya manualmente un
campo de idioma como parte de la clave y cree un filtro para el idioma de trabajo. Existe una
función de SAP HANA llamada join de texto que combina una conexión externa izquierda con
un filtro para el idioma de trabajo. Para modelar una vista de cálculo para atributos
dependientes del tiempo, añada campos de fecha como campos clave adicionales. Puede
definir jerarquías, pero no todas las funciones del concepto de InfoObjeto de SAP BW/4HANA
se admiten en las vistas de cálculo de SAP HANA.

Figura 82: Ventajas: Ratios en tablas de datos maestros

Los atributos pueden ser ratios (indicadores). Con indicadores como atributos, es posible
realizar cálculos que utilizan valores de datos maestros y valores transaccionales. Por
ejemplo, un precio total puede derivarse calculando el precio multiplicado por la cantidad en
cada registro y, a continuación, agregando todos los productos. Este tipo de cálculo se puede
definir en una vista SAP HANA o en una consulta BW.

© Copyright. Reservados todos los derechos. 109

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Figura 83: Ventajas: Historización de datos maestros

Utilice tablas de datos maestros separadas para grabar modificaciones históricas en los
datos maestros solo una vez por modificación. A continuación, puede almacenar el período
de validez para cada conjunto de atributos en un registro. A continuación, puede buscar los
valores de atributo que son válidos para una fecha de ventas específica para generar la
verdad histórica. Por ejemplo, el precio histórico para cada pedido de cliente si el precio se
almacena como un atributo dependiente del tiempo. Esta búsqueda puede tener lugar en el
proceso de puesta a disposición o durante la gestión de informes.

Figura 84: Ventajas: Datos maestros como datos de referencia

110 © Copyright. Reservados todos los derechos.

 Lección: Separación de datos maestros y datos transaccionales

La ventaja más importante de las tablas de datos maestros independientes es la verificación

de la integridad referencial.

Los errores tipográficos son una fuente típica de errores. En un almacén de datos
consolidado, solo se deben aceptar valores válidos. La idea de la integridad referencial es
eliminar registros sin entradas correspondientes en las tablas de datos maestros.
Si modela flujos de datos de SAP BW/4HANA, los registros con valores que no se enumeran
en las tablas de datos maestros se reconocen como errores. Según el motivo de la entrada
que falta, tiene dos opciones para solucionarlo: cargar las entidades que faltan en las tablas
de datos maestros o corregir las entradas en la fuente de datos transaccionales. A
continuación, vuelva a cargar los valores.
Si utiliza vistas SAP HANA, puede utilizar la conexión interna de tipo de conexión para
eliminar registros con valores que no coincidan con las entradas de la tabla de datos
maestros.

Figura 85: Ventajas: Informes de datos maestros

Los datos maestros se pueden utilizar para la gestión de informes sin datos de movimiento.
Este ejemplo ofrece un resumen de la cantidad total de productos y las categorías más
relevantes. ¿Cómo se genera este informe?
La lista de productos debe estar disponible como datos maestros.
En SAP BW/4HANA, las características se pueden utilizar como un InfoSitio. A continuación,
se genera el número de filas como un ratio que se puede agregar por categoría.
En las vistas de cálculo nativas de SAP HANA, se puede crear una columna calculada con un
valor constante de 1 por fila para lograr el mismo resultado.
En las consultas BW y en las vistas nativas de SAP HANA, se puede generar una jerarquía de
visualización a partir de una lista de atributos.

© Copyright. Reservados todos los derechos. 111

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Figura 86: Resumen: Ventajas de separar datos maestros

Se recomienda almacenar los datos maestros y los datos transaccionales por separado. Esto
tiene las siguientes ventajas:
● Generar nueva información
Con la gestión de informes de datos maestros, puede ver cuántos productos de cada
categoría tiene o con qué frecuencia se ha modificado la categoría de un producto.
● Reducir espacio de almacenamiento
Las tablas de datos maestros almacenan cada relación solo una vez.
● Soporte de idioma
Con los textos dependientes de idioma, la vista se adapta al idioma de trabajo.
● Separar ciclos de carga
Los datos maestros normalmente se actualizan con menos frecuencia que los datos
transaccionales. Si las relaciones de datos maestros se modifican, no es necesario volver a
cargar los datos operacionales. Nota: Al cargar datos maestros de diferentes fuentes, la
secuencia de cargas de datos determina qué valores se sobrescriben.
● Consistencia
Rechazar valores de producto incorrectos. Después de la búsqueda de datos maestros,
visualice el mismo producto con la misma categoría en todo el informe.
● Flexibilidad
Si los datos maestros se han modificado, el usuario de reporting puede seleccionar la
fecha clave global.

Atributos transitorios y datos maestros virtuales

Como se ha comentado anteriormente en esta unidad, con SAP BW/4HANA, puede reducir el
espacio de almacenamiento separando los datos maestros y los datos transaccionales. Sin

112 © Copyright. Reservados todos los derechos.

 Lección: Separación de datos maestros y datos transaccionales

embargo, es posible que haya información redundante dentro de las tablas de datos
maestros. Considere el siguiente ejemplo: 34.000 empleados están asignados a 20 unidades
organizativas y 3 sociedades. Sin embargo, la sociedad sólo depende de la unidad
organizativa. En lugar de almacenar la sociedad para cada uno de los 34.000 empleados,
basta con almacenar la unidad organizativa de cada empleado y la sociedad de cada unidad
organizativa en una tabla más pequeña con 20 filas. En una vista de cálculo de SAP HANA,
puede definir un join para recuperar la sociedad de los empleados.

Figura 87: Atributos transitorios con característica SAP BW

¿Cómo funciona con InfoObjetos? En SAP BW/4HANA y SAP BW 7.5 SP04, puede activar
Atributos transitorios para características de InfoObjeto con atributos. De este modo, puede
ampliar su modelo de datos con los atributos de sus atributos de visualización o atributos de
navegación. Estos se pueden definir como atributos de solo visualización o como listos para la
navegación.
Encontrará la función de actualización de la característica en el menú contextual del panel
Visualizar y atributos de navegación de la pestaña Atributos en la pantalla InfoObjeto basado
en Eclipse de las herramientas de modelado de SAP BW.

Nota:
El concepto SAP BW/4HANA de atributos transitivos se limita a un paso (desde el
atributo de primer nivel, por ejemplo, unidad organizativa, al atributo transitivo,
por ejemplo, sociedad). Un atributo del atributo transitorio, por ejemplo, el país de
la sociedad, no puede estar disponible para la característica básica, por ejemplo,
empleado. Una posible solución sería cargar la información del país como atributo
de la unidad organizativa, que luego podría convertirse en un atributo transitorio
del empleado.

© Copyright. Reservados todos los derechos. 113

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Datos maestros virtuales de SAP HANA

Mediante las vistas de cálculo de SAP HANA, los atributos de los atributos se pueden derivar
mediante joins. No hay límite en el número de combinaciones.

Figura 88: "Atributos transitivos" con vista de cálculo de SAP HANA

Si la relación entre característica y atributo es estable, existe una forma diferente de modelar
una jerarquía de atributos. Si las dos primeras letras de un número de producto determinan
su tipo, puede utilizar una fórmula en una vista de cálculo de SAP HANA para derivar el tipo de
producto. Si otras letras del número de producto definen grupos de productos de nivel
inferior, se puede derivar una jerarquía de atributos de producto.

Atención:
Sin embargo, este concepto solo es útil si está seguro de que la asignación es
estable, por ejemplo, si se basa en una relación química o física, o si el ID de
producto siempre es una combinación de tipo, material y color, y un nuevo tipo o
color requiere un nuevo ID de producto. (Incluso en los casos en que se pensaba
que una relación era estable, resultó estar cambiando. Por ejemplo, los números
de la seguridad social alemana contienen el sexo y la fecha de nacimiento de la
persona porque cuando se desarrolló el diseño, nadie podía imaginarse que
podrían cambiar. Pero hoy en día, la gente puede (y algunos sí) cambiar su sexo,
y algunos inmigrantes reclamaron una fecha de nacimiento equivocada que tuvo
que ser cambiada más adelante. En estos casos, el ID debe modificarse en todas
partes donde aparece, o derivar el atributo como fórmula da resultados
incorrectos).

114 © Copyright. Reservados todos los derechos.

 Lección: Separación de datos maestros y datos transaccionales

Figura 89: InfoObjetos con acceso virtual: Consumo de datos maestros de SAP HANA

Datos maestros virtuales

Con SAP BW/4HANA, es posible que los InfoObjetos accedan a los datos de las vistas de
cálculo de SAP HANA pero no guarden de forma persistente estos datos. Existen las
siguientes ventajas:
● Los modelos de información de SAP HANA existentes se exponen y se pueden utilizar
como datos maestros virtuales (atributos y textos de navegación virtual) en SAP BW.
● Los cambios en las tablas subyacentes se reflejan inmediatamente sin latencia.
● Se pueden modelar niveles superiores de atributos transitivos (atributos de atributos de
atributos).
● Los atributos transitorios se pueden poner a disposición sin ofrecer el atributo intermedio.
● No se requiere staging de datos de datos maestros de SAP HANA.

¿Qué debe hacer para crear datos maestros virtuales?

Procedimiento

1. En la perspectiva de SAP HANA Modeler en SAP HANA Studio, defina y active una vista de
cálculo de SAP HANA que contenga la característica básica y todos los textos y atributos
necesarios.

2. Cambie a la perspectiva de modelado BW en SAP HANA Studio.

3. Haga clic con el botón derecho en una InfoÁrea y cree un InfoObjeto. Seleccione el subtipo
Característica.

4. Realice las entradas necesarias para su InfoObjeto, por ejemplo, parametrizaciones para
el tipo de datos, relación y textos. En la etiqueta Atributos, enumere todos los atributos
necesarios.

© Copyright. Reservados todos los derechos. 115

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

5. En la etiqueta Datos maestros/Textos, seleccione SAP HANA Viewas Access Type.

6. Especifique el paquete SAP HANA, así como la vista SAP HANA.

7. Seleccione los atributos de SAP HANA para los que desea generar propuestas y
seleccione Aplicar. Aparece una lista de propuestas. Los atributos del modelo SAP HANA
se visualizan en carpetas. Las propuestas se enumeran en estas carpetas. Seleccione
Detalles técnicos para visualizar la estrategia para crear propuestas.

8. En cada caso, seleccione una propuesta adecuada para atributos, textos y relación (si
procede). Si ninguno de los InfoObjetos sugeridos es adecuado, inicialmente puede dejar
el atributo sin asignar y asignarlo manualmente más tarde. Seleccione Continuar. Se
asignan los atributos. Si ha seleccionado textos (TXTSH, TXTMD, TXTLG), se fijará el
indicador correspondiente para textos en la etiqueta Datos maestros/Textos.

9. Asignar atributos manualmente: Seleccione Actualizar enlaces SAP HANA.

10. En cada caso, seleccione atributos SAP HANA adecuados para atributos, textos y relación
(si procede) y seleccione Aplicar.

11. Active la característica.

Ahora puede utilizar la característica con datos en sus modelos de datos.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Datos maestros y transaccionales separados

116 © Copyright. Reservados todos los derechos.

 Capítulo 4
Lección 3
Historial de seguimiento

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Comprender el historial de seguimiento

Historial de seguimiento

Figura 90: Escenario empresarial para historial de seguimiento

Para enriquecer los informes de ventas, ITelO desea añadir información de categoría para
productos vendidos. Supongamos que las asignaciones de producto a categoría de producto
se modifican con el tiempo en el sistema original Online Transaction Processing (OLTP).
Algunos usuarios de SAP BW/4HANA solo necesitan la relación capturada en el pedido de
cliente cuando se creó. A otros les gustaría realizar su análisis basado en la última asignación
de las tablas de datos maestros. Debe decidir cómo documentar las modificaciones de estas
asignaciones en el modelo SAP BW4/HANA.

© Copyright. Reservados todos los derechos. 117

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Figura 91: Ejemplo de datos de soporte para el historial de seguimiento

El ejemplo de la figura, Datos de soporte para el historial de seguimiento, se centra en las

modificaciones que se realizan en la categoría de producto (alimentos, productos químicos,
etc.) en relación con los datos maestros de producto. Supongamos que el 1 de enero de 2018
se modificaron las asignaciones de categoría de producto para el alcohol de producto y se
añadió un nuevo ozono de producto a los datos maestros de producto.
La figura, Tablas SAP BW4/HANA para el historial de seguimiento, muestra los datos que
existen en el sistema OLTP o en el sistema SAP ERP. Los datos representan la tabla de datos
maestros de producto (en dos versiones) y una tabla de pedidos de cliente.

Figura 92: Tablas SAP BW4/HANA para historial de seguimiento

118 © Copyright. Reservados todos los derechos.

 Lección: Historial de seguimiento

Si desea documentar modificaciones de datos maestros, puede definir la categoría como un

atributo dependiente del tiempo del producto. Recuerde que si desea visualizar los valores de
categoría sin visualizar los valores de producto, seleccione la opción de atributo de
navegación. Cada vez que se modifica la asignación, se cargan nuevos registros de datos
maestros en SAP BW4/HANA. El período de validez de la nueva asignación empieza en la
fecha actual. En nuestro ejemplo, esta fecha es 1 de enero de 2018. El período de validez de la
asignación anterior finaliza el día anterior. En nuestro ejemplo, esta fecha es el 31 de
diciembre de 2017.
Si no necesita documentar modificaciones, la categoría podría modelarse como atributo no
dependiente del tiempo. No se crea ningún período de validez. La asignación antigua ya no se
puede recuperar.
Como alternativa, puede almacenar las asignaciones dentro de la tabla de datos
transaccionales. Cargue los datos transaccionales inmediatamente después de la creación de
los pedidos de cliente en el sistema SAP ERP y capture la relación entre el producto y la
categoría de producto que existe en ese momento. Si realiza nuevas asignaciones en SAP
ERP, los nuevos pedidos de cliente reflejan estas modificaciones, pero los pedidos de cliente
antiguos siguen siendo los mismos. Por lo tanto, el mismo producto se puede enumerar con
diferentes categorías en la tabla de datos transaccionales. Después de la agregación de datos
de diferentes pedidos de cliente, si el mismo producto se vendió en la misma categoría de
producto, se mantendrá un valor agregado. Pero las diferentes combinaciones de producto y
categoría de producto permanecen separadas.
Si la característica de categoría no se proporciona en la tabla de datos transaccionales del
sistema ERP cuando se cargan los datos de transacción, puede crear esta información, por
ejemplo, con una búsqueda de la tabla de datos maestros de producto, para determinar el
valor de categoría.

Figura 93: Escenario A para seguimiento de historial: Verdad histórica

Escenario A: Verdad histórica en el momento del pedido de cliente

© Copyright. Reservados todos los derechos. 119

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

¿Cómo se pueden notificar los datos de estos modelos? En la figura, Escenario A para
Seguimiento de historial: “Verdad histórica”, la categoría en una consulta es una
característica de los datos transaccionales.
En nuestro ejemplo, el azúcar siempre se vendió en la categoría de alimentos y la fila muestra
los valores de 2017 y 2018. El alcohol se vendió en parte como productos químicos y en parte
como alimento, por lo que aparecen dos filas diferentes en el informe. El ozono siempre se
vendía como productos químicos.
La tabla de datos maestros no se utiliza en absoluto al crear el informe. En la figura, Escenario
A para Seguimiento de Historia: Verdad Histórica, está marcado en gris por este motivo.
Si elimina la característica de producto del desglose, la categoría se seguirá reflejando como
una verdad histórica en esta vista agregada.
La ventaja de este diseño es que todos los valores aparecen como sumas como se habrían
calculado en el día de ventas.

Vista actual
Como desventaja de la visualización de la verdad histórica, parece que los ingresos por ventas
para la categoría de alimentos subieron drásticamente, y los productos químicos tuvieron un
rendimiento más deficiente. Sin embargo, se trata de un efecto de las modificaciones ocultas
de las asignaciones de datos maestros, no de una tendencia de ventas real.
¿Cómo se pueden hacer visibles las tendencias de ventas reales?

Figura 94: Escenario B: Vista actual

En la imagen, Escenario B: Vista actual, la categoría se modela como un atributo de

navegación independiente del tiempo del producto. Ahora, para cada producto, solo hay una
asignación, según la última relación entre el producto y la categoría.
La columna de categoría de la tabla de datos transaccionales no se utiliza en absoluto.
Si elimina el producto del desglose, en el ejemplo, todas las ventas de azúcar y alcohol se
sumarán al valor total de ingresos por ventas de alimentos. El valor total de los productos

120 © Copyright. Reservados todos los derechos.

 Lección: Historial de seguimiento

químicos contiene los productos que actualmente pertenecen a los productos químicos. En el
ejemplo, solo el ozono sigue asignado como productos químicos.
La ventaja del escenario B es que el informe agregado refleja las tendencias de ventas reales:
los alimentos y los productos químicos muestran una tendencia positiva.

Vista dependiente del tiempo

Como desventaja, los datos de 2017 no reflejan la verdad: parece que en 2017 no se vendieron
productos químicos.

Figura 95: Escenario C1: En cualquier momento, fecha clave actual

En la imagen, Escenario C1: En cualquier momento, fecha clave actual, la categoría se modela
como un atributo de navegación dependiente del tiempo del producto.
Cuando se crean consultas en la herramienta de modelado de BW, se especifica una fecha
clave en las propiedades de consulta para indicar al sistema qué registro de datos maestros
debe utilizar.
Por defecto, esta fecha clave es la fecha en la que se ejecuta el informe. A continuación, se
ignoran las asignaciones históricas. Los números en el resultado son los mismos que el
escenario B (vista actual).

© Copyright. Reservados todos los derechos. 121

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Figura 96: Escenario C2: Fecha clave histórica en cualquier momento

Sin embargo, con este diseño de modelo, se puede seleccionar una vista diferente. Si la fecha
clave se modifica a 1 de enero de 2017, se ignora la asignación de otros períodos de validez
(marcada en gris en la figura, Escenario C2: En cualquier momento, Fecha clave histórica). En
su lugar, todos los productos se visualizan de forma consistente con la categoría asignada el 1
de enero de 2017, como si no se hubieran modificado asignaciones de datos maestros. El
ozono, que no se ha registrado en esa fecha, se visualiza con la categoría No asignado
(visualizado como #).
Como ventaja, las tendencias y los valores de 2017 son correctos. Como desventaja, los
ingresos de ventas actuales de 2018 se representan con asignaciones históricas.

122 © Copyright. Reservados todos los derechos.

 Lección: Historial de seguimiento

Figura 97: Escenarios para el historial de seguimiento: Resumen

Según el escenario, los valores se agregan de diferentes maneras.

Es posible combinar el escenario A con otros escenarios.
Por ejemplo, la categoría puede ser una característica en los datos transaccionales y también
puede ser un atributo de navegación dependiente del tiempo del producto (escenario C).
Si la consulta contiene ambos, la persona que diseña el informe puede elegir la forma más
adecuada de visualizar los datos.

Nota:
Se aplican escenarios similares para jerarquías dependientes del tiempo.

© Copyright. Reservados todos los derechos. 123

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Figura 98: Resumen y aspectos adicionales

En resumen, no hay mejor escenario. Depende de sus necesidades.

El escenario A (verdad histórica) es mejor en términos de rendimiento y complejidad de la
gestión de informes. Todos los valores se pueden leer desde una tabla.
El escenario B (vista actual) es mejor en términos de espacio de almacenamiento. No hay
redundancia. Solo se almacenan los valores necesarios actualmente. Sin embargo, pierde
toda la información sobre las asignaciones históricas.
El escenario C (dependiente de tiempo) es mejor en términos de flexibilidad porque el usuario
empresarial puede elegir libremente qué fecha clave utilizar.
Recuerde que el escenario A se puede combinar con otras opciones: la mayoría de las veces,
se seleccionan los escenarios A y C, o A y B.
Además, tenga en cuenta que el valor de los datos históricos disminuye con el tiempo.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Comprender el historial de seguimiento

124 © Copyright. Reservados todos los derechos.

 Capítulo 4
Lección 4
Asignación y transformación de datos

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Mapee y transforme datos

Asignación y transformación de datos

Figura 99: Escenario empresarial: Asignación y transformación de datos

La integración de datos de diferentes fuentes en un almacenamiento común es una tarea

típica al crear un almacén de datos.
Los datos de diferentes fuentes, como tablas en diferentes sistemas fuente o diferentes
tablas en el mismo sistema fuente, se recopilan en el almacén de datos.
En primer lugar, debe identificar los campos fuente que contienen identificadores para una
entidad de palabra real específica, como producto. A continuación, debe hacer las siguientes
preguntas:
● ¿El mismo producto tiene el mismo ID en ambas fuentes?
● ¿Los diferentes productos tienen ID diferentes?

Si la respuesta es sí a ambas preguntas, no se requiere ningún cambio en los campos

correspondientes durante la integración de datos.
Si la respuesta es no a esta pregunta, se deben realizar las siguientes tareas:
● Separe diferentes objetos.

© Copyright. Reservados todos los derechos. 125

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Este proceso separa objetos que tienen el mismo identificador en diferentes fuentes.
● Asignar diferentes valores.
Este proceso determina un identificador común para cada objeto del mundo real que
reemplaza los diferentes identificadores originales de diferentes fuentes.

Decida qué tipo de objeto se debe crear para generar el conjunto de resultados. Existen
diferentes escenarios, dependiendo del grado de transformación de los datos.

Figura 100: Motivación: Tareas de armonización

La imagen, Motivación: tareas de armonización, muestra un ejemplo de tareas de

transformación típicas de un almacén de datos empresariales.
La tarea central del modelado de almacén de datos es integrar y separar datos de varias
fuentes. Para crear un informe para toda la empresa, todos los resultados deben ser
comparables. Del mismo modo, para la armonización de datos maestros, se asignan
diferentes nombres técnicos a una nueva clave única de BW/4HANA para tablas de datos
transaccionales. Si faltan campos, deben derivarse para que todos los registros se enumeren
dentro de la misma estructura. Los ratios (indicadores) deben tener el mismo formato. Esto
incluye la conversión de cantidades a una unidad de BW/4HANA estándar, al menos para el
mismo producto, y la conversión de importes a una moneda estándar de BW/4HANA.
Otras tareas de armonización suelen formar parte de un proyecto de implementación de
almacén de datos. Antes de persistir los valores armonizados en un almacén de datos central,
se deben corregir o calcular los valores, como la facturación entre empresas, los tipos
impositivos o el margen neto. Si los registros están duplicados o están fuera del alcance del
proyecto BW/4HANA, deben eliminarse.
Si los valores deben estar disponibles inmediatamente en tiempo real, los resultados
armonizados se pueden realizar como vistas de cálculo de SAP HANA. Si los valores
históricos deben almacenarse de forma permanente, utilice InfoSitios BW/4HANA. Los
escenarios mixtos son posibles y se explicarán más adelante en esta unidad.

126 © Copyright. Reservados todos los derechos.

 Lección: Asignación y transformación de datos

Figura 101: Integración de datos: Separación de fuentes por rangos de números

Supongamos que carga valores de dos fuentes en la misma tabla de almacén de datos y que
cada registro tiene un identificador de pedido único (ID) dentro de su fuente. Desea evitar
sobrescribir un pedido de cliente de una fuente con el pedido de cliente de la otra fuente. Por
lo tanto, debe asegurarse de que los valores clave en el almacén de datos sean diferentes si
los pedidos provienen de diferentes fuentes.
Almacenar claves separadas para fuentes de aprovisionamiento separadas tiene las
siguientes ventajas:
● Independientemente de la fuente que se cargue primero, los datos integrados resultantes
en el almacén de datos son los mismos.
● Puede modelar los datos integrados como la unión de las fuentes.

Las claves de separación se pueden conseguir de las siguientes maneras:

● Rangos de números
● Claves compuestas
● Claves concatenadas

El enfoque de rango de números consiste en separar los posibles valores clave en las fuentes.
Si puede diseñar el proceso de generación de valores clave en las fuentes, defina rangos de
números diferentes que no se solapen para cada fuente. Asegúrese de que cada fuente solo
crea valores clave de su propio rango de números. A continuación, puede tomar los valores de
ID tal como están en el almacén de datos.
Tener los mismos ID en el almacén de datos y en el sistema de origen tiene las siguientes
ventajas:
● No se requiere transformación.
● Los informes creados en el almacén de datos y los informes creados en el sistema de
origen muestran los mismos valores de ID.

© Copyright. Reservados todos los derechos. 127

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

● Es más fácil identificar las entradas correspondientes en la fuente cuando se investiga un

pedido específico.
● Es posible unir tablas de la fuente con tablas de almacén de datos.

Incluso si no tiene control sobre los rangos de números, verifique si las fuentes ya
proporcionan conjuntos disjuntos de identificadores. Por ejemplo, los pedidos de cliente y los
pedidos se toman de diferentes rangos de números en la mayoría de las aplicaciones SAP.
Además, observe los formatos de los campos. No puede haber solapamientos si todos los
números de ID son valores puramente numéricos en una fuente y cada ID empieza por dos
letras en la segunda fuente. Verifique qué reglas se aplican para generar los valores de ID. Por
ejemplo, los números de matrícula tienen formatos diferentes en diferentes países. Verifique
si las reglas para la generación de valores clave en combinación con el formato de campo
garantizan conjuntos de valores que no se solapan. Imagine, por ejemplo, la siguiente
situación: en una fuente, los números de orden de 10 dígitos empiezan por 1, y en la otra
fuente, los números de orden de 13 dígitos empiezan por 1. Serán diferentes.
Tenga en cuenta que algunos rangos parecen ser diferentes, pero de hecho tienen
solapamientos. Si la clave es la fecha y las fuentes corresponden a diferentes años,
normalmente no hay solapamiento. Sin embargo, si se escribe un valor para el 31 de
diciembre de 2016 en el almacenamiento de 2016 durante el día, y el 1 de enero de 2017, se
escribe un valor actualizado para el 31 de diciembre en el almacenamiento del nuevo año, y la
misma fecha (31 de diciembre de 2016) ocurre en ambas fuentes. Para evitar sobrescribir un
valor con el otro, debe crear una transformación que incluya información sobre la fuente en la
clave.

Figura 102: Integración de datos: Separación de fuentes por extensión de clave (composición)

El segundo método, Ampliación de clave (o Composición), muestra una forma diferente de

mantener separados los valores de diferentes fuentes.
Supongamos que el mismo valor clave original existe en diferentes fuentes, representando
diferentes entidades y desea diferenciarlas en el almacén de datos. La forma más fácil es
añadir un identificador de fuente a la clave. Este método tiene las siguientes ventajas:

128 © Copyright. Reservados todos los derechos.

 Lección: Asignación y transformación de datos

● Puede identificar fácilmente de qué fuente proviene un registro.

● Los registros de diferentes fuentes permanecen separados.
● La transformación necesaria es simple: el ID de orden se asigna 1:1 desde las fuentes y se
genera un ID de fuente como valor constante.
● Es fácil filtrar por un número de orden original o fuente.
● SAP BW4/HANA proporciona un concepto técnico llamado relación de características en
la definición de InfoObjeto para este método.

Relacionar el ID de origen con la clave original tiene las siguientes desventajas:

● La transformación debe realizarse de la misma manera para todos los procesos o vistas de
carga (datos maestros y datos de transacción).
● Para comprender los datos, el usuario empresarial debe comprender el concepto de una
clave combinada.
● Para evitar una agregación incorrecta, la fuente de campo debe incluirse en todos los
objetos que contengan la orden.
● Se deben modelar más campos.
● Las combinaciones incorrectas de filtros para la fuente y la orden llevan a un conjunto de
resultados vacío.

La relación de características de característica de SAP BW4/HANA soporta este método.

Figura 103: Integración de datos: Separación de fuentes por concatenación

El tercer método, que separa las fuentes mediante concatenación, significa que los primeros
caracteres de la clave de orden de almacén de datos se toman de un ID para la fuente, y los
últimos caracteres de la clave de orden original, y juntos forman un único campo clave.
El concepto de concatenación tiene las siguientes desventajas:
● Debe implementar transformaciones más complejas, que impliquen una fórmula o un
programa.
● Necesita una selección de rango para filtrar la fuente.

El concepto de concatenación tiene las siguientes ventajas:

● Un campo es suficiente para distinguir diferentes órdenes en el informe.

© Copyright. Reservados todos los derechos. 129

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

● Si se debe incluir otro campo en la clave, modifique la transformación y vuelva a cargar los
valores. Los objetos no se modifican.
● Si esta concatenación no es necesaria para un sistema fuente específico, puede verificar la
fuente en la codificación de fórmula o de programa.

Puede utilizar una rutina de transferencia global para la característica SAP BW/4HANA para
implementar el enfoque de concatenación.

Figura 104: Integración de datos: Armonización de contenido

El número de empresas que utilizan BW/4HANA para armonizar datos, especialmente datos
maestros, de fuentes heterogéneas está creciendo.
Imagine que el mismo proveedor está representado en diferentes fuentes con diferentes
valores clave. ¿Qué valor debe ser válido en el almacén de datos?
Otro problema es el problema de la mala calidad de los datos en la fuente. Debido a errores en
la fuente, puede haber diferentes entradas para la misma entidad dentro de una fuente.
Tenga en cuenta el siguiente ejemplo. Un empleado de su organización de compras introduce
un texto incorrecto para un proveedor. Más tarde, un colega desea comprar mercancías del
mismo proveedor, busca este proveedor y no encuentra una entrada. A continuación, crean
una nueva entrada (con el texto correcto).
En la aplicación BW/4HANA, para tener una representación única y consistente de cada
proveedor, desea asignar los diferentes valores clave originales a la misma clave nueva.
Además, desea corregir textos erróneos.
¿Cómo se pueden identificar y corregir los valores de diferentes fuentes?
Para empezar, realice una armonización técnica. Si un campo de una fuente tiene una
longitud menor o un tipo de datos más restrictivo que el campo correspondiente en otra
fuente, busque el tipo de datos más general que puede contener todos los valores. Por
ejemplo, si una fuente tiene un campo NUMC(10) con hasta 10 dígitos, y la otra fuente tiene
un campo NUMC(13) con hasta 13 dígitos, seleccione al menos NUMC(13). Si una fuente tiene
un campo NUMC(10) con 10 dígitos y el campo correspondiente de la otra fuente es
CHAR(10) con 10 letras, seleccione CHAR(10).

130 © Copyright. Reservados todos los derechos.

 Lección: Asignación y transformación de datos

Una tabla de asignación es una tabla que contiene los valores clave nuevos correspondientes
para cada valor clave original y fuente. Para el formato clave original, utilice el formato más
general que se reconoce durante la armonización técnica.
Por motivos de rendimiento, recomendamos utilizar un aDSO en SAP BW4/HANA para
almacenar la tabla de asignación. A continuación, puede utilizar una regla de transformación
leída del objeto DataStore (avanzado) en lugar de una rutina para derivar los nuevos valores
clave. Este método de transformación se puede realizar rápidamente en la memoria de SAP
HANA.
Almacene la nueva clave derivada en las tablas de datos maestros de SAP BW4/HANA. Si los
valores clave originales aún son necesarios, simplemente añada la Nueva clave como atributo
del proveedor original. Si no es necesario visualizar o utilizar los valores originales, utilice la
clave nueva en lugar de la clave original. Entonces solo queda un registro por clave nueva, lo
que reduce el número de entradas de datos maestros y hace que las tablas de datos
maestros sean mucho más pequeñas.
Generación de datos transaccionales armonizados.
Utilice la misma tabla de asignación para armonizar datos transaccionales. Puede verificar la
integridad de referencia. Esto significa que si no existe ninguna entrada coincidente en la
tabla de asignación, se genera un mensaje de error. Como alternativa, puede generar un
workflow. Un usuario empresarial (o un programa inteligente) verifica si este valor se puede
identificar con una clave nueva existente o si se debe generar otra clave nueva.
Supongamos que espera solo un valor para una entidad, por ejemplo, el tipo de valor siempre
debería ser Datos reales, o la unidad de medida siempre debería ser unidades, pero el campo
fuente está vacío o no existe. Entonces, no necesita una tabla de asignación con una entrada.
Simplemente rellene un campo de este tipo con un valor constante. Es posible que desee
generar un error cuando aparezca un valor diferente en la fuente.
En un escenario de valor predeterminado, puede combinar una tabla de asignación y una
constante. Primero, verifique si una entrada coincidente para un registro determinado
aparece en la tabla de asignación. Si no es así, seleccione siempre el mismo valor por defecto.
Un valor estándar típico serían otros.

Figura 105: Tarea de modelado: Armonización de datos transaccionales

© Copyright. Reservados todos los derechos. 131

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

¿Cómo pueden resolverse otras cuestiones de armonización?

En este ejemplo, los registros de origen contienen importes en diferentes monedas e
información adicional diferente. En el ejemplo, la fuente A contiene números de orden, pero la
fuente B no. Para crear una estructura de tabla compatible en BW/4HANA central, a nivel
global, se necesitan varias tareas de armonización:
● Generar números de pedido para fuente B o almacenar el total para cada proveedor
● Asegúrese de que los números de orden en la tabla central son diferentes cuando los
números de orden se toman de diferentes fuentes.
● Utilice una tabla de asignación para asignar el ID de proveedor a una clave de proveedor
global de BW/4HANA.
● La fuente B enumera la información sobre los países, pero no la información fiscal. Existe
una tabla de datos maestros de país a partir de la cual se pueden derivar la moneda y el
tipo impositivo. Unir estas dos tablas para encontrar el tipo impositivo.
● Calcule el valor imponible absoluto.
● Convierta todos los valores diferentes a USD (USD $).
● Estandarice el formato de número ya que es diferente.

Dependiendo del enfoque de modelado para este escenario, estas tareas se realizan
utilizando transformaciones de SAP BW/4HANA o en SAP HANA, mediante vistas de cálculo.

Figura 106: Mejores prácticas: combinar dos fuentes en una

¿Qué objetos se necesitan para integrar datos de diferentes fuentes? Depende de la

complejidad y del enfoque de modelado (SAP BW/4HANA, con o sin destino persistente, o
SAP HANA con vistas virtuales o un escenario mixto). Intente modelar la menor cantidad
posible de capas físicas utilizando Proveedores compuestos, InfoFuentes y Vistas de cálculo
de SAP HANA para combinar datos:

132 © Copyright. Reservados todos los derechos.

 Lección: Asignación y transformación de datos

En escenarios simples, si ambas fuentes tienen un campo común y el formato y los valores ya
coinciden, una combinación se puede realizar directamente sin transformación. Con SAP
HANA como base de datos, las combinaciones se pueden ejecutar en memoria siempre que
sea necesario. Si los valores originales permanecen disponibles, no es necesario guardar el
resultado de la combinación de forma permanente.
Imagine, por ejemplo, que una tabla de datos maestros y una tabla de texto utilizan la misma
clave técnica. Las combinaciones se pueden definir como uniones de base de datos simples o
de las siguientes maneras diferentes mediante las funciones de SAP BW4/HANA o SAP
HANA:
● Una vista de cálculo nativa de SAP HANA puede contener joins internos, externos,
referenciales, temporales y de texto. Para obtener más detalles, consulte unidades
posteriores.
● Una vista Open ODS se puede asociar a otra vista ODS, especialmente cuando se impone
la integridad referencial, por ejemplo para combinar atributos y textos.
● Un CompositeProvider (CP) puede contener joins internos y externos.

En diferentes escenarios, las fuentes no suministran todos los campos en el formato o con los
datos necesarios para el join. En estos casos, combine las transformaciones con un join.
Averigüe qué transformaciones son específicas de una de las fuentes (transformaciones
específicas de fuente) y qué transformaciones son válidas para todas las fuentes
(transformaciones independientes de fuente).
Para los siguientes ejemplos, utilice transformaciones específicas de fuente:
● Armonización de formato: los identificadores de suministrador tienen 10 caracteres en una
fuente y 13 dígitos en la otra fuente, y deben ampliarse a un formato común de 13
caracteres.
● Ampliación de clave: en el contexto de la relación de características de SAP BW4/HANA,
añada el sistema fuente específico como una constante.
● Derivación de valores que faltan: Supongamos que una fuente entrega la tasa de impuesto
y el importe neto, y la otra fuente entrega el importe del impuesto. A continuación, el
cálculo del importe del impuesto solo es necesario para una fuente.
● Aplicación de tablas de asignación específicas de fuente: Supongamos que los valores de
proveedor de una fuente se toman como la nueva clave. Entonces, la asignación solo es
necesaria para valores de proveedor originales de la otra fuente.

En los siguientes casos, utilice transformaciones independientes de fuente:

● Aplicación de tablas de asignación: desde una tabla de asignación común, lea el valor
armonizado de SAP BW4/HANA que corresponde a la combinación de ID de fuente e ID de
proveedor original.
● Conversión de moneda: utilice la misma tecnología para convertir diferentes monedas a la
misma moneda común, como Euro.
● Fórmulas matemáticas comunes: si ambas fuentes contienen el importe neto y el importe
del impuesto, calcule el importe bruto.

Cuando necesite generar valores armonizados fiables, almacene el resultado de estas

transformaciones de forma permanente (consulte la parte central de la figura).
Recomendamos implementar un flujo de datos BW con una InfoFuente como capa intermedia

© Copyright. Reservados todos los derechos. 133

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

no persistente y un aDSO como almacenamiento persistente del resultado. Dividir

transformaciones de forma que no tenga que crear la misma transformación dos veces.
Implemente las partes específicas de fuente de la transformación antes de la InfoFuente. Si
hay partes de transformaciones que son independientes de la fuente, se pueden implementar
entre la InfoFuente y el destino.
Utilice la jerarquía de las vistas de cálculo cuando necesite informar en tiempo real sobre
valores armonizados (consulte la parte derecha de la figura) y el resultado no tenga que
grabarse de forma permanente. De forma similar, las fórmulas específicas de origen se
pueden implementar en la primera capa, y las fórmulas independientes de origen en una capa
de nivel superior. Al final, se puede realizar una unión o un join en un proveedor compuesto.
Si no está seguro de qué escenario elegir, seleccione las opciones más flexibles con
transformaciones.

Figura 107: Resumen: Tareas de integración

Ha visto diferentes técnicas para integrar datos de diferentes fuentes. En la imagen "Tareas
de integración de resumen" se enumeran los métodos que se pueden aplicar a las diferentes
tareas.
Primero, busque los campos originales correspondientes para cada entidad y compare los
formatos de estos campos. Determine un formato común que sea lo suficientemente general
como para contener todos los valores diferentes. Considere el futuro.
En segundo lugar, distinga diferentes objetos de diferentes fuentes. Si no hay identificadores
disponibles, genere nuevos valores dentro de un rango de números específico de fuente en
una transformación específica de fuente. Si se pueden suministrar objetos diferentes con la
misma clave original, amplíe la clave a una clave combinada de valor original y fuente. Como
alternativa, puede concatenar la fuente y la clave original en un campo clave largo. Si está
seguro de que ahora y en el futuro, las fuentes ya entregan valores diferentes, no es necesaria
ninguna transformación para este paso.
Por último, armonice diferentes valores que representen el mismo objeto en un identificador
SAP BW4/HANA común. Si no se presenta ningún valor para una entidad con solo un objeto,

134 © Copyright. Reservados todos los derechos.

 Lección: Asignación y transformación de datos

añada una constante. Si existen valores diferentes, defina una tabla de asignación y lea el
identificador correspondiente desde allí.

Figura 108: Ejercicio: Leer valores de asignación de un ADSO

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Mapee y transforme datos

© Copyright. Reservados todos los derechos. 135

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

136 © Copyright. Reservados todos los derechos.

 Capítulo 4
Lección 5
Diseño de una arquitectura escalable en capas
de SAP BW/4HANA (LSA++)

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Diseñar una arquitectura escalable en capas con capas virtuales

Diseño de una arquitectura escalable en capas con capas virtuales

Escenario empresarial para LSA++

Figura 109: Escenario empresarial: LSA++

Los datos están disponibles desde diferentes fuentes, algunas de las cuales son archivos de
departamentos locales. Los requisitos de la explotación central y el negocio local son
diferentes. La retención central espera datos integrados. Los usuarios empresariales locales
necesitan cálculos individuales. En todos los niveles de integración, la generación de informes
en tiempo real debe ser posible. El diseño debe ser flexible y escalable.
Debe integrar datos paso a paso y generar diferentes versiones para diferentes usuarios
empresariales.

© Copyright. Reservados todos los derechos. 137

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Integración y adaptación de datos

Figura 110: Motivación: modelos globales armonizados y modelos locales individuales

Dos problemas de transformación de datos surgen en un almacén de datos: armonización de

datos de fuentes heterogéneas y transformaciones específicas del negocio para grupos
locales o subsidiarias.
Especialmente si las diferentes líneas de negocio tienen diferentes requisitos, recomendamos
generar un almacenamiento de datos central con datos estándar de toda la empresa (punto
único de verdad) de los que se pueden derivar diferentes versiones locales. En caso de
conflictos, los datos estándar de toda la empresa son el punto de referencia.
Por lo tanto, el departamento de TI de retención global desea definir un estándar para toda la
empresa. En el ejemplo de la imagen Motivación: modelos globales armonizados y modelos
locales individuales, el ID de proveedor debe asignarse a una nueva clave de proveedor global.
Todos los valores de importe se convierten a la moneda de retención USD. El formato de
número es estandarizado.
Las subsidiarias locales tienen requisitos diferentes. Según este pool de datos global, la
subsidiaria canadiense debe calcular el importe neto (importe excepto impuestos) y
reconvertir el total en dólares canadienses. La filial francesa desea convertir los valores a
euros y calcular el tipo impositivo medio.
Este es un requisito típico. Además de las transformaciones gestionadas centralmente para la
armonización y distribución de datos, los departamentos individuales controlan fuentes de
datos adicionales. ¿Cómo se pueden gestionar de forma coherente todos estos conjuntos de
datos diferentes? ¿Qué arquitectura recomienda SAP?

138 © Copyright. Reservados todos los derechos.

 Lección: Diseño de una arquitectura escalable en capas de SAP BW/4HANA (LSA++)

LSA++

Figura 111: Resumen de las capas LSA++

Un departamento local, como el francés, utiliza los datos armonizados en toda la empresa
como servicio. Esta idea se puede ampliar: Un modelo de datos bien estructurado consta de
diferentes capas, y cada capa proporciona sus datos como servicio para la siguiente capa. La
ventaja es que puede definir claramente qué equipo es responsable de cada servicio
(proporcionando una calidad específica de los datos). Cuando se establece una
infraestructura de datos central con alta calidad, es fácil generar nuevos conjuntos de datos
locales en esta base.
Esta ventaja de flexibilidad la representa SAP en la arquitectura escalable en capas
actualizada, LSA para SAP BW/4HANA o, en resumen, LSA++.
La figura, Resumen de las capas LSA++, presenta la idea principal de cada capa.
La adquisición de datos normalmente no es persistente para ahorrar costes de
almacenamiento. En su lugar, las vistas basadas en campos que hacen referencia a tablas
SAP HANA o vistas de cálculo están disponibles en SAP BW/4HANA, incluso para la gestión
de informes. La capa que contiene estas vistas se denomina Open Operational Data Store. El
objeto principal es la vista Open ODS, como alternativa, el aDSO basado en campo.
El almacenamiento persistente principal se denomina Flexible EDW Core. Es el
almacenamiento armonizado, consistente y estable. El objeto principal es el aDSO en sus
diversas formas.
Los InfoSitios del núcleo EDW flexible están diseñados para satisfacer todos los requisitos.
Para presentar una selección centrada con un nombre de InfoSitio específico, se introduce la
capa virtual. Una finalidad es combinar datos de diferentes InfoSitios con almacenamiento
físico. Sin almacenamiento adicional, puede definir una operación de unión, una conexión
externa o una conexión interna o simplemente una proyección, es decir, un subconjunto de
los campos, de los registros. Otra de las capas virtuales es la flexibilidad. Si modifica el
InfoSitio subyacente o lo sustituye por otro, las consultas creadas en la parte superior de la
capa virtual no se ven influenciadas. El objeto principal es el CompositeProvider.

© Copyright. Reservados todos los derechos. 139

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Basándose en estos InfoSitios, las consultas BW se establecen en una capa llamada capa de
consulta. El concepto de virtualización significa que todos los cálculos que son lo
suficientemente simples se definen en una consulta y son manejados por SAP HANA en cada
vez que se ejecuta la consulta. Para consultas complejas de ejecución lenta, se crean aDSO
separados en la capa EDW Core flexible como almacenamiento permanente.
La presentación de datos de forma imprimible o presentable es la tarea de la capa de
informes.
A veces, los datos externos son difíciles de armonizar e integrar en SAP BW/4HANA,
especialmente si hay modificaciones frecuentes que deben reflejarse inmediatamente. Luego,
la capa de data mart ágil le permite ampliar el modelo de datos con cálculos en SAP HANA. El
objeto principal es las vistas de cálculo nativas de SAP HANA.
Si los datos no están disponibles públicamente pero pertenecen a un departamento o usuario
específico, implemente un área de trabajo BW como una extensión ágil local. El objeto
principal es el proveedor compuesto local.
Para ambos escenarios ágiles, se puede hacer referencia a los datos del núcleo EDW flexible
(expuestos). La combinación con los datos locales se debe crear en el modelo local.

Nota:
Si ha migrado de BW en SAP HANA a SAP BW/4HANA, su arquitectura LSA
existente no está completamente obsoleta o incluso es superflua. Si se ciñe a
conceptos generales de la LSA, como las convenciones para fijar nombres, los
dominios y las capas, estará muy bien posicionado. Ahora depende de usted la
rapidez con la que incorpora las nuevas funciones proporcionadas por SAP HANA.

La capa Open Operational Data Store

Figura 112: LSA++: la capa Open Operational Data Store

La capa Operational Data Store es una capa de entrada que también ofrece servicios como
consultas e informes.

140 © Copyright. Reservados todos los derechos.

 Lección: Diseño de una arquitectura escalable en capas de SAP BW/4HANA (LSA++)

Combina las tareas de la capa de adquisición de datos, así como el Operational Data Store
(para la gestión de informes operativa) de la LSA clásica.
La tienda de datos operativa abierta cumple los siguientes requisitos:
● Staging inicial: desde aquí los datos se pueden cargar en EDW Core flexible y consistente y
se someten a verificaciones de calidad y armonizaciones.
● Generación de informes operativos: generación de informes en tiempo real en
transacciones OLTP sin más staging en EDW Core.
● Integración incremental: comience con la generación de informes en tiempo real y cargue
aquellos escenarios que deben modificarse, armonizarse o integrarse con otros
escenarios, ya que esta necesidad parece ser importante.

Las fuentes podrían tener cualquier estado de calidad posible: fuente operativa, almacén de
datos operativos, almacén de datos, centro de datos o fuente de lago de datos (Hadoop).
El estado de los datos externos prácticamente integrados solo puede reflejarse con la
clasificación de las vistas Open ODS, es decir, dándoles nombres claros y transparentes.
Modelado basado en campos
Al utilizar SAP HANA como plataforma, también es posible ofrecer más servicios en los datos
descritos por los campos de la capa de entrada. La intención es que los datos estén
disponibles en la semántica y sintaxis del sistema fuente. Los datos son de calidad a nivel de
origen, pero están disponibles para la gestión de informes, y las funciones se pueden realizar
directamente en los datos brutos de la fuente.
Para enfatizar el hecho de que LSA++ para SAP BW/4HANA incorpora una filosofía de
modelado basada en campos sin persistencia, se ha introducido el término Capa Open
Operational Data Store (capa Open ODS). Este enfoque se realiza utilizando la vista Open
ODS como InfoSitio de esta capa. Al igual que en las vistas de cálculo de SAP HANA, no se
necesitan InfoObjetos. De hecho, el motivo principal para implementar la capa es hacer que
las vistas y tablas de otros esquemas gestionados externamente estén disponibles para SAP
BW/4HANA.
Tenga en cuenta la siguiente recomendación al trabajar con la vista Open ODS en la capa
Open ODS:
● Generar vistas Open ODS como InfoSitios proxy con autorizaciones de SAP BW/4HANA
para vistas de cálculo de SAP HANA nuevas y existentes
● Consumir datos en lugar de moverlos.
● Utilice los datos brutos siempre que sea necesario.
● Evite crear datos maestros innecesarios, como una pura lista de números de orden
existentes.
● Para crear un almacén de datos virtual sin persistencia, defina asociaciones con otras
vistas Open ODS o InfoObjetos
● Transformar datos solo si aparecen valor: No es necesario utilizar InfoObjetos. La
asignación de campos a InfoObjetos solo se realiza si aporta información semántica o
características técnicas como atributos, relación o un concepto de autorización.

La vista Open ODS es el objeto central para la integración virtual de datos externos debido a
las siguientes ventajas:

© Copyright. Reservados todos los derechos. 141

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

● La accesibilidad de los datos externos: cada fuente accesible para SAP HANA es una
fuente potencial para una vista Open ODS. La vista Open ODS acepta vistas SQL, vistas
SAP HANA, tablas y tablas SAP HANA virtuales que representan una vista de BD remota o
una tabla remota (acceso a datos inteligentes de SAP HANA). No es necesaria ninguna
puesta a disposición.
● La posibilidad de asignar semántica. Toda la vista Open ODS se puede clasificar como
texto, datos maestros o datos transaccionales. Los campos se pueden clasificar como
característica, ratio, moneda, unidad, etc.
● La capacidad de modelar datos externos: las vistas Open ODS se pueden asociar con otras
vistas Open ODS. La asociación de vistas Open ODS de datos maestros con una vista Open
ODS de hecho produce un esquema estrella. Las asociaciones entre datos maestros y
textos son posibles para mejorar el esquema estrella con descripciones. Las vistas Open
ODS también se pueden asociar con InfoObjetos.
● La posibilidad de intercambiar estructuras fuente de forma flexible: Si las fuentes B tienen
los campos de la fuente A, puede reemplazar la fuente A sin afectar a las consultas que se
definen en la parte superior de la vista Open ODS. En este sentido, la ubicación de los
datos es irrelevante.
● La posibilidad de integrar los datos externos en SAP BW/4HANA: La fuente puede
sustituirse por un flujo de datos generado y un aDSO si los datos deben transferirse al
almacén de datos.

En resumen, los servicios de la capa Open ODS en el contexto de LSA++ para el

almacenamiento de datos simplificado se pueden clasificar de la siguiente manera:
● Servicio de capa de adquisición de datos (cuando se genera un flujo de datos desde una
vista Open ODS)
● Opción de consulta e informes inmediata con información estratégica en tiempo real
(cuando no se genera ningún mecanismo de staging)
● Integración temprana y simple de datos en el almacén de datos utilizando LSA++ para un
almacenamiento de datos simplificado (cuando las vistas Open ODS están asociando
otras)

142 © Copyright. Reservados todos los derechos.

 Lección: Diseño de una arquitectura escalable en capas de SAP BW/4HANA (LSA++)

Capa EDW central

Figura 113: LSA++ La capa de núcleo EDW flexible

La capa EDW principal consta de las siguientes tres capas persistentes:

● La capa de propagación de EDW: almacena resultados armonizados de transformaciones
gestionadas globalmente que se ejecutan en la capa de transformación EDW. El objeto
principal es aDSO.
● La capa de data marts con arquitectura: sus requisitos son definidos por los
departamentos locales o para aplicaciones específicas. El número de casos en los que es
necesario el almacenamiento físico se limita a los casos de transformaciones complejas
ejecutadas en la capa de transformación empresarial. En otros casos, la capa de data mart
virtual está directamente conectada a la capa de propagación EDW, y la capa de data
marts arquitectos se omite.
● Memoria corporativa: Al igual que el concepto de LSA, la memoria corporativa mantiene
información detallada de las fuentes, ya sea sin transformación, o con las
transformaciones de la capa de transformación EDW, dependiendo de qué versión sea un
punto de partida más adecuado para construir nuevos objetivos. Normalmente se utiliza
una memoria corporativa para garantizar la reproducibilidad del historial de
contabilización transaccional. Esto también es posible para los datos maestros, por
supuesto. Dado que los datos en la capa de memoria corporativa se almacenan con
cronomarcadores, su aptitud para el reporting es limitada.
● Cómo y hasta qué punto los datos se almacenan físicamente en el almacén de datos se
determina mediante factores como si los datos deberían ser reproducibles y si se requiere
un reporting "veraz". Considerar almacenamiento nearline para datos antiguos.

En SAP BW/4HANA en SAP HANA, con almacenamiento y agregación basados en columnas

dentro de la memoria, la generación de informes en aDSOs (independientemente del tamaño
y el tipo) se puede realizar sin desventajas. Los requisitos de informes se pueden realizar
directamente en la primera capa con datos armonizados globales, la capa de propagación
EDW. Si las otras capas se utilizan principalmente para optimizar el rendimiento, con SAP
HANA se minimiza su importancia. Por ejemplo, no es necesario almacenar información que

© Copyright. Reservados todos los derechos. 143

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

actualmente no se evalúa en un aDSO de memoria corporativa aparte si almacenarlos junto

con los valores necesarios en un aDSO estándar aún conduce a un comportamiento de
tiempo de ejecución aceptable. A continuación, los servicios de ambas capas se pueden
combinar en una capa.
Esto lleva al concepto de una capa EDW central. EDW Core incluye todas las capas que
contienen los datos de forma consolidada y armonizada. Esto significa que los datos están
disponibles en una calidad definida como estándar de SAP BW/4HANA. Su contenido es
similar a la capa de propagación de datos del concepto clásico de LSA, pero en contraste con
la capa de propagación de datos de LSA que no está pensada como base para la generación
de informes en LSA clásica, la capa EDW de núcleo es la capa central para los informes. Al
mismo tiempo, sirve como el único punto confiable de la verdad en toda la corporación.
Sin embargo, en algunos casos la diferenciación sigue siendo útil. Las capas se presentarán
ahora con más detalle.
La capa de propagación EDW
La capa de propagación EDW es el proveedor de datos primario para los informes. Almacena
los detalles de forma armonizada, depurada y consolidada. Consiste principalmente en
objetos DataStore estándar. Durante el proceso de activación de la cola de datos nuevos, se
eliminan los duplicados. Sin SAP HANA, la tarea principal de esta capa era proporcionar un
mecanismo delta (como antes y después de las imágenes) para destinos optimizados para un
tiempo de ejecución de reporting más corto.
La ventaja de LSA++ es guardar solo los datos persistentes una vez (o dos veces cuando sea
realmente necesario, en todos los sistemas fuente)
La capa EDW central es una solución flexible y escalable que admite grandes volúmenes de
datos.
Es posible integrar procesos ETL, acceso en tiempo real, datos maestros almacenados y
virtuales.
La capa de transformación EDW
El grado de armonización de los requisitos en términos de semántica y valores
estandarizados y de criterios de consistencia varía de un cliente a otro. Esto también se aplica
al alcance y la complejidad de las transformaciones de datos necesarias. Esto depende de
cómo se utiliza el almacén de datos:
● Si el almacén de datos está dominado por otro sistema fuente, es decir, que la mayoría o
todos los valores y semánticos se toman de este sistema fuente, se realizan muy pocas
transformaciones de datos para estos datos del sistema fuente como norma. Esto se
conoce como almacén de datos de dominio.
● Si el almacén de datos tiene que armonizar una gran cantidad de fuentes equivalentes, se
realizará una cantidad significativa de transformaciones de datos y modelos. Este es un
almacén de datos empresariales (EDM) clásico.

En la LSA, la capa de armonización a menudo se representa explícitamente como la capa de

preparación para los objetos en la capa de propagación. Para que sean más fáciles de
entender, las tareas y los objetivos de armonización en la capa de propagación se explican en
detalle.
Cuando cree un aDSO y no haya más destinos que se completen desde este aDSO, evite crear
las entradas del log de modificaciones desmarcando la propiedad aDSO correspondiente.

144 © Copyright. Reservados todos los derechos.

 Lección: Diseño de una arquitectura escalable en capas de SAP BW/4HANA (LSA++)

Figura 114: Capa de transformación EDW (armonización) con y sin ADSO

En la imagen Capa de transformación EDW (armonización) con y sin un ADSO, se encuentran

diferentes enfoques para realizar la armonización de datos. En casos simples, las reglas de
transformación se pueden implementar directamente entre InfoSitios. En otros casos, utilice
las InfoFuentes para dividir, combinar y apilar la lógica de transformación utilizando
InfoFuentes para garantizar la actualización de los flujos de datos y la flexibilidad general.
En algunos escenarios, necesita todos los datos de una o varias fuentes para un paso
específico de destino. A continuación, sustituya la InfoFuente por un aDSO. Sin embargo,
para ahorrar costes de almacenamiento, elimine su contenido si se ha actualizado
correctamente en todos los destinos. Este escenario se denomina escenario de transferencia:
todos los registros pasan el aDSO de transferencia pero no se almacenan durante mucho
tiempo. Si necesita un almacenamiento persistente de datos detallados, cree una memoria
corporativa independiente. Si el llenado utiliza una gran cantidad de recursos del sistema,
puede ser útil recopilar cargas diarias en el aDSO de transferencia durante una semana y
rellenar la memoria corporativa el fin de semana.
Data Marts con arquitectura
Architected data mart es un término de la industria para un repositorio de datos, diseñado
para servir a una comunidad particular de trabajadores de la información mediante la
formación de una base para la generación de informes. En el contexto de LSA++, significa que
el diseño no está determinado por el equipo global de almacenamiento de datos
empresariales, sino por departamentos o grupos locales.
La capa arquitectónica data mart sirve como una capa de acceso de consulta si la capa EDW
Propagation no puede cumplir ciertos requisitos de negocio. Solo en casos muy raros, puede
ser útil almacenar los resultados en esta capa por motivos de rendimiento puro.
Persistent Architected Data Marts se definen en base a aDSOs (objetos DataStore
(avanzados)) e InfoObjetos.

© Copyright. Reservados todos los derechos. 145

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Existen perfiles especiales para un aDSO en la capa data mart con arquitectura (capa de
reporting). Normalmente, se requieren consultas de autoservicio con combinaciones libres de
filtros y características de desglose. Por lo tanto, utilice el perfil con la opción "Todas las
características son clave" (aDSO multidimensional o similar al cubo). Sin esta
parametrización, modificar el conjunto de características contenido en el aDSO significa que
la clave debe ajustarse. Con esta parametrización, el sistema utiliza la clave nueva
correspondiente.
Transformaciones empresariales
Los datos se transforman o combinan según la lógica empresarial. Los datos de la capa
anterior (capa de propagación EDW) no se deben transformar según la lógica empresarial
para garantizar que los datos se puedan utilizar en otros escenarios.
Verifique si los requisitos pueden cumplirse mediante una secuencia de uniones o joins, o
mediante una secuencia de fórmulas. A continuación, mueva esta lógica a la capa de data
mart virtual o a la consulta BW. En la mayoría de los casos, estas transformaciones requieren
cierta programación.
Memoria corporativa para historial de transacciones
Una regla de modelación general indica que conserva el historial completo de todos los datos
cargados en al menos una capa de memoria corporativa. Se puede utilizar como fuente para
reconstrucciones, sin necesidad de acceder de nuevo a las fuentes. Los datos se almacenan
en aDSO con el perfil de modelo correspondiente.
Numerosos documentos de transacción (por ejemplo, para pedidos de cliente) se pueden
modificar una vez creados. Si aplica esta regla, se debe guardar un registro de todos estos
cambios en la capa EDW. Para grabar los costes de almacenaje, verifique si es suficiente
grabar los datos de transacción más recientes para el reporting táctico o estratégico.
Esta capa se utiliza:
● Si se pierden datos de SAP BW/4HANA y es necesario recuperarlos de forma
estandarizada, especialmente
- si el tiempo de inactividad del sistema fuente operativo para la recuperación
(inicialización) no es aceptable
- si los datos ya se han modificado o archivado en el sistema fuente.
● Si los nuevos requisitos de data mart requieren acceso a valores detallados que no se
almacenan de otro modo.
● Si se debe almacenar más información de la requerida originalmente.
● Si desea que los datos brutos estén disponibles como servicio.

Normalmente, esta capa se realiza mediante un aDSO optimizado para la escritura (un aDSO
sin activación). Se recomienda utilizar un almacenamiento cerca de la línea (NLS) con un
medio de almacenamiento barato para una memoria corporativa. Todavía es posible extraer
registros del NLS y cargarlos en destinos subsiguientes.

146 © Copyright. Reservados todos los derechos.

 Lección: Diseño de una arquitectura escalable en capas de SAP BW/4HANA (LSA++)

Criterios de decisión sobre el uso de proveedor compuesto

Figura 115: LSA++: La capa data mart

Verifique hasta qué punto es necesario mantener las capas de forma persistente en su
arquitectura de Enterprise Data Warehouse. ¿Realmente necesita un aDSO separado para la
capa de data mart de arquitectura?
Dos parámetros son decisivos: La complejidad de las transformaciones entre la capa de
propagación EDW y la capa de data marts (eje horizontal), y la tasa de compresión, es decir,
el número de registros almacenados en la capa EDW dividido por el número de registros
necesarios en la capa data mart (eje vertical). Por ejemplo, si la capa EDW contiene
1.000.000 registros y la capa data mart 100.000 registros, la tasa de compresión es baja
(10). Sin embargo, si la capa EDW contiene 100.000.000 registros y la capa data mart 10.000
registros, la tasa de compresión es alta (10.000).
En algunos casos, especialmente si la tasa de compresión es baja y los InfoObjetos se asignan
1:1 (sin lógica de transformación), puede ser posible utilizar una capa virtual (Composite
Provider) en lugar de aDSO, ahorrando así volumen de datos, rendimiento de carga y,
finalmente, costes. No es necesario que haya InfoSitios separados que sean puros
aceleradores de agregaciones previas para los datos, sino en un modelo de datos diferente.
Si la transformación es compleja y la tasa de compresión es alta, se recomienda un nuevo
almacenamiento físico de datos como objetos DataStore separados.
Si la lógica de transformación empresarial no es 1:1 pero en realidad no es muy compleja, por
ejemplo, si está implicado un join o un cálculo matemático, investigue si puede mover esta
lógica a la capa de reporting (es decir, consulta BW) o a las transformaciones de la capa de
armonización. Verifique si la mejora del tiempo de ejecución justifica los costes de
almacenaje.
Como recomendación práctica, primero intente satisfacer los requisitos basados en la capa
de propagación y la capa de data mart virtual. Una capa de data mart con arquitectura
persistente solo se crea si el nivel de servicio o los requisitos empresariales no se pueden
cumplir en la capa de propagación, como:

© Copyright. Reservados todos los derechos. 147

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

● Los valores deben convertirse y el resultado de la conversión debe ser un valor no

modificado fiable, pero el factor de conversión es volátil.
● La transformación utiliza un programa que depende de los valores que pueden cambiar.
● La transformación busca datos a los que solo se puede acceder en determinados
momentos.
● El resultado debe ser una instantánea.
● Se debe procesar una selección compleja de varios InfoSitios de la capa de propagación
● La transformación debe almacenar y leer valores repetidamente. (Una fórmula de consulta
no puede almacenar valores repetidamente.)
● La transformación es compleja y su ejecución sobre la marcha lleva a un tiempo de
ejecución de reporting inaceptable.

La capa de data mart virtual

Figura 116: LSA++La capa virtual de data mart

¿Cuál es el objetivo de la capa de data mart virtual?

Los objetos de la capa Virtual Data Mart actúan como una interfaz para consultas e informes.
Puede seleccionar qué campos (InfoObjetos) están disponibles en el diseño de query,
agruparlos y definir sus propiedades de visualización por defecto.
La capa de data mart virtual en LSA++ le permite combinar InfoSitios persistentes y
proveedores virtuales a partir de datos ágiles y operativos con datos maestros persistentes o
virtuales. Se pueden combinar diferentes InfoSitios de cualquier tipo mediante la operación
Uniones o Unión. Las capas no representan límites estrictos. Esto significa que es posible
combinar objetos de la capa ODS abierta con objetos de la capa de propagación o la capa
data mart con arquitectura. Sin embargo, cada modelador es exclusivamente responsable de
la viabilidad en cada caso.

148 © Copyright. Reservados todos los derechos.

 Lección: Diseño de una arquitectura escalable en capas de SAP BW/4HANA (LSA++)

Los objetos de la capa virtual data mart son el CompositeProvider y, a veces, la vista Open
ODS (especialmente en combinación con data marts ágiles).

Figura 117: LSA++: Estructuración de capa de data mart virtual

La capa virtual consta de dos sublayers: la capa de envoltura (virtual) y la capa de

composición (virtual).
SAP recomienda incluir un objeto de la capa de data mart virtual, normalmente
CompositeProvider, en la parte superior de cada InfoSitio que sea una base para el reporting.
Esta técnica a veces se conoce como "Envoltura del InfoSitio físico", y los proveedores
compuestos simples correspondientes forman la capa de ajuste.
Esta capa de ajuste se recomienda por los siguientes motivos:
● Asociación de datos maestros: Asocie InfoObjects a campos de modelos ágiles u
operativos. Esto incluye la asociación implícita de datos maestros y textos.
● Mejora de los datos maestros: si necesita atributos de navegación, añádalos en la capa de
ajuste. Si un atributo de navegación debe estar disponible en un nivel superior, debe estar
activado en el InfoObjeto y en el objeto Ajustar capa.
● Flexibilidad: si necesita intercambiar el InfoSitio físico a continuación, simplemente
sustituya el proveedor de piezas. O, si necesita modificar las asignaciones de un
InfoObjeto, no aplique esta modificación en el CompositeProvider y todos los queries BW
pueden permanecer inalterados.

Para combinaciones (uniones o joins) de diferentes InfoSitios, se introduce otra capa de

CompositeProviders, la capa de composición.
Un InfoSitio de capa de composición está diseñado para una solución de reporting específica.
● Defina la condición de conexión, como un left outer join de una vista de datos maestros de
producto y datos de ventas almacenados para ver todos los productos que no se han
vendido.
● (De nuevo) asigne diferentes campos o InfoObjetos de tipo de datos compatible. Deje los
detalles que no deberían estar disponibles.
● Modifique las propiedades de visualización, como los campos.

© Copyright. Reservados todos los derechos. 149

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Figura 118: LSA++: Proveedor compuesto

¿Cuáles son las posibilidades técnicas de un CompositeProvider? Un proveedor compuesto

puede combinar unión y join. La combinación puede ser una conexión interna o externa. La
unión debe ejecutarse antes de la unión. Como proveedores de parte, se pueden utilizar las
vistas de cálculo de SAP HANA y los InfoSitios de SAP BW/4HANA. El proveedor compuesto
se utiliza para presentar los campos o InfoObjetos de los proveedores de parte subyacentes a
un cliente BI o query. Si se combinan tablas físicas, se puede utilizar como fuente para la
extracción posterior. No todos los campos deben estar asignados. Si se aplica un join, la
condición de join se puede definir en función de uno o más pares de campos con un formato
compatible.
Incluso es posible anidar un proveedor compuesto en otro, pero se aplican restricciones
similares en la secuencia de uniones y uniones.
Centros de datos ágiles

150 © Copyright. Reservados todos los derechos.

 Lección: Diseño de una arquitectura escalable en capas de SAP BW/4HANA (LSA++)

Figura 119: LSA++ Agile Data Marts

Hasta el momento, todas las capas se operan con la tecnología SAP BW/4HANA. En SAP
BW/4HANA, existe acceso virtual a una fuente remota o se calculan valores en SAP BW/
4HANA a partir de valores programados estandarizados. Hasta ahora, para responder
preguntas urgentes sobre la situación actual, debe poner estrés en el sistema fuente o debe
trabajar con valores de la última carga de datos correcta.
Con SAP BW/4HANA, los data marts ágiles proporcionan información necesaria para
responder a corto plazo a los requisitos empresariales. Están diseñados específicamente
para los siguientes casos de utilización:
● Soluciones productivas de una sola vez
● Un prototipo productivo

El modelo consiste en un mecanismo para replicar datos de cualquier fuente a SAP HANA, y
modelos nativos de SAP HANA (vistas de cálculo) basados en estos datos en tiempo real, y un
método para exponer las vistas a SAP BW/4HANA, normalmente proveedores compuestos
como capa de ajuste virtual.
En situaciones en las que se necesitan reacciones inmediatas a un mundo cambiante, un
centro de datos ágil es mejor que un EDW inflexible. Sin data marts. Apenas podemos evitar
fusionar datos de estabilidad diferente en InfoSitios persistentes, por ejemplo, si queremos
añadir valores en tiempo real a los valores armonizados o si no podemos verificar la
integridad referencial de los nuevos registros transaccionales porque los datos maestros
nuevos correspondientes aún no se han cargado.
Conectar incluso los datos transaccionales consolidados existentes con InfoObjetos puede
causar un gran impacto en la estabilidad de los Data Marts con arquitectura resultantes.
Una solución son centros de datos ágiles. Los data marts con arquitectura permanecen en
SAP BW/4HANA con datos consolidados y todas las verificaciones de referencia. Los datos
nuevos se replican inmediatamente en una tabla SAP HANA en un esquema externo.
La conexión entre los datos consolidados de SAP BW/4HANA y los datos en tiempo real se
realiza en una vista de SAP HANA con menos consolidación. La idea es proporcionar una
respuesta única sin complicada integración de datos. Como ventaja, puede ver y reaccionar

© Copyright. Reservados todos los derechos. 151

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

inmediatamente a la modificación de datos. Como desventaja, el resultado no es

reproducible.
Desde una perspectiva funcional, un centro de datos ágil es un tipo de centro de datos que
ofrece análisis e informes sobre los datos adquiridos de un sistema transaccional. Los data
marts ágiles que se utilizan en SAP HANA ofrecen ventajas de flexibilidad en comparación con
la implementación de data marts con arquitectura en el contexto de un Enterprise Data
Warehouse.

Figura 120: LSA++: Arquitectura ágil de Data Marts

Si desea calcular la diferencia entre los costes plan almacenados y una previsión de los costes
reales que se pueden calcular con las funciones nativas de SAP HANA, debe exponer sus
datos almacenados a un modelo de datos virtual. Siempre que desee proporcionar valores de
forma flexible en tiempo real siempre que se necesiten, tenemos un escenario de datos ágil.
La imagen, Agile Data Marts Architecture, muestra los componentes de data marts ágiles.
Estos son los pasos para crearlo:

1. Poner los datos a disposición en SAP HANA.

La fuente puede ser un sistema SAP o no SAP. Puede conceder acceso virtual o generar,
cargar o replicar datos en un esquema SAP HANA externo. (Las diferentes herramientas
de importación y reproducción se describen en la clase BW450.) Utilice la tecnología Open
Hub para exportar datos de otro BW o BW/4HANA a SAP HANA. Si los datos se han
cargado en su propio BW/4HANA, no tiene que duplicarlos. Puede simplemente
exponerlo generando una vista SAP HANA externa. Estas vistas de cálculo son referencias
a las tablas del InfoSitio o consulta de SAP BW/4HANA.

2. Diseñe manualmente otra vista de SAP HANA que consuma campos de las tablas o vistas
básicas de SAP HANA.
Para generar una visión profunda de la situación real en tiempo real e integrar datos de
diferentes esquemas de SAP HANA, utilice una secuencia de vistas de cálculo en SAP
HANA. Con SAP HANA Modeling, puede implementar subcapas y transformaciones
similares a Core EDW, pero sin persistencia como almacén de datos virtual.

152 © Copyright. Reservados todos los derechos.

 Lección: Diseño de una arquitectura escalable en capas de SAP BW/4HANA (LSA++)

3. Consumir la vista SAP HANA.

El resultado se puede consumir directamente con las herramientas de cliente BI. El
usuario requiere autorizaciones de SAP HANA. Si desea utilizar el concepto de
autorización de SAP BW/4HANA, la vista se puede consumir con un proveedor
compuesto y una consulta BW.
Los modelos nativos de SAP HANA apenas son flexibles en términos de modificación del
método de cálculo. Si se necesita más flexibilidad, en el último paso, modifique la fórmula
y calcule conjuntos más grandes de valores más detallados. Siempre que sea posible,
vuelva a consumir los modelos en SAP BW/4HANA utilizando openODSview o
CompositeProvider.

¿Cuándo necesita data marts ágiles?

Como recomendación para juzgar la necesidad de mercados de datos ágiles, primero intente
implementar los requisitos utilizando los conceptos de Core EDW. Con un flujo de datos de
BW/4HANA, el cálculo se ejecuta una vez y el resultado se almacena. El query BW lee
subconjuntos específicos de los registros almacenados. Sin embargo, hay casos de
necesidades para las que el resultado se debe volver a calcular individualmente para cada
ejecución de consulta:
● Precios medios ponderados de todos los artículos existentes
● La mejor coincidencia utilizando una búsqueda inexacta
● Análisis ABC anidado basado en todas las posiciones (encontrando el peor de los mejores
80%)
● Discriminación por casos anidados complejos

Además, utilice data marts ágiles en lugar de procesos de carga de datos si el

almacenamiento de valores en BW/4HANA no tiene ninguna ventaja:
● Debe mantener pequeña la memoria utilizada y calcular el resultado es lo suficientemente
rápido.
● Desea utilizar una herramienta de informes de terceros, por ejemplo, Tableau.

Como ventaja, el resultado visualizado cambia inmediatamente en respuesta a las

modificaciones en la base de datos.
Nota:
Existen mejoras en las capacidades y el rendimiento del tiempo de ejecución en ambos lados,
por lo que asegúrese de verificar regularmente si está disponible una mejor solución.

© Copyright. Reservados todos los derechos. 153

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Ampliación ágil local

Figura 121: LSA++ Ampliación ágil local

¿Cuál es el objetivo y cuáles son las características de la capa de extensión ágil local?
La ampliación ágil pretende colmar la brecha entre los requisitos de gobernanza central y las
necesidades de flexibilidad local. TI tiene que actualizar modelos de datos gestionados
centralmente basados en datos centrales con una semántica definida centralmente en esos
datos. Aquí, TI normalmente está vinculado por acuerdos de nivel de servicio, así como por
reglas de conformidad y tiene como objetivo mantener los datos en los contenedores de
datos consistentes. Esto significa que el departamento de TI no puede reaccionar de forma
espontánea ante solicitudes de modificación de datos o de añadir datos nuevos. El
departamento empresarial local debe actuar de forma ágil en sus operaciones diarias.

Figura 122: LSA++: Arquitectura de espacios de trabajo BW locales

154 © Copyright. Reservados todos los derechos.

 Lección: Diseño de una arquitectura escalable en capas de SAP BW/4HANA (LSA++)

Este desafío se puede superar configurando áreas de trabajo BW en SAP BW/4HANA para
departamentos empresariales locales (por ejemplo, marketing, recursos humanos,
controlling, etc.). Un área de trabajo BW es un área de trabajo limitada dedicada con usuarios
asignados específicamente. Los usuarios empresariales asignados pueden reaccionar
rápidamente a los requisitos nuevos y cambiantes cargando archivos y combinando
conjuntos de datos. TI limita la cantidad de recursos (como espacio de almacenamiento) que
un área de trabajo BW puede utilizar y expone algunos de los modelos de datos centrales al
área de trabajo BW (datos de los modelos y su semántica relacionada). Los usuarios del
departamento local crean proveedores compuestos (locales) y consultas (locales) en el área
de trabajo BW. Una consulta local puede hacer referencia a una consulta existente del
InfoSitio central y, a continuación, las modificaciones de la consulta central se reflejan en la
consulta local.
Una forma alternativa de implementar una ampliación ágil de SAP BW/4HANA central es un
SAP Data Warehouse Cloud (DWC) complementario. En DWC, IT define uno o más espacios.
Cada espacio contiene recursos, usuarios y conexiones a fuentes existentes. Los usuarios del
departamento local pueden cargar o federar datos de estas conexiones y cargar datos
adicionales desde archivos planos. Pueden crear modelos e historias.
Ventajas
Con una extensión ágil local, el negocio local tiene su propia posibilidad de responder a los
volátiles requisitos de negocio locales:
● Conectando o cargando sus propios datos siempre que estén disponibles.
● Diseñando modelos de datos locales que amplían la solución central
● Mediante la generación de informes de autoservicio (consultas o historias locales) sobre
los modelos locales.

Las principales ventajas son las siguientes:

● Independencia local con acceso controlado a EDW/ Open ODS Core InfoProvider
● Gestión global de recursos. (La TI global puede limitar el número de objetos y el número de
KB por área de trabajo.)
● Un concepto de autorización claro.

Escenarios empresariales de ejemplo

Con las áreas de trabajo, se pueden lograr diferentes escenarios.
Ejemplo 1: Un departamento de marketing desea iniciar una campaña de marketing pronto.
Para supervisar los datos de la campaña, desean configurar un InfoSitio para realizar un
seguimiento de las reacciones de los clientes. El departamento empresarial se dirige al
departamento de TI con esta solicitud y le informan de que se podría implementar un nuevo
aDSO en un plazo de dos meses, como muy pronto.
Ejemplo 2: Sus superusuarios están descargando cantidades masivas de datos en MS Access
donde se procesan individualmente. Para TI, esto es un no-go y no hay documentación sobre
esta "caja negra". Para detener esta forma de trabajar, está permitiendo que algunos de ellos
utilicen y creen áreas de trabajo BW que están dentro de su organización de TI.
Ejemplo 3: Su sistema ERP aún no está totalmente integrado. La gestión de almacenes y los
sistemas CRM no están conectados al EDW de su organización y los datos sólo se pueden
integrar en base a ficheros planos ad-hoc. Estas fuentes deben integrarse de forma flexible
para el análisis de pedidos de cliente. Este es el escenario para los ejercicios de esta unidad.

© Copyright. Reservados todos los derechos. 155

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

El área de trabajo BW solo expone los datos centrales de forma lógica: los datos no se copian
ni replican, sino que solo se exponen virtualmente en el área de trabajo BW. El objetivo es
permitir a los usuarios empresariales clave utilizar estos datos centrales para enriquecerlos
en un entorno dedicado y separado. Lo que ocurre después dentro del área de trabajo de BW
está en manos del departamento empresarial.

La capa de reporting BW

Figura 123: LSA++ La capa de gestión de informes

La consulta es la interfaz final para las herramientas de reporting. Siempre se debe crear una
consulta en la parte superior de los InfoSitios de la capa de data mart virtual (o en
proveedores compuestos locales de la capa de área de trabajo BW).
Puede utilizar las herramientas de modelado de SAP BW/4HANA para definir consultas BW
para InfoSitios para analizar los datos en SAP BW/4HANA. Esta funcionalidad se liberó
primero con las siguientes funciones:
● Crear estructuras en los ejes de fila y columna de la consulta BW
● Seleccionar características del InfoSitio para los ejes de fila y columna del query BW o
como características libres (incluido el uso de jerarquías de características)
● Seleccionar ratios del InfoSitio como elementos de estructura para los ejes de fila y
columna del query BW
● Crear ratios restringidos para la consulta BW actual
● Utilizar ratios calculados y restringidos reutilizables, así como variables
● Definir las propiedades de características, estructuras y ratios
● Crear filtros, excepciones y condiciones estáticos y dinámicos
● Conversión de moneda y unidad

156 © Copyright. Reservados todos los derechos.

 Lección: Diseño de una arquitectura escalable en capas de SAP BW/4HANA (LSA++)

● Crear fórmulas, es decir, ratios calculados, para la consulta BW actual

Compruebe si el número de objetos de la capa de transformación empresarial se puede

reducir utilizando consultas con los mismos cálculos.
Además, las consultas son el lugar para implementar posibilidades de entrada de usuario
(llamadas variables de tipo entrada manual).
Las consultas pueden proporcionar selecciones estándar y propiedades de desglose para
informes estándar. Si se permite un desarrollo más local en la gestión de informes, las
consultas no siempre son necesarias. La mayoría de las herramientas de reporting pueden
acceder directamente a InfoSitios como proveedores compuestos como fuente.
Las consultas pueden proporcionar selecciones estándar y propiedades de desglose para
informes estándar. Si se permite un desarrollo más local en la gestión de informes, las
consultas no siempre son necesarias. La mayoría de las herramientas de reporting pueden
acceder directamente a InfoSitios como proveedores compuestos como fuente.

Historias
En SAP Analytics Cloud (SAC), Business Objects BI y otras herramientas de generación de
informes, se pueden definir informes o historias basadas en web con opciones interactivas
que tengan funciones similares (filtros, cálculos, opciones de desglose, jerarquías). Se
pueden crear a partir de consultas BW existentes. Además, normalmente contienen una
disposición predefinida.

Recomendación de caso empresarial

La LSA++ contiene un máximo de diferentes conceptos de BW/4HANA, pero no se deben
realizar todas las capas. Las capas necesarias dependen de la complejidad de sus requisitos y
de su estrategia. En especial, debe decidir cuándo utilizar las capas de SAP BW/4HANA con
almacenamiento persistente y cuándo utilizar modelos SAP HANA virtuales.
LSA++ combina sabiamente elementos con almacenamiento de datos (EDW, extensión ágil
local) y capas virtuales (Agile Data Mart, Virtual Layer, BW Reporting Layer). Dentro de LSA+
+, se prefieren las capas virtuales. Las capas de persistencia deben tener un motivo
empresarial.
Por ejemplo, debe almacenar un historial de datos si desea detectar una tendencia. Utilice un
centro de datos ágil (vista de SAP HANA) para ver las ventas de hoy.

Nota:
LSA++ proporciona escenarios en los que las consultas se crean sobre
proveedores compuestos que conectan solo vistas Open ODS basadas en vistas
SAP HANA o tablas remotas. Este ejemplo muestra que la persistencia no siempre
es necesaria. Para la generación de informes de autoservicio, existe una tendencia
a un almacén de datos virtual sin ninguna capa persistente.

Una LSA++ típica consiste en sólo una o dos capas físicas del núcleo EDW. La capa Open ODS
no necesita ser persistente si los valores de carga en la capa EDW central global
(normalmente un aDSO estándar) son fiables y lo suficientemente rápidos. Los datos
transaccionales de la misma granularidad de diferentes fuentes se pueden almacenar en un
aDSO grande.

© Copyright. Reservados todos los derechos. 157

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Nota:
Las capas no se corresponden 1:1 con los objetos BW/4HANA. Por ejemplo, no es
ningún problema almacenar datos armonizados (concepto Propagator Layer) y
datos brutos (concepto de memoria corporativa) en un aDSO grande. Desde el
mismo registro, puede seleccionar solo datos armonizados (ID de proveedor BW y
valores USD) o solo datos brutos (ID de proveedor original y valores AUD), o
incluso ambos para recalcular el factor de conversión. Con SAP HANA, solo se
leen las columnas necesarias.
Sin embargo, mantenga los datos de la memoria corporativa de diferentes niveles
de granularidad separados en diferentes aDSO para ahorrar espacio en el disco.

Los data marts con arquitectura se pueden modelar como proveedores compuestos si las
transformaciones son lo suficientemente simples, como joins o uniones de proveedores de
partes. No almacene el resultado físico de un join sin investigar minuciosamente el tiempo de
ejecución frente a los costes de almacenamiento. Por ejemplo, verifique si el join temporal en
un CompositeProvider es lo suficientemente rápido como para derivar el escenario del
historial de seguimiento "verdad histórica".
Para transformaciones un poco más complicadas, verifique si se pueden calcular en un query
BW. Si ni el proveedor compuesto ni la consulta son suficientes, utilice transformaciones y
una nueva capa física. Normalmente, este data mart arquitectónico será un aDSO
multidimensional, lo que significa que todas las características son campos clave.
Además de cada proveedor físico, utilice un proveedor compuesto wrap, y si se necesitan
combinaciones de diferentes proveedores físicos, se recomienda otra capa compuesta.
Forman la base para las consultas.

Convenciones para fijar nombres

Se recomienda utilizar una convención para fijar nombres para los nombres técnicos de los
InfoSitios y otros objetos de SAP BW/4HANA que indique la capa (y la importancia del
objeto).
La primera letra o letras están reservadas para un área de nombres para un área de
responsabilidad de nivel superior, como una sección empresarial. La siguiente letra está
reservada para la capa LSA. Las siguientes letras son una propuesta para estas áreas de
nombres:

● Z: Fuente de datos (basada en las convenciones para fijar nombres existentes en los
sistemas fuente de SAP)
● O: Capa Open ODS (vista Open ODS)
● CM: Capa de memoria corporativa (staging aDSO)
● DW: Capa de almacén de datos / Cálculo delta (aDSO estándar)
● DM: Capa de Data Mart (Data Mart aDSO) (con arquitectura)
● W: capa de ajuste (virtual) (proveedor compuesto)
● V: Capa de composición (virtual) (proveedor compuesto)
● CV: Vista de cálculo (capa Agile Data Mart)

158 © Copyright. Reservados todos los derechos.

 Lección: Diseño de una arquitectura escalable en capas de SAP BW/4HANA (LSA++)

Las siguientes letras se pueden reservar para el concepto empresarial o dominio, si se

necesita un concepto de autorización tan detallado.
Con SAP BW/4HANA, obtenemos más flexibilidad y más opciones que cubren las
necesidades empresariales. Sin embargo, necesitamos una nueva LSA++ holística que
proporcione un marco para todos los tipos de BI diferentes y sus datos persistentes y centros
de datos virtuales.

Nota:
Para obtener más detalles, consulte también este documento:
“LSA++ para SAP BW” https://archive.sap.com/documents/docs/DOC-35212
SAP Help for BW/4HANA: arquitectura de capa de un almacén de datos con base
de datos de SAP HANA (LSA++): https://help.sap.com/viewer/
dd104a87ab9249968e6279e61378ff66/11.0.8/en-US/
22ad6fad96b547c199adb588107e6412.html

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Diseñar una arquitectura escalable en capas con capas virtuales

© Copyright. Reservados todos los derechos. 159

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

160 © Copyright. Reservados todos los derechos.

 Capítulo 4
Lección 6
Comprender la partición física y lógica

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Comprender la partición física y lógica

Comprender la partición lógica y física

Figura 124: Escenario empresarial para partición lógica y física

Desea acelerar el rendimiento del reporting dividiendo todo el set de datos en unidades más
pequeñas que se pueden leer en paralelo. Desea utilizar características que normalmente se
seleccionan o desglosan en informes.

Figura 125: Separación de áreas de responsabilidad

Durante algún tiempo, las fuentes originales (agente clásico de ITeIO y Retailer King 3000),
seguirán siendo áreas de responsabilidad separadas, pero un objetivo estratégico es unirse a
estas áreas y reducir las diferencias hasta que finalmente, ya no se separarán en absoluto.

© Copyright. Reservados todos los derechos. 161

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Por lo tanto, ITeIO quiere separarlos de una forma muy flexible que pueda modificarse
fácilmente. Puesto que es muy difícil cambiar este concepto más adelante, debe examinarse
detenidamente este proceso de decisión. ¿Cuál es un procedimiento de mejores prácticas
para diseñar este modelo de infraestructura del sistema?

Separación de áreas de responsabilidad

¿Cómo se organiza su empresa? En la revisión empresarial, ha identificado diferentes

procesos empresariales que contribuyen al almacén de datos. Normalmente, cada proceso
corresponde a una o más áreas de responsabilidad, por ejemplo, una subsidiaria o un tema de
informes. Una cuestión importante es si las diferentes áreas de responsabilidad deben
compartir objetos comunes y qué tan dinámica son estas asignaciones.

1. Defina procesos empresariales relevantes y asigne claramente áreas de responsabilidad

separadas, como ventas y compras.

2. Identifique las subáreas de responsabilidad, como Ventas Europa, Ventas Asia.

3. Investigar a fondo dónde se producen solapamientos entre procesos empresariales.

Defina una responsabilidad global para problemas de varios temas, como la competencia
entre diferentes organizaciones de ventas.

4. Identifique qué elementos básicos están implicados, como pedidos, clientes, productos,
países, monedas.

5. Identifique especialmente si estos elementos son específicos de un proceso o área

empresarial:

a. Los elementos globales como país, tiempo, moneda y sociedad son relevantes en
muchas áreas,

b. Los elementos "locales" específicos son específicos de un proceso, como descuento

de ventas, motivo de rechazo, retraso en la entrega.

6. Identifique en qué nivel una reorganización de responsabilidades puede ser un problema

en el futuro.

¿Cómo se separan técnicamente las diferentes áreas de responsabilidad? Considere qué

sucede si la empresa se reorganiza o si se establecen nuevos procesos y sistemas. La
complejidad aumenta y las asignaciones que parecían corregirse deben modificarse. Por lo
tanto, si tiene dudas, le recomendamos que elija el concepto más flexible. En la imagen
"Separar diferentes áreas de responsabilidad" se distinguen tres conceptos diferentes:
● Aplicaciones separadas como sistemas fuente independientes
● Separar áreas de nombres (nombres técnicos) en un sistema
● Más flexible: Separe carpetas en una jerarquía (InfoÁreas, Componentes de aplicación,
paquetes de contenido de SAP HANA).

De hecho, las combinaciones de estos conceptos son comunes en las implementaciones de

data warehouse.
Veamos estos conceptos con un poco más de detalle:

Aplicaciones separadas
Algunas áreas de responsabilidad deben separarse de una manera rígida y estable con
estrictas barreras de acceso técnico. Por ejemplo, puede separar un almacén de datos de HR
de un almacén de datos CRM utilizando diferentes aplicaciones BW. De forma similar al nivel

162 © Copyright. Reservados todos los derechos.

 Lección: Comprender la partición física y lógica

de sistema fuente, las grandes empresas a menudo utilizan diferentes sistemas BW/4HANA
para diferentes procesos si no se requieren o se requieren pocos objetos comunes. Pero
compartir objetos comunes es difícil. Se requiere un esfuerzo adicional para combinar datos
de varias aplicaciones BW/4HANA en un informe global. Por ejemplo, puede extraer
fracciones de datos relevantes en un tercer almacén de datos global.

Separar áreas de nombres

Para áreas de responsabilidad más pequeñas que deben separarse de forma rígida y estable
con muchos objetos comunes, le recomendamos que utilice diferentes áreas de nombres. Por
ejemplo, puede crear diferentes áreas de nombres para aprovisionamiento y ventas, y un área
de nombres global para objetos comunes como día, producto, empleado o socio comercial.
Los informes globales que combinan datos de ambas áreas de responsabilidad se pueden
crear como vistas en ambas áreas en el área de nombres de objetos comunes.
Un área de nombres es un conjunto de posibles nombres técnicos para objetos, normalmente
definidos por sus letras iniciales. Por ejemplo, todos los objetos SAP empiezan con números.
El contenido de BI empieza por 0. Es posible definir subáreas de nombres. Por ejemplo, los
objetos del contenido de demostración de SAP BI empiezan por 0D. Los nombres técnicos de
los objetos de contenido de demostración de SAP NetWeaver para esta formación empiezan
por 0D_NW. Forman parte del contenido de demostración de SAP BI. Defina sus propias
áreas de nombres en el área de nombres de cliente, es decir, todos los nombres técnicos que
empiecen por letras. Por ejemplo, podría utilizar X, Y, Z para tres áreas de responsabilidad
diferentes y G para objetos globales. En nuestro sistema de formación, todos los objetos de
ejercicio que no son BI Content empiezan con P (preparados para formación, por ejemplo,
modelos) o U para sus propios objetos de usuario.

Separar carpetas
Tenga en cuenta que el diseño de las responsabilidades puede cambiar con el tiempo. Las
áreas de responsabilidad se dividen periódicamente en subáreas. Para estos casos, utilice
una jerarquía de carpetas que refleje una jerarquía de áreas de responsabilidad que cambia
dinámicamente. En SAP BW/4HANA, utilice InfoÁreas, en SAP HANA, utilice paquetes de
contenido y, en un sistema fuente, utilice componentes de aplicación. Por ejemplo, cree
InfoÁreas para ventas online y ventas productivas como subInfoÁreas de ventas.

Resumen
Con los tres conceptos, se puede implementar una gestión de autorizaciones. Sin embargo,
con sistemas separados, el impacto técnico de cambiar la organización es alto. Con el
enfoque del área de nombres, al menos es fácil añadir un área de nombres si es necesario
añadir nuevas áreas de responsabilidad. Pero es difícil reasignar objetos en uso a otra área de
nombres. Por lo tanto, tenga cuidado con la definición de áreas de nombres. Recomendamos
trabajar con almacenes de datos y áreas de nombres separados solo para áreas que
permanecen tal como están.
Incluso si ahora tiene una organización estricta, desea reorganizarla más tarde. En este caso,
es más flexible si su concepto se basa en una jerarquía de carpetas (InfoÁreas, componentes
de aplicación, componentes de visualización, paquetes de contenido HANA). Añadir nuevas
carpetas y mover objetos a otras carpetas normalmente no supone ningún problema.

© Copyright. Reservados todos los derechos. 163

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Figura 126: Separación de dominios de contenido

Figura 127: Mejores prácticas para dominios (1)

Pero, ¿cuál es una buena manera de dividir el conjunto de datos? La imagen, Mejores
prácticas para dominios (1), presenta dos sugerencias.
Supongamos que está considerando dos especificaciones de dominio posibles diferentes,
basadas en el estado del pedido combinado con el valor total de ventas, o en base a la
organización regional que originalmente participó en la creación del pedido.
Para el estado, todas las órdenes tienen inicialmente el estado abierto, pero en un momento
actual, el 80% ya están cerradas o rechazadas.
Para la organización regional, hay alrededor del 40% de los pedidos generados por América,
el 30% por Europa y el 30% por Asia.
¿Qué concepto sería una buena especificación de dominio y por qué?

164 © Copyright. Reservados todos los derechos.

 Lección: Comprender la partición física y lógica

Figura 128: Mejores prácticas para dominios (2)

La figura, Best Practice for Domains (2), presenta una recomendación: dominios separados
basados en filtros simples de una característica principal, generalmente uno que ya está
disponible en la capa de adquisición. A continuación, es fácil determinar los valores de filtro.
Técnicamente, el concepto de dominio puede ser realizado por diferentes InfoSitios con la
misma estructura pero diferentes registros (llamados agrupación semántica, partición
semántica o partición lógica), o mediante la partición de base de datos. La agrupación
semántica tiene la ventaja de que se pueden añadir diferentes transformaciones específicas
de dominio o incluso estructuras. Sin embargo, es una desventaja que se deban crear y
actualizar más objetos y procesos de carga. La partición de la base de datos requiere
estructuras exactamente idénticas, por lo que las estructuras son consistentes.
Si se utiliza la agrupación semántica, es importante seleccionar valores de filtro que
permanezcan fijos para cada entrada. Si se utiliza un aDSO estándar en la capa EDW para
generar imágenes anteriores y posteriores, solo serán correctas si todas las versiones de un
registro se encuentran en el mismo InfoSitio físico.
El estado de un registro normalmente cambia durante su vida útil. Por lo tanto, no utilice el
estado, sino una característica estable como regiones geográficas, áreas de mercado,
unidades organizativas o subempresas como característica determinante.
Idealmente diferentes dominios son de tamaño similar.
No es ningún problema que se cree un nuevo dominio, por ejemplo, la adición de otro dominio
geográfico para Australia y el Pacífico no causa problemas.
Se recomienda reutilizar InfoObjects en todos los dominios. A continuación, un objeto de un
dominio se puede utilizar como modelo para el objeto correspondiente del siguiente dominio
en la misma capa.
En los modelos basados en SAP HANA, los dominios se utilizan con menos frecuencia. Sin
embargo, es posible generar vistas de cálculo específicas de dominio y luego crear otra vista
de cálculo que genere la unión de todos los dominios.

© Copyright. Reservados todos los derechos. 165

Capítulo 4 : Estándares de mejores prácticas en el modelado de SAP BW/4HANA

Figura 129: Partición lógica o física

Los dominios se pueden modelar mediante dos tipos diferentes de partición:

● Partición física
Particiones dentro de un aDSO. Todos los campos clave de un aDSO se pueden
seleccionar como criterios de partición. Esto da como resultado particiones físicas de la
base de datos en SAP HANA. Todas las particiones se rellenan con la misma
transformación. La base de datos decide en función del contenido, en qué partición se
almacena un registro.
● Partición lógica
Particiones dentro de un grupo semántico de diferentes objetos DataStore. Si diferentes
particiones deben rellenarse con diferentes transformaciones, puede definir un grupo
semántico. Esto significa que diferentes objetos DataStore se agrupan y se utilizan como
parte de proveedores de un proveedor compuesto común.

Ambas técnicas de partición se pueden combinar. Si existen varios sistemas fuente, puede
recopilar las fuentes correspondientes de diferentes sistemas fuente en el mismo aDSO,
incluso con el concepto de dominio.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Comprender la partición física y lógica

166 © Copyright. Reservados todos los derechos.

 Capítulo 4

Evaluación de la formación

1. En una infraestructura productiva, SAP Best Practice debe tener al menos un sistema de
desarrollo, un sistema de garantía de calidad y un sistema productivo.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

2. El sistema BW productivo siempre se define como un sistema cerrado en el que las

modificaciones solo se pueden realizar importando un transporte.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

3. ¿Por qué recomendaría una separación de datos maestros y datos transaccionales?

Seleccione las respuestas correctas.

X A No se necesitan combinaciones para la generación de informes.

X B Esto generalmente reduce el tamaño del almacenamiento físico.

X C Mejore la consistencia en el almacén de datos empresariales.

X D Este es un requisito previo para la conversión de moneda.

4. Para modelar los escenarios del historial de seguimiento de la verdad histórica y la verdad
actual, se necesitan dos esquemas en estrella diferentes.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

© Copyright. Reservados todos los derechos. 167

Capítulo 4 : Evaluación de la formación

5. Utilice Cliente y Fecha de reserva como características junto con el ratio Importe en un
aDSO. El cliente tiene un atributo dependiente del tiempo Clase de cliente, que no forma
parte de este modelo. ¿Qué puede hacer para ver la verdad histórica en un informe que
muestra Cliente, Clase de cliente, Fecha de reserva e Importe?
Seleccione las respuestas correctas.

X A No hace falta cambiar nada, se mostrará la verdad histórica.

X B Añada Clase de cliente como atributo de navegación de Cliente.

X C Remodele el aDSO y añada la característica Clase de cliente en el modelo aDSO.

Rellene la nueva columna con una búsqueda del cliente de InfoObject, basado en la
fecha de reserva.

X D Cree un CompositeProvider con un join temporal para la característica Cliente con

referencia a la fecha de reserva. Asegúrese de que Clase de cliente se ha añadido a la
estructura de destino.

6. ¿Cuáles de las siguientes afirmaciones son verdaderas con respecto a la diferencia entre
composición y concatenación?
Seleccione las respuestas correctas.

X A La composición es más fácil de filtrar en las consultas porque los objetos están
separados, mientras que con la concatenación, la cadena clave debe enmascararse.

X B La composición es más fácil de entender para los usuarios porque se basa en una
asignación de objeto 1:1 pero la concatenación es más compleja para que los usuarios
la comprendan y descifren.

X C La concatenación utiliza un valor clave individual, pero la relación utiliza más de

uno.

X D La concatenación se admite en la definición del InfoObjeto, mientras que la

relación solo es relevante para los datos transaccionales.

168 © Copyright. Reservados todos los derechos.

 Capítulo 4 : Evaluación de la formación

7. ¿Cuál es el objetivo de la capa de data mart virtual?

Seleccione las respuestas correctas.

X A Ampliación ágil: Permita que los usuarios empresariales carguen archivos e

informen directamente sobre ellos.

X B Ampliación de datos maestros: añadir atributos de navegación según sea

necesario para un escenario empresarial específico.

X C Flexibilidad: Si necesita intercambiar el InfoSitio físico a continuación, todas las

consultas BW pueden permanecer sin cambios.

X D Soporte para Desconocido: Almacene datos que actualmente no se necesitan en

caso de que se necesiten más adelante.

X E Combinación virtual: Filtrar y unir datos de InfoSitios existentes sin cargar

registros ya disponibles.

8. Para la partición, utilice un campo que se modifique con frecuencia en la fuente.

Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

© Copyright. Reservados todos los derechos. 169

 Capítulo 4

Respuestas a la Evaluación de la formación

1. En una infraestructura productiva, SAP Best Practice debe tener al menos un sistema de
desarrollo, un sistema de garantía de calidad y un sistema productivo.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! SAP siempre recomienda que haya al menos tres sistemas técnicos:
desarrollo, QA y producción. Leer más en el módulo Comprensión de las opciones de
modificación de objetos, en el curso BW430.

2. El sistema BW productivo siempre se define como un sistema cerrado en el que las

modificaciones solo se pueden realizar importando un transporte.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

Es correcto. Los sistemas BW suelen ser sistemas abiertos porque deberían ser posibles
alteraciones en objetos como consultas y vistas de consulta. Los cambios en estos
objetos no se consideran dañinos. Leer más en el módulo Comprensión de las opciones de
modificación de objetos, en el curso BW430.

170 © Copyright. Reservados todos los derechos.

 Capítulo 4 : Respuestas a la Evaluación de la formación

3. ¿Por qué recomendaría una separación de datos maestros y datos transaccionales?

Seleccione las respuestas correctas.

X A No se necesitan combinaciones para la generación de informes.

X B Esto generalmente reduce el tamaño del almacenamiento físico.

X C Mejore la consistencia en el almacén de datos empresariales.

X D Este es un requisito previo para la conversión de moneda.

¡Ha acertado! Para incluir datos maestros almacenados por separado en un informe, se
deben ejecutar joins (pero esto es bastante rápido con SAP HANA). Sin embargo, necesita
menos espacio de almacenamiento si los atributos, textos o jerarquías no se repiten en la
tabla de datos de transacción. Al utilizar el mismo conjunto de datos maestros para
diferentes conjuntos de datos de transacción y al verificar la integridad referencial durante
el proceso de transferencia de datos, se obtiene consistencia en el almacén de datos
empresariales. Para la conversión de moneda, solo necesita ratios con monedas en los
datos de transacción. (Las tablas de datos maestros separadas no son necesarias). Leer
más en el módulo Separación de datos maestros y datos de transacción, en el curso
BW430.

4. Para modelar los escenarios del historial de seguimiento de la verdad histórica y la verdad
actual, se necesitan dos esquemas en estrella diferentes.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! El modelado de la verdad actual e histórica se puede modelar en un único

esquema estrella utilizando una mezcla de características (para la verdad histórica) y
atributos de navegación independientes del tiempo (para la verdad actual). Leer más en el
módulo Seguimiento de historial, en el curso BW430.

© Copyright. Reservados todos los derechos. 171

Capítulo 4 : Respuestas a la Evaluación de la formación

5. Utilice Cliente y Fecha de reserva como características junto con el ratio Importe en un
aDSO. El cliente tiene un atributo dependiente del tiempo Clase de cliente, que no forma
parte de este modelo. ¿Qué puede hacer para ver la verdad histórica en un informe que
muestra Cliente, Clase de cliente, Fecha de reserva e Importe?
Seleccione las respuestas correctas.

X A No hace falta cambiar nada, se mostrará la verdad histórica.

X B Añada Clase de cliente como atributo de navegación de Cliente.

X C Remodele el aDSO y añada la característica Clase de cliente en el modelo aDSO.

Rellene la nueva columna con una búsqueda del cliente de InfoObject, basado en la
fecha de reserva.

X D Cree un CompositeProvider con un join temporal para la característica Cliente con

referencia a la fecha de reserva. Asegúrese de que Clase de cliente se ha añadido a la
estructura de destino.

¡Ha acertado! Con un atributo de navegación, los datos se visualizan en función de una
fecha clave. La verdad histórica solo se puede generar con un valor de datos de
transacción cargado o con un join temporal en un CompositeProvider. Leer más en el
módulo Seguimiento de historial, en el curso BW430.

6. ¿Cuáles de las siguientes afirmaciones son verdaderas con respecto a la diferencia entre
composición y concatenación?
Seleccione las respuestas correctas.

X A La composición es más fácil de filtrar en las consultas porque los objetos están
separados, mientras que con la concatenación, la cadena clave debe enmascararse.

X B La composición es más fácil de entender para los usuarios porque se basa en una
asignación de objeto 1:1 pero la concatenación es más compleja para que los usuarios
la comprendan y descifren.

X C La concatenación utiliza un valor clave individual, pero la relación utiliza más de

uno.

X D La concatenación se admite en la definición del InfoObjeto, mientras que la

relación solo es relevante para los datos transaccionales.

Tienes razón. Todas las respuestas son verdaderas con respecto a las diferencias excepto
para la pregunta relativa a la definición de InfoObjetos. La composición, no la
concatenación, se admite en la definición de un InfoObjeto. Ambos métodos son
relevantes para los datos maestros y transaccionales, y siempre se crean tablas de base
de datos separadas para InfoObjetos, independientemente de si están compuestos o
concatenados. Leer más en el módulo Asignación y transformación de datos, en el curso
BW430.

172 © Copyright. Reservados todos los derechos.

 Capítulo 4 : Respuestas a la Evaluación de la formación

7. ¿Cuál es el objetivo de la capa de data mart virtual?

Seleccione las respuestas correctas.

X A Ampliación ágil: Permita que los usuarios empresariales carguen archivos e

informen directamente sobre ellos.

X B Ampliación de datos maestros: añadir atributos de navegación según sea

necesario para un escenario empresarial específico.

X C Flexibilidad: Si necesita intercambiar el InfoSitio físico a continuación, todas las

consultas BW pueden permanecer sin cambios.

X D Soporte para Desconocido: Almacene datos que actualmente no se necesitan en

caso de que se necesiten más adelante.

X E Combinación virtual: Filtrar y unir datos de InfoSitios existentes sin cargar

registros ya disponibles.

¡Ha acertado! Los beneficios clave en la implementación de una capa virtual data mart son
mejorar los datos maestros, intercambiar de forma flexible InfoSitios virtuales o físicos y
combinar virtualmente lo que ya está disponible. Las extensiones Agile locales (para
cargar archivos) y la memoria corporativa (para soportar lo desconocido) pertenecen a
otras áreas funcionales de la LSA++. Leer más en el módulo Diseño de una arquitectura
escalable en capas (LSA++) de SAP BW/4HANA, en el curso, BW430.

8. Para la partición, utilice un campo que se modifique con frecuencia en la fuente.

Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

Tienes razón. Debería utilizar un campo que no se modifique, normalmente un campo

clave del modelo. Si se debe actualizar un registro con cambios de la fuente, debe
distribuirse a la misma partición. Leer más en el módulo Comprender la partición física y
lógica, en el curso BW430.

© Copyright. Reservados todos los derechos. 173

Capítulo 4 : Respuestas a la Evaluación de la formación

174 © Copyright. Reservados todos los derechos.

CAPÍTULO 5 Proceso de modelado

Lección 1
Definición de la secuencia de proyectos de SAP BW/4HANA 177

Lección 2
Planificación de las fases de un proyecto de SAP BW/4HANA 185

Lección 3
Desarrollo de un modelo de datos de SAP BW/4HANA 197

OBJETIVOS DEL CAPÍTULO

● Definir una secuencia de proyectos SAP BW

● Enumerar las cinco fases de un proyecto SAP BW
● Comprender la fase de preparación
● Comprender la fase de blueprint empresarial
● Comprender la fase de realización
● Comprender la fase de preparación final
● Comprender la fase de entrada en productivo y soporte
● Estructurar el proceso de creación del modelo de datos en la fase de plano empresarial
● Realizar un análisis de requisitos
● Crear un resumen de la arquitectura
● Crear un modelo de datos lógico
● Desarrollar un modelo de datos de SAP BW/4HANA

© Copyright. Reservados todos los derechos. 175

Capítulo 5 : Proceso de modelado

176 © Copyright. Reservados todos los derechos.

 Capítulo 5
Lección 1
Definición de la secuencia de proyectos de
SAP BW/4HANA

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Definir una secuencia de proyectos SAP BW

Escenario empresarial y objetivo de un proyecto piloto

El proceso de modelado

Figura 130: Escenario empresarial: Proceso de modelado

La experiencia de más de 10.000 instalaciones ha demostrado que el número de proyectos

de SAP BW necesarios para desarrollar soluciones SAP BW específicas dentro de una
empresa está creciendo rápidamente. Con el fin de proporcionar un sistema central para big
data, otras aplicaciones principalmente operativas utilizadas para la generación de informes
junto con SAP BW se están integrando gradualmente en la aplicación SAP BW o se transfieren
a una aplicación basada en SAP HANA. Con SAP BW potenciado por SAP HANA, la idea de
una aplicación para toda la empresa para proporcionar datos para dar soporte a toda la gama
de decisiones operativas y estratégicas se considera más que nunca.
Las empresas internacionales que desean implementar y gestionar un almacén de datos
global e integrado se enfrentan primero a la decisión estratégica de hacerlo. En primer lugar,
las normativas y estándares corporativos (directrices de implementación específicas de la
empresa) que describen el enfoque de implementación son necesarios antes de implementar
dicho almacén de datos global. Analizaremos el contenido necesario más adelante en la
sección. Las soluciones SAP BW individuales y a menudo descentralizadas se presentan
como proyectos dentro de la empresa. Analizaremos el orden de los proyectos en una
secuencia y el proceso de modelado dentro de un proyecto BW.
Se recomienda utilizar un proceso estructurado con diferentes pasos. Necesita este proceso
estructurado para lograr lo siguiente:

© Copyright. Reservados todos los derechos. 177

Capítulo 5 : Proceso de modelado

● Asegúrese de que toda la información necesaria esté completa y esté correctamente

representada en los informes y en SAP BI.
● Garantizar un alto rendimiento de SAP BW en relación con los procesos de consulta y de
carga.
● Integrar a todas las personas involucradas en el proyecto.
● Asegúrese de que el modelo de datos está bien documentado y, en última instancia,
obtenga un modelo de datos consistente en SAP BW powered by SAP HANA.

En este curso, aprenderá sobre las características del modelado de datos. Lamentablemente,
no existe un único procedimiento exacto para el modelado de datos. Debido a diferentes
análisis de requisitos, procesos del sistema fuente y relaciones, no existe ningún mecanismo
que pueda utilizar para crear un modelo de datos único y óptimo. En su lugar, el
procedimiento es un compromiso que implica implementar el análisis de requisitos y
optimizar el rendimiento al mismo tiempo.
Además, durante la fase de modelado, los requisitos pueden cambiar, la mayoría de las veces
cuando la forma en que se ven las estructuras de datos se investiga en el sistema fuente y en
un momento en el que se integran fuentes de datos adicionales en SAP BW. Por lo tanto, es
un buen consejo pensar en qué fuentes podrían llegar a ser relevantes en el futuro.

Proceso para modelado

Antes de considerar los aspectos específicos de SAP BW del proceso, debe revisar sus
decisiones estratégicas, desarrollar estándares generales y planificar todo el proceso para el
proyecto.

Figura 131: Decisión estratégica de SAP BW

Comience con la decisión estratégica de SAP BW. ¿Cuál es el motivo principal para
implementar SAP BW? Los siguientes son algunos ejemplos y sus consecuencias para la
captura de datos:

178 © Copyright. Reservados todos los derechos.

 Lección: Definición de la secuencia de proyectos de SAP BW/4HANA

● Informes estratégicos, evaluación de tendencias a lo largo de varios años, con una

urgencia de semanas, es decir, puede tardar semanas en recopilar los datos relevantes.
● Gestión de informes táctica, por ejemplo, una comparación anual acumulada entre el año
anterior y este año, cuando es suficiente con tener datos del día laborable anterior.
● Reporting operativo, por ejemplo, la evaluación de la suma actual de pedidos pendientes,
que requiere acceso en tiempo real a los datos de último minuto.
● Integración de datos maestros de diferentes fuentes, con la necesidad de cargar datos
maestros siempre que se produzcan modificaciones.
● Planificación y distribución de valores plan, con la posibilidad de escribir directamente en
objetos de almacenamiento de datos.

¿Qué ventajas operativas espera? Algunos ejemplos son las siguientes expectativas:
● Mayores ingresos: lograr sus objetivos de manera más rápida y eficiente, verificar sus
metas utilizando instrumentos integrados para el análisis y modelado de datos y utilizar
una planificación óptima para abrir nuevo potencial de ingresos.
● Costos reducidos: analizar específicamente las cadenas de suministro, los procesos de la
empresa y otras áreas que son críticas para el éxito.
● Gestión informada: aumentar la capacidad de acción y la velocidad de reacción de sus
especialistas y la gestión, y utilizar Internet para proporcionar información actualizada y
precisa continuamente sobre la empresa y el desarrollo del mercado de una manera clara
y accesible.
● Mejor orientación al cliente: transferir los resultados del análisis a los sistemas operativos.
De este modo, sus decisiones siempre se basan en la información actual y la interacción
con el cliente mejora considerablemente.

Antes de diseñar pautas de implementación en toda la empresa y una secuencia de proyectos

de SAP BW, basados en la decisión estratégica de SAP BW, responda las siguientes
preguntas:
● ¿Qué función debería tener SAP BW en 10 años?
● ¿Cuáles son los campos estratégicos de negocio que deben integrarse en el almacén de
datos?
● ¿Esperas cambios en el enfoque?
● ¿Espera que aumenten los requisitos de generación de informes en sectores específicos?
● ¿Espera modificaciones en el sistema fuente?
● ¿Cuáles son nuestras prioridades en nuestro almacén de datos?
● ¿El modelado debe realizarse principalmente en SAP BW y SAP HANA?

A continuación, defina las directrices de implementación para toda la empresa. Las

normativas y estándares corporativos (directrices de implementación específicas de la
empresa) que describen el enfoque de implementación son un requisito previo para
implementar un almacén de datos global.

© Copyright. Reservados todos los derechos. 179

Capítulo 5 : Proceso de modelado

Directrices de implementación en toda la empresa

Figura 132: Directrices de implementación en toda la empresa

Una directriz para toda la empresa de implementación es un conjunto de estándares que no

son específicos del proyecto. Considere muchos procesos de negocio para definirlos. La
directriz debería abarcar al menos los siguientes puntos:
● Infraestructura de transporte y sistema
¿Qué sistemas forman parte del dominio de transporte? ¿Qué objetos son modificables en
qué sistemas?
● Idiomas y monedas del sistema
¿Es suficiente con almacenar todos los textos en inglés o qué otros idiomas son
necesarios? ¿Qué monedas están permitidas, de dónde proceden los factores de
conversión?
● Procedimiento para integrar escenarios o datos globales y locales
¿Cuáles son los estándares para los datos globales? ¿Quién es responsable de las tareas
de armonización global y cómo pueden utilizar los proyectos locales estos datos
armonizados? ¿En qué casos los proyectos locales pueden crear sus propios objetos?
(Tenga en cuenta los datos de transacción y los datos maestros).
● Concepto de Enterprise Data Warehouse (EDW)
Por ejemplo, utilice las capas según LSA++.
● Concepto de autorización y convenciones para fijar nombres
Los estándares de toda la empresa se encuentran en un alto nivel. Es necesario un ajuste
preciso específico del proyecto.
● Concepto operativo

180 © Copyright. Reservados todos los derechos.

 Lección: Definición de la secuencia de proyectos de SAP BW/4HANA

¿Cuándo se ejecutan los jobs regulares? Por ejemplo, cada viernes se transportan órdenes
de transporte liberadas. El día 10 de cada mes se ejecutan jobs de limpieza y se archivan
fracciones de datos.
● Procedimiento para integrar modelos de datos
Por ejemplo, primero genere un modelo de datos, luego verifique qué objetos globales se
pueden utilizar y cree nuevas copias locales si es necesario.
● Pautas de documentación
Por ejemplo, documente no solo las propiedades técnicas, sino también los motivos de las
decisiones de modelado y la persona o equipo responsable
● Gestión de contenido de BI
Por ejemplo, defina que solo se utilicen las características de tiempo y los objetos de
contenido BI técnicos en el área de nombres original y que se copien todos los demás.
● Pautas para modificaciones y proyectos locales. Por ejemplo, responda las siguientes
preguntas:
- ¿Qué objetos deben utilizarse en común por diferentes agentes, proyectos?
- ¿Tenemos algún tipo de ciclo de lanzamiento de BW para mantener actualizados los
proyectos finalizados?
- ¿Cuáles son los criterios para los proyectos locales admisibles?
- ¿Qué estándares aplicamos?
- ¿Cómo llevamos una implementación local exitosa a una solución global en toda la
empresa?
- ¿Quién tiene que autorizar modificaciones de SAP y objetos globales?

SAP Solution Manager contiene la información que necesita para responder a esta
pregunta. Además, SAP organiza cursos y talleres además de proporcionar servicios de
consultoría.

Proyecto piloto
Divida las diferentes necesidades en una secuencia de proyectos más pequeños. El primer
proyecto, llamado proyecto piloto, es el más importante porque en él, se deben crear todos
los objetos comunes.

© Copyright. Reservados todos los derechos. 181

Capítulo 5 : Proceso de modelado

Figura 133: Proyecto piloto

Un proyecto piloto adecuado cumple los siguientes objetivos:

● Resuelve un problema real urgente
● Utiliza objetos estándar que se utilizan posteriormente
● Ayuda a adquirir experiencia
● Consigue la aceptación del usuario

Por lo tanto, debería contener problemas típicos, pero debería ser lo suficientemente fácil
como para producir resultados rápidos. Es bueno si muchos de ellos pueden ser realizados
por objetos estándar de SAP (contenido de BI o SAP HANA Live).

La secuencia de proyectos
Al planificar los proyectos subsiguientes, tenga en cuenta lo siguiente:
● Evitar conflictos y cuellos de botella de recursos. Intente programar diferentes proyectos
en diferentes intervalos de tiempo.
● Tenga en cuenta las dependencias con los proyectos planificados en los sistemas fuente.
Espere con el proyecto SAP BW hasta que las modificaciones se completen en el sistema
fuente.
● En algunos casos, una subsidiaria individual tiene requisitos específicos que no están
cubiertos por proyectos "globales" en toda la empresa. Los proyectos locales de
subsidiarias individuales deben respetar las decisiones globales y no deben modificar los
objetos globales.

182 © Copyright. Reservados todos los derechos.

 Lección: Definición de la secuencia de proyectos de SAP BW/4HANA

Figura 134: Proyecto global

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Definir una secuencia de proyectos SAP BW

© Copyright. Reservados todos los derechos. 183

Capítulo 5 : Proceso de modelado

184 © Copyright. Reservados todos los derechos.

 Capítulo 5
Lección 2
Planificación de las fases de un proyecto de
SAP BW/4HANA

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Enumerar las cinco fases de un proyecto SAP BW
● Comprender la fase de preparación
● Comprender la fase de blueprint empresarial
● Comprender la fase de realización
● Comprender la fase de preparación final
● Comprender la fase de entrada en productivo y soporte

Fases de proyectos SAP BW

Este curso presenta un modelo de procedimiento simplificado que le guía a través de los
pasos más importantes en la fase de modelado de su proyecto. Cada fase finaliza con una
revisión que es un hito del proyecto y proporciona toda la información y los objetos
necesarios para iniciar la siguiente fase.

Figura 135: Fases de un proyecto SAP BW

© Copyright. Reservados todos los derechos. 185

Capítulo 5 : Proceso de modelado

Los proyectos SAP BW implican las siguientes fases:

1. Preparación del proyecto

El objetivo de esta fase es proporcionar la planificación inicial y la preparación para su
proyecto SAP, y establecer el alcance, la organización y la infraestructura del proyecto.
Enfoque en la disponibilidad de recursos (presupuesto, empleados, expertos). Defina los
estándares del proyecto como, por ejemplo, cómo y cuándo comunicar el progreso y los
retrasos del proyecto. La preparación del proyecto finaliza con una revisión conceptual.
Esta revisión refleja que el presupuesto es suficiente para el alcance y que el equipo
proporciona las habilidades necesarias.

2. Plano empresarial
El objetivo de esta fase es lograr un entendimiento común de cómo la empresa pretende
operar su negocio dentro de la aplicación SAP. El resultado es el plano empresarial, una
documentación detallada de los resultados recopilados durante los talleres de requisitos.
El documento de blueprint empresarial representa los requisitos del proceso empresarial
de la empresa. Es la declaración acordada de cómo la empresa pretende ejecutar su
negocio dentro del sistema SAP, desde el resumen de la arquitectura del sistema hasta
propiedades detalladas del objeto. La línea de negocio debe aprobar la aceptación parcial
del concepto de datos maestros y del concepto de datos transaccionales.

3. Realización
El objetivo de esta fase es implementar todos los requisitos del proceso empresarial
basados en el plano empresarial. Cree los objetos necesarios en SAP HANA y SAP BW,
primero para los datos maestros y después para los datos transaccionales. Establecer
InfoSitios, mecanismos de carga e informes. En la revisión de la configuración, verifique
que todas las definiciones de la fase de anteproyecto se reflejan en el sistema y que los
datos se han entregado tal y como se ha definido.

4. Preparación final
El objetivo de esta fase es completar la preparación final (incluidas las pruebas, la
formación del usuario final, la gestión del sistema y las actividades de transposición) para
finalizar su preparación para la entrada en productivo. La fase de preparación final
también sirve para resolver todos los problemas críticos pendientes. Una vez finalizada
con éxito esta fase, estará listo para ejecutar su empresa en su sistema SAP productivo.
Documentar los resultados de la prueba en una revisión de desempeño.

5. Puesta en marcha y soporte

El objetivo de esta fase es pasar de un entorno de preproducción orientado al proyecto a
una operación de producción en vivo. Las ampliaciones se pueden desarrollar en
pequeños ciclos de liberación de ampliación. Planifique detenidamente las modificaciones
de objetos que se utilizan en varios proyectos. Estos objetos se deben registrar en
órdenes de transporte separadas.

En esta lección, presentamos un roadmap de implementación que forma el marco metódico

para las fases necesarias para implementar una solución SAP. Incluye las tareas de gestión de
proyectos necesarias, la configuración de la solución del sistema, así como características
técnicas, procedimientos de prueba y conceptos de capacitación. La metodología del
roadmap de implementación le ayuda a utilizar estos requisitos como base para crear el
modelo de datos.

186 © Copyright. Reservados todos los derechos.

 Lección: Planificación de las fases de un proyecto de SAP BW/4HANA

Nota:
Debe aclarar una serie de puntos en cada etapa antes de añadir los requisitos al
roadmap de implementación. Al hacerlo, se identifican los problemas de forma
temprana y se reduce el tiempo total necesario. Además, descarta la posibilidad
de que surjan diferentes expectativas a nivel de proyecto o de proceso.

La fase de preparación del proyecto

Tareas de la fase de preparación
¿Qué aspectos deben tenerse en cuenta para una implementación exitosa del proyecto?
Los especialistas de SAP examinan el alcance del proyecto, la organización del proyecto, los
estándares del proyecto y la disponibilidad de recursos. La imagen, La fase de preparación del
proyecto, muestra algunas de las tareas de la primera fase.

Figura 136: La fase de preparación del proyecto

La primera fase del proyecto se centra en preparar todo lo necesario para un proyecto exitoso
y en los estándares del proyecto.
Para la tarea de definición del alcance, defina qué partes de la organización, divisiones, áreas
regionales y sistemas están implicadas. Definir claramente lo que es imprescindible, lo bueno
de tener y lo que no está dentro del alcance del proyecto.
Para la tarea de asignación de recursos, busque y solicite el hardware necesario, planifique y
reserve el presupuesto, alquile o asigne salas de reuniones y proyectos, y como período de
tiempo, programe reuniones del proyecto e hitos. Defina quién informa a qué coordinador y
planifica reuniones regulares para las actualizaciones de estado.
Asignar responsabilidades. Busque los miembros del equipo del proyecto según los roles
necesarios en el proyecto. Póngase en contacto con los usuarios empresariales desde el
principio para beneficiarse de los cambios y motivarlos, encontrar a alguien de todas las

© Copyright. Reservados todos los derechos. 187

Capítulo 5 : Proceso de modelado

organizaciones implicadas. Encuentre personal de TI y gerencia que brinde soporte al

proyecto y trabajen juntos. Incluya SAP Consulting.
Al seleccionar el método o la instancia del proyecto, siga la propuesta de esta sección. Al
elegir el método de implementación, plantéese aprovechar las soluciones de rápida
implantación. Con las soluciones de rápida implantación, los consultores de SAP le ayudan a
formular las preguntas correctas para adaptar los estándares de mejores prácticas a sus
necesidades individuales.
La última tarea es proporcionar acceso a la información sobre el proyecto a todos los
implicados. Una unidad de participación en el proyecto es un buen lugar para almacenar
informes de estado del proyecto y los resultados de las fases del proyecto finalizado para las
fases subsiguientes. Defina cómo debatir preguntas abiertas y cómo resolver conflictos.

Recomendaciones para la fase de preparación

Aplique las siguientes recomendaciones durante la fase de preparación:
● Definir claramente lo que es imprescindible, lo bueno de tener y lo que no está en el
alcance del proyecto.
● Definir reuniones para actualizaciones de estado.
● Informar a todos en una fase temprana, especialmente a los usuarios empresariales y a TI.
● Utilice las soluciones de rápida implantación de SAP.
● Mantenga esta fase corta, pero asegúrese de que todos los miembros del equipo de
proyecto estén seguros sobre el objetivo del proyecto, su rol y los métodos de
cooperación. Reúna a todos al menos una vez, incluso si provienen de diferentes
ubicaciones de negocio.

La fase del anteproyecto de negocio

En la imagen "Fase de plano empresarial" se enumeran algunas de las áreas de decisión del
modelo de gobernanza.

Figura 137: La fase del anteproyecto de negocio

188 © Copyright. Reservados todos los derechos.

 Lección: Planificación de las fases de un proyecto de SAP BW/4HANA

Toda la segunda fase del proyecto se centra en la recopilación de requisitos. El plano

empresarial de SAP es una documentación completa y detallada de los resultados
recopilados durante los talleres de requisitos. Documenta los requisitos del proceso
empresarial de la empresa.

Tareas de la fase de blueprint empresarial

La fase del plano empresarial consta de las siguientes tareas:
● Analice los procesos empresariales. Recopilar indicadores de rendimiento clave
(indicadores) de los procesos empresariales y los roles de la empresa.
● Analizar procesos de planificación y definir el nivel de planificación.
● Analice el proceso de información. Recopilar los requisitos de información centrales e
individuales, definir el nivel de informes y el concepto de autorización.
● Analice el concepto de gestión de informes. Defina qué informes deben entregarse como
informes estándar diseñados y qué posibilidades de generación de informes se definen
como informes de autoservicio con posibilidades de navegación flexibles.
● Analizar requisitos a nivel de estructuras de datos. Verifique la disponibilidad de los datos
y la granularidad disponible.

A partir del plano empresarial, puede derivar un concepto de implementación que debería
cubrir al menos los siguientes puntos:
● Procedimiento para integrar escenarios o datos globales y locales
● Datos maestros
● Los datos variables
● Concepto de Enterprise Data Warehouse (EDW) (definir capas)
● Concepto de archivo
● Modelo de datos, flujo de datos, destinos de datos, objetos SAP BW
● Convenciones para fijar nombres
● Concepto de autorización
● Concepto operativo
● Procedimiento para integrar modelos de datos
● Concepto de transporte
● Pautas de documentación

Los temas especiales adicionales u otros comentarios relacionados con los temas incluyen
los siguientes:
● Conversión de moneda, unidades, conversión de unidades
● Modificaciones
● Transferencia inicial de datos
● Tratamiento delta
● Gestión de contenido de BI

© Copyright. Reservados todos los derechos. 189

Capítulo 5 : Proceso de modelado

● Gestión de responsabilidades de objeto

Recomendaciones para la fase de Plano empresarial

Aplique las siguientes recomendaciones durante la fase de blueprint empresarial:
● Mantenga las entrevistas precisas y breves.
● No utilice demasiada terminología de SAP BW.
● Observe los informes existentes para averiguar qué debería ser mejor. (Pídale a sus socios
de entrevistas que traigan informes existentes y que sigan una ruta de desglose típica).
● Defina anticipadamente el concepto de autorización.

Definición de modelo de datos

Antes de iniciar la implementación, se requiere una definición de modelo de datos. Esta
definición de modelo debe contener los siguientes temas:
● Enfoque de modelado
Decida qué requisitos se realizarán como vistas SAP HANA virtuales y cuáles como
almacenamiento permanente en SAP BW.
● Arquitectura de LSA++
Diseñe el concepto de capa de datos (vistas modulares, concepto de flujo de datos).
● Concepto de datos maestros o definición de InfoSitio
Decida qué entidades empresariales se modelarán basadas en campos (sin dominios de
datos maestros) y cuáles basadas en InfoObjeto, con posibles textos dependientes del
idioma y del tiempo, atributos dependientes del tiempo y jerarquías. Decida para datos
transaccionales, si el almacenamiento físico en SAP BW está previsto, o si se prefiere el
acceso virtual para informes en tiempo real (o ambos). Defina las propiedades detalladas
de los objetos implicados. Definir los mecanismos de extracción y armonización, y los
cálculos.
● Temas especiales
Definir conversión de unidad y divisa, idiomas, husos horarios y áreas de trabajo.
● Análisis de contenido
Seleccione contenido BI útil y defina si los objetos de BI Content se activan sin
modificaciones, con modificaciones o se copian.
● Procesos por lotes
Defina la frecuencia con la que se cargan los registros de datos. ¿Cuál es el período de un
ciclo de carga de datos? ¿Se requieren cargas completas o instantáneas? ¿Se pueden
utilizar mecanismos delta y en función de qué criterios?

190 © Copyright. Reservados todos los derechos.

 Lección: Planificación de las fases de un proyecto de SAP BW/4HANA

Figura 138: Definición de modelo de datos

Recomendaciones para la definición del modelo de datos

Para desarrollar modelos de datos, utilice un modelo de procedimiento estándar. Siga la
propuesta de esta unidad.
Planifique una infraestructura de tres sistemas y un sistema de prueba separado para probar
la viabilidad técnica.
Manténgalo sencillo. Mantenerlo flexible. Habrá cambios en los requisitos.

© Copyright. Reservados todos los derechos. 191

Capítulo 5 : Proceso de modelado

La fase de realización

Figura 139: La fase de realización

Tareas de la fase de realización

La tarea de esta fase es la implementación. La fase de realización implica la configuración de
lo siguiente:
● Infraestructura de transporte
Conectar sistemas fuente. Instale los dominios de transporte. Fije las opciones de
modificación de objetos.
● Vistas SAP HANA
Cree vistas y defina sus propiedades.
● Temas especiales de SAP BW
Crear husos horarios, conversiones de moneda
● InfoObjetos, InfoSitio
Activar y copiar objetos de contenido. Crear InfoObjetos definidos por el cliente.
● Informes y aplicaciones
Genere informes, dashboards, aplicaciones de Design Studio y aplicaciones basadas en
Java.
● Documentación
Crear documentación funcional del diseño y documentación técnica de los objetos de SAP
BW.

192 © Copyright. Reservados todos los derechos.

 Lección: Planificación de las fases de un proyecto de SAP BW/4HANA

● Procesos por lotes

Inicializar el mecanismo delta. Cargar datos. Crear cadenas de procesos.

Recomendaciones para la fase de realización

Aplique las siguientes recomendaciones durante la fase de realización:
● Utilizar copias de objetos de contenido BI excepto en casos simples (características de
tiempo, país, versión).
● Implemente los objetos en el orden de los procesos ETL.
● Escribir documentación durante la creación de objetos. Proporcione no solo el formato
técnico, sino también la motivación y los límites.
● Si necesita ficheros planos, distribuya ficheros de muestra con el formato técnico
correcto.

La fase de preparación final

Figura 140: La fase de preparación final

Tareas de la fase de preparación final

En esta fase, instale y verifique todos los procesos necesarios para iniciar una operación
regular del almacén de datos, incluidos los siguientes:
● Procesos ETL
Planificar cadenas de procesos periódicamente.
● Organización de test
Realice pruebas técnicas, observe el trace de rendimiento y optimice el rendimiento donde
no sea aceptable.
● Concepto operativo
Implementar la estrategia de copia de seguridad de la base de datos, iniciar la supervisión
del volumen de datos, la supervisión de jobs de fondo, la supervisión de sentencias de
larga duración para sentencias SQL lentas y funciones de supervisión similares. Cree

© Copyright. Reservados todos los derechos. 193

Capítulo 5 : Proceso de modelado

usuarios, roles y autorizaciones en SAP BW y SAP HANA, según el concepto de rol y

autorización.
● Servicios SAP GoingLive
Desarrollar un programa de capacitación y ofrecer soporte in situ durante los primeros
días que un usuario de negocio trabaja con el nuevo almacén de datos.

Recomendaciones para la fase de preparación final

Aplique las siguientes recomendaciones durante la fase de preparación final:
● Definir benchmarks para tests. Piense en casos especiales cuando pruebe la
funcionalidad, como caracteres no imprimibles en fuentes de archivos planos, o regalos
con un valor de ventas de 0.
● Utilice BI content (estadística), el código de transacción DE SAP NETWEAVER ST03N y el
cockpit de SAP HANA para ver cuánto espacio de almacenamiento se consume, cuántos
registros se almacenan y cuánto tiempo tarda la ejecución de la consulta.

La fase de entrada en productivo y soporte

Figura 141: La fase de entrada en productivo y soporte

Tareas de la fase de entrada en productivo y soporte

Las siguientes tareas se deben cumplir continuamente incluso después de la entrada en
productivo.
● Optimización del sistema
Realizar actualizaciones de la base de datos y del sistema SAP NetWeaver de acuerdo con
una estrategia, añadir un servidor de SAP HANA para obtener más datos si es necesario
("escalar hacia afuera"), realizar un concepto de datos de acceso frecuente o frecuente,
adaptar los parámetros del sistema en el sistema SAP NetWeaver y en la base de datos de
SAP HANA.
● Acuerdo sobre el nivel de servicio

194 © Copyright. Reservados todos los derechos.

 Lección: Planificación de las fases de un proyecto de SAP BW/4HANA

Cree un centro de competencias de BI (soporte de primer nivel) y procedimientos

estándar para la producción y publicación de informes y el mantenimiento de usuarios.
● Concepto de archivo
Crear intervalos de tiempo para el almacenamiento nearline y los archivos offline. Archivar
información de supervisión de solicitud.
● Mejoras continuas
Generar informes. Ampliar los dominios de LSA. Planificar proyectos subsiguientes.
● Soporte continuo
Proporcionar notas y parches de SAP.

Recomendaciones para la fase de entrada en productivo y soporte

Los siguientes consejos le ayudan a organizar el soporte y el funcionamiento del sistema SAP
BW:
● Programe tareas de limpieza de SAP BW para deshacerse de la información de estado
obsoleta y de los detalles de supervisión del sistema. Esto se puede hacer en la sección de
administración del código de transacción RSA1.

● Definir usuarios empresariales técnicamente competentes como "usuarios clave".

Proporcionan un soporte de primer nivel para todos los usuarios empresariales y analizan
las mejoras con el equipo de TI de BI.
● Cree un centro de competencias de BI en el que el soporte de primer nivel, el soporte de
segundo nivel y el equipo de TI de BI almacenen toda la información relativa a la utilización
de SAP BI y recopilen experiencia con el almacén de datos.
● Anclar una impresión de los resúmenes de arquitectura más importantes, flujos de datos y
roles en el muro.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Enumerar las cinco fases de un proyecto SAP BW
● Comprender la fase de preparación
● Comprender la fase de blueprint empresarial
● Comprender la fase de realización
● Comprender la fase de preparación final
● Comprender la fase de entrada en productivo y soporte

© Copyright. Reservados todos los derechos. 195

Capítulo 5 : Proceso de modelado

196 © Copyright. Reservados todos los derechos.

 Capítulo 5
Lección 3
Desarrollo de un modelo de datos de SAP BW/
4HANA

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Estructurar el proceso de creación del modelo de datos en la fase de plano empresarial
● Realizar un análisis de requisitos
● Crear un resumen de la arquitectura
● Crear un modelo de datos lógico
● Desarrollar un modelo de datos de SAP BW/4HANA

Escenario empresarial y objetivo de un modelo de datos

Ventajas del diseño de un modelo de datos
Un modelo de datos es un resumen completo y completo de todas las decisiones necesarias
para la fase de implementación. Contiene decisiones de todos los objetos y sus propiedades.
El diseño de un modelo de datos tiene las siguientes ventajas:

● Requisitos de estructuración y verificación

Un modelo de datos incorpora y visualiza la información de los talleres de requisitos. No se
puede diseñar con requisitos que no son viables.
● Optimización de la arquitectura
Un buen diseño de modelo conduce a una forma integral y flexible de armonizar los datos.
● Ahorro de espacio de almacenamiento
En un modelo, identifique y reduzca la redundancia y combine los datos existentes.
● Proporcionar pautas para la fase de realización
El modelo de datos visualiza el flujo de datos y las dependencias entre objetos.
● Mejorar la coherencia
Un modelo de datos documenta las decisiones técnicas que se pueden verificar en una
revisión empresarial.

Diseño del modelo de datos en la fase de plano empresarial

Existen dos formas de derivar el modelo de datos: basado en fuente de datos (ascendente) y
basado en ratios (descendente).

© Copyright. Reservados todos los derechos. 197

Capítulo 5 : Proceso de modelado

Enfoque de fuente de datos (ascendente)

El enfoque ascendente viene impulsado por la pregunta "¿Qué podemos ofrecer?", a partir de
fuentes existentes. Es útil para un proyecto piloto.
Determine las fuentes de datos y los campos relevantes. Puede echar un vistazo al contenido
BI disponible y cómo se asigna a los campos que ha encontrado para InfoObjetos. En función
de la información fuente, analice qué objetos de BI Content (flujo de datos ascendente) son
necesarios para el escenario. A continuación, determine InfoSitios y queries.
Si su proyecto se basa en la planificación de recursos empresariales (ERP), o si uno de los
sistemas fuente es un sistema SAP ERP, se recomienda el enfoque ascendente. Debido a que
el cliente ya sabe mucho sobre el sistema SAP ERP, normalmente está interesado en tener los
datos correctos en SAP BW. Por lo tanto, es más fácil para un consultor de SAP BW utilizar
los términos relacionados con el sistema SAP, ya que son familiares para el cliente.

Enfoque basado en ratios (descendente)

El enfoque descendente está impulsado por la pregunta "¿Qué desea?", empezando por los
KPI deseados.
Un enfoque basado en ratios incluye los siguientes pasos:

1. Obtenga una idea clara de sus requisitos, especialmente los ratios.

2. Desarrollar un modelo de datos lógico sin detalles técnicos.

3. Derive un modelo basado en una vista de cálculo de SAP HANA o un modelo de SAP BW
con detalles técnicos. En un modelo de SAP BW, defina objetos DataStore avanzados para
datos transaccionales e InfoObjetos para datos maestros (relaciones de atributos, textos
y jerarquías) y CompositeProviders para combinarlos.

Al final, puede verificar si hay contenido BI adecuado. Busque fuentes relevantes para las
consultas necesarias y compare las propiedades de los objetos de contenido BI con su diseño
de modelo.

Estrategia mixta

Figura 142: Estrategia mixta para la fase de anteproyecto de negocio

198 © Copyright. Reservados todos los derechos.

 Lección: Desarrollo de un modelo de datos de SAP BW/4HANA

El enfoque principal en un proyecto de presentación de informes debería ser un enfoque

mixto. De forma similar a un enfoque descendente, comience desde el proceso de negocio e
identifique sus KPI. A continuación, busque posibles fuentes. Identifique cómo necesita
transformar los ratios básicos. Busque el contenido de BI correspondiente. Si la búsqueda de
los ratios correspondientes no es correcta, intente un enfoque ascendente. Si faltan campos
obligatorios, debe verificar si se pueden añadir, es decir, si existen en el sistema. En un
escenario mixto, los escenarios descendente y ascendente no pueden considerarse
completamente separados entre sí. El uso simultáneo de ambos escenarios hace que el
proceso de modelado sea más eficiente.
Otra opción es comenzar con un enfoque descendente y añadir nuevos objetos de acuerdo
con un enfoque ascendente.
Es importante comprender la base empresarial y el contexto del modelo. Una descripción
técnica por sí sola nunca dará lugar a un resultado completo.

Propuesta de método descendente para derivar un modelo de datos

El modelado de datos desempeña el papel más importante en su diseño de SAP BW. Diseñar
un modelo de datos corporativo y consistente es la única manera de evitar tener aplicaciones
aisladas y garantizar que pueda proporcionar la información correcta a los empleados
relevantes. Los problemas de redundancia también se deben tener en cuenta en el modelado
de datos. La relación entre todo lo anterior se hará evidente en este curso.
La creación de un modelo de datos de SAP BW requiere una preparación exhaustiva. Uno de
los pasos más importantes es analizar cuidadosamente los requisitos de futuros modelos de
datos de SAP BW. En este curso, sin embargo, nos centramos en los requisitos actuales.

Figura 143: Propuesta de método descendente para derivar un modelo de datos

Proponemos el siguiente proceso para crear un modelo de datos:

© Copyright. Reservados todos los derechos. 199

Capítulo 5 : Proceso de modelado

1. Realice un análisis de necesidades.

En este paso, debe recopilar sus requisitos de informe definitivos en colaboración con el
patrocinador del proyecto, el departamento de usuarios y los usuarios. Esta es la base
para el modelo de datos.

2. Prepare una matriz de ratios.

Primero debe estructurar la información del análisis de requisitos. Es posible que deba
estructurar las características y los ratios analizados en una visualización de tabla y definir
las relaciones iniciales entre las características y los ratios. Proporcionamos dos ejemplos
de visualizaciones de tabla en una sección posterior, una simple y otra más compleja.

3. Planifique un modelo de resumen de la arquitectura.

Debe planificar con antelación qué objetos físicos y lógicos se necesitarán para
implementar los requisitos. Intente mantener el modelo de arquitectura simple. Para
reducir los costes de almacenamiento, no incluya demasiados objetos de almacenamiento
físicos. Trabajar con proveedores compuestos para proporcionar un subconjunto de
campos o una combinación de diferentes InfoSitios físicos a los usuarios finales.
Como se describió anteriormente, hay capas estándar dentro de la arquitectura escalable
en capas (LSA++) para manejar este aspecto.

4. Desarrolle un modelo lógico de datos y compárelo con el contenido de BI.

Puede utilizar la visualización de tabla para desarrollar el modelo de datos lógico inicial.
Aquí relaciona y agrupa las características y los ratios, y puede encontrar un modelo de
burbuja o un diagrama de modelo de entidad-relación (ERM) útil para visualizar las
relaciones entre diferentes características. Sin embargo, primero compare los requisitos
de información con el extractor de BI Content. Analice la definición de las tablas originales.
Si los datos proceden de una fuente de datos que no es de SAP, debe analizar el modelo
de datos del sistema externo. Si el extractor estándar de SAP no proporciona los datos
que necesita, puede adaptarlos a sus necesidades. También puede crear su propio
extractor. Sin embargo, tenga en cuenta que modificar el extractor existente o crear uno
propio conlleva un esfuerzo de proyecto adicional.

5. Complete el modelo de datos SAP BW.

El modelo de datos lógico ahora se convierte en un modelo de datos SAP BW (como una
definición aDSO detallada) o un modelo de vista SAP HANA (como un esquema estrella).

Objetivo de un análisis de requisitos

El objetivo de un análisis de requisitos es averiguar qué información se necesita para la
generación de informes. Recopile información de departamentos o usuarios finales
específicos sobre lo que necesitan para ejecutar o evaluar el proceso empresarial.

200 © Copyright. Reservados todos los derechos.

 Lección: Desarrollo de un modelo de datos de SAP BW/4HANA

Figura 144: Creación de matriz de ratios

Como parte del proceso de recopilación de información, define puntos de decisión

específicos en las características de diseño (como el nivel de granularidad de los datos y el
enfoque para realizar el seguimiento del historial).
Mientras investiga sobre los requisitos, lo más probable es que encuentre diferentes vistas
del mismo proceso. Estas diferencias deben resolverse.
La información que obtiene del proceso de entrevista es la base de conocimientos que
utilizará en el proceso de diseño. Durante el proceso de recopilación de información, puede
comenzar a recopilar las expectativas de los entrevistados.
En esta etapa, debe identificar los distintos puntos que debe considerar durante el proceso de
entrevista.
Su primera tarea es recopilar información sobre el proceso empresarial y los informes
deseados. A continuación, establezca dónde puede obtener estos datos, lo que implica
identificar el sistema fuente y analizar sus estructuras de datos. Por último, cree un modelo
de datos de SAP BW basado en características y ratios. Necesita este procedimiento
estructurado.
Debe analizar los procesos relevantes en los sistemas fuente y compilar la información
necesaria. Para ello, el departamento del usuario, los usuarios y el equipo de proyecto de SAP
BW deben trabajar en estrecha colaboración. No subestime el tiempo necesario para esta
fase del proyecto.

El proceso de análisis de requisitos

La imagen "Proceso de recopilación de información de análisis de requisitos" muestra las
preguntas que deben abordarse durante el análisis de requisitos, los subpasos
correspondientes y las fuentes de información.

© Copyright. Reservados todos los derechos. 201

Capítulo 5 : Proceso de modelado

Figura 145: Proceso de recopilación de información de análisis de requisitos

Durante el análisis de requisitos, consulte las siguientes fuentes de información:

● Enfoque del proyecto
Verifique el alcance y el objetivo del proyecto con el patrocinador.
● Entrevistas
Identificar a los participantes para las entrevistas (gerencia) y determinar las condiciones
(estrategia empresarial, productos, mercados, clientes, objetivos, alcance del proyecto)
como base para los talleres operativos (con los empleados).
● Talleres
Realizar un taller con los empleados de los departamentos y determinar propuestas para
ratios (KPI) y características.
● Documentación
Documentar los resultados recopilados (características, ratios, cálculos, descripciones) y
determinar qué áreas ya tienen KPI.
● Análisis de carencias
Determine las diferencias entre los sistemas de informes anteriores.
● Requisitos de información
Con los departamentos (a través de los talleres), determine los requisitos de gestión de
informes utilizando las características y ratios recopilados (documentación).

En general, proceda en una secuencia lógica:

1. Requisitos de información:
¿Qué se debe analizar? ¿Cuáles son los KPI?

2. Fuentes de datos:

202 © Copyright. Reservados todos los derechos.

 Lección: Desarrollo de un modelo de datos de SAP BW/4HANA

¿Dónde tenemos información básica de qué KPI se pueden derivar?

3. Transformaciones:
¿Cómo debemos asignar, transformar, filtrar los datos fuente?

4. Requisitos de almacenamiento:
¿Esta transformación requiere valores intermedios persistentes confiables? ¿Se requiere
almacenamiento para una base de datos estable? ¿Se desea acceso virtual para cumplir
con los requisitos en tiempo real?

Preguntas típicas de la entrevista

Pregunte sobre las propiedades del informe:
● ¿Qué atributos y medidas son necesarios?
● ¿Cuál es el nivel más detallado que se necesita? (¿Es el nivel de documento o una
combinación de producto, tiempo y cliente?) ¿Cómo depende el nivel de granularidad de la
antigüedad de los datos?
● ¿Qué vías de acceso de desglose se utilizan normalmente? ¿Qué jerarquías se utilizan?
● ¿Cómo se calculan los valores? (Por ejemplo, ¿es un valor porcentual basado en el
volumen o el peso? ¿Cómo se calcula un margen?)
● ¿Cómo se deben agregar valores de los detalles? (¿Como valor máximo, mínimo, total,
promedio o sin valor? ¿Qué unidades y monedas deben tenerse en cuenta?)
● ¿Cómo se deben visualizar las características y los ratios? (¿Como textos, IDs técnicos o
ambos? ¿Cuántos dígitos hay para los valores?)
● ¿En qué nivel deben definirse las autorizaciones?

Haga preguntas para determinar los requisitos de aprovisionamiento y almacenamiento de

datos:
● ¿Qué datos se necesitan de qué fuente? (¿De qué sistemas SAP? ¿Qué datos externos?)
● ¿Se necesitan datos en tiempo real? ¿Qué latencia es aceptable?
● ¿En qué intervalos deben cargarse los valores? (Por ejemplo, cada seis horas para delta
transaccional, una vez al día para datos maestros, una vez por semana para una
instantánea de transacción).
● ¿Es necesario que la información antigua siga siendo accesible? (estado anterior o valores
anteriores en datos transaccionales, atributos dependientes del tiempo y jerarquías)
● ¿Cuántos años atrás se necesitan valores históricos? ¿Es aceptable un menor rendimiento
para los datos antiguos?
● ¿Qué intervalos de tiempo se pueden trasladar a ubicaciones de almacenamiento más
baratas, archivos accesibles o archivos offline?
● ¿Visualiza valores de atributo históricos basados en fecha clave o como verdad histórica?
● ¿Cuántos registros o KB se pueden esperar por carga?
● ¿Cuántos usuarios simultáneos accederán a los datos?

Haga preguntas para determinar las transformaciones necesarias:

© Copyright. Reservados todos los derechos. 203

Capítulo 5 : Proceso de modelado

● ¿Cuáles son los sistemas y las tablas o los informes existentes que contienen los valores
originales? ¿Cuáles son los formatos en los sistemas fuente? ¿Se garantiza la integridad
referencial?
● ¿Cómo se gestionan los cambios en la fuente? (¿Cuál es la clave única? ¿Se pueden
actualizar, insertar, borrar registros?)
● ¿Se necesitan instantáneas en momentos específicos?
● ¿Cómo se deben tratar las extracciones repetidas para la misma clave? (¿Marcar como
error? ¿Desea añadir un cronomarcador actual? ¿Sobrescribir? ¿Desea crear un log de
modificaciones?)
● ¿En qué se diferencian la semántica, las unidades, las monedas y los cálculos entre
distintas fuentes? ¿Cuál debería ser la verdad de la empresa?
● ¿Necesita asignar datos maestros, como ID de producto antiguos a nuevos, y dónde
encuentra la tabla de asignación? ¿Es necesario proporcionar la información original?
● ¿Tiene que filtrar los valores incorrectos? ¿Qué se debe tratar como errores?
● ¿Qué información debe añadirse?

Consejos para diferentes fuentes de información

Es importante definir la cobertura correcta para entrevistas de personal. Debe tener en
cuenta diferentes regiones (por ejemplo, los empleados del departamento de ventas de cada
país), departamentos corporativos y niveles (el nivel ejecutivo para determinar los requisitos
para la gestión y el nivel operativo para determinar los requisitos para los empleados del
departamento de ventas en el campo).
La empresa puede ayudar a mejorar los informes existentes para encontrar un mayor nivel de
beneficios.
Los departamentos de TI pueden ayudar a identificar las fuentes de información que la
empresa necesita. Esto ofrece una visión más realista de la información disponible y ayuda a
identificar qué problemas de autorización deben tenerse en cuenta.
Comprender los procesos empresariales de los usuarios y saber qué componentes analíticos
deben cubrirse en los informes de BI son dos requisitos definidos para el modelado correcto.
A menudo, los usuarios no pueden expresar sus necesidades de forma técnica, por lo que
debe convertirlas en un formato técnico.
La creación paralela de prototipos es útil para obtener una comprensión común del proceso
modelado. SAP HANA Live y BI Content pueden ayudar a crear un prototipo rápido (pero
concreto).
Además de hablar directamente con usuarios y clientes, existen otras fuentes de información
interesantes. Analice los roles de cada uno de los departamentos y establezca cómo se
distribuyen las tareas. Examine también los sistemas preexistentes para el sistema SAP BW y
la documentación de los informes existentes.

Estructuración de la información
Primero debe estructurar la información del análisis de requisitos. Es posible que deba
estructurar las características y los ratios analizados en una visualización de tabla y definir las
relaciones iniciales entre las características y los ratios. Proporcionamos dos ejemplos de
visualizaciones de tabla.
La imagen "Generación de matriz de ratio simple" muestra un ejemplo sencillo de la matriz de
ratios que contiene solo la información necesaria para los pasos siguientes. Muestra una

204 © Copyright. Reservados todos los derechos.

 Lección: Desarrollo de un modelo de datos de SAP BW/4HANA

forma formal de estructurar los requisitos de información que ha recopilado. El primer paso
es determinar qué ratios deben medirse (por ejemplo, cantidades, volúmenes, beneficios y
costes).

Figura 146: Generación de matriz de ratio simple

Los pasos implicados en la creación de una visualización de tabla (matriz de ratios) a partir de
un análisis de necesidades son los siguientes:

1. Recopilar ratios como filas.

a. Obtener KPI relevantes de entrevistas.

b. Determinar ratios base.

2. Para cada ratio, incorpore la granularidad temporal más detallada.

3. Reunir características como columnas.

a. Obtenga las características que describen los KPI a partir de entrevistas (enumere los
objetos de tratamiento básicos y sus atributos sin distinción).

b. Para cada característica, genere una nueva columna.

4. Asignar objetos de tratamiento a KPIs.

Para cada ratio, añada una marca (X) para todas las características que describen este
ratio

5. Agrupar ratios por estructura. La idea es que los ratios con el mismo conjunto de
características puedan estar en el mismo InfoSitio.

Cuestionamiento de la terminología
Diferentes entrevistadores pueden proporcionar respuestas diferentes. Tenga en cuenta que
las personas pueden utilizar términos diferentes para las mismas cosas, como "ID de
producto" y "número de producto".
Intente averiguar si realmente son los mismos. ¿Existe una diferencia semántica entre
"personal" y "número de empleados", o entre "ingresos de ventas" y "volumen de ventas"?
"Región" puede ser un área de ventas, una provincia o un continente. "Devoluciones" pueden
ser devoluciones al proveedor o devoluciones del cliente a la organización de ventas. El

© Copyright. Reservados todos los derechos. 205

Capítulo 5 : Proceso de modelado

"volumen de ventas neto" se puede calcular de diferentes maneras, por ejemplo, eliminando
impuestos o eliminando tarifas y descuentos adicionales. "País" puede hacer referencia al
país del cliente, el país de la organización de ventas o el país de la cuenta de costes.
Pídale a los socios de la entrevista que acuerden una definición. Si no es posible, acuerde una
terminología BW que distinga distintas entidades lo más claramente posible.

Integración de requisitos adicionales

Si existen necesidades diferentes, adapte las entradas en la matriz de ratios de las siguientes
maneras:

1. Si los nuevos entrevistadores mencionan otros KPI con otros ratios necesarios, añádalos
a la lista como filas nuevas.

2. Si los nuevos entrevistadores desean una referencia temporal más aproximada, deje la
más fina de los socios anteriores. Si necesitan características de tiempo más detalladas,
modifique la característica de tiempo a la más detallada.

3. Si los nuevos entrevistadores mencionan otras características, añádalas a la lista como

columnas nuevas.

4. Si los nuevos entrevistadores desean más asignaciones, añada marcas nuevas (X) y no
elimine las marcas antiguas.

5. Reagrupe los ratios.

Ampliación de una matriz de ratios

El gráfico, Ampliación de matriz de ratios, muestra ejemplos de ampliaciones de la matriz de
ratios.

Figura 147: Ampliación de matriz de ratio

También puede añadir cualquier tipo de información a la matriz de ratios que facilite los pasos
posteriores.
Añadir la unidad de medida (o moneda), ya sea fija ("KG" para kilogramo, o "UN" para piezas)
o diferente ("unidad original"), o ninguna ("1" como unidad).
Si espera o conoce contenido de SAP BI que cubre la necesidad, puede indicar el objeto de
contenido o, al menos, el componente de aplicación.

206 © Copyright. Reservados todos los derechos.

 Lección: Desarrollo de un modelo de datos de SAP BW/4HANA

Si sabe qué sistema fuente o incluso qué tabla está implicada, indíquelo en otra columna. Esto
le ayuda a reconocer dónde son relevantes los problemas de armonización.
Si está claro que un ratio no se puede evaluar para un determinado nivel de detalle
(característica), indíquelo con “-”. Si resulta que se ha solicitado este detalle, notifique
inmediatamente los problemas al solicitante.
Si una consulta más detallada revela que una característica se utiliza con diferentes objetos
de referencia, como país del cliente y país de la organización de ventas, añada más columnas.
Si una consulta más detallada revela que un ratio se utiliza en diferentes versiones, como el
volumen de ventas en la moneda original y el volumen de ventas en euros, o los valores netos
y brutos, copie la línea para generar dos líneas con las mismas asignaciones.
Agregue fórmulas para el cálculo, como las siguientes:
● "Conversión de moneda"
● “Conversión de unidades”
● “1:1” si no hay transformación
● "RKF" para ratio restringido, con una condición específica como "tipo de coste =
"almacenamiento"
● “CKF” para el ratio calculado con una fórmula como “artículos * precio” o “ingresos –
costes”

Los KPI del análisis de necesidades se desglosan hasta el nivel más bajo de los ratios base. Al
hacerlo, también debe tener en cuenta si estos ratios son ratios base o ratios calculados.
Añada nuevas líneas para los ratios base.
Si un ratio se calcula a partir de otros, se debe asignar el mismo nivel de detalle que para el
ratio calculado a los ratios base. Por ejemplo, si el beneficio se calcula a partir de los ingresos
y los costes, con valores detallados por producto, los costes y los ingresos también deben
proporcionarse por producto. Esto se indica con el texto rojo y las flechas de la figura.

Objetivo de un resumen de la arquitectura

La imagen, Creación de un modelo de resumen de arquitectura, muestra el segundo paso de
nuestra propuesta para derivar un modelo de datos: una visualización de los InfoSitios
necesarios de acuerdo con la arquitectura de LSA++.

Figura 148: Creación de un modelo de resumen de arquitectura

© Copyright. Reservados todos los derechos. 207

Capítulo 5 : Proceso de modelado

Un modelo de resumen de la arquitectura es un resumen de los objetos que se deben crear

para cumplir con los requisitos de reporting. Sirve como visualización de los InfoSitios que
deben crearse para el proyecto SAP BW.
En un nivel superior, enumera solo los data marts e InfoObjects. Una versión más detallada
contiene fuentes, sistemas fuente, transformaciones, otros objetos lógicos y las relaciones
entre ellos. Puede indicar qué objetos son virtuales sin su propio almacenamiento físico.

Proceso de creación de resumen de la arquitectura

El proceso de derivar un modelo de resumen de arquitectura a partir de una matriz de ratios
implica los siguientes pasos:

1. Definición de data marts y sus ratios.

2. Identificación de las fuentes.

3. Identificación de transformaciones.

4. Adición de más capas según LSA++.

5. Decisión sobre requisitos de almacenamiento físico (para almacenar datos de

instantáneas o para gestionar duplicados).

6. Identificación y reducción de despidos.

Definición de data mart y sus ratios

Al definir data marts y sus ratios, inicie la matriz de ratios con ratios agrupados por el
conjunto de características relevantes para ellos. Para cada grupo, defina un objeto data
mart. Para cada objeto data mart, liste los ratios.

Figura 149: Definición de data mart y sus ratios

Identificación de fuentes y transformaciones

Para cada par de data mart y fuente, indique cómo se deben derivar los ratios. Si se necesitan
valores adicionales en una transformación, añada más fuentes y destinos.

208 © Copyright. Reservados todos los derechos.

 Lección: Desarrollo de un modelo de datos de SAP BW/4HANA

Figura 150: Identificación de fuentes y transformaciones

Adición de capas
En la parte superior de cada data mart, añada un proveedor compuesto como interfaz para el
reporting. Añada una capa de propagador y, tal vez, capas adicionales para la adquisición de
datos.

Figura 151: Adición de capas

Requisitos de almacenamiento
Si los valores se pueden calcular con una fórmula simple, calcúlelos en una consulta (o vista
de cálculo de SAP HANA) en lugar de almacenar resultados en un data mart adicional. Elimine
el data mart del modelo de arquitectura. Para la capa de propagador, si se permiten las

© Copyright. Reservados todos los derechos. 209

Capítulo 5 : Proceso de modelado

modificaciones de claves existentes, utilice un ADSO estándar con log de modificaciones. Si

no hay modificaciones en los valores originales, utilice uno con funciones de compresión, pero
sin log de modificaciones. Si cada clave se proporciona una vez, utilice una InfoFuente en
lugar de un ADSO de propagador. Para data mart, decida si tiene una clave especificada o si
todas las características son clave.

Figura 152: Requisitos de almacenamiento

Modelo de arquitectura simple

En el siguiente ejercicio, creará un modelo de resumen de arquitectura. La imagen "Modelo de
arquitectura simple" muestra una posible solución.

Figura 153: Ejercicio: realizar el resumen de la arquitectura

210 © Copyright. Reservados todos los derechos.

 Lección: Desarrollo de un modelo de datos de SAP BW/4HANA

Objetivo de un modelo de datos lógico

La imagen "Creación de modelo lógico" presenta un paso para analizar las relaciones entre las
características y los ratios.

Figura 154: Creación de modelo lógico

Un modelo lógico de datos es una visualización gráfica de las relaciones que pueden existir
entre instancias de características y ratios. Ayuda a identificar qué características se pueden
modelar como atributos entre sí. Se basa en la lista de ratios y características de la matriz de
ratios.
Es importante saber qué características dependen de otras y qué propiedades de una
característica deben modelarse como datos maestros. Por lo tanto, se pueden utilizar varios
métodos de técnicas de visualización. En esta unidad se presentan dos alternativas: un
modelo de relación de entidad simple y un modelo de burbuja. Usar una de estas alternativas
es suficiente, y los modeladores experimentados a menudo omiten este paso. Sin embargo, el
proceso de diseño de modelos lógicos puede facilitar discusiones y pensamientos sobre
cómo representar el proceso de negocio sin ser canalizado por detalles técnicos.

Proceso de creación del modelo de datos lógico

Modelo entidad-relación simple
La imagen "Modelo entidad-relación simple" presenta una opción de visualización para las
relaciones entre entidades empresariales.

© Copyright. Reservados todos los derechos. 211

Capítulo 5 : Proceso de modelado

Figura 155: Modelo entidad-relación simple

Un modelo entidad-relación es un diagrama que contiene entidades o "posiciones", relaciones

entre ellas y atributos de las entidades y las relaciones.
Para crear un modelo entidad-relación simple, observe el diseño de la tabla de base de datos
o analice los datos existentes en la fuente, para averiguar qué características o
combinaciones son las características clave más básicas y cuáles son características de alto
nivel.
Las características de alto nivel con valores que (en un momento determinado) se
determinan mediante características clave de nivel inferior se denominan atributos.
Representan propiedades de las características clave. Por ejemplo, para cada producto, solo
hay una categoría. Pero la misma categoría puede tener varios productos. Esta relación se
describe como relación 1:N (“N” = muchos).
En el modelo entidad-relación simple que se propone aquí, una relación 1:N se visualiza con
una flecha o rama.
De hecho, otras características son independientes de las características clave. Como
ejemplo, tenga en cuenta el producto y el color. Para cada producto, puede haber varios
colores. Para cada color, puede haber varios productos. El color de relación:producto se
describe como relación N:M.
En el modelo entidad-relación simple que se propone aquí, una relación N:M se visualiza con
una rama doble. Si existe un ratio para una combinación de este tipo, se puede asignar en la
línea. Si diferentes atributos de características independientes son relevantes en un proyecto,
o si existen atributos de atributos, se puede combinar una cadena de entidades en una
imagen. Para que sea sencillo, no dibuje relaciones que sean obvias.
El proceso para dibujar un diagrama entidad-relación simple con las características de la
matriz de ratios implica los siguientes pasos:

212 © Copyright. Reservados todos los derechos.

 Lección: Desarrollo de un modelo de datos de SAP BW/4HANA

1. Para cada característica de la matriz de ratios, indique cómo se determina el dominio de

valores, cuántos valores aproximadamente contiene, si nulo es un valor aceptable y, si es
aceptable, qué indica nulo.

2. Averigüe cuáles son las características independientes de nivel inferior (características

clave).

3. Añada la lista de ratios a la combinación de características clave.

4. Añada más atributos disponibles.

5. Documente las suposiciones que haga.

Estos modelos le permiten analizar los requisitos en un nivel alto y facilitar la consulta con
usuarios y departamentos.

Consejo:
Para mantener el diagrama simple, utilice diagramas separados para cada data
mart.

Como alternativa al modelo entidad-relación simple, puede crear un diagrama de burbuja. El

objetivo del diagrama de burbujas, como para el modelo entidad-relación, es identificar sus
asuntos empresariales principales, como cliente, producto y organización, y describirlos
según sus propiedades clave.
En un diagrama de burbujas, los ratios se visualizan como un rectángulo y las características
son burbujas. Si hay más valores para una característica, la burbuja es mayor.
Tenga en cuenta los asuntos empresariales que son las principales perspectivas de gestión de
informes. Estos objetos de tratamiento se describen mediante atributos, que a menudo
agrupan y categorizan los objetos de tratamiento principales. Normalmente tienen una
relación 1:N, lo que significa que el asunto empresarial principal tiene la información más
detallada que su atributo.

© Copyright. Reservados todos los derechos. 213

Capítulo 5 : Proceso de modelado

Figura 156: Diagrama de burbujas

El proceso para generar diagramas de burbujas implica los siguientes pasos para cada objeto
(InfoSitio) tal y como se detalla en la figura Diagrama de burbujas:

1. Enumerar ratios en un rectángulo central.

2. Identifique sus principales objetos de tratamiento (características de desglose), como

cliente, producto, grupo de productos y organización, y añádalos como burbuja. Apunte a
ellos con flechas. Utilice burbujas más grandes si hay más valores.

3. Verifique las relaciones.

Para burbujas pequeñas, verifique si son atributos (relación 1:N) de burbujas más
grandes. Si están en una relación N:M, no dibuje una flecha. Añada más propiedades
(atributos) como burbujas más pequeñas. Añada flechas para relaciones 1:N (de grande a
pequeño).

4. Elimine las flechas de acceso directo.

Si hay una flecha que apunta a una burbuja que puede ser alcanzada por una secuencia de
flechas, solo mantenga las flechas en la secuencia más larga.

Nota:
No olvide la perspectiva del tiempo. Añada el nivel necesario más detallado.

Por último, la lista de ratios apunta a diferentes objetos de tratamiento que tienen una
relación N:M. (Por ejemplo, un cliente puede comprar varios productos o un producto puede
ser comprado por varios clientes. Los productos se venden en varias unidades
empresariales).

214 © Copyright. Reservados todos los derechos.

 Lección: Desarrollo de un modelo de datos de SAP BW/4HANA

Identificación de tipo de modelo

Desde el modelo lógico, conoce los campos necesarios (objetos de tratamiento) y sus
relaciones.

Figura 157: Identificación de tipo de modelo

La imagen "Identificación de tipo de modelo" muestra los casos en los que los modelos de
SAP BW/4HANA (físicos o virtuales) son los más adecuados y en los que los modelos de SAP
HANA (virtuales) son mejores. En cualquier caso, puede reducir la tarea de modelado y
acelerar la implementación verificando si los objetos estándar proporcionados por SAP se
ajustan a sus necesidades.
La verificación del contenido de BI para modelos BW/4HANA (o, de forma similar, SAP HANA
Live, para modelos de SAP HANA) es un proceso continuo que dura hasta que termina de
crear un modelo. Si desea trabajar con BI Content, le recomendamos que proceda de la
siguiente manera:

1. Defina las tareas y los roles de sus empleados. Determine los ratios necesarios o la
información que sus empleados necesitan para realizar sus tareas. Para ello, puede
utilizar el contenido BI basado en roles.

2. Compare los resultados de su análisis de requisitos y su modelo de datos con el contenido

de BI. Normalmente, se realiza una comparación descendente, es decir, se buscan ratios,
informes y aDSO en BI Content que son necesarios.

3. Determine las diferencias entre su propio modelo de datos y el contenido BI.

4. En función del tipo de objeto, puede ampliar o modificar el contenido BI, utilizarlo como
modelo de copia para sus propios objetos o crear sus propios objetos en su área de
nombres, independientemente del contenido BI.

© Copyright. Reservados todos los derechos. 215

Capítulo 5 : Proceso de modelado

Proceso de creación del modelo de datos detallado

Generación de un modelo de datos SAP HANA o SAP BW detallado
Su última tarea es convertir el modelo de datos lógico en un modelo de datos SAP HANA o
SAP BW detallado (dependiendo del destino de datos). Esta es la versión detallada del
modelo, que contiene toda la información necesaria para crear los objetos como contenido de
SAP HANA u objetos de SAP BW.
En esta fase, convierte un requisito en una opción de realización técnica. Por ejemplo, si los
usuarios empresariales desean ver valores actualizados, decide modelar un modelo lógico
como una vista de SAP HANA, pero si necesitan una instantánea conservada, utilice InfoSitios
de SAP BW. Al definir los campos clave de un objeto, se define el nivel de granularidad.
Si decide modelar un InfoSitio de SAP BW, decida por un enfoque basado en campos o en
InfoObjetos. Utilice un enfoque basado en campos si no necesita un dominio para los datos
maestros. Decida si una categoría se modelará como atributo o nivel de jerarquía en modelos
de datos maestros separados o si se guardará junto con cada registro. Este es un buen punto
de partida para una documentación.

Modelo SAP HANA: ¿modelos de datos maestros separados?

La imagen "Opciones de modelo de SAP HANA" muestra sus opciones si decide utilizar un
modelo de SAP HANA. La pregunta más importante es si algunos atributos, textos o
jerarquías se separan como diferentes vistas de datos maestros.

Figura 158: Opciones de modelo de SAP HANA

Las ventajas de esta separación de datos maestros son las siguientes:

● Durante el reporting, una vista de dimensión solo se lee si los atributos de la misma se
solicitan en una consulta.

216 © Copyright. Reservados todos los derechos.

 Lección: Desarrollo de un modelo de datos de SAP BW/4HANA

● Las vistas de dimensión se pueden reutilizar como "vistas compartidas" en combinación

con otros hechos.
● Se mejora la consistencia, ya que la asignación de atributos es la misma para todos los
hechos.
● Las definiciones requieren menos esfuerzo.

Si se utiliza una vista de área empresarial en diferentes escenarios y se debe añadir un

cambio de formato o nuevos atributos, solo es necesario adaptar la vista una vez.
Si no se necesitan vistas compartidas, todos los hechos se pueden modelar en una vista de
cálculo del tipo cubo sin join en estrella. A continuación, su tarea consiste en decidir qué
campos contienen medidas que deben agregarse y si la agregación es total, mínima o
máxima.

¿Qué tipo de modelo de SAP BW?

Si decide utilizar un modelo de SAP BW, puede centrarse en las vistas o guardará de forma
persistente los valores en un aDSO. Si decide utilizar vistas, defina diferentes tipos de vistas
Open ODS y sus relaciones como esquema estrella virtual.

Figura 159: Centros de datos virtuales

Para cada aDSO, la pregunta más importante es el tipo de aDSO que necesita, como se
muestra en la imagen "Definición de almacenamiento físico".

© Copyright. Reservados todos los derechos. 217

Capítulo 5 : Proceso de modelado

Figura 160: Definición de almacenamiento físico

Si todos los registros solo se agregan, nunca se sobrescriben y la clave consta de todas las
características del aDSO, utilice un data mart de tipo aDSO.
Las principales ventajas de un data mart de tipo aDSO son las siguientes:
● Es fácil de administrar. Si se añaden características nuevas o se eliminan de la lista de
campos, no es necesario adaptar la clave manualmente.
● Los nuevos registros están disponibles inmediatamente para la generación de informes.
● Puede contener más de 3000 características.

El principal inconveniente es que solo se pueden implementar correcciones de datos

transaccionales añadiendo un registro de almacenamiento.
Si necesita una funcionalidad de sobrescritura para modificar características o InfoObjetos,
utilice otros tipos de objetos DataStore con la clave especificada.
Para las características, defina si están integradas como InfoObjeto o como campo. Utilice
InfoObjetos para cargar un dominio de valor, atributos, textos y jerarquías y hacer que estén
disponibles en las consultas. Si no es necesario, utilice un campo con un formato de datos
especificado. La imagen, InfoObjeto u opciones basadas en campo, enumera las diferencias
de estos métodos.
Los atributos del modelo lógico se pueden representar como características de la tabla de
datos transaccionales, como atributos de datos maestros separados o como nivel de
jerarquía.

218 © Copyright. Reservados todos los derechos.

 Lección: Desarrollo de un modelo de datos de SAP BW/4HANA

Figura 161: Opciones basadas en InfoObjeto o campo

Las características se almacenan de forma redundante y los valores ya se determinan

durante la carga de datos. Esta opción de modelado se utiliza para el escenario de historial de
seguimiento A (verdad histórica). Los niveles de atributo y jerarquía se almacenan por
separado en una tabla de datos maestros que reduce la redundancia y los valores se derivan
en el momento del informe. Utilice esta opción de modelado con un atributo o jerarquía no
dependiente del tiempo para el escenario de historial de seguimiento B (vista actual). Con un
atributo o jerarquía dependiente del tiempo, se modela el escenario de historial de
seguimiento C (basado en fecha clave).

Especificación de InfoObjeto
Análisis de solapamiento
El proceso para derivar un modelo de SAP BW para datos maestros implica los siguientes
pasos:

1. Enumere todas las áreas empresariales e identifique qué características son relevantes
para ellas.

2. Recopilar y combinar requisitos de todos los modelos relevantes.

Las figuras, Definición de características y Combinación de necesidades, muestran cómo

puede recopilar qué atributos y propiedades necesita un InfoObjeto.
En el primer paso, para cada InfoObjeto, enumere las áreas de negocio para las que es
relevante. Por ejemplo, la característica de producto es relevante para un modelo de
producción y un modelo de ventas, pero no para HR.

© Copyright. Reservados todos los derechos. 219

Capítulo 5 : Proceso de modelado

Figura 162: Definición de característica

En el segundo paso, debe incluir todas las propiedades para el InfoObjeto que son necesarias
para al menos un modelo. A continuación, se muestran algunos ejemplos:
● Supongamos que para el modelo de producción, los textos de producto se necesitan solo
en inglés, pero para el modelo de ventas, los textos de producto se necesitan en inglés y
francés. A continuación, debido al modelo de ventas, los textos de producto deben
especificarse como dependientes de idioma.
● Supongamos que para el modelo de producción, los atributos peso y categoría son
necesarios, y para el modelo de ventas, el precio y la categoría. A continuación, el
InfoObjeto de producto necesita el peso, la categoría y el precio.
● Supongamos que para el modelo de producción, el atributo de categoría no necesita ser
dependiente del tiempo, pero para el modelo de ventas, debe ser dependiente del tiempo.
A continuación, el atributo de categoría debe ser dependiente del tiempo.

Resumen
Ha aprendido una propuesta para derivar un modelo de datos detallado. La imagen "Método
descendente para derivar un modelo de datos" muestra los resultados de las siguientes
tareas:

1. Análisis de requisitos realizado con entrevistas, reuniones de requisitos e ideas de

sistemas fuente y los informes existentes.

2. Ratios extraídos del análisis de necesidades y visualizados junto con las características
relevantes en una matriz de ratios.

3. Resumen de la arquitectura derivado que enumera todos los InfoSitios.

4. Modelo lógico de datos derivado y visualizado con uno de los dos métodos alternativos.

5. Se verificó el contenido de BI o la solución SAP HANA Live para identificar si coinciden con
su modelo o si se desarrolló su propio modelo de datos detallados.

220 © Copyright. Reservados todos los derechos.

 Lección: Desarrollo de un modelo de datos de SAP BW/4HANA

Figura 163: Método descendente para derivar el modelo de datos

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Estructurar el proceso de creación del modelo de datos en la fase de plano empresarial
● Realizar un análisis de requisitos
● Crear un resumen de la arquitectura
● Crear un modelo de datos lógico
● Desarrollar un modelo de datos de SAP BW/4HANA

© Copyright. Reservados todos los derechos. 221

Capítulo 5 : Proceso de modelado

222 © Copyright. Reservados todos los derechos.

 Capítulo 5

Evaluación de la formación

1. ¿Cuáles de las siguientes pautas deben tenerse en cuenta en una implementación de BW

en HANA en toda la empresa?
Seleccione las respuestas correctas.

X A Cómo se incorporarán los diferentes modelos de datos

X B Utilizar las capas LSA++ en el diseño del EDW

X C Qué idiomas y monedas deberán tenerse en cuenta

X D ¿Qué comprenderán el sistema y la infraestructura de transporte?

X E Qué usuarios iniciarán sesión en el sistema

2. ¿Cuál es la secuencia de las siguientes fases?

Poner en el orden correcto

0 Preparación

0 Preparación final

0 Realización

0 Plano empresarial

0 Entrada en productivo

3. La definición del modelo de datos es una actividad que se lleva a cabo en la fase de
realización de un proyecto BW.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

4. El diseño de un modelo de datos ayuda a rechazar requisitos que no son factibles.

Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

© Copyright. Reservados todos los derechos. 223

 Capítulo 5

Respuestas a la Evaluación de la formación

1. ¿Cuáles de las siguientes pautas deben tenerse en cuenta en una implementación de BW

en HANA en toda la empresa?
Seleccione las respuestas correctas.

X A Cómo se incorporarán los diferentes modelos de datos

X B Utilizar las capas LSA++ en el diseño del EDW

X C Qué idiomas y monedas deberán tenerse en cuenta

X D ¿Qué comprenderán el sistema y la infraestructura de transporte?

X E Qué usuarios iniciarán sesión en el sistema

¡Ha acertado! Todos los puntos son consideraciones para proyectos EDW en toda la
empresa, excepto para los nombres de usuario. El nombre de los usuarios que iniciarán
sesión es una actividad a nivel de proyecto y no una consideración en toda la empresa.
Leer más en el módulo Definición de la secuencia de proyectos de SAP BW/4HANA, en el
curso BW430.

2. ¿Cuál es la secuencia de las siguientes fases?

Poner en el orden correcto

1 Preparación

4 Preparación final

3 Realización

2 Plano empresarial

5 Entrada en productivo

Correcto. Primero prepare el proyecto, luego defina el modelo en la fase de plano

empresarial, luego realice el modelo, luego realice la prueba en la fase de preparación final
e instale finalmente las estructuras de soporte en la fase de entrada en productivo de un
proyecto BW. Leer más en el módulo Planificación de fases de un proyecto SAP BW/
4HANA, en el curso BW430.

224 © Copyright. Reservados todos los derechos.

 Capítulo 5 : Respuestas a la Evaluación de la formación

3. La definición del modelo de datos es una actividad que se lleva a cabo en la fase de
realización de un proyecto BW.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! La definición del modelo de datos se lleva a cabo en la fase de plano
empresarial de un proyecto BW. Leer más en el módulo Planificación de fases de un
proyecto SAP BW/4HANA, en el curso BW430.

4. El diseño de un modelo de datos ayuda a rechazar requisitos que no son factibles.

Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! Un modelo de datos no se puede diseñar en base a requisitos que no se

pueden realizar. Leer más en el módulo Desarrollo de un modelo de datos de SAP BW/
4HANA, en el curso BW430.

© Copyright. Reservados todos los derechos. 225

Capítulo 5 : Respuestas a la Evaluación de la formación

226 © Copyright. Reservados todos los derechos.

CAPÍTULO 6 Complemento de contenido de
SAP BW/4HANA

Lección 1
Trabajar con SAP Business Content 229

Lección 2
Introducción a las vistas CDS ABAP proporcionadas por SAP BW/4HANA 239

OBJETIVOS DEL CAPÍTULO

● Trabajar con SAP Business Content

● Introducir vistas CDS ABAP proporcionadas por SAP BW/4HANA

© Copyright. Reservados todos los derechos. 227

Capítulo 6 : Complemento de contenido de SAP BW/4HANA

228 © Copyright. Reservados todos los derechos.

 Capítulo 6
Lección 1
Trabajar con SAP Business Content

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Trabajar con SAP Business Content

Contenido empresarial de SAP

Escenario empresarial

Figura 164: Escenario empresarial para Business Content

SAP BI se está introduciendo en su empresa o ya se está utilizando en algunas áreas y ahora

se va a ampliar a otras áreas. Ha finalizado el análisis de necesidades o desea verificar lo que
sugiere SAP para este tema. Por lo tanto, eche un vistazo al estándar de SAP, llamado
Business Content, y aprenda a instalar y adaptar objetos de Business Content.

© Copyright. Reservados todos los derechos. 229

Capítulo 6 : Complemento de contenido de SAP BW/4HANA

Uso de contenido empresarial

Figura 165: Uso de contenido empresarial

Cuando los clientes deciden implementar la gestión de informes con SAP BW/4HANA, suele
haber mucha presión para proporcionar los primeros informes sin una optimización que
requiere mucho tiempo. Para los primeros resultados, y para obtener una impresión de la
potencia de BW, especialmente para un proyecto piloto, es una buena idea utilizar gran parte
de las estructuras predefinidas. SAP da soporte a una implementación tan rápida
proporcionando contenido empresarial para muchos escenarios típicos, incluso con
extractores para complicados mecanismos delta del sistema fuente ECC. Sin embargo, la
verificación de Business Content es un proceso continuo que dura hasta que termina de crear
un modelo de datos BW e incluso continúa siendo un primer paso para implementar
requisitos adicionales.
Si desea trabajar con Business Content, le recomendamos que proceda de la siguiente
manera, de forma similar al procedimiento de para proyectos BW propuesto en la última
unidad:

1. Defina las tareas y los roles de sus empleados. Determine los ratios necesarios o la
información que sus empleados necesitan para realizar sus tareas. Para ello, puede
utilizar el contenido empresarial basado en roles.

2. Utilizando la información que ha adquirido en el primer paso, defina un modelo de datos

para sus necesidades.

3. Compare los resultados de su análisis de requisitos y su modelo de datos con el contenido

empresarial. Normalmente, se realiza una comparación descendente, es decir, se buscan
ratios, informes y objetos DataStore avanzados en Business Content que son necesarios.

4. Determine las diferencias entre su propio modelo de datos y el Business Content.

230 © Copyright. Reservados todos los derechos.

 Lección: Trabajar con SAP Business Content

5. En función del tipo de objeto, puede ampliar o modificar el contenido empresarial,

utilizarlo como plantilla de copia para sus propios objetos o crear sus propios objetos en
su área de nombres, independientemente del contenido empresarial.

Figura 166: Enfoque descendente, enfoque ascendente

Al igual que para sus propios objetos, existen diferentes enfoques para encontrar los objetos
necesarios: el enfoque descendente y el enfoque ascendente. Estos escenarios no pueden
considerarse completamente separados entre sí. El uso simultáneo de ambos escenarios
hace que el proceso de modelado sea más eficiente.

Enfoque basado en ratios (descendente)

En un enfoque basado en ratios (descendente), haga lo siguiente:

1. Obtenga una idea clara de su modelo lógico de datos.

2. Desglose la granularidad de sus indicadores de rendimiento clave (KPI) en ratios básicos.

3. Busque sus ratios básicos y compárelos con el repository de Business Content.

4. Compare los escenarios de su modelo lógico de datos con los objetos DataStore,
consultas y libros de trabajo de Business Content.

5. Verifique los KPI en las consultas de Business Content.

6. Examine el flujo de datos para los ratios.

Enfoque de fuente de datos (ascendente)

Para el enfoque Fuente de datos (ascendente), haga lo siguiente:

1. Céntrese en el proceso empresarial de su sistema fuente.

2. Verifique sus fuentes de datos.

3. Determine la fuente de datos para características definidas en las dimensiones de su

modelo de datos lógico.

4. Comprenda cómo el contenido empresarial se asigna a los campos que ha encontrado

para InfoObjetos.

5. En función de la información de origen, analice qué objetos de Business Content (flujo de

datos ascendente) son necesarios para el escenario.

Al verificar la integridad del contenido empresarial, tenga en cuenta si necesita lo siguiente:

© Copyright. Reservados todos los derechos. 231

Capítulo 6 : Complemento de contenido de SAP BW/4HANA

● Flujo de datos y objetos para datos de transacción

● Flujo de datos y objetos para datos maestros
● Ampliación de objetos de Business Content, como adaptaciones de las fuentes de datos
del sistema fuente, fuentes de datos adicionales (genéricas), transformaciones o vistas de
SAP HANA para escenarios ágiles. Más información sobre cómo adaptar las fuentes de
datos forma parte del curso BW450.
● Vistas basadas en SAP HANA para un escenario ágil.
● InfoSitios adicionales para la consolidación de datos, consumo, según el modelo LSA++.

Figura 167: Ejemplo de contenido de demostración

Hay más contenido optimizado de SAP HANA disponible. El contenido empresarial

optimizado de SAP HANA sigue principalmente el enfoque ascendente. Para muchas fuentes
de datos, como datos de cabecera de documentos de ventas, datos de posición de
documento de ventas, hay disponible un único flujo de datos optimizado para HANA.
Este contenido utiliza la nueva filosofía de modelado de acuerdo con la LSA++. Normalmente
existe la fuente de datos, una memoria corporativa (con el nombre técnico /IMO/CM….) y un
aDSO de Data Warehouse persistente (con el nombre técnico /IMO/D_...). El aDSO se puede
rellenar directamente desde la fuente de datos o a través de la memoria corporativa. Para
combinar ambas vías de acceso, se utiliza una InfoFuente con la misma estructura.
Normalmente, no hay un nivel persistente por encima del ADSO del propagador. Las
combinaciones de diferentes conjuntos de datos, como la combinación de información de
cabecera y de posición, pueden ser realizadas por CompositeProviders (con nombre
técnico /IMO/V…) de la capa virtual de data marts virtuales.

232 © Copyright. Reservados todos los derechos.

 Lección: Trabajar con SAP Business Content

Fuentes de información para Business Content

Figura 168: Información sobre Business Content

Las siguientes son fuentes útiles para encontrar el contenido empresarial correcto:
● RSA1: sección Repositorio de metadatos y contenido empresarial
● Notas de release en SAP Service Marketplace y en la documentación

Uso de contenido empresarial en proyectos

Figura 169: Opciones para el uso del contenido

© Copyright. Reservados todos los derechos. 233

Capítulo 6 : Complemento de contenido de SAP BW/4HANA

Durante los proyectos de SAP BW/4HANA, puede utilizar el contenido empresarial de varias
maneras: para recopilar ideas, como fuente de información o para reducir el esfuerzo de
desarrollo en el proceso de extracción. La siguiente información proporciona consejos y
recomendaciones sobre el uso de Business Content en su proyecto.
Recomendamos utilizar Business Content en las siguientes fases:

Plano empresarial y realización

● Si los requisitos del cliente se corresponden con el Business Content, puede utilizar
Business Content como base para ampliaciones posteriores.

En esta fase, tiene las opciones para

● Active los objetos de Business Content y utilícelos 1:1 sin modificaciones. Esto se
recomienda especialmente para las características de tiempo, el contenido técnico y
las características que son ampliamente estándar, como el país o la sociedad CO.
● Active los objetos de Business Content y modifíquelos. Esto se recomienda si desea
implementar requisitos globales que sean estándar para toda su empresa. La versión
D permanece disponible y se puede volver a instalar si desea descartar sus
adaptaciones. (Pero tenga en cuenta que en este caso, pierde todas las
modificaciones.)
● Active los objetos de Business Content y utilícelos como modelo para un objeto
propio. Algunos clientes de SAP siguen la directriz para copiar cualquier objeto de
Business Content en un área de nombres de cliente tan pronto como modifique la
definición de cualquier manera para que no pierda ninguna adaptación cuando vuelva
a instalar el Business Content. Otros clientes de SAP solo crean copias cuando el
cambio es necesario para adaptaciones locales. Puede crear diferentes copias y
modificarlas de forma independiente. Esto le proporciona la mayor flexibilidad. La
versión activa original permanece disponible a medida que se entrega. No cree
demasiadas copias, sino que intente reutilizarlas tanto como sea posible.
● Cree un nuevo objeto independiente del Business Content. Puede utilizar los objetos
de contenido como sugerencias.

Después de la entrada en productivo y para la mejora continua

● Después de actualizar un release de Business Content, puede volver a instalar los
objetos de Business Content.
● Verifique si hay paquetes de soporte de Business Content para volver a instalar
objetos suministrados con este support package.

En ambos casos, dispone de las siguientes opciones:

● Si ha modificado el objeto Business Content y el tipo de objeto admite la función
Coincidencia, las modificaciones de SAP y sus modificaciones definidas por el cliente
se pueden integrar en una nueva versión. En algunos casos, la integración se realiza
automáticamente, por ejemplo, si se han añadido nuevos InfoObjetos a un catálogo de
InfoObjetos, se añadirán a la versión activa actual. En otros casos, como diferentes
parametrizaciones para una propiedad de característica, aparece una ventana de
diálogo en la que puede seleccionar si desea cambiar a la nueva parametrización de
SAP Business Content. La opción estándar es mantener la versión de cliente.

234 © Copyright. Reservados todos los derechos.

 Lección: Trabajar con SAP Business Content

● Si el tipo de objeto no soporta la función de correspondencia o si decide no utilizarla,

sustituya la versión de cliente por la versión de SAP si activa el nuevo contenido de
SAP suministrado.
● Si ha creado una copia del contenido empresarial, la activación del contenido nuevo
no afecta a su copia. Es necesaria la adaptación manual de la copia.

Algunos tipos de objeto no admiten la opción de fusión (coincidencia). Solo puede activar o
instalar estos objetos y sobrescribir una versión A existente si es necesario. Estos objetos
incluyen, por ejemplo, consultas y elementos de consulta, proveedor compuesto, tipos de
conversión de moneda, tipos de conversión de unidades, libros de trabajo y roles. Puede
instalar, activar y modificar estos objetos o activarlos y utilizarlos como modelos (queries,
modelos Web).
Puede fusionar otros objetos en Business Content. Puede determinar las diferencias entre la
versión activa y la versión entregada y, a continuación, fusionar los objetos. Por ejemplo,
puede añadir los nuevos atributos de una característica del Business Content a una
característica que haya activado.

Instalación de Business Content

Figura 170: Recomendaciones para instalar contenido empresarial

Recomendaciones:
Inicie la instalación de Business Content desde los tipos de objeto más fundamentales hasta
los más complicados, e intente mantener pequeño el conjunto de objetos instalados. Empiece
con vistas de cálculo o fuentes de datos. A continuación, instale InfoObjetos, Vistas ODS,
InfoFuentes y ADSO antes de CompositeProviders. La imagen "Recomendaciones para
instalar contenido empresarial" enumera recomendaciones específicas de objeto. En
especial, modifique o amplíe los InfoSitios inferiores en el flujo de datos, como las vistas Open
ODS, y copie o cree InfoSitios que sean más altos en el flujo de datos como ADSO y
CompositeProviders.

© Copyright. Reservados todos los derechos. 235

Capítulo 6 : Complemento de contenido de SAP BW/4HANA

● No active ningún contenido que no desee utilizar (por ejemplo, no active toda la InfoÁrea).
Algunos objetos no se pueden volver a borrar porque hacen referencia a un gran número
de otros objetos.
● No active el contenido en proceso de fondo si desea realizar una comparación (opción de
coincidencia). De lo contrario, se sobrescribirá la versión existente.
● Fije el Modo de cobro en automáticamente, pero preste atención a la opción Agrupación.
● Flujo de datos anterior: todos los objetos del flujo de datos anterior se recopilan y activan.
● Flujo de datos después (ascendente): todos los objetos en el flujo de datos después de se
activan posteriormente. Familiarícese con el flujo de datos. Debe seleccionar
cuidadosamente los objetos que realmente necesita.
● Evite utilizar la opción Flujo de datos antes y después excepto en escenarios bien definidos
con un pequeño número de objetos (como la instalación del contenido técnico).

Procedimiento
En el workbench de almacenamiento de datos, seleccione el árbol BI Content(= Business
Content). Recopile los objetos que desea activar. En el área de pantalla Objetos recopilados,
verifique las columnas Instalar, Coincidir (X) o Copiar y versión activa disponible.
Los siguientes objetos de Business Content se resaltan por defecto en la columna Instalar:
● Objetos que se transfieren por primera vez. No existe ninguna versión activa de estos
objetos en el sistema.
● Objetos de Business Content que se han vuelto a entregar en una nueva versión. Estos
objetos se pueden identificar mediante el cronomarcador Business Content en las tablas
de objetos correspondientes.

Si fija manualmente el indicador de instalación, verifique si la casilla de selección hace

referencia a una carpeta o a un objeto individual. Si la casilla de selección hace referencia a
una carpeta, el indicador se fija para todos los objetos que pertenecen a esta carpeta. Si la
casilla de selección hace referencia a un objeto individual, el indicador solo se fija para un
objeto individual y los indicadores para los otros objetos de la carpeta no se modifican. Lo
mismo se aplica si elimina la marca.
En el menú contextual dispone de las siguientes opciones para modificar el indicador para
toda la subjerarquía:
● Instalar todo a continuación: El objeto del nivel de jerarquía seleccionado y todos los
objetos de los niveles inferiores de la jerarquía se seleccionan como Instalar.
● No instalar todo lo siguiente: Los indicadores de instalación se eliminan para el objeto en el
nivel de jerarquía seleccionado y todos los objetos en los niveles inferiores de la jerarquía.

Coincidencia de columna (X) o copia

Es importante marcar el indicador Instalar para los objetos que permiten la opción
Coincidencia. Si el indicador Instalar está fijado, no se utilizará la función de correspondencia.
Si la versión de entrega de SAP y la versión activa pueden coincidir, se visualiza una casilla de
selección en esta columna.
Con los tipos de objeto más importantes, la versión activa y la versión suministrada por SAP
pueden coincidir.
Cuando se hace coincidir un objeto, se comparan propiedades de objeto específicas entre la
versión activa (versión de cliente) y la versión de Business Content (versión de entrega).

236 © Copyright. Reservados todos los derechos.

 Lección: Trabajar con SAP Business Content

Atención:
Si no compara las versiones, se utilizará la versión de entrega y la versión de
cliente activa se sobrescribirá al activar el Business Content. En otras palabras,
la versión de entrega se copia sobre la versión activa.

La tabla RSTLOGOPROP indica los tipos de objeto que soportan el ajuste. Esta tabla enumera
los tipos de objeto transportables y describe sus propiedades. El campo MERGEFL indica si se
soporta el ajuste para un tipo de objeto determinado.
El indicador Coincidencia está fijado por defecto para los objetos que admiten esta función.
De este modo se evita que la versión de cliente se sobrescriba involuntariamente. Tenga en
cuenta que si la casilla Instalar no está marcada, el objeto no se copia ni coincide. En este
caso, el indicador Coincidencia no tiene ningún efecto. La casilla de selección Coincidencia se
evalúa de la siguiente manera:
● La versión activa de un objeto coincide con la versión de entrega, si ha configurado las
siguientes opciones para el objeto:
- El indicador de coincidencia está seleccionado
- La casilla Instalar está seleccionada
● La versión activa de un objeto se sobrescribe con la versión de entrega si ha configurado
las siguientes opciones para el objeto:
- El indicador de coincidencia no está seleccionado
- La casilla Instalar está seleccionada

Se recomienda realizar una coincidencia si ha modificado la versión de cliente de un objeto.

Nota:
Si se produce un error al intentar activar Business Content por primera vez,
desmarque el indicador Coincidencia cuando vuelva a intentar instalar el BI
Content. De este modo, puede evitar inconsistencias en la versión modificada.

Nota:
Cuando las transformaciones coinciden, se conservan todas las reglas de
transformaciones disponibles y solo se añaden reglas nuevas (por ejemplo,
campos que se rellenan con una rutina nueva). En este caso, las rutinas existentes
no se sustituyen. Esto puede provocar errores después de activar el Business
Content. Por lo tanto, se recomienda instalar transformaciones del Business
Content sin ajuste y, a continuación, modificar las rutinas.

En el menú contextual dispone de dos opciones para modificar el indicador de fusión para
subjerarquías:
● Fusionar todo lo siguiente: El objeto del nivel de jerarquía seleccionado y todos los objetos
de los niveles inferiores de la jerarquía se seleccionan como Coincidencia.
● Las casillas de selección Coincidencia se desmarcan para el objeto en el nivel de jerarquía
seleccionado y para todos los objetos en los niveles inferiores de la jerarquía. Si la casilla

© Copyright. Reservados todos los derechos. 237

Capítulo 6 : Complemento de contenido de SAP BW/4HANA

de selección Instalar también está marcada, estos objetos se copiarán de la versión de

entrega a la versión activa.

Coincidencia automática y manual

Es necesario identificar si las propiedades, que se comparan entre la versión activa y la
versión de entrega, pueden coincidir automáticamente o si esto se debe hacer manualmente.
Si está seguro de que el objeto se utilizará del mismo modo después de instalar Business
Content, puede realizar una coincidencia automática para esas propiedades. Al realizar las
coincidencias manualmente, debe decidir individualmente para cada propiedad si las
características de la versión activa se deben conservar o si las características se deben copiar
de la versión de entrega.
Ejemplo de coincidencia automática:
Se han añadido atributos específicos de cliente adicionales a la versión de cliente de un
InfoObjeto. En la versión de Business Content, SAP ha suministrado dos atributos adicionales
que no contienen los atributos específicos de cliente. Para poder utilizar los atributos
adicionales, la versión de entrega debe volver a instalarse desde Business Content. Al mismo
tiempo, se deben conservar los atributos específicos de cliente. En este caso, debe fijar el
indicador (X) en la casilla de selección. Después de instalar el Business Content, los atributos
adicionales están disponibles y las ampliaciones específicas de cliente se han conservado
automáticamente. Sin embargo, si no ha seleccionado el indicador de coincidencia, se
perderán las ampliaciones específicas de cliente en la versión de cliente.
Ejemplo de coincidencia manual:
La versión de cliente y la versión Business Content de un InfoObjeto tienen textos diferentes.
En este caso, las dos versiones deben coincidir manualmente. Cuando se instala el Business
Content, aparece una pantalla detallada en la que se especifica si desea aplicar el texto de la
versión activa o de la versión de Business Content.
Normalmente, cuando se hacen coincidir versiones, se añaden modificaciones o adiciones a
las opciones basadas en listas (como la lista de atributos, la lista de campos y la lista de
procesos implicados) en el contenido empresarial a la versión del cliente. Las opciones
alternativas (como las descripciones y las casillas de selección) se conservan de la versión del
cliente durante la coincidencia automática o se deben hacer coincidir manualmente.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Trabajar con SAP Business Content

238 © Copyright. Reservados todos los derechos.

 Capítulo 6
Lección 2
Introducción a las vistas CDS ABAP
proporcionadas por SAP BW/4HANA

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Introducir vistas CDS ABAP proporcionadas por SAP BW/4HANA

Introducción a las vistas CDS ABAP proporcionadas por SAP BW/4HANA

Ha instalado algunos procesos de staging y consultas BW, por ejemplo, desde SAP BI
Content. Sin embargo, los usuarios se quejan de un retraso entre los procesos empresariales
y la disponibilidad de los datos relacionados en SAP BW/4HANA y son reacios a utilizar estas
consultas. El administrador de la base de datos se queja de un consumo de memoria
excesivo.

Escenario empresarial para vistas CDS

Figura 171: Vistas CDS de escenario empresarial

Trabaja con SAP S/4HANA u otro SAP ECC en la aplicación SAP HANA, principalmente con
procesos y tablas estándar. Desea desarrollar informes directamente en los datos originales.
Sin embargo, las directrices de conformidad de su empresa disuaden a los desarrolladores de
iniciar sesión en la base de datos de SAP HANA. ¿Hay una forma de desarrollar, o incluso más
simplemente, instalar vistas flexibles optimizadas de SAP HANA desde la capa de aplicación?
¿Puede obtener un análisis de rendimiento en tiempo de ejecución detallado para consultas
de ambos métodos sin iniciar sesión en SAP HANA? ¿Puede verificar qué InfoSitios
consumen cuántos megabytes y qué queries se utilizan realmente?

© Copyright. Reservados todos los derechos. 239

Capítulo 6 : Complemento de contenido de SAP BW/4HANA

Hasta ahora, puede que haya considerado dos opciones para la generación de informes casi
en tiempo real: staging de datos de SAP BW/4HANA con intervalos periódicos breves y
replicación de datos en tiempo real en la plataforma SAP HANA del sistema SAP BW/4HANA.
Ambas opciones tienen la desventaja de que los datos del sistema fuente original se duplican,
lo que cuesta el volumen de almacenamiento y provoca un retraso breve. Si su sistema fuente
es una aplicación SAP basada en SAP HANA, como SAP S/4HANA, las vistas de los datos
originales se pueden gestionar en la propia plataforma SAP HANA del sistema fuente con
velocidades rápidas. SAP ha desarrollado un tipo especial de vista que permite la integración
de consultas SQL, incluida la unión, la unión, las cláusulas WHERE y todas las demás
funciones SQL: la vista ABAP Core Data Services (vista CDS ABAP). Existen vistas CDS de
contenido predefinidas para escenarios empresariales y otras para evaluaciones técnicas que
enumeran el consumo de memoria o el rendimiento del tiempo de ejecución de consulta.

Consumir vistas CDS

Figura 172: Escenario de implementación para vistas CDS

Una vista de Core Data Services (CDS) es un objeto con un nombre técnico que contiene
código SQL para acceder a los datos directamente, posiblemente ampliado con más
información sobre cómo gestionar y enriquecer los datos. Las vistas CDS se gestionan
mediante el servidor de aplicación SAP (capa ABAP). Puede ser un sistema fuente de SAP o
BW/4HANA.
La ventaja de este enfoque es la integración de ABAP completa, lo que permite la reutilización
de autorizaciones de informes existentes, etc. Además, el motor analítico (funcionalidad
integrada de Business Warehouse (BW)) admite la creación de la visualización de jerarquía.
Esto permite crear más casos de uso para este modelo de datos virtual: SAP S/4HANA
Embedded Analytics no solo admite informes OLAP operativos genéricos, sino también
análisis integrados para aplicaciones transaccionales y analíticas híbridas (por ejemplo, SAP
Embedded BI o SAP Smart Business Cockpits) basados en los mismos modelos. También se
admite el acceso de lectura para la búsqueda/hojas informativas. También hay extractores
para la puesta a disposición de EDW en SAP BW/4HANA para crear consistencia entre BI
Content y los modelos de sistema fuente.
Hay dos formas en que una vista CDS puede utilizar otra:

240 © Copyright. Reservados todos los derechos.

 Lección: Introducción a las vistas CDS ABAP proporcionadas por SAP BW/4HANA

● Los ficheros fuente DDL se crean y actualizan mediante la herramienta de desarrollo ABAP
(ADT) en Eclipse, pero el objeto (vista CDS) forma parte del repository ABAP. Esto
significa que cuando se selecciona un paquete transportable, la fuente DDL se puede
añadir a una orden de transporte ABAP. Esta solicitud de transporte ABAP seguirá la ruta
de transporte definida en el sistema de transporte ABAP.
Hay un editor gráfico que le permite obtener un resumen de los campos, las tablas y las
asociaciones con otras vistas.
De forma similar al contenido de BI, hay contenido de vista CDS suministrado previamente
por SAP. Después de la instalación, puede ampliar o modificar una vista CDS, utilizarla
como plantilla de copia para sus propios objetos o crear sus propios objetos en su área de
nombres, independientemente del contenido de SAP.
El consumo significa que una vista CDS tiene otra vista como base de datos (Definir vista
V1 como Seleccionar de B1 …). Se pueden combinar varias vistas en una vista por
operaciones de unión o unión.
● No hay ninguna restricción en el número de capas.
● La asociación permite añadir información de otras vistas a petición.

Figura 173: Ejemplo CDS de SAP S4HANA

La idea detrás de las asociaciones en ABAP Core Data Services (CDS) es proporcionar una
representación adecuada de una relación entre dos entidades en el modelo de datos en el
Dictionary ABAP. Si piensa en el modelo clásico Entidad-Relación como un grafo atribuido
dirigido, las asociaciones son los bordes de este grafo.

© Copyright. Reservados todos los derechos. 241

Capítulo 6 : Complemento de contenido de SAP BW/4HANA

Definición de vista CDS

Figura 174: Definición de vista CDS

Los ficheros fuente DDL se crean y actualizan mediante la herramienta de desarrollo ABAP
(ADT) en Eclipse, pero el objeto (vista CDS) forma parte del repository ABAP. Esto significa
que cuando se selecciona un paquete transportable, la fuente DDL se puede añadir a una
orden de transporte ABAP. Esta solicitud de transporte ABAP seguirá la ruta de transporte
definida en el sistema de transporte ABAP.
Hay un editor gráfico que le permite obtener un resumen de los campos, las tablas y las
asociaciones con otras vistas.
De forma similar al contenido de BI, hay contenido de vista CDS suministrado previamente
por SAP. Después de la instalación, puede ampliar o modificar una vista CDS, utilizarla como
plantilla de copia para sus propios objetos o crear sus propios objetos en su área de nombres,
independientemente del contenido de SAP.

Anotaciones semánticas

Figura 175: Anotaciones

242 © Copyright. Reservados todos los derechos.

 Lección: Introducción a las vistas CDS ABAP proporcionadas por SAP BW/4HANA

Para el procesamiento de datos, los análisis y el consumo de datos, los motores principales
deben interpretar correctamente las columnas utilizadas en la lista de proyecciones. Las
anotaciones semánticas informan a los clientes sobre el tipo de datos.
Las anotaciones semánticas complementan el concepto de tipos de datos semánticos.
Mientras que los tipos de datos semánticos siempre introducen un comportamiento
específico en la infraestructura principal (a través de operaciones dedicadas o funciones de
conversión), las anotaciones semánticas permiten estandarizar la semántica que solo tiene
un impacto en el lado del consumo (como el número de teléfono, la dirección de correo
electrónico, la ciudad, etc.).
Algunas anotaciones son anotaciones principales. Se refieren a toda la vista. Por ejemplo, un
nombre de vista para el diccionario ABAP se define con la anotación
@AbapCatalog.SqlViewName.
Una etiqueta de texto legible y significativa para toda la vista se define con la anotación
@EndUserText.label.
La mayoría de las anotaciones se refieren a un solo campo.
Por ejemplo, la anotación @ObjectModel.representativeKey define el campo más específico
de la clave primaria.
@Semantics.CurrencyCode: true define que este campo específico se puede utilizar como
moneda.

Nota:
En el sistema T41, se ha implementado la vista CDS ABAP ZPEPMCDSVST. Esta
vista CDS ABAP se utiliza para proporcionar datos de almacenamiento (acceso
virtual y extracción) del sistema T41.

Figura 176: ABAP_CDS_VIEW para datos de almacenamiento

© Copyright. Reservados todos los derechos. 243

Capítulo 6 : Complemento de contenido de SAP BW/4HANA

Ejemplos de vistas CDS predefinidas

Figura 177: Ejemplo de vistas CDS

Con SAP BW/4HANA, SAP proporciona vistas CDS predefinidas para analizar datos
empresariales para el modelo de demostración EPM (nombres técnicos 2CREPM_*), pero
también para muchos procesos empresariales reales desde el aprovisionamiento hasta el
pago. Se basan principalmente en tablas de SAP S/4HANA.
Para los usuarios con un interés administrativo o técnico, existe la InfoÁrea 2O-BW4-DM-
STAT con vistas para analizar datos estadísticos, como:
● Volumen de datos por tabla en SAP HANA, NLS y ambas opciones de almacenamiento
● Tamaño de la solicitud (número de registros), estado de la solicitud y tiempo de ejecución
por DTP
● Número de solicitudes en la tabla de entrada y activa, y cronomarcador de adquisición de
datos para aDSOs
● Utilización de consulta (actual e histórica)
● Resumen del tiempo de ejecución de consulta

Para cada vista CDS, existe al menos una consulta, pero puede crear las suyas propias.
Independientemente de si se trata de una consulta definida por el cliente o entregada, ya sea
basada en ADSO o en vistas CDS,
Existen diferentes formas de ejecutar una consulta:
● Con la opción Ejecutar y depurar en el código de transacción RSRT, puede ver el tiempo de
ejecución y la estadística de volumen de la ejecución ejecutada.
● Con el UIBB de lista de análisis o Analysis for Office, puede navegar libremente, es decir,
definir restricciones, desglosar y visualizar propiedades correctas.

244 © Copyright. Reservados todos los derechos.

 Lección: Introducción a las vistas CDS ABAP proporcionadas por SAP BW/4HANA

● Con el generador de KPI de SAP Fiori, puede definir valores umbral y una buena
visualización para la integración del portal de SAP Fiori.

En el siguiente ejercicio, ejecute un query (RSRT) y verifique las estadísticas de tiempo de

ejecución en tiempo de ejecución.
A continuación, ejecute una consulta de vista CDS de contenido técnico
(2CRVCOLAPSTATAQ) para un resumen estadístico de todas las ejecuciones de consulta.
Existen otras consultas de vista CDS para otros temas, como 2CRVCDTPLOADQ para el
estado de carga DTP, basado en una vista CDS ABAP RVCDTPLOADQ.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Introducir vistas CDS ABAP proporcionadas por SAP BW/4HANA

© Copyright. Reservados todos los derechos. 245

Capítulo 6 : Complemento de contenido de SAP BW/4HANA

246 © Copyright. Reservados todos los derechos.

 Capítulo 6

Evaluación de la formación

1. Instalar SAP Business Content significa que el usuario empresarial define todas las
propiedades del objeto desde cero.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

2. El contenido empresarial optimizado en memoria disponible para SAP BW/4HANA utiliza

el concepto de diseño de LSA++ con una fuente de datos, una memoria corporativa y un
ADSO de propagación persistente.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

3. Los objetos de BI Content se suministran primero en la versión A (activa).

Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

4. Incluso si ha modificado InfoObjetos de SAP Business Content, no pierde las

modificaciones cuando SAP envía nuevas versiones de contenido (a menos que desee o
cometa un error estúpido).
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

© Copyright. Reservados todos los derechos. 247

Capítulo 6 : Evaluación de la formación

5. El contenido técnico, como la información sobre el estado de carga de DTP, se

proporciona en base a las vistas CDS ABAP de SAP BW/4HANA.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

248 © Copyright. Reservados todos los derechos.

 Capítulo 6

Respuestas a la Evaluación de la formación

1. Instalar SAP Business Content significa que el usuario empresarial define todas las
propiedades del objeto desde cero.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

Tienes razón. Con SAP Business Content, se utilizan objetos con propiedades definidas
por SAP. Leer más en el módulo Trabajar con SAP Business Content, en el curso BW430.

2. El contenido empresarial optimizado en memoria disponible para SAP BW/4HANA utiliza

el concepto de diseño de LSA++ con una fuente de datos, una memoria corporativa y un
ADSO de propagación persistente.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! El contenido empresarial se ha diseñado utilizando LSA++, tal como se ha

descrito anteriormente. Leer más en el módulo Trabajar con SAP Business Content, en el
curso BW430.

3. Los objetos de BI Content se suministran primero en la versión A (activa).

Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! Los objetos de SAP Business Content se suministran en la versión D

(suministrada). Leer más en el módulo Trabajar con SAP Business Content, en el curso
BW430.

© Copyright. Reservados todos los derechos. 249

Capítulo 6 : Respuestas a la Evaluación de la formación

4. Incluso si ha modificado InfoObjetos de SAP Business Content, no pierde las

modificaciones cuando SAP envía nuevas versiones de contenido (a menos que desee o
cometa un error estúpido).
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! Los objetos de SAP Business Content se suministran en la versión D

(suministrada), lo que significa que conserva sus versiones M o A modificadas. Incluso
cuando instala la nueva versión, de forma predeterminada se establece la opción de
coincidencia. Esto le permite comparar su propia versión con la nueva versión de SAP y
decidir individualmente para cada modificación si desea conservarla o no. Leer más en el
módulo Trabajar con SAP Business Content, en el curso BW430.

5. El contenido técnico, como la información sobre el estado de carga de DTP, se

proporciona en base a las vistas CDS ABAP de SAP BW/4HANA.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! Los informes técnicos, como 2CRVCDTPLOADQ para el estado de carga
DTP o 2CRVCOLAPSTATAQ para un resumen estadístico de todas las ejecuciones de
consulta, se envían en función de las vistas CDS ABAP. Leer más en el módulo Vistas CDS
ABAP proporcionadas por SAP BW/4HANA, en el curso BW430.

250 © Copyright. Reservados todos los derechos.

CAPÍTULO 7 Implementación de modelos
basados en campos de SAP
BW/4HANA

Lección 1
Implementación de modelado basado en campos con vistas Open ODS 253

Lección 2
Comprender los modelos de memoria corporativa y de instantánea 265

OBJETIVOS DEL CAPÍTULO

● Comprender el objetivo del modelado basado en campos con vistas Open ODS
● Conectar orígenes de datos
● Combinar hechos, datos maestros y textos en vistas Open ODS
● Integrar datos transaccionales con vistas Open ODS
● Comprender la instantánea y la memoria corporativa

© Copyright. Reservados todos los derechos. 251

Capítulo 7 : Implementación de modelos basados en campos de SAP BW/4HANA

252 © Copyright. Reservados todos los derechos.

 Capítulo 7
Lección 1
Implementación de modelado basado en
campos con vistas Open ODS

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Comprender el objetivo del modelado basado en campos con vistas Open ODS
● Conectar orígenes de datos
● Combinar hechos, datos maestros y textos en vistas Open ODS
● Integrar datos transaccionales con vistas Open ODS

Descripción del objetivo del modelado basado en campos

Figura 178: Escenario empresarial para modelado basado en campos

Desea presentar un informe flexible con datos maestros integrados y datos transaccionales
de diferentes fuentes. Los datos deben estar disponibles primero como datos en tiempo real
(acceso directo). Encontrará los datos que necesita para este informe específico en fuentes
existentes (tablas de base de datos, vistas de base de datos, vistas de cálculo de SAP HANA,
fuentes de datos BW o aDSOs).

© Copyright. Reservados todos los derechos. 253

Capítulo 7 : Implementación de modelos basados en campos de SAP BW/4HANA

Creación rápida de prototipos

Figura 179: Creación rápida de prototipos e integración incremental

Imagine que desea saber si los usuarios empresariales utilizarían un nuevo modelo. Sin
embargo, desea evitar invertir demasiado tiempo en la implementación de un modelo. A
continuación, simplemente puede proporcionar informes a los usuarios con algunos campos
de la fuente de datos, o incluso desde una fuente de datos remota en un paso sencillo.

Figura 180: Crear un data mart virtual

En este modelo simple, genere primero las vistas Open ODS de datos maestros y, a
continuación, las vistas Open ODS. En cualquier caso, no es necesario cargar datos en SAP
BW/4HANA. En consecuencia, el modelo se llama Virtual Data Mart. Los pasos se muestran
en la figura Creación de un data mart virtual.

254 © Copyright. Reservados todos los derechos.

 Lección: Implementación de modelado basado en campos con vistas Open ODS

Figura 181: Convertir un data mart virtual en un data mart persistente

Si a los usuarios les gusta la idea, pero necesitan una mayor armonización, una base de datos
estable o un acceso más rápido a los datos, aproveche un método simple para generar un
flujo de datos a un objeto DataStore avanzado. A continuación, puede asociar (enlazar) más
información desde InfoObjetos. El resultado se denomina Data Mart físico. La imagen,
Convertir un data mart virtual en un data mart persistente, muestra los pasos necesarios.

Figura 182: InfoObjeto o modelado basado en campos

La imagen, InfoObjeto o modelado basado en campos, compara el enfoque de modelado

tradicional con un enfoque de modelado. La idea principal del enfoque de modelado
simplificado es que no tiene que crear InfoObjetos de SAP BW/4HANA para todos los campos
de sus fuentes de datos.
La parte izquierda de la figura muestra la filosofía BW clásica basada en InfoObjetos, donde la
integración se produce antes de que se apliquen las funciones empresariales. Integración
significa la asignación de InfoObjetos, que se utilizan para armonizar e integrar datos de
diferentes fuentes, y para añadir significado (también conocido como semántica) a los datos.

© Copyright. Reservados todos los derechos. 255

Capítulo 7 : Implementación de modelos basados en campos de SAP BW/4HANA

Estas semánticas se definen mediante la lista de valores posibles del InfoObjeto, la definición
de clave o los atributos, o por unidades o monedas referenciadas.
Luego, después de asignar los InfoObjetos, modela funciones como aplicar un filtro o calcular
nuevos valores. Por ejemplo, puede leer de los datos maestros de un InfoObjeto en una
transformación o aplicar una conversión de moneda en un query BW. Esto garantiza tanto
datos de alta calidad como un alto nivel de normalización.
El lado derecho de la figura muestra el modelado simplificado e inmediato utilizado en el
enfoque basado en campos (donde el modelado de funciones se produce antes de la
integración). Este enfoque se basa en la definición de una cantidad mínima de significado
(semántica) para los datos. Puede ejecutar una consulta inmediatamente sin crear
InfoObjetos, staging, etc. Este enfoque minimalista le permite aplicar funciones empresariales
a los datos brutos antes de la integración y proporciona respuestas inmediatas a preguntas
urgentes. Sin embargo, la calidad de los datos depende de su fuente. El objeto central para el
modelado basado en campos es la vista Open ODS y su versión persistente, el objeto
DataStore (avanzado).
Sin embargo, el CompositeProvider, el aDSO y la vista Open ODS le permiten mezclar el
enfoque basado en campos (donde el modelado se produce antes de la integración) y el
enfoque basado en InfoObjetos (donde la integración se produce antes del modelado de
funciones). Las vistas SQL siempre siguen el enfoque basado en campos.

Conexión de fuentes de datos en vistas Open ODS

Figura 183: Tipos de fuente disponibles

Como se ha descrito anteriormente, la base de datos de SAP HANA consta de diferentes

esquemas de base de datos, cada uno de los cuales puede representar una aplicación
diferente. Existe el esquema que gestiona SAP BW/4HANA, por ejemplo (en nuestra
instalación, SAPCIA), pero también puede haber otros esquemas que contengan objetos de

256 © Copyright. Reservados todos los derechos.

 Lección: Implementación de modelado basado en campos con vistas Open ODS

otras aplicaciones o de un sistema ECC. Todos los esquemas que no son el esquema BW/
4HANA se denominan esquemas gestionados externamente. Los datos de bases de datos
externas se pueden replicar en esquemas de SAP HANA gestionados externamente mediante
herramientas de replicación, como SAP System Landscape Transformation Replication
Server (SLT) o Smart Data Integration (SDI). Para integrar otras tablas de base de datos sin
duplicar datos, las tablas se pueden conectar mediante Smart Data Access desde bases de
datos externas.
Las siguientes fuentes clave están disponibles para las vistas Open ODS:
● Tablas de base de datos SAP HANA, vistas de base de datos o vistas de cálculo.
Proporcionan datos gestionados por SAP HANA.
● Tablas virtuales de bases de datos externas conectadas a SAP HANA mediante Smart
Data Access (*).

La imagen "Tipos de fuente disponibles" explica la diferencia entre los tipos de fuente Tabla
de base de datos o Vista y Tabla virtual mediante HANA Smart Data Access.
Utilice la primera opción, Tabla de base de datos o Vista si tiene un objeto existente (tabla,
vista, vista de cálculo o incluso tabla virtual) en la base de datos SAP HANA propia de BW/
4HANA. Para cada esquema, se requiere un sistema fuente del tipo HANA_LOCAL en BW/
4HANA. Puede aprovechar uno existente o generar uno nuevo en el asistente de vista Open
ODS.
Tenga en cuenta que la segunda opción, Tabla virtual mediante HANA Smart Data Access,
solo es necesaria si aún no ha definido una tabla virtual en el nivel de base de datos. Sin
embargo, necesita una conexión de acceso a datos inteligentes existente a nivel de base de
datos. A continuación, BW/4HANA crea una nueva tabla virtual en el esquema gestionado
BW/4HANA. Para cada conexión fuente remota a nivel de SAP HANA, se requiere un sistema
fuente separado del tipo HANA_SDA en BW/4HANA. Puede aprovechar uno existente o
generar uno nuevo en el asistente de vista Open ODS.
(*) Ahora incluso es posible aprovechar las conexiones SDI con este framework, básicamente
utilizando la función de tabla virtual SDI.
Con SAP HANA 2.0, se admiten al menos las siguientes fuentes remotas:
● SAP HANA
● SAP IQ
● SAP Adaptive Service Enterprise
● Base de datos Oracle 12C
● Procesador de SAP Event Stream
● SAP MaxDB
● Distribución de Hortonworks para Apache Hadoop versión 2.3
● Base de datos Teradata
● Microsoft SQL Server 2012
● IBM DB2
● Aplicación IBM Netezza
● Provincia de Apache Spark

© Copyright. Reservados todos los derechos. 257

Capítulo 7 : Implementación de modelos basados en campos de SAP BW/4HANA

● SAP MII (Manufacturing Integration and Intelligence, véase también la nota SAP 1984859)

Requisitos previos
Pasos necesarios para facilitar SAP HANA Smart Data Access como tipo de fuente para las
vistas Open ODS:

1. Instale el controlador ODBC para la base de datos que desea conectar.

2. Inicie sesión en SAP HANA con un usuario con el privilegio de sistema CREATE REMOTE
SOURCE.

3. Conecte la base de datos fuente utilizando SAP HANA Smart Data Access como fuente
remota.

4. Otorgue la autorización CREATE VIRTUAL TABLE en esta fuente remota al usuario de la

base de datos de BW/4HANA.

En nuestro entorno, el usuario de la base de datos de BW/4HANA es SAPCIA.

Para obtener más información, consulte la nota SAP 1868702, el Manual de administración de
SAP HANA y SAP BW/4HANA & SAP HANA Smart Data Access - Guía de configuración:
http://scn.sap.com/docs/DOC-53048.
En casos excepcionales, podrán utilizarse otras fuentes, como las siguientes:
● Fuentes de datos BW con acceso directo habilitado para tipos de sistema fuente BW/
4HANA ODP(SAP), SAP HANA. Para obtener más información sobre estas técnicas de
conexión, consulte el curso BW450
● Transformaciones
● DSO avanzados

Al crear una vista Open ODS, el objeto subyacente se etiqueta como hechos, datos maestros
o textos.
La vista Open ODS actúa como InfoSitio BW. Sirve como fuente para consultas BW y, como
tal, puede ser consumida directamente por los clientes de reporting.
Por motivos de flexibilidad y para cumplir con la arquitectura LSA++, recomendamos integrar
cada vista Open ODS en CompositeProviders.

258 © Copyright. Reservados todos los derechos.

 Lección: Implementación de modelado basado en campos con vistas Open ODS

Combinación de hechos, datos maestros y textos en vistas Open ODS

Figura 184: Data Marts virtuales utilizando vistas Open ODS

Existen varias ventajas de separar los datos maestros de los datos transaccionales. Una de
estas ventajas es evitar la redundancia. La tabla de hechos se puede restringir a las entidades
básicas que determinan los ratios y todas las categorías se pueden derivar mediante una
unión a la tabla de datos maestros. Esta separación a menudo ya se realiza en el sistema
fuente, en una base de datos o en SAP HANA.
En este caso, puede combinar varias vistas Open ODS en un esquema estrella
multidimensional. La imagen "Marts de datos virtuales que utilizan vistas Open ODS" explica
el concepto. El diseño necesario se puede derivar directamente del modelo de sistema fuente
o del modelo de datos lógico de la fase de plano empresarial de su proyecto BW.
Para diferentes tipos de datos, defina diferentes tipos de vistas Open ODS. Los hechos Vista
Open ODS es una vista Open ODS importante que proporciona los ratios. Otros tipos posibles
son las vistas de datos maestros, que se utilizan para atributos y las vistas de texto. (Las
jerarquías no están disponibles). Las conexiones de tabla para el esquema estrella se definen
como "asociaciones" en la vista Open ODS central en SAP BW. Una vista Open ODS que hace
referencia a datos maestros se puede asociar con una vista de texto de la misma manera.
Los datos referenciados del data mart virtual normalmente se almacenan fuera de BW/
4HANA, en diferentes esquemas, incluso en diferentes bases de datos externas siempre que
se puedan conectar como una fuente remota en SAP HANA.
También puede asociar determinados campos en su vista Open ODS con InfoObjetos BW.
Esta asociación le permite reutilizar metadatos BW valiosos que pueden existir en sus
InfoObjetos de SAP BW. Los siguientes metadatos pueden existir en sus InfoObjetos de SAP
BW:
● Parametrizaciones estándar BW
● Jerarquías
● Textos

© Copyright. Reservados todos los derechos. 259

Capítulo 7 : Implementación de modelos basados en campos de SAP BW/4HANA

● Atributos para datos maestros

● Atributos de navegación para datos maestros

Figura 185: Añadir atributos

¿Cómo puede asociar una vista Open ODS de hechos con una vista Open ODS de datos
maestros? Los campos individuales se pueden enlazar con una vista Open ODS de datos
maestros que ya existe. La clave de la vista Open ODS referenciada debe coincidir con el
campo. A continuación, puede incluir cualquier característica no clave, como atributos de
navegación. Puede asignarles nuevos nombres y descripciones locales. Los motivos para
llevar a cabo esta asociación son similares a los motivos para reutilizar InfoObjetos BW, e
incluyen lo siguiente:
● Solo es necesario definir la relación una vez
● Puede añadir más información a sus hechos
● Solo tiene que utilizar la asociación cuando sea necesario
● Puede evitar la lectura innecesaria de datos maestros

Sin embargo, los InfoObjetos están más avanzados. Los InfoObjetos le permiten definir
atributos dependientes del tiempo y le permiten utilizar fórmulas que aprovechan las
variables definidas en el InfoObjeto asociado.
Las consultas en la vista Open ODS heredan propiedades del objeto asociado.
Las propiedades especificadas mediante la asociación se pueden volver a modificar en la
propiedad; seleccione Conmutar valor predeterminado/Entrada manual. También puede
utilizar esta opción para reinicializar las modificaciones locales.

Para añadir atributos a una vista Open ODS de tipo de texto

Para permitir que una vista Open ODS contenga atributos y textos, puede añadir más
semánticas, aparte de la semántica especificada durante la creación, a la vista. Puede añadir
textos a las vistas Open ODS con atributos y puede añadir atributos a las vistas Open ODS
con textos.

260 © Copyright. Reservados todos los derechos.

 Lección: Implementación de modelado basado en campos con vistas Open ODS

Por ejemplo, si en el primer paso necesita un modelo de datos simple para el que solo desea
utilizar textos sobre los hechos Vistas Open ODS, puede añadir el modelado de atributos en
un paso posterior. Esto significa que la función también soporta el modelado flexible de vistas
Open ODS.

1. En el menú Editar, seleccione la siguiente entrada:

● Añadir atributos en una vista Open ODS con textos

● En una vista Open ODS con atributos: Añadir textos

2. En la siguiente ventana de diálogo, añada datos para los objetos fuente y destino para la
semántica añadida.

3. Actualice la asignación de campos clave.

4. Seleccione Crear.
La vista Open ODS ahora muestra la etiqueta para la semántica añadida.

5. Especifique la estructura de la vista Open ODS para la semántica añadida.

6. Verifique, grabe y active la vista Open ODS.

Modificación de la referencia
Otra opción de remodelado es sustituir una fuente para las vistas Open ODS por otra fuente.
Inicie la actualización de la vista Open ODS en la etiqueta Semántica y modifique el nombre de
la tabla. Siempre que el Open ODS permanezca consistente después de intercambiar la
fuente, los objetos que se construyen en la vista Open ODS, como consultas, por ejemplo, se
pueden seguir utilizando.

Integrar datos transaccionales con vistas Open ODS

Figura 186: Asignación de unidad o cantidad

Separar diferentes atributos es una tarea frecuente en los informes empresariales.

Para asignar una moneda o unidad, debe definirse como un campo de moneda.
A continuación, la agregación definida solo es posible para importes de la misma moneda.
Esto se recomienda para evitar agregaciones inútiles.

© Copyright. Reservados todos los derechos. 261

Capítulo 7 : Implementación de modelos basados en campos de SAP BW/4HANA

Si asocia un ratio con un InfoObjeto, la propiedad Moneda/Unidad debe ser consistente con el
InfoObjeto asociado. Asegúrese de que el campo de moneda o el campo de unidad
especificados coincidan con las propiedades del InfoObjeto.
El elemento referenciado ya debe estar asignado al InfoObjeto de unidad correcto.

Unión de diferentes vistas

Figura 187: CompositeProvider que contiene dos vistas Open ODS

Si diferentes vistas Open ODS tienen campos comunes, se pueden integrar en un

CompositeProvider común. Si se selecciona la operación de unión, la propiedad de
agregación para un indicador determina cómo se deriva el valor total. Se crea
automáticamente un nuevo campo InfoSitio. Puede restringir el acceso a un proveedor de
origen aplicando un filtro a este campo. De lo contrario, ambos proveedores fuente se leen en
paralelo y el método de agregación se aplica en ambas fuentes. Recomendamos la asociación
de InfoObjetos para garantizar una agregación consistente.
En los ejercicios siguientes, creará el siguiente escenario.
En primer lugar, los datos de almacenamiento se proporcionan virtualmente desde el sistema
fuente T41 mediante una vista Open ODS que se basa en una fuente de datos BW. Esta fuente
de datos BW debe crearse en la parte superior de una vista CDS ABAP. En lugar de una vista
Open ODS adicional para los datos del sistema fuente CIA, un CompositeProvider consume
directamente una vista de cálculo de SAP HANA.
En segundo lugar, a medida que el curso avanza, los datos de almacenamiento se cargarán
desde ambas fuentes para persistir instantáneas semanales.

262 © Copyright. Reservados todos los derechos.

 Lección: Implementación de modelado basado en campos con vistas Open ODS

Figura 188: Ejercicios: Virtualización con vista de cálculo, vista Open ODS y proveedor compuesto

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Comprender el objetivo del modelado basado en campos con vistas Open ODS
● Conectar orígenes de datos
● Combinar hechos, datos maestros y textos en vistas Open ODS
● Integrar datos transaccionales con vistas Open ODS

© Copyright. Reservados todos los derechos. 263

Capítulo 7 : Implementación de modelos basados en campos de SAP BW/4HANA

264 © Copyright. Reservados todos los derechos.

 Capítulo 7
Lección 2
Comprender los modelos de memoria
corporativa y de instantánea

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Comprender la instantánea y la memoria corporativa

Comprender los modelos de memoria corporativa y de instantánea

Figura 189: Escenario empresarial: Instantáneas y memoria corporativa

Imagine el siguiente escenario empresarial: desarrolle y pruebe un nuevo modelo de negocio

de una manera simple (creación rápida de prototipos) basado en una vista Open ODS. Desea
generar un aDSO persistente con los mismos campos si hay demanda para este modelo.
En función del escenario, existen diferentes formas de generar datos persistentes:
● Cargar y agregar
Acumular cantidades de producción de diferentes instantáneas. Si se requieren diferentes
formas de agregación de datos, extraiga los datos una vez y despliéguelos en varios
destinos.
● Instantánea
Si solo necesita un acceso rápido a los valores actuales de las reclamaciones abiertas, la
dirección y el número de teléfono de sus interlocutores comerciales desde los valores de
origen de períodos anteriores ya no son necesarios. Genere una instantánea, es decir, un
extracto completo nuevo de la vista Open ODS en un aDSO en un momento determinado.
Para las cantidades de almacenamiento, puede esperar ver la cantidad total exacta y
consistente para cada producto y ubicación a partir de las 8:00 am del día actual.

© Copyright. Reservados todos los derechos. 265

Capítulo 7 : Implementación de modelos basados en campos de SAP BW/4HANA

● Soporte de instantáneas
A partir de una lista de instantáneas con cantidades para sus ubicaciones de
almacenamiento, determine las diferencias entre dos instantáneas. Puede utilizar estos
datos para determinar períodos de estabilidad (sin modificaciones). Puede actualizar
estos datos aún más para generar valores de entrada y salida para un escenario de
inventario con valores no acumulados (véase la unidad 12). La función de soporte de
instantáneas genera un registro de modificaciones incluso para ubicaciones que se
cerraron.
● Memoria corporativa
No tiene ningún escenario de gestión de informes actual, pero desea generar un historial
de cantidades de almacenamiento detalladas y valores de producto a partir de extractos
de datos regulares en intervalos periódicos. Al almacenar estos valores, añada el tiempo
de la extracción. Desde este almacén de datos, puede responder preguntas futuras sobre
tendencias de precio y cantidad, o valores promedio durante diferentes períodos de
tiempo.

Figura 190: Convertir el acceso virtual en un modelo de datos persistente

El objetivo principal de una vista Open ODS es dar soporte al acceso virtual a los datos
originales. La ventaja principal es la gestión de informes en tiempo real. Como se ha descrito
en la lección anterior, puede utilizar una vista Open ODS como InfoSitio para queries con
fórmulas. Sin embargo, recomendamos incluir una vista Open ODS como PartProvider dentro
de un CompositeProvider y crear consultas BW solo en la parte superior del
CompositeProvider.
Las ventajas de utilizar un CompositeProvider como interfaz para consultas BW son las
siguientes:
● Si se debe incluir otra fuente, puede crear otra vista Open ODS y añadirla como un
PartProvider adicional del CompositeProvider. No es necesario realizar cambios en las
consultas.

266 © Copyright. Reservados todos los derechos.

 Lección: Comprender los modelos de memoria corporativa y de instantánea

● Puede asociar InfoObjetos o vistas Open ODS de datos maestros en el nivel de

CompositeProvider. La asignación de datos maestros una vez en este nivel garantiza la
consistencia de los datos maestros. Además, es menos trabajo que repetir la asignación
para cada InfoSitio.
● En lugar de las vistas Open ODS, puede seleccionar otros InfoSitios como PartProviders
cuando desee cambiar del acceso virtual a los datos persistentes. No es necesario
modificar las consultas BW.

Tenga en cuenta que los usuarios empresariales verán diferentes datos (según lo previsto) en
los informes cuando modifique los PartProviders de los CompositeProviders.
¿Por qué debería querer cambiar a datos persistentes? Las desventajas del acceso virtual son
las siguientes:
● Rendimiento
La lectura de la fuente es mucho más lenta que la lectura de valores de SAP BW/4HANA,
especialmente si se trata de una base de datos tradicional.
● Carga de trabajo
Si no hay ningún filtro en la consulta, se leen todos los valores en la fuente. Esto resulta en
una gran carga de trabajo para el sistema original y un gran tráfico de red. Este estrés se
produce cada vez que se ejecuta la consulta.
● Valores volátiles en la fuente
Los valores pueden cambiar entre diferentes ejecuciones. Puede que no sea posible
reproducir resultados.
● Transformaciones limitadas
Con la vista Open ODS basada en fuentes de datos, tablas o vistas, los valores se leen 1:1.
Los cálculos y transformaciones se limitan a las posibilidades de consulta.

Si desea evitar estos problemas, seleccione el almacenamiento persistente. La imagen,

Convertir el acceso virtual a un modelo de datos persistente, muestra dos opciones. Si las dos
vistas Open ODS tienen campos similares, considere grabar el contenido en el mismo aDSO.
De lo contrario, cree dos aDSO diferentes y combínelos en un CompositeProvider.
Es posible generar un flujo de datos desde una vista Open ODS existente utilizando un
asistente. A continuación, se añade la misma vista Open ODS en la parte superior de un aDSO
generado. Ahora veremos esta función con más detalle.

© Copyright. Reservados todos los derechos. 267

Capítulo 7 : Implementación de modelos basados en campos de SAP BW/4HANA

Figura 191: Convertir una vista Open ODS en un ADSO

No es necesario crear un aDSO desde cero. Es más fácil generar automáticamente un flujo de
datos y un aDSO. Técnicamente, se crean una fuente de datos de SAP BW/4HANA (tipo
ODP), transformación, aDSO y DataTransferProcess (DTP).

Nota:
Los objetos generados con el flujo de datos se escriben en el paquete local $TMP
sin consulta de transporte. Modifique la asignación de paquete en la conexión de
transporte del sistema back end BW/4HANA y escriba los objetos en una orden
de transporte manualmente.

1. Puede empezar con una vista Open ODS que se genera basada en una tabla de base de
datos, una vista de base de datos, la vista de cálculo nativa de SAP HANA, una tabla virtual
utilizando el acceso a datos inteligentes de SAP HANA o una fuente de datos BW. Deje que
la propuesta de campo se genere automáticamente. Asegúrese de desplazar la
combinación de campos que forman la clave semántica a la carpeta de características
(clave). Asegúrese de que todos los ratios de importe tienen una moneda asignada y que
todos los campos de cantidad tienen una unión asignada.

2. Si se necesita más información semántica, asocie InfoObjetos a nivel de vista Open ODS.

3. Pruebe el escenario.

Nota:
Si aún necesita el escenario original en tiempo real, copie primero la vista Open
ODS.

268 © Copyright. Reservados todos los derechos.

 Lección: Comprender los modelos de memoria corporativa y de instantánea

Si el escenario funciona según lo previsto, genere un flujo de datos con un aDSO según los
siguientes pasos:

1. En la ficha General, seleccione Generar flujo de datos en Semántica. Aparecerá el asistente

para crear el flujo de datos.

2. Si la vista Open ODS tiene como fuente una tabla de base de datos o una tabla virtual, cree
una fuente de datos en el primer paso:

a. Asigne un nombre de fuente de datos.

b. Especifique qué hacer con los tipos de datos de los campos. El gestor de análisis solo
admite tipos de datos específicos para la gestión de informes. Si la fuente utiliza
diferentes tipos de datos, estos tipos se convierten automáticamente en el tiempo de
ejecución. Si crea el objeto de destino con tipos de datos SAP BW, esta conversión no
se debe realizar en tiempo de ejecución.

c. Seleccione Finalizar.
El sistema crea ahora una fuente de datos en el sistema fuente de la vista Open ODS
en el componente de aplicación NODESNOTCONNECTED. Los campos de esta fuente
de datos se crean a partir de los campos fuente de la vista Open ODS.
El sistema sustituye por la vista Open ODS por el objeto fuente. El objeto fuente es
ahora la fuente de datos.
Si la vista Open ODS tiene ahora una fuente de datos como fuente, cree un objeto
DataStore (avanzado). Para ello, vaya a la ficha General y seleccione Generar flujo de
datos en Semántica. Aparecerá el asistente para crear el flujo de datos.

d. Seleccione el tipo de objeto Objeto de fuente de datos (avanzado) como objeto de

destino.

e. Asigne un nombre para el objeto DataStore (avanzado).

f. Especifique qué hacer con los tipos de datos de los campos. Seleccione los tipos de
datos de SAP BW, lo que facilita el uso del aDSO en otros objetos BW/4HANA.

g. Seleccione Finalizar.
El sistema crea un objeto DataStore avanzado basado en campos con una tabla activa
pero sin log de modificaciones en la InfoÁrea de la vista Open ODS. El objeto fuente de
la vista Open ODS es ahora la tabla activa del objeto DataStore avanzado.

3. Si necesita un tipo diferente de aDSO, vaya a la pestaña General y seleccione las opciones
necesarias.

4. Los campos de la tabla activa se transfieren de los campos de la estructura de la vista

Open ODS. Las asociaciones con campos de vista Open ODS se ignoran al crear el objeto
DataStore. Integre el aDSO en un CompositeProvider y vuelva a añadir las asociaciones.

El sistema crea una transformación entre la fuente de datos y el objeto DataStore y un

proceso de transferencia de datos para esta transformación.
Este escenario que implica la persistencia gestionada por BW es comparable con un
Persistent Staging Area (PSA) donde los datos se pueden seguir procesando. Funciona como
una tabla PSA con posibilidades de gestión de informes adicionales para datos brutos
almacenados. Para fines puramente informativos, se recomienda utilizar la vista Open ODS
directamente si se requiere un reporting en tiempo real y utilizar un CompositeProvider como
InfoSitio de capa continua. Si se requiere el reporting en tiempo real y los valores

© Copyright. Reservados todos los derechos. 269

Capítulo 7 : Implementación de modelos basados en campos de SAP BW/4HANA

almacenados, cargue instantáneas del CompositeProvider o genere un flujo de datos solo con
una fuente de datos para la vista Open ODS.
Sin cargar y activar los datos, este modelo de datos no verá ningún dato. En este escenario,
se duplican (replican) datos de una fuente fuera del esquema de SAP BW/4HANA en el
esquema de SAP BW/4HANA. Es importante verificar que este paso sea realmente necesario.

Figura 192: Carga y agregación de datos

Existen diferentes versiones de modelo para cómo se pueden almacenar los datos en el aDSO
correspondiente y cargarlos en otros destinos.
La imagen "Carga y agregación de datos" muestra cómo se almacenan y condensan los
datos.
Si genera un flujo de datos con aDSO desde una vista Open ODS, la lista de campos de la vista
y la definición de clave se toman del aDSO. Sin embargo, puede modificar la definición.
Elimine características irrelevantes como el número de ubicación de la definición aDSO para
ahorrar espacio de disco.
Si carga valores de diferentes fuentes y desea mantener estos registros separados, añada
Fuente como un campo nuevo. Cada registro se carga 1:1 en la tabla de entrada del aDSO.
Utilice una transformación para rellenar el nuevo campo.
Para conjuntos de datos pequeños y medianos, puede eliminar la propiedad de modelado
aDSO Activar datos. A continuación, los registros de la tabla de entrada están disponibles
directamente para la gestión de informes. Sin embargo, si esta tabla es grande, la gestión de
informes puede ser algo más lenta y la carga puede ser mucho más lenta.
Para preagregar valores, defina una clave semántica y aplique Activar datos. Para cada
indicador, defina si desea visualizar un máximo, un mínimo o un total de diferentes filas con la
misma clave. El tamaño de la tabla de datos activos depende de la definición de la clave aDSO.
La definición clave debe basarse en los requisitos de informes. Si el nuevo campo Fuente debe
distinguirse en los informes, márquelo como campo clave aDSO.
Además de las consideraciones de rendimiento, puede utilizar la opción Activar datos como
un paso de la gestión de calidad. Active sólo aquellos registros de datos que haya verificado

270 © Copyright. Reservados todos los derechos.

 Lección: Comprender los modelos de memoria corporativa y de instantánea

como correctos. Cuando mantiene la propiedad de modelado aDSO Activar datos, solo los
datos activados son visibles en la gestión de informes. Ahora tiene varias opciones
adicionales.
Si los detalles de los registros originales ya no son necesarios, no seleccione ninguna otra
propiedad de modelado aDSO para mantener el tamaño de almacenamiento pequeño. Tenga
en cuenta que con esta opción, se pierde toda la información sobre solicitudes y
modificaciones individuales. Las solicitudes activadas ya no se pueden borrar.
Si es posible que necesite borrar solicitudes activadas, debe seleccionar Activar datos y
Escribir log de modificaciones. Cuando se borran las solicitudes, una operación de rollback
restablece la situación antes de la activación. Si anula una solicitud, todas las solicitudes
posteriores deben deshacerse primero. Tenga en cuenta que borrar solicitudes y cargarlas de
nuevo modificará el resultado si la fuente se ha modificado.
Si desea actualizar los valores a destinos subsiguientes con una definición de clave diferente,
con otros métodos de agregación o con el número de ubicaciones, necesitará los detalles de
entrada para la extracción. Active el indicador Conservar datos entrantes, Extraer de tabla de
entrada en las Propiedades de modelado del aDSO. Tenga en cuenta el impacto en el
consumo del espacio de almacenamiento. Si los datos se extraen de la tabla de entrada, no es
necesario generar ningún log de modificaciones.
Con este escenario, se recupera el mínimo o el total en todas las ubicaciones. Sin embargo, si
carga registros día tras día, el mínimo o el total de todos los días se almacena en la tabla
Datos activos. ¿Qué debe hacer si necesita los totales solo para los valores del día actual?
Tenga en cuenta los siguientes escenarios.

Figura 193: Generación de instantáneas

La imagen, Generación de instantáneas, muestra el escenario de instantánea Cargar y soltar.

Una instantánea es un extracto completo en un momento determinado que se almacena de
forma persistente. A intervalos regulares o irregulares, cargue todos los valores de una o más
fuentes a un aDSO. Utilice el método de extracción completo. Active los datos. Si se borran o
modifican registros en la fuente, los valores en el aDSO se conservan.

© Copyright. Reservados todos los derechos. 271

Capítulo 7 : Implementación de modelos basados en campos de SAP BW/4HANA

Para generar la siguiente instantánea, borre todo el contenido del aDSO destino y cargue los
nuevos valores.

Figura 194: Activación con soporte de instantáneas

Supongamos que desea recuperar la entrada y salida diarias de sus instantáneas de

almacenamiento. El método Soporte de instantáneas está diseñado para determinar las
modificaciones, incluso si las instantáneas no proporcionan valores 0 para los registros
borrados. La forma más fácil es ajustar las opciones del aDSO de destino. Además de Activar
datos, debe seleccionar Escribir log de modificaciones y Soporte de instantáneas. La imagen,
Activación con soporte de instantánea, muestra un ejemplo.
Pueden darse las siguientes situaciones:
● La instantánea se carga por primera vez. Todas las líneas se introducen en el aDSO de
destino. Durante la activación de datos, para cada producto, el total de la cantidad se
almacena en la Tabla activa. Si la opción Escribir log de modificaciones está activa, estos
totales se introducen en la tabla Log de modificaciones como líneas nuevas.
● Un producto se clasifica y ya no se almacenará en las tablas de origen. En el ejemplo, ya no
existe ningún registro para el producto obsoleto HT-1080. Con las opciones Escribir log de
modificaciones, Soporte de instantánea, el sistema genera un registro de almacenamiento
en la tabla Log de modificaciones (cantidad: -280). Sin la opción Soporte de instantánea,
esta línea no se generaría en la tabla Log de modificaciones.
● Aún existe un producto, pero con una cantidad de almacenamiento diferente. En el
ejemplo, el total del producto HT-1081 cambia de 110 a 70. El valor se actualiza en la tabla
Datos activos. Con la opción Escribir log de modificaciones (con o sin soporte de
instantánea), el sistema genera un registro de almacenamiento y un registro after-image
en la tabla Log de modificaciones (cantidad: -110, luego +70).
● Aún existe un producto con la misma cantidad de almacenamiento. En el ejemplo, el total
del producto HT-1082 permanece en la cantidad 115. No es necesario realizar ninguna
modificación en la tabla Datos activos. No se añade ninguna entrada para este producto en
la tabla Log de modificaciones.

272 © Copyright. Reservados todos los derechos.

 Lección: Comprender los modelos de memoria corporativa y de instantánea

● Se añade un producto nuevo que no se ha almacenado antes. En el ejemplo, el producto

HT-1083 es nuevo con la cantidad 50. En la tabla Datos activos y en la tabla Log de
modificaciones, se añade un nuevo registro (con el valor +50).

La tabla Log de modificaciones se puede utilizar en los siguientes escenarios:

● Determinar los valores de entrada y de salida para un escenario de gestión de stocks
(ratios no acumulativos, véase la unidad 12).
● Determinar el número de modificaciones para un producto específico
● Actualice los valores delta a otro destino en el que el ratio de cantidad sea aditivo (ratio
acumulado). Para leer sólo los valores que aún no se han incluido en el destino, seleccione
el modo de extracción Delta en el DTP. (Puede obtener más información sobre los
mecanismos delta en el curso BW450.)

Si la opción Soporte de instantánea está activa, asegúrese de que cada carga de datos
contenga los mismos valores de filtro o simplemente cargue un conjunto completo de datos.
Si se activa un filtro, se producirán registros de almacenamiento.

Figura 195: Generar un historial

La imagen "Generar un historial" muestra un escenario para crear una memoria corporativa.
Para este escenario, debe añadir el cronomarcador de fecha o hora como campo clave
adicional. En el ejemplo, seleccione Día y Producto como clave aDSO combinada. A
continuación, los registros existentes no se modifican al cargar nuevos valores. Al igual que
en otros escenarios, al eliminar algunos campos, puede agregar valores de diferentes
registros.
En este escenario, todos los registros en aDSO tienen diferentes claves. A continuación,
recomendamos una de las dos opciones siguientes:
● Generar un historial
Si desea especificar un conjunto de características clave con valores dependientes o
implementar un paso de gestión de calidad, implemente la activación de datos. Para

© Copyright. Reservados todos los derechos. 273

Capítulo 7 : Implementación de modelos basados en campos de SAP BW/4HANA

mejorar el rendimiento de la activación, seleccione solo las propiedades de modelado

Activar datos y Registros de datos unívocos. (No se necesita un log de modificaciones,
solo repetiría los valores.)
● Memoria corporativa
Si no necesita un paso de gestión de calidad, puede modificar las opciones del aDSO para
que los datos no estén activados. Todos los registros permanecen en una tabla, la tabla de
entrada.

Para actualizaciones en otros destinos, puede utilizar lo que se denomina un pseudodelta:

para obtener las nuevas entradas cada día, extraiga datos con un filtro variable para el día
actual. En función del escenario, lea desde la tabla Datos activos o desde la tabla de entrada.

Figura 196: Ejercicio: Instantáneas semanales

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Comprender la instantánea y la memoria corporativa

274 © Copyright. Reservados todos los derechos.

 Capítulo 7

Evaluación de la formación

1. El enfoque basado en campos significa que todos los campos están asignados a un
InfoObjeto de SAP BW.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

2. ¿Qué objetos BW/4HANA se pueden modelar como un modelo puramente basado en

campos?
Seleccione las respuestas correctas.

X A InfoObjetos con jerarquías

X B Vistas Open ODS

X C ADSO

X D CompositeProviders

3. ¿Cuál es el beneficio durante la activación de datos si la propiedad Soporte de instantánea

está establecida en un aDSO?
Seleccione la respuesta correcta.

X A Para la primera solicitud completa, no se generan entradas del log de

modificaciones.

X B Si un registro extraído por una solicitud completa anterior se borra en la fuente y

se carga una nueva solicitud completa, el sistema genera un registro de anulación en
la tabla Log de modificaciones incluso si la fuente no proporciona una imagen de
borrado o un registro storno.

X C Si un registro extraído por una solicitud completa anterior se extrae de nuevo con
el mismo valor, el sistema genera una Before-Image y una nueva imagen en la tabla
Log de modificaciones aunque ambos sumen 0.

© Copyright. Reservados todos los derechos. 275

 Capítulo 7

Respuestas a la Evaluación de la formación

1. El enfoque basado en campos significa que todos los campos están asignados a un
InfoObjeto de SAP BW.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

Tienes razón. El enfoque basado en campos significa que los campos se pueden modelar
con un nombre individual y un tipo de datos, sin referencia a un InfoObjeto de SAP BW.
Leer más en el módulo Implementación de modelos basados en campos, en el curso
BW430.

2. ¿Qué objetos BW/4HANA se pueden modelar como un modelo puramente basado en

campos?
Seleccione las respuestas correctas.

X A InfoObjetos con jerarquías

X B Vistas Open ODS

X C ADSO

X D CompositeProviders

¡Correcto! Las vistas Open ODS, aDSO y CompositeProviders se pueden modelar

exclusivamente en función del campo (o como una combinación con InfoObjetos). Las
jerarquías en BW/4HANA solo se pueden implementar en InfoObjetos, no en campos.
Leer más en el módulo Implementación de modelos basados en campos, en el curso
BW430.

3. ¿Cuál es el beneficio durante la activación de datos si la propiedad Soporte de instantánea

está establecida en un aDSO?
Seleccione la respuesta correcta.

X A Para la primera solicitud completa, no se generan entradas del log de

modificaciones.

X B Si un registro extraído por una solicitud completa anterior se borra en la fuente y

se carga una nueva solicitud completa, el sistema genera un registro de anulación en

276 © Copyright. Reservados todos los derechos.

 Capítulo 7 : Respuestas a la Evaluación de la formación

la tabla Log de modificaciones incluso si la fuente no proporciona una imagen de

borrado o un registro storno.

X C Si un registro extraído por una solicitud completa anterior se extrae de nuevo con
el mismo valor, el sistema genera una Before-Image y una nueva imagen en la tabla
Log de modificaciones aunque ambos sumen 0.

Es correcto. Con la opción de soporte Instantánea, el sistema muestra el siguiente

comportamiento: si un registro (extraído por una solicitud completa anterior) se borra en
la fuente y se carga una nueva solicitud completa, el sistema genera un registro de
almacenamiento en la tabla Log de modificaciones incluso si la fuente no proporciona una
imagen borrada o un registro de almacenamiento. Sin embargo, las entradas aún se
escriben en la tabla Log de modificaciones para la primera solicitud. Y aún así, no se
generan registros en el Log de modificaciones si las imágenes de antes y después son
iguales. Leer más en el módulo Comprender la instantánea y los modelos de memoria
corporativa, en el curso BW430.

© Copyright. Reservados todos los derechos. 277

Capítulo 7 : Respuestas a la Evaluación de la formación

278 © Copyright. Reservados todos los derechos.

CAPÍTULO 8 Implementación de modelos de
datos maestros de InfoObjeto
de SAP BW/4HANA

Lección 1
Modelado e implementación de datos maestros de SAP BW/4HANA 281

Lección 2
Modelado de jerarquías de SAP BW/4HANA 301

OBJETIVOS DEL CAPÍTULO

● Enumerar las tablas en el modelo de datos de SAP BW/4HANA

● Implementar datos maestros de SAP BW/4HANA
● Modelado y uso de jerarquías de SAP BW/4HANA

© Copyright. Reservados todos los derechos. 279

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

280 © Copyright. Reservados todos los derechos.

 Capítulo 8
Lección 1
Modelado e implementación de datos
maestros de SAP BW/4HANA

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Enumerar las tablas en el modelo de datos de SAP BW/4HANA
● Implementar datos maestros de SAP BW/4HANA

Enumerar las tablas en el modelo de datos de SAP BW/4HANA

Los objetos de evaluación empresarial (clientes, volumen de ventas, etc.) se denominan
InfoObjetos en SAP BW/4HANA. Se dividen en características, ratios, unidades,
características de tiempo y características técnicas (como el ID de solicitud).
Los InfoObjetos (ratios y características) son los módulos de información más pequeños
disponibles en SAP BW/4HANA. Permiten modelar la información de forma estructurada.
También se utilizan para definir informes y para evaluar datos maestros y de transacción. Las
características describen la afiliación de ratios. Por ejemplo, los costes pertenecen a un
centro de coste, donde el centro de coste es una característica. La imagen, InfoObjeto de
característica, proporciona un resumen de las funciones que puede tener una característica
en el modelado de SAP BW/4HANA.

© Copyright. Reservados todos los derechos. 281

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

Figura 197: InfoObjeto de característica

Las características se pueden utilizar de muchas maneras diferentes en SAP BW/4HANA.

Puede informar sobre ellas, puede utilizarlas para identificar unidades y se pueden utilizar
como atributos para otras características.

Tres tipos posibles de datos maestros

● Las características en SAP BW/4HANA son los objetos de memoria central de los datos
maestros. Un InfoObjeto de característica tiene dos funciones:
- Definir el tipo de datos de elementos de estructura en SAP BW/4HANA, especialmente
en InfoSitios y consultas
- Almacene tres tipos de datos maestros (de características, características de tiempo):
■ Atributos (principalmente características, pero también ratios)
■ Textos
■ Jerarquías

Cuando activa una característica que soporta datos maestros, las tablas de datos maestros
(atributos, texto, jerarquías) se generan en la actualización de características, en función de
las opciones que haya configurado en las etiquetas.

282 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de datos maestros de SAP BW/4HANA

Figura 198: Opciones de modelación para el InfoObjeto de característica

Los datos maestros se almacenan por separado para atributos, textos y jerarquías. Los
atributos son campos relacionados, como la dirección. Los textos proporcionan
descripciones y las jerarquías se utilizan, por ejemplo, para el rollup de datos de transacción.

Figura 199: Modelado de características en Eclipse

Tipos de datos para Big Data

Solo si es necesario, utilice tipos de datos especiales para Big Data:

© Copyright. Reservados todos los derechos. 283

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

● Utilice el tipo de datos de ratios, Entero 8, para superar la limitación de dos mil millones
para valores enteros estándar.
● Las características de cardinalidad alta pueden tener más de dos mil millones de entradas.
La propiedad de cardinalidad alta solo se admite para los tipos de datos CHAR y NUMC
con longitud >= 10.

Figura 200: Actualización de InfoObjeto

Se puede fijar la longitud de los valores de característica. El máximo es de 250 caracteres

para la longitud total (compuesta) de la clave.
La existencia y la estructura de las tablas de datos maestros depende de la definición de la
característica. Solo se crea una tabla de texto si ha seleccionado la casilla de selección Textos
al crear y, a continuación, ha activado el InfoObjeto de característica. Puede elegir entre las
siguientes propiedades:
● Texto breve: 20 caracteres
● Texto de longitud media: 40 caracteres
● Texto explicativo: 60 caracteres
El texto explicativo con la opción Texto es más largo y puede tener hasta 1333 caracteres.
● Los textos pueden depender del idioma.
● Los textos pueden ser temporales.

284 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de datos maestros de SAP BW/4HANA

Figura 201: Tabla de texto para una característica

El ratio, Tabla de texto para una característica, muestra la estructura de la tabla de texto,
utilizando el ejemplo de la característica definida por el cliente COSTC. Dado que los
indicadores de texto breve, texto de longitud media, tiempo y dependencia de idioma se han
fijado en la etiqueta Datos maestros/Textos, estos campos se incluyen en la estructura de la
tabla de texto.

Consejo:
Puede simplemente activar la propiedad larga adicional para las características
existentes, no se requieren modificaciones en front end.
Sin embargo, si utiliza el campo en el código de cliente, puede que reciba un
error de sintaxis o de tiempo de ejecución, ya que el elemento de datos central
RSCHAVL debía modificarse del tipo CHAR60 a STRING 1333. Por lo tanto, los
textos ya no se transfieren a la estructura RSTXTSML. En su lugar, se transfieren
a la estructura RSTXTSMXL. Los campos tienen el mismo nombre, aunque el
campo TXTLG en la estructura RSTXTSMXL es del tipo SSTRING. Para evitar
que las modificaciones en los metadatos de BAPIs provoquen incompatibilidades
(BAPI_IOBJ_GETDETAIL, BAPI_IOBJ_CREATE y BAPI_IOBJ_CHANGE), el campo
CHACONST de la estructura BAPI6108 se ha mantenido como CHAR60. Si el
valor fijo supera los 60 caracteres, se truncará. El valor no truncado se encuentra
en la nueva estructura BAPI6108_2. Los BAPIs OLAP liberados no se han
modificado. Estos textos truncan que superan los 60 caracteres de longitud. Si
desea utilizar textos más largos, deberá cambiar a un API compatible con RFC
que lo admita. Si tiene su propia codificación, cambiar al tipo de datos SSTRING
podría provocar errores de sintaxis y de tiempo de ejecución. Para obtener más
información, consulte las notas SAP 1823174 y 1879618.

© Copyright. Reservados todos los derechos. 285

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

Figura 202: Tablas de atributos para una característica

Si ha seleccionado la opción Datos maestros en la etiqueta General, puede actualizar

atributos para las características que contienen datos maestros en la etiqueta Atributos.
Puede optar por definir atributos como atributos de visualización y atributos de navegación
como atributos independientes del tiempo o dependientes del tiempo. Esta sección se centra
solo en los atributos de visualización. Para cada característica con datos maestros se pueden
generar como máximo dos tablas de atributos para los atributos de visualización (atributos
dependientes del tiempo (Q) e independientes del tiempo (P)). Siempre que exista la tabla P o
la Q, se genera automáticamente una vista (/BIC/M<nombre de característica>) mediante P,
Q o P y Q.
Los atributos XXL son InfoObjetos XXL, que se asignan lógicamente a la característica. Puede
utilizar InfoObjetos XXL para grabar información adicional para una característica como tipo
de datos STRING o XSTRING. Además, puede especificar el tipo de datos mediante un tipo
MIME. Se admiten numerosos formatos, incluidos diferentes tipos de documentos, archivos
de audio o archivos de vídeo, textos e imágenes.

Nota:
Los siguientes servicios deben activarse en laDefault Host transacción SICF
para poder actualizar jerarquías y datos maestros para características de
InfoObjeto:
● Actualización de jerarquía: /sap/bc/webdynpro/sap/
RSSHWDY_HIERARCHY_MAINT_APP
● Actualización de datos maestros: /sap/bc/webdynpro/sap/
RSDMDM_MD_MAINTENANCE_APP y /sap/bc/webdynpro/sap/
RSDMDM_MD_NEW_APP

286 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de datos maestros de SAP BW/4HANA

Actualización de InfoObjetos en el cockpit de SAP BW/4HANA

Figura 203: Actualización de datos maestros para InfoObjetos con atributos o textos

SAP aún recomienda cargar datos maestros desde los sistemas fuente, pero si la cardinalidad
de un InfoObjeto es bastante baja o desea modificar solo un registro, el cockpit de
administración de BW/4HANA proporciona funciones de mantenimiento como las siguientes:
● Crear textos en varios idiomas.
● Añadir, modificar o borrar registros
● Copiar registros
● Buscar valores de característica (con campos clave o de atributo como criterios de
búsqueda)
● Visualizar valores sin datos maestros
● Generar una referencia de utilización para determinados valores
● Exportación de datos maestros completos a un archivo CSV

Como alternativa, puede abrir la definición de InfoObjeto en Herramientas de modelado BW y,

a continuación, seleccionar el enlace Actualización de datos maestros para llamar la interfaz
de usuario basada en web. Es fácil cambiar entre atributos independientes del tiempo,
atributos dependientes del tiempo y textos.

Propiedades de clientes BI
Defina las propiedades para el query BW. (Clase de visualización estándar, valor inicial,
parametrizaciones de rendimiento)

Enlaces entre tablas y vistas en el esquema estrella de SAP BW

Cuando los InfoObjetos se asocian en un SAP BW/4HANA a un campo de un aDSO y los
números SID se generan en el aDSO, varias tablas están implicadas en la recuperación de
datos. Las tablas SID enlazan los datos maestros con los datos de transacción. Este principio
del esquema estrella de SAP BW/4HANA se muestra en la imagen "Combinación de tablas de
datos maestros".

© Copyright. Reservados todos los derechos. 287

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

Figura 204: Combinación de tablas de datos maestros

Supongamos que un filtro para una forma jurídica de cliente (independiente del tiempo) debe
ejecutarse en un aDSO con datos de socio comercial. Se ejecutan los siguientes pasos:

1. A partir del valor clave BP200 de la categoría, derive su valor SID

2. En la tabla X del interlocutor comercial, busque todos los valores SID correspondientes del
interlocutor comercial.

3. Seleccione este número SID para buscar en aDSO.

En una situación en la que las personas responsables deben enumerarse para estos valores,
la tabla SID de los interlocutores comerciales proporciona la clave técnica de los
interlocutores comerciales relevantes. Se pueden buscar en la tabla Q para encontrar la
persona responsable correspondiente para la fecha clave requerida.

Uso de ID de sustituto (SID) y atributos de navegación

Si un atributo se debe filtrar y desglosar, conviértalo en un atributo de navegación:

1. Seleccione Atributo de navegación como Tipo de atributo en la pestaña Atributos de su

característica básica. Defina si los valores deben almacenarse como dependientes del
tiempo. (Si un atributo se define como independiente del tiempo, las versiones existentes
con la misma clave se sobrescribirán con una nueva carga de datos.)

2. Libere los atributos de navegación en el nivel de InfoSitio (CompositeProvider o vista

Open ODS). De lo contrario, solo se pueden utilizar como atributos de visualización.

3. Al definir queries, utilice atributos de navegación del mismo modo que utiliza
características, por ejemplo, como Características libres o en una selección.

El sistema crea las siguientes tablas cuando se activa la característica:

● Tabla sustituta (tabla S): contiene una clave artificial (llamada ID sustituto o SID) para
cada valor de clave semántica de la característica correspondiente.

288 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de datos maestros de SAP BW/4HANA

● Tablas de atributos: La tabla P contiene atributos que no dependen del tiempo, la tabla Q
contiene atributos dependientes del tiempo (en ambos casos, atributos de visualización y
navegación).
● Tablas de atributos de navegación: la tabla X contiene ID sustitutos de los atributos
independientes del tiempo, la tabla Y contiene ID sustitutos de los atributos dependientes
del tiempo.
● Tabla de texto: la tabla T contiene textos.
● Tablas de jerarquía: véase la lección siguiente

El objetivo de la tabla S es enumerar todos los valores existentes para las verificaciones de
referencia. El objetivo de los ID sustitutos en la tabla S, X e Y es mejorar el rendimiento para
buscar valores de atributo de navegación. El sistema genera automáticamente las claves de
ID de sustituto (SID) cuando se cargan los datos maestros. La clave de la tabla S es la
característica para la que se han generado los valores de ID sustituto. Si la característica está
relacionada, la clave también se compone de la característica relacionada.
La figura, Tabla S (SID) para una característica, ilustra la relación entre la tabla S y las tablas
que pertenecen a la característica de datos maestros BP. La cifra se ha simplificado.

Figura 205: Tabla S (SID) para una característica

Atributos de navegación independientes del tiempo

La tabla X solo se genera si al menos un atributo independiente del tiempo está definido como
atributo de navegación. La clave de la tabla X es el SID de la característica básica y la versión
de objeto. La clave externa de un atributo de navegación (elemento de datos S_<nombre de
atributo>) es el SID de la característica de atributo. La imagen, Tablas X e Y para una
característica, ilustra la estructura de la tabla y el siguiente ejemplo: el centro de beneficio es
un atributo de navegación independiente del tiempo para la característica BP. La cifra se ha
simplificado.

© Copyright. Reservados todos los derechos. 289

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

Figura 206: Tablas X e Y para una característica

Atributos de navegación dependientes del tiempo

La tabla Y solo se genera si al menos un atributo dependiente del tiempo está definido como
atributo de navegación. El comportamiento corresponde a la forma en que se utiliza la tabla
X, pero con una diferencia: Para distinguir diferentes registros para diferentes intervalos de
tiempo, DATETO es parte de la clave. Se selecciona el registro que contiene la fecha clave del
query BW.

Nota:
Fijar la fecha clave en un query BW no solo puede influir en los valores de atributo,
sino también en la visualización de textos y jerarquías

Varias tablas están implicadas en la recuperación de datos. Supongamos que un filtro como
"P100" para el centro de beneficio (independiente del tiempo) debe ejecutarse en un aDSO
con datos de centro de coste. Se ejecutan los siguientes pasos:

1. A partir del valor clave P100 del centro de beneficio, derive su valor SID.

2. En la tabla X del centro de coste, busque todos los valores correspondientes del centro de
coste.

3. Seleccione estos valores para buscar en el aDSO.

En una situación en la que las personas responsables deben enumerarse para estos valores,
estos valores se pueden buscar en la tabla Q para encontrar la persona responsable
correspondiente para la fecha clave requerida.

Problemas, recomendaciones y limitaciones

Al utilizar las opciones de atributo, tenga en cuenta lo siguiente:
● Todos los InfoObjetos pueden ser atributos de visualización, pero las unidades y los ratios
no pueden ser atributos de navegación.

290 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de datos maestros de SAP BW/4HANA

● Se recomienda utilizar características de tiempo con atributos de navegación (0CALYEAR

como atributo de 0CALDAY).
● Un atributo de navegación de un atributo de navegación se puede convertir en un atributo
de navegación transitiva.
● Puede restringir la posibilidad de utilizar un atributo como atributo de navegación. Las
características que tienen la propiedad Solo atributo solo pueden ser atributos de
visualización, no atributos de navegación de otras características. Además, para una
característica básica específica, puede volver a Atributo de visualización en la pestaña
Atributo de la característica básica.
● Con los atributos dependientes del tiempo, puede visualizar los datos de transacción
actuales con valores de atributo históricos y datos históricos con valores de atributo
actuales. Asegúrese de que los usuarios sepan lo que ven.
● La utilización de atributos dependientes del tiempo tiene un ligero impacto en el
rendimiento de los procesos de carga de datos y de lectura de datos, en comparación con
la utilización de atributos independientes del tiempo (porque se debe evaluar el campo
clave de tiempo correspondiente).
● El uso de atributos de navegación tiene un ligero impacto en el rendimiento de los
procesos de carga de datos y los procesos de lectura de datos, en comparación con el uso
de características (porque las tablas X o Y están implicadas).

La tabla S no se genera en los siguientes casos excepcionales:

● Cuando se define una característica con la opción Solo atributo. (Una característica de
este tipo sólo se puede definir como atributo de visualización de otra característica.)
● Cuando una característica se define como un InfoObjeto de cardinalidad alta. (Una
característica de este tipo puede almacenar más de 2.000 millones de registros.)

Las características sin valores SID (solo atributo, cardinalidad alta) no se pueden utilizar en
los siguientes casos:
● Como elemento superior de relación
● Como atributo de navegación
● Como InfoObjeto aDSO con la verificación de datos maestros durante la carga/activación y
la opción Persistir SID en DataStore (puede utilizar una verificación de datos maestros sin
generación de SID o sin verificación de datos maestros).
● En jerarquías

Los tiempos de respuesta de las consultas pueden verse afectados.

Casos especiales de modelado de atributos

Normalmente, los ratios se implementan para almacenar los hechos, pero también se pueden
utilizar como atributos.
Ratios como atributos
Los precios son un buen ejemplo de ratios como atributos. Por ejemplo, el precio describe un
artículo, como el atributo del fabricante. Por lo tanto, tiene sentido añadir el precio a la tabla
de datos maestros. En este caso, modele el precio como un atributo en una tabla de datos
maestros.

© Copyright. Reservados todos los derechos. 291

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

Cuando se utiliza una variable de fórmula, el atributo de navegación precio se puede utilizar
para calcular, por ejemplo, ventas netas = precio x número de unidades vendidas. Esto facilita
los cálculos en las consultas. Además, considere una dimensión categórica como precio alto,
bajo o medio si se debe utilizar para el análisis.

Modificaciones en un InfoObjeto de característica después de cargar los datos

maestros
Puede realizar las siguientes modificaciones en una característica después de que se hayan
cargado los datos maestros:

● Puede cambiar entre atributos de visualización y atributos de navegación.

● Puede activar o desactivar un atributo transitorio.
● Puede añadir un atributo, una versión de texto o una jerarquía nuevos.
● Un atributo independiente del tiempo se puede cambiar a un atributo dependiente del
tiempo.
● Se puede añadir otra característica de relación.
● Puede borrar un atributo, una versión de texto o una jerarquía, pero tenga en cuenta las
consecuencias (efectos en otros objetos, pérdida de datos).

En estos casos, se añaden valores por defecto (referencia temporal del 1 de enero, 1000 al 31
de diciembre de 9999 y contenido vacío en los nuevos campos clave o de atributo).
Mientras el InfoObjeto contenga datos, no es posible cambiar un atributo o texto de una
versión dependiente del tiempo a una versión independiente del tiempo. No es posible
eliminar campos relacionados. No es posible modificar el tipo de datos o la longitud. Para
realizar estas modificaciones, debe crear una copia del InfoObjeto, cargar todos los datos en
la copia, borrar todo el contenido del InfoObjeto original y volver a cargar los valores de la
copia. En una transformación, por ejemplo, puede decidir utilizar el intervalo que coincide con
el día actual o sobrescribir duplicados. Finalmente, limpie y borre el otro InfoObjeto.
Estos pasos se visualizan en la imagen "Modificaciones en las tablas de atributos".

Figura 207: Modificaciones en las tablas de atributos después de cargar los datos maestros

Puede ampliar la estructura de las características que contienen datos maestros después de
que se hayan cargado los datos maestros.
También puede añadir atributos nuevos o ampliar las casillas de selección para los textos,
pero luego debe ejecutar una nueva carga de datos para rellenar los nuevos campos de las
tablas de datos maestros.

292 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de datos maestros de SAP BW/4HANA

No puede borrar campos de una estructura si los campos contienen datos. Si desea modificar
un atributo dependiente del tiempo en un atributo independiente del tiempo, primero debe
borrar el contenido de las tablas para la característica.

Actualización de datos maestros ampliada

Para características con atributos y/o textos, puede utilizar la actualización de datos
maestros ampliada. Esto permite la carga paralela de datos y el seguimiento de
modificaciones. Para ello, el atributo recibe tablas adicionales. Entonces tiene una estructura
como un objeto DataStore (avanzado) con una tabla de entrada y un log de modificaciones.
La actualización de datos maestros ampliada es una ventaja si desea cargar una gran
cantidad de datos o cargar datos de varias fuentes de datos simultáneamente. También
puede cargar deltas de un InfoObjeto a otro InfoObjeto.

Figura 208: Actualización de datos maestros estándar para características de InfoObjeto en SAP BW/4HANA

Por defecto, la forma estándar de cargar datos en el InfoObjeto Características se ejecuta en

orden secuencial. La paralelización no es posible, pero si solo está cargando una pequeña
cantidad de datos, esto no es un problema. Los datos se cargan directamente en las tablas de
atributos o de texto y la versión se activa inmediatamente (OBJVERS = A). No se requiere un
proceso de activación aparte.

© Copyright. Reservados todos los derechos. 293

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

Figura 209: Actualización de datos maestros ampliada para características de InfoObjeto en SAP BW/4HANA

Si sus requisitos están en conflicto con el procesamiento secuencial del aprovisionamiento de

datos en características de InfoObjeto con atributos y/o textos, puede utilizar la propiedad
Actualización de datos maestros ampliada en SAP BW/4HANA para habilitar la carga paralela
de los datos. La característica InfoObjeto tiene una estructura como un objeto DataStore
avanzado, con tablas adicionales como una tabla de entrada y un log de modificaciones. La
actualización de datos maestros ampliada es útil si desea cargar una gran cantidad de datos o
cargar datos de varias fuentes de datos simultáneamente. También puede cargar deltas de
un InfoObjeto a otro InfoObjeto o aDSO.
Las tablas nuevas se crean cuando se define esta propiedad:
● Tabla de entrada para atributos: /BIC/D<techn.Name>
● Log modif.p.atributos: /BIC/E<techn.Name>
● Tabla de entrada para textos: /BIC/F<techn.Name>
● Log de modificaciones para textos: /BIC/G<techn.Name>

294 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de datos maestros de SAP BW/4HANA

Figura 210: Flujo de proceso de actualización de datos maestros ampliado

Los datos se cargan inicialmente en paralelo en la tabla de entrada. Cuando se activa, se

actualizan el log de modificaciones y las tablas activas de atributos o textos del InfoObjeto. La
activación se puede procesar en paralelo en tiempo de ejecución ABAP o en el tiempo de
ejecución de SAP HANA (HANA 2.0 SPS03 es un requisito previo para el tiempo de ejecución
de SAP HANA). Para ello, dispone de una nueva variante de proceso, Activar datos maestros.
Puede realizar parametrizaciones para procesar solicitudes en la transacción
RSDMD_SETTINGS.

Nota:

● A partir de BW/4HANA 1.0 SP08, la propiedad Actualización de datos maestros

ampliada ha estado disponible, pero solo para atributos o textos no
dependientes del tiempo.
● A partir de BW/4HANA 2.0 SP04, la propiedad Actualización de datos
maestros ampliada también está disponible para textos o atributos
dependientes de tiempo.
● No hay modificaciones en el tratamiento de jerarquías, ya que el concepto de
actualizaciones ampliadas solo cubre atributos y textos.

Ampliación de clave, relación y característica de referencia

Extensión de clave semántica
En el panel Relación, en la etiqueta General de una definición de característica, determine si
desea relacionar la característica con otros InfoObjetos. Esto significa que los InfoObjetos
relacionados formarán parte de la clave en todas las tablas de datos maestros de esta
característica.

© Copyright. Reservados todos los derechos. 295

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

Escenario: Separar valores de diferentes fuentes

Figura 211: Relación

La relación se utiliza para definir valores de característica de forma unívoca. Por ejemplo, si el
ID de almacén 200000 para el centro A y el mismo ID de almacén 200000 para el centro B
hacen referencia a diferentes ubicaciones físicas, solo puede distinguir la característica
almacén en relación con el centro. En este caso, la relación entre la característica almacén y
centro lo hace unívoco. También puede combinar varias características, como el ID de
sistema fuente y el centro. Existen dos InfoObjetos útiles de BI Content:
● El ID de sistema fuente (0SOURSYSTEM) es un identificador de dos dígitos para un
sistema fuente en SAP BW/4HANA.
● El sistema lógico (0LOGSYS) es una especificación de 10 caracteres de una conexión
lógica (sistema y mandante).

La forma más fácil de derivar el valor es añadir una constante directamente al cargar datos de
la fuente.
Una alternativa a la relación es la extensión de la clave para la característica mediante rutinas
o fórmulas, o definir un atributo de navegación como una nueva clave artificial. Estas
alternativas se han analizado en la unidad Estándares de mejores prácticas en el modelado
BW/4HANA.

296 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de datos maestros de SAP BW/4HANA

Uso de relación para dividir el rol de un interlocutor comercial

Figura 212: Relación para diferentes roles de interlocutor comercial

Aquí hay otro escenario para la relación: Imagine que su interlocutor comercial ocurre en
diferentes roles, como proveedor y cliente, y que la lista de atributos, como la persona de
contacto y la dirección, son la misma. Sin embargo, dependiendo del tipo de relación, puede
tener diferentes direcciones o personas de contacto para el mismo socio comercial. A
continuación, en lugar de modelar dos características diferentes, puede modelar solo una
relación funcional y separarla mediante la relación de un rol de InfoObjeto (0D_NW_ROLE
está relacionado con 0D_NW_BP). Puede modelar relaciones de proveedor y cliente para un
interlocutor comercial en el mismo InfoSitio con diferentes registros y añadir todos los
valores relativos a este interlocutor comercial. Como alternativa, puede mantener los
procesos de proveedor y cliente en InfoSitios separados y combinarlos con un join. Debido al
modelo de datos maestros, el mismo ID de socio comercial significa el mismo socio
comercial.
Como alternativa, puede modelar dos InfoObjetos separados. A continuación, es más flexible,
pero necesita crear y añadir más objetos.

© Copyright. Reservados todos los derechos. 297

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

Uso de características de referencia para dividir el rol de un socio comercial

Figura 213: Características de referencia para diferentes funciones de interlocutor comercial

Si la lista de todos los atributos y el contenido es la misma en ambos roles y obtiene

información de registro de transacción sobre ambos roles, el concepto de características de
referencia es mejor. Esto significa que existe un archivo para el InfoObjeto interlocutor
comercial y que los roles de interlocutor comercial (0SOLD_TO, 0PAYER) se leen de la lista
de datos maestros común. Normalmente no es un problema si la lista común (datos maestros
de interlocutor comercial) contiene más valores de los que realmente se necesitan. Para este
modelo, no se necesita ninguna relación.

Modificaciones en características de referencia

La siguiente tabla es un ejemplo de una característica de referencia U00_CHBY que hace
referencia a P_EMPL.

Tabla 1: Modificaciones en la característica de referencia U00_CHBY, que hace referencia a la

característica de referencia P_EMPL
Modificaciones en la característica de refe- ¿Posible?
rencia U00_CHBY

Modifique la descripción de U00_CHBY a U00 Sí

Empleado que ha modificado una po­
sición

Hacer relevante para autorización U00_CHBY Sí

Activar textos para U00_CHBY No
Hacer dependientes la versión de las jerar- No
quías
Eliminar un atributo No

298 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de datos maestros de SAP BW/4HANA

Modificaciones en la característica de refe- ¿Posible?

rencia U00_CHBY

Verificar el atributo 0D_NW_ORGU (que es Sí

un atributo de navegación de P_EMPL) como
Todos los atributos que se verifican como
atributo de navegación
atributos de navegación en la característica
referenciada (P_EMPL) no se verifican por
defecto como atributos de navegación en la
característica de referencia (U00_CHBY),
pero se pueden verificar opcionalmente co-
mo atributos de navegación en la caracterís-
tica de referencia (U00_CHBY).

Modifique el atributo 0D_NW_USER (que es No

un atributo de visualización de P_EMPL) a un
atributo de navegación
Desactivar atributo transitorio 0D_NW_CODE No
Activar atributo transitorio No

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Enumerar las tablas en el modelo de datos de SAP BW/4HANA
● Implementar datos maestros de SAP BW/4HANA

© Copyright. Reservados todos los derechos. 299

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

300 © Copyright. Reservados todos los derechos.

 Capítulo 8
Lección 2
Modelado de jerarquías de SAP BW/4HANA

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Modelado y uso de jerarquías de SAP BW/4HANA

Ventajas de las jerarquías

Definición
Las jerarquías proporcionan una forma estructurada de visualizar los datos en un análisis. En
una jerarquía, los valores de característica se organizan en grupos. Por ejemplo, los valores
para la característica Empleado se agrupan por regiones geográficas. Estas regiones se
agrupan por país. Los países se agrupan por continente. Estos grupos se utilizan para
acumular datos de transacción.
La figura, Ventajas de las jerarquías, muestra las ventajas generales de las jerarquías desde
una perspectiva de usuario empresarial que son independientes del tipo de jerarquía o del
método de implementación (SAP BW o SAP HANA).

Figura 214: Ventajas de las jerarquías

La figura, Ventajas de las jerarquías, muestra más ejemplos de una combinación estructurada
de diferentes valores de característica en niveles superiores:
● En una dimensión organizativa, combinar empleados en unidades organizativas de niveles
inferiores y superiores

© Copyright. Reservados todos los derechos. 301

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

● En una dimensión de tiempo, combinar días a meses a trimestres a años

● En una dimensión de ubicación, combinar ciudades con provincias con países
● En una dimensión de producto, combinar productos con categorías de productos y
categorías principales

Ventajas
Las jerarquías se utilizan para navegar todo el conjunto de miembros con más facilidad (la
ubicación de la empresa, los productos o los días, semanas, meses o años) al analizar los
datos.
Las principales ventajas de las jerarquías son los informes centrados:
● El informe muestra primero un nivel agregado y, a continuación, es posible un desglose de
los detalles.
● Se visualizan diferentes niveles en la misma columna.
● Solo se deben abrir los nodos interesantes. Solo se deben visualizar detalles interesantes.
● En la mayoría de las herramientas de gestión de informes, los filtros en nodos de jerarquía
son posibles.
● Se pueden implementar autorizaciones para jerarquías y nodos de jerarquía.

Otros efectos
● En el tiempo de diseño de un modelo, debe definir la secuencia de desglose de una
jerarquía. Esto ayuda a los usuarios a investigar los valores interesantes de un nivel
agregado al siguiente. Sin embargo, reduce la flexibilidad cuando las herramientas de
informes no permiten un salto del nivel 1 directamente al nivel 3, o utilizar una secuencia
totalmente diferente.

Jerarquías internas y externas

Las jerarquías se pueden utilizar para guiar el desglose a detalles, para filtrar datos y para
definir autorizaciones de análisis.

Terminología de jerarquía
Hay muchos términos que se utilizan cuando hablamos de jerarquías. Debemos ser muy
claros sobre las diferencias entre las jerarquías externas e internas.
● Jerarquía interna: una visualización jerárquica de las características existentes, por
ejemplo, en los informes. Esto también se conoce como tiempo de ejecución o jerarquía de
visualización. Se denominan internos porque los datos de transacción dentro del InfoSitio
se utilizan para realizar la agrupación. Además, también se pueden incluir atributos de
navegación.
● Jerarquía externa: datos principal-secundario almacenados en tablas de datos maestros
relacionadas con SAP BW/4HANA para una característica específica. Se denominan
externas porque están fuera de las tablas de datos de transacción.

Tanto las jerarquías internas como las externas siempre se definen en características y
atributos, no en ratios. No contienen fórmulas. La agregación estándar se aplica para los
ratios del query.
La jerarquía interna se define dentro de la consulta BW configurando la opción Jerarquía
universal de visualización en activa en las filas o columnas. Por ejemplo, si tiene país y cliente

302 © Copyright. Reservados todos los derechos.

 Lección: Modelado de jerarquías de SAP BW/4HANA

en las filas, puede activar la función de jerarquía interna que agrupará los clientes por país.
También puede activar Visualización compacta en filas, por ejemplo, en Analysis for Office.

Figura 215: Visualización jerárquica de características y atributos de navegación en líneas ("Jerarquía interna")

Jerarquías externas

© Copyright. Reservados todos los derechos. 303

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

Figura 216: Elementos de jerarquía (externos)

Cada jerarquía externa se basa en una característica básica específica. Se compone de una
serie de grupos (nodos) de los siguientes tipos:
Hojas
Los nodos sin nodos subordinados se denominan hojas. Contienen valores para la
característica básica de jerarquía, visualizan sus textos y pueden tener entradas en la tabla de
hechos.
Nodos contabilizables
Los nodos contabilizables son nodos que hacen referencia a la característica básica, pero
tienen nodos subordinados. Puede extraer datos de movimiento del destino de datos solo
para nodos contabilizables.
Nodos no contabilizables
Los nodos no contabilizables no hacen referencia a la característica básica. Pero otras
características específicas (Características externas) se pueden permitir como nodo de
característica en las opciones de jerarquía de la característica básica. (No es necesario que
sean atributos de la característica). Estos nodos obtienen su texto y valor de la característica
externa.
Un nodo Texto pertenece a una jerarquía específica sin relación con otra característica. Su
texto se define en la jerarquía.
El nodo superior (nodo raíz) de la jerarquía siempre es un nodo de texto. Para los nodos de
texto se utiliza la característica técnica 0HIER_NODE.

304 © Copyright. Reservados todos los derechos.

 Lección: Modelado de jerarquías de SAP BW/4HANA

Figura 217: Características externas en jerarquías

Niveles de jerarquía
El nivel de un nodo indica la distancia del nodo desde la raíz. La raíz de una jerarquía forma el
primer nivel, sus secundarios el segundo nivel, etc.
Intervalos
Los intervalos contienen un número de hojas que van juntas, descritas por sus límites
superior e inferior. Puede crearlos para un nodo que tenga más de una hoja. Al definir
intervalos, los nuevos valores de característica que se añaden a los datos maestros se
asignan automáticamente al intervalo si el valor de característica está incluido en la amplitud
de intervalo.

© Copyright. Reservados todos los derechos. 305

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

Modelado de jerarquías externas

Figura 218: Aspectos básicos de jerarquía (externa)

La definición de jerarquía de una jerarquía externa se almacena físicamente en la base de

datos SAP HANA. Las funciones clave de las jerarquías externas son las siguientes:

● Se pueden cargar desde flujos de datos de contenido de SAP BW predefinidos o la interfaz

de archivo plano.
● Se pueden definir manualmente como tablas de datos maestros de SAP BW/4HANA.
● Las asignaciones pueden cambiar con frecuencia. Toda la jerarquía o la estructura
jerárquica se puede modelar como dependiente del tiempo.
● No tienen un número fijo de niveles y pueden estar en una jerarquía desequilibrada.
● Para cada característica son posibles varias jerarquías.
● La estructura define la vía de desglose fija.
● Los valores no asignados se pueden visualizar en la gestión de informes.
● Los datos de consulta se pueden restringir a un nodo de jerarquía.

Las jerarquías externas proporcionan agrupaciones de rollup flexibles y fácilmente

modificadas para la generación de informes. Para utilizar estas jerarquías externas, debe
crearlas manualmente en SAP BW/4HANA o cargarlas.
Las funciones de la jerarquía ETL son las siguientes:
● Cualquier objeto de SAP BW se puede utilizar como fuente.

306 © Copyright. Reservados todos los derechos.

 Lección: Modelado de jerarquías de SAP BW/4HANA

● Está totalmente integrado en el flujo de datos de BW/4HANA con todos los tipos de regla y
con rutinas de inicio, fin y experto dentro de las transformaciones.
● Es posible una cantidad arbitraria de InfoFuentes entre la fuente y el destino.
● Los datos pueden cargarse desde una fuente de datos y distribuirse a varias tablas de
jerarquía.
● Las jerarquías se cargan en proceso de fondo o en diálogo mediante un DTP. Las opciones
son una actualización completa, la inserción de un subárbol o la actualización de un
subárbol.
● ChildID, NextID y nivel son suministrados automáticamente por el nuevo framework (si la
fuente no los rellena).
● El nombre de jerarquía es un campo clave de la tabla de jerarquía. Se pueden leer varias
jerarquías a la vez en un destino de jerarquía.

Tablas de jerarquía
La tabla de jerarquía (tabla H) se utiliza para almacenar las relaciones jerárquicas entre
valores de característica si se utilizan jerarquías externas para la característica. Sólo se
genera una tabla H, incluso si una característica contiene varias jerarquías. En otras palabras,
la tabla H contiene todas las jerarquías.
Si toda la jerarquía depende del tiempo, los campos DATETO y DATEFROM no aparecen en la
tabla H. En su lugar, aparecen como campos globales (metainformación) en la tabla
RSHIEDIR. Esto también es válido para el campo VERSIÓN en jerarquías dependientes de
versión. Si la estructura jerárquica es dependiente del tiempo, los dos campos de fecha
aparecen en la tabla H.

Almacenamiento de jerarquía externa

Figura 219: Jerarquía externa para característica 0COUNTRY

© Copyright. Reservados todos los derechos. 307

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

La figura, Jerarquía externa para la característica 0COUNTRY, muestra el contenido de la

tabla H después de que se haya cargado una jerarquía en SAP BW para la característica
0COUNTRY, o después de que se haya creado y activado una jerarquía (versión de
visualización simplificada) en SAP BW/4HANA. El segundo nivel de la jerarquía de ejemplo le
ayuda a comprender mejor la estructura de la tabla. En el campo NODEID puede ver que
EUROPA es el segundo nodo de esta jerarquía.
El campo PARENTID muestra que el nodo superior tiene NODEID 1. En este ejemplo, el nodo
de nivel superior es el nodo raíz RAWO. El campo CHILDID denota el nodo de nivel inferior y el
campo NEXTID el nodo adyacente (siguiente). En este ejemplo, el nodo de nivel inferior es
Austria y el nodo adyacente es USA. Si se permiten intervalos en esta jerarquía, un indicador
en el campo INTERVL indica que este nodo representa un intervalo. Una tabla adicional /BIC/
JCOUNTRY enumera los valores de las claves FROM y TO para cada nodo de intervalo.
Si ha marcado la casilla de selección Con jerarquías en las pantallas de actualización para
características, las tablas de ID sustituto (SID) siempre se generan además de la tabla H.
Tabla SID de nodos
En la tabla de ID de datos maestros de nodos se asignan valores de ID de datos maestros
negativos a los nodos. La figura Estructura de tabla I y K muestra una tabla K para una
característica con una jerarquía independiente del tiempo.
Tabla de inclusión
Esta tabla contiene esencialmente la misma información que la tabla H porque muestra las
relaciones entre nodo a nodo y nodo a hoja. A las hojas (valores de característica) se les
asignan valores de ID de datos maestros positivos y a los nodos se les asignan valores de ID
de datos maestros negativos (tabla K).

Tablas I y K
La figura, Tablas I y K con datos, muestra las tablas I y K después de que se haya cargado una
jerarquía en SAP BW/4HANA para la característica COUNTRY, o después de que se haya
creado y activado una jerarquía para esta característica (visualización simplificada).

Figura 220: Tablas I y K con datos

308 © Copyright. Reservados todos los derechos.

 Lección: Modelado de jerarquías de SAP BW/4HANA

Tabla 2: Leyenda
La siguiente tabla describe toda la estructura de tabla I y K:
Campo Descripción

SID SID para el nodo dentro de la jerarquía

IDSO SID para el nodo como valor original
LINKNO Número de enlace
SVER Versión en la clave de la tabla de inclusión
ANTERIOR ID de datos maestros (predecesor)
SUCC ID de datos maestros (sucesor)
NÚMERO DE LISTA Secuencia de las relaciones de inclusión
FACTOR Factor que la relación de inclusión se incluye
en el nodo con
NTYPEID ID interno para tipos de nodo

Jerarquía dependiente de tiempo o estructura de jerarquía, Fecha clave de

consulta y Fecha de jerarquía
Si toda la jerarquía es válida para un período de tiempo específico y, a continuación, se lleva a
cabo una reorganización completa, cree toda la jerarquía como dependiente del tiempo.
Si las modificaciones solo afectan a unas pocas relaciones subordinadas, utilice una jerarquía
con una estructura dependiente del tiempo. A continuación, los nodos u hojas de jerarquía
pueden aparecer varias veces bajo diferentes nodos superiores. Normalmente, se fija el
tiempo de validez de los enlaces de modo que los intervalos de tiempo de todos los nodos
duplicados con la misma clave técnica no se solapen.

Figura 221: Estructura jerárquica dependiente del tiempo con nodos duplicados y nodos de enlace

© Copyright. Reservados todos los derechos. 309

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

La evaluación de una jerarquía dependiente del tiempo o de una estructura de jerarquía

dependiente del tiempo depende de las opciones de jerarquía y de la configuración de la
consulta:
● Puede fijar una fecha clave de consulta. Si mantiene la parametrización estándar Fecha
clave de la consulta (<valor por defecto>) al activar la visualización de jerarquía externa en
el query BW, la jerarquía se visualizará en la especificación que se ajuste a la fecha clave
del query.
● De forma alternativa, se puede introducir una Fecha de jerarquía en las propiedades de
jerarquía. Esto determinará la especificación de la jerarquía que se utilizará en la gestión
de informes independientemente de la fecha clave de la consulta.
● Si no se fija explícitamente ninguna fecha clave de consulta ni ninguna fecha de jerarquía,
como para los atributos dependientes del tiempo, la fecha del sistema se utiliza en el
tiempo de ejecución.

Figura 222: Estructura jerárquica dependiente del tiempo y fecha de jerarquía en la consulta

310 © Copyright. Reservados todos los derechos.

 Lección: Modelado de jerarquías de SAP BW/4HANA

Figura 223: Estructura jerárquica dependiente del tiempo, nodos de enlace y fecha de jerarquía en la consulta

En lugar de separar el tiempo de validez en la definición de jerarquía, puede definir nodos

duplicados como Nodos de enlace.
A continuación, el nombre, el InfoObjeto y, si es necesario, los campos Fecha de inicio y Fecha
de fin de los nodos son idénticos. Sin embargo, el nodo de enlace sólo es un enlace al nodo
original. No se puede modificar de forma independiente. Los nodos de enlace no pueden tener
nodos subordinados propios. Toman los nodos de nivel inferior del nodo original. Estos nodos
subordinados no se visualizan en la actualización de jerarquía.
Si un nodo de nivel superior es un ascendiente común del nodo de enlace y su nodo original
referenciado, un valor de ratio se añade solo una vez, no dos veces a la agregación.

Estructura de jerarquía dependiente de tiempo y enlace de jerarquía temporal

Para evaluar históricamente una jerarquía con una estructura jerárquica dependiente del
tiempo, para una fecha clave que debe derivarse de los datos evaluados, seleccione la opción
Combinación de jerarquía temporal y especifique el tipo de derivación para la fecha clave.

© Copyright. Reservados todos los derechos. 311

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

Figura 224: Join de jerarquía temporal y clase de derivación de fecha clave

En la figura, Join de jerarquía temporal y clase de derivación de fecha clave, puede ver la
parametrización temporal para la característica P_EMPL. Para realizar un enlace temporal, se
necesita una consulta. El tipo de derivación de fecha clave que se utiliza para determinar la
fecha clave para el join se puede crear en SAP HANA Studio mediante
Fichero → Nuevo → Otro → tipo de derivación de fecha clave o en SAP GUI mediante el código
de transacción RSTHJTMAINT.

312 © Copyright. Reservados todos los derechos.

 Lección: Modelado de jerarquías de SAP BW/4HANA

Parametrizaciones de jerarquía para combinaciones de jerarquía temporales en Query

Designer

Figura 225: Estructura de jerarquía dependiente de tiempo y enlace de jerarquía temporal en la consulta

Nota:
La forma en que se determina la clase de derivación de fecha clave influye en el
rendimiento. La cantidad de joins que debe realizar el procesador de Online
Application Processing (OLAP) se corresponde con el grado de detalle en el que
se encuentra la característica de tiempo en la definición de la clase de derivación
de fecha clave y el nivel de hoja. Por ejemplo, una jerarquía pequeña tiene 100
hojas. Para un período de 12 meses, el procesador OLAP debe crear 1.200 joins a
nivel de mes. A nivel de día, tiene que hacer 36.500 uniones.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Modelado y uso de jerarquías de SAP BW/4HANA

© Copyright. Reservados todos los derechos. 313

Capítulo 8 : Implementación de modelos de datos maestros de InfoObjeto de SAP BW/4HANA

314 © Copyright. Reservados todos los derechos.

 Capítulo 8

Evaluación de la formación

1. En el modelo de datos de SAP BW/4HANA, los datos maestros se almacenan por

separado en tablas de atributos, texto y jerarquías que están vinculadas entre sí mediante
el ID sustituto (SID).
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

2. Los atributos dependientes e independientes del tiempo se almacenan en la misma tabla

X que utiliza De fecha y A fecha como campos clave.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

3. Cuando crea un InfoObjeto en SAP BW, puede introducir un modelo o un objeto de

referencia. ¿Cuál es la diferencia entre ambos?

4. ¿Cuáles de las siguientes afirmaciones sobre jerarquías internas y externas son

verdaderas?
Seleccione las respuestas correctas.

X A Las jerarquías internas no tienen vínculo con las tablas de datos maestros

X B Las jerarquías internas se utilizan para visualizar características sin utilizar una
jerarquía externa

X C Las jerarquías externas se definen en Business Explorer Query Designer en la ficha

Jerarquía

X D Las jerarquías externas se definen como "externas" porque los datos se almacenan
fuera de BW en el servidor OLAP

X E Las jerarquías externas se almacenan en tablas de datos maestros BW

© Copyright. Reservados todos los derechos. 315

 Capítulo 8

Respuestas a la Evaluación de la formación

1. En el modelo de datos de SAP BW/4HANA, los datos maestros se almacenan por

separado en tablas de atributos, texto y jerarquías que están vinculadas entre sí mediante
el ID sustituto (SID).
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! El enlace entre las diferentes tablas de datos maestros es el ID sustituto.
Leer más en el módulo Modelado e implementación de datos maestros de SAP BW/
4HANA, en el curso BW430.

2. Los atributos dependientes e independientes del tiempo se almacenan en la misma tabla

X que utiliza De fecha y A fecha como campos clave.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! Los atributos dependientes del tiempo se almacenan en la tabla Y que utiliza
el campo Fecha de fin (no Fecha de inicio) en la clave. Los atributos independientes del
tiempo se almacenan en la tabla X sin fechas en la clave de tabla. Leer más en el módulo
Modelado e implementación de datos maestros de SAP BW/4HANA, en el curso BW430.

3. Cuando crea un InfoObjeto en SAP BW, puede introducir un modelo o un objeto de

referencia. ¿Cuál es la diferencia entre ambos?

Si selecciona un InfoObjeto de referencia, no podrá modificar las opciones técnicas y el

nuevo InfoObjeto utilizará las mismas tablas de metadatos que el objeto referenciado. Las
modificaciones posteriores en el InfoObjeto referenciado tendrán efecto en la
característica de referencia. Si selecciona un modelo, puede modificar las opciones
técnicas y crear sus propias tablas de metadatos. Las modificaciones posteriores en el
InfoObjeto referenciado no tendrán efecto en la característica de referencia.

316 © Copyright. Reservados todos los derechos.

 Capítulo 8 : Respuestas a la Evaluación de la formación

4. ¿Cuáles de las siguientes afirmaciones sobre jerarquías internas y externas son

verdaderas?
Seleccione las respuestas correctas.

X A Las jerarquías internas no tienen vínculo con las tablas de datos maestros

X B Las jerarquías internas se utilizan para visualizar características sin utilizar una
jerarquía externa

X C Las jerarquías externas se definen en Business Explorer Query Designer en la ficha

Jerarquía

X D Las jerarquías externas se definen como "externas" porque los datos se almacenan
fuera de BW en el servidor OLAP

X E Las jerarquías externas se almacenan en tablas de datos maestros BW

¡Ha acertado! Las jerarquías internas no tienen enlace a los datos maestros porque se
crean "sobre la marcha" cuando el resultado de la consulta se presenta al usuario. Las
jerarquías externas se almacenan en tablas de datos maestros BW. Las jerarquías
externas no están definidas en el Query Designer, sino que se almacenan en las tablas de
jerarquía BW. Las jerarquías externas son externas a la ejecución de la consulta y no están
almacenadas en el servidor OLAP. Leer más en el módulo Modelado e implementación de
datos maestros de SAP BW/4HANA, en el curso BW430.

© Copyright. Reservados todos los derechos. 317

Capítulo 8 : Respuestas a la Evaluación de la formación

318 © Copyright. Reservados todos los derechos.

CAPÍTULO 9 Implementación de modelos de
datos transaccionales de SAP
BW/4HANA

Lección 1
Modelado e implementación de objetos DataStore avanzados (ADSO) 321

Lección 2
Modelado e implementación de InfoFuentes y conversiones en transformaciones 345

Lección 3
Modelado e implementación de CompositeProviders 359

OBJETIVOS DEL CAPÍTULO

● Modelar e implementar objetos DataStore avanzados (ADSO)

● Modelar e implementar InfoFuentes
● Decidir cómo derivar ratios
● Convertir monedas
● Convertir unidades de medida
● Modelar e implementar CompositeProviders

© Copyright. Reservados todos los derechos. 319

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

320 © Copyright. Reservados todos los derechos.

 Capítulo 9
Lección 1
Modelado e implementación de objetos
DataStore avanzados (ADSO)

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Modelar e implementar objetos DataStore avanzados (ADSO)

Modelos de objeto de almacén de datos avanzado

El objeto DataStore avanzado (aDSO) es el objeto SAP BW/4HANA para el almacenamiento
persistente de datos.
En función del tipo, puede definir campos clave y los campos dependientes se pueden
sobrescribir o agregar.
El objeto DataStore avanzado (aDSO) proporciona un InfoSitio para muchos escenarios de
modelado diferentes, o para muchas capas EDW diferentes, tanto para el modelado basado
en campos como el basado en InfoObjetos en un entorno basado en Eclipse fácil de usar.

Figura 226: Características clave de los objetos DataStore avanzados

El objeto DataStore avanzado consta de tres tablas principales que se generan en proceso de
fondo cuando se crea y activa el objeto DataStore avanzado. El sistema utiliza las tablas en
función de las opciones de modelado seleccionadas. Independientemente del caso de uso,
estas tres tablas siempre se generan para admitir modificaciones rápidas y flexibles en el
modelo de datos. Las tablas son las siguientes:

© Copyright. Reservados todos los derechos. 321

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Figura 227: Estructura de objetos DataStore avanzados

● Tabla de entrada: Nombre técnico /BIC/A<nombre técnico>1

Es igual a la tabla de cola de activación para el DSO estándar (clásico) o la tabla de hechos
no comprimida del InfoCubo optimizado para HANA en el pasado
Estructura: ID de solicitud (REQTSN), paquete de datos (DATAPAKID), número de registro
(RECORD), modo de registro (RECORDMODE), campo clave 1, campo clave n, campo 1,
campo n...
● Tabla de datos activos: /BIC/A<nombre técnico>2
Es igual a la tabla activa de DSO (clásica) o la tabla de hechos comprimida del InfoCubo no
optimizado para HANA en el pasado
Estructura: Campo clave 1, Campo clave n, Modo de registro (RECORDMODE), Campo 1,
Campo n...
● Tabla de log de modificaciones: /BIC/A<nombre técnico>3
Igual que para DSO estándar (clásico) en el pasado
Estructura: ID de solicitud (REQTSN), paquete de datos (DATAPAKID), número de registro
(RECORD), modo de registro (RECORDMODE), campo clave 1, campo clave n, campo 1,
campo n...

Independientemente de la instancia del objeto DataStore avanzado que modele, los datos
siempre se cargan primero en la tabla de entrada (excepto para los aDSO "Actualización
directa"). A continuación, los datos se leen directamente de esta tabla o se siguen
procesando en las otras dos tablas para su lectura o extracción. Esto depende de cómo se
utilizan los datos y cómo se personaliza el modelo.
Además de estas tres tablas principales, también se crean las tres vistas de tabla siguientes.
Cuál de las tres tablas principales a las que hacen referencia depende del escenario de
modelado (es decir, la opción de las propiedades de Modelado):
● Vista para extracción desde el objeto DataStore avanzado: /BIC/A<nombre técnico>6
● Vista para reporting para objeto DataStore avanzado: /BIC/A<nombre técnico>7

322 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de objetos DataStore avanzados (ADSO)

● Vista para acceso SQL externo para objeto DataStore avanzado: /BIC/A<nombre
técnico>8

Vista SQL externa

Aunque es una práctica habitual, SAP no admite el acceso directo a las tres tablas que
almacenan datos aDSO (consulte la nota SAP 1682131). Por este motivo, SAP BW/4HANA 2.0
proporciona una nueva vista de base de datos para el acceso SQL externo. Está pensado para
ser una interfaz estable que permite el acceso oficial y autorizado a los datos aDSO. Es una
API técnica de bajo nivel diseñada principalmente para llamarse en escenarios de staging, por
ejemplo, para realizar búsquedas en rutinas con ABAP o AMDP/SQLScript en
transformaciones. También conocida como la vista SQL de SAP HANA externa, no
proporciona funciones como autorizaciones de análisis y combinaciones de texto, que
proporciona la vista externa de SAP HANA (cálculo) (consulte la unidad 5).
La vista SQL SAP HANA externa se genera automáticamente durante la activación de un
aDSO. Se crea en el Dictionary ABAP y, por lo tanto, también en el catálogo de base de datos
para su uso con Native SQL y OpenSQL/ABAP. Para los objetos DataStore avanzados que se
activaron antes de la introducción de la función de vista SQL de SAP HANA externa en la
versión 2.0, puede crear las vistas que faltan con el report RSDG_ADSO_ACTIVATE. El botón
Reparar con Reestructurar vistas de base de datos seleccionadas solo crea la(s) vista(s) en el
catálogo de base de datos, pero no en el Dictionary ABAP. Para crear la(s) vista(s) también en
el Dictionary ABAP, debe activar el objeto DataStore (avanzado) manualmente utilizando las
herramientas de modelado BW o el informe mencionado anteriormente. La activación no
debe realizarse directamente en el Dictionary ABAP.

Nota:
No está previsto proporcionar esta vista SQL para objetos que no sean aDSO en
SAP BW/4HANA.

Propiedades de modelado central

Figura 228: Las propiedades de modelado principales de los objetos DataStore avanzados en SAP BW/4HANA

Las propiedades de modelado principales, ubicadas en la pestaña General de la GUI de

herramientas de modelado de SAP BW/4HANA, representan las opciones clave que definen

© Copyright. Reservados todos los derechos. 323

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

el comportamiento del objeto DataStore avanzado y el uso de sus tres tablas back end.
También hay algunas mejoras adicionales llamadas "propiedades especiales" en relación con
los ratios de inventario, las funciones de planificación y una nueva interfaz de escritura, que
están disponibles en función del escenario de modelado central que haya definido antes.
1. Objeto DataStore estándar

Figura 229: Objeto DataStore avanzado de tipo "Estándar" incluido un log de modificaciones

Figura 230: Objeto DataStore avanzado de tipo "Estándar" excluyendo un log de modificaciones

El objeto DataStore estándar es adecuado para la mayoría de casos de aplicación y para

reporting. Puede seleccionar las siguientes propiedades:
● Escribir log de modificaciones: si selecciona esta opción, el delta (registros nuevos,
borrados y modificados) se guarda en el log de modificaciones. El log de modificaciones se

324 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de objetos DataStore avanzados (ADSO)

utiliza para extraer el delta. Las solicitudes solo se pueden restaurar desde el objeto
DataStore si el objeto DataStore tiene un log de modificaciones; es decir, el estado antes
de que se pueda restaurar la activación de la solicitud. En comparación con el pasado
(DSO clásico estándar), es una nueva opción no utilizar un log de modificaciones. Esto
puede grabar recursos si no necesita ninguna extracción delta de este objeto fuente.
● Soporte de instantánea: si su fuente de datos solo entrega el conjunto de datos actual
como COMPLETO fijando este indicador, los registros de datos borrados se pueden
identificar y actualizar. Durante la activación, el sistema reconoce los registros que están
en la tabla de datos activos, pero no en la solicitud de carga. Estos se escriben en el log de
modificaciones como imágenes inversas.
● Registros de datos únicos: si solo carga registros de datos únicos (registros de datos con
combinaciones de claves no periódicas) en el objeto DataStore, puede seleccionar esta
propiedad. Si el indicador está fijado, el sistema verifica durante la activación si existen
registros unívocos. Si ya existe un registro, la activación se cancela con un error.

2. Objeto DataStore de staging

Figura 231: Objeto DataStore avanzado del tipo "Staging"

© Copyright. Reservados todos los derechos. 325

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Figura 232: Objeto DataStore avanzado del tipo "Staging" con compresión

Figura 233: Objeto DataStore avanzado del tipo "Staging" con capacidades de reporting

El objeto DataStore de staging se puede utilizar en tres casos de utilización diferentes

seleccionando sus propiedades. Estos escenarios son los siguientes:
● Solo cola de entrada: No se graban datos en el log de modificaciones. El proceso de
extracción siempre lee de nuevo los datos en la tabla de entrada, para la extracción delta o
la extracción completa. Este objeto no es adecuado para reporting y análisis.
● Comprimir datos: En general, los datos siempre se escriben en la tabla de entrada. Si
selecciona Comprimir datos, los datos se escribirán en la tabla para datos activos (durante
el proceso de compresión). Durante la activación, los datos se agregan de acuerdo con la
clave semántica y se escriben en la tabla Datos activos. Para ahorrar espacio de memoria,
el log de modificaciones no se rellena. Por lo tanto, no puede realizar el borrado de datos
basado en solicitudes del objeto DataStore. Solo puede borrar datos de forma selectiva.

326 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de objetos DataStore avanzados (ADSO)

● Habilitado para reporting: Los datos se escriben en la tabla Datos activos, pero también se
conservan en la tabla de entrada. Dado que los datos se almacenan de forma redundante
en la tabla de entrada, los datos pueden borrarse de la tabla activa y reestructurarse a
partir de la tabla de entrada. Los datos solo se extraen de la tabla de entrada. Cuando se
ejecuta una consulta, se accede a la tabla activa:

3. Objeto DataStore de data mart

Figura 234: Objeto DataStore avanzado de tipo "Data Mart"

El objeto DataStore data mart está optimizado para reporting y análisis (similar a InfoCubos
del pasado) y tiene las siguientes características:
● Campos clave: no se puede especificar ninguna clave para este tipo de objeto DataStore,
pero los registros se tratan como si todas las características estuvieran en la clave (clave
lógica).
● Carga: Los datos siempre se cargan en la tabla de entrada.
● Activación: Cuando activa los datos, estos se copian en la tabla de datos activos y se
agrupan según el comportamiento de agregación. A continuación, los datos se borran de la
tabla de entrada. El log de modificaciones no se rellena. La activación se compara con una
compresión de InfoCubos conocida del pasado.
● Rollback: para este tipo, las solicitudes solo se pueden borrar si la solicitud aún no se ha
activado.
● Extracción: La extracción completa e inicial lee los datos para la actualización en otro
destino de datos como una unión de la tabla de entrada y la tabla de datos activos.
Los datos para la extracción delta solo se leen de la tabla de entrada.
● Informes: la consulta lee los datos como una unión de la tabla de entrada y de la tabla de
datos activos. Por lo tanto, no es necesario activar los datos para poder ver todos los
datos. Los datos leídos son consistentes, ya que los datos sólo se incluyen hasta la
primera solicitud inconsistente. Los datos leídos también son estables, ya que la cantidad

© Copyright. Reservados todos los derechos. 327

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

de datos incluidos del objeto DataStore no cambia durante los pasos de navegación en el
query.

4. Actualización directa de objeto DataStore

Figura 235: Objeto DataStore avanzado de tipo "Actualización directa"

En el objeto DataStore para actualización directa, puede cargar datos directamente en la

tabla de datos activos, incluidas las verificaciones de consistencia estándar (por ejemplo,
procesamiento SID, consistencia de características de tiempo, áreas bloqueadas por
almacenamiento en frío o NLS).
Los datos se pueden cargar mediante DTP/Transformación estándar o mediante las API
siguientes:
● RSDSO_DU_WRITE_API / RSDSO_DU_WRITE_API_RFC: Carga datos de una tabla interna
a la tabla de datos activos.
● RSDSO_DU_DELETE_API_RFC: Borra datos de la tabla de datos activos. Este se puede
truncar o eliminar de forma selectiva.
● RSDSO_DU_CLEANUP_API_RFC: Borra solicitudes API con errores. Las solicitudes rojas
bloquean otras solicitudes de carga por DTP/Transformación o por API.

5. Objeto DataStore con interfaz de escritura

328 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de objetos DataStore avanzados (ADSO)

Figura 236: Objeto DataStore de tipo "Estándar" con interfaz de escritura

Figura 237: Objeto DataStore de tipo "Staging" con interfase de escritura

Los datos de este objeto DataStore se pueden mover a la tabla de entrada mediante las
soluciones de integración de SAP mediante PUSH. Basado en esta propiedad, es el sucesor
para los tipos de sistema fuente BW obsoletos SAP Data Services y Servicio Web. La interfaz
se puede integrar con las siguientes soluciones SAP:
● SAP Data Services local (requiere 4.2 SP11 revisión 4)
● Integración de SAP Cloud Platform (CPI)
● SAP NetWeaver Process Integration (PI) (previsto para SAP NetWeaver 7.50 SP15)
● SAP Data Hub (previsto para finales de 2019)

© Copyright. Reservados todos los derechos. 329

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

● SAP CPI-Data Services (previsto para finales de 2019)

La propiedad ADSO Interfaz de escritura se puede utilizar para todos los tipos de objetos
DataStore estándar y objetos DataStore de staging, pero no junto con el inventario activado o
la planificación habilitada. Puede utilizar los datos RFC o HTTP para enviar los datos al aDSO
en dos procedimientos posibles:
● Enviar datos sin una solicitud: se abre una nueva solicitud para cada llamada interna
● Enviar datos con una solicitud: Para ello se utiliza la siguiente secuencia: Solicitud abierta,
n veces Enviar datos (con solicitud y paquete), Cerrar solicitud.

Se aplican las siguientes propiedades:

● Los datos se transfieren en formato interno.
● Solo se pueden cargar los deltas after-image.
● Los módulos de funciones RFC se encuentran en el grupo de funciones de RSO_PUSH.
● Puede encontrar las URL específicas de cada objeto DataStore avanzado para llamar las
funciones mediante HTTP (JSON o XML) en las herramientas de modelado BW, en
Propiedades –> URL de plantilla.
● Después de escribir los datos en la tabla de entrada aDSO, el procesamiento posterior,
como la compresión/activación o el reporting, no se modifica.

Partición física y lógica

Figura 238: Partición

Si lee objetos DataStore realmente grandes (avanzados), incluso con SAP HANA, el
rendimiento puede convertirse en un problema. A continuación, tenga en cuenta los modelos
de datos particionados semánticamente. Esto ofrece las siguientes ventajas cuando se
compara con un único DSO avanzado:
● Mejor rendimiento con datos en masa: la partición semántica significa que los conjuntos
de datos se distribuyen entre varios contenedores de datos. Los tiempos de ejecución se
mantienen cortos durante la carga de datos y la generación de informes, incluso si el
volumen de datos es grande.

330 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de objetos DataStore avanzados (ADSO)

Especialmente, si un informe contiene un filtro para el campo de partición, solo debe

leerse una partición. Esto reduce enormemente el consumo de recursos, lo que
normalmente reduce el tiempo de ejecución.
● Trabajar con diferentes husos horarios: En muchas organizaciones, los escenarios de
almacenamiento de datos cruzan varios husos horarios. Con un modelo de datos
particionado semánticamente, los husos horarios o las regiones correspondientes se
pueden separar mediante las particiones. Por lo tanto, se pueden programar tareas
administrativas y de carga de datos para utilizar ventanas de baja actividad en cada región
o zona horaria.
● Aislamiento de los datos: Mejor tratamiento de errores. Si una solicitud para una región
finaliza con un error, sin partición, todo el InfoSitio no estará disponible para el análisis y el
reporting. Con un modelo de datos particionado semánticamente, la separación de las
regiones en diferentes particiones significa que solo la región que causó el error no está
disponible para el análisis de datos.

Hay dos opciones. En primer lugar, considere la partición semántica física (también conocida
como partición de base de datos). Esto significa que crea un aDSO individual con una
propiedad de partición. A continuación, la administración es más fácil y se utiliza la misma
estructura para todas las particiones.
Si diferentes particiones deben tener una estructura diferente, estarán disponibles los grupos
semánticos. A diferencia de su objeto predecesor, los objetos particionados semánticamente
(SPO) del pasado, el grupo semántico no es un InfoSitio en sí mismo. Es una herramienta
utilizada para generar un grupo a partir de los objetos DataStore avanzados relacionados
semánticamente. Siempre puede generar componentes nuevos en un grupo semántico. A
continuación, la estructura se toma de un modelo de objeto DataStore avanzado. Si se
cumplen determinadas condiciones, también se pueden añadir al grupo objetos DataStore
con una estructura diferente. Los aDSO siguen siendo objetos por derecho propio. Se puede
generar un CompositeProvider para simplificar el reporting y el análisis global de
componentes de un grupo semántico.
Ambas opciones se pueden combinar, por ejemplo, puede utilizar grupos semánticos para
años y particiones físicas para meses. Veamos los detalles.
Particiones físicas o particiones hash

© Copyright. Reservados todos los derechos. 331

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Figura 239: Partición aDSO física: Automática y manual

Puede utilizar la partición para dividir todo el conjunto de datos de un objeto DataStore en
varias unidades más pequeñas que son independientes y libres de redundancia. La partición
puede mejorar el rendimiento del sistema durante el análisis de datos. No es necesario crear
DTP diferentes para rellenar estas particiones. Un DTP es suficiente. Cada registro se
almacena automáticamente en su partición correcta.
La partición también puede ser necesaria si está gestionando un gran volumen de datos en
ADSO, porque una tabla SAP HANA o una partición de tabla SAP HANA puede contener un
máximo de dos mil millones de registros (exactamente 2^31 = 2.147.384.648 registros). La
partición también puede ser necesaria si utiliza Data Tiering Optimization (DTO).

1. La partición de nivel primario hace referencia a todas las tablas aDSO y está disponible en
la generación del aDSO. Esto significa que cada modelo de datos tiene una partición hash
de forma predeterminada. El objetivo principal es distribuir los datos a varios nodos
escalados en la base de datos de SAP HANA. Las reglas básicas para este tipo de partición
se definen según las recomendaciones de SAP proporcionadas en la nota SAP 2334091 y
sus anexos. Proporcionan la entrada para la tabla Customizing llamada
TABLE_PLACEMENT en SAP HANA. Basándose en estas reglas, una ejecución de
redistribución de infraestructura dentro de SAP HANA partirá las tablas aDSO en
consecuencia.

2. La partición automática de nivel secundario hace referencia a una partición de rango de

TSN de solicitud BW/4HANA en las tablas de entrada y los logs de modificación de los
ADSOs. Requisito previo: Personalización adecuada como se describe en la nota SAP
2081135.

3. La partición manual de nivel secundario hace referencia a una partición de rango que se
puede definir para la tabla aDSO de datos activos. En la IU de modelado de ADSOs
(etiqueta Opciones), los desarrolladores pueden seleccionar uno de los InfoObjetos (o
campos) clave para que sea el criterio de partición. Después, los rangos manuales deben
configurarse como parte de los metadatos. Las modificaciones de las particiones deben
transportarse como modificaciones de metadatos en la infraestructura de sistemas. Los
objetos de criterios de partición típicos son características de tiempo (por ejemplo,
0CALYEAR y todos los InfoObjetos relacionados con su jerarquía de tiempo) o campos

332 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de objetos DataStore avanzados (ADSO)

que describen unidades organizativas (como 0COUNTRY). Tenga en cuenta que en este
concepto solo la tabla de datos activos está dentro del alcance. Esto significa, por
ejemplo, que los datos en un aDSO de tipo "Data Mart" no se particionarán hasta que los
active (comprima).

Además de esta definición estática de valores de partición explícitos, también puede

realizar lo mismo de forma dinámica. En el caso de esta partición dinámica, especifique
solo el campo de partición, pero no el valor explícito. Las particiones se crean de forma
dinámica durante la activación de los datos. Por lo tanto, la partición dinámica es más
flexible que la partición estática.

Dado que se crea una partición nueva para cada valor nuevo del campo de partición
cuando se activan los datos, puede que se cree una gran cantidad de particiones, lo que
tiene un efecto negativo en el rendimiento. Como regla general, el número de particiones
en la tabla activa aDSO no debe aumentar más de 50 (particiones HASH x particiones
RANGE). Por lo tanto, la partición dinámica solo es adecuada para características con
cardinalidad baja. Puede reducir el número de particiones dinámicas aprovechando una
característica de tiempo de SAP (0CAL*, 0FISC*) como campo de partición, o una
característica derivada o un campo con el tipo de datos DATS como campo de partición.
Puede definir una granularidad de partición para estos campos, por ejemplo, año natural
(0CALYEAR) para el campo de partición mes natural (0CALMONTH). En este ejemplo,
todos los valores que pertenecen a un año natural se agrupan en una partición de rango y
se crean menos particiones de las que se habrían creado sin granularidad.

Figura 240: Recomendaciones para configurar particiones aDSO

© Copyright. Reservados todos los derechos. 333

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Nota:
SAP recomienda evaluar otros conceptos también para controlar el crecimiento
de los datos. En lugar de particionar físicamente tablas aDSO en el nivel de base
de datos, existen opciones para partir semánticamente los datos en diferentes
ADSOs (también conocido como Grupo semántico, véase más abajo) o puede
utilizar Data Tiering Optimization para almacenar datos históricos o menos
utilizados en otras ubicaciones (véase la unidad 7). Consulte también la nota SAP
2374652 (Gestión de grandes volúmenes de datos con objetos DataStore
avanzados en BW/4HANA).

Índices
● Puede crear índices secundarios para aDSOs si es necesario (por ejemplo, para una
búsqueda muy compleja). Se crea un índice en la tabla activa o, si no se encuentra ninguna
tabla activa, el índice se crea en la tabla de entrada.
● Por defecto, se crea un índice para las características de relación. Esto suele ser útil. A
partir de BW/4HANA 2.0, SP 04, puede desactivar la creación de este tipo de índices si es
más importante mantener el consumo de memoria bajo. Si no está seguro, verifique
ambas versiones y determine hasta qué punto el rendimiento puede verse afectado
negativamente.
● A partir de BW/4HANA 2.0, SP 04, puede seleccionar la opción de un índice de clave
primaria (invertido) optimizado para memoria. La necesidad de actualizar este índice
ralentiza el proceso de activación de datos.

Nota:
La partición y los índices son parametrizaciones expertas y sólo deberían
utilizarse si el rendimiento resulta ser un problema. En la mayoría de los casos, la
parametrización estándar es suficiente.

Grupos semánticos

334 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de objetos DataStore avanzados (ADSO)

Figura 241: Grupo semántico

Ahora, veamos los aspectos clave de los grupos semánticos:

Puesta a disposición de datos
Al cargar datos en un objeto DataStore avanzado que forma parte de un grupo semántico, un
filtro en el DTP requiere que solo se extraigan los datos adecuados para el objeto DataStore
como parte del grupo semántico. El DTP recibe el status “verde”, incluso si se han filtrado
registros. Los criterios de partición también se aplican en la transformación. Esto evita que
los datos se contabilicen en el objeto DataStore avanzado que no coincide con los criterios de
partición.

Informes
Cuando crea el grupo semántico, puede generar un CompositeProvider que contenga todos
los objetos DataStore avanzados en el grupo semántico. También los asigna el uno al otro por
la unión. Esto le proporciona el objeto para la gestión de informes y el análisis. Este
CompositeProvider se sobrescribe cada vez que se modifica el grupo semántico. Por lo tanto,
no debería modificarse manualmente.

Transporte
El propio grupo semántico no se puede transportar. En el sistema de desarrollo, los objetos se
generan a partir del grupo semántico. Estos objetos se pueden transportar al sistema
productivo. Para el transporte, todos los objetos están en el mismo paquete y todos los
objetos están en la misma orden de transporte.
Puede modificar un grupo semántico, pero tenga en cuenta que se aplican las siguientes
restricciones:
● Añadir y borrar campos: puede añadir o borrar elementos (InfoObjetos o campos)
modificando la estructura de referencia y volviendo a crear el grupo. Todos los
componentes para los que se ha fijado la casilla de selección Aplicar estructura de
referencia se ajustan de acuerdo con la nueva estructura. Sin embargo, al borrar
elementos, la característica de referencia debe conservarse.
● Añadir nuevos componentes: puede añadir un componente nuevo al grupo semántico en
cualquier momento.

© Copyright. Reservados todos los derechos. 335

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

● Borrar componentes: los componentes activos se pueden borrar del grupo. En este caso,
solo se elimina la referencia al grupo de los metadatos del objeto DataStore avanzado; el
propio objeto DataStore avanzado se conserva. Si desea borrarlo, ejecute esta operación
directamente en el objeto DataStore avanzado.
● Eliminar el grupo semántico: si elimina un grupo semántico, se conservan los objetos
DataStore avanzados participantes y el CompositeProvider. Solo se eliminan las
referencias al grupo en los objetos DataStore avanzados individuales.
● Modificar criterios: Los criterios de partición se pueden modificar en cualquier momento
sin remodelación. Si restringe los criterios para que ya no se correspondan con los datos
cargados, a menudo es necesario remodelar. Para obtener más información, consulte la
siguiente sección sobre Remodeling después de la generación.
● Modificación de un DSO avanzado que es el componente de un grupo: después de añadir
componentes, puede modificar directamente la estructura de componentes individuales.
Puede realizar la modificación en la pantalla de edición del objeto DataStore avanzado
como de costumbre. El editor indica que el objeto DataStore avanzado pertenece a un
grupo. Una vez que se realiza este tipo de modificación, la estructura del objeto DataStore
avanzado generalmente se desvía de la estructura de referencia del grupo. Si la casilla de
selección Mantener estructura no está marcada, la siguiente activación del grupo
semántico deshará la modificación. Al realizar modificaciones, tenga en cuenta que la
característica de referencia no se puede borrar del objeto DataStore avanzado.
● Remodeling después de la creación: si los componentes de un grupo semántico ya
contienen datos, puede ser necesario remodelar después de la generación. Durante el
proceso de generación, se crean jobs de remodelado para los componentes afectados.
Estos jobs deben ejecutarse manualmente en la transacción RSCNV_MONITOR. La
generación del grupo semántico se ejecuta sin errores y solo se visualiza una advertencia
para los componentes afectados. El remodelado suele ser necesario cuando se restringen
los criterios. Si el remodelado no es correcto, deberá ajustar los criterios para que
coincidan con los datos cargados o borrar selectivamente los datos no coincidentes del
objeto DataStore avanzado. A continuación, debe reiniciar la solicitud de remodelado.

Ejemplo: Creación de un grupo semántico simple

Figura 242: Creación de un grupo semántico: detalles generales

336 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de objetos DataStore avanzados (ADSO)

Figura 243: Crear un grupo semántico: Definir particiones

Figura 244: Creación de un grupo semántico: Generar objetos relacionados

Figura 245: Creación de un grupo semántico: objetos SAP BW resultantes

Detalles adicionales de objetos DataStore avanzados

El objeto DataStore avanzado (aDSO) es el objeto SAP BW/4HANA para el almacenamiento
persistente de datos.
En función del tipo, puede definir campos clave y los campos dependientes se pueden
sobrescribir o añadir. Como ya se ha introducido en unidades anteriores, aquí el foco está en
las características adicionales:

© Copyright. Reservados todos los derechos. 337

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Figura 246: Modelado con campos en lugar de InfoObjetos 1

Figura 247: Modelado con campos en lugar de InfoObjetos 2

Figura 248: Límites generales para el modelado aDSO

Número de campos clave

338 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de objetos DataStore avanzados (ADSO)

Un aDSO estándar puede contener hasta 120 campos clave, lo que es una mejora importante
en comparación con los DSO (clásicos) con un máximo de 16 campos clave. La clave puede
consistir en InfoObjetos o campos o cualquier combinación de ambos. En un aDSO data mart,
no hay límite para la cantidad de campos clave.
Cantidad de campos
Un objeto DataStore avanzado puede contener hasta 1000 campos (campos clave/
InfoObjetos + campos de datos/InfoObjetos).
Atributos de navegación
El foco del objeto DataStore avanzado es la gestión de datos transaccionales con su propia
persistencia. Las funciones de gestión de informes ampliadas, como la disponibilidad de
atributos de navegación, no están disponibles en este modelo de datos (véase también la
nota SAP 2215947). Sin embargo, puede definirlos en CompositeProvider en la parte superior
del objeto DataStore avanzado y, a continuación, están completamente disponibles para el
reporting. Para obtener más detalles, consulte la nota SAP 2185212: aDSO: Recomendaciones
y restricciones relacionadas con la generación de informes.
Sin embargo, en la ficha Detalles de un objeto DataStore avanzado, los atributos de
navegación de los InfoObjetos se pueden activar para las transformaciones para evitar la
configuración de búsquedas manuales. En la pestaña Detalles, seleccione el InfoObjeto que
debe proporcionar sus atributos de navegación a la estructura fuente de una regla de
transformación de BW/4HANA y, a continuación, active la propiedad Utilizar atributos de
navegación en extracción.

Parametrizaciones relativas a la generación de SID

Figura 249: Opción de verificación de datos maestros aDSO

© Copyright. Reservados todos los derechos. 339

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Remodelación de ADSO

Figura 250: Requisitos de remodelado debido a modificaciones en ADSO que contienen datos

Si su aDSO está vacío, los cambios son posibles en las herramientas de modelado BW/
4HANA sin actividades adicionales. En algunos casos, como sustituir un InfoObjeto por un
campo o viceversa, el remodelado es más fácil si activa primero el estado actual y, a
continuación, selecciona el botón Remodel (que requiere una definición de aDSO activa) y, a
continuación, activa el nuevo estado. El cambio es inmediatamente effecitve.
Sin embargo, si el aDSO ya contiene datos, el sistema sigue una lógica predefinida para
decidir si se requiere una tarea de remodelación manual adicional para activar el objeto
correctamente. Esto también se aplica a la gestión de transporte cuando se aprovisionan
finalmente estas modificaciones en el sistema de producción. El rol del job de remodelado
separado es mantener el tiempo de activación al mínimo y, por lo tanto, evitar cancelaciones
durante la ejecución directa (por ejemplo, timeouts). Este cinturón de seguridad está
justificado porque los cambios en los ADSO con muchos datos pueden resultar en
operaciones de lectura y escritura en los datos existentes en el objeto DataStore avanzado.
Los requisitos de remodelado no se limitan a las modificaciones ofrecidas por el botón
Remodelación en la IU de modelado aDSO de las herramientas de modelado BW/4HANA. El
framework de remodelado también se utiliza cuando otros cambios requieren actividades
cruciales de lectura y/o escritura en las tablas de base de datos aDSO, como cambios en las
propiedades de modelado generales, cambios en la clave aDSO, cambios en índices,
particiones o configuraciones de Nivelación de datos.

1. Asegúrese de iniciar el remodelado desde una versión activa del aDSO.

2. En las herramientas de modelado de SAP BW/4HANA, abra el objeto DataStore avanzado

que desea modificar. Si desea utilizar las opciones de remodelado aDSO estándar,
seleccione Remodeling en la etiqueta Detalles. A continuación, estarán disponibles las
siguientes opciones. Consulte la ayuda de la aplicación BW/4HANA para obtener detalles
adicionales sobre las restricciones y las formas de trabajar:

● Sustituir InfoObjeto por otro

340 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de objetos DataStore avanzados (ADSO)

● Sustituir InfoObjeto por un campo

● Sustituir campo por otro

● Sustituir campo por un InfoObjeto

● Rellenar con el valor del InfoObjeto

● Rellenar con el valor del campo

● Rellenar con valor constante

Para otras actividades, como modificar los campos clave de aDSO, añadir o borrar un
InfoObjeto o campo, utilice los otros botones de la pestaña Detalles.

3. Durante la activación, el sistema verifica si el objeto se puede activar inmediatamente o si

se debe remodelar primero. Si se requiere remodelado, aparece una advertencia:
Remodeling está pendiente. El objeto DataStore no está activado. Ejecute el remodelado.
Esto significa que el objeto aún no está activado y se crea una solicitud de remodelado. Si
ha realizado dos o más modificaciones en su objeto, estas modificaciones se compilarán
en una solicitud de remodelado. Puede seguir utilizando la versión aDSO antigua hasta
que no se haya ejecutado la solicitud de remodelado.

4. Abra la aplicación Solicitudes de remodelado en el cockpit de BW/4HANA o utilice la

transacción RSMONITOR para abrir el monitor de remodelado en su sistema SAP BW/
4HANA. Identifique la solicitud generada e iníciela o prográmela manualmente.

5. Si desea transportar un aDSO remodelado al sistema de test y finalmente al sistema

productivo, y ya existe en el sistema productivo, el sistema verifica si es necesario
remodelar y se crea la solicitud de remodelado necesaria en el sistema de destino. Si
desea transportar un DSO avanzado para el que se ha creado una solicitud de remodelado
pero que aún no se ha ejecutado, un mensaje de advertencia le informará de que la versión
M y la versión A son diferentes. Solo puede transportar la versión A (sin las modificaciones
actuales).

Nota:
Consulte este blog para obtener más detalles:

Rol de remodelado en el proceso de gestión de modificaciones aDSO: https://

blogs.sap.com/2020/11/30/role-of-remodeling-in-the-adso-change-
management-process/

Gestión de ADSO
Mientras se modelan los ADSO en las herramientas de modelado de BW (BWMT) de SAP
HANA Studio, la gestión del flujo de datos relacionado y la supervisión de la carga se llevan a
cabo en el cockpit de BW/4HANA basado en la web. Aquí debe realizar tareas
administrativas, como activar o borrar solicitudes, visualizar datos y visualizar el log de
modificaciones.
Algunas funciones de soporte están disponibles en la transacción SAP GUI RSOADSO:

● Visualizar datos
● Visualizar modelo de datos (botón Visualizar XML o Visualizar salida)

© Copyright. Reservados todos los derechos. 341

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

● Verificar y activar modelo de datos

● Entrada catálogo obj.
● Escribir orden de transporte (menú Tratar → Escribir orden de transporte)
● Referencia de utilización

Figura 251: Transacción RSOADSO

Existen herramientas adicionales para analizar los ADSO y reparar su inconsistencia:

342 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de objetos DataStore avanzados (ADSO)

Figura 252: Otras herramientas de soporte aDSO

● Report RSDG_ADSO_ACTIVATE para activar estos objetos y reparar determinados

problemas en su definición de modelo de datos
● Report SAP_ADSO_DESIGNS para analizar el tamaño de los ADSO y planificar actividades
de limpieza

Figura 253: Ejercicio: aDSO para la capa de núcleo EDW

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Modelar e implementar objetos DataStore avanzados (ADSO)

© Copyright. Reservados todos los derechos. 343

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

344 © Copyright. Reservados todos los derechos.

 Capítulo 9
Lección 2
Modelado e implementación de InfoFuentes y
conversiones en transformaciones

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Modelar e implementar InfoFuentes
● Decidir cómo derivar ratios
● Convertir monedas
● Convertir unidades de medida

El rol de las InfoFuentes en LSA++

Las InfoFuentes pueden desempeñar un papel decisivo en LSA++. Cuanto más complejo sea
un modelo de SAP BW/4HANA, más importante será pensar en las InfoFuentes para
garantizar la capacidad de mantenimiento de los flujos de datos y la flexibilidad global.

Figura 254: Dividir transformaciones

¿En qué casos de utilización sería especialmente útil una InfoFuente?

● Conectar múltiples fuentes y objetivos
Como ejemplo, utilice una InfoFuente si desea conectar varias fuentes diferentes a un
destino común y las diferentes fuentes requieren las mismas reglas empresariales. Utilice
la estructura fuente como modelo para la InfoFuente y cree asignaciones estándar (1:1).

© Copyright. Reservados todos los derechos. 345

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Las reglas empresariales necesarias se aplican en la transformación posterior entre la

InfoFuente y el destino. Puede realizar cualquier modificación en estas reglas de forma
centralizada en esta transformación, según sea necesario.
Supongamos que tiene varias fuentes y varios destinos, y puede identificar una parte que
es relevante para todas las combinaciones de origen y destino, y otras partes específicas
de origen o destino. A continuación, utilice una InfoFuente de salida de uso común
después de las fuentes y una InfoFuente de entrada de uso común delante de los destinos.
A continuación, agrupe la lógica de proceso en lugar de modelar un gran número (y
potencialmente confuso) de reglas de transformación individuales. La parte principal de la
lógica de transformación siempre se encuentra entre la InfoFuente de salida del InfoSitio
fuente y la InfoFuente de entrada del InfoSitio destino. Los nuevos InfoSitios se pueden
añadir fácilmente con una sola regla adicional. Usted obtiene flexibilidad.
● Dividir una transformación compleja en partes simples
Supongamos que desea convertir los datos del centro de coste a la moneda de la sociedad
CO. En lugar de programar una secuencia compleja de pasos, puede integrar una
InfoFuente. Antes de la InfoFuente, busque la moneda de destino a partir de los atributos.
Después de la InfoFuente, incluya la conversión de moneda.
Si la transformación se debe modificar, puede fijar solo una de las partes. Obtiene
flexibilidad y facilidad de uso.
● Reducir el número de transformaciones
Si tiene N fuentes y destinos M, necesitará N transformaciones M veces para rellenarlas
todas. Si incluye una InfoFuente, puede combinar N reglas antes de la InfoFuente y M
reglas después de la InfoFuente. Solo necesita transformaciones individuales N + M. Es
más fácil encontrar y corregir uno de ellos si lo necesita.

Ratios dinámicos o persistentes

Figura 255: Ratios dinámicos o persistentes

346 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de InfoFuentes y conversiones en transformaciones

Los ratios suelen formar parte del destino de datos y se rellenan con datos mediante el
proceso de extracción, transformación y carga (ETL).
También puede calcular ratios en el query y estos ratios formarán parte de la tabla de hechos.
La pregunta es si modelar estos ratios en el modelo de datos y cargar los datos durante el
proceso de carga (persistente), o si modelar los ratios en una definición de consulta y calcular
el hecho durante la ejecución de la consulta (dinámica). Para persistente, el ratio calculado
debe formar parte del modelo de datos y el cálculo debe realizarse utilizando rutinas, por
ejemplo, en las reglas de actualización.
Para dinámico, el ratio debe definirse en la definición de query. Si calcula un hecho durante la
ejecución de un query, esto puede afectar al rendimiento del query, dependiendo de la
complejidad del ratio calculado y de la frecuencia con la que se ejecuta el query. Con SAP BW
en SAP HANA, sin duda estos cálculos serán mucho más rápidos que con BW en una base de
datos tradicional.

Opciones para la conversión de moneda

En SAP BW/4HANA, la conversión de moneda se puede realizar en las siguientes
ubicaciones:
● Cuando se ejecuta una consulta BW
● En una transformación
● En una vista de cálculo de SAP HANA que está integrada en un proveedor compuesto,
pero luego, con una definición basada en SAP HANA diferente

Figura 256: Conversión de moneda

Si convierte monedas durante una actualización de datos, los valores de conversión se

guardan físicamente con la moneda seleccionada. Esto acelera el procesamiento de informes.
Sin embargo, el valor original y la moneda original se pierden.

© Copyright. Reservados todos los derechos. 347

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Consejo:
Para evitar esta pérdida de información, se recomienda almacenar los valores
originales junto a los convertidos en el aDSO. (Esto no ralentiza la lectura de los
datos para el reporting porque solo se leen las columnas solicitadas.)

Al convertir monedas durante la gestión de informes, el análisis se puede realizar para varias
monedas de destino. La moneda de transacción original no se pierde.

Tipos de conversión de moneda

El factor para la conversión de moneda se denomina tipo de cambio. El tipo de cambio
depende de cuatro parámetros:
● Moneda de origen
● Moneda de destino
● Tipo de cotización
● Referencia temporal

Esta relación se almacena en la tabla TCURR. Existen muchas formas de determinar la

moneda de destino o la referencia temporal. Un objeto BW especial, tipo de conversión de
moneda, define cómo se derivan estos parámetros.

Figura 257: Tabla TCURR

348 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de InfoFuentes y conversiones en transformaciones

Figura 258: Ejemplo: Crear una clase de conversión de moneda

Existen muchas formas de determinar la moneda de destino o la referencia temporal. Como

ejemplo, puede crear un tipo de conversión de moneda con el tipo de cambio (=tipo de curso)
M, la moneda de destino USD y la fecha de conversión Día de ventas.
En una clase de conversión de moneda, también puede especificar un InfoObjeto (por
ejemplo, la característica sociedad) a partir del cual se determina la moneda fuente o destino
de la conversión. En este caso, debe fijar un atributo de moneda en la actualización de
características en la etiqueta Ampliado que esté incluido como atributo de la característica
(sociedad) en la etiqueta Atributos.

Figura 259: AttributeAsCurrencyKey.ppt

© Copyright. Reservados todos los derechos. 349

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Figura 260: Concepto de conversión de moneda

La figura, Concepto de conversión de moneda BW, muestra esta opción mencionada

anteriormente: la moneda fuente o destino se puede determinar como un atributo de moneda
de un InfoObjeto que forma parte de la fuente. Por ejemplo, una sociedad francesa utilizaría
EUR mientras que una sociedad canadiense utilizaría CAD.
Según el escenario empresarial, el valor de destino debe almacenarse o determinarse en el
tiempo de ejecución de la consulta. Se pueden utilizar las mismas o diferentes clases de
conversión en diferentes escenarios. Pero no se admiten todos los tipos de traducción en una
ubicación específica. Si la conversión de moneda se lleva a cabo en el tiempo de ejecución, el
usuario de reporting puede definir la moneda de destino o la referencia temporal mediante
una variable BW. Una opción de este tipo no se puede utilizar en una transformación.
Para todos los tipos de conversión, se utilizan las mismas tablas de conversión de moneda
(tablas TCUR*), especialmente la tabla TCURR con tipos de cambio.

Nota:
Para importar tipos de cambio de SAP ECC o SAP S/4HANA manualmente, en el
workbench de almacenamiento de datos, en Administración, seleccione el árbol
del sistema fuente. En el menú contextual de su sistema fuente SAP, seleccione
Transferir tipos de cambio.
Para importar periódicamente valores actuales, planifique un job con el programa
RSIMPCURR con una variante específica. Del mismo modo, los tipos de cambio se
pueden importar desde un sistema fuente de fichero plano utilizando el programa
RSIMPCURFILE.

350 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de InfoFuentes y conversiones en transformaciones

Integración de conversión de moneda en el flujo de datos

En una transformación BW, puede activar la conversión de moneda y unidad en la pestaña
General. A continuación, puede seleccionar tipos de conversión de moneda si asigna un ratio
con una moneda.

Requisitos previos para la conversión de moneda en la transformación

Los requisitos previos para la conversión de moneda son los siguientes:

● La fuente de datos debe contener un ratio (tipo de datos AMOUNT) con una moneda fija o
variable.
● El destino de datos debe contener un ratio correspondiente (tipo de datos AMOUNT) con
una moneda fija o variable especificada.
● Todas las monedas y unidades deben formar parte de la clave del destino de datos. Esto
ya no es necesario a partir de BW/4HANA2.0 SP04.
● En la transformación, la casilla de selección Permitir conversión de moneda y unidad debe
estar marcada.
● Debe definir una clase de conversión de moneda adecuada en SAP BW.
● Debe haber cargado tipos de cambio en SAP BW desde el sistema fuente.

Para la conversión de moneda realizada durante la gestión de informes, solo se aplican los
dos últimos requisitos previos.

Nota:
Antes de BW/4HANA 2.0 SP04, era necesario que la unidad o la moneda fuera un
campo clave del destino. Esto ya no es necesario.

© Copyright. Reservados todos los derechos. 351

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Figura 261: Conversión de moneda en la transformación

Durante la transferencia de datos, las monedas se pueden convertir al ratio de destino en el

destino de datos. Puede convertir la moneda en la actualización de las siguientes maneras:
● Mediante clases de conversión de moneda
● Utilización de rutinas definidas por el usuario

La conversión de moneda normalmente se realiza con tipos de conversión de moneda

reutilizables. Las rutinas se utilizan cuando la conversión es un caso especial que no se puede
o no se debe realizar utilizando tipos de conversión de moneda.
Como resultado de la conversión de moneda, los importes se graban en la moneda de destino
en el destino de datos.

Conversión de unidad
La conversión de unidades le permite convertir ratios con unidades que utilizan diferentes
unidades de medida en el sistema fuente en una unidad de medida uniforme en el sistema
SAP BW/4HANA.
Esta función permite la conversión de registros de datos actualizados de la unidad de medida
de origen a una unidad de medida de destino, o a diferentes unidades de medida de destino, si
la conversión se repite. En términos de funcionalidad, la conversión de unidades se estructura
de forma similar a la conversión de moneda. Se basa en parte en la funcionalidad de
conversión de unidades en SAP NetWeaver Application Server.
Las conversiones simples se pueden realizar entre unidades de medida que pertenecen a la
misma dimensión (como metros a kilómetros, kilogramos a gramos).
También puede realizar conversiones específicas de InfoObjeto, como un ejemplo en el que se
solicitaron dos paletas (PAL) del material 4711 y esta cantidad de pedido debe convertirse en
la cantidad de stock caja (CAR).

352 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de InfoFuentes y conversiones en transformaciones

Figura 262: Conversión de unidades en transformaciones

La conversión de unidades se basa en tipos de conversión de unidades. El tipo de conversión

de unidades es una combinación almacenada de los siguientes parámetros que determinan
cómo se realiza la conversión. Los parámetros que determinan los factores de conversión son
la unidad de medida de origen y de destino, y la opción que seleccione para determinar los
factores de conversión. Se puede integrar en los siguientes lugares:
● Regla de asignación directa de ratio en una transformación BW a una InfoFuente o aDSO,
● Rutinas definidas por el usuario en las reglas de transformación (en determinados casos),
● Propiedades de ratio en un query BW,

No es posible convertir valores en un DTP en un destino open hub o en una vista Open ODS o
CP. Se recomienda realizar la conversión de unidades en la transformación y almacenar el
resultado en un aDSO. A continuación, es posible acceder a los valores convertidos en el
tiempo de ejecución de query, lo que mejora el rendimiento del tiempo de ejecución de query.
El alcance de la mejora depende de la cantidad de datos que se convierten.

Nota:
Al igual que la conversión de moneda, la conversión de unidad debe estar
permitida en las opciones generales de la transformación. Seleccione Permitir
conversión de moneda y unidad. A continuación, puede especificar
individualmente para cada ratio si se realiza una conversión de unidades y cuál
durante la actualización. (Antes de SAP BW/4HANA 2.0 SP04, era necesario que
el InfoObjeto de unidad fuera un campo clave del destino, pero esta restricción ya
no se aplicaba.)

© Copyright. Reservados todos los derechos. 353

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Conversión de unidades en transformaciones y en un query BW

La conversión de unidades durante la transformación le permite convertir registros de datos
de la unidad de medida fuente en una unidad de medida del destino de transformación. La
conversión de unidades en la transformación se realiza normalmente utilizando tipos de
conversión de unidades definidos previamente.
En función del tipo de unidad de medida, existen dos tipos diferentes de ratios:
● Ratios con unidad de medida fija
Con una unidad de medida fija, la unidad se fija para el ratio. El ratio se refiere
específicamente a la unidad de medida, por lo que no es necesario volver a introducir la
unidad en el registro de datos.
● Ratios con unidad de medida variable
Una unidad de medida variable hace referencia a un InfoObjeto de unidad.

Las transformaciones se pueden realizar para ratios de las siguientes maneras:

● Cada ratio en un aDSO (ratio destino) tiene un ratio correspondiente en la fuente (ratio
fuente). No se ha realizado la conversión de unidades
● No existe ningún ratio fuente correspondiente en los datos fuente para el ratio destino en
el aDSO. En este caso, dispone de las siguientes opciones:
- Puede asignar un ratio fuente del mismo tipo al ratio de destino.
Si las unidades de medida de ambos ratios son iguales, no se puede realizar ninguna
conversión de unidades. Si las unidades de medida son diferentes, se puede realizar
una conversión utilizando un tipo de conversión de unidades o simplemente asignando
una unidad de medida.
- Si no existe ningún ratio fuente correspondiente del mismo tipo, deberá rellenar el ratio
del destino mediante una rutina.

Creación de una rutina para la conversión de unidades

Si desea convertir unidades de medida durante la transformación pero la conversión de
unidades no está disponible por uno de los motivos mencionados anteriormente, puede crear
una rutina. En la definición de regla de transformación, seleccione Rutina con unidad. En el
editor de rutinas se obtiene un parámetro de retorno adicional UNIT y la unidad de medida de
destino se determina mediante el valor de este parámetro.

Factores de conversión
La forma en que se deben determinar los factores de conversión es el elemento decisivo en la
definición de una clase de conversión.

354 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de InfoFuentes y conversiones en transformaciones

Figura 263: Determinación de factores de conversión de unidades

Figura 264: Crear tipos de conversión de cantidad (unidad)

Opciones de factor de conversión

Las opciones específicas para la determinación dinámica de factores de conversión son las
siguientes:
● Utilice el InfoObjeto de referencia.

© Copyright. Reservados todos los derechos. 355

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

● Utilice unidades de medida centrales (T006).

● Utilice el InfoObjeto de referencia si está disponible. De lo contrario, utilice unidades de
medida centrales (T006).
● Utilice las unidades de medida centrales (T006) si están disponibles. De lo contrario,
utilice el InfoObjeto de referencia.

La determinación dinámica de factores de conversión permite que la determinación provenga

de un InfoObjeto de referencia (y de la cantidad vinculada DSO), de la tabla T006 o de ambos.
Si ambos, el orden de las operaciones se fija y si el sistema no puede encontrarlos en la fuente
inicial, buscará la fuente alternativa para la determinación final.
Las siguientes opciones están disponibles para los factores de conversión:
● Mediante un InfoObjeto de referencia
El sistema intenta determinar los factores de conversión del InfoObjeto de referencia que
ha seleccionado o del objeto DataStore de cantidad correspondiente. Si desea convertir
1000 gramos en kilogramos pero los factores de conversión no están definidos en la
cantidad DSO, el sistema no puede realizar la conversión (aunque se trate de una
conversión muy simple).
● Utilizando unidades de medida centrales
La conversión sólo puede tener lugar si la unidad de medida fuente y la unidad de medida
de destino pertenecen a la misma dimensión (por ejemplo, metros a kilómetros,
kilogramos a gramos, etc.).
● Utilizando InfoObjeto de referencia, si está disponible, unidades de medida centrales, si no
El sistema intenta determinar los factores de conversión utilizando el DSO de cantidad que
ha definido. Si el sistema encuentra factores de conversión, los utiliza para realizar el
cálculo. Si el sistema no puede determinar los factores de conversión a partir del DSO de
cantidad, lo intentará de nuevo utilizando las unidades de medida centrales.
● Utilizando unidades de medida centrales, si están disponibles, InfoObjeto de referencia si
no
El sistema intenta encontrar los factores de conversión en las unidades centrales de la
tabla de medidas. Si el sistema encuentra factores de conversión, los utiliza para realizar la
conversión. Si el sistema no puede determinar factores de conversión a partir de las
unidades de medida centrales, intentará encontrar factores de conversión que coincidan
con los atributos del registro de datos mirando la cantidad DSO.

Las opciones que puede realizar en el sistema afectan al rendimiento y la decisión debe
basarse estrictamente en el conjunto de datos. Tenga en cuenta los siguientes puntos:
● Si está realizando conversiones solo dentro de la misma dimensión, la segunda opción es
la más adecuada.
● Si está realizando conversiones específicas de InfoObjeto (por ejemplo, conversiones
específicas de material) entre unidades que no pertenecen a la misma dimensión, la
primera opción es la más adecuada.

356 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de InfoFuentes y conversiones en transformaciones

Nota:
En los dos casos anteriores, el sistema accede solo a una tabla de base de
datos. Esta tabla contiene los factores de conversión.

● Con la tercera y la cuarta opción, el sistema intenta determinar factores de conversión en

cada etapa. Si no existen factores de conversión en la tabla básica (T006), el sistema
buscará de nuevo en la cantidad DSO o a la inversa.
● La opción que seleccione dependerá de cómo desee distribuir la conversión. Por ejemplo,
si la unidad de medida de origen y la unidad de medida de destino pertenecen a la misma
dimensión para el 80% de los registros de datos que desea convertir, intente determinar
factores utilizando las unidades de medida centrales (la cuarta opción) y acepte que el
sistema tendrá que buscar en la segunda tabla también el 20% restante.

Factor de conversión de InfoObjeto (ratio)

La opción Factor de conversión de InfoObjeto (ratio) (como con Tipo de cambio de InfoObjeto
en tipos de conversión de moneda) solo está disponible cuando carga datos. El ratio que
indique aquí debe existir en el InfoSitio y el valor que este ratio tiene en el registro de datos se
toma como factor de conversión.

Unidad de medida de origen

La unidad de medida de origen es la unidad de medida que desea convertir. Durante el
proceso de carga de datos, la unidad de medida fuente se determina dinámicamente a partir
del registro de datos o de un atributo de unidad (cantidad) de un InfoObjeto (característica).
También puede especificar una unidad de medida fuente fija o determinar la unidad de
medida fuente mediante una variable.
Al convertir cantidades en un query BW, el registro de datos determina la unidad de medida
fuente.

Unidad de medida de destino

Dispone de las siguientes opciones para determinar la unidad de medida de destino:
● Puede introducir una unidad de medida de destino fija en el tipo de conversión de unidad
(por ejemplo, kg).
● Puede especificar un InfoObjeto en el tipo de conversión de unidades que se utiliza para
determinar la unidad de medida de destino durante la conversión. Todos los InfoObjetos
que tienen al menos un tipo de atributo de unidad se listan en InfoObjeto para determinar
unidad de medida. Debe seleccionar uno de estos atributos como el atributo de cantidad
correspondiente.
● Como alternativa, puede especificar que la unidad de medida de destino se determine a
partir de una variable durante la conversión.

Entradas de tabla globales transferidas para unidades de medida de sistemas

SAP
Utilice esta función para transferir todas las tablas relevantes para la conversión de unidades
desde otros sistemas SAP conectados al sistema SAP BW. Específicamente, esto incluye las
siguientes tablas:
● T006

© Copyright. Reservados todos los derechos. 357

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

● T006A
● T006B
● T006C
● T006D
● T006I
● T006J
● T006T

En el workbench de data warehousing, en Modelado, seleccione el árbol del sistema fuente.

En el menú contextual de su sistema fuente SAP, seleccione Transferir opciones globales.
Aparecerá la pantalla Transfer Global Settings: Selection. En Transferir contenido de tabla
global, seleccione el campo Unidades de medida.

Figura 265: Ejercicios: Implementar conversión de moneda y unidad

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Modelar e implementar InfoFuentes
● Decidir cómo derivar ratios
● Convertir monedas
● Convertir unidades de medida

358 © Copyright. Reservados todos los derechos.

 Capítulo 9
Lección 3
Modelado e implementación de
CompositeProviders

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Modelar e implementar CompositeProviders

CompositeProviders

Figura 266: Resumen de CompositeProvider

En un entorno SAP BW/4HANA, a menudo se combinan datos procedentes de varias fuentes.

Esta combinación de datos se puede modelar enriqueciendo datos durante el proceso de
staging. El resultado de este enriquecimiento persiste en un nivel de base de datos,
normalmente en objetos DataStore (avanzados). Sin embargo, la combinación de datos
también se puede realizar durante el tiempo de ejecución de la consulta realizando una
operación de unión o unión en combinación con agregaciones y proyecciones, por ejemplo.
Normalmente, esto es modelado por CompositeProviders.

© Copyright. Reservados todos los derechos. 359

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Nota:
CompositeProvider es el objeto que forma la capa de data mart (virtual) en el
modelo de LSA++ que proporciona datos para la generación de informes y el
análisis para BW/4HANA. No lo mezcle con los CompositeProviders locales que
utilizan los usuarios empresariales en el área de trabajo de BW.

Funciones clave de CompositeProvider

● Definición flexible de uniones y joins (outer, inner, referential, left, right, full, temporal
joins)
● Combinación flexible de proyección, agregación, join y unión en cualquier orden
● Integración flexible de todos los InfoSitios BW y las vistas de SAP HANA
● Fácil sustitución de un proveedor de piezas por otro
● Integración de filtros SQL y fórmulas
● Asignación de atributos de navegación
● CompositeProvider puede ser consumido por otro CompositeProvider
● Optimizado completamente para SAP HANA

En general, la flexibilidad y el rendimiento son beneficios clave.

Con las ampliaciones de BW/4HANA SPS 04, hay disponibles más funciones de consultas
BW o vistas de cálculo de SAP HANA en CompositeProvider. Por lo tanto, el límite entre el
modelado BW y el modelado nativo de HANA se ha desplazado a la dirección del modelado
BW.

Figura 267: CompositeProvider en SAP HANA Studio: UNION

360 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de CompositeProviders

Figura 268: Proveedor compuesto en SAP HANA Studio: JOIN

InfoSitios admitidos
Puede integrar los siguientes tipos de PartProvider en un CompositeProvider utilizando un
nodo UNION o JOIN:
● InfoObjeto
● Objeto DataStore (avanzado)
● Vista Open ODS
● CompositeProvider (si se ha liberado para su uso en otro CompositeProvider)
● Vista de cálculo de SAP HANA

Si el nodo raíz SQL es UNION, también puede incluir un nivel de agregación.

Además, puede aplicar nodos de agregación o proyección con filtros o cálculos.
Aspectos a tener en cuenta en general:
● Los ADSO deben tener propiedades que sean relevantes para la gestión de informes. En
otras palabras, deberían tener una de las siguientes combinaciones de propiedades:
- Objeto DataStore estándar con y sin log de modificaciones
- Objeto DataStore de staging, reporting habilitado
- Objeto DataStore data mart
- Actualización directa de objeto DataStore
● Las vistas SAP HANA externas generadas para InfoSitios de SAP BW generalmente no
están disponibles como objetos de entrada para CompositeProviders.
● Se admiten ambas generaciones de vistas de cálculo de SAP HANA (XS clásico, XS
avanzado/HDI). Consulte la nota SAP 2810348 - Las vistas de cálculo de HDI no están
disponibles para el consumo en BW/4HANA sobre cómo configurar el consumo de HDI en
el Customizing de SAP BW/4HANA.
● Las vistas Open ODS que desea utilizar en CompositeProviders sólo pueden contener
campos con tipos de datos compatibles con InfoObjetos. Estos son los siguientes tipos de
datos: CHAR, CUKY, CURR, DEC, DATS, FLTP, INT4, NUMC, TIMS, QUAN, UNIT. El tipo de
datos STRG también se admite para valores de campo de tipo de característica
especialmente largos.

© Copyright. Reservados todos los derechos. 361

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

● En el caso de objetos DataStore, los datos se pueden leer desde el almacenamiento

nearline para uniones y joins.
● Cuando se asigna un campo, el sistema verifica si el campo de destino es adecuado para la
asignación que se está realizando. Un campo destino es adecuado si aún no se ha
asignado a otro campo de la estructura fuente. Además, el sistema verifica si tiene un tipo
de datos compatible. Consulte la nota SAP 2228967 - Comprender la asignación
automática de campos en el proveedor compuesto BW para obtener todos los detalles.

Figura 269: Tipos de join en CompositeProvider

362 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de CompositeProviders

Figura 270: Join no igual en proveedor compuesto

Combinaciones temporales
En SAP BW/4HANA y SAP BW 7.5 SP04, CompositeProviders también admite el modelado
de uniones temporales para representar flujos de tiempo.

Figura 271: Enlace temporal en proveedor compuesto

© Copyright. Reservados todos los derechos. 363

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Figura 272: Crear un join temporal en un proveedor compuesto

Se aplican las siguientes restricciones para los joins temporales en los proveedores
compuestos:
● Es compatible con PartProviders: solo InfoObjetos, DSO (avanzado).
● Un interlocutor join debe modelarse con dependencia temporal, el otro interlocutor join
debe tener una característica de tiempo que sea una característica que haga referencia a
0DATE, 0CALMONTH o similar.
● No se permiten nodos de unión en uniones temporales.
● El CompositeProvider resultante no puede contener ningún campo que no esté asignado.

En cuanto se utiliza una característica dependiente del tiempo en el join, el join se convierte
en dependiente del tiempo. Los dos campos adicionales 0DATEFROM y 0DATETO se
comparan con una característica temporal del interlocutor join. Esta característica de tiempo
debe indicarse como fecha clave en el menú contextual del interlocutor de conexión. Si la
característica de tiempo es un intervalo, como 0CALYEAR, se puede derivar el primer o el
último día del intervalo, o una clase de derivación de fecha clave específica define cómo se
deriva una fecha clave.
También puede desactivar la dependencia temporal mediante Ocultar campos dependientes
del tiempo, siempre que la característica no esté formada exclusivamente por atributos
dependientes del tiempo.
Los DSO avanzados no se pueden definir como dependientes del tiempo. Sin embargo, a
menudo contienen características de tiempo a partir de las cuales se puede derivar un
intervalo de tiempo, o un mínimo de dos InfoObjetos que hacen referencia a, por ejemplo,
STARTDATE y ENDDATE, que puede utilizar para definir un intervalo de tiempo para.

364 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de CompositeProviders

Seleccione Definir dependencia temporal en el menú contextual de este objeto DataStore

avanzado en el CompositeProvider, que lo hace pseudodependiente del tiempo.
Tan pronto como un InfoSitio contenido en el CompositeProvider se convierte en
pseudodependiente del tiempo, se trata como una fuente de datos dependiente del tiempo.
Una diferencia importante entre los InfoSitios dependientes de pseudotiempo y los
InfoObjetos dependientes del tiempo es que el sistema no puede evitar que se produzcan
discontinuidades o solapamientos en la barra de tiempos. Esto siempre depende del set de
datos del pseudo InfoSitio dependiente del tiempo.
Uso del join temporal en lugar de datos persistentes durante la carga
Si su fuente no proporciona la información de categoría, puede derivar la verdad histórica en
SAP BW/4HANA, ya sea añadiendo datos persistentes durante un proceso de carga o
combinando virtualmente los datos maestros y los datos transaccionales en un proveedor
compuesto utilizando un enlace temporal.

Figura 273: Derivar la verdad histórica

Operaciones admitidas

Figura 274: Operaciones admitidas

© Copyright. Reservados todos los derechos. 365

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Figura 275: Proveedor compuesto - Nuevas funciones

En BW/4HANA 2.0 SP04, las posibilidades de modelado para CompositeProvider se han

ampliado en el primer trimestre de 2020. La intención de esta ampliación era permitir más
opciones en el CompositeProvider para reducir los casos de utilización, donde es necesario
un modelado mixto entre SAP HANA y SAP BW/4HANA. Todas las nuevas opciones pueden
tener un impacto en el rendimiento, ya que todavía se garantiza el mejor rendimiento con una
unión simple directamente en los PartProviders. Tenga en cuenta las consideraciones y
recomendaciones de diseño proporcionadas en la nota SAP 2271658 - Design Considerations
for Composite Providercon alguna guía útil para evitar errores de modelado. Lea más al final
de la lección.
Modelado de proyecciones y agregaciones en CompositeProviders
Los nodos Agregación y Proyección no son necesarios en general en el CompositeProvider.
Solo hay algunos casos de uso específicos, donde puede ser interesante utilizarlos, como:
● Definir un filtro o cálculo directamente en la parte superior de un PartProvider
● Definir un comportamiento de agregación diferente para un ratio, por ejemplo, en
combinación con forzar grupo por
● Agregación de datos necesaria entre nodos de combinación
● Bloquee la agregación por defecto de PartProvider con un nodo de proyección para
objetos DataStore y vistas Open ODS:
Por defecto, el CompositeProvider lee los datos de los PartProviders ya agregados y la
Unión directamente en la parte superior de los PartProviders también agrega los datos.
Esto significa también que los datos de PartProviders se agregan antes de ejecutar un join.
Esta agregación es necesaria, por ejemplo, para el tratamiento de join ambiguo. La
agregación directa de datos de PartProvider se puede omitir ahora para ADSO y vistas
Open ODS utilizando un nodo de proyección directamente en la parte superior del
PartProvider. Esto introduce la opción, por ejemplo, de utilizar un comportamiento de
agregación diferente directamente para un PartProvider. Para ello es necesario un nodo de

366 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de CompositeProviders

agregación en la parte superior de esta proyección, que tiene un comportamiento de

agregación diferente especificado para el ratio. Este es el primer comportamiento de
agregación, que se utiliza para el ratio.

Figura 276: Proveedor compuesto - Proyección y nodo de agregación

Figura 277: Proveedor compuesto: Ejemplo de nodo de agregación

© Copyright. Reservados todos los derechos. 367

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Figura 278: Proveedor compuesto - Filtro SQL

Figura 279: Proveedor compuesto - Campo calculado

368 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de CompositeProviders

Figura 280: Proveedor compuesto: Crear y duplicar campo

Modelado y asignación de campos

En el editor de escenarios CompositeProvider, el usuario puede crear y modificar
asignaciones entre los campos (columnas) de una estructura fuente y los campos (columnas)
de un nodo de vista destino. La estructura fuente contiene los campos de un InfoSitio o de
otro nodo de vista en el mismo modelo CompositeProvider. Un nodo destino en el contexto de
asignación siempre es un nodo de vista. Este es el nodo de salida (por defecto) o cualquier
otro nodo de vista intermedio.
Un CompositeProvider admite varios tipos de nodos de vista: unión, unión, agregación o
proyección. El nodo de vista de salida (nodo por defecto) es un nodo de vista dedicado en el
conjunto de todos los nodos de vista en un CompositeProvider. Este nodo de vista define la
semántica del CompositeProvider cuando se utiliza como una vista de reporting. Solo los
campos en el nodo de salida son visibles para las herramientas de reporting.
Durante el modelado del CompositeProvider, los campos de las estructuras fuente se asignan
a la estructura de destino final. Un campo fuente se puede asignar a un campo destino de dos
maneras:
● Arrastrando el campo solo con el ratón del ordenador o como parte de una selección de
campos múltiple a un elemento del área de colocación de destino
● Ejecutando el comando Crear asignaciones en el menú contextual del campo o la selección
de campos en el área fuente

Durante la asignación, suceden dos cosas esenciales. En primer lugar, el editor intenta
identificar un campo de destino potencial en la estructura de nodo de vista de destino. En
segundo lugar, verifica si el campo de destino seleccionado es adecuado para la asignación.
Un campo de destino existente es adecuado si cumple los siguientes criterios:

© Copyright. Reservados todos los derechos. 369

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

● Aún no está asignado a otro campo en la misma estructura fuente de la que proviene el
campo fuente.
● Tiene un tipo de datos binario compatible. En el método 2) se favorece un campo con el
mismo nombre que el campo fuente.

Si no existe ningún campo destino existente adecuado, se creará un nuevo campo destino
con el tipo de InfoObjeto y el tipo de datos adecuados y se asignará al campo fuente. Una
asignación completada se denota mediante una línea sólida que conecta el campo de origen a
la izquierda con el campo de destino en la parte derecha.
La compatibilidad del tipo de datos se garantiza mediante la evaluación de las reglas de
compatibilidad. Para obtener detalles sobre estas reglas, consulte la nota SAP 2228967 -
Comprender la asignación automática de campos en el proveedor compuesto BW.

Utilización de atributos de navegación en CompositeProvider

Figura 281: Activar atributos de navegación en CompositeProvider

Figura 282: Atributos de navegación como campos fuente

370 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de CompositeProviders

Los atributos de navegación se pueden utilizar como campos de origen, pero no por defecto;
esta función debe activarse manualmente. En la pestaña Escenario, seleccione Mostrar
atributos de navegación no asignados de cada PartProvider para que estos campos estén
disponibles como fuentes de características en la estructura de destino del
CompositeProvider. Esto es independiente de la activación de atributos de navegación en el
CompositeProvider. Se gestionan en la etiqueta Salida y se pueden activar para cada
InfoObjeto que contenga atributos listos para la navegación.
Consulte la nota SAP 2215947 - Cómo fijar atributos de navegación para un ADSO, un HCPR o
un nivel de agregación.

Figura 283: Asignación de constantes

Consumo de CompositeProviders en otro CompositeProvider

Figura 284: CompositeProviders anidados

Puede utilizar un CompositeProvider como PartProvider en otro CompositeProvider. Para

activar este consumo, libere primero el CompositeProvider para esta función. En la etiqueta

© Copyright. Reservados todos los derechos. 371

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

General de la interfaz de modelador CompositeProvider en BWMT, seleccione Este

CompositeProvider se puede añadir a otro CompositeProvider.

Nota:
SAP solo admite dos niveles de consumo. Es decir, el CompositeProvider que
consume otro no puede formar parte de otro CompositeProvider en la parte
superior.
Tenga en cuenta que aquí no se admiten todos los escenarios de combinación de
uniones y uniones. Consulte la ayuda de SAPhttps://help.sap.com/viewer/
b3701cd3826440618ef938d74dc93c51/2.0.5/en-US/
d8b12ec099e04e6aa77a312be687db63.html.

Consideraciones de diseño
Consulte la nota SAP 2271658 - Design Considerations for Composite Provider para obtener
recomendaciones adicionales sobre el modelado de CompositeProviders centradas en las
siguientes áreas:
● Rendimiento de uniones
● Cantidad de proveedores de partes
● Valores NULL
● Integridad referencial
● Claves de relación
● Almacenamiento nearline
● Procesamiento basado en clave
● Atributos de navegación
● Campos sin asociación de InfoObjeto
● CompositeProviders anidados
● Operaciones en HANA
● Privilegios de SAP HANA y autorizaciones de SAP BW

Por lo tanto, la nota SAP 2271658 - Design Considerations for Composite Provider
proporciona una lista creciente de recomendaciones y mejores prácticas que proporcionan
una guía para modelar CompositeProviders con respecto al rendimiento y la calidad de los
datos. Algunos de los aspectos más importantes son:
● Inner Join versus Left Outer Join: Si es posible, utilice un inner join, porque este join
siempre es más rápido.
● Si se garantiza la Integridad referencial, debe fijar el indicador correspondiente en la ficha
Salida. A continuación, debe asegurarse de que existe exactamente un registro de datos
maestros para cada valor de la característica en el proveedor. Si existe integridad
referencial, esto puede mejorar el rendimiento.
● Uso de funciones OLAP en escenarios mixtos con vistas de cálculo de SAP HANA: Si hace
un uso significativo de las funciones BW OLAP, recomendamos utilizar solo InfoSitios

372 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de CompositeProviders

persistentes de BW. De este modo se garantiza el mejor rendimiento posible al utilizar las
funciones OLAP de BW. Las funciones OLAP (como la agregación de excepción) solo se
pueden ejecutar de forma optimizada en SAP HANA si todos los campos utilizados en la
consulta tienen ID de datos maestros (SID). Sin embargo, las vistas de cálculo de SAP
HANA no tienen ID de datos maestros.

Consulte también la nota SAP 2103032 - Tiempos de ejecución largos en el query en

CompositeProvider.

Figura 285: CompositeProvider como fuente para una transformación

Al igual que los MultiSitios en el pasado, el nuevo CompositeProvider también puede servir
como fuente para una transformación. Esto puede ser útil para requisitos especiales, cuando
la unión/unión SQL debe persistir en un ADSO, por ejemplo. La extracción del tipo FULL
siempre está disponible. Una extracción de tipo DELTA está disponible si se cumplen las
siguientes condiciones:

1. La operación raíz del CompositeProvider es Union.

2. El CompositeProvider consta solo de ADSO.

3. Todos los aDSO son del tipo objeto DataStore data mart.

Encontrará más detalles en la nota SAP 2556591 - HCPR como fuente de DTP: datos
recuperados incorrectos.
En algunos casos, un query BW en el proveedor compuesto en lugar del propio
CompositeProvider debe utilizarse como fuente para la transformación: consulte la nota SAP
2372430 - Unins ambiguos: LISTCUBE puede mostrar valores incorrectos.
Resumen
El rol del CompositeProvider es proporcionar un objeto de metadatos que forme la capa data
mart dentro de SAP BW/4HANA. Proporciona los datos para la gestión de informes y el
análisis en forma de una estructura de salida rica semánticamente. Hace que los objetos SAP
BW/4HANA subyacentes sean abstractos y proporciona una interfaz de salida que puede
consumir cualquier tipo de consulta al ofrecer la opción de generar una vista de SAP HANA.
Por lo tanto, las consultas de SAP BW siempre deben definirse solo en el nuevo
CompositeProvider, porque esta opción

© Copyright. Reservados todos los derechos. 373

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

CompositeProviders le permite reducir aún más la persistencia de datos en su almacén de

datos. Anteriormente, las operaciones de conexión se realizaban principalmente durante el
staging de datos, con resultados persistentes S en objetos DataStore (clásicos). Por ejemplo,
con el nuevo CompositeProvider, existe una alternativa de prima para evitar esta persistencia
y el TCO relacionado (procesamiento de carga, tiempo y latencia).

Propuesta de valor para su arquitectura EDW

En un almacén de datos de SAP BW/4HANA de última generación, una capa de virtualización
siempre es la interfaz para la gestión de informes de SAP BW. El rol del CompositeProvider es
proporcionar un objeto de metadatos que forme la capa data mart (virtual) dentro de SAP
BW. Además de un almacenamiento físico (aDSO), puede crear muchos CompositeProviders
con diferentes selecciones de campos, de acuerdo con diferentes requisitos empresariales
locales.
El CompositeProvider añade valor a su arquitectura. Un CompositeProvider combina datos
de InfoSitios de SAP BW con vistas de cálculo de SAP HANA por join y unión, con las opciones
Inner Join, Left Outer Join y Temporal Join.

Figura 286: CompositeProviders: Virtualización o unión persistente

Resumen
Aproveche los CompositeProviders optimizados para SAP HANA para reducir la persistencia
de datos en su almacén de datos. En lugar de crear el resultado de las operaciones de
conexión por staging de datos, con un resultado persistente en objetos DataStore
(avanzados), defina las operaciones de conexión aprovechadas por el nuevo
CompositeProvider, que aprovecha las potentes capacidades SQL de SAP HANA. Los
desarrolladores de SAP BW pueden combinar datos de múltiples InfoSitios de SAP BW y
vistas de SAP HANA.

374 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de CompositeProviders

Nota:
Es posible acceder a un CompositeProvider desde otro si el CompositeProvider
subordinado está definido como una unión de proveedores de partes. Si necesita
InfoObjetos y atributos de navegación en el nivel superior de Composite Provider,
deberá integrarlos en el CompositeProvider subyacente de antemano.

Un CompositeProvider hace que los objetos SAP BW subyacentes sean abstractos.

Proporciona una interfaz de salida que puede consumir cualquier tipo de consulta. El orden de
los campos, las descripciones y, en cierta medida, la asociación de InfoObjetos se pueden
modificar.

Figura 287: Esquema estrella dinámico simple

La idea es mantener simples las capas físicas subyacentes con objetos DataStore
(avanzados) o tablas de base de datos. El modelo puede estar basado principalmente en
campos. En la capa virtual por encima de los datos físicos, use principalmente
CompositeProviders, o en algunos casos, vistas Open ODS (tipo de hecho) para agregar
información semántica enriquecida. Asocie InfoObjetos o vistas Open ODS del tipo Datos
maestros y active los atributos de navegación.

Nota:
Puede crear grupos de campos para unir características o ratios semánticamente
cercanos entre sí. (Esto no afecta al rendimiento del tiempo de ejecución.)

Le recomendamos que base siempre el reporting SAP BW en el CompositeProvider

optimizado para SAP HANA, ya que esta opción le ofrece una mayor flexibilidad para
reaccionar a las modificaciones en sus requisitos de reporting. Puede simplemente
intercambiar el InfoSitio subyacente y ajustar algunas asignaciones de campo.

© Copyright. Reservados todos los derechos. 375

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Figura 288: Dimensiones de copos de nieve

Existen algunos trucos adicionales para aumentar la flexibilidad y reducir el volumen de datos.
La dimensión principal es el InfoObjeto que está asociado directamente en el
CompositeProvider. Tenga en cuenta si realmente necesita un campo físico directo para
todos los atributos necesarios de la dimensión central. (Este enfoque de modelo se llama
desnormalizado.) Por ejemplo, si la categoría principal solo depende de la categoría de
producto, es suficiente con almacenar valores de categoría de producto físicamente en la
dimensión principal e integrar la categoría principal como un atributo de clave externa
(atributo transitivo en el InfoObjeto principal). Esto tiene las siguientes ventajas:
● El volumen de datos se reduce porque la relación entre categoría y categoría principal solo
se almacena una vez
● Los InfoObjetos de InfoObjeto principal y de atributo de clave externa pueden tener
diferentes ciclos de carga (si tienen diferentes propietarios o volatilidad)
● Aún decide qué atributos de los atributos son visibles y cuáles no proporcionan un valor
empresarial.

Sin embargo, un join puede tardar mucho tiempo si la dimensión principal y las tablas de
atributos de clave externa son grandes. Luego, es mejor desnormalizar el modelo.

Figura 289: Dividir dimensión

376 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de CompositeProviders

Otro concepto para aumentar la flexibilidad es el concepto de Dimensiones de división.

Imagine que hay algunos atributos de producto que todos pueden ver, como longitud y altura,
y otros que son críticos, como el tipo de producto y el precio. Si todos estos atributos se
almacenan en el mismo InfoObjeto, asociando el InfoObjeto, toda la información de este tipo
aparece como atributos de visualización en todas las consultas, incluidas las críticas.
Además, para cargar un precio nuevo, debe cargar de nuevo toda la lista de atributos, incluida
la información de tamaño no modificada. Para evitar estos problemas, recomendamos crear
diferentes InfoObjetos, uno con atributos técnicos no críticos y otro para atributos críticos. A
continuación, puede decidir para cada CompositeProvider si asociar ambos InfoObjetos (lo
que se puede hacer asignando el mismo campo fuente dos veces al área de destino) o solo
uno u otro. Además, uno de los InfoObjetos podría sustituirse fácilmente por una vista Open
ODS, por ejemplo, si necesita información de precio en tiempo real o si desea reducir el
espacio de almacenamiento, sin cambiar la referencia a los datos almacenados físicamente
del otro InfoObjeto.

Figura 290: Esquema estrella dinámico totalmente expandido

Finalmente, considerando las opciones de atributos transitivos (dimensiones cocidas de

nieve), características de referencia y dimensiones de partición, y dejando algunos campos
sin asociar utilizando un enfoque basado en campos, puede generar un modelo flexible con un
consumo de espacio de almacenamiento mínimo.

© Copyright. Reservados todos los derechos. 377

Capítulo 9 : Implementación de modelos de datos transaccionales de SAP BW/4HANA

Figura 291: Ejercicios: proveedor compuesto

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Modelar e implementar CompositeProviders

378 © Copyright. Reservados todos los derechos.

 Capítulo 9

Evaluación de la formación

1. Los objetos DataStore data mart pueden contener un máximo de 120 campos clave.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

2. Si se utiliza una InfoFuente de entrada delante de un InfoSitio y una InfoFuente de salida

después de un InfoSitio, la lógica de transformación debería encontrarse entre la
InfoFuente de salida del InfoSitio fuente y la InfoFuente de entrada del InfoSitio destino.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

3. ¿Qué influye en la tasa de conversión para una conversión de moneda?

Seleccione las respuestas correctas.

X A La referencia de fecha para la conversión

X B El tipo de cotización

X C El lugar en el que se ejecuta la conversión de moneda

X D El usuario que ejecuta la conversión de moneda

4. A partir de SAP BW/4HANA 2.0, SP 04, CompositeProviders puede contener expresiones

de filtro basadas en SQL.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

© Copyright. Reservados todos los derechos. 379

 Capítulo 9

Respuestas a la Evaluación de la formación

1. Los objetos DataStore data mart pueden contener un máximo de 120 campos clave.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! Los objetos DataStore de staging contienen una clave semántica con como
máximo 120 campos o InfoObjetos, pero los objetos DataStore data mart contienen todas
las características como clave, incluso si son más de 120. Leer más en el módulo
Modelado e implementación de objetos DataStore avanzados (ADSO), en el curso
BW430.

2. Si se utiliza una InfoFuente de entrada delante de un InfoSitio y una InfoFuente de salida

después de un InfoSitio, la lógica de transformación debería encontrarse entre la
InfoFuente de salida del InfoSitio fuente y la InfoFuente de entrada del InfoSitio destino.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! Este uso de InfoSitios con InfoFuentes de entrada y salida se utiliza
ampliamente con diseños de LSA. Este diseño significa que solo hay asignaciones 1:1 entre
la InfoFuente de entrada y el InfoSitio, y el InfoSitio y la InfoFuente de salida. Su objetivo es
garantizar la consistencia y reducir el número de cambios de transformación cuando se
añade un nuevo InfoSitio al modelo. Leer más en el módulo Modelado e implementación
de InfoFuentes y conversiones en transformaciones, en el curso BW430.

380 © Copyright. Reservados todos los derechos.

 Capítulo 9 : Respuestas a la Evaluación de la formación

3. ¿Qué influye en la tasa de conversión para una conversión de moneda?

Seleccione las respuestas correctas.

X A La referencia de fecha para la conversión

X B El tipo de cotización

X C El lugar en el que se ejecuta la conversión de moneda

X D El usuario que ejecuta la conversión de moneda

Tienes razón. Un tipo de conversión de moneda está influenciado por la moneda de

origen, la moneda de destino, la fecha de referencia y el tipo de tipo de cambio. El lugar y
el usuario de la ejecución no tienen ningún efecto sobre el tipo de cambio. Lea más en el
módulo Modelado e implementación de InfoFuentes y conversiones en transformaciones,
en el curso BW430.

4. A partir de SAP BW/4HANA 2.0, SP 04, CompositeProviders puede contener expresiones

de filtro basadas en SQL.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! CompositeProviders puede contener expresiones de filtro basadas en SQL.

Leer más en el módulo Modelado e implementación de CompositeProviders, en el curso
BW430.

© Copyright. Reservados todos los derechos. 381

Capítulo 9 : Respuestas a la Evaluación de la formación

382 © Copyright. Reservados todos los derechos.

CAPÍTULO 10 Gestión del ciclo de vida de los
datos de SAP BW/4HANA

Lección 1
Descripción de la gestión de datos de varias temperaturas 385

Lección 2
Presentación de SAP BW/4HANA Data Tiering Optimization (DTO) 393

OBJETIVOS DEL CAPÍTULO

● Explicar la gestión de datos de temperatura múltiple en SAP BW/4HANA

● Explicar el concepto de optimización de niveles de datos de SAP BW/4HANA

© Copyright. Reservados todos los derechos. 383

Capítulo 10 : Gestión del ciclo de vida de los datos de SAP BW/4HANA

384 © Copyright. Reservados todos los derechos.

 Capítulo 10
Lección 1
Descripción de la gestión de datos de varias
temperaturas

RESUMEN DE LA LECCIÓN
En esta lección, hablamos de la necesidad de optimizar el uso de recursos de hardware de un
sistema SAP BW/4HANA. Abordamos técnicas para gestionar su almacenamiento de datos
en función de la probabilidad de que se necesite un dato específico y la frecuencia con la que
se acceda a ellos. Analizaremos los conceptos de cómo clasificar los datos y su distribución
óptima.

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Explicar la gestión de datos de temperatura múltiple en SAP BW/4HANA

Resumen de la gestión de datos de SAP BW/4HANA

Requisitos y desafíos debidos al crecimiento de los datos
Se requieren conceptos sofisticados de gestión de datos para optimizar las inversiones
financieras y el uso de los recursos de hardware de SAP BW/4HANA. SAP proporciona
conceptos y soluciones para asignar datos de SAP BW/4HANA a varias áreas de
almacenamiento y medios de almacenamiento.

© Copyright. Reservados todos los derechos. 385

Capítulo 10 : Gestión del ciclo de vida de los datos de SAP BW/4HANA

Figura 292: Requisitos para la gestión de datos optimizada

Valor de datos y relación con el tiempo

SAP ha definido el denominado concepto de almacenamiento de datos multitemperatura, que
clasifica los datos como HOT, WARM o COLD (y a veces incluso FROZEN), dependiendo de la
frecuencia de acceso y ciertos otros criterios. Estos criterios incluyen el tipo de datos
implicados, su utilidad para fines empresariales, la importancia de estos procesos, la
frecuencia de acceso, el rendimiento y los requisitos de seguridad. Entre los hechos que
influyen en la configuración de la estrategia de temperatura múltiple de SAP para almacenar
datos se incluyen:
● Restricciones financieras
● Restricciones de capacidad en su base de datos SAP HANA
● Almacenamiento de datos históricos (debido al crecimiento de los datos)
● Almacenamiento de datos en masa (datos de liquidación, logs automáticos, datos de
secuencia de clics)
● Directrices para guardar datos de la empresa, como la necesidad de guardar todos los
datos durante al menos algunos años por motivos legales

Una gran parte de los datos gestionados en un gran almacén de datos empresariales como
SAP BW/4HANA se procesa con frecuencia y se utiliza con regularidad. Este tipo de datos se
pueden considerar HOT.
Además, a menudo también hay un gran volumen de datos a los que no se accede con
frecuencia. Estos datos son raramente necesarios o nunca en procesos regulares de almacén
de datos o para análisis/planificación; por este motivo, este tipo de datos se puede definir
como WARM o COLD. El principal desafío de implementar una estrategia de memoria

386 © Copyright. Reservados todos los derechos.

 Lección: Descripción de la gestión de datos de varias temperaturas

multitemperatura es la integración fluida de las áreas de memoria WARM y COLD y hacer que
estas áreas sean visibles al exterior para que todas las funciones requeridas puedan ser
aplicadas a estos datos.

Figura 293: Valor de datos y relación con el tiempo

Concepto de gestión de datos de varias temperaturas

La siguiente ilustración proporciona un resumen de la clasificación de datos de varias
temperaturas de las diferentes categorías de datos.

Figura 294: Niveles de datos de varias temperaturas en SAP BW/4HANA

Clasificación de datos por frecuencia de acceso en tres temperaturas diferentes

Los datos de SAP BW/4HANA se clasifican por frecuencia de acceso y caso de uso en HOT,
WARM y COLD.

© Copyright. Reservados todos los derechos. 387

Capítulo 10 : Gestión del ciclo de vida de los datos de SAP BW/4HANA

HOT
● Se accede a los datos urgentes con frecuencia para la gestión de informes y la
planificación o mediante procesos habituales de SAP BW/4HANA. Entre los ejemplos se
incluyen los siguientes:
- ADSO de data mart
- ADSO estándar
● Sin restricciones funcionales

ADVERTENCIA
● A los datos cálidos se accede con menos frecuencia o rara vez. No es crítico en términos
de rendimiento y no tiene que almacenarse de forma permanente en la memoria principal.
Entre los ejemplos se incluyen los siguientes:
- Objetos en la memoria corporativa de LSA++, por lo general la puesta a disposición de
ADSO.
- Objetos en la capa Open Operational DataStore de LSA++, por lo general, la puesta a
disposición de ADSO.
● Sin restricciones funcionales

COLD
● Los datos fríos se acceden rara vez o esporádicamente. Los datos no tienen que
conservarse en la base de datos de SAP HANA; en su lugar, se almacenan y gestionan
fuera de SAP HANA en una fuente externa.
● Restricciones funcionales: se restringe a las capacidades de SAP BW/4HANA de este
denominado almacenamiento en frío (también conocido como almacenamiento nearline
en el pasado). Esto significa que está disponible para la generación de informes, pero no
para la escritura, y las expectativas sobre el rendimiento deben ser mucho más bajas.

388 © Copyright. Reservados todos los derechos.

 Lección: Descripción de la gestión de datos de varias temperaturas

Figura 295: Gestión de datos de varias temperaturas en contexto de arquitectura SAP EDW (LSA++)

En el contexto de la arquitectura de referencia de SAP BW/4HANA para el almacenamiento

de datos (arquitectura escalable en capas para BW/4HANA o LSA++), las diferentes áreas de
un almacén de datos y las diferentes capas de la arquitectura EDW se pueden asignar a estas
categorías de datos de varias temperaturas.
● CÓMO: Todas las capas relacionadas con el análisis y la planificación de negocio críticos
para la misión diaria
● ADVERTENCIA: Todas las capas relacionadas con la adquisición de datos
● COLD: Todas las capas relacionadas con la recopilación de datos históricos

Solución técnica para implementar el concepto de gestión de datos de varias temperaturas

en SAP BW/4HANA
Para implementar una gestión de datos de varias temperaturas en SAP BW/4HANA (también
conocido como Data Tiering), SAP proporciona el concepto de Data Tiering Optimization
(DTO).

© Copyright. Reservados todos los derechos. 389

Capítulo 10 : Gestión del ciclo de vida de los datos de SAP BW/4HANA

Figura 296: Niveles de datos de varias temperaturas en el concepto de Data Tiering Optimization (DTO) de SAP
BW/4HANA

Los conceptos técnicos de SAP BW/4HANA para gestionar los diferentes niveles de datos
son:
● HOT: los datos se gestionan completamente en la memoria de SAP HANA.
● ADVERTENCIA:
- Nodo ampliado de SAP HANA: Nodos de trabajador aprovisionados en exceso con
dimensionamiento relajado de memoria/CPU en una arquitectura de escalabilidad
horizontal.
- SAP HANA Native Storage Extension (NSE): solución de gestión de almacenamiento
universal mejorada en SAP HANA adecuada para arquitecturas de escalabilidad.
● COLD
- Almacenamiento externo de SAP IQ: los datos se gestionan fuera de SAP HANA en una
base de datos de SAP IQ.

Soluciones técnicas adicionales para otros productos de SAP

SAP proporciona soluciones técnicas adicionales para la gestión de datos de SAP HANA en
otros productos de SAP. En aras de la integridad, a continuación encontrará un breve
resumen:
● SAP BW en cualquier BD

1. Almacenamiento nearline SAP BW (NLS)

2. Soluciones de socio para SAP BW NLS

● SAP BW powered by SAP HANA

1. Almacenamiento nearline SAP BW (NLS)

2. Soluciones de socio para SAP BW NLS

3. Clasificación dinámica: nodo dedicado de procesamiento de discos con datos tibios

dentro de SAP HANA
● Aplicaciones nativas de SAP HANA

390 © Copyright. Reservados todos los derechos.

 Lección: Descripción de la gestión de datos de varias temperaturas

- Clasificación dinámica: nodo dedicado de procesamiento de discos con datos tibios

dentro de SAP HANA
● SAP Business Suite en SAP HANA
- Atributos de paginación: nodo in-memory de HANA con datos de acceso frecuente (por
partición) parcialmente paginados en el disco
● SAP S/4HANA
- Clasificación dinámica: nodo dedicado de procesamiento de discos con datos tibios
dentro de SAP HANA

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Explicar la gestión de datos de temperatura múltiple en SAP BW/4HANA

© Copyright. Reservados todos los derechos. 391

Capítulo 10 : Gestión del ciclo de vida de los datos de SAP BW/4HANA

392 © Copyright. Reservados todos los derechos.

 Capítulo 10
Lección 2
Presentación de SAP BW/4HANA Data Tiering
Optimization (DTO)

RESUMEN DE LA LECCIÓN
En esta lección se describe Data Tiering Optimization (DTO) en SAP BW/4HANA.

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Explicar el concepto de optimización de niveles de datos de SAP BW/4HANA

Optimización de niveles de datos (DTO) de SAP BW/4HANA

Introducción a Data Tiering Optimization en SAP BW/4HANA

Figura 297: Resumen de SAP BW/4HANA Data Tiering Optimization (DTO)

© Copyright. Reservados todos los derechos. 393

Capítulo 10 : Gestión del ciclo de vida de los datos de SAP BW/4HANA

Figura 298: Conceptos técnicos detrás de SAP BW/4HANA Data Tiering Optimization (DTO)

Data Tiering Optimization (DTO) para SAP BW/4HANA le ayuda a clasificar los datos en su
objeto DataStore avanzado como HOT, WARM o COLD. Dependiendo de esta clasificación y
de cómo se utilizan los datos, los datos se almacenan en diferentes áreas de
almacenamiento. En SAP BW/4HANA, dispone de las siguientes opciones:

1. Nivel estándar (HOT): Los datos se almacenan en la memoria principal de SAP HANA.

2. Nivel de extensión (WARM): Según la arquitectura de hardware (scale-out o scale-up), los

datos se almacenan en un nodo de extensión de SAP HANA o en SAP HANA Native
Storage Extension (NSE).

3. Nivel externo (COLD): Los datos se almacenan en un sistema externo, ya sea una base de
datos SAP IQ o un clúster de archivos Hadoop.

En SAP BW/4HANA DTO, el nivel estándar (HOT) y el nivel de extensión (WARM) crean una
unidad lógica dentro de la plataforma SAP HANA. Los SLA definidos para la recuperación de
datos y la disponibilidad de datos se aplican por igual. Los datos COLD se encuentran en el
llamado nivel externo. Se gestiona por separado fuera de SAP HANA. Es posible que se
requieran medidas adicionales necesarias para la seguridad y la disponibilidad de los datos.

Configuración de la optimización del nivel de datos en las herramientas de modelado de

SAP BW/4HANA
En SAP BW/4HANA, el objeto DataStore avanzado (ADSO) es el único modelo de datos que
gestiona físicamente los datos transaccionales. En consecuencia, es en los ADSO donde
configura todos los parámetros DTO relevantes. El proceso de Customizing tiene dos tareas
principales:

1. Definir niveles DTO y particiones en las herramientas de modelado de SAP BW/4HANA

para cada ADSO (Customizing relevante para la conexión de transporte).

2. Defina la temperatura de cada partición en el ADSO en el cockpit DTO (a definir

manualmente en cada sistema, sin conexión de transporte).

394 © Copyright. Reservados todos los derechos.

 Lección: Presentación de SAP BW/4HANA Data Tiering Optimization (DTO)

Figura 299: Configuración de temperaturas de SAP BW/4HANA para ADSO

En la edición de ADSO dentro de las herramientas de modelado de BW en Eclipse, en la

pestaña General, especifique las propiedades de clasificación de datos de la siguiente
manera:
● Niveles (temperaturas) dentro del alcance de este objeto
● Actualización de las temperaturas a nivel de objeto o de partición

© Copyright. Reservados todos los derechos. 395

Capítulo 10 : Gestión del ciclo de vida de los datos de SAP BW/4HANA

Figura 300: Configuración de particiones relacionadas para ADSO

Si ha seleccionado Actualización de datos a nivel de partición, el ADSO requiere la definición

de particiones. En la pantalla Edición ADSO, vaya a la pestaña Opciones para configurar un
número adecuado de particiones para gestionar los datos en diferentes niveles. Tenga en
cuenta que los campos de partición deben definirse como campos clave en su definición de
ADSO. Los campos de partición recomendados son características de tiempo estándar de
SAP (por ejemplo, 0CALMONTH, 0CALYEAR, 0FISCPER, 0FISCYEAR) u objetos que
representan unidades organizativas. Si las definiciones de partición se modifican en un
momento posterior (especialmente cuando el ADSO ya está gestionando datos), el sistema
verifica si es necesario remodelar cuando activa el objeto. Si el remodelado es necesario, se
crea automáticamente un job de remodelado, que debe iniciarse manualmente después.

396 © Copyright. Reservados todos los derechos.

 Lección: Presentación de SAP BW/4HANA Data Tiering Optimization (DTO)

Definición y ejecución de la optimización de niveles de datos en el cockpit de SAP GUI o

BW/4HANA

Figura 301: SAP BW/4HANA Data Tiering Optimization: tiempo de diseño — Definir temperaturas planificadas

La siguiente tarea es definir la temperatura planificada de cada ADSO o cada partición de un

ADSO. SAP BW/4HANA proporciona dos IU para todas las actividades siguientes:

1. SAP GUI: Cockpit DTP: Transacción RSOADSODTO, disponible en SAP BW/4HANA 1.0
SP04

2. Cockpit de SAP BW/4HANA: aplicación para objetos DataStore - Gestionar niveles de

datos, disponible en SAP BW/4HANA 2.0

Ambas IU proporcionan todas las funciones necesarias para definir la temperatura para las
particiones ADSO o, dependiendo de la configuración general, para todo el ADSO, y para
ejecutar el desplazamiento de datos.

Nota:
La información real sobre qué datos se almacenan a qué temperatura se
especifica en una definición de metadatos separada solo en el sistema local; no es
una propiedad de transporte como las otras propiedades ADSO de modelado.

Procedimiento:

1. Defina la columna Temperatura planificada para cada entrada en el cockpit.

2. Grabe estas modificaciones.

© Copyright. Reservados todos los derechos. 397

Capítulo 10 : Gestión del ciclo de vida de los datos de SAP BW/4HANA

3. Seleccione Mostrar pool de trabajo para visualizar solo las particiones que se han
modificado.

4. Seleccione Verificar niveles de datos para verificar si las temperaturas seleccionadas son
técnicamente posibles.

5. Seleccione Simular para simular los efectos de modificar la temperatura.

6. Seleccione Ejecutar para ejecutar la modificación de temperatura para las particiones

seleccionadas como job de fondo. El sistema genera un log de sus modificaciones.

Nota:
Como alternativa, puede ejecutar y planificar jobs DTO en BW/4HANA Data
Warehousing Workbench → Administración → Mantenimiento → Ejecución
DTO, o simplemente llamar la transacción RSOADSODTOEXE o configurar una
cadena de procesos basada en elAdjust Data Tiering nuevo tipo de
variante.

SAP BW/4HANA Data Tiering Optimization: Tiempo de ejecución — Ejecución de la

distribución de datos

Figura 302: SAP BW/4HANA Data Tiering Optimization: Tiempo de ejecución — Ejecución de la distribución de
datos

Además de la definición manual de la temperatura de una partición u objeto, también puede

definir reglas de modificación de temperatura para objetos seleccionados. Se pueden definir
reglas para ADSOs con niveles a nivel de partición y con una característica de tiempo de SAP
o un campo de tipo de datos DATS como campo de partición. En la regla, a partir de la fecha
actual, puede especificar una condición basada en tiempo relativa para las diferentes
temperaturas posibles. Puede especificar la temperatura cálida para los datos que superan el
año de antigüedad, por ejemplo, y los datos de más de cinco años de antigüedad son poco
interesantes.
Cada vez que se inicia el cambio de temperatura para ADSOs con una regla utilizando el job
DTO, la regla se evalúa primero. Esto determina la nueva temperatura objetivo. El método de

398 © Copyright. Reservados todos los derechos.

 Lección: Presentación de SAP BW/4HANA Data Tiering Optimization (DTO)

determinación es el siguiente: Para particiones cuyo límite superior se corresponde con la

condición en la regla, se fija la temperatura objetivo seleccionada en la condición. Si, por
ejemplo, el límite superior de una partición tiene más de un año de antigüedad y ha definido
en su regla que todos los datos de más de un año de antigüedad se deben mover al almacén
cálido, la temperatura objetivo se fija en caliente para esta partición. Tenga en cuenta que la
evaluación de la regla solo tiene en cuenta los límites de intervalo. Los datos que realmente
están almacenados en la partición se ignoran. Las particiones siempre se mueven en su
totalidad. En el caso de particiones que consisten en un solo valor individual (EQUAL), este
valor es el valor superior. El traslado real se realiza con el job DTO.
Tenga en cuenta las siguientes restricciones para trabajar con reglas de modificación de
temperatura:
● Si activa una regla para un ADSO y luego especifica la modificación de temperatura
manualmente para una o varias particiones del objeto, la regla se desactivará para todo el
objeto.
● No se permiten huecos en los cambios de temperatura basados en reglas, ya que las
condiciones especificadas en la regla no pueden tener un límite inferior.
● Estas reglas se han introducido con SAP BW/4HANA 2.0 SP04.

El nivel DTO WARM

Nivel DTO WARM para sistemas de múltiples nodos (scale-out):Nodos de extensión de SAP
HANA
El nivel de acceso frecuente gestionado por los nodos de extensión de SAP HANA requiere
una arquitectura de infraestructura de SAP BW/4HANA basada en un escalado de los
llamados nodos coordinadores y diferentes nodos de trabajador. Configurar uno (o varios)
nodos de trabajador como nodos de extensión significa ejecutar una infraestructura de
escalabilidad asimétrica de SAP HANA. Esto incluye un grupo de nodos de trabajador (para
sus datos activos) con dimensionamiento de memoria/volumen de datos estándar y otro
grupo con un dimensionamiento relajado para almacenar más datos en estos nodos de
extensión.

1. Para datos HOT: nodo de SAP HANA con dimensionamiento estándar -

Las directrices de dimensionamiento del hardware de SAP HANA recomiendan una
relación 2:1 entre la memoria principal disponible y el volumen de datos guardados. Esto
significa una huella de datos de aproximadamente el 50% de la memoria principal
disponible. Esto garantiza que todos los datos se puedan almacenar en la memoria
principal en cualquier momento y que haya suficiente espacio para el procesamiento
inmediato de datos y los conjuntos de resultados temporales.

2. Para datos WARM: nodo SAP HANA con dimensionamiento menos estricto (también
conocido como nodo de extensión) -
Las directrices de dimensionamiento se pueden definir de forma menos estricta para los
datos de acceso frecuente. Esto significa una huella de datos de hasta el 200% de la
memoria principal disponible o una asignación de datos que duplica el tamaño de la
memoria principal disponible. Las consideraciones a la hora de definir nodos de extensión
incluyen:

● Se accede a datos interesantes con menos frecuencia.

© Copyright. Reservados todos los derechos. 399

Capítulo 10 : Gestión del ciclo de vida de los datos de SAP BW/4HANA

● Cuando se accede a los datos de acceso frecuente, se aplican acuerdos sobre el nivel
de servicio más bajos con respecto al rendimiento.

● Se requieren menos procesos intensivos de CPU para acceder a los datos de acceso
frecuente.

● Solo se accede simultáneamente a partes de los datos de acceso frecuente.

La configuración de nodos de extensión de SAP HANA le permite ejecutar una infraestructura

de escalabilidad horizontal de HANA con menos nodos y menos memoria principal para el
mismo volumen de datos. Otra ventaja de esta configuración es que todos los servicios de
SAP HANA relacionados con las operaciones, las actualizaciones y la gestión de datos están
disponibles listos para usar. Además, los datos se pueden diferenciar fácilmente en activos e
interesantes en la aplicación BW/4HANA, utilizando las técnicas estándar de SAP HANA para
reubicar los datos entre nodos.
Los datos, que se generan en la capa de adquisición y en la memoria corporativa,
normalmente se consideran menos críticos para la misión, es decir, como WARM. Según el
concepto DTO de SAP BW/4HANA, el contenido de los objetos DataStore en estas áreas
puede ser al menos parcialmente almacenado en los nodos de extensión de SAP HANA. Estos
presentan un área para datos WARM con menos prioridad para los procesos de almacén de
datos a un costo general más bajo pero sin restricciones funcionales.

Nivel DTO WARM para sistemas de nodo único (ampliación): SAP HANA Native Storage
Extension (NSE)
A partir de SAP BW/4HANA 2.0 SP04, SAP HANA NSE proporciona un nuevo enfoque para
gestionar el nivel de acceso frecuente en un único sistema de nodos sin la necesidad de
cambiar a una arquitectura de escalabilidad según sea necesario para el concepto de nodos
ampliados de SAP HANA.
SAP HANA NSE es una extensión basada en disco para el ALMACÉN DE COLUMNA in-
memory dentro de SAP HANA. En lugar de cargar una columna completa, solo las páginas
necesarias se cargan en la caché de memoria intermedia al acceder a los datos. SAP HANA
NSE es una solución de gestión de almacenamiento universal para datos de acceso frecuente
para SAP BW/4HANA, SAP S/4HANA y SAP Business Suite powered by SAP HANA. Está
integrado con SAP HANA y le permite gestionar datos a los que no es necesario acceder con
frecuencia, sin tener que cargarlos completamente en la memoria de SAP HANA. Si SAP
HANA NSE se utiliza o no en SAP BW/4HANA para el nivel de datos templados se decide a
nivel de sistema:
● SAP HANA NSE se utiliza automáticamente como nivel de datos para datos de acceso
frecuente si no hay nodos de extensión de SAP HANA configurados para el sistema y la
infraestructura es una infraestructura de un solo nodo en lugar de una infraestructura de
escalabilidad horizontal.
● En todos los demás casos, los nodos de ampliación de SAP HANA se utilizan como área de
almacenamiento para datos de acceso frecuente (si existe algún nodo de ampliación) o no
hay ningún área de almacenamiento para los datos de acceso frecuente.

Desde el punto de vista de la aplicación, SAP BW_BU4HANA DTO se gestiona de la misma

manera, independientemente de cuál de los dos conceptos se utiliza para los datos de acceso
frecuente. Por lo tanto, durante el modelado, defina las propiedades de clasificación de datos
de ADSO como utilizando previamente las temperaturas que se deben soportar. En un
momento posterior, puede especificar la temperatura para todo el objeto o para particiones
individuales y, a continuación, modificar la temperatura mediante un job DTO.

400 © Copyright. Reservados todos los derechos.

 Lección: Presentación de SAP BW/4HANA Data Tiering Optimization (DTO)

El nivel DTO COLD

Almacenamiento externo
Los datos DTO poco interesantes se mueven primero a un almacenamiento externo y, a
continuación, se borran del sistema SAP BW/4HANA (es decir, de la base de datos SAP
HANA). Para esta actividad se utiliza el proceso BW estándar de Borrado selectivo. Aún es
posible acceder a los datos directamente (por ejemplo, con consultas BW) o volver a
cargarlos en los niveles WARM o HOT si es necesario.
El conjunto de datos total de un ADSO se refleja consistentemente de la siguiente manera:
Todos los datos en particiones ADSO en la memoria HANA (HOT) + todos los datos en
particiones ADSO en nodos ampliados HANA (WARM) + todos los datos en particiones ADSO
en almacenamiento externo (COLD)
En SAP BW/4HANA, el nivel COLD está disponible para todos los datos gestionados en
ADSOs. Sin embargo, es un requisito definir particiones dentro del ADSO. Se aplican las
siguientes restricciones:
● En general, el ADSO debe tener al menos un campo clave y las particiones deben definirse
en uno de los campos clave. Esta llamada partición RANGE definida por el usuario se
combina con la partición HASH para algunos casos de uso. Consulte más detalles en la
nota SAP 2985173.
● Los ADSO del tipo Actualización directa requieren SAP BW/4HANA 2.0 SP07 o superior
para gestionar sus datos en el nivel COLD.
● El nivel COLD no está disponible para ADSOs con las siguientes propiedades de modelado:
- Objeto DataStore de staging: Solo cola de entrada
- Objeto DataStore de staging — Reporting habilitado

Los datos inactivos permanecen disponibles en cualquier momento para todos los demás
procesos en SAP BW, para los accesos de lectura y también para los procesos ETL o
búsquedas individuales. Los informes de gestión, que analizan datos a lo largo de períodos de
tiempo más largos y, por lo tanto, inevitablemente también incluyen datos poco interesantes,
se dividen. Aprovienen datos tanto de la base de datos de SAP HANA como del
almacenamiento externo. El proceso de eliminación en sí es complejo y debe cumplir con los
requisitos transaccionales. SAP BW/4HANA proporciona control de todo el proceso.
Finalmente, en el caso del almacenamiento externo, debe garantizarse la consistencia de
todo el pool de datos en todo momento, incluso si el pool se divide en dos partes inconexas.

Nivel COLD basado en SAP IQ

SAP BW/4HANA viene con el adaptador para la base de datos de SAP IQ como un medio de
almacenamiento externo. Los datos de SAP IQ se almacenan en un almacenamiento en
columnas en una forma comprimida similar a SAP HANA, con la gran diferencia de que los
datos no se gestionan en memoria, sino que se procesan en disco.
Algunas de las características clave de SAP IQ como almacenamiento externo para DTO son:
● Rendimiento de carga optimizado basado en la funcionalidad de cargador de SAP IQ y el
acceso inteligente a datos de SAP HANA.
● SAP HANA y SAP IQ comparten el mismo paradigma columnar.
● La compresión de datos es muy eficiente en aproximadamente el 90%.

© Copyright. Reservados todos los derechos. 401

Capítulo 10 : Gestión del ciclo de vida de los datos de SAP BW/4HANA

● Gestión más estricta: SAP BW/4HANA Cold Store en SAP IQ proporciona la capacidad de
procesar actualizaciones y eliminaciones excepcionales de los datos inactivos

Manejo más estricto

Figura 303: Actualizaciones excepcionales de los datos COLD basados en SAP IQ ("Gestión más estricta")

A partir de SAP BW/4HANA 2.0 SP07, SAP proporciona un proceso de activación ampliado
que detecta y gestiona modificaciones excepcionales de datos en las ubicaciones de tienda
DTO COLD. Esta función tiene las siguientes características:
● Esta función avanzada proporciona la capacidad de procesar sentencias SQL UPDATE /
INSERT / DELETE en el almacén DTO COLD.
● El proceso de activación ADSO detecta y gestiona estas modificaciones excepcionales en
los datos en el almacén DTO COLD. En el back end de SAP BW/4HANA, el ADSO gestiona
una tabla de entrada secundaria adicional que almacena las modificaciones en las
particiones COLD.
● En general, necesita un ADSO estándar del tipo "con log de modificaciones" y la propiedad
de modelado correspondiente Excepción Actualizaciones en almacén de datos inactivos
para habilitar este tratamiento de actualización.
● La función está limitada a la base de datos de SAP IQ como la ubicación del almacén DTO
COLD.
● Para obtener más detalles, consulte la nota SAP 2865304 (Actualizaciones excepcionales
para almacenes en frío en SAP BW/4HANA 2.0 Optimización de clasificación de datos).

Nivel COLD basado en Hadoop

402 © Copyright. Reservados todos los derechos.

 Lección: Presentación de SAP BW/4HANA Data Tiering Optimization (DTO)

A partir de SAP BW/4HANA 1.0 SP08, es posible configurar un clúster de archivos Hadoop
(HDFS) como almacenamiento en frío. Allí puede almacenar datos con los formatos
TEXTFILE, ORC y PARQUET. Con el formato TEXTFILE, los archivos CSV no comprimidos se
guardan en HDFS.
Para verificar si los archivos han llegado a Hadoop, puede usar el explorador del sistema de
archivos Hadoop (informeRSDA_HDP_BROWSE_HDFS). Además, obtiene información sobre los
metadatos de los archivos y su estructura. Si desea borrar datos físicamente, puede utilizar el
reportRSDA_CLEANUP_ARCHIVE o programar una cadena de procesos con la
varianteCleanup Cold Store.
El rendimiento de acceso para este método de almacenamiento y gestión de datos externos
es considerablemente menor en comparación con SAP IQ. Por este motivo, este nivel a veces
se denomina FROZEN. Por otro lado, el TCO no es necesariamente menor en comparación
con SAP IQ, por lo que la recomendación general es aprovechar el nivel frío con SAP IQ en
lugar de en Hadoop.

Nota:
SAP recomienda aprovechar SAP IQ para almacenar datos fríos en el contexto
de DTO. Se puede seguir utilizando Hadoop (con las restricciones mencionadas
en la nota SAP 2363218: Hadoop NLS - Información, recomendaciones y
limitaciones), pero no es la solución recomendada en adelante.

Gestión de acceso de informes a datos poco interesantes

Figura 304: Activar y desactivar datos almacenados externamente para reporting a nivel de InfoSitio o a nivel de
consulta

© Copyright. Reservados todos los derechos. 403

Capítulo 10 : Gestión del ciclo de vida de los datos de SAP BW/4HANA

Hay opciones disponibles para controlar el acceso de informes a los datos COLD:
● Configuración general a nivel de CompositeProvider: Propiedades comunes de tiempo de
ejecución → Acceso a almacén frío: Activar/Desactivar
● Parametrización individual a nivel de query BW: Propiedades ampliadas → Acceso a
almacén frío (nearline): active/desactive o lea la configuración del proveedor compuesto

404 © Copyright. Reservados todos los derechos.

 Lección: Presentación de SAP BW/4HANA Data Tiering Optimization (DTO)

Nota:
Para obtener más detalles, consulte las siguientes fuentes:
Resumen general
● Blog de SAP PM Gordon Witzel: SAP BW/4HANA Data Tiering Optimization
https://blogs.sap.com/2018/01/03/sap-bw4hana-data-tiering-
optimization/?preview_id=586084
● Ayuda de SAP BW/4HANA: resumen de clasificación de datos https://
help.sap.com/viewer/107a6e8a38b74ede94c833ca3b7b6f51/2.0.4/en-US/
4a2e3fa51c450451e10000000a421937.html
● Optimización de niveles de datos en SAP BW/4HANA https://www.sap.com/
documents/2017/12/b8ff485c-e47c-0010-82c7-eda71af511fa.html
● Nota de SAP 2517460: SAP BW/4HANA Optimización de clasificación de
datos: información, recomendaciones y limitaciones
● Nota SAP 2985173: Optimización de niveles de datos (DTO) y partición

Almacén WARM basado en SAP HANA Native Storage Extension (NSE)

● Ayuda de SAP: SAP HANA Extension Node as a Warm Store https://
help.sap.com/viewer/107a6e8a38b74ede94c833ca3b7b6f51/2.0.8/en-US/
004655ec72c64b4090d272a11346f2f3.html
● Ampliación de almacenamiento nativo de documento informativo https://
www.sap.com/documents/2019/09/4475a0dd-637d-0010-87a3-
c30de2ffd8ff.html
● Nota SAP 2799997: Preguntas frecuentes sobre la extensión de
almacenamiento nativo de SAP HANA (NSE)
● Nota SAP 2347382: Información general de SAP BW/4HANA para NSE
● Ayuda de SAP: SAP HANA Native Storage Extension como tienda virtual
https://help.sap.com/viewer/
107a6e8a38b74ede94c833ca3b7b6f51/2.0.8/en-US/
a9493e2172294f72847e2293aeeb14cd.html
● Guía de administración de SAP HANA: extensión de almacenamiento nativo de
SAP HANA https://help.sap.com/viewer/

© Copyright. Reservados todos los derechos. 405

Capítulo 10 : Gestión del ciclo de vida de los datos de SAP BW/4HANA

6b94445c94ae495c83a19646e7c3fd56/2.0.04/en-US/
4efaa94f8057425c8c7021da6fc2ddf5.html
● Nota SAP 2816823: Uso de SAP HANA Native Storage Extension en SAP S/
4HANA y SAP Business Suite
● Nota SAP 2927591: SAP HANA Native Storage Extension 2.0 SPS 05
Restricciones funcionales
● Nota SAP 2771956: SAP HANA Native Storage Extension 2.0 SPS 04
Restricciones funcionales

Almacén WARM basado en nodo de extensión de SAP HANA

● SAP BW con nodo de ampliación HANA https://www.sap.com/documents/
2017/05/ac051285-bc7c-0010-82c7-eda71af511fa.html
● Resumen técnico de nodo de ampliación https://www.sap.com/documents/
2018/06/1e103233-0d7d-0010-87a3-c30de2ffd8ff.html
● Blog: Detalles – HANA Extension Nodes https://blogs.sap.com/2016/04/26/
more-details-hana-extension-nodes-for-bw-on-hana/
● Nota SAP 2486706: Preguntas frecuentes sobre SAP BW/4HANA con nodos
de extensión
● Nota SAP 2644438: Nodo de ampliación de SAP HANA - Nota de release
maestra
● Nota SAP 2363218: Información, recomendaciones y limitaciones de Hadoop
NLS

Almacenamiento COLD basado en la base de datos de SAP IQ

● Blog de Roland Kramer: Solución SAP-NLS (también aplicable para
almacenamiento en frío DTO) para SAP BW (todas las versiones) https://
blogs.sap.com/2016/10/12/sap-nls-solution-sap-bw/
● Primera orientación de SAP BW NLS con SAP IQ y SDAhttps://www.sap.com/
documents/2013/03/d2ff3a4c-577c-0010-82c7-eda71af511fa.html
● Nota SAP 2865304: Actualizaciones excepcionales a almacenes en frío en SAP
BW/4HANA 2.0 Optimización de clasificación de datos
● Nota SAP 1796393: solución nearline de SAP BW con SAP IQ
● Nota SAP 2165650: Preguntas frecuentes Almacenamiento nearline BW con
HANA Smart Data Access
● Ayuda de SAP: Configuración de SAP IQ como una tienda fría https://
help.sap.com/viewer/107a6e8a38b74ede94c833ca3b7b6f51/2.0.8/en-US/
e8395401e46f4edca50aefeead7f3a44.html

Almacén COLD basado en Hadoop

● Nota SAP 2363218: Hadoop NLS - Información, recomendaciones y
limitaciones

406 © Copyright. Reservados todos los derechos.

 Lección: Presentación de SAP BW/4HANA Data Tiering Optimization (DTO)

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Explicar el concepto de optimización de niveles de datos de SAP BW/4HANA

© Copyright. Reservados todos los derechos. 407

Capítulo 10 : Gestión del ciclo de vida de los datos de SAP BW/4HANA

408 © Copyright. Reservados todos los derechos.

 Capítulo 10

Evaluación de la formación

1. SAP agrupa los datos en HOT, WARM y COLD para organizarlos para Data Lifecycle
Management. Con respecto a SAP BW/4HANA, es un concepto central que los datos HOT
y WARM se gestionan en la misma plataforma SAP HANA, mientras que los datos COLD
se gestionan externamente.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

2. Desea implementar un concepto de optimización de niveles de datos para un objeto

DataStore (avanzado) que contenga datos de varios años.
Poner en el orden correcto

0 Defina particiones ADSO en el InfoObjeto que representa el año natural.

0 Defina la temperatura planificada para cada una de las particiones.

0 Programe un job que ejecute el desplazamiento de datos.

0 Defina los niveles ADSO en los que desea gestionar los datos.

© Copyright. Reservados todos los derechos. 409

 Capítulo 10

Respuestas a la Evaluación de la formación

1. SAP agrupa los datos en HOT, WARM y COLD para organizarlos para Data Lifecycle
Management. Con respecto a SAP BW/4HANA, es un concepto central que los datos HOT
y WARM se gestionan en la misma plataforma SAP HANA, mientras que los datos COLD
se gestionan externamente.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

Correcto. Los datos HOT se gestionan en la memoria estándar de SAP HANA y los datos
WARM se gestionan en un nodo ampliado de SAP HANA (sistemas de escalabilidad
horizontal) o en extensiones de almacenamiento nativo de SAP HANA (sistemas de
escalabilidad) en la misma plataforma SAP HANA. Sin embargo, los datos COLD se
mueven a una base de datos externa de SAP IQ o a un clúster de ficheros Hadoop.

2. Desea implementar un concepto de optimización de niveles de datos para un objeto

DataStore (avanzado) que contenga datos de varios años.
Poner en el orden correcto

1 Defina particiones ADSO en el InfoObjeto que representa el año natural.

3 Defina la temperatura planificada para cada una de las particiones.

4 Programe un job que ejecute el desplazamiento de datos.

2 Defina los niveles ADSO en los que desea gestionar los datos.

Correcto. La secuencia correcta es la siguiente: 1) Defina las particiones ADSO en el

InfoObjeto que representa el año natural. 2) Defina los niveles de ADSO en los que desea
gestionar los datos. 3) Defina la temperatura planificada para cada una de las particiones.
4) Programe un job que ejecute el desplazamiento de datos.

410 © Copyright. Reservados todos los derechos.

CAPÍTULO 11 Implementación de vistas
nativas de SAP HANA

Lección 1
Introducción a SAP Web IDE para SAP HANA 413

Lección 2
Modelado de datos maestros en vistas SAP HANA 419

Lección 3
Modelado de datos transaccionales en vistas de SAP HANA 431

Lección 4
Diferencias entre SAP HANA 1.0 y SAP HANA 2.0 445

OBJETIVOS DEL CAPÍTULO

● Explore SAP Web IDE para SAP HANA

● Crear vistas SAP HANA con jerarquías
● Crear vistas SAP HANA con indicadores
● Explicar las diferencias entre SAP HANA 1.0 y SAP HANA 2.0

© Copyright. Reservados todos los derechos. 411

Capítulo 11 : Implementación de vistas nativas de SAP HANA

412 © Copyright. Reservados todos los derechos.

 Capítulo 11
Lección 1
Introducción a SAP Web IDE para SAP HANA

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Explore SAP Web IDE para SAP HANA

Configuración y modelado en SAP Web IDE para SAP HANA

Como se mencionó en la tercera unidad, SAP proporciona diferentes herramientas para
gestionar la plataforma SAP HANA:

1. SAP HANA Studio proporciona una interfaz basada en el framework de código abierto de
Eclipse. Es una instalación integral del cliente que es la interfaz de usuario estratégica
para el modelado en SAP BW/4HANA (herramientas de modelado de SAP BW, BWMT) o
desarrollo ABAP en SAP BW/4HANA o SAP S/4HANA local (herramientas de desarrollo
ABAP, ADT). SAP HANA Studio también se puede utilizar para el mantenimiento de la
base de datos y el modelado de HANA, pero usarlo para ese fin significa trabajar en el
marco XS ahora obsoleto. Los clientes siguen utilizando SAP HANA Studio, pero SAP
recomienda cambiar al concepto de XS Advanced y al SAP Web IDE relacionado para SAP
HANA.

2. El workbench de desarrollo basado en web de SAP HANA proporciona una interfaz basada
en la web para crear y probar artefactos de desarrollo en el entorno de SAP HANA. Se
introdujo con SAP HANA 1.0 y hace referencia a SAP HANA Extended Application Services
obsoletos (SAP HANA XS, también conocido como SAP HANA XS clásico). Nunca alcanzó
el alcance funcional de SAP HANA Studio y nunca estuvo ampliamente en uso.

3. SAP Web IDE para SAP HANA es un nuevo entorno de desarrollo integrado (IDE) basado
en navegador y es la herramienta recomendada para el modelado nativo de SAP HANA y
la administración de base de datos. Se introdujo con SAP HANA 2.0 y hace referencia a
SAP HANA Extended Application Services Advanced (SAP HANA XSA) de última
generación. Es la sucesora de las IU mencionadas aquí en las posiciones 1 y 2. Recibirá
actualizaciones regulares en el futuro.

En esta formación BW430, seguimos la recomendación de SAP y utilizamos SAP Web IDE
para SAP HANA para gestionar la base de datos de SAP HANA y utilizar sus datos para el
modelado nativo de SAP HANA.

Módulos de desarrollo
Activación de vistas de información

© Copyright. Reservados todos los derechos. 413

Capítulo 11 : Implementación de vistas nativas de SAP HANA

Figura 305: Infraestructura de despliegue de SAP HANA 2.0 (HDI)

Cuando crea o modifica una vista de cálculo con Web IDE para SAP HANA, trabaja en un
objeto de tiempo de diseño, que es un archivo ubicado en un módulo de base de datos HANA
(HDB) del proyecto actual. El proyecto puede contener varios módulos. Un módulo contiene
archivos del área de trabajo del desarrollador. Cada archivo normalmente contiene la
definición de un artefacto de base de datos, como una vista de cálculo.
Para utilizar la vista SAP HANA, debe crear (desplegar) el fichero de tiempo de diseño de la
vista de cálculo HDI (categoría de datos Dimensión) para generar un objeto de tiempo de
ejecución.
Seleccione "Estructurar" para uno o varios objetos de tiempo de diseño o para todo el
módulo. A continuación, se verifican las dependencias entre estos objetos, se realizan
verificaciones de sintaxis y se crean objetos en tiempo de ejecución. Una vista de cálculo se
despliega como una vista de columna. Para cada módulo, el sistema crea un contenedor HDI
dedicado que es básicamente un esquema de base de datos aislado.
Para comenzar con el modelado, primero debe crear un proyecto. En su proyecto, creará un
módulo. Para cada tipo de objeto de desarrollo, SAP proporciona una serie de módulos. Los
modeladores normalmente solo funcionan con módulos HDB (base de datos HANA). Dentro
de un módulo se desarrollan archivos de origen del tipo asociado al módulo. Por ejemplo, en
un módulo HDB se crean artefactos de base de datos.
Cuando se crea el módulo, puede añadir carpetas y subcarpetas adicionales para
proporcionar una mejor organización del contenido.
Para crear los distintos artefactos de desarrollo y archivos de origen, haga clic con el botón
derecho en una carpeta del proyecto y seleccione el tipo de archivo que desea crear en el
menú contextual.
Por ejemplo, si fuera modelador, trabajaría en un módulo HDB y crearía los siguientes
artefactos de base de datos:
● Procedimiento
● Función
● Vista de cálculo
● Diagrama de flujo

414 © Copyright. Reservados todos los derechos.

 Lección: Introducción a SAP Web IDE para SAP HANA

● Autorización de análisis
● Artefacto CDS
● Diccionarios de análisis de texto y conjuntos de reglas

También puede importar artefactos individuales a las carpetas del proyecto mediante la
opción de menú Importar. Incluso puede importar un proyecto completo a su área de trabajo.

Nota:
Dado que los proyectos normalmente serán trabajados por varios
desarrolladores, se recomienda el uso de Git para documentar y gestionar las
versiones de código fuente y esta herramienta se admite e integra completamente
en SAP Web IDE para SAP HANA. Un desarrollador simplemente clona el proyecto
actual del repositorio Git compartido en su área de trabajo Web IDE. Cuando
terminan con el desarrollo, confirman sus objetos fuente de nuevo en el
repositorio Git compartido con notas para describir lo que han cambiado.

El desarrollo en SAP Web IDE para SAP HANA está completamente basado en archivos, lo
que significa que cada artefacto de origen es un archivo simple (identificado con una
extensión) que es fácil de exportar e importar dentro de y también a través de SAP HANA.
Cada archivo que cree tiene su propia extensión, como .hdbfunction o .hdbcalculationview, lo
que facilita la identificación de su tipo. También es así como el IDE sabe qué editor abrir para
cada tipo de artefacto. Determinados tipos de archivos se pueden abrir solo en un editor de
texto o en un editor gráfico. Algunos tipos de archivos se pueden abrir en ambos.
Para poder desplegar un objeto en tiempo de ejecución desde el objeto fuente, debemos
ejecutar una creación. En SAP BW/4HANA, esto sería equivalente a una activación. Los
objetos creados generados se pueden visualizar en la vista Explorador de base de datos.

Lanzar SAP Web IDE para SAP HANA

Debe obtener la URL del administrador para poder iniciar SAP Web IDE. La URL incluye el host
(en nuestro caso wdflbmt7211) y el puerto (en nuestro caso, 53075) en el que están
instalados HANA y la interfaz de usuario. En esta formación BW430, después de iniciar la URL
https://wdflbmt7211.wdf.sap.corp:53075 en Google Chrome como navegador recomendado,
se muestra la pantalla que se muestra en la imagen Iniciar Web IDE para SAP HANA. Cuando
haya iniciado sesión, puede decidir qué vista desea trabajar.

© Copyright. Reservados todos los derechos. 415

Capítulo 11 : Implementación de vistas nativas de SAP HANA

Cambiar vistas

Figura 306: Cambiar vistas en SAP Web IDE para SAP HANA

La vista Desarrollo y la vista Explorador de base de datos son los principales entornos de
trabajo en SAP Web IDE para SAP HANA.

416 © Copyright. Reservados todos los derechos.

 Lección: Introducción a SAP Web IDE para SAP HANA

La vista de desarrollo

Figura 307: SAP Web IDE para SAP HANA - Vista de desarrollo

La vista Desarrollo se utiliza para desarrollar y actualizar objetos de cliente como modelos de
datos mediante editores gráficos o basados en texto. Aquí puede crear los artefactos SAP
HANA XSA como vistas de cálculo o funciones. Puede identificar el tipo de objeto desde su
extensión de archivo. Los artefactos de origen se organizan mediante carpetas.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Explore SAP Web IDE para SAP HANA

© Copyright. Reservados todos los derechos. 417

Capítulo 11 : Implementación de vistas nativas de SAP HANA

418 © Copyright. Reservados todos los derechos.

 Capítulo 11
Lección 2
Modelado de datos maestros en vistas SAP
HANA

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Crear vistas SAP HANA con jerarquías

Escenario empresarial y objetivo de las vistas que contienen datos maestros

Usted es un experto en modelación de datos para el proyecto de gestión de informes ITelO.
Como parte de la implementación de SAP BW/4HANA, ITelO desea acceder a datos que
cambian rápidamente en tiempo real. Para una flexibilidad máxima, decide utilizar las
funciones de SAP HANA.
ITelO desea presentar los mismos datos maestros consistentes para los informes de ventas y
compras. Los textos de producto deben estar disponibles en diferentes idiomas y visualizarse
en el idioma adecuado para el usuario empresarial. Para seleccionar o visualizar productos,
se necesita una jerarquía con diferentes niveles de categorías de producto para una opción de
desglose guiada. A partir de atributos dependientes de tiempo, asignaciones de jerarquía o
textos, se debe visualizar el valor adecuado a la fecha de venta.
Definiciones

© Copyright. Reservados todos los derechos. 419

Capítulo 11 : Implementación de vistas nativas de SAP HANA

Figura 308: Escenario empresarial y tipos de vistas

Antes de entrar en más detalles, revisemos los conceptos básicos utilizados en la generación
de informes, como dimensiones, indicadores, atributos, jerarquías, etc.
Un indicador (como precio, volumen) es un valor numérico, como un precio, cantidad,
volumen, en el que puede procesar operaciones aritméticas o estadísticas, como suma,
promedio, valores top N y cálculos.
Un atributo es un elemento que se utiliza para describir un indicador, se puede utilizar como
filtro o para dividir un valor agregado en entidades individuales.
Una jerarquía es una agrupación de varios niveles de valores de atributo.
Las vistas nativas de SAP HANA, también conocidas como Vistas de información, son vistas
en SAP HANA que organizan los datos de tablas individuales y permiten una variedad de
cálculos de datos, con el fin de obtener un conjunto relevante y significativo de indicadores y
dimensiones o atributos para responder a una necesidad de informes específica.
Beneficios de las vistas de información
Las principales ventajas de utilizar las vistas de información en SAP HANA son las siguientes:
● Puede definir un subconjunto de datos que sea relevante para tareas empresariales
específicas. Puede hacer que los datos sean más significativos que en las tablas de origen
personalizando los nombres de las columnas, asignando columnas de etiquetas a
columnas clave y uniendo atributos adicionales.
● Los nuevos valores se pueden derivar sobre la marcha, por ejemplo, como cálculos
matemáticos o como subcadenas.
● No es necesario almacenar resultados. Pueden existir diferentes versiones de vistas sin
almacenamiento de datos adicional. Esto se denomina modelo de datos virtual (VDM).

420 © Copyright. Reservados todos los derechos.

 Lección: Modelado de datos maestros en vistas SAP HANA

● No es necesario precalcular los agregados y las herramientas de generación de informes

front-end delegan la mayor parte de la carga de trabajo de procesamiento de datos
(filtrado, agregación, cálculos) a los motores in-memory de SAP HANA. Esto alcanza un
rendimiento muy alto.
● Acceso en tiempo real: las vistas de SAP HANA proporcionan acceso inmediato a valores
cambiantes, basados en los datos que residen en los esquemas de base de datos de SAP
HANA y en datos remotos a los que se puede acceder mediante tablas virtuales.
● Reusabilidad: Cada vista de información puede ser utilizada (referenciada) por otras vistas
de información.
● Flexibilidad: Las vistas de la información proporcionan una serie de funciones que las
hacen muy flexibles. Por ejemplo, definir jerarquías, filtrar datos, generar peticiones para
variables y parámetros de entrada y realizar la conversión de moneda.
● Adaptabilidad: Una vista de información de SAP HANA puede adaptar su comportamiento
a la lista de columnas que se seleccionan o proyectan sobre ella. Por ejemplo, la
granularidad de un nodo Rango se puede determinar dinámicamente en función de si
consulta los resultados por País o por País y Cliente.
● Fácil de transportar: SAP HANA proporciona potentes herramientas para transportar
modelos de información entre diferentes bases de datos de SAP HANA. Por ejemplo, para
instalar modelos de información suministrados por SAP o transportar sus propios
modelos de información entre sus infraestructuras de desarrollo, gestión de calidad y
producción.

Según las mejores prácticas, ITelO decide utilizar un enfoque modular, es decir, separar las
vistas de datos maestros y las vistas de datos transaccionales.
Una ventaja de este concepto es que las vistas de datos transaccionales que contienen
importes para transacciones de compra o venta se pueden crear independientemente del
conjunto de atributos de producto. En diferentes vistas de SAP HANA para informes de
compras o ventas, estas vistas de datos transaccionales se pueden unir con la misma vista de
datos maestros (productos con textos y atributos estándar). Esto garantiza que los datos
maestros sean consistentes en todos los escenarios.
Con el desarrollo nativo de HANA 2.0, utilizamos vistas de cálculo como vistas de
información. Son posibles tres categorías de datos de vistas de cálculo:
● Una vista de cálculo DIMENSION no agrega indicadores. Cualquier columna (números
pares) se trata como un atributo. Si una columna contiene valores numéricos, es una
propiedad del elemento correspondiente. Si una fuente entrega registros duplicados, solo
serán visibles diferentes registros. La agregación se comporta como el comandoselect
single SQL. Las vistas de cálculo de dimensión se utilizan para conectar textos, atributos
y jerarquías.
● Una vista de cálculo CUBE está diseñada para el reporting multidimensional. Los
indicadores se pueden agregar como suma, mínimo, máximo, promedio o recuento.
● Una vista de cálculo SQL ACCESS se utiliza como capa intermedia (vistas de interfaz). Los
indicadores no se agregan y los duplicados no se eliminan como en una vista de
dimensión. Pueden ser consumidos por otras vistas de cálculo o mediante SQL. No se
pueden utilizar en herramientas de informes como Excel o SAP Analysis para Microsoft
Office.

Ejemplo empresarial para vista de cálculo de dimensión

© Copyright. Reservados todos los derechos. 421

Capítulo 11 : Implementación de vistas nativas de SAP HANA

Desea crear una vista en su información de producto (por ejemplo, ID, nombre, categoría,
categoría principal, tóxico o no, precio, tamaño, peso, etc.) en función de diferentes tablas. El
nombre de sus empleados debe combinarse a partir del nombre y el apellido. Los
interlocutores comerciales tienen una clasificación interna que cambia con el tiempo.
En SAP HANA, normalmente recupera esta información con Vista de cálculo de la categoría
de datos DIMENSION, lo que le permite estructurar los datos maestros y adaptarlos a sus
requisitos de informes. Ejemplos de ello son los siguientes:
● Unir varias tablas para definir una dimensión que contenga todos los atributos que
necesita.
● Cree una combinación de texto para seleccionar el texto que coincida con el idioma de
inicio de sesión antes de unirse al texto.
● Seleccione solo algunas de las columnas de las tablas de origen porque algunos datos
podrían ser innecesarios.
● Modifique el nombre o las etiquetas de las columnas.
● Asocie semánticamente el nombre o código y la descripción de objetos (por ejemplo,
código de producto y descripción de producto).
● Definir atributos calculados.

Nota:
Las vistas de cálculo de dimensión no permiten indicadores. Cualquier columna
numérica o valor siempre se trata como atributos.
Normalmente, los datos de una vista de cálculo de dimensión no están disponibles
para la generación de informes directamente. Normalmente, se crea una vista de
cálculo de cubo que une los datos de hechos y los datos maestros. Los atributos
de las vistas de cálculo de dimensión se pueden combinar con otras columnas de
la vista de cálculo de cubo en columnas calculadas, como multiplicar la
información de precio de la vista de datos maestros con valores de cantidad de
ventas para obtener el volumen de ventas total.

Figura 309: Objetivo de las vistas que contienen datos maestros

Dentro de una vista, se pueden contener y combinar diferentes tablas. Diferentes tipos de join
son posibles, especialmente un inner join, o un outer join. Una conexión interna solo contiene
registros que tienen una coincidencia en ambas tablas. Una combinación externa izquierda

422 © Copyright. Reservados todos los derechos.

 Lección: Modelado de datos maestros en vistas SAP HANA

conserva todos los registros de la tabla de la izquierda y agrega columnas de la tabla derecha
de una combinación.
Dependencia de idioma
En la mayoría de las empresas multinacionales, los textos de productos, colores, materiales,
canales de distribución, métodos, motivos, elementos de coste, centros de coste, meses e
incluso ciudades y países se almacenan en varios idiomas. Normalmente, estos idiomas
diferentes ya existen en la fuente. Para facilitar la comprensión de los informes
empresariales, cada usuario debe ver los datos con textos de su idioma preferido.
Si una tabla independiente forma parte de una vista de dimensión, utilice un filtro dinámico de
una columna de idioma con el valor de filtro $$language$$. A continuación, se determina este
idioma de trabajo y se utiliza como valor de filtro.
Combinaciones de texto
La imagen, Definición de join de texto, muestra funciones adicionales de las vistas de cálculo
de SAP HANA que ayudan a presentar textos dependientes de idioma si hay dos tablas
implicadas.

Figura 310: Definición de combinación de texto

Si desea asignar textos específicos de idioma de una tabla a atributos de otra tabla, utilice un
join de texto en una vista de cálculo de dimensión.
Para un join de texto, utilice la vista de atributo como la tabla de la izquierda del join y la tabla
de texto como tabla derecha. El join de texto se comporta como un filtro en una columna de
idioma especificada (en fuentes SAP normalmente etiquetadas como SPRAS) y una unión
externa izquierda en el resultado. Esto significa que solo se añade el texto en el idioma de
trabajo si existe. Si no existe ningún texto correspondiente en el idioma de trabajo, se
seguirán visualizando los atributos, pero sin texto.
Para cada atributo, es posible definir una asignación de descripción. Esta asignación es
específica del idioma del usuario final. El atributo que contiene la descripción se denomina
columna de etiqueta. La relación se puede definir en el nodo de semántica de una vista de
cálculo.
Combinación temporal

© Copyright. Reservados todos los derechos. 423

Capítulo 11 : Implementación de vistas nativas de SAP HANA

Figura 311: Conexión no equi

En el ejemplo de la figura, No Equi Join, el texto depende del tiempo. Esta información se
captura en una tabla dedicada. Cree un inner join con diferentes condiciones en un nodo Non
Equi Join:
● ID de producto y D_NW_PRID (ID de producto): Igual
● Fecha y DATETO: Menor que [o] igual a
● Fecha y DATEFROM: Mayor que [o] igual a

Nota:
Esto reemplaza la definición de unión temporal de las vistas analíticas de SAP
HANA 1.0 donde las condiciones solo se pueden definir en columnas de los
siguientes tipos de datos: cronomarcador, fecha y número entero.

Tipos de jerarquía de SAP HANA

Se pueden definir dos tipos de jerarquías en una vista de cálculo de dimensión: "Jerarquía
superior-inferior" o "Jerarquía de nivel". En la imagen "Tipos de jerarquía de SAP HANA" se
comparan las dos opciones para una jerarquía de categorías de producto.

424 © Copyright. Reservados todos los derechos.

 Lección: Modelado de datos maestros en vistas SAP HANA

Figura 312: Tipos de jerarquía de SAP HANA

Para comprender las funciones de estos tipos de jerarquía, es útil la siguiente terminología de
jerarquías:
● Una entidad de una jerarquía se denomina nodo.
● Casi todos los nodos tienen un nodo superior asignado, es decir, el nodo correspondiente
en el siguiente nivel de agregación. Un nodo sin nodo superior se denomina nodo raíz.
● Una relación entre un nodo y su nodo superior se denomina enlace.
● Los nodos que están asignados al mismo nodo superior son los nodos subordinados de
este nodo superior.
● Los hijos del nodo raíz son nodos del nivel 1, los hijos de los nodos del nivel 1 son nodos del
nivel 2, etc.
● Los nodos que no tienen nodos secundarios, se llaman nodos de hoja o hojas.
● Los nodos que no son nodos finales, y no el nodo raíz, se denominan nodos internos.
● Una jerarquía se denomina jerarquía equilibrada si todas las hojas están en el mismo nivel.
En otras palabras, cada ruta del nodo raíz a un nodo hoja contiene un nodo de cada nivel,
todas las rutas tienen la misma longitud.
● Lo contrario, una jerarquía que tiene hojas en diferentes niveles, es una jerarquía
desequilibrada.

Jerarquías superior-inferior
Si tiene una tabla de todos los enlaces, que enumera todos los nodos en una columna clave, y
la superior para cada nivel inferior en una columna separada, se puede crear una jerarquía
superior-inferior a partir de esta tabla.
Supongamos que tiene una lista de todos los empleados y sus gerentes, y los propios
gerentes son empleados en esta tabla. Al buscar a cada gerente como empleado, el sistema
puede crear una jerarquía de empleados. En el nivel más alto, un gerente superior que no
informe a otro gerente será la raíz de la jerarquía. Todos los empleados que no son
supervisores en sí mismos formarán las hojas de la jerarquía. Este es un ejemplo típico de una
jerarquía desequilibrada. El secretario del gerente superior puede ser un nodo final en el nivel

© Copyright. Reservados todos los derechos. 425

Capítulo 11 : Implementación de vistas nativas de SAP HANA

1, y los empleados normales dentro de los grandes departamentos están en niveles más abajo
en la jerarquía.
Las jerarquías superior-inferior son comunes en otros dominios, como categorías de
producto, centros de coste o departamentos.

Consejo:
Como consecuencia del diseño, los tipos de datos de todos los nodos deben ser
los mismos. Por lo tanto, si las entidades inferiores (por ejemplo, productos) se
representan mediante números, todos los nodos superiores (por ejemplo,
categorías de producto) también deben representarse mediante números.
Asegúrese de que quedan suficientes números abiertos para una jerarquía
creciente. Como opción más flexible, seleccione tipos de datos de cadena de
caracteres para la columna inferior y superior.

Jerarquías de niveles
Supongamos que sus entidades básicas (nodos finales) y los niveles superiores son entidades
diferentes con diferentes tipos de datos. A continuación, no puede crear jerarquías
superiores-inferiores.
Si tiene una tabla con un número fijo de atributos que corresponden a niveles de agregación
bien definidos por encima de cada elemento de hoja, se puede crear una jerarquía de niveles.
Una jerarquía de niveles es una jerarquía equilibrada.
Supongamos que para cada fecha, extrae el mes, el trimestre y el año como tres nuevas
columnas calculadas. Tenga en cuenta que estas columnas tienen diferentes tipos de datos
(ocho, seis, cinco o cuatro dígitos), y cada columna representa un nivel de agregación
específico. Todas las fechas del mismo mes se pueden combinar en un nodo para este mes,
todos los meses del mismo trimestre se pueden combinar en un nodo para este trimestre,
etc. Este es un ejemplo típico de una jerarquía de niveles. Se añade automáticamente un nodo
raíz.
Si los productos y las categorías de producto tienen diferentes tipos de datos y desea crear
una jerarquía de nivel, necesita una tabla que contenga los productos y las categorías en
diferentes columnas, y la columna de productos debe ser la columna clave. Si desea añadir un
nivel nuevo para la categoría principal agregando diferentes categorías, puede añadir una
columna nueva. Sin embargo, es importante que cada producto tenga una entrada adecuada
para cada columna y que los productos de la misma categoría tengan la misma categoría
principal.
En la imagen "Tipos de jerarquía de SAP HANA: tabla de comparación" se comparan las dos
opciones y sus características.

426 © Copyright. Reservados todos los derechos.

 Lección: Modelado de datos maestros en vistas SAP HANA

Figura 313: Tipos de jerarquía de SAP HANA: tabla de comparación

Casos de uso
Si su modelo de jerarquía es una jerarquía desequilibrada y sus datos están disponibles como
una lista de enlaces, necesitará una jerarquía superior-inferior.
Si su jerarquía está equilibrada y la fuente proporciona una lista de atributos que representan
niveles de agregación, implemente una jerarquía de niveles.
Implementación técnica de una jerarquía superior-inferior
Defina una tabla con dos columnas del mismo tipo de datos. Una columna con la propiedad
clave, para el elemento “secundario” de cada vínculo, la segunda columna para el “principal”
del vínculo.
Una entrada sin elemento superior es una raíz.
Ventajas de una jerarquía superior-inferior
Una jerarquía superior-inferior tiene las siguientes ventajas:
● Ahorra espacio de memoria porque cada información de enlace se almacena solo una vez
(sin redundancia).
● Mover un subárbol es fácil porque solo requiere un cambio en una fila.

Implementación técnica de una jerarquía de niveles

Defina una tabla con tantas columnas como niveles con tipos de datos posiblemente
diferentes. La primera columna para el nivel más bajo (hojas) debe tener la propiedad clave,
todas las demás son dependientes.
El nodo raíz no debe incluirse en la tabla. Se añade automáticamente como un nodo individual
adicional.
Añadir un nivel nuevo es muy complicado porque se deben añadir muchos enlaces nuevos
para este nivel y se deben eliminar muchos existentes.
Debido a la compresión, almacenar muchos valores de atributo repetidamente no es tan malo
como lo sería en otras bases de datos.
Ventajas de una jerarquía de niveles
Si se pueden derivar niveles superiores de atributos existentes, la implementación es directa.
Si los atributos se pueden derivar como los primeros o últimos N caracteres, como en las
áreas de nombres anidadas, utilice la función de string de izquierda o string derecho para
derivar estos atributos como columnas calculadas.

© Copyright. Reservados todos los derechos. 427

Capítulo 11 : Implementación de vistas nativas de SAP HANA

Los atributos adicionales son posibles en la tabla de datos que no forman parte de la
jerarquía, por ejemplo, textos o precios.
Añadir o modificar niveles es fácil. Simplemente añada una nueva columna a la tabla y la
jerarquía, o elimine o modifique una columna en la jerarquía.
Mover un subárbol de la jerarquía es complicado porque para todas las hojas que forman
parte del subárbol movido se deben modificar varios valores de atributo.
Creación de una jerarquía de niveles
La imagen, Creación de una jerarquía de niveles, muestra capturas de pantalla del proceso
para definir una jerarquía de niveles

Figura 314: Creación de una jerarquía de niveles

Para crear una jerarquía de niveles, proceda de la siguiente manera:

1. Cree una nueva vista de cálculo de dimensión.

Seleccione todas las tablas que contengan atributos relevantes para la jerarquía y defina
las combinaciones necesarias entre ellas.
Asegúrese de que todos los atributos que serán columnas de la jerarquía se propaguen a
la capa semántica.

2. En la sección Detalles, en la ficha Jerarquías, defina la jerarquía.

Seleccione Añadir jerarquía → Jerarquía de niveles e introduzca un nombre y una etiqueta
(descripción) para la jerarquía.

3. Añada los atributos en el orden deseado, desde el nivel de agregación más alto al nivel
más bajo (nodos finales).

4. Si comete un error, utilice los botones Subir y Bajar para corregir el orden.

5. Active la vista de cálculo.

Creación de una jerarquía superior-inferior

La imagen, Creación de una jerarquía superior-inferior, muestra capturas de pantalla del
proceso para definir una jerarquía superior-inferior.

428 © Copyright. Reservados todos los derechos.

 Lección: Modelado de datos maestros en vistas SAP HANA

Figura 315: Creación de una jerarquía principal y secundaria

Para crear una jerarquía superior-inferior, proceda de la siguiente manera:

1. Cree una nueva vista de cálculo de dimensión.

Seleccione todas las tablas que contengan atributos relevantes para la jerarquía y defina
las combinaciones necesarias entre ellas.
Asegúrese de que todos los atributos que se convertirán en columnas subordinadas y
superiores se propaguen a la capa semántica.

2. En la sección Detalles, en la ficha Jerarquías, defina la jerarquía.

Seleccione Añadir jerarquía → Jerarquía superior-inferior.

3. Seleccione las columnas para el nivel inferior y superior.

4. Active la vista de cálculo.

Figura 316: Ejercicio: Ampliar vistas de cálculo de dimensión de tipo con jerarquías

© Copyright. Reservados todos los derechos. 429

Capítulo 11 : Implementación de vistas nativas de SAP HANA

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Crear vistas SAP HANA con jerarquías

430 © Copyright. Reservados todos los derechos.

 Capítulo 11
Lección 3
Modelado de datos transaccionales en vistas
de SAP HANA

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Crear vistas SAP HANA con indicadores

Integración de datos transaccionales con datos maestros y cálculo de valores en

un modelo de datos virtual (VDM)
Esquema estrella clásico
Los modelos de datos multidimensionales se utilizan para crear aplicaciones analíticas. El
esquema estrella clásico, como se muestra en la figura Esquema de inicio clásico, es el
modelo multidimensional más utilizado para bases de datos relacionales. Este esquema de
base de datos clasifica los datos en dos grupos: hechos (como importe de ventas o cantidad)
y atributos de dimensión (como cliente, producto o tiempo).

Figura 317: Esquema estrella clásico

Los hechos son el centro de cualquier análisis de las actividades empresariales. Los datos de
hechos (valores para los hechos) se almacenan en una tabla de hechos altamente
normalizada. La tabla de hechos contiene hechos o indicadores, así como las claves utilizadas
para identificar, para cada dimensión, qué miembro de dimensión corresponde a cada hecho.
Los valores de los atributos de dimensión se almacenan en varias dimensiones
desnormalizadas. Aquí, los atributos de dimensión relacionados lógicamente se almacenan

© Copyright. Reservados todos los derechos. 431

Capítulo 11 : Implementación de vistas nativas de SAP HANA

como una jerarquía (relaciones superior-inferior o atributos para diferentes niveles) dentro de
la tabla de dimensión. Además, las tablas de dimensión contienen textos y atributos
numéricos para las características de dimensión. Las relaciones de clave externa o primaria
(operaciones de combinación) vinculan las tablas de dimensión con la tabla de hechos
central. El atributo de dimensión con el nivel de detalle más fino de la tabla de dimensión
correspondiente es una clave externa en la tabla de hechos.
Esquema estrella SAP HANA

Figura 318: Esquema estrella SAP HANA

En SAP HANA, en lugar de tablas, se utilizan vistas. La vista de hecho central puede ser una
combinación de diferentes vistas. De forma similar, una vista de dimensión normalmente es
una unión de una tabla de atributos y una tabla de texto, o se añaden diferentes atributos de
diferentes tablas.
La combinación de estas tablas se definirá en una vista multidimensional de nivel superior.
Esta es una vista de cálculo del tipo Cubo con un join en estrella.
Este concepto se denomina modelo de datos virtual. Una combinación de varios modelos de
datos virtuales en diferentes niveles (similar al concepto de LSA++) se puede combinar con
un almacén de datos virtual.
Dimensiones de tiempo
Para las vistas de dimensión de tiempo, SAP HANA tiene un tipo específico de vista de
cálculo, llamado subtipo Tiempo. En una vista de tiempo, solo se permiten características de
tiempo del mismo tipo de calendario. Se ofrecen los siguientes dos tipos de calendario:
● Gregoriano: El calendario gregoriano se compone de años, meses y días. Puede ajustar el
nivel de granularidad en horas, minutos o segundos.
● Fiscal: el calendario fiscal está organizado en ejercicios fiscales y períodos fiscales. Se
pueden definir varias variantes de ejercicio en función de sus necesidades de informes.

432 © Copyright. Reservados todos los derechos.

 Lección: Modelado de datos transaccionales en vistas de SAP HANA

Nota:
El calendario fiscal es especialmente útil para mostrar datos en sus modelos de
información de acuerdo con las tablas del calendario fiscal disponibles en su
sistema SAP ERP.

Para crear una vista de cálculo de dimensión de tiempo

Requisito previo: Los datos de tiempo se han generado en su sistema SAP HANA.

Nota:
Este procedimiento lo realiza generalmente un administrador del sistema y rellena
algunas tablas M_TIME_DIMENSION_* (calendario gregoriano) o la tabla
M_FISCAL_CALENDAR (calendario fiscal), ubicada en el esquema _SYS_BI.

1. Cree una nueva vista de cálculo del subtipo Tiempo.

2. Seleccione un tipo de calendario (Gregoriano o Fiscal).

3. Defina el nivel de granularidad (gregoriano) o la variante (fiscal).

4. Para obtener la tabla relevante del esquema _SYS_BI incluido automáticamente en el

escenario de vista de cálculo, seleccione la casilla de selección Crear automáticamente.

5. Seleccione Finalizar.

6. Añada las columnas que se ajusten a sus necesidades de gestión de informes para la
salida.

7. Asegúrese de incluir una columna relevante que se utilizará como clave para unir la vista
de cálculo de tiempo a las tablas o vistas que contienen sus indicadores.

8. Si es necesario, organice los datos de tiempo en jerarquías de nivel.

9. Guarde y active la vista.

Combinación de vistas de cálculo

Para crear un modelo de datos virtual de este tipo, se combinan diferentes tipos de vistas de
cálculo de forma modular. Las tres figuras Integración de datos y Cálculo de valores en un
modelo de datos virtual sugieren un procedimiento paso a paso que comienza con el
modelado de datos maestros.

© Copyright. Reservados todos los derechos. 433

Capítulo 11 : Implementación de vistas nativas de SAP HANA

Figura 319: Integración de datos Web IDE

Primero, defina las vistas de datos maestros (dimensión Categoría de datos)

1. Proyección: Seleccione los campos obligatorios.

2. Si es necesario: Unir diferentes tablas de datos maestros (atributos y textos).

3. Verifique la semántica (columnas de etiqueta).

4. Crear jerarquías.

5. Active la Vista de cálculo.

A continuación, defina una vista de infraestructura de datos (cubo de categoría de datos sin
combinación en estrella).

1. Seleccione una tabla central con indicadores y, normalmente, registros transaccionales.

2. Si es necesario: Combine otros hechos, como la tabla de cabecera o la tabla de

posiciones.

3. Armonizar datos en columnas calculadas.

4. Si es necesario: Combine conjuntos de datos a través de la unión.

5. Definir método de agregación (suma, máximo, promedio, ...).

6. Active la Vista de cálculo.

434 © Copyright. Reservados todos los derechos.

 Lección: Modelado de datos transaccionales en vistas de SAP HANA

Figura 320: Integración de datos mediante Cube con Star Join

Si resulta útil, defina un cubo sin join en estrella.

1. Conecte la vista de la infraestructura de datos central con las vistas de cálculo de datos
maestros.

2. Si es necesario, añada cálculos u oculte campos.

3. Defina las propiedades para el acceso a datos, como las opciones de caché dependientes
del cliente.

4. Active la Vista de cálculo.

1. El tipo de join típico es un referential join. Un referential join se comporta como un inner
join, pero el join no se ejecuta si solo se seleccionan campos de un lado. En particular, el
efecto de una conexión referencial es que las tablas de dimensión no se ejecutan si no se
selecciona ningún atributo de la vista de dimensión.
La visión referencial supone que se garantiza la integridad referencial. Integridad
referencial significa que todos los valores de la infraestructura de datos (vista de hechos
central) se producen en la vista de dimensión conectada. En este caso, el conjunto de
resultados de una conexión interna es el mismo que un left outer join. En otras palabras, el
número de registros de la unión es el mismo que el número de registros de la vista central.

2. (Opcional) Se pueden añadir vistas de cálculo y nodos adicionales para incluir

clasificaciones, extraer niveles de jerarquía, encontrar la vía de acceso más corta en una
red de grafos o añadir anonimización
Además, las vistas de cálculo cuentan con opciones adicionales, como parámetros de
entrada o funciones de tabla. Se utilizan para integrar el script SQL, un lenguaje que
presenta variables, bucles, if-then-else, llamadas de función y procedimiento. El código se
calcula a petición (durante la gestión de informes).

Cálculo y evaluación de medidas en vistas de cálculo

En muchos casos, las vistas de cálculo con indicadores (Cubo de categoría de datos) ofrecen
funciones de cálculo que no se pueden modelar con consultas BW clásicas. En la imagen
"Caso de utilización para vistas de cálculo" se enumeran algunos.

© Copyright. Reservados todos los derechos. 435

Capítulo 11 : Implementación de vistas nativas de SAP HANA

Figura 321: Utiliza el caso para vistas de cálculo

Las figuras, Creación de una vista de cálculo de cubo y Creación de una vista de cálculo –
Nodos, explican cómo se crea una vista de cálculo de cubo.

Figura 322: Creación de una vista de cálculo: nodos

La imagen "Vistas de cálculo - Nodos" explica los diferentes tipos de nodos:

● Se pueden añadir nodos de proyección para seleccionar campos existentes o para añadir
campos adicionales. Por ejemplo, puede crear una columna calculada para concatenar dos
campos, extraer una subcadena o añadir una marca que indique el registro como un
registro de valor real versus planificado.
(Esta función también está disponible en los otros tipos de nodo, pero si necesita campos
antes de los otros nodos, utilice una vista de proyección.)
● Un nodo Agregación permite definir un tipo de agregación para cada indicador.
● Se puede añadir un nodo Join para ampliar los registros de una vista con columnas desde
otra vista.
● Se puede añadir un nodo Union para traer valores de diferentes fuentes a un conjunto
común de datos.

436 © Copyright. Reservados todos los derechos.

 Lección: Modelado de datos transaccionales en vistas de SAP HANA

● Un nodo de intersección solo proporciona registros que existen en ambas fuentes.

● Se puede añadir un nodo Menos para comparar valores de diferentes fuentes. El nodo
menos proporciona los registros de una fuente que no están disponibles en la otra.
● Un nodo Star Join conecta una tabla o vista de hechos central con una o más vistas de
dimensión.
● Se puede añadir un nodo Rango para mantener solo una lista de valores superiores o
inferiores.
● El nodo Semántica representa el final del gráfico de flujo de datos. Contiene todas las
propiedades y le permite generar jerarquías, tipos semánticos, parámetros de entrada y
variables. Es la interfaz de la siguiente vista de cálculo o herramienta de gestión de
informes.
● Dependiendo del tipo de vista, el nodo más alto por debajo de Semántica es un nodo de
agregación, proyección o join en estrella. Si necesita modificarlo, modifique el tipo de
categoría de datos en las propiedades de la vista.

Para crear una vista de cálculo, arrastre los nodos desde la paleta situada a la izquierda.
Perfilar conexiones. Debe asignar todos los campos obligatorios de cada nivel al siguiente
nivel.

Figura 323: Nodo de clasificación

Conversión de moneda
La figura, Conversión de moneda, muestra las opciones de una conversión de moneda.

© Copyright. Reservados todos los derechos. 437

Capítulo 11 : Implementación de vistas nativas de SAP HANA

Figura 324: Conversión de moneda

Cuando crea modelos de información, los datos de origen a menudo se expresan en una única
moneda. Normalmente, para los datos de ventas, esta sería la moneda de transacción en la
fecha de venta.
Sin embargo, para fines de gestión de informes, muy a menudo es necesario convertir las
monedas. Los fines pueden incluir (entre otros) lo siguiente:
● Informes corporativos: Cuando se utiliza una moneda de informes globales en informes
corporativos, todos los valores deben mostrarse en la moneda de informes globales.
● Informes regionales: por ejemplo, es posible que la región de EE. UU. desee ver las cifras
europeas en USD.

Debido a la fluctuación permanente de los tipos de cambio, debe definir un proceso de

conversión inteligente y, en particular, definir una fecha de referencia. Se utiliza la tasa de
conversión de la fecha de referencia. En particular, defina qué fecha debe considerarse para
definir la tasa de conversión a aplicar. Este requisito es aún más fuerte cuando la moneda de
origen o destino es volátil.
Conversión de moneda nativa en modelos de información SAP HANA
SAP HANA ofrece un mecanismo de conversión elaborado que se basa en los siguientes
módulos:
● Un conjunto de tablas técnicas para almacenar datos maestros sobre monedas, tipos de
cambio y valores de tipos de cambio.
● El concepto de tipo semántico. Si se selecciona el tipo semántico Importe con código de
moneda, las medidas de esta columna tienen una referencia a una moneda (bien una
moneda fija, una moneda de la conversión de moneda o una moneda de otra columna).

438 © Copyright. Reservados todos los derechos.

 Lección: Modelado de datos transaccionales en vistas de SAP HANA

● Una interfaz para definir, para cada indicador de importe, cómo debe procesar la
conversión el modelo de información (qué tasa y fechas de conversión se deben aplicar y
dónde encontrar la moneda de origen y de destino.

Enfoques de conversión de moneda en SAP HANA

En SAP HANA, la conversión de datos se puede implementar en vistas gráficas y basadas en
scripts.
Las vistas de cálculo gráfico en SAP HANA proporcionan la forma más fácil de convertir
monedas porque el modelado de conversión se puede realizar mediante la interfaz gráfica.
Como alternativa, en caso de restricciones en los datos maestros o debido a la complejidad
de los requisitos de gestión de informes, puede modelar la conversión de moneda dentro de
una vista de script.
Sin embargo, esta función se basa en una función SQLScript, CONVERT_CURRENCY, que se
basa en operadores de plan de motor de columnas (o funciones CE), que ahora están
obsoletos.
Aplicación de la conversión a nodos de agregación inferiores
A partir de SAP HANA 1.0 SPS12 en adelante, es posible definir una conversión de moneda en
cualquier nodo de agregación de una vista de cálculo. Esta mejora le permite actualizar una
conversión de moneda en un nivel intermedio de su vista de cálculo. Por ejemplo, cuando
necesita combinar dos conjuntos de datos diferentes con un nodo Union, y solo uno de los
conjuntos de datos debe convertirse. Además, es posible definir una conversión de moneda
como referencia a otra columna: todas las propiedades de conversión, incluida la moneda de
destino, se toman de la columna referenciada.

Nota:
Hasta SPS11, la conversión de moneda solo se podía definir en el nivel más alto de
la vista de cálculo, ya sea el nodo superior Agregación de una vista de cálculo de
cubo o el nodo Combinación de estrella de una vista de cálculo de cubo con unión
de estrellas.

Tablas de conversión necesarias

Para habilitar la conversión en SAP HANA, las siguientes tablas deben estar disponibles en la
base de datos de SAP HANA, por ejemplo, en un esquema dedicado para monedas y tipos de
cambio.

Tabla 3: Tablas de conversión necesarias

Nombre de tabla Descripción

TCURC Códigos de moneda

TCURR Tipos de cambio

TCURV Tipos de cotización para conversión de mo-

neda
TCURF Factores de conversión

TCURN Ofertas

TCURX Decimales en monedas

© Copyright. Reservados todos los derechos. 439

Capítulo 11 : Implementación de vistas nativas de SAP HANA

Estas tablas existen en la mayoría de los sistemas SAP (en particular, SAP Business Suite y
SAP Business Warehouse). En la definición del cálculo de moneda, debe especificar el
esquema para la conversión de moneda.
Si desea hacer referencia a las tablas BW, seleccione el esquema BW. Asegúrese de que se
actualicen regularmente para cubrir todas las fechas de conversión necesarias.
Si los modelos se basan en datos replicados desde otro sistema, el proceso de replicación
también debería incluir estas tablas para que siempre se sincronicen con las que se
encuentran en el sistema fuente.
Configuración del tipo semántico
De forma predeterminada, un indicador no tiene ningún tipo semántico. Cuando un indicador
contiene un importe y desea habilitar la conversión, debe modificar su Tipo semántico a
Importe con código de moneda.
¿Cómo se asigna el tipo semántico?
En el panel Salida del nodo Agregación, seleccione una columna agregada y, en el panel
Propiedades generales, defina el Tipo semántico. También puede hacer doble clic en la
columna.
Este tipo Importe con código de moneda es el requisito previo para la conversión de moneda,
pero puede ser una configuración valiosa por sí sola para combinar valores con una moneda.
Opciones a nivel semántico
La imagen, Opciones en el nivel de semántica de una vista de cálculo, presenta una captura de
pantalla del nodo de semántica.
En el nivel de semántica de una vista de cálculo, tiene las siguientes opciones:
● Añada los atributos y los indicadores a la salida y defina su orden
● Definir el tipo de campo (indicador o atributo) y el método de agregación
● Crear más jerarquías y variables, si lo desea

La activación crea la vista de columna a la que pueden acceder las herramientas de front end

Consejo:
Hay un botón Asignar automáticamente para derivar las asignaciones de tipo del
tipo subyacente o del tipo de datos. Sin embargo, verifique si el tipo sugerido es
realmente adecuado para su requisito de gestión de informes.

Cálculo y evaluación de medidas en vistas de cálculo

440 © Copyright. Reservados todos los derechos.

 Lección: Modelado de datos transaccionales en vistas de SAP HANA

Figura 325: Cálculos y funciones en las vistas de SAP HANA

La figura, Cálculos y funciones en las vistas de SAP HANA, muestra algunas funciones
posibles que se pueden utilizar para ampliar una vista de SAP HANA existente. Para derivar
nuevos valores, puede añadir una columna calculada, un contador o una columna restringida.
Estas funciones se ejecutan durante la generación de informes y normalmente no forman
parte de un escenario de almacenamiento de datos, sino que se definen en un nodo de vista
de SAP HANA específico. Como requisito previo, asegúrese de que todos los campos que
necesita en la expresión están disponibles en este nivel.
Las columnas calculadas son similares a los ratios calculados de la consulta BW. Para crear
una columna calculada, proceda de la siguiente manera:

1. Cree una nueva columna calculada.

2. Introduzca un nombre y una etiqueta.

3. Seleccione un Tipo de datos.

4. Para definir un método de agregación, active la agregación por parte del cliente. De lo
contrario, la fórmula se evaluará en el nivel resultante. La agregación por parte del cliente
es útil para algunos cálculos, como la multiplicación A*B, pero no para otros, como la
división X/Y.

5. Introduzca la expresión y verifique la sintaxis.

© Copyright. Reservados todos los derechos. 441

Capítulo 11 : Implementación de vistas nativas de SAP HANA

Consejo:
Las columnas de este nodo, los operadores matemáticos y las funciones de SAP
HANA se pueden seleccionar mediante arrastrar y soltar para generar la
expresión. Como alternativa, puede empezar a escribir un nombre de función
para desencadenar la función de autocompletar.

Figura 326: Columnas restringidas en vistas de cálculo de SAP HANA

Las columnas restringidas son similares a los ratios restringidos de la consulta BW. Para
crear uno, proceda de la siguiente manera:

Nota:
Esta función solo existe para nodos de nivel superior con indicadores (nodo Unión
en estrella o Agregación).

1. Cree una nueva columna restringida.

2. Introduzca un nombre y una etiqueta.

3. Hacer referencia a un indicador base (y heredar el tipo de datos y el método de

agregación).

4. Defina una restricción mediante uno de los siguientes métodos:

● una lista de entradas que compara un atributo con un valor (diferentes valores para el
mismo atributo se combinan con lógicos o)

● una expresión

5. Introduzca la expresión y verifique la sintaxis.

Vista previa de resultado

442 © Copyright. Reservados todos los derechos.

 Lección: Modelado de datos transaccionales en vistas de SAP HANA

Figura 327: Vista previa de resultado

Utilice la opción Vista previa para ver los datos brutos y para probar un análisis.
Errores y sugerencias típicos para corregir errores
Si no aparecen valores, verifique el filtro (incluido el filtro implícito de un join temporal o de
texto), el tipo de join y las condiciones de conexión. Verifique que los campos
correspondientes correctos estén conectados en una definición de join. A continuación,
puede utilizar una vista previa en cada nodo de una vista de cálculo gráfica para verificar los
datos en el nivel del nodo seleccionado.
Si aparecen demasiados valores, verifique si necesita especificar más campos en una
definición de join. Verifique si ha seleccionado las columnas correctas en las uniones
temporales y de texto, y si ha aplicado los filtros relevantes.
Si aparecen valores incorrectos, verifique las fórmulas, los valores de datos de origen y las
conversiones de moneda. Verifique especialmente si las tablas TCUR* están actualizadas.
Si se producen errores, verifique las condiciones de combinación y de fórmula. Verifique los
detalles del error. Normalmente, el primer mensaje de error detallado es el más útil.

© Copyright. Reservados todos los derechos. 443

Capítulo 11 : Implementación de vistas nativas de SAP HANA

Figura 328: Ejercicio: Ampliar una vista de cálculo con fórmulas y conversión de moneda

Para el ejercicio, cree una vista de cálculo con join en estrella. Cree columnas calculadas para
derivar el año a partir de cronomarcadores y convierta los importes de ventas a la moneda de
empresa común US $.
La jerarquía de un ejercicio anterior (o, alternativamente, la solución maestra) es visible en la
vista de cálculo de cubo.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Crear vistas SAP HANA con indicadores

444 © Copyright. Reservados todos los derechos.

 Capítulo 11
Lección 4
Diferencias entre SAP HANA 1.0 y SAP HANA
2.0

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Explicar las diferencias entre SAP HANA 1.0 y SAP HANA 2.0

Diferencias de modelado entre SAP HANA 1.0 y SAP HANA 2.0

Desde su introducción a finales de 2010, la plataforma SAP HANA ha cambiado mucho y se
ha convertido en la base madura de la cartera de soluciones actual de SAP. La versión 1.0
recibió el último support package SPS12 en 05/2016, que se actualiza hasta el 05/2021. El
enfoque de esta versión está en la estabilidad y la continuidad sin ninguna innovación
importante. En 2016, se introdujo la plataforma SAP HANA 2.0 (actualmente en SPS05 con
ciclos de lanzamiento anuales); representa la dirección estratégica de innovación de SAP en
su plataforma in-memory.

Figura 329: Servidores de aplicación de SAP HANA 1.0 vs. SAP HANA 2.0

SAP HANA 2.0 innova la plataforma SAP HANA en muchos términos, incluidos sus conceptos
de modelado. El modelado ahora se basa en un framework de modelado que proporciona
nuevas interfaces de usuario, artefactos y funciones. Algunas de las innovaciones clave son:
● SAP HANA XSC era un servidor de aplicaciones web con un motor JavaScript del lado del
servidor integrado en la base de datos SAP HANA 1.0 con un repositorio propio, mientras
que SAP HANA XSA es una plataforma abierta para aplicaciones web políglotas basadas

© Copyright. Reservados todos los derechos. 445

Capítulo 11 : Implementación de vistas nativas de SAP HANA

en microservicios on-premise y también proporciona sus servicios en la nube (también

conocidos como Cloud Foundry Buildpacks).
● SAP HANA 1.0 se basa en el repositorio nativo XSC (pedido por Paquetes, transportado
por Unidades de Entrega), mientras que SAP HANA 2.0 XSA aprovecha los servicios
abiertos de GitHub como repositorio. Sus objetos se separan en módulos y se transportan
mediante importación/exportación de proyecto o GitHub. Según los módulos, los objetos
de BD se gestionan en los llamados contenedores de HANA Deployment Infrastructure
(HDI).
● En el pasado, se utilizaban varias herramientas de desarrollo diferentes para escenarios de
desarrollo HANA específicos. Para unificar la experiencia de desarrollo en SAP HANA, se
ha introducido un nuevo entorno de desarrollo que integra estas herramientas de
desarrollo independientes anteriores en un entorno de desarrollo. Este entorno se
denomina SAP Web IDE para SAP HANA y se ejecuta en el entorno XS Advanced (XSA) de
SAP HANA 2.0. SAP HANA Web IDE sustituye las perspectivas de HANA Studio basadas
en Eclipse para el desarrollo nativo de HANA. Sin embargo, esto no se aplica a las
herramientas de modelado de BW.
● HANA 2.0 no admite vistas de atributo o de análisis como vistas de información. Se
requiere una migración de las vistas de información de HANA (XSC, HANA 1.0) a las vistas
de cálculo de HDI (XSA, HANA 2.0). SAP proporciona soporte de herramientas para
gestionar esta migración.

Figura 330: Funciones de modelado de SAP HANA 1.0 y SAP HANA 2.0

XSA proporciona características de modelado adicionales. Algunos ejemplos:

● Combinaciones no Equi: la condición de conexión se puede basar en cualquier operador de
comparación (no igual, menor que, mayor que). Esto significa que puede unirse a un
registro que contiene la fecha de ventas con todas las ofertas que se crearon antes de la
fecha de venta.
● Menos: Una operación de conjunto de datos que pasa todos los registros que aparecen en
una, pero no en la otra fuente. Esto significa que puede determinar todos los productos
que se han vendido en un sistema fuente, pero no en el otro.
● Anonimización: es posible sustituir el ID de empleado por un número aleatorio y el
cumpleaños por un valor de nivel superior (mes de nacimiento, año de nacimiento o
década de nacimiento).

446 © Copyright. Reservados todos los derechos.

 Lección: Diferencias entre SAP HANA 1.0 y SAP HANA 2.0

Figura 331: SAPHANA_Platforms7_image.pptx

Actualmente, la plataforma SAP HANA 2.0 es totalmente compatible con SAP HANA 1.0, lo
que significa que la aplicación XSC puede coexistir actualmente con las aplicaciones XSA.
Con SAP Netweaver BW 7.5 o BW/4HANA 1.0, debe utilizar el entorno de modelado clásico
XS, incluso si su plataforma de base de datos es SAP HANA 2.0. Para el desarrollo de XSC,
aún necesita trabajar en SAP HANA Studio o en el workbench de desarrollo HANA 1.0 basado
en la web. Con BW/4HANA 2.0, SAP recomienda aprovechar el marco XSA para nuevas
aplicaciones y considerar la migración de aplicaciones heredadas. Esperamos que el clásico
de XS no se admita en todas las versiones futuras.

Nota:
Para obtener más detalles, consulte las siguientes fuentes:
● Nota SAP 2396214: Transición a servicios ampliados de SAP HANA avanzados
y cockpit de SAP HANA - Desvanecimiento de XS Classic y HANA Studio
● Nota SAP 2465027: obsolescencia de los servicios de aplicación ampliados de
SAP HANA, modelo clásico y repositorio de SAP HANA
● Nota SAP 2325817: Migración de vistas de análisis, vistas de atributo y vistas
de cálculo basadas en script a vistas de cálculo gráfico
● Nota SAP 2493252: SAP HANA XS Advanced Migration Assistant 1
● Migración de vista de información SAP HANA https://service.sap.com/
~sapidb/012002523100010024602017
● Resumen de la migración de modelos de vista gráfica de SAP HANA al nuevo
entorno de desarrollo XSA https://blogs.sap.com/2017/09/01/overview-of-
migration-of-sap-hana-graphical-view-models-into-the-new-xsa-development-
environment/
● Guía de migración avanzada de SAP HANA XS https://help.sap.com/doc/
DRAFT/4b2182c05561496d83e2a32b7d22a625/2.0.03/en-US/
SAP_HANA_XS_Advanced_Migration_Guide_en.pdf

© Copyright. Reservados todos los derechos. 447

Capítulo 11 : Implementación de vistas nativas de SAP HANA

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Explicar las diferencias entre SAP HANA 1.0 y SAP HANA 2.0

448 © Copyright. Reservados todos los derechos.

 Capítulo 11

Evaluación de la formación

1. ¿Cuál de las siguientes opciones contiene la terminología correcta acerca de las

jerarquías?
Seleccione las respuestas correctas.

X A Una entidad de una jerarquía se denomina nodo

X B Los nodos que no tienen nodos superiores se denominan nodos huérfanos.

X C Los nodos que no tienen nodos subordinados se denominan nodos finales u hojas.

X D Una relación entre un nodo y su nodo superior se denomina árbol genealógico.

X E Una jerarquía con hojas en diferentes niveles es una jerarquía desequilibrada

2. A diferencia del esquema estrella clásico en el que los hechos se almacenan en la tabla de
hechos, en SAP HANA, se pueden utilizar varias vistas para representar la vista de hechos
central en un modelo de datos virtual.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

3. ¿Cuál de las siguientes opciones es necesaria para realizar la conversión de moneda en un

modelo de información SAP HANA?
Seleccione las respuestas correctas.

X A Se requiere una conexión interna entre las medidas de la vista Open ODS y la tabla
de tipos de cambio

X B Se requiere un conjunto de tablas técnicas para almacenar monedas y tipos de

cotización y tipos de cambio

X C Fijar un tipo semántico en un indicador para que el importe incluya siempre una
moneda

X D Almacenar la moneda y el tipo de cambio el día de la transacción mejorará el

rendimiento

X E Una interfaz para definir cómo se debe procesar la conversión de moneda

© Copyright. Reservados todos los derechos. 449

Capítulo 11 : Evaluación de la formación

4. ¿Qué entorno de tiempo de ejecución se recomienda para los nuevos modelos nativos?
Seleccione la respuesta correcta.

X A XS clásico

X B XS avanzado

X C S/4HANA ABAP

450 © Copyright. Reservados todos los derechos.

 Capítulo 11

Respuestas a la Evaluación de la formación

1. ¿Cuál de las siguientes opciones contiene la terminología correcta acerca de las

jerarquías?
Seleccione las respuestas correctas.

X A Una entidad de una jerarquía se denomina nodo

X B Los nodos que no tienen nodos superiores se denominan nodos huérfanos.

X C Los nodos que no tienen nodos subordinados se denominan nodos finales u hojas.

X D Una relación entre un nodo y su nodo superior se denomina árbol genealógico.

X E Una jerarquía con hojas en diferentes niveles es una jerarquía desequilibrada

¡Ha acertado! En una jerarquía, las entidades se denominan nodos, los nodos sin hijos son
hojas y las jerarquías con hojas en diferentes niveles están desequilibradas. Los nodos sin
nodos superiores se denominan nodos raíz. Una relación entre un nodo superior e inferior
es un enlace. Leer más en el módulo Uso de datos maestros en vistas de SAP HANA, en el
curso BW430.

2. A diferencia del esquema estrella clásico en el que los hechos se almacenan en la tabla de
hechos, en SAP HANA, se pueden utilizar varias vistas para representar la vista de hechos
central en un modelo de datos virtual.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! En lugar de guardar datos de forma persistente en una tabla de hechos
central, SAP HANA puede proporcionar los datos utilizando vistas utilizando un join en
estrella. Leer más en el módulo Uso de indicadores en vistas de SAP HANA, en el curso
BW330H.

© Copyright. Reservados todos los derechos. 451

Capítulo 11 : Respuestas a la Evaluación de la formación

3. ¿Cuál de las siguientes opciones es necesaria para realizar la conversión de moneda en un

modelo de información SAP HANA?
Seleccione las respuestas correctas.

X A Se requiere una conexión interna entre las medidas de la vista Open ODS y la tabla
de tipos de cambio

X B Se requiere un conjunto de tablas técnicas para almacenar monedas y tipos de

cotización y tipos de cambio

X C Fijar un tipo semántico en un indicador para que el importe incluya siempre una
moneda

X D Almacenar la moneda y el tipo de cambio el día de la transacción mejorará el

rendimiento

X E Una interfaz para definir cómo se debe procesar la conversión de moneda

¡Ha acertado! El modelado de conversión de moneda en SAP HANA incluye el uso de las
tablas técnicas para monedas y tasas, la configuración de un tipo semántico para incluir
moneda y una interfaz que debe utilizarse para determinar cómo debe tener lugar la
conversión. Los joins internos de una medida con la tabla de tipos de cambio no son
posibles. Almacenar los tipos de cambio diarios junto con los datos de transacción no
sería un diseño eficaz. Leer más en el módulo Uso de datos transaccionales en vistas de
SAP HANA, en el curso BW430.

4. ¿Qué entorno de tiempo de ejecución se recomienda para los nuevos modelos nativos?
Seleccione la respuesta correcta.

X A XS clásico

X B XS avanzado

X C S/4HANA ABAP

Es correcto. En una versión de SAP HANA futura importante, ya no se admitirá XS clásico.

Por lo tanto, XS avanzado es el framework de aplicación recomendado para las vistas de
SAP HANA. Leer más en el módulo Diferencias de modelado entre SAP HANA 1.0 y SAP
HANA 2.0, en el curso BW430.

452 © Copyright. Reservados todos los derechos.

CAPÍTULO 12 Implementación de escenarios
mixtos

Lección 1
El objetivo de los escenarios mixtos 455

Lección 2
Integración de vistas de cálculo de SAP HANA en BW/4HANA 465

Lección 3
Generar vistas SAP HANA externas desde objetos SAP BW/4HANA 467

Lección 4
Modelado e implementación de escenarios mixtos 477

OBJETIVOS DEL CAPÍTULO

● Explicar la integración de HDI con SAP BW/4HANA

● Explicar el objetivo de los escenarios mixtos
● Integrar vistas de cálculo de SAP HANA en SAP BW/4HANA
● Generar vistas SAP HANA externas a partir de objetos SAP BW/4HANA
● Consumir vistas SAP HANA externas generadas

© Copyright. Reservados todos los derechos. 453

Capítulo 12 : Implementación de escenarios mixtos

454 © Copyright. Reservados todos los derechos.

 Capítulo 12
Lección 1
El objetivo de los escenarios mixtos

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Explicar la integración de HDI con SAP BW/4HANA
● Explicar el objetivo de los escenarios mixtos

Integración de HDI con SAP BW/4HANA

Figura 332: Escenario empresarial: Generación de vistas de SAP HANA

Su empresa, ITelO, ha creado un modelo de datos de ventas con el enfoque de SAP BW/
4HANA (con acceso virtual o datos persistentes). Los datos de compra adicionales ya están
disponibles en las vistas de cálculo de SAP HANA. Al acceder a los datos de SAP BW/4HANA
con SQL y las funciones de cálculo en SAP HANA, la vista de cálculo de compras debe
combinarse con los datos de ventas para responder a preguntas urgentes:
● ¿Qué productos se compraron en Alemania y se vendieron a otros países al menos 30 días
después?
● Para todos los países, verifique las diferencias entre los 5 productos de venta principales y
los 5 productos de compra principales.

Sería útil generar una clasificación para productos vendidos por país, similar a una
clasificación de compras existente, y procesar una consulta SQL para encontrar las
diferencias.

© Copyright. Reservados todos los derechos. 455

Capítulo 12 : Implementación de escenarios mixtos

Figura 333: Escenarios mixtos: Aspectos del modelado en diferentes mundos

Un escenario mixto (también llamado modelo híbrido) fusiona los datos de propiedad y
modelados en SAP BW/4HANA (esquema gestionado por SAP BW/4HANA) con los datos
propiedad de y modelados fuera de SAP BW/4HANA, en un esquema gestionado
externamente. Esto significa que las funciones, los datos y los metadatos de SAP BW/4HANA
y SAP HANA se combinan para obtener más información y flexibilidad.
Primero, veamos cómo los datos de cualquier esquema externo pueden estar disponibles en
SAP BW/4HANA mediante vistas Open ODS y CompositeProviders. A continuación,
aprenderá a hacer que los datos de SAP BW/4HANA estén disponibles en un esquema de
SAP HANA gestionado externamente.

Utilización de modelos de SAP HANA en BW/4HANA

Es posible consumir modelos XS Classic y modelos avanzados XS uno al lado del otro. Con
SAP HANA 2.0, la nueva infraestructura de despliegue (SAP HANA Deployment Infrastructure
(HDI)) y el entorno XS Advanced (XSA) son los nuevos estándares para el procesamiento de
aplicaciones. SAP recomienda pasar gradualmente a modelos avanzados de XS.
La integración de las vistas nativas de SAP HANA se admite en SAP BW/4HANA 2.0 de la
siguiente manera:

456 © Copyright. Reservados todos los derechos.

 Lección: El objetivo de los escenarios mixtos

Figura 334: Consumir vistas HANA

1. Puede consumir vistas de cálculo XS clásico o XS avanzado (HDI) directamente en

InfoObjetos con el tipo de acceso Vista SAP HANA, en vistas Open ODS y
CompositeProviders.
2. Puede integrar las vistas de cálculo clásicas XS o XS avanzadas (HDI) utilizando fuentes de
datos HANA_LOCAL para transformar sus datos mediante transformaciones BW. Esto se
explica en Formación BW450.
3. Puede generar sinónimos en un contenedor HDI para las vistas de cálculo de SAP HANA
clásicas de XS existentes.

Integración de modelos gestionados de BW/4HANA en vistas nativas de SAP HANA

Puede integrar modelos en la otra dirección. En SAP BW/4HANA, puede crear vistas de SAP
HANA externas (vistas de cálculo de SAP HANA) en modelos de datos de InfoSitio de SAP
BW/4HANA y consultas BW. Estas vistas de SAP HANA apuntan directamente a datos y
tablas gestionados por SAP BW/4HANA. Por lo tanto, los datos de SAP BW se pueden
consumir directamente en SAP HANA y sus interfaces. Esto también proporciona una interfaz
clara entre el esquema gestionado por SAP BW/4HANA y un área fuera de SAP BW/4HANA,
gestionada por otras herramientas u otro grupo de usuarios. Esta interfaz aclara dónde
terminan los servicios en SAP BW/4HANA y dónde comienzan las mejoras o mejoras
manuales con herramientas de terceros.
Las vistas de SAP HANA no se despliegan en HDI, pero siguen en el entorno clásico de SAP
HANA XS por los siguientes motivos:
● HDI no contiene funciones que sean relevantes para las vistas externas de SAP HANA
generadas desde BW/4HANA.
● El despliegue clásico es estable y más fácil de soportar.
● No se necesita migración y todos los escenarios de modelado mixto existentes están
cubiertos.
● Para los casos de uso de modelado mixto, las vistas de cálculo de HANA clásicas
generadas se pueden consumir mediante contenedores HDI en el entorno de modelado

© Copyright. Reservados todos los derechos. 457

Capítulo 12 : Implementación de escenarios mixtos

avanzado de SAP HANA XS configurando un llamado sinónimo de SAP HANA que

representa el acceso a un objeto en un esquema clásico.

Figura 335: Acceso a vistas de cálculo clásicas de XS desde XS Advanced y sus vistas de cálculo de HDI

Antes de poder crear un sinónimo, la base de datos o el administrador de XSA crea un servicio
personalizado proporcionado por el usuario (CUPS) para acceder al esquema de base de
datos clásico, que, como concepto, es similar a la configuración de una conexión ODBC. Lo
ejecuta un usuario técnico. Después, un rol de seguridad XSC, que tiene todos los privilegios
necesarios en el esquema clásico, tendrá que crearse en el entorno de origen.
Basándose en esto, se puede crear un archivo Grantor con la combinación de CUPS y el rol de
seguridad de XSC para proporcionar acceso al propietario del contenedor XSA HDI de
destino. Finalmente, es posible configurar un sinónimo que apunte a los objetos de esquema
clásicos desde el contenedor HDI. Este sinónimo se puede utilizar como objetos XSA locales
para modelar vistas de cálculo HDI.

Nota:
Para obtener más detalles, consulte las siguientes fuentes:
● Nota SAP 2463612: Soporte de vistas de cálculo de HDI con SAP BW en HANA
y SAP BW/4HANA
● Nota SAP 2810348: Las vistas de cálculo de HDI no están disponibles para su
consumo en BW/4HANA
● Nota SAP 2729983: Soporte para combinar vistas de modelado creadas en
HANA Studio y en Web IDE
● Blog: Escenarios mixtos de SAP BW/4HANA con contenedores HANA HDI
nativos https://blogs.sap.com/2020/02/21/bw-4-hana-mixed-scenarios-
with-native-hana-hdi-containers/
● Blog: "XS Advanced DB Access Scenarios – Overview" https://blogs.sap.com/
2019/08/02/xs-advanced-db-access-scenarios-overview/

458 © Copyright. Reservados todos los derechos.

 Lección: El objetivo de los escenarios mixtos

Ejemplos típicos de escenarios mixtos

Figura 336: Escenarios mixtos: ejemplos 1 y 2

En los dos ejemplos de un escenario mixto de la figura, Ejemplos de escenarios mixtos 1 y 2, la

parte izquierda muestra una adquisición de datos completa en SAP BW/4HANA. El modelado
en SAP BW/4HANA se ha ampliado con vistas SAP HANA modeladas adicionales sobre las
vistas SAP HANA externas generadas. Utilice aplicaciones de terceros basadas en SQL o
clientes BI para la generación de informes basada en SAP BW/4HANA, o SAP
BusinessObjects Lumira para el acceso en línea a datos de SAP BW/4HANA, o SAP
BusinessObjects Predictive Analytics para la adquisición de datos de SAP BW/4HANA.
El lado derecho de la figura anterior, Escenarios mixtos, ejemplos 1 y 2, muestra la adquisición
de datos en SAP HANA. El modelado se realiza principalmente en SAP HANA y se mejora con
Transformación adicional, Virtualización (unión o unión) o lógica de consulta sofisticada. El
uso de datos es por parte de la generación de informes de SAP BW/4HANA. Por ejemplo, SAP
BusinessObjects Analysis, SAP BusinessObjects Design Studio, etc.

© Copyright. Reservados todos los derechos. 459

Capítulo 12 : Implementación de escenarios mixtos

Figura 337: Escenarios mixtos: ejemplo 3

El tercer ejemplo de escenarios mixtos que se muestra en la figura, Escenarios mixtos -

Ejemplo 3, es el mismo que el lado izquierdo del primer ejemplo. Sin embargo, también se
incluyen otros datos externos en SAP HANA. Por ejemplo, los datos transaccionales pueden
gestionarse fuera de SAP BW/4HANA, pero los datos maestros de SAP BW (InfoObjetos) se
reutilizan para enriquecer los datos transaccionales.

460 © Copyright. Reservados todos los derechos.

 Lección: El objetivo de los escenarios mixtos

Figura 338: Escenarios mixtos: ejemplo 4

También hay escenarios en los que tiene sentido publicar datos en una dirección para utilizar
una función de procesamiento que no está disponible en el entorno original. Después, el
resultado se devuelve a la fuente original. Por ejemplo, publicar datos de SAP BW/4HANA en
SAP HANA, procesarlos dentro de una vista de cálculo y reintegrar el resultado en SAP BW/
4HANA para que pueda notificar el resultado en función de las consultas de SAP BW/4HANA.
El cuarto ejemplo de escenarios mixtos que se muestra en la figura, Escenarios mixtos:
ejemplo 4, es el mismo que el lado izquierdo del primer ejemplo. Sin embargo, SAP BW/
4HANA vuelve a realizar el consumo. En este ejemplo, la lógica de transformación nativa de
SAP HANA se añade al modelo de datos de SAP BW/4HANA. Esto se debe a que la misma
lógica sería más difícil de implementar en SAP BW/4HANA. Por ejemplo, contenido de SAP
BW/4HANA para pedidos retrasados SD. Lo mismo se podría hacer con datos externos
adicionales disponibles en SAP HANA basados en vistas de SAP HANA (en referencia al
ejemplo 3).
Hay algunos buenos ejemplos para el último escenario disponible en BI Content para SAP
NetWeaver BW. Tenga en cuenta que estos ejemplos no se suministran actualmente en el
add-on de contenido de SAP BW/4HANA.
En el siguiente escenario, los datos de SAP BW se exponen a SAP HANA como una vista
externa. Esta fuente se procesa con capacidades de modelado nativas de SAP HANA para
calcular ratios que no se pueden derivar fácilmente en transformaciones SAP BW.
Finalmente, la vista de cálculo resultante se integra de nuevo en la semántica de SAP BW
utilizando un CompositeProvider y una consulta SAP BW encima.

© Copyright. Reservados todos los derechos. 461

Capítulo 12 : Implementación de escenarios mixtos

Figura 339: Contenido mixto Escenario 1: Pedidos retrasados SD

La activación de este escenario mixto requiere lo siguiente:

● Dos vistas de cálculo de SAP HANA se generan automáticamente mediante la opción en
dos objetos DataStore (la casilla de selección Vista SAP HANA externa).
● Otra vista de cálculo de SAP HANA utiliza las dos vistas de cálculo de SAP HANA. El valor
añadido son varias columnas calculadas que generan nuevos ratios.
● Por último, un CompositeProvider consume esta vista de cálculo de SAP HANA y la vuelve
a integrar completamente en SAP BW/4HANA.

462 © Copyright. Reservados todos los derechos.

 Lección: El objetivo de los escenarios mixtos

Figura 340: Escenario mixto de contenido 2: Contabilidad de deudores FI

Otro ejemplo es el escenario mixto de Controlling financiero. Esta solución se basa en tablas
SAP ERP replicadas (BSAD, BSID, BKPF, T001) en SAP HANA y varias vistas de cálculo de
SAP HANA además de las que calculan una previsión de pago.

© Copyright. Reservados todos los derechos. 463

Capítulo 12 : Implementación de escenarios mixtos

Activación de contenido empresarial para escenarios mixtos

Figura 341: Activación de contenido empresarial para escenarios mixtos

Las vistas de cálculos de SAP HANA se crean automáticamente. En un segundo paso, puede
activar los modelos HANA de SAP HANA Live creados en la parte superior.

Información relacionada
Para obtener más información, consulte lo siguiente:
● Escenarios mixtos: SAP BW/4HANA y datamart de SAP HANA: https://archive.sap.com/
documents/docs/DOC-59762
● Escenarios mixtos de SAP BW y SAP HANA: noticias, valor añadido y ejemplos de clientes:
https://archive.sap.com/documents/docs/DOC-46093
● Híbrido - Integración de datos de SAP HANA Live y SAP BW: https://blogs.sap.com/
2014/05/26/go-hybrid-sap-hana-live-sap-bw-data-integration/

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Explicar la integración de HDI con SAP BW/4HANA
● Explicar el objetivo de los escenarios mixtos

464 © Copyright. Reservados todos los derechos.

 Capítulo 12
Lección 2
Integración de vistas de cálculo de SAP HANA
en BW/4HANA

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Integrar vistas de cálculo de SAP HANA en SAP BW/4HANA

Integración de vistas de cálculo de SAP HANA en SAP BW/4HANA

Existen dos opciones y la forma de elegir depende de la aplicación y la estrategia de gestión
de informes. ¿Se centra en los servicios de SAP BW/4HANA o en conceptos nativos de SAP
HANA? ¿Su estrategia de informes se basa en la generación de informes tradicional de SAP
BW/4HANA o en otros clientes de BI?

Figura 342: Integración de vistas de cálculo XSA en modelos de SAP BW/4HANA

1. En XS avanzado, las vistas de cálculo se despliegan en un contenedor HDI. Está aislado a

otros contenedores y también a esquemas de base de datos clásicos.
2. Para proporcionar el acceso en el contenedor HDI, el sistema genera un rol de acceso que
debe concederse al usuario con el que SAP BW/4HANA accede a SAP HANA. En la instalación
BW430 se trata del usuario SAPCIA. El rol se puede conceder manualmente o mediante
procedimientos almacenados estándar.
3. Incluso después de conceder el rol, las vistas de cálculo del contenedor HDI no son visibles
para su consumo en un CompositeProvider. Se requiere una configuración de personalización
especial, HANA Development Infrastructure (HDI) o Modo híbrido: HDI y XS clásico para
permitir el consumo de contenedores HDI en CompositeProviders. Para obtener más

© Copyright. Reservados todos los derechos. 465

Capítulo 12 : Implementación de escenarios mixtos

información, consulte la nota SAP 2810348. Tenga en cuenta que esto solo es posible en SAP
BW/4HANA 2.0, no en SAP BW/4HANA 1.0.

Figura 343: Customizing general de BW/4HANA para activar las vistas de cálculo de HDI para el modelado

4. Por último, incluya la vista SAP HANA como proveedor parcial en BW/4HANA
CompositeProviders, o en una fuente de datos BW o una vista Open ODS.

Nota:
Consulte los siguientes blogs:
https://blogs.sap.com/2019/08/02/xs-advanced-db-access-scenarios-
overview/comment-page-1/#
https://blogs.sap.com/2017/11/15/hana-studio-eclipse-web-workbench-web-
ide-cloud-and-web-ide-for-hana/
https://blogs.sap.com/2018/01/24/the-easy-way-to-make-your-hdi-container-
accessible-to-a-classic-database-user/

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Integrar vistas de cálculo de SAP HANA en SAP BW/4HANA

466 © Copyright. Reservados todos los derechos.

 Capítulo 12
Lección 3
Generar vistas SAP HANA externas desde
objetos SAP BW/4HANA

RESUMEN DE LA LECCIÓN
Esta lección proporciona un resumen funcional de la función para generar vistas SAP HANA
externas basadas en InfoSitios de SAP BW.

Ejemplo empresarial
El objetivo empresarial de las funciones analizadas en esta lección se describe en la siguiente
lección sobre los escenarios mixtos.

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Generar vistas SAP HANA externas a partir de objetos SAP BW/4HANA

Generación de vistas SAP HANA externas

Ha cargado datos en modelos BW/4HANA y desea ampliar estos modelos con funciones
nativas de SAP HANA.

Figura 344: Integración de modelos de SAP BW/4HANA en vistas de cálculo de XSA

La imagen, Integración de modelos de SAP BW/4HANA en las vistas de cálculo de XSA,

muestra tres pasos:

© Copyright. Reservados todos los derechos. 467

Capítulo 12 : Implementación de escenarios mixtos

1. Generar una vista SAP HANA en un esquema gestionado externamente basado en

modelos BW/4HANA. Puede generar una vista de cálculo basada en un InfoObjeto, un
aDSO o un CompositeProvider. Después de haber generado una vista de cálculo para el
modelo subyacente, se puede generar una vista basada en una consulta BW.

2. La vista generada está disponible automáticamente en el repositorio de SAP HANA para

su uso posterior en el modelado de vistas de cálculo clásico XS. Sin embargo, no está
disponible directamente en contenedores XS Advanced HDI. Un administrador debe crear
un servicio de proveedor de usuarios personalizado (tazas) en el espacio en el que desea
continuar desarrollando. En cada contenedor HDI que necesita acceder a la vista
generada, debe desplegar subvenciones y un sinónimo con un nombre nuevo para la vista
de cálculo generada.

3. Por último, otras vistas de SAP HANA pueden consumir vistas de cálculo de contenedor
HDI. Además, todas las aplicaciones que pueden leer las vistas de SAP HANA pueden
procesar los datos. Por ejemplo, los clientes de SAP BusinessObjects Reporting, así como
los clientes BI de proveedores externos.

Nota:
No modifique manualmente las vistas SAP HANA generadas. El sistema
sobrescribe la vista SAP HANA generada por SAP BW/4HANA cuando el objeto
original se vuelve a activar. Esto significa que se perderían las modificaciones
manuales.

Figura 345: De SAP BW/4HANA a SAP HANA

Generación de vistas de SAP HANA desde objetos de SAP BW/4HANA

La generación de vistas SAP HANA externas desde el sistema SAP BW/4HANA permite
generar vistas de cálculo SAP HANA sin utilizar el modelador SAP HANA o Web IDE. Estas
vistas se generan durante el proceso de activación de objetos de SAP BW/4HANA si
selecciona la opción Vista externa de SAP HANA en la pantalla de actualización de objetos de

468 © Copyright. Reservados todos los derechos.

 Lección: Generar vistas SAP HANA externas desde objetos SAP BW/4HANA

SAP BW/4HANA. Si el objeto BW/4HANA está activado sin esta opción, se borrarán las vistas
correspondientes. Esto se denomina el concepto “push”.
Los siguientes tipos de objeto de SAP BW/4HANA admiten esta función:
● InfoObjetos (para datos maestros)
● Objetos DataStore avanzados
● CompositeProviders
● Consultas SAP BW (aplicar la parametrización en la transacción RSDDB para índice de
instantánea de consulta)
● CompositeProviders locales modelados en SAP BW/4HANA Workspace Designer

En la transacción RS2HANA_VIEW, defina en qué paquete de contenido de SAP HANA se

generan las vistas. Estas vistas de SAP HANA forman parte del ciclo de vida normal del
InfoSitio de SAP BW/4HANA. Se transportan con los InfoSitios correspondientes y se
generan en la base de datos SAP HANA del SAP BW/4HANA de destino en el sistema SAP
HANA.
La transacción RS2HANA_ADMIN enumera todas las vistas SAP HANA generadas existentes y
los objetos BW/4HANA correspondientes. De hecho, la vista combina el hecho
correspondiente, los datos maestros y las tablas de texto en el esquema de SAP BW/4HANA.
Contiene filtros para la fecha clave y el idioma de trabajo. Si los datos de ADSO también se
gestionan en almacenamiento nearline, la vista SAP HANA generada incluye estas particiones
NLS en el modelo.
Cuando se ejecuta una consulta en la vista SAP HANA, los datos se solicitan directamente
desde SAP HANA, sin que se aborde la capa ABAP de SAP BW. Esto significa que las
funciones de SAP BW/4HANA, como la caché y el motor OLAP, no se utilizan. Por lo tanto, las
autorizaciones no las gestiona SAP BW/4HANA, sino las autorizaciones de SAP HANA
correspondientes.

© Copyright. Reservados todos los derechos. 469

Capítulo 12 : Implementación de escenarios mixtos

Figura 346: Gestión de autorizaciones de las vistas HANA generadas

Los privilegios analíticos de SAP HANA se crean durante la activación de los objetos BW/4
basados en las autorizaciones existentes de SAP BW/4HANA (nivel de objeto y nivel de fila).

Figura 347: Generación de autorizaciones de SAP HANA

470 © Copyright. Reservados todos los derechos.

 Lección: Generar vistas SAP HANA externas desde objetos SAP BW/4HANA

En SAP HANA y SAP BW/4HANA, existen varios requisitos previos para la correcta
configuración de la generación de vistas de SAP HANA externas.
En SAP HANA, para acceder a las vistas de SAP HANA que se han generado desde SAP BW/
4HANA, necesita las siguientes autorizaciones:
● Privilegio de objeto: SELECT en privilegio de objeto _SYS_BI
● EXECUTE en la autorización de paquete REPOSITORY_REST(SYS)
● REPO.READ en el paquete de contenido donde se almacenan las vistas SAP HANA
generadas.
● El mandante de sesión debe corresponderse con el mandante del sistema SAP BW/
4HANA. Si gestiona la asignación de autorizaciones en roles, esto solo será válido para el
usuario SAP<SID>. Si prefiere una asignación directa de privilegios, es necesaria para
todos los usuarios de SAP HANA que deberían poder ver los datos de las vistas generadas.

Los requisitos previos en la aplicación SAP BW/4HANA para generar vistas SAP HANA a
partir de objetos SAP BW/4HANA y utilizar sus datos son los siguientes:
● Debe existir una asignación explícita del usuario de la aplicación SAP BW/4HANA al
usuario de SAP HANA. A diferencia de SAP BW 7.x en SAP HANA, esta asignación debe
definirse manualmente en la administración central de usuarios de SAP BW/4HANA.
Las condiciones previas para activar la pestaña DBMS en la actualización de usuarios
(transacción SU01) son las siguientes:

- Defina una conexión de base de datos en la tabla DBCON con la Descripción de la vista
de modificación de conexiones de base de datos: Resumen (transacción DBCO) para el
usuario de base de datos y el tipo de base de datos HDB.
- Actualice la vista USR_DBMS_SYSTEM en la transacción SM30 para ampliar la
actualización de usuarios de SAP BW (transacción SU01) con una nueva función DBMS
para especificar esta asignación.

Los usuarios de SAP HANA se pueden crear mediante el informe RSUSR_DBMS_USERS.

Para obtener más detalles, consulte la nota SAP 1927767.
● Se deben crear autorizaciones de análisis de SAP BW/4HANA. Defínalos para todas las
características marcadas como relevantes para autorización en el InfoSitio
correspondiente. También deben contener todas las características técnicas del InfoSitio
(0TCAVALID, 0TCAIPPROV), los ratios (0TCAKYFNM) y la actividad (0TCAACTVT).
Asigne estas autorizaciones de análisis al usuario de SAP BW/4HANA.
● Configure el tipo, el tipo de asignación y la asignación de usuario correctamente en la
imagen SAP BW/4HANA (transacción RS2HANA_VIEW).

© Copyright. Reservados todos los derechos. 471

Capítulo 12 : Implementación de escenarios mixtos

Figura 348: Customizing general de esta función (transacción RS2HANA_VIEW)

Consejo:
En caso de que haya problemas al consultar la vista SAP HANA, puede utilizar la
transacción RS2HANA_CHECK para verificar si todas las opciones de autorización
son correctas (consulte la nota SAP 2031522 y la nota SAP 2103553). Para
obtener un resumen detallado de la configuración de autorizaciones para vistas
SAP HANA externas, consulte la Ayuda de SAP.

Restricciones
No todas las propiedades del InfoSitio se pueden añadir a las vistas de SAP HANA generadas.
No se admiten las siguientes propiedades:
● Conversión ALPHA y conversión de fecha
● Visualizar atributos
● Los ratios no acumulativos solo se admiten en la vista SAP HANA para consultas
● Ratios para los que la agregación está fijada en Sin agregación
● Ratios del tipo de datos fecha u hora relacionados con la agregación SUM
● El ratio técnico 1ROWCOUNT solo se admite para consultas DataStore-Object (avanzado),
CompositeProvider y BW, que se basan en un DataStore-Object (avanzado) o en un
CompositeProvider.
● Para obtener información sobre las restricciones relacionadas con los datos en el
almacenamiento nearline, consulte la nota SAP 2032797 - Vista SAP HANA externa: Incluir
datos NLS con HANA Smart Data Access
● Para obtener información sobre las restricciones relacionadas con los ratios no
acumulativos en aDSO, consulte la Unidad 11, Otros temas de modelado en SAP BW/
4HANA de este curso.

472 © Copyright. Reservados todos los derechos.

 Lección: Generar vistas SAP HANA externas desde objetos SAP BW/4HANA

● Las restricciones adicionales para InfoObjetos son las siguientes:

- Debe ser una característica con datos maestros y textos.
- El acceso a datos maestros debe ser estándar o vista SAP HANA.
- No se ha marcado la casilla de selección Solo atributo.
- El InfoObjeto no debe tener ningún atributo de navegación que sea relevante para
autorización y cuyo acceso a datos maestros no sea estándar.
- Las características compuestas se añaden como InfoObjetos simples; la propiedad de
relación se pierde y no hay valores concatenados.
- Las jerarquías de SAP BW requieren SAP BW 7.5 y solo están disponibles en las vistas
de SAP HANA para InfoObjetos.
- La fecha clave para atributos y textos dependientes del tiempo se especifica mediante
la fecha clave del parámetro de entrada de la vista SAP HANA. Si este parámetro no se
proporciona explícitamente con datos cuando se produce el acceso, se utiliza el día
actual. El formato del parámetro es AAAAMMDD, que corresponde al tipo DATS de
ABAP.

Generación de vista de SAP HANA para consultas de SAP BW

El gestor analítico compila las consultas en un plan de ejecución optimizado. Esto significa
que la mayoría de las partes se ejecutan en SAP HANA y solo una pequeña parte en el
servidor de aplicación SAP BW. En muchos casos, el conjunto de resultados es complejo y
multidimensional.
Sin embargo, en algunos casos, el resultado de la consulta se muestra como una vista plana y
se puede calcular completamente en SAP HANA. Para estas consultas, se puede generar una
vista de cálculo de SAP HANA desde SAP BW. Esta vista se puede utilizar con interfaces
nativas de SAP HANA como SQL.
Una vista de cálculo de SAP HANA, que se ha creado a partir de su consulta SAP BW, no se
puede comparar con otras interfaces de consulta como BICS. Esto se debe a que la vista de
cálculo de SAP HANA no puede realizar cálculos como jerarquías, supresión de ceros o
cálculos locales, que normalmente se realizan en el servidor de aplicaciones SAP BW.
Por lo tanto, no hay ninguna garantía de que el resultado de la vista de cálculo de SAP HANA
sea exactamente el mismo que el resultado de la consulta ejecutada en el servidor de
aplicación SAP BW/4HANA. Aquí, las restricciones de la vista SAP HANA del InfoSitio, en la
que se basa la consulta, también se aplican a la consulta. Si modifica la consulta en las
herramientas de modelado de SAP BW, la vista SAP HANA asociada se actualiza
automáticamente. Sin embargo, los elementos globales no se actualizan. Si se modifican
elementos globales, estos elementos solo se modifican en la consulta, una vez que la consulta
se vuelve a activar. La vista SAP HANA asociada también se actualiza.
Requisitos previos
Los requisitos previos son los siguientes:
● Los InfoSitios admitidos son DataStore-Object (avanzado) o CompositeProvider.
● La casilla de selección Vista SAP HANA externa debe estar marcada para el InfoSitio en el
que se define la consulta.
● Esta consulta no está lista para la entrada y no contiene funciones no admitidas como filtro
en una jerarquía, cálculo de fórmulas, selección constante, definiciones en una celda o

© Copyright. Reservados todos los derechos. 473

Capítulo 12 : Implementación de escenarios mixtos

agregación de excepción. Para todas las funciones admitidas, consulte la Ayuda de SAP
BW/4HANA.

Aunque la vista SAP HANA aún se puede generar, las siguientes funciones de SAP BW/
4HANA se ignoran:
● Opciones de visualización de jerarquía
● Valores de propuesta para características
● Estructuras
● Condiciones
● Excepciones
● Cálculos locales
● Opciones de visualización (por ejemplo, el número de decimales)
● Supresión de ceros
● Propiedades de query adicionales (modo caché, modo de lectura, modo de
almacenamiento nearline)
● Ratios ocultos
● Visualizar atributos
● Clase de acceso para valores de resultado (la clase siempre es valores contabilizados)

Para ratios no acumulativos, consulte la nota SAP 2032830 - Vista SAP HANA externa: Ratios
de inventario (ratios no acumulativos).
Las siguientes funciones no se admiten para generar vistas SAP HANA a partir de consultas:
● Selección constante
● Definiciones en una celda
● Agregación de excepción

Nota:
Esta lista no es exhaustiva. Supongamos que no se admite nada que no esté
incluido en la lista de funciones de SAP BW admitidas. Si alguna de estas
funciones se encuentra en la consulta, las vistas de SAP HANA no se pueden
generar.

Administración de vistas SAP HANA externas

Además de la transacción SAP GUI RS2HANA_ADMIN, también hay una función de cockpit de
BW/4HANA Gestionar vistas que le proporciona un resumen de todos los objetos SAP BW/
4HANA con una vista SAP HANA externa en todo el sistema, junto con las siguientes
funciones de administración y verificación:
● Verificar vista externa
● Reparar vista externa
● Log para jobs de reparación

474 © Copyright. Reservados todos los derechos.

 Lección: Generar vistas SAP HANA externas desde objetos SAP BW/4HANA

● Herramienta de verificación de consistencia, principalmente para la configuración de

autorizaciones (transacción RS2HANA_CHECK)

En el Customizing (o transacción GUI RS2HANA_VIEW) puede realizar las siguientes

funciones:
● Definir el paquete de contenido estándar de SAP HANA
● Visualizar propiedades como el motor de ejecución
● Efectuar parametrizaciones para las autorizaciones generadas

Figura 349: Administración de vistas SAP HANA externas

Información relacionada
Para obtener más información, consulte lo siguiente:
● Primera orientación de SAP - Generación de vista de SAP BW 7.4 SAP HANA: https://
archive.sap.com/documents/docs/DOC-52790
● Nota de SAP: 2317197 - Vista de SAP HANA externa: preguntas frecuentes, disponibilidad
de características
● Guía de modelado de SAP HANA: http://help.sap.com/hana/
SAP_HANA_Modeling_Guide_en.pdf

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Generar vistas SAP HANA externas a partir de objetos SAP BW/4HANA

© Copyright. Reservados todos los derechos. 475

Capítulo 12 : Implementación de escenarios mixtos

476 © Copyright. Reservados todos los derechos.

 Capítulo 12
Lección 4
Modelado e implementación de escenarios
mixtos

RESUMEN DE LA LECCIÓN
En esta lección se presenta el modelado híbrido en SAP BW/4HANA. Abarca el intercambio
de objetos SAP BW y vistas nativas de SAP HANA para su uso en varios escenarios de uso y
modelado flexibles. Analizaremos la interacción de los datos de propiedad y modelados en
SAP BW/4HANA (esquema gestionado por BW) y los datos propiedad y modelados fuera de
SAP BW (esquema externo), pero con capacidades de modelado nativo de SAP HANA.

Ejemplo empresarial
Desea utilizar el conjunto completo de funciones en SAP HANA. En lugar de integrar todos los
datos en SAP BW de la forma clásica, planea utilizar el concepto de escenarios mixtos. Su
organización acaba de implementar SAP BW/4HANA. Tiene algunos proyectos que requieren
funciones centrales de SAP HANA, la primera de las cuales es un proyecto de análisis
predictivo complejo, combinado con una función de búsqueda de conocimientos basada en la
web. Para ello, debe utilizar herramientas nativas de SAP HANA. Sin embargo, los datos
necesarios se encuentran en SAP BW. Por lo tanto, desea determinar la forma más fácil de
hacer que los datos de SAP BW estén disponibles en modelos nativos de SAP HANA. Desea
utilizar vistas generadas en SAP HANA Studio para crear modelos de datos propios utilizando
datos de SAP BW y algoritmos nativos de SAP HANA.

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Consumir vistas SAP HANA externas generadas

Consumir vistas SAP HANA externas generadas

Existe una gran ventaja para las vistas SAP HANA externas generadas: cada vez que se
modifica el objeto BW/4HANA subyacente, la vista SAP HANA se genera en función del
último modelo BW/4HANA.

© Copyright. Reservados todos los derechos. 477

Capítulo 12 : Implementación de escenarios mixtos

Figura 350: Escenarios mixtos que combinan BW y modelos nativos

Atención:
No modifique nunca una vista de cálculo generada porque todas las
modificaciones se sobrescribirán la próxima vez que se active el objeto BW.

Para ampliar una vista generada, cree una vista de cálculo nueva e integre la vista generada
con un nodo de proyección o agregación. En la parte superior, añada más nodos para
aprovechar las opciones relacionadas con la unión de datos y la realización de cálculos de
vistas de cálculo de SAP HANA.

Figura 351: Ampliación de una vista generada con un nodo de clasificación

Por ejemplo, el nodo Clasificación se puede utilizar para el análisis de tipo Top 5 o Bottom 5.
Si desea enumerar los cinco productos principales para cada país por separado, incluya la
columna de país como un atributo Partición por columna. La lista se generará para cada país
por separado.

478 © Copyright. Reservados todos los derechos.

 Lección: Modelado e implementación de escenarios mixtos

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Consumir vistas SAP HANA externas generadas

© Copyright. Reservados todos los derechos. 479

Capítulo 12 : Implementación de escenarios mixtos

480 © Copyright. Reservados todos los derechos.

 Capítulo 12

Evaluación de la formación

1. ¿Cuáles son los ejemplos típicos de escenarios mixtos?

Seleccione las respuestas correctas.

X A Adquisición de datos en SAP BW/4HANA y aplicación de lógica SQL en vistas SAP

HANA modeladas sobre las vistas SAP HANA generadas

X B Adquisición de datos en SAP HANA y aplicación de lógica BW en

CompositeProviders que solo contienen vistas de cálculo de SAP HANA

X C Adquisición de datos en SAP BW/4HANA y aplicación de lógica BW en

CompositeProviders que solo contienen aDSOs e InfoObjetos.

X D Adquisición de datos en SAP BW/4HANA y SAP HANA y aplicación de lógica BW

en CompositeProviders que solo contienen aDSOs y vistas de cálculo de SAP HANA

2. Para el sistema BW/4HANA, puede especificar el paquete de contenido de SAP HANA en

el que se encuentran las vistas SAP HANA externas generadas.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

© Copyright. Reservados todos los derechos. 481

 Capítulo 12

Respuestas a la Evaluación de la formación

1. ¿Cuáles son los ejemplos típicos de escenarios mixtos?

Seleccione las respuestas correctas.

X A Adquisición de datos en SAP BW/4HANA y aplicación de lógica SQL en vistas SAP

HANA modeladas sobre las vistas SAP HANA generadas

X B Adquisición de datos en SAP HANA y aplicación de lógica BW en

CompositeProviders que solo contienen vistas de cálculo de SAP HANA

X C Adquisición de datos en SAP BW/4HANA y aplicación de lógica BW en

CompositeProviders que solo contienen aDSOs e InfoObjetos.

X D Adquisición de datos en SAP BW/4HANA y SAP HANA y aplicación de lógica BW

en CompositeProviders que solo contienen aDSOs y vistas de cálculo de SAP HANA

¡Ha acertado! Se trata de un escenario BW/4HANA puro si combina la adquisición de

datos de BW/4HANA en InfoObjetos o aDSOs con lógica BW/4HANA en Proveedores
compuestos. Es un escenario de SAP HANA puro si combina la adquisición de datos en
SAP HANA solo con la lógica SQL. Siempre que combine funciones del escenario de SAP
BW/4HANA y del escenario de SAP HANA, esto se denomina escenario mixto. Leer más
en el módulo Ejemplos típicos de escenarios mixtos, en el curso BW430.

2. Para el sistema BW/4HANA, puede especificar el paquete de contenido de SAP HANA en

el que se encuentran las vistas SAP HANA externas generadas.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

Tienes razón. En la transacción RS2HANA_VIEW del sistema BW/4HANA, puede

especificar el paquete de contenido de SAP HANA en el que se encuentran las vistas SAP
HANA externas generadas. Leer más en el módulo Generación de vistas externas de SAP
HANA para objetos de SAP BW/4HANA, en el curso BW430.

482 © Copyright. Reservados todos los derechos.

CAPÍTULO 13 Otros temas de modelado en
SAP BW/4HANA

Lección 1
Introducción al proceso de análisis de SAP HANA (HAP) 485

Lección 2
Definición de escenarios de inventario 491

Lección 3
Cobertura de stock 507

Lección 4
Modo de planificación 511

OBJETIVOS DEL CAPÍTULO

● Presentar el proceso de análisis de SAP HANA (HAP)

● Crear ratios para no acumulativos
● Definir escenarios de inventario utilizando objetos DataStore (avanzados)
● Analizar la cobertura de stock
● Discutir el modo de planificación

© Copyright. Reservados todos los derechos. 483

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

484 © Copyright. Reservados todos los derechos.

 Capítulo 13
Lección 1
Introducción al proceso de análisis de SAP
HANA (HAP)

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Presentar el proceso de análisis de SAP HANA (HAP)

Aspectos básicos de Data Mining

Data Mining es el proceso de uso de algoritmos matemáticos y estadísticos para determinar
automáticamente patrones y relaciones interesantes que son difíciles de detectar en grandes
volúmenes de datos. Data Mining le proporciona hallazgos y relaciones que antes
permanecían ocultos o que no se tenían en cuenta, porque no se consideró posible
analizarlos. Como resultado, Data Mining puede ser un factor de éxito decisivo a medida que
la competencia se intensifica. Data Mining le permite convertir grandes volúmenes de datos
en información de alto valor. No solo proporciona información mediante el análisis de datos
pasados, sino que también es capaz de predecir tendencias y patrones de comportamiento
futuros. Data Mining permite a las organizaciones dar el salto crítico del análisis retrospectivo
a la toma de decisiones proactiva.

Figura 352: Relaciones ocultas en los datos

Las principales áreas de aplicación para los procedimientos de minería de datos son
generalmente las áreas de ventas y marketing, que requieren un análisis integral de los
clientes y su comportamiento. Sin embargo, los métodos también se pueden utilizar en
diferentes áreas. La siguiente figura, Fundamentos de Data Mining, muestra algunos ejemplos
de áreas de aplicación.

© Copyright. Reservados todos los derechos. 485

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

Figura 353: Aspectos básicos de Data Mining

Proceso de análisis SAP HANA (HAP)

Figura 354: Proceso de análisis de SAP HANA

Con SAP HANA Analysis Process (HAP), los usuarios de SAP BW pueden leer datos de una
fuente de datos, realizar una función para el análisis de datos y almacenar el resultado en un
destino de datos. HAP admite funciones de Predictive Analysis Library (PAL), L-Script, R-
Script o procedimientos de base de datos de SAP HANA autodesarrollados de la base de
datos de SAP HANA.
Se admiten las siguientes funciones PAL:
● Análisis ABC
● A priori
● Alisamiento exponencial doble

486 © Copyright. Reservados todos los derechos.

 Lección: Introducción al proceso de análisis de SAP HANA (HAP)

● Medios K
● Valores atípicos
● Alisamiento exponencial simple
● Alisamiento exponencial triple
● Tabla de puntuación ponderada
● Proyección

HAP ofrece lo siguiente:

● Procesamiento de funciones PAL nativas de SAP HANA directamente en datos de InfoSitio
de SAP BW.
● Procesamiento de procesos complejos e intensivos de datos en SAP HANA, sin perder la
integridad e integración con el entorno de SAP BW/4HANA.
● Materialización del resultado de un proceso de análisis de SAP HANA en SAP HANA para
su procesamiento posterior.
● Soporte de una ejecución en proceso de fondo planificada basada en cadenas de proceso
SAP BW.

Consejo:
Para obtener más detalles sobre PAL, consulte lo siguiente:http://
help.sap.com/hana/SAP_HANA_Predictive_Analysis_Library_PAL_en.pdf

Figura 355: Crear un HAP

El proceso se realiza exclusivamente en SAP HANA, por lo tanto, con un buen rendimiento.
Solo los InfoSitios, que se representan como una vista de columna en la base de datos de SAP
HANA, se admiten como fuentes de datos, principalmente aDSO e InfoObjetos. Si desea
almacenar los resultados en un InfoSitio BW, en lugar de escribir directamente en un destino

© Copyright. Reservados todos los derechos. 487

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

de datos SAP HANA, conecte el HAP con una transformación BW. A continuación, puede
combinar el HAP y las funciones del sistema SAP BW. Este será el escenario del siguiente
ejercicio. Con este diseño, el mismo HAP puede rellenar varios InfoSitios.

Creación de un proceso de análisis SAP HANA (HAP)

En el proceso de análisis de SAP HANA, no hay uniones. Si estas combinaciones son
necesarias, utilice un CompositeProvider de SAP BW como fuente. SAP HANA se puede
utilizar para el procesamiento y se puede garantizar un rendimiento satisfactorio si continúa
utilizando las funciones PAL nativas en SAP HANA.

Figura 356: Crear un HAP

Nota:
La fuente puede ser un proceso de análisis de SAP HANA, que le permite
concatenar un proceso de análisis tras otro. Si los resultados intermedios deben
ser persistentes, el destino y la fuente del proceso de análisis subsiguiente pueden
ser una tabla de base de datos. SAP proporciona funciones predefinidas, como el
análisis ABC.

Para crear un HAP

1. Utilice la transacción RSDHAAP o seleccione Proceso de análisis SAP HANA en el

Workbench / Árbol de modelado.

2. En la etiqueta Resumen, seleccione una fuente de datos.

3. Seleccione la función o el procedimiento para el análisis de datos.

4. Seleccione el destino de datos.

488 © Copyright. Reservados todos los derechos.

 Lección: Introducción al proceso de análisis de SAP HANA (HAP)

5. Realice las parametrizaciones necesarias en las etiquetas Fuente de datos, Definición del
procedimiento, Análisis de datos y Destino de datos.

6. Active su proceso de análisis. Cuando se activa, un proceso de análisis se puede

transportar a otros sistemas SAP BW/4HANA.

Nota:
El HAP no se puede transportar si la fuente de datos es un query como
InfoSitio o como índice analítico. Estos objetos solo se crean localmente.

7. Dispone de las siguientes opciones para ejecutar el proceso de análisis:

● Ejecute el proceso de análisis directamente.

● Prográmelo en proceso de fondo.

● Inserte el proceso de análisis en una cadena de procesos (transacción RSPC).

Seleccione el tipo de proceso Ejecutar proceso de análisis SAP HANA en los otros tipos
de proceso.

● Si ha especificado en su HAP que se puede utilizar en un proceso de transferencia de

datos, puede crear una transformación para ello. Para ello, seleccione Proceso de
análisis HANA al crear una transformación SAP BW como fuente.

Para seleccionar los componentes HAP correctos

1. La fuente de datos puede ser una de las siguientes:

● Cualquier InfoSitio de SAP BW/4HANA

● Cualquier tabla de base de datos de SAP HANA

● Otro HAP. Por lo tanto, HAP le permite ejecutar una serie de HAP en secuencia y solo
grabar el resultado final.

2. El análisis de datos puede ser uno de los siguientes:

● Función o script: una serie de funciones PAL seleccionadas de SAP HANA están
disponibles aquí. También puede añadir sus propias funciones PAL.

● Procedimiento: puede seleccionar un procedimiento que haya implementado en SAP

HANA Modeler como procedimiento de contenido. Se encuentran en un esquema
específico y se asignan a un paquete. Siempre se genera un procedimiento de
repository para un procedimiento de contenido. El proceso de análisis accede a estos
procedimientos de repository. La ventaja de implementar un procedimiento usted
mismo es que puede reutilizarlo más tarde. Siempre debe ocuparse del transporte
usted mismo.

3. El destino de datos puede ser uno de los siguientes:

● Índice analítico: está obsoleto. En su lugar, utilice un objeto DataStore avanzado

basado en el incrustado en DataTransferProcessoption.

● Tabla de base de datos SAP HANA

© Copyright. Reservados todos los derechos. 489

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

● Integrado en DataTransferProcess: Si selecciona esta opción, puede crear una

transformación en la que su proceso de análisis de SAP HANA sea el objeto de entrada.
Esto significa que el HAP se ejecuta y sus resultados se contabilizan en el destino del
DTP, según la lógica definida dentro de la regla de transformación. Debido a su
flexibilidad, esta es la opción recomendada para el destino de datos.

4. Guarde y active su proceso de análisis de SAP HANA.

Trabajar en el modo experto

A partir de SAP BW 7.4 SP7, hay un modo experto disponible que ofrece funciones
adicionales. Para abrir el modo de experto, seleccione Extras → Modo experto On/Off.
El modo experto tiene las siguientes funciones:
● Nuevo icono en la barra de herramientas: Exportar: puede exportar el proceso de análisis
de SAP HANA como un archivo XML para el análisis si se producen errores.
● Nuevo icono en la barra de herramientas: Registros - puede visualizar un resumen de todos
los registros existentes.
● Nuevo icono en la barra de herramientas: Ejecución de mantenimiento: puede simular la
ejecución del proceso de análisis de SAP HANA para la resolución de problemas.
● Etiqueta Nuevo escenario de cálculo: puede visualizar una simulación del tiempo de
ejecución del escenario de cálculo. El escenario de cálculo es la fuente para leer mientras
se ejecuta una consulta. Cuando se activa, se genera a partir del proceso de análisis. Los
cálculos se realizan al leer. La simulación del tiempo de ejecución le proporciona una
verificación de consistencia previa. Puede ver tanto la representación XML como la
definición de script. En la representación XML, puede seleccionar elementos subrayados
para navegar a ellos y visualizar datos de muestra. Esto le permite verificar si el resultado
es el que desea. Seleccionando Exportar escenario de cálculo, puede exportar la
simulación como un archivo XML para el análisis si se producen errores.
● Nueva etiqueta Consulta, donde el Monitor de consultas está integrado. Esto le permite
ejecutar consultas estándar para su proceso de análisis.

Además, RSDHAAP_MONITOR es una nueva transacción para supervisar ejecuciones HAP.

Información alineada

Para obtener más información, consulte lo siguiente:

● Documentación oficial de Predictive Analysis Library: http://help.sap.com/hana/
SAP_HANA_Predictive_Analysis_Library_PAL_en.pdf
● Primer documento de orientación Proceso de análisis de HANA BW 7.40: https://
archive.sap.com/documents/docs/DOC-56000

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Presentar el proceso de análisis de SAP HANA (HAP)

490 © Copyright. Reservados todos los derechos.

 Capítulo 13
Lección 2
Definición de escenarios de inventario

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Crear ratios para no acumulativos
● Definir escenarios de inventario utilizando objetos DataStore (avanzados)

Ratios no acumulativos en SAP BW

Los ratios no acumulativos se pueden utilizar para modelar, por ejemplo, modificaciones de
stock y balances de stock.

Figura 357: Modificaciones no acumuladas

Los valores acumulados son ratios que se acumulan utilizando todas las características (por
lo tanto, también utilizando el tiempo). Los valores no acumulativos son ratios que se miden
en relación a un período en el tiempo, por lo que no se pueden acumular de forma significativa
a lo largo del tiempo. Los valores no acumulativos se integran a lo largo del tiempo mediante
la agregación de excepción (en este caso, valor medio o último valor).
Los ratios no acumulativos son valores calculados según un período de tiempo determinado
(como un saldo inicial o inicial). A continuación, el valor se incrementa o disminuye en función

© Copyright. Reservados todos los derechos. 491

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

de una entrada o salida. Los niveles de inventario son un buen ejemplo: los niveles de
inventario se calculan en función de un saldo inicial del período de inicio y, a continuación, se
derivan de añadir los flujos de entrada netos y restar los flujos de salida de ese saldo inicial.
Los valores no acumulativos son ratios especiales que son diferentes de otros ratios (valores
acumulados) tanto en la transferencia de datos como en el comportamiento agregado.
Un ratio no acumulativo se modela en SAP BW mediante el campo relevante para el cambio
de valor no acumulativo de los campos relevantes para entradas y salidas en la actualización
de InfoObjetos. Puede determinar el valor no acumulativo actual o el valor no acumulativo en
un momento determinado, a partir del saldo final actual y los cambios de valor no
acumulativos o las entradas y salidas.

Modelado de ratios no acumulativos

Existen dos formas de definir ratios no acumulativos, como se indica a continuación:

● Un ratio no acumulativo (para saldo) con 1 ratio acumulativo (para modificación de valor)
Defina un ratio acumulativo adicional que contenga el cambio de valor no acumulado.
Un valor mayor que nulo representa una entrada, un valor menor que nulo representa una
salida.
● Un ratio no acumulativo (para saldo) con 2 ratios acumulativos (para entrada y salida)
Defina dos ratios acumulativos adicionales: uno para entradas y otro para flujos de salida.
● Los ratios acumulados (modificación de valor, entrada y salida) deben tener Agregación
como SUM. No se pueden definir como No acumulativos.
Deben tener el mismo tipo de datos (por ejemplo, importe, cantidad) que el ratio no
acumulado.
● El ratio No acumulado debe definirse con la agregación SUM, pero con la agregación de
excepción, por ejemplo, Primer valor, Último valor o Promedio con referencia a días
naturales.

492 © Copyright. Reservados todos los derechos.

 Lección: Definición de escenarios de inventario

Figura 358: Ratio no acumulado con entradas y salidas

Agregación de ratios no acumulativos

Los ratios para modificaciones de valor no acumulativo, o para entradas y salidas, son ratios
acumulativos normales; tienen la totalización como agregación y la agregación de excepción.
Los ratios no acumulativos siempre tienen la totalización como agregación estándar
(comportamiento de agregación en la base de datos). Sin embargo, una agregación de
excepción en el reporting no tiene totalización con referencia a una característica de tiempo.
No tiene totalización porque no tendría sentido totalizar valores no acumulativos a lo largo del
tiempo.
Para el ratio acumulado Ventas, es útil, por ejemplo, sumar las ventas individuales a lo largo
de diferentes períodos y utilizar características como Productos y Clientes.
A continuación se muestra un ejemplo de la diferencia entre ratios no acumulativos y ratios
acumulativos.
La cantidad de actividades de ventas de campo (ratio acumulado): Actividades de ventas de
campo 01 de enero + Actividades de ventas de campo 02 de enero + Actividades de ventas de
campo 03 de enero da el total de ventas para estos tres días.
Stock en almacén (ratio no acumulado): Stock 01 de enero + Stock de enero 02 + Stock de
enero 03 no indica el stock total de estos tres días.
Si agrega valores acumulados, como costes, se utiliza la agregación estándar (SUM, MIN o
MAX) para todas las características (incluidas las características de tiempo).
¿Cómo modelaría el ratio Stock de almacén? Es razonable esperar la totalización de
características (que no son características de tiempo) como producto o almacén. Con
referencia a una característica de tiempo, como el mes natural, el ratio no acumulativo Stock
de almacén normalmente tiene el último valor de agregación de excepción (LAS).

© Copyright. Reservados todos los derechos. 493

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

Figura 359: Agregación de excepción "Último valor" de ratios no acumulados

La figura, Agregación de excepción "Último valor" de ratios no acumulados muestra un

ejemplo de stock de almacén de material. Un valor no acumulativo devuelve un valor inicial
(no acumulativo inicial) y, a continuación, la información sobre los cambios. En el reporting,
debe ser posible realizar declaraciones concluyentes tanto para informes diarios como para
informes basados en un período de tiempo (en este caso, meses). De forma alternativa, el
promedio de agregación de excepción (AVG) o el último valor evita que los valores diarios
individuales se totalicen durante el período de tiempo.

Característica de referencia temporal

Puede haber varios ratios no acumulativos y varias características de tiempo para cada aDSO
de inventario, pero solo puede haber una característica de referencia temporal. Al actualizar
un aDSO con ratios no acumulativos, solo puede actualizar la característica de referencia
temporal y la variante de ejercicio. Todas las demás características de tiempo se derivan
automáticamente de la característica de referencia temporal. Por lo tanto, si hay diferentes
ratios no acumulativos de un modelo de inventario, debe ser lo suficientemente fino como
para derivar todas las características de referencia temporal.
Imagine que un aDSO contiene ratios de stock en almacén y desea evaluar el balance de
stocks para el mes natural y el número de vehículos de transporte para el año natural. En este
caso, el mes natural es lo suficientemente bueno como para derivar ambas características de
referencia temporal. La característica de referencia temporal no debe dejarse en blanco. Si
desea tener un valor no acumulado semanal y mensual en un aDSO al mismo tiempo, la
característica de tiempo más general es el día natural. La característica de tiempo Día natural
debe incluirse en el aDSO para que pueda funcionar como característica de referencia para la
agregación temporal.

494 © Copyright. Reservados todos los derechos.

 Lección: Definición de escenarios de inventario

Comparación del modelado de escenarios no acumulativos

El objetivo del almacenamiento especial de ratios no acumulativos es optimizar el transporte
de datos a SAP BW y optimizar el almacenamiento de datos y el acceso a la base de datos
durante la evaluación de informes en SAP BW.
Además del escenario "Modelado de valores no acumulativos con ratios no acumulativos"
descrito en la sección anterior, existe un escenario diferente "Modelar valores no
acumulativos con ratios normales (ratios acumulativos)".
Sin embargo, la situación determina si es útil o no "modelar valores no acumulativos con
ratios no acumulativos". Se recomienda utilizar el escenario "Modelar valores no
acumulativos con ratios no acumulativos" para áreas en las que los valores no acumulativos
no se modifican completamente de forma regular (por ejemplo, el stock en almacén o el
número de empleados).
La forma en que se asignan los valores no acumulativos en SAP BW depende de la situación.
En función de la frecuencia de modificación de los valores no acumulativos y de la cantidad
total de objetos para la que se deben determinar los valores no acumulativos, seleccione uno
de los dos escenarios siguientes:
● Gestión no acumulativa con ratios normales (ratios acumulativos): cada carga de datos
representa un movimiento. Aunque el modelo está diseñado para sumar los valores
individuales, aún es posible definir diferentes métodos de agregación en una consulta BW,
como listar el coste medio a lo largo de diferentes meses como una agregación de
excepción definida por la consulta.
● Gestión no acumulativa con ratios no acumulativos: cada ratio no acumulativo se define
con una agregación estándar y una agregación de excepción.

Los ratios no acumulativos siempre tienen la totalización como agregación estándar. Para las
características de tiempo, tienen una agregación de excepción distinta a la totalización. A
menudo se toma el primer valor (agregación FIRST), el último valor (agregación LAST) o el
promedio. Otra agregación de excepción útil para ratios no acumulativos se pondera
promediadamente según los días naturales (AV1).
Esta solución tiene las siguientes ventajas y desventajas:
● Ventajas
- Las tablas de hechos se mantienen más pequeñas.
- El historial no se modifica.
- Se puede calcular un valor para cualquier día dentro del período de validez. También
puede visualizar valores no acumulativos para períodos para los que no se han cargado
datos de movimiento.
● Desventajas
- No puede utilizar el aDSO junto con otro aDSO con ratios no acumulativos en un
CompositeProvider.

Explicar aDSO para inventario

En esta sección, vemos cómo los no acumulativos se cargan en objetos DataStore avanzados,
cómo los datos se almacenan internamente y cómo los lee el gestor analítico.

© Copyright. Reservados todos los derechos. 495

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

Figura 360: Inventario aDSO – Ficha General

El objeto DataStore avanzado debe tener una tabla de datos de entrada y una tabla de datos
activa. Existen dos opciones de modelado. Si solo carga deltas adicionales, puede seleccionar
la opción Todas las características son clave ("como cubo"). Si necesita sobrescribir
características, seleccione una Clase estándar. Además, fije la propiedad Inventario.

Nota:
Los objetos DataStore avanzados de inventario almacenan valores de
característica en lugar de ID de datos maestros. Solo en casos excepcionales,
puede ser útil almacenar valores de característica e ID de datos maestros para
InfoObjetos individuales en un objeto DataStore avanzado de este tipo.

El contenido empresarial optimizado para SAP HANA para la gestión de stocks está
disponible utilizando DataStores avanzados.

Figura 361: Etiqueta aDSO de inventario – Detalles

Cuando el ratio no acumulativo se añade al aDSO, el ratio para Modificación de valor no

acumulado o los ratios para entradas y salidas también se añaden al objeto DataStore, el
sistema también mostrará la ficha Inventario.

496 © Copyright. Reservados todos los derechos.

 Lección: Definición de escenarios de inventario

Figura 362: aDSO de inventario - Ficha Inventario

En este ejemplo, 0CALDAY se fija como característica de tiempo de referencia. 0PLANT es la

característica de validez.
La tabla de validez almacena los intervalos de tiempo para los que se han cargado valores no
acumulativos en el InfoSitio. Las características de validez forman la clave de la tabla de
validez. Se actualizan en la IU de modelado del objeto DataStore avanzado. La tabla de validez
contiene automáticamente la característica de tiempo más granular; otras características son
opcionales y solo deben añadirse con cuidado.

Tabla 4: Tablas aDSO de inventario

Nombre de tabla Descripción

/BIC/ANCUMADSO1 Tabla de entrada

/BIC/ANCUMADSO2 Tabla de datos activa

/BIC/ANCUMADSO3 Log de modificaciones

/BIC/ANCUMADSO4 Tabla de validez

/BIC/ANCUMADSO5 Tabla de puntos de referencia

Veamos las tablas que se generan para el DataStore avanzado de ejemplo llamado
NCUMADSO.

1. Las nuevas solicitudes se cargan en la tabla de entrada (finalizando en "1").

2. La activación de una solicitud transfiere los datos de la tabla de entrada a la tabla de datos
activa (finalizando en "2"). Se compactan los registros de datos de la misma clave.

3. El log de modificaciones (que finaliza en "3") siempre se crea y, si se utiliza el tipo estándar
de aDSO, almacena antes y después de las imágenes. Si la propiedad Escribir log de
modificaciones no está fijada, permanecerá vacía.

4. La tabla de validez (que finaliza en "4") almacena los intervalos de tiempo para los que se
han cargado valores no acumulativos en el InfoSitio.
Las características de validez forman la clave de la tabla de validez. Se actualizan en la IU
de modelado del objeto DataStore avanzado. La tabla de validez contiene
automáticamente la característica de tiempo más granular; otras características son
opcionales y solo deben añadirse con cuidado.

© Copyright. Reservados todos los derechos. 497

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

5. La tabla de puntos de referencia (que termina en "5") contiene puntos de referencia para
ratios no acumulativos. A diferencia de los InfoCubos en el pasado, los puntos de
referencia se almacenan en una tabla separada para DSO avanzados.

Nota:
Consulta estas interesantes notas sobre Inventario: 360249 No acumulativos:
Datos no o ininteligibles encontrados en las consultas. 1548125 Hechos
interesantes sobre Cubos de Inventario.

Figura 363: DTP de cantidad de stock inicial

Para cargar el balance de stock inicial, creamos un DTP para la fuente de datos
ZINITIALBALANCE con el modo de actualización Generar estado inicial. También creamos un
DTP a partir de la fuente de datos ZINITIALBALANCE en el DataStore avanzado NCUMADSO
con el modo de extracción No acumulado inicial para valores no acumulados.

Figura 364: Cantidad de stock inicial en fuente

La figura, Balance de stock inicial en origen, muestra los balances de stock iniciales que se
almacenan en la tabla ZINITIALBALANCE.

498 © Copyright. Reservados todos los derechos.

 Lección: Definición de escenarios de inventario

Figura 365: Tabla de puntos de entrada y de referencia

Veamos el contenido de la cola de entrada después de ejecutar el DTP para el balance de

stock inicial.
Al escribir los stocks iniciales en la tabla de entrada, SAP BW/4HANA ha rellenado el campo
técnico RECORDTP (clase de registro) con el valor 1.
Los DSO avanzados no acumulativos utilizan el campo técnico RECORDTP (tipo de registro)
para diferenciar entre lo siguiente:
● Los puntos de referencia con RECORDTP="1",
● Registros que aún no están contenidos (semánticamente) en los puntos de referencia con
RECORDTP='0'
● Registros que ya están contenidos (semánticamente) en los puntos de referencia con
RECORDTP='2'

Para DSO avanzados, los puntos de referencia (RECORD_TP='1') contienen los registros de
inicialización, es decir, los stocks iniciales en nuestro escenario. A diferencia de los InfoCubos
en el pasado, no se almacenan para la fecha fija 9999-12-31 (infinito), sino para la fecha como
se proporciona en el registro de datos. Además, los puntos de referencia se actualizan cada
vez que se activa una solicitud con movimientos delta. En otras palabras, los puntos de
referencia son los valores de stock de la inicialización más o menos los de todas las
solicitudes activadas con movimientos delta. Tenga en cuenta que utilizamos el término
"activar" en lugar de "colapsar" en el contexto de DSO avanzados.
No actualizar puntos de referencia implicaría que los valores de stock en la gestión de
informes deben calcularse como el total del balance de stock inicial más o menos todos los
movimientos delta que se han producido entre la fecha de inicialización y la fecha solicitada
en la consulta. Esto tendría una desventaja importante porque, semánticamente, no sería
posible borrar movimientos delta antiguos sin corromper los valores de stock actuales. Por
este motivo, los puntos de referencia se actualizan al activar solicitudes con movimientos
delta para objetos DataStore avanzados. Esto es crucial para permitir el archivo temporal de
datos de objetos DataStore avanzados no acumulativos.
Después de cargar los balances de stock iniciales, activamos la solicitud. La activación de una
solicitud con stocks iniciales transfiere los datos de la tabla de entrada a la tabla de puntos de
referencia. El tipo de registro sigue siendo 1 y los valores de la característica de tiempo más

© Copyright. Reservados todos los derechos. 499

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

granular CALDAY permanecen como cargados originalmente. Las características de tiempo

distintas de la más granular se generan en la tabla de puntos de referencia, pero siempre se
rellenan con valores iniciales. La tabla de puntos de referencia no contiene ningún
identificador de solicitud porque almacena los puntos de referencia agregados en la
granularidad de las características definidas por el usuario.

Figura 366: Movimientos delta

En el siguiente paso, cargamos movimientos delta, es decir, las modificaciones de stock que
se produjeron después de la inicialización el 22/02/2015. Para ello, creamos un DTP simple a
partir de la fuente de datos ZMOVEMENTS en el DataStore avanzado NCUMADSO con un
filtro en CALDAY > '2015-02-22' y lo ejecutamos. La imagen "Movimientos delta" muestra una
vez más los movimientos delta de nuestro escenario de muestra, que se almacenan en la
tabla ZMOVEMENTS.
Como se ha explicado anteriormente, los movimientos delta se cargan para el tipo de registro
0. En consecuencia, después de cargar los movimientos delta, vemos nuevos registros en la
tabla de entrada con RECORDTP='0'. Tenga en cuenta que la transacción SE16 muestra un
string vacío para RECORDTP en lugar del valor inicial relacionado con el tipo (aquí: 0) que se
almacena en la base de datos.

Figura 367: Comprimir los datos de movimiento

Como se ha explicado anteriormente, los movimientos delta se cargan para el tipo de registro
0. Por lo tanto, vemos nuevos registros en la tabla de entrada con RECORDTP='0' después de
cargar los movimientos delta. Tenga en cuenta que la transacción SE16 muestra un string
vacío para RECORDTP en lugar del valor inicial relacionado con el tipo (aquí: 0) que se
almacena en la base de datos.
Después de cargar los movimientos delta, activamos esa solicitud. La activación de una
solicitud con movimientos delta transfiere los datos de la tabla de entrada a la tabla de datos
activos (véase la imagen Comprimir los datos de movimiento). También tenemos en cuenta

500 © Copyright. Reservados todos los derechos.

 Lección: Definición de escenarios de inventario

que todos los registros en la tabla de datos activa ahora hacen referencia a RECORDTP = "2",
es decir, el tipo de registro se cambia de 0 en la tabla de entrada a 2 en la tabla de datos
activa. Además, la información de solicitud ha desaparecido, que es el comportamiento
previsto al activar una solicitud en un objeto DataStore avanzado con propiedades de
modelado.
Además, el sistema ha actualizado los registros en la tabla de puntos de referencia al activar
los movimientos delta. Vamos a verificar que para el material A100 en el centro S400:
● 100 punto de referencia antes de activar los movimientos delta
● -70 salida de mercancías el 25/02/2015
● +150 entrada de mercancías el 26/02/2015
● 180 nuevo valor de punto de referencia después de activar los movimientos delta

Esta lógica garantiza que todos los movimientos delta activados estén incluidos en los puntos
de referencia. La actualización de puntos de referencia semánticamente permite el archivo
basado en tiempo de movimientos delta antiguos (no admitido para DataStore avanzados con
ratios no acumulativos en el momento de la escritura). Además, cambiar el tipo de registro de
"0" a "2" mantiene el contenido del objeto coherente con la semántica de los tipos de registro
para DSOs avanzados. Solo para recordar:
● El tipo de registro 0 significa que un registro de tabla de hechos aún no está incluido en el
punto de referencia.
● La clase de registro 2 significa que ya existe un registro de tabla de hechos en el punto de
referencia.

Al activar la solicitud con movimientos delta, se han actualizado los puntos de referencia y,
por lo tanto, la clase de registro se ha cambiado de "0" a "2".

Figura 368: DTP para movimientos históricos

© Copyright. Reservados todos los derechos. 501

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

Ahora cargamos movimientos históricos, es decir, las modificaciones de stock que se

produjeron antes de la inicialización el 22/02/2015. Para ello, creamos un DTP a partir de la
fuente de datos ZMOVEMENTS en el DataStore avanzado NCUMADSO con un filtro en
CALDAY < '2015-02-22' y actualizamos la opción Historical Transactions. Esta opción solo
está disponible para movimientos pero como transacciones históricas que ya estaban
contenidas semánticamente en los balances de stock iniciales. Es crucial verificar este
indicador al cargar transacciones históricas. Permite que SAP BW/4HANA detecte que la
solicitud no se debe tratar como un delta normal. De lo contrario, las consultas en el aDSO
mostrarán datos inesperados.

Figura 369: Movimientos históricos

La figura, Movimientos históricos, muestra los movimientos históricos de nuestro escenario

de muestra, que se almacenan en la tabla ZMOVEMENTS. Como se ha explicado
anteriormente, los movimientos históricos se cargan para el tipo de registro 2 en caso de que
el InfoSitio sea un objeto DataStore avanzado. Por lo tanto, vemos nuevos registros en la
tabla de entrada con RECORDTP='2' después de cargar los movimientos históricos.

Figura 370: Resultado del informe

Nota:
Los valores de saldo inicial se muestran entre paréntesis[].

En este punto, verifiquemos cómo se ve el resultado de una consulta simple sin filtros como
en la imagen "Resultado del informe". No es obligatorio activar la solicitud con transacciones
históricas. El resultado de la consulta es correcto en cualquier caso. Puede verificar los
movimientos históricos mediante la consulta BW antes de ocultar la solicitud. Si ha detectado
errores, podrá borrar y volver a cargar la solicitud. Si está seguro de que todos los valores
están almacenados correctamente, active la solicitud. La activación de una solicitud con
movimientos históricos transfiere los datos de la tabla de entrada a la tabla de datos activa. El

502 © Copyright. Reservados todos los derechos.

 Lección: Definición de escenarios de inventario

tipo de registro aún es 2 y la información de solicitud ha desaparecido, que es el

comportamiento previsto al activar una solicitud en un objeto DataStore avanzado con
propiedades de modelado.
Tenga en cuenta que los puntos de referencia siguen siendo los mismos. Los movimientos
históricos ya están contenidos (semánticamente) en los puntos de referencia. Por este
motivo, la tabla de puntos de referencia no se actualiza al activar una solicitud con
movimientos históricos. Sin embargo, se crea un nuevo registro con valores de ratio iniciales
si la tabla de puntos de referencia aún no contiene un registro para la combinación indicada
de valores de característica.

Figura 371: Tabla de datos activa después de activar los datos históricos

En aras de la integridad, activamos la solicitud. La activación de una solicitud con

movimientos históricos transfiere los datos de la tabla de entrada a la tabla de datos activa. El
tipo de registro aún es 2 y la información de solicitud ha desaparecido, que es el
comportamiento esperado al activar una solicitud en un DSO avanzado modelado como tipo
DataMart. Tenga en cuenta que los puntos de referencia no se han actualizado. Los
movimientos históricos ya están contenidos (semánticamente) en los puntos de referencia.
Por este motivo, la tabla de puntos de referencia no se actualiza al activar una solicitud con
movimientos históricos. Sin embargo, se crea un nuevo registro con valores de ratio iniciales
si la tabla de puntos de referencia aún no contiene un registro para la combinación indicada
de valores de característica.

© Copyright. Reservados todos los derechos. 503

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

Figura 372: Cálculo para material A100

Hemos visto cómo Analytic Manager calcula el valor de stock para un intervalo de tiempo
entre t1 y t2 para DSO avanzados. La fórmula de la figura, Procesamiento de consultas,
muestra cómo se calculan los valores de stock para cualquier tiempo t0 en el intervalo entre
t1 y t2.

1. La primera solicitud de lectura es necesaria para calcular el valor de stock en el límite

superior del intervalo de tiempo t2. ¿Cómo harías eso? Bien, debe leer el punto de
referencia (tipo de registro 1) que contiene el balance de stock inicial, así como todos los
movimientos delta activados. A continuación, añada todos los movimientos delta aún no
activados que se han producido hasta t2 inclusive, ya que también son relevantes para la
consulta. A partir de este valor se restan los movimientos que ya se encuentran en el
punto de referencia (tipo de registro 2) pero que se han producido después de t2 y, por lo
tanto, no son válidos para el intervalo de tiempo solicitado:

● punto de referencia (tipo de registro 1)

● (= stock inicial +/- todos los movimientos delta activados)

● + movimientos delta aún no activados (clase de registro "0") con fecha ≤ t2

● - movimientos ya contenidos en el punto de referencia (clase de registro "2") con fecha

> t2

● valor de stock t2

2. La segunda solicitud de lectura no es tan intuitiva como la primera. Este query no tiene
ninguna característica de tiempo en "GROUP BY", ni siquiera solicita un ratio. El único
objetivo de este query es determinar aquellas combinaciones de características que no
serían alcanzadas por las otras dos solicitudes de lectura. Estas tuplas sólo tienen
movimientos no activados con fecha > t2. Sin embargo, aún deben mostrarse con stock
cero si su fracción de validez correspondiente forma parte del resultado de la consulta.

504 © Copyright. Reservados todos los derechos.

 Lección: Definición de escenarios de inventario

3. La tercera solicitud de base de datos lee todos los movimientos en el intervalo de tiempo
entre t1 y t2 si están incluidos en el punto de referencia (tipo de registro 0) o no (tipo de
registro 2) - con característica de tiempo en "GROUP BY".

4. Utilizando los datos leídos en el paso 3, el sistema puede realizar un cálculo regresivo
desde el límite superior del intervalo t2 (leer en el paso 1) hasta el límite inferior del
intervalo t1. Esto se realiza simplemente restando todas las entradas de mercancías y
añadiendo todas las salidas de mercancías que se han producido

Para el material A100, el centro S400 y el intervalo de tiempo entre 24/02/2015 (t1) y
26/02/2015 (t2), el cálculo sería similar a la figura Cálculo para material A100.
En resumen, el tratamiento no acumulativo para objetos DataStore avanzados reduce
potencialmente el coste de cálculo para el valor de stock en t2 en la base de datos, en
comparación con los anteriores escenarios de gestión de stocks no basados en HANA. Esto
se debe a que los puntos de referencia se actualizan durante la activación de solicitudes con
movimientos delta para objetos DataStore avanzados.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Crear ratios para no acumulativos
● Definir escenarios de inventario utilizando objetos DataStore (avanzados)

© Copyright. Reservados todos los derechos. 505

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

506 © Copyright. Reservados todos los derechos.

 Capítulo 13
Lección 3
Cobertura de stock

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Analizar la cobertura de stock

El ratio de cobertura de stock

Figura 373: Ratio de cobertura de stock

Cobertura de stock: Requisito empresarial

● Para un stock determinado en un determinado momento y una serie cronológica de

valores de demanda, una pregunta frecuente es para cuántos días cubre el stock la
demanda.
● Este indicador de rendimiento clave (KPI) es Cobertura de stock. La solución debe
describir cómo se define la cobertura de stock en una consulta procesada en un sistema
OLAP como SAP BW.
● La solución es definir la cobertura de stock como un ratio especial en los metadatos BW.

© Copyright. Reservados todos los derechos. 507

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

● Un ratio de cobertura de stock calcula la cantidad de períodos para los que un stock cubre
la demanda planificada o prevista.
● Ejemplo: El stock actual es de 10 unidades. La demanda prevista para las próximas cuatro
semanas es de 2 unidades, 3 unidades, 4 unidades, 2 unidades. Por lo tanto, el stock actual
durará 3 1/2 semanas más.

Para crear el ratio de cobertura de stock, seleccione el indicador Cobertura de stock. Ahora
puede ver una ficha adicional llamada Cobertura de stock. Ahora se puede especificar una
unidad fija como día o mes.
En la etiqueta Agregación, especifique una característica de tiempo que especifique la
granularidad de la cobertura de stock. Esta característica también sirve como característica
de referencia para la agregación de excepción. Siempre se debe especificar una agregación
de excepción para los ratios para la cobertura de stock.
En la ficha Cobertura de stock, especifique un ratio de referencia para el stock. Puede ser un
ratio no acumulativo o un ratio acumulativo. Seleccione un ratio de referencia para la
demanda. La cantidad máxima de períodos de tiempo que se tienen en cuenta. Cuantos más
períodos se especifiquen aquí, mayor será el tiempo de ejecución. Decida si el ratio
referenciado para el stock es un stock inicial o un stock de cierre.
Puede utilizar un ratio especial en una consulta para visualizar cuánto tiempo cubrirá la
cantidad disponible de un valor de stock determinado la demanda planificada o prevista. El
ratio especial para la cobertura de stock calcula cuánto tiempo durará el stock utilizando los
ratios para stock y demanda con referencia a una característica de tiempo. Un ratio para la
cobertura de stock se puede utilizar en todos los InfoSitios, a excepción de los objetos
DataStore. Si un ratio para la cobertura de stock se utiliza en niveles de agregación, no está
habilitado para la entrada. Un ratio para la cobertura de stock se puede utilizar en fórmulas,
fórmulas con agregación de excepción, condiciones y en todos los estados de navegación
posibles de una consulta.
Los ratios para la cobertura de stock no están disponibles en los queries estándar de un
InfoSitio. Si una característica de tiempo en el query se encuentra en el desglose o filtro, o una
característica de tiempo es una referencia para una agregación de excepción, esta
característica de tiempo debe ser compatible con la característica de tiempo para calcular la
cobertura de stock. Si no es compatible, no podrá obtener resultados significativos. Una
característica de tiempo es compatible con la característica de tiempo para calcular la
cobertura de stock si se puede asignar un valor unívoco de la característica de tiempo para
cada valor de la característica de tiempo para calcular la cobertura de stock.

508 © Copyright. Reservados todos los derechos.

 Lección: Cobertura de stock

Figura 374: Ejemplo de cobertura de stock

En la figura, Ejemplo de cobertura de stock, si hay un balance de stock de 10.000 y la

demanda es de 1000 por día, hay 10 días de inventario. Si la demanda es de 2000 por día,
solo hay 5 días de inventario. Si la demanda es de 1000 por día para nueve días y 2000 para el
día 10, solo hay 9,5 días de inventario.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Analizar la cobertura de stock

© Copyright. Reservados todos los derechos. 509

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

510 © Copyright. Reservados todos los derechos.

 Capítulo 13
Lección 4
Modo de planificación

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Discutir el modo de planificación

Las opciones ADSO habilitadas para la planificación

Existen dos tipos de objeto DataStore (avanzado) que se pueden utilizar para introducir
valores plan. En ambos casos, si se necesita la entrada manual de valores, la propiedad de
modelo Habilitada para la planificación debe estar activa (consulte el siguiente gráfico,
Opciones de ADSO posibles para el modo de planificación).

Figura 375: Opciones de ADSO posibles para el modo de planificación

ADSO con modo de planificación y actualización directa

Especialmente, para los escenarios de planificación, un aDSO se puede definir como un tipo
especial llamado Actualización directa. En lugar de cargar datos mediante DTP, los valores se
actualizan directamente en la tabla de datos activa mediante la planificación de entrada
manual o las funciones de planificación. ¿Cuáles son las funciones en detalle?

Actualización directa - Detalles

● La tabla contiene la clave que se ha seleccionado durante la creación.

● No hay ningún log de modificaciones ni cola de activación.

© Copyright. Reservados todos los derechos. 511

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

● No se puede utilizar para escenarios de transformación o escenarios de carga.

● No es un destino para los procesos de carga de SAP BW.
● Sin embargo, se puede exportar a otros InfoSitios.
● La gestión de informes es posible.

Los ADSO se pueden fijar en Actualización directa para que puedan recibir datos de APIs.
Además, también se pueden activar para la planificación. Los datos de planificación pueden
incluir datos de transacción o comentarios (utilizar para capturar supuestos de planificación,
por ejemplo). En dicho aDSO, debe definir una clave. Los registros con la misma clave se
pueden sobrescribir.
A veces desea valores de atributos de planificación, como precio de producto o número de
empleados de un departamento, aunque este valor se trate como un atributo (de
visualización) para datos reales. A continuación, modele el InfoObjeto como una
característica con un tipo numérico, como Entero. En la definición del aDSO habilitado para la
planificación, fije el indicador "Utilizar característica como ratio" (también conocido como
"Ratio de texto") para lograr la planificación de atributos en la IU admitida.

Planificación ADSO en cubo like

Existe otra opción si necesita realizar un seguimiento de las modificaciones durante un
tiempo, o si desea cambiar entre la carga y la planificación: si selecciona las opciones Objeto
DataStore data mart, habilitado para la planificación, la combinación de todas las
características funciona como clave. (Si no desea planificar en todas las combinaciones,
puede definir selecciones como una combinación específica de unas pocas características.)
El objeto DataStore (avanzado) para la planificación tiene dos tablas. La tabla de entrada se
descomprime y almacena cada conjunto de modificaciones en una solicitud de entrada. Los
IDs de solicitud se cierran después de escribir los datos en la base de datos. Si no necesita
identificar determinadas solicitudes, actívelas. A continuación, todos los registros con el
mismo conjunto de valores de característica se condensan en un registro que se almacena en
la tabla Datos activos. Este tipo de aDSO para la planificación se puede cargar o planificar.
Una solicitud abierta se cierra si se cambia el modo.

512 © Copyright. Reservados todos los derechos.

 Lección: Modo de planificación

Figura 376: Arquitectura de BW/4HANA para planificación

Los datos reales a menudo son más detallados. Recomendamos utilizar distintos aDSO para
valores plan y valores reales, con un CompositeProvider como techo común.

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Discutir el modo de planificación

© Copyright. Reservados todos los derechos. 513

Capítulo 13 : Otros temas de modelado en SAP BW/4HANA

514 © Copyright. Reservados todos los derechos.

 Capítulo 13

Evaluación de la formación

1. Los ratios no acumulativos tienen la totalización como agregación por defecto. Para las
características de tiempo, debe utilizar la agregación de excepción.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

2. Los ratios no acumulativos son valores calculados según un período de tiempo

determinado. A continuación, el valor se incrementa o disminuye en función de una
entrada o salida.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

3. Para un escenario de cobertura de stock, debe proporcionar un período de validez.

Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

© Copyright. Reservados todos los derechos. 515

 Capítulo 13

Respuestas a la Evaluación de la formación

1. Los ratios no acumulativos tienen la totalización como agregación por defecto. Para las
características de tiempo, debe utilizar la agregación de excepción.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

Tienes razón. Los ratios no acumulativos tienen la totalización como agregación por
defecto. Para las características de tiempo, debe utilizar la agregación de excepción. Leer
más en el módulo Definición de escenarios de inventario, en el curso BW430.

2. Los ratios no acumulativos son valores calculados según un período de tiempo

determinado. A continuación, el valor se incrementa o disminuye en función de una
entrada o salida.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Ha acertado! Los no acumulativos no se acumulan como ratios normales porque su valor
depende de una estipulación de un tiempo para que la acumulación tenga sentido.
Ejemplos de no acumulativos son el stock en almacén al final del mes o los saldos iniciales
en el libro mayor. Leer más en el módulo Definición de escenarios de inventario, en el
curso BW430.

3. Para un escenario de cobertura de stock, debe proporcionar un período de validez.

Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

¡Correcto! Un escenario de cobertura de stock solo necesita un ratio de stock y un ratio de

demanda, y se calculan los valores de ratio de cobertura de stock (duración de
disponibilidad). A diferencia de la gestión de stocks, no se puede fijar ningún período de
validez. Leer más en el módulo Cobertura de stock, en el curso BW430.

516 © Copyright. Reservados todos los derechos.

CAPÍTULO 14 Apéndice

Lección 1
Implementación de áreas de trabajo de SAP BW/4HANA 519

Lección 2
Gestión del ciclo de vida de SAP BW/4HANA - Información adicional 535

Lección 3
Fuentes de información adicionales para SAP BW/4HANA 539

OBJETIVOS DEL CAPÍTULO

● Comience con las áreas de trabajo de SAP BW

● Proporcionar información adicional sobre la gestión del ciclo de vida de SAP BW/4HANA
● Proporcionar fuentes de información adicionales en relación con SAP BW/4HANA

© Copyright. Reservados todos los derechos. 517

Capítulo 14 : Apéndice

518 © Copyright. Reservados todos los derechos.

 Capítulo 14
Lección 1
Implementación de áreas de trabajo de SAP
BW/4HANA

RESUMEN DE LA LECCIÓN
Las áreas de trabajo de SAP BW proporcionan al usuario empresarial los medios para
desarrollar sus propios modelos dentro de SAP BW. Este concepto se trata en esta lección y
en el ejercicio que lo acompaña.

Ejemplo empresarial
Ejemplo 1: Un departamento de marketing desea iniciar una campaña de marketing dentro de
unas semanas. Para supervisar los datos de la campaña, desea configurar un ADSO para
realizar un seguimiento de las reacciones de los clientes, por ejemplo. El departamento
empresarial se dirige al departamento de TI con esta solicitud y le dicen que se puede
implementar un nuevo ADSO en dos meses, como muy pronto.
Ejemplo 2: Sus “superusuarios” están descargando grandes cantidades de datos en
Microsoft Access, donde se procesan individualmente. Para TI esto es insostenible y no hay
documentación sobre esta caja negra. Para evitar esta forma de trabajar, permite que
algunos de ellos utilicen y creen áreas de trabajo de SAP BW, que están dentro de su
organización de TI.
Ejemplo 3: Su sistema SAP ERP aún no está totalmente integrado. La gestión de almacenes y
los sistemas CRM no están conectados al EDW de su organización y los datos sólo se pueden
integrar en base a ficheros planos. Estas fuentes deben integrarse de forma flexible para el
análisis de pedidos de cliente. Este es el escenario para los ejercicios de esta unidad.

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Comience con las áreas de trabajo de SAP BW

© Copyright. Reservados todos los derechos. 519

Capítulo 14 : Apéndice

Capa de área de trabajo de SAP BW

Figura 377: Centros de datos centrales con arquitectura frente a data mart departamentales

El caso empresarial para un área de trabajo es proporcionar un método rápido y simple para
integrar datos que se rige por un departamento con datos proporcionados por el
departamento de TI central. Es una mejora ágil del núcleo central de LSA++.

520 © Copyright. Reservados todos los derechos.

 Lección: Implementación de áreas de trabajo de SAP BW/4HANA

Figura 378: Resumen de áreas de trabajo de SAP BW

Las áreas de trabajo de SAP BW abordan una brecha específica que se suele encontrar en los
proyectos de implementación de almacenamiento de datos: el conflicto entre el
departamento de TI central y los requisitos del departamento de negocio. TI tiene que
mantener un espacio controlado centralmente con modelos de datos basados en datos
centrales, con una semántica definida centralmente en esos datos. El departamento de TI
suele estar vinculado por acuerdos de nivel de servicio, así como por reglas de cumplimiento.
Su objetivo es mantener la consistencia de los datos en los contenedores de datos. Esto
significa que el departamento de TI no puede reaccionar de forma espontánea ante
solicitudes de modificación de datos o de añadir datos nuevos. El departamento empresarial
debe actuar de forma ágil en sus operaciones diarias.
Este desafío se puede superar configurando un área de trabajo de SAP BW para el
departamento empresarial (por ejemplo, marketing, recursos humanos, controlling, etc.) en
SAP BW. Por lo tanto, los usuarios empresariales pueden reaccionar rápidamente a los
requisitos nuevos y cambiantes. Este área de trabajo BW es un área de trabajo dedicada que
define TI. TI establece los límites y el número de recursos que puede utilizar un área de
trabajo de SAP BW. Expone algunos de los modelos de datos centrales al área de trabajo de
SAP BW (datos de los modelos y su semántica relacionada).
El área de trabajo de SAP BW solo expone los datos centrales de forma lógica. Los datos no se
copian ni replican, sino que solo se exponen virtualmente en el área de trabajo de SAP BW. El
objetivo es permitir a los usuarios empresariales clave utilizar estos datos centrales para
enriquecerlos en un entorno dedicado y separado, que está profundamente integrado e
integrado en la infraestructura SAP BW existente. El departamento empresarial decide qué
ocurre después dentro del área de trabajo de SAP BW.

© Copyright. Reservados todos los derechos. 521

Capítulo 14 : Apéndice

Figura 379: Objetos de área de trabajo SAP BW

En un área de trabajo de SAP BW, están disponibles los siguientes objetos:

1. Proveedores centrales
Representan InfoSitios clave de su sistema SAP BW/4HANA. Tenga en cuenta que no se
replican datos de un InfoSitio cuando se fija como Proveedor central. Esto significa que el
InfoSitio solo está virtualmente expuesto y su modelo principal y los datos no se
modifican.

2. Proveedores locales
Representan datos locales que se han cargado directamente en un área de trabajo de SAP
BW.

3. CompositeProviders locales
Esto le permite combinar datos de proveedores locales con proveedores centrales.

522 © Copyright. Reservados todos los derechos.

 Lección: Implementación de áreas de trabajo de SAP BW/4HANA

Nota:
A partir de SAP BW 7.4, la relevancia de CompositeProviders ha aumentado.
SAP presenta el CompositeProvider basado en Eclipse, que se gestiona en
SAP HANA Studio Herramientas de modelado de SAP BW. No lo confunda con
el CompositeProvider local de un área de trabajo de SAP BW. Ambos
proporcionan una función similar, pero técnicamente son objetos de SAP BW
diferentes, de la siguiente manera:

a. CompositeProvider local de SAP BW Workspace: tipo de objeto CPRO,

objeto de autorización S_RS_CPRO, actualización en la transacción
RSLIMOBW

b. CompositeProvider en SAP BW/4HANA: Tipo de objeto HCPR, objeto de

autorización S_RS_HCPR

4. Característica local
Puede crear una característica local que tome sus atributos y la mayoría de sus
propiedades de una característica de InfoObjeto de SAP BW de referencia central. Esto
siempre es independiente del tiempo y no dependiente del idioma, incluso si la
característica de referencia es dependiente del tiempo y del idioma. Si la característica de
referencia tiene textos, también se pueden definir textos para nuevos valores en la
característica local. Los textos existentes no se pueden sobrescribir.
Puede cargar datos en la característica local mediante un archivo (CSV o Microsoft Excel)
o introduciendo los datos manualmente. También puede definir atributos adicionales,
pero se almacenan localmente. La característica local solo se puede utilizar en
proveedores locales y CompositeProviders locales en el mismo área de trabajo. Los
atributos relevantes para autorización de la característica de referencia se ignoran en la
característica local. Las modificaciones de los datos maestros de la característica de
referencia también aparecen en los datos maestros de la característica local si los valores
clave no se han modificado durante la creación de la característica local.

5. Jerarquía local
Puede crear una jerarquía local que derive su estructura de una jerarquía o fichero central.
Como alternativa, puede crear la estructura jerárquica usted mismo. Puede modificar la
estructura de jerarquía local insertando nodos y valores de datos maestros adicionales,
modificando y borrando nodos. Los siguientes InfoObjetos están disponibles como
características básicas para una jerarquía local:

● Características centrales, que tienen datos maestros y jerarquías de soporte

● Características locales (incluso si su InfoObjeto maestro no admite jerarquías)

Las siguientes funciones no son compatibles con las jerarquías:

● Dependencia temporal de la estructura de jerarquía: para jerarquías SAP BW

dependientes del tiempo como fuentes, debe decidir cuándo (en qué fecha clave)
desea que se cargue la jerarquía.

● Versiones

© Copyright. Reservados todos los derechos. 523

Capítulo 14 : Apéndice

● Intervalos de tiempo

● Características externas: para las jerarquías de SAP BW como fuentes, los nodos con
características externas se convierten en nodos de texto.

● Invertir signos más y menos

● Jerarquías virtuales

Figura 380: Grupos de usuarios y sus herramientas de áreas de trabajo de SAP BW

Los siguientes grupos de usuarios interactúan en áreas de trabajo de SAP BW:

● Administradores de SAP BW: se debe definir un área de trabajo de SAP BW en el back end
de SAP BW/4HANA. Esta tarea la realiza normalmente un equipo de TI central. La
definición le permite controlar el número de objetos, el consumo de memoria y las
autorizaciones. Además, existe una definición clara de qué parte de los datos de EDW
pueden ser utilizados por el espacio de trabajo de SAP BW: datos de ventas, datos de
producto o cualquier dato EDW central que se pretenda utilizar para el modelado
posterior. Las tareas principales son las siguientes:
- Configure el Customizing general (transacción RSWSP_CUST).

- Crear y supervisar todas las áreas de trabajo de SAP BW.

- Exponer InfoSitios del sistema SAP BW/4HANA a las áreas de trabajo de SAP BW,
donde se denominan Proveedores centrales.
- Asignar autorizaciones para áreas de trabajo SAP BW y datos del sistema SAP BW/
4HANA a los diferentes grupos de usuarios.

524 © Copyright. Reservados todos los derechos.

 Lección: Implementación de áreas de trabajo de SAP BW/4HANA

Nota:
El objeto de autorización estándar de SAP BW para esta función es
S_RS_WSPAC. Hay tres nuevas plantillas de rol disponibles para áreas de
trabajo SAP BW: Administrador de área de trabajo SAP BW (S_RS_TWSPA),
Diseñador de área de trabajo SAP BW (S_RS_TWSPD) y Usuario de query
de área de trabajo SAP BW (S_RS_TWSPQ).

● Usuarios clave de negocio: el modelado y enriquecimiento del espacio de trabajo de SAP

BW se realiza mediante las funciones de SAP BW Workspace Designer de un rol de portal o
la nueva GUI de SAPUI5, así como mediante SAP BusinessObjects Analysis para Microsoft
Excel. Los usuarios clave pueden conectar datos locales externos desde ficheros planos a
los datos centrales, por ejemplo. Los modelos de datos específicos de línea de negocio o
departamento se pueden crear fácilmente de manera fluida e intuitiva. Técnicamente, se
combinan modelos de datos locales con modelos centrales mediante operaciones JOIN y
UNION, y se crean definiciones de CompositeProvider que se procesan completamente en
memoria. Los usuarios son guiados paso a paso por un asistente a través del
procedimiento de fusión de modelos centrales y locales, la definición del
CompositeProvider y la creación de consultas. Sin embargo, las áreas de trabajo de SAP
BW son una funcionalidad importante para el usuario empresarial clave que sabe qué
datos desea combinar y qué lograr con los datos unidos. Por lo tanto, dependiendo
principalmente de la herramienta que está en uso, el grupo de usuarios de negocio en foco
aquí necesita una comprensión sólida de los tipos join comunes, como UNION, INNER o
LEFT OUTER JOIN. Las tareas principales son las siguientes:
- Cargar datos de ficheros planos. Otras fuentes son las consultas de SAP BW o las
fuentes de datos de SAP BW (solo para SAP Business Client). Estos se almacenan
técnicamente como índices analíticos en SAP HANA. Se pueden volver a cargar o
borrar en cada área de trabajo de SAP BW, o se pueden gestionar con otras funciones
administrativas en una transacción. RSDD_LTIP.

- Cree nuevos CompositeProviders locales, combinando los proveedores locales con los
proveedores centrales del área de trabajo de SAP BW.
- Crear referencias locales a consultas centrales y modificarlas o ampliarlas (Workspace
Query Designer)
- Defina informes de SAP BW sobre estos nuevos modelos de datos para los usuarios
finales.
● Usuarios finales: Según los clientes de generación de informes de SAP BW, hay varias
opciones disponibles para el uso de los datos del área de trabajo de SAP BW. Los usuarios
finales pueden ir con SAP BusinessObjects Analysis, por ejemplo, o con otros clientes de
informes de SAP BW. Además, cualquier Query sobre un CompositeProvider local puede
ser utilizado por las interfaces estándar de SAP BW MDX y BICS, utilizando todos los
clientes BI certificados.

© Copyright. Reservados todos los derechos. 525

Capítulo 14 : Apéndice

Herramientas de área de trabajo de SAP BW

Figura 381: Mantenimiento de áreas de trabajo SAP BW en SAP GUI

Un administrador debe crear un área de trabajo antes de que un usuario pueda trabajar en
ella. Para la actualización de áreas de trabajo SAP BW individuales, la transacción es RSWSP.
Para el procesamiento en masa de todas las áreas de trabajo SAP BW existentes en el
sistema, la transacción es RSWSPW. Aquí se definen las siguientes opciones principales:

● Configuración: definición de la fecha de vencimiento, el prefijo para todos los objetos

creados, el proveedor central principal (CompositeProvider), el número máximo de
proveedores locales y la memoria máxima disponible para ellos, la configuración avanzada
para los datos locales, la asignación de la carpeta del área de trabajo de SAP BW y otros.
● Proveedores centrales: Selección de InfoSitios de SAP BW (con persistencia) para exponer
al área de trabajo de SAP BW. Dentro de ellos, puede restringir la selección de
características individuales además de ratios. También puede definir Fuentes de datos
para que sean Proveedores centrales. Sin embargo, tenga cuidado con el impacto de
rendimiento resultante en el sistema fuente.
● Destinos de envío: los DSO avanzados se pueden liberar aquí para guardar de forma
persistente los datos de los proveedores locales en un objeto SAP BW principal.
● Proveedores Locales: Lista y estado de los datos cargados y los Proveedores Locales
creados por los usuarios empresariales.
● CompositeProviders locales: lista y estado de los CompositeProviders locales generados
por los usuarios empresariales.

526 © Copyright. Reservados todos los derechos.

 Lección: Implementación de áreas de trabajo de SAP BW/4HANA

● Datos locales: Lista y estado de características locales, así como jerarquías locales
creadas por usuarios empresariales basadas en características de InfoObjeto de SAP BW
de referencia central.
● Consultas de área de trabajo: Lista de consultas locales definidas con SAP BW Workspace
Query Designer.
● Usuarios: Lista de usuarios de SAP BW que están autorizados para trabajar con el área de
trabajo de SAP BW o ejecutar consultas relacionadas.

SAP BusinessObjects Analysis para Microsoft Excel

Figura 382: Áreas de trabajo BW en SAP BusinessObjects Analysis para Microsoft Excel

SAP BusinessObjects Analysis para Microsoft Excel es un front end de usuario alternativo
para gestionar áreas de trabajo SAP BW desde la perspectiva del usuario empresarial.
Proporciona un flujo de trabajo simplificado dentro del conocido entorno de Microsoft Excel.
Aunque el control de las opciones de modelado no es tan flexible como Workspace Designer,
las funciones principales están disponibles aquí, sin una instalación de cliente adicional, y
están totalmente integradas en Microsoft Office. Las funciones del área de trabajo de SAP BW
se representan con los siguientes botones en la cinta Análisis / Origen de datos de SAP
BusinessObjects Analysis para Microsoft Excel:
● Crear: use este botón para cargar sus propios datos locales de Microsoft Excel (rabia
mínima de 2x2 celdas) y crear un proveedor local de esta manera. Después de seleccionar
el sistema y el área de trabajo de SAP BW, se deben especificar el nombre técnico y la
descripción del nuevo proveedor local. Además, debe definir si los campos son medidas de
características. También puede renombrar los nombres de columna y especificar los tipos
de datos. Si planea combinar este proveedor local con un proveedor central, asegúrese de
cargar la clave de las columnas de características y solo los valores clave existentes.

© Copyright. Reservados todos los derechos. 527

Capítulo 14 : Apéndice

● Recargar: esta opción vuelve a cargar los proveedores locales existentes. Se trata de una
carga completa que borra todos los registros existentes (sin soporte delta).
● Agregar: este botón crea un CompositeProvider local dentro de su área de trabajo de SAP
BW. Como requisito previo, debe comenzar con una consulta existente del InfoSitio que se
haya definido como Proveedor central del área de trabajo de SAP BW. En primer lugar,
debe seleccionar un sistema, un área de trabajo de SAP BW y el proveedor local que desea
combinar. A continuación, proporcione una descripción y un nombre técnico del nuevo
Local CompositeProvider. Los siguientes son dos métodos de modelado para unir el
proveedor central y el proveedor local:
- Dimensión: Left Outer Join se basa en un valor de característica; el objeto izquierdo es
el proveedor central y todas las claves de conexión posibles coinciden con la columna
correspondiente del proveedor local. Esto se recomienda si el proveedor local solo
amplía características del proveedor central, pero no contiene ratios adicionales.
- Registros de datos: La unión se basa en los ratios de un proveedor local; por lo tanto,
esta es la opción del modelador cuando el proveedor local también contiene ratios.

Figura 383: SAP BW Workspace Query Designer

SAP BW Workspace Designer permite a los usuarios ocasionales crear fácilmente nuevas
consultas de área de trabajo de SAP BW para el análisis de datos o para ampliar las consultas
existentes. Una consulta de área de trabajo de SAP BW siempre tiene una referencia a un área
de trabajo de SAP BW porque su definición está almacenada en un área de trabajo. Para
reducir la complejidad, la definición de Query SAP BW Workspace solo tiene un subconjunto
de las funciones de SAP BW Query Designer normal. También puede ampliar las consultas,
que ha definido con las herramientas de modelado de SAP BW, en SAP BW Workspace Query
Designer. Para cada Query de área de trabajo SAP BW, el sistema genera un nuevo ID
individual. Esto permite utilizar una consulta de área de trabajo como cualquier otra consulta
analítica de SAP BW. Los InfoSitios centrales del área de trabajo de SAP BW con sus datos
expuestos se pueden utilizar como InfoSitios para la consulta de área de trabajo de SAP BW.
También puede crear CompositeProviders locales o cargar proveedores locales. En un
CompositeProvider local, puede fusionar sus datos personalizados con datos de SAP BW. Las
funciones son las siguientes:

528 © Copyright. Reservados todos los derechos.

 Lección: Implementación de áreas de trabajo de SAP BW/4HANA

● Configuración: Para habilitar esta aplicación SAPUI5, se deben activar los siguientes dos
servicios de conexión a Internet en la transacción SICF: /sap/bc/ui5_ui5/sap/rsl_wqd
y /sap/bw/Modeling.
● Inicie la aplicación: Utilice la transacción RSWQD o seleccione lo siguiente directamente en
un navegador Web: HTTPS://[WEBSERVER HOST]:[WEBSERVER PORT]/SAP/BW/WQD/
INDEX.HTML

● La aplicación se divide en tres partes principales:

- Consulta:
Abra una consulta de área de trabajo SAP BW existente o cree una nueva basada en un
InfoSitio del área de trabajo o basada en una consulta SAP BW regular del proveedor
central.
- InfoSitio:
Abra un InfoSitio existente del área de trabajo en modo de consulta, cree un nuevo
proveedor local basado en ficheros planos (CSV, XLSX, XLSM) o cree un nuevo
proveedor compuesto local.
- Área de trabajo:
Visualice las propiedades del área de trabajo de SAP BW actual o seleccione otra área
de trabajo de SAP BW.

Figura 384: Diseñador de área de trabajo de SAP BW

SAP BW Workspace Designer es una interfaz de usuario basada en web para SAP Enterprise
Portal. Si su organización no utiliza SAP Enterprise Portal, puede utilizar SAP Business Client
para utilizar esta interfaz de usuario en una instalación de cliente local. SAP BW Workspace
Designer ofrece las siguientes funciones para usuarios clave empresariales:

© Copyright. Reservados todos los derechos. 529

Capítulo 14 : Apéndice

● Resumen de centro de trabajo: Resumen de las funciones existentes.

● Mi área de trabajo: Resumen de objetos existentes. Este panel también hace referencia a
las consultas de área de trabajo de SAP BW definidas en SAP BW. Área de trabajo Query
Designer (transacción RSWQD). Puede obtener una vista previa de las consultas existentes
desde aquí o iniciar el Workspace Query Designer para crear nuevos objetos.
● Crear CompositeProvider local: En un CompositeProvider local, puede combinar o fusionar
los datos de todos los modelos de datos disponibles en el área de trabajo de SAP BW:
proveedor central, proveedor local y característica local. El enfoque de modelado se basa
en un asistente que guía a los modeladores a través de esta función en los siguientes
pasos:
- Seleccionar proveedor: seleccione el objeto que se debe combinar.
- Modelo CompositeProvider: Este es el paso clave en esta función, ya que realmente
modela el CompositeProvider definiendo Inner Join, Left Outer Join o Union. Una
función propone campos que están disponibles para estas combinaciones SQL. Existe
una vista gráfica fácil de usar que muestra el modelo de datos resultante.
- Editar campos: cada campo del CompositeProvider local se puede adaptar según su
nombre y tipo.
- Crear consultas: existe una opción para crear consultas de plantilla. Por ejemplo, existe
un query estándar que publica todos los campos del CompositeProvider local en el
query como características libres o ratios. Este query no se puede modificar en el
Query Designer, pero se modifica automáticamente cuando se modifica el
CompositeProvider local.
- Verificar y grabar: Esta es la validación final y la activación del nuevo modelo de datos.
Como opción, puede optar por crear una vista de SAP HANA externa automáticamente.
● Crear proveedor local: basado en ficheros planos, consultas o fuentes de datos SAP BW,
los usuarios pueden crear Proveedores locales seleccionando primero la estructura y
luego cargando los datos locales en el sistema. Este proceso se divide en tres pasos; el
asistente lo guía a través de ellos de una manera sencilla.
● Enviar datos: puede transferir datos de proveedores locales a proveedores SAP BW
centrales. Los destinos admitidos son objetos DataStore (avanzados), que corresponden a
los tipos de DataMart, objeto DataStore estándar y objeto DataStore de staging. Además,
estos objetos DataStore (avanzados) deben liberarse para la transferencia de datos y los
InfoObjetos y campos deben activarse para que el administrador los escriba primero
(transacción RSWSP). Además, puede definir determinadas reglas de depuración y filtrado.

● Datos locales > Crear característica local: puede crear una característica local que tome
sus atributos y la mayoría de sus propiedades de un InfoObjeto maestro en SAP BW. Esto
siempre es independiente del tiempo y no dependiente del idioma, incluso si el InfoObjeto
maestro es dependiente del tiempo y del idioma. Si el InfoObjeto maestro tiene textos, los
textos también se pueden definir para valores nuevos en la característica local. Los textos
existentes no se pueden sobrescribir. Puede cargar datos en la característica local
utilizando un archivo (CSV o XLS) o introduciendo los datos manualmente. También
puede definir atributos adicionales. Los atributos adicionales se almacenan localmente
solo en el área de trabajo de SAP BW. Las características locales se pueden utilizar en
Proveedores locales o CompositeProviders locales. Se encuentran en el área Datos locales
del diseñador de área de trabajo.

530 © Copyright. Reservados todos los derechos.

 Lección: Implementación de áreas de trabajo de SAP BW/4HANA

● Datos locales > Crear jerarquía local: puede crear una jerarquía local, que deriva su
estructura de una jerarquía o fichero central. Como alternativa, puede crear la estructura
jerárquica usted mismo. Puede modificar la estructura de jerarquía local insertando nodos
y valores de datos maestros adicionales, modificando y borrando nodos. Por último, se
encuentran en el área Datos locales del diseñador de área de trabajo.
● Herramientas del área de trabajo: Si tiene autorización para más de un área de trabajo de
SAP BW, seleccione primero el área de trabajo de SAP BW relevante aquí. Las funciones
adicionales son gestionar los bloqueos de áreas de trabajo de SAP BW y tareas periódicas,
como eliminar objetos no utilizados durante un tiempo determinado.

Nota:
En SAP BW Workspace Designer, puede crear un proveedor local para la
planificación integrada de SAP BW. Debe activar el kit de aplicaciones de
planificación para utilizar esta función. Esto requiere una licencia para Business
Objects Planning and Consolidation, versión para SAP NetWeaver (consulte la
nota SAP 1637199 - Uso de las aplicaciones de planificación KIT).
Al crear un proveedor local, seleccione la propiedad Para planificación, de modo
que se pueda utilizar para la planificación integrada de SAP BW. Al grabar y activar
este proveedor local, el sistema genera automáticamente un nivel de agregación y
un query estándar listo para la entrada. Como resultado, este proveedor local está
disponible como nivel de agregación de SAP BW para una definición más detallada
de las funciones de planificación.

Figura 385: Comparación de herramientas de área de trabajo de SAP BW para usuarios empresariales clave

© Copyright. Reservados todos los derechos. 531

Capítulo 14 : Apéndice

Figura 386: Informes de área de trabajo de SAP BW

Los objetos del área de trabajo de SAP BW se pueden utilizar directamente para la generación
de informes de SAP BW. Todos ellos (proveedor central, proveedor local y proveedor
compuesto local) sirven como InfoSitios SAP BW normales. En muchos mandantes de
reporting, estos objetos se gestionan en áreas de trabajo de InfoÁrea separadas
(@3WORKSPACE_AREA) y se encuentran allí fácilmente.
Para SAP BusinessObjects Analysis o SAP BusinessObjects DesignStudio, no es necesario
definir consultas para utilizar los datos. En su lugar, puede seleccionar el InfoSitio
directamente y ejecutar un informe en él. Para todos los demás clientes de SAP BW Reporting
(por ejemplo, SAP BusinessObjects Web Intelligence, SAP BusinessObjects Dashboards, SAP
Crystal Reports), debe existir una consulta antes de que sean visibles y estén disponibles
para leer los datos de los objetos del área de trabajo de SAP BW. Defina estas consultas en
Query Designer.

Atención:
La flexibilidad y la agilidad son las características principales de las áreas de
trabajo de SAP BW. Por lo tanto, ninguno de los objetos o opciones del área de
trabajo de SAP BW está conectado al sistema de transporte. Todas las
modificaciones y el Customizing se realizan directamente en el sistema
productivo.

532 © Copyright. Reservados todos los derechos.

 Lección: Implementación de áreas de trabajo de SAP BW/4HANA

Nota:
Para obtener más información, consulte lo siguiente:
● Página de llegada de áreas de trabajo de SAP BW: https://blogs.sap.com/
2012/03/04/sap-bw-workspaces/
● Introducción a las áreas de trabajo BW y su uso con las herramientas de la
suite SAP BusinessObjects Business Intelligence: https://archive.sap.com/
documents/docs/DOC-54697

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Comience con las áreas de trabajo de SAP BW

© Copyright. Reservados todos los derechos. 533

Capítulo 14 : Apéndice

534 © Copyright. Reservados todos los derechos.

 Capítulo 14
Lección 2
Gestión del ciclo de vida de SAP BW/4HANA -
Información adicional

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Proporcionar información adicional sobre la gestión del ciclo de vida de SAP BW/4HANA

Gestión del ciclo de vida de SAP BW/4HANA - Información adicional

SAP Near-Line Storage para SAP BW
El almacenamiento externo tiene un historial bastante largo en la evolución de SAP BW. El
concepto se denominó almacenamiento nearline (NLS) y fue suministrado inicialmente por
los interlocutores de SAP. En 2013, se introdujo la primera versión de SAP Near-Line Storage
para SAP BW. Después, se introdujeron muchas innovaciones en esta área:
● SAP BW 7.3 SP9: SAP BW NLS basado en SAP IQ para InfoCubes y DSO (clásico)
● SAP BW 7.4 SP8: Ampliado con escenarios de inventario
● SAP BW 7.5 SP1: Mejorado con DSO avanzados
● SAP BW 7.5 SP4: SAP BW NLS basado en Hadoop
● SAP BW/4HANA 1.0 SP4: Nivel frío en BW/4HANA Optimización de clasificación de datos
● SAP BW/4HANA 2.0 SP04: introducción de una gestión más estricta para el nivel frío

La siguiente figura proporciona algunos detalles sobre las diferencias del nivel DTO COLD con
respecto al almacenamiento nearline (NLS) de SAP BW

© Copyright. Reservados todos los derechos. 535

Capítulo 14 : Apéndice

Figura 387: Comparación de SAP BW NLS con SAP BW/4HANA DTO Cold Store

En SAP BW/4HANA, NLS aún está disponible como concepto de almacenamiento COLD y
puede utilizarlo en lugar de DTO en casos excepcionales. Sin embargo, Data Tiering
Optimization (DTO) es la solución de éxito para almacenar datos en varias áreas de memoria.
En SAP BW/4HANA, aún puede utilizar NLS basado en un objeto BW llamado Proceso de
archivo de datos (DAP) y, por lo tanto, los escenarios existentes de SAP BW 7.x se pueden
retener incluso después de la conversión a SAP BW/4HANA.
SAP recomienda claramente que use Data Tiering Optimization (DTO) para escenarios
nuevos siempre que sea posible para beneficiarse de todas las innovaciones que DTO ha
recibido desde que se introdujo en 2017. La conversión de NLS a DTO está disponible pero
requiere procesamiento manual porque el soporte de herramientas no está disponible. Los
pasos manuales incluyen:

1. "Inhabilitar" NLS cargando todos los datos de vuelta a las particiones de los ADSO
originales (por ejemplo, de vuelta a la memoria de SAP HANA o nivel HOT)

2. Definir las temperaturas DTO finales para estas particiones ADSO

3. Ejecutar estos cambios de DTO para devolver los datos al nivel WARM o COLD definido

536 © Copyright. Reservados todos los derechos.

 Lección: Gestión del ciclo de vida de SAP BW/4HANA - Información adicional

Figura 388: Árbol de decisión para opciones de conversión de NLS a DTO

Concepto de datos activos/no activos

El concepto de datos activos/no activos tiene como objetivo un uso más eficaz de la memoria
principal en SAP HANA en el contexto de SAP BW powered by SAP HANA principalmente. El
concepto también existe en SAP BW/4HANA, pero la importancia ha disminuido debido al
hecho de que SAP BW/4HANA Data Tiering Optimization anula este concepto. Esto significa,
por ejemplo, que si un ADSO utiliza la memoria WARM en nodos ampliados DTO, el concepto
de datos activo/no activo ya no es aplicable para este objeto.
El concepto de datos activos/no activos se basa en el concepto de desplazamiento para los
cuellos de botella de la memoria principal en la base de datos de SAP HANA. Si estos cuellos
de botella de la memoria principal se producen en SAP HANA (y solo en este caso), los
criterios estrictos basados en tiempo se utilizan normalmente para desplazar los datos de la
memoria principal al sistema de ficheros de SAP HANA. Además de esta lógica de SAP HANA,
el concepto activo/no de datos proporciona una interfaz adicional para que un desarrollador
BW proporcione criterios por objeto BW: por lo tanto, si un InfoCubo se define como no activo
en SAP BW powered by HANA, sus tablas BD se desplazan con mayor prioridad que las tablas
de otro InfoCubo. Técnicamente, las tablas de este InfoCubo no activo en este ejemplo se
fijan en el valor 7 en lugar de 5 en el parámetro Prioridad de descarga (Tr. SE14,
Parámetros de almacenamiento) en el Dictionary ABAP.
Generalmente, los datos no activos en el sistema se tratan de la siguiente manera:
● Si la memoria principal tiene capacidad suficiente, los datos no activos residen en la
memoria principal.
● Si se producen cuellos de botella en la memoria principal, los datos no activos se
desplazan con mayor prioridad que otros datos de la memoria principal de la base de
datos en el sistema de ficheros de SAP HANA.
● Si se solicitan datos no activos que residen solo en el sistema de archivos de SAP HANA
(por ejemplo, mediante una consulta BW), solo se vuelve a cargar el menor volumen de
datos posible en la memoria principal (es decir, las columnas de las particiones
relevantes).

La mayoría de los datos no activos (clasificados como tibios según la clasificación de varias
temperaturas) se almacenan en objetos DataStore de staging, que solo constan de una tabla
de entrada. Estos objetos DataStore se utilizan normalmente en la capa Open Operational
Data Store de LSA++ o en la memoria corporativa. Los datos de estos objetos normalmente

© Copyright. Reservados todos los derechos. 537

Capítulo 14 : Apéndice

se consideran datos no activos. Los datos de estas capas se conservan por motivos de
seguridad para permitir la restauración de las capas relevantes para la generación de
informes o para garantizar el acceso a los datos antiguos. Los objetos DataStore de estas
capas a menudo contienen datos que ya no se necesitan. Los nuevos datos también se
cargan en estos objetos cada día. Aparte de la solicitud actual, no obstante, estos datos no
suelen ser necesarios para el procesamiento en SAP BW_BU4HANA. Si se produce un cuello
de botella de memoria, estos objetos se deben desplazar a primera prioridad (en lugar de los
datos para los objetos relevantes para el reporting, por ejemplo), incluso si estos datos se
utilizaron por última vez hace menos de 24 horas. Los datos que ya no se necesitan no se
deben volver a cargar en la memoria principal cuando se cargan datos nuevos.
Concepto de datos activos/no activos en SAP BW/4HANA
Si los ADSO no utilizan ya la memoria DTO WARM, el concepto de datos no activos se aplica
para su tabla de entrada y el log de modificaciones por defecto. Cuando estos objetos
DataStore están activados, esto significa que la tabla de entrada y el log de modificaciones se
marcan automáticamente para el desplazamiento priorizado de la memoria principal de SAP
HANA. Se aplica una excepción a esta regla en el caso de tablas de entrada de ADSO que se
modelan como un InfoCubo (Todas las características son clave, las propiedades Informes de
unión de entrada y Tabla activa); no están marcadas como no activas.
Esto significa que cuando se activan objetos DataStore que no utilizan un nivel DTO WARM, la
tabla de entrada y el log de modificaciones se utilizan automáticamente para el
desplazamiento priorizado, a excepción de la tabla de entrada de objetos DataStore data
mart.
● Monitoreo del concepto: es posible validar y monitorear este concepto en SAP BW/
4HANA basado en Tr. RSDHDBMON o en el Workbench / Monitores / Datos activos/no
activos.
● Cambiar el concepto: Ya no es posible hacer ningún cambio en este concepto. Se ha
podido fijar el indicador "Descarga anticipada" para objetos BW en SAP BW powered by
HANA, pero en SAP BW/4HANA esta opción se ha eliminado y SAP no recomienda
modificar manualmente nada en relación con la prioridad de descarga en las tablas back
end.

Nota:
Para obtener más detalles, consulte la nota SAP 1767880: Concepto de datos no
activos para BW en la base de datos SAP HANA o la ayuda de SAP BW/4HANA
(Modelado de datos / Definición de modelos de datos físicos / Definición de
objeto DataStore / Uso del concepto de datos no activos)

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Proporcionar información adicional sobre la gestión del ciclo de vida de SAP BW/4HANA

538 © Copyright. Reservados todos los derechos.

 Capítulo 14
Lección 3
Fuentes de información adicionales para SAP
BW/4HANA

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Proporcionar fuentes de información adicionales en relación con SAP BW/4HANA

Fuentes de información de SAP BW/4HANA

Las siguientes son algunas fuentes de información adicionales sobre SAP BW/4HANA:
● Página de llegada de SAP BW/4HANA: https://www.sap.com/products/bw4hana-data-
warehousing.html
● Comunidad de SAP BW/4HANA: https://www.sap.com/community/topic/bw4hana.html
● Portal de documentación de SAP BW/4HANA: https://help.sap.com/viewer/product/
SAP_BW4HANA/2.0.4/en-US
● ¿Por qué BW/4HANA?: https://blogs.sap.com/2016/09/05/why-bw4hana/
● Guías prácticas específicas de la aplicación: https://blogs.sap.com/2012/05/23/sap-
first-guidance-collection-for-sap-bw-powered-by-sap-hana/
● Guías prácticas técnicas: https://blogs.sap.com/2016/10/11/sap-first-guidance-
collection-sap-bw-hana/
● Preguntas frecuentes sobre SAP BW/4HANA: http://go.sap.com/documents/2016/08/
c4458a08-877c-0010-82c7-eda71af511fa.html

© Copyright. Reservados todos los derechos. 539

Capítulo 14 : Apéndice

Figura 389: Preguntas frecuentes 1 de SAP BW/4HANA

Figura 390: Preguntas frecuentes sobre SAP BW/4HANA 2

540 © Copyright. Reservados todos los derechos.

 Lección: Fuentes de información adicionales para SAP BW/4HANA

Figura 391: Preguntas más frecuentes de BW/4HANA 3

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Proporcionar fuentes de información adicionales en relación con SAP BW/4HANA

© Copyright. Reservados todos los derechos. 541

Capítulo 14 : Apéndice

542 © Copyright. Reservados todos los derechos.

 Capítulo 14

Evaluación de la formación

1. El diseñador de área de trabajo de Netweaver Business Client es una herramienta en la

que un administrador de área de trabajo de BW/4HANA define los límites de
almacenamiento y el proveedor central que se utiliza en un área de trabajo de BW/
4HANA.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

© Copyright. Reservados todos los derechos. 543

 Capítulo 14

Respuestas a la Evaluación de la formación

1. El diseñador de área de trabajo de Netweaver Business Client es una herramienta en la

que un administrador de área de trabajo de BW/4HANA define los límites de
almacenamiento y el proveedor central que se utiliza en un área de trabajo de BW/
4HANA.
Indique si esta afirmación es verdadera o falsa.

X Verdadero

X Falso

Tienes razón. Workspace Designer es una herramienta para usuarios clave de la línea de
negocios que se utiliza específicamente para crear proveedores compuestos locales. Los
administradores del área de trabajo definen el proveedor central y los límites para el
espacio y el número de proveedores locales en la transacción RSWSP de SAP GUI. Leer
más en el módulo Implementación de área de trabajo SAP BW4/HANA, en el curso
BW430.

544 © Copyright. Reservados todos los derechos.

CAPÍTULO 15 Glosario

Lección 1
Glosario 547

OBJETIVOS DEL CAPÍTULO

● Ofrezca una visión general de los términos más importantes de esta capacitación de BW/
4HANA

© Copyright. Reservados todos los derechos. 545

Capítulo 15 : Glosario

546 © Copyright. Reservados todos los derechos.

 Capítulo 15
Lección 1
Glosario

OBJETIVOS DE LA LECCIÓN
Después de completar esta lección, podrá:
● Ofrezca una visión general de los términos más importantes de esta capacitación de BW/
4HANA

RESUMEN DE LA LECCIÓN
Ahora podrá:
● Ofrezca una visión general de los términos más importantes de esta capacitación de BW/
4HANA

© Copyright. Reservados todos los derechos. 547

Glosario

ABAP Core Data Services (CDS) diferentes fuentes de SAP (p. ej., SAP ERP) a varias
La infraestructura de modelado de SAP permite a los aplicaciones de destino como SAP BW o SAP BW/
desarrolladores crear un modelo de datos virtual en la 4HANA
base de datos de SAP HANA que incluye servicios de
Área de trabajo BW
aplicación de SAP ABAP y SAP HANA que se pueden
Entorno de modelado de datos ágil utilizado por los
exponer a consumidores o IU. Los casos de uso
usuarios de negocio para desarrollar sus propios
típicos son la extracción de SAP S/4HANA, la analítica
modelos de datos ad hoc dentro del sistema BW/
integrada de SAP S/4HANA o el análisis estadístico
4HANA
de SAP BW/4HANA.
Arquitectura escalable en capas (LSA++)
Acceso a datos inteligentes (SDA) de HANA Arquitectura de referencia y anteproyecto de
Componente de SAP HANA que proporciona
modelado de mejores prácticas proporcionado por
conectores a algunas bases de datos centrales para
SAP para guiar a los clientes en el diseño de una
integrar sus datos en SAP BW/4HANA
arquitectura de almacén de datos de SAP BW/4HANA
Actualización de datos maestros ampliada sostenible y eficiente
Propiedad de una característica con textos o
Atributo transitorio
atributos. Con esta propiedad, además de las tablas
Un atributo de un atributo. En BW/4HANA, los
de datos maestros activas, se crean una tabla de
atributos transitivos se pueden unir en tiempo de
entrada y un log de modificaciones (como para un
ejecución.
objeto DataStore (avanzado)) que facilita la carga de
datos maestros en paralelo y la implementación de la Autorización de análisis
gestión de calidad. Objeto de seguridad utilizado para definir reglas de
acceso a datos a nivel de fila para usuarios de
Almacenamiento nearline (NLS) informes
Conexión permanente de SAP BW/4HANA a un
almacén de datos de archivo como SAP IQ o Hadoop BW Query
para datos clasificados como poco interesantes Anteriormente conocido como BEx Query — Objeto
de modelado para definir los elementos clave de un
Ampliación ágil local informe, como las características y las cifras clave que
Un área funcional (capa) de LSA++, para
están disponibles, los valores de filtro y el diseño
proporcionar a una empresa local la posibilidad de
predeterminado de filas y columnas. Basado en
cargar sus propios datos y crear sus propios modelos
InfoSitios y utilizado normalmente en clientes de SAP
y ampliar los modelos BW/4HANA existentes,
Analytics
basados en áreas de trabajo de BW o Data Warehouse
Cloud. Cadena de procesos
Objeto de modelado que representa una secuencia de
Ampliación de almacenamiento nativo HANA pasos de job en SAP BW/4HANA utilizados para
Componente de la configuración de la plataforma SAP
automatizar la carga y el procesamiento de datos
HANA como arquitectura de ampliación para
gestionar los datos de SAP BW/4HANA clasificados Capa de data mart virtual
como tibios Anteriormente conocida como capa de virtualización -
un área funcional de la LSA++ para dar soporte a los
Análisis estadístico BW/4HANA requisitos actuales mediante el acceso y la
El sucesor del llamado contenido técnico en SAP
combinación de modelos existentes basados en
NetWeaver BW (0TCT*) que proporciona el análisis
CompositeProviders y vistas Open ODS.
de los tiempos de ejecución de Query, la carga de
procesos y la gestión del volumen de datos dentro de Capa de reporting BW
la infraestructura de SAP BW/4HANA Un área funcional (capa) de LSA++ para proporcionar
propiedades de fórmula, layout y visualización para
Aprovisionamiento de datos operativos (ODP) informes basados en consultas BW.
Un servicio general de SAP NetWeaver y SAP BW/
4HANA que admite escenarios de extracción de Capa Open ODS

548 © Copyright. Reservados todos los derechos.

Un área funcional (capa) de LSA++, utilizada para Componente aplicación
la adquisición de datos y para proporcionar datos El objeto utilizado para organizar fuentes de datos
de una fuente para la generación de informes para que sean fáciles de encontrar utilizando una
operativos. (ODS = Operational Data Store) estructura jerárquica
Característica CompositeProvider
El tipo de InfoObjeto esencial se utiliza para Objeto de modelado utilizado para modelar la capa
modelar entidades empresariales como productos virtual mediante uniones, joins, agregaciones o
o clientes y proporciona los metadatos técnicos y proyecciones de InfoSitios y proporcionar la base
empresariales esenciales, como un tipo de datos, para definir consultas BW
una longitud o una descripción. Opcionalmente,
Contenedor
puede gestionar textos, almacenar datos maestros
El componente central de HANA Deployment
como atributos y proporcionar jerarquías.
Infrastructure (HDI) y el colector de todos los
Característica de referencia objetos de tiempo de ejecución de base de datos
Una característica que hace referencia a otra utilizados por una aplicación. Es una capa lógica
característica no almacena sus propios datos que se encuentra por encima del esquema físico de
maestros, sino que apunta a las tablas de datos la base de datos donde residen los objetos de base
maestros de la característica referenciada. Como de datos reales, utilizado solo por aplicaciones XSA.
consecuencia, las propiedades relativas a los datos
Data mart ágil
maestros no se pueden modificar. Sin embargo, el
Un área funcional (capa) de LSA++, utilizada para
nombre y la descripción, las propiedades
proporcionar datos en tiempo real con cálculos de
predeterminadas para el diseño de query y las
SAP HANA o fuentes externas basadas en vistas
propiedades relacionadas con la autorización
SAP HANA.
pueden diferir de la característica referenciada.
Datos activos
Categoría de datos Datos en objetos DataStore (avanzados) o textos
Se distinguen tres categorías de datos para las
de características o atributos que se utilizan para
vistas de cálculo de SAP HANA: Cubo de categoría
reporting. (Para los objetos DataStore data mart
de datos significa que las medidas se pueden
(avanzados), la situación es ligeramente diferente:
agregar, por ejemplo, como suma, máx., media. La
la unión de la tabla de entrada y los datos activos se
dimensión Categoría de datos significa que todos
utiliza para reporting.)
los campos se tratan como atributos, pero se
omiten los registros completamente duplicados. La Datos de entrada
categoría por defecto significa que incluso los Datos en objetos DataStore (avanzados) o
registros completamente idénticos se conservan características con actualización de datos
en el conjunto de resultados. Solo las vistas de maestros ampliados que se han cargado, pero no
categoría de datos cubo o dimensión se utilizan activado. Los registros se almacenan en secuencia
directamente en los informes. con una clave técnica (solicitud, paquete, ID de
registro).
Cockpit BW/4HANA
Interfaz basada en SAP Fiori para todas las Destino open hub
actividades cruciales de SAP BW/4HANA, como la Objeto de modelado que gestiona la distribución de
administración de destinos de datos, el modelado datos de SAP BW/4HANA a destinos externos
de cadenas de procesos y la supervisión de EDW central
procesos de carga Capa de Aka Enterprise Data Warehouse, también
Cola delta operativa (ODQ) conocida como EDW central flexible: un área
Un componente central del framework ODP en el funcional de LSA++, que se utiliza para almacenar
que se mantienen los nuevos registros generados datos armonizados de forma persistente para
en el sistema fuente a la espera de la extracción a cumplir con los requisitos actuales.
consumidores como SAP BW/4HANA Escenario mixto

© Copyright. Reservados todos los derechos. 549

Aka Modelado mixto o Modelado híbrido — Enfoque comunes para opciones de implementación más
de modelado que combina ambos conceptos de flexibles
modelado de SAP BW/4HANA con conceptos de
Herramientas de desarrollo ABAP (ADT)
modelado nativos de SAP HANA
Conjunto de herramientas proporcionadas por SAP e
Esquema en estrella integradas en Eclipse para desarrollo ABAP
Un esquema estrella es la forma más simple de un
Herramientas de modelado BW/4HANA
modelo dimensional, en el que los datos se organizan
(BWMT)
en hechos y dimensiones. Los hechos representan
Conjunto de herramientas proporcionadas por SAP e
eventos contados o medidos, como un evento de
integradas en Eclipse para todas sus actividades de
ventas. Las características básicas que describen los
modelado de BW/4HANA
hechos tienen dimensiones asociadas. Un diseño más
complejo es el modelo de copo de nieve, en el que Historial de seguimiento
estas dimensiones se normalizan aún más. Integración de versiones obsoletas de datos maestros
en un modelo con datos de transacción.
Flujo de datos
Objeto de BW/4HANA que se utiliza para definir la ID de sustituto (SID)
secuencia completa de objetos en todas las capas, Cada valor de característica utilizado en la gestión de
tanto la disposición física como las capas virtuales, y informes tiene uno de ellos para acelerar la
es útil para ayudar con la visualización de flujos navegación de informes sustituyendo el valor de
complejos característica externo (por ejemplo, Inglaterra) por un
valor interno entero de 4 bytes (por ejemplo, 2834)
Fuente de datos que es mucho más rápido de procesar que los valores
Objeto de modelado utilizado para definir la interfaz
de cadena de longitud variable. SAP BW/4HANA los
para un objeto externo que proporciona datos
genera y gestiona internamente y no están expuestos
basados en los campos proporcionados y siempre
al usuario empresarial.
relacionados con un sistema fuente SAP BW/4HANA
InfoÁrea
Gestión de stocks El objeto utilizado para organizar todos los objetos de
Tratar los valores de ratio como se calculan a partir de
modelado de SAP BW/4HANA como InfoSitios,
un saldo inicial, de entrada y de salida. Este escenario
consultas BW, InfoObjetos, InfoFuentes y cadenas de
de modelado es útil si las modificaciones son poco
procesos en una estructura jerárquica
frecuentes.
InfoFuente
Gestor analítico Objeto de modelado utilizado en el flujo de datos para
Anteriormente conocido como motor OLAP: un
crear un hub de preparación de datos no persistente
componente central de SAP BW/4HANA que
para recopilar una o más fuentes de datos de entrada
proporciona el tiempo de ejecución de una consulta
que luego se pueden distribuir a uno o más destinos
BW que genera la ruta de ejecución óptima y calcula
de datos con diferentes reglas de transformación de
los resultados de una definición de consulta BW
datos
Grupo semántico
InfoObjeto
Objeto de modelado utilizado para gestionar grandes
Objeto de modelado utilizado para definir los
cantidades de datos mediante la partición lógica de
metadatos de entidades como cliente, ingresos, año.
datos relacionados en diferentes ADSOs
Existen cuatro tipos de InfoObjetos: característica,
HANA Extended Services Advanced (XSA) ratio, unidad y tiempo
El componente de servidor de aplicación de segunda
InfoSitio
generación de SAP en la plataforma SAP HANA y el
El término genérico que se utiliza para describir
sucesor de XS que proporciona todos los
cualquier proveedor de datos a una consulta BW (por
componentes necesarios para crear y ejecutar
ejemplo, CompositeProvider, objeto DataStore
aplicaciones que ahora siguen estándares de nube
(avanzado), característica para reporting de datos
maestros)

550 © Copyright. Reservados todos los derechos.

Infraestructura de despliegue HANA (HDI) datos virtual cuando un InfoSitio estándar no se
La infraestructura de despliegue utilizada para ajusta a los requisitos
crear aplicaciones SAP HANA XSA
Proyecto BW
Integración de datos inteligentes de HANA Un objeto BWMT utilizado para gestionar todos los
(SDI) objetos de modelado para una instancia de BW/
El componente que se puede añadir a SAP HANA 4HANA en las herramientas de modelado de BW/
para integrar datos de varias fuentes basadas en 4HANA
adaptadores en SAP BW/4HANA
Ratio
Log de modificaciones Tipo de InfoObjeto que se utiliza para definir
Una tabla para objetos DataStore estándar medidas como ingresos, costes, cantidad o número
(avanzados) o características con carga de datos de empleados
maestros ampliada que almacena las
Ratios acumulados
modificaciones de la tabla de datos activa en la
Los valores acumulados son ratios que se
secuencia correcta.
acumulan utilizando todas las características (por
Memoria corporativa lo tanto, también utilizando el tiempo). Los valores
Un área funcional de la LSA++, utilizada para no acumulativos son ratios que se miden en
almacenar datos detallados para soportar los (aún) relación a un período en el tiempo, por lo que no se
requisitos desconocidos. pueden acumular de forma significativa a lo largo
del tiempo.
Nodo de extensión HANA
Componente de la configuración de la plataforma Replicación
SAP HANA como arquitectura escalable para Replicación es un término utilizado en dos casos
gestionar los datos de SAP BW/4HANA para indicar la duplicación del contenido: La
clasificados como de acceso frecuente replicación de una Fuente de datos desde un
sistema fuente ODP genera una Fuente de datos
Objeto DataStore (avanzado) (ADSO)
BW (sin datos) con el mismo nombre y metadatos.
Objeto de modelado multipropósito utilizado para
(En este caso, solo se duplican los metadatos.)
almacenar datos de transacción y se utiliza en
Replicación de datos significa crear una copia de
flujos de datos a través de las distintas capas de
los datos de origen en el destino, en la mayoría de
staging con sus funciones de tratamiento delta
los casos el término se utiliza para un escenario
avanzadas
(casi) en tiempo real.
Optimización de niveles de datos (DTO)
Concepto de gestión del ciclo de vida de datos de
Replicación SLT
SAP Landscape Transformation Replication Server
SAP BW/4HANA para diferentes niveles en un
permite la replicación de tablas de base de datos en
ADSO (muy interesante, interesante, poco
SAP BW/4HANA (mediante ODP) o SAP HANA en
interesante) para gestionar el desplazamiento de
tiempo real o en modo de lotes.
los datos relacionados mediante procesos
automatizados para controlar el crecimiento de los SAP HANA Studio
datos del sistema Entorno de desarrollo integrado (IDE) basado en
Eclipse aprovechado para el modelado en SAP BW/
Proceso de transferencia de datos (DTP)
4HANA (BWMT), desarrollo ABAP (ADT) en SAP
Objeto de programación de una transformación
BW/4HANA o SAP S/4HANA on-premise, y
utilizado para definir los parámetros de carga de
administración de base de datos de SAP HANA o
datos como filtros, tamaño de paquete y
modelado de datos nativos basados en XS
tratamiento de errores
Script SQL
Proveedor BAdI
El lenguaje de consulta de base de datos nativo de
Objeto de modelado basado en una
SAP HANA que es una extensión de SQL estándar
implementación ABAP y utilizado como modelo de
con soporte adicional para el almacenamiento en

© Copyright. Reservados todos los derechos. 551

columnas, el procesamiento en memoria más el Objeto de modelado virtual que elude la preparación
procesamiento de datos avanzado como texto o de datos e integra datos gestionados externamente
espacial de forma ágil. (ODS = Operational Data Store)
Servicios ampliados de HANA (XS) Vista SAP HANA externa
Aka XS clásico, componente de servidor de Vista de cálculo de SAP HANA generada por un
aplicaciones de primera generación de SAP en la InfoSitio o una consulta BW para proporcionar una
plataforma SAP HANA que proporciona todos los interfaz nativa de modelado y consumo de SAP HANA
componentes necesarios para crear y ejecutar para los datos gestionados para estos objetos de SAP
aplicaciones. BW/4HANA
Sistema fuente Web IDE para SAP HANA
El objeto utilizado para definir interfaces para fuentes Entorno de desarrollo integrado (IDE) de última
de datos externas de SAP y no SAP y base para la generación basado en la web para la implementación,
definición de fuentes de datos administración, modelado y desarrollo de
aplicaciones de SAP HANA XSA, que se considera el
SNWD
sucesor de SAP HANA Studio y el workbench de
SAP NetWeaver Demo es un escenario de contenido
desarrollo basado en la web
predefinido con datos para escenarios de compra,
almacenamiento y venta. Se utiliza en este curso. Workbench de desarrollo basado en web
Interfaz web obsoleta utilizada por desarrolladores y
Solicitud
modeladores para crear modelos de datos y
Número de secuencia de transacción Aka (TSN): una
aplicaciones XS, y una alternativa ligera a SAP HANA
envoltura única generada que se utiliza para
Studio
identificar cada carga de datos individual y que se
puede supervisar fácilmente para ver dónde y cómo
se ha utilizado en SAP BW/4HANA
Transformación
Objeto de modelado en el flujo de datos que define las
reglas utilizadas para asignar y transformar datos de
una capa de staging de datos al siguiente
Variable
Objeto de modelado en una consulta BW que define
una reserva-espacio para un filtro cuyo valor no se
puede o no se debe fijar en la definición de consulta, y
que debería introducirse o generarse en el tiempo de
ejecución de la consulta
Vista de cálculo
Objeto de modelado central en SAP HANA que se
utiliza para definir el modelo de datos de cualquier
tipo, incluidos la dimensión, el cubo y el esquema en
estrella de cubo. Las vistas de cálculo clásicas son
aquellas que gestiona SAP HANA Extended
Application Services (XS clásico), mientras que han
sido sustituidas por vistas de cálculo HDI gestionadas
por HANA Deployment Infrastructure (HDI) por SAP
HANA Extended Application Services Advanced (XSA)
en SAP HANA 2.0
Vista Open ODS

552 © Copyright. Reservados todos los derechos.

© Copyright. Reservados todos los derechos. 553