Uso de una vista de atributos de SAP HANA en SAP Data Services

SAP Data Services es algo más que una herramienta de ETL (Extract, Transform, Load) es una plataforma de tratamiento de datos con múltiples funciones y posibilidades, especialmente por las amplias alternativas de utilizar diversos tipos fuentes de datos. En un entono SAP HANA se acopla…


SAP Data Services es algo más que una herramienta de ETL (Extract, Transform, Load) es una plataforma de tratamiento de datos con múltiples funciones y posibilidades, especialmente por las amplias alternativas de utilizar diversos tipos fuentes de datos. En un entono SAP HANA se acopla perfectamente, pudiendo ser el instrumento clave para mover los datos desde y hacia la base de datos de esta plataforma in-memory computing.

Una de las posibilidades que podemos tener en cuenta es el uso de Vistas de Atributos (Attibute View) de SAP HANA en Data Services como DataStore (objeto que define una conexión a una fuente de datos), el procedimiento es señalado en la nota de referencia.

Referencia: SAP Note 2009982

Importación de objetos BW para modelarlos en SAP HANA Studio

Si tenemos SAP NetWeaver Business Warehouse sobre una plataforma SAP HANA (BW on HANA) podríamos importar los denominados objetos BW para que sean accesibles desde la interfaz SAP HANA Studio y por consiguiente diseñar vistas de información que faciliten el acceso a los datos desde MS Excel o aplicaciones cliente tales como los componentes SAP BusinessObjects BI e inclusive…


Si tenemos SAP NetWeaver Business Warehouse sobre una plataforma SAP HANA (BW on HANA) podríamos importar los denominados objetos BW para que sean accesibles desde la interfaz SAP HANA Studio y por consiguiente diseñar vistas de información que faciliten el acceso a los datos desde MS Excel o aplicaciones cliente tales como los componentes SAP BusinessObjects BI e inclusive diseñar Universos para que los usuarios de aplicaciones como Lumira o Predictive Analysis pueda acceder a esta información dado que estas herramientas, por el momento, no pueden acceder directamente a consultas BEx.

Los objetos BW importados son presentados en la interfaz SAP HANA según la naturaleza del objeto, así un DataStore lo verámos como una vista analítica con el mimo nombre del objeto origen.  La importación de un cubo o también denominado infocubo generaría una vista analítica de uso interno con el prefijo _INTERNAL y una vista calculada la que podría ser utilizada por los usuarios. Una QuerySnapshot InfoProvider generaría una vista analítica. Un infoObjeto tipo Característica generaría una vista de atributos.

Para más información sobre la importación de objetos SAP NW BW para modelarlos en SAP HANA Studio consultar la nota 1764251 la cual puede presentar novedades en cualquier momento.

Reglas de oro para diseñadores SAP HANA

En SAP SCN encontramos un post que será muy útil para todos aquellos que estén comenzando a diseñar modelos de datos o a desarrollar aplicaciones en una plataforma SAP HANA. Por el momento se señalan seis “reglas de oro” que seguro se podrán ir ampliando en la medida que SAP HANA siga evolucionando al ritmo que lleva, presentando grandes cambios en cada actualización.


En SAP SCN encontramos un post que será muy útil para todos aquellos que estén comenzando a diseñar modelos de datos o a desarrollar aplicaciones en una plataforma SAP HANA. Por el momento se señalan seis “reglas de oro” que seguro se podrán ir ampliando en la medida que SAP HANA siga evolucionando al ritmo que lleva, presentando grandes cambios en cada actualización.

  1. Nunca utilices tablas con almacenamiento basado en filas.  SAP HANA está preparado para trabajar con los dos tipos de almacenamiento de tablas (basado en filas y en columnas), el sistema ya cuenta con mecanismos necesarios para optimizar la grabación de datos en tablas con almacenamiento columnar.  Una de las claves de éxito de HANA es el almacenamiento en columnas, son muy pocos los casos en que se recomienda las tablas con almacenamiento en filas, especialmente la tablas de parámetros o configuración.
  2. No crear índices. El almacenamiento columnar, equivale a tener un índice por cada columna, por lo que crear índices secundarios, tal como se estila hacer en un sistema de base de datos relacional tradicional, no ayuda a reducir los tiempos de acceso a los datos.  Sólo podría ser útil en el caso de tener una tabla muy grande sobre la que se realiza una selección muy pequeña de un conjunto de datos.
  3. Utilizar la Perspectiva Development de SAP HANA Studio.  SAP HANA Studio es la herramienta que facilita todas las tareas de administración y desarrollo en la plataforma HANA.  Las capacidades que ofrece SAP HANA Studio están divididas en Perspectivas (véase como paneles o ventanas), dependiendo de las necesidades y autorizaciones disponibles se podrán habilitar las perspectivas. Para los desarrolladores se ofrecen varias perspectivas entre ellas System, Modeler  y Debug, se sugiere el uso de la perspectiva Development, debidamente configurada se puede contar con todos los recursos necesarios en una única perspectiva.
  4. No utilizar SQLScript, a menos que sea necesario.  SAP HANA ofrece una implementación SQL, la cual se denomina SQLScript, este lenguaje puede ser muy útil en determinadas circunstancias, pero en muchos casos lo que se realice con este lenguaje se podría hacer con vistas de información (de atributos, analíticas y de cálculos) las cuales son más eficientes dado que SQLScript no paraleliza la ejecución de procesos (hasta la reciente actualización SPS07 este es el comportamiento de SQLScript, quizás más adelante se ofrezca una actualización que mejore este comportamiento).
  5. Si utiliza SQLScript, no utilice cursores o SQL dinámico. El uso de estas sentencias ocasiona pérdida de rendimiento, especialmente el uso de SQL dinámico para referirse a nombres de columnas en sentencias INSERT o SELECT, hay otras alternativas disponibles, como las vistas de información (para los SELECTs) o el uso del lenguaje Python (para cargar datos).
  6. Evitar Joins en grandes volúmenes de datos. Unir tablas con más de cien mil filas resultará ineficiente, en su lugar se sugiere normalizar vía el uso de vistas analíticas, para luego unir vía una vista calculada.

Referencia: SAP SCN

Uso de Vistas Analíticas de SAP HANA en BEx Query Designer

En un escenario SAP NetWeaver BW powered by SAP HANA o simplemente BW on HANA, las posibilidades de utilizar estructuras de datos nativos de HANA con los de BW o viceversa, se van ampliando con cada actualización tanto de HANA como de BW.


En un escenario SAP NetWeaver BW powered by SAP HANA o simplemente BW on HANA, las posibilidades de utilizar estructuras de datos nativos de HANA con los de BW o viceversa, se van ampliando con cada actualización tanto de HANA como de BW. 

Creación de un VirtualProvider Based on a HANA Model

Por ejemplo, si necesitásemos diseñar una consulta BEx con datos BW y datos HANA, actualmente, esta necesidad puntual podríamos cubrirla del siguiente modo:

  • Crearíamos una vista analítica HANA (analytical view) para acceder a los datos HANA que se requieren.
  • Desde NW BW, accedemos a la transacción RSA1 y creamos un VirtualProvider de tipo “Based on a HANA Model” en la InfoArea que veamos conveniente. A través de botón de “detalles” seleccionamos la vista analítica HANA que deseamos utilizar.
  • Luego visualizaremos los atributos de la vista analítica, seleccionaremos aquellos que deseamos que sean accesibles desde el VirtualProvider y luego vincularemos con objetos BW.
  • Grabamos y activamos el VirtualProvider.  A partir de este punto podríamos utilizar BEx Query Designer para construir una consulta o podríamos definir un Multiprovider para combinar el VirtualProvider con otras fuentes BW.

Referencia: Post «Creación de una “Analytic View” de SAP HANA»

¿SQLScript?

SQLScript es una variante del lenguaje estándar SQL-92 (Structured Query Language), diseñado por SAP para obtener el máximo beneficio de un sistema de base de datos de SAP HANA. Tanto el SQL estándar, como SQLScript pueden ser usados en HANA. El SQL tradicional se puede utilizar para crear tablas de datos (cuando las estructuras de metadatos no pueden ser importadas). También se pueden utilizar SQL para crear vistas de cálculo (calculation views), para manipular los datos y gestionar transacciones.


SQLScript es una variante del lenguaje estándar SQL-92 (Structured Query Language), diseñado por SAP  para obtener el máximo beneficio de un sistema de base de datos de SAP HANA. Tanto el SQL estándar, como SQLScript pueden ser usados en HANA. El SQL tradicional se puede utilizar para crear tablas de datos (cuando las estructuras de metadatos no pueden ser importadas).  También se pueden utilizar SQL para crear vistas de cálculo (calculation views), para manipular los datos y gestionar transacciones.

Muestra de la sintasis de SQLScript

SQLScript está compuesto por un grupo extensiones (Data Extensions, Procedural Extensions y Functional Extensions) que contribuirán a que las operaciones con los datos se ejecuten sobre la base de datos HANA, utilizando de la mejor manera su arquitectura para obtener el máximo  rendimiento del sistema. Para este fin, destacan las funciones CE:

Funciones CE más populares de SQLScript de SAP HANA

Mensaje final: si estás escribiendo sentencias SQL en SAP HANA, siempre que puedas, utiliza la sintaxis de SQLScript para obtener el mejor rendimiento al acceder a la información.