SAP HANA, la base de datos.

 

 2- SAP HANA, Base de Datos. 

La base de datos SAP HANA conceptualmente trata de aumentar la velocidad en las respuestas, aumentando la velocidad de ejecución de consultas de las bases de datos a través de la utilización del almacenamiento de datos en memoria, y por lo tanto aumentar la velocidad de las aplicaciones. Con la base de datos SAP HANA, las consultas pueden ser ejecutadas en paralelo y rápidamente. Esto significa que las técnicas de codificación mas complejas, por ejemplo, pre-cálculo de los valores , que han sido usadas por las bases de datos tradicionales para mantener un buen nivel de rendimiento ya no son necesarias. Cuando este desarrollo extra y complejo se retira, las aplicaciones pueden ser creadas y modificadas de una manera sencilla y clara, permitiendo tiempos más rápidos de desarrollo.

SAP HANA también trabaja correctamente en las bases de datos más tradicionales, por ejemplo,  con tablas con una orientación en filas. Esta combinación de lo clásico y de las nuevas tecnologías permite al desarrollador elegir la mejor tecnología para su aplicación y, en cualquier caso, utilizar los dos en paralelo.

2.1- Conceptos Básicos. 

 2.1.1- Impacto del nuevo Hardware sobre la Arquitectura del sistema de la Base de Datos.

 
 Históricamente los sistemas de bases de datos se han diseñado para funcionar bien en sistemas informáticos de RAM limitada, esto tuvo el efecto de que los discos duros tuvieses un acceso lento I / O, siendo este el principal cuello de botella en el rendimiento en el acceso a los datos. En consecuencia, la arquitectura de los sistemas fue diseñada con un enfoque para tratar de optimizar el acceso al disco, por ejemplo, minimizando el acceso del número de bloques de disco (o páginas) que se lee en la memoria principal en el tratamiento de una consulta.

Las arquitecturas de las computadoras ha cambiado en los últimos años. Ahora las CPU multi-core son bastante comunes, con una comunicación entre los núcleos del procesador que permite el procesamiento en paralelo de datos. Por otro lado la memoria principal ya no es un recurso limitado, los servidores modernos pueden tener 2 TB de memoria del sistema y esto permite a bases de datos completas, ser alojadas en la memoria RAM. Actualmente los procesadores del servidor tienen hasta 64 núcleos y los 128 núcleos pronto estarán disponibles. Con el creciente número de núcleos, las CPU son capaces de procesar mas datos en menos tiempo.

Esto cambia el cuello de botella en el rendimiento de disco E / S para la transferencia de datos entre la CPU y la memoria caché de la memoria principal (véase la figura. 1).

Las Bases de datos tradicionales para el procesamiento de transacciones en línea (OLTP) no utilizan eficientemente el hardware actual. Se ha demostrado en 1999 por Alamaki, que cuando todas las bases de datos tienen los datos cargados en la memoria principal de la CPU pasa la mitad de su tiempo de ejecución en puestos de espera, es decir, esperando que los datos se carguen desde la memoria principal a la memoria caché de CPU.

Así que, ¿cuáles son las características principales de un sistema de base de datos que se ejecuta con este nuevo hardware?


En la memoria de bases de datos. Todos los datos pertinentes están disponibles en la memoria principal. Esta característica evita la pérdida de rendimiento de disco I / O. Con todos los datos en la memoria, usar técnicas para reducir la E / S en disco como índices ya no es necesario. El almacenamiento en disco se requiere para la persistencia y permanencia de los datos, por ejemplo en caso de un fallo de alimentación.

Organización de la memoria Cache-consistente. El diseño debe minimizar el número de errores de caché y evitar paradas CPU en el acceso a memoria. Un mecanismo general para lograr esto es el de maximizar la localidad espacial de los datos, es decir, que los datos a los que se deben acceder consecutivamente deben ser almacenados de forma contigua en la memoria. Por ejemplo en las operaciones de búsqueda de datos en tablas se puede acelerar mediante la organización de los datos en columnas en lugar de filas.

Apoyo a la ejecución en paralelo. Las altas velocidades de ejecución de la CPU se consiguen añadiendo más núcleos a la CPU dando como resultado una mayor densidad de embalaje en el chip y la optimización de las rutas electrónicas actuales. Los avances de velocidad disponibles utilizando estas técnicas han sido, en su mayor parte, ya agotados. Estos avances se basan en algoritmos que se utilizarán en las bases de datos con el fin de aprovechar al máximo los recursos informáticos disponibles.

2.1.2- Almacenamiento basado en Columnas y Filas.

Como se mencionó anteriormente la organización del almacenamiento en columnas en ciertas situaciones conduce a menos fallos de caché y de CPU. Es particularmente útil cuando usamos la CPU para escanear a través de una columna completa. Por ejemplo, esto sucede cuando se ejecuta una consulta que no puede ser satisfecha por el índice de búsqueda o cuando se calculan funciones de agregado sobre la columna, por ejemplo, la suma o la media.

Las Filas indexadas son los medios clásicos para acelerar el acceso a tablas basadas en filas.

Por lo tanto, los programadores de bases de datos tienen que entender las ventajas y desventajas de ambas técnicas de almacenamiento con el fin de encontrar un equilibrio adecuado.


Conceptualmente, una tabla de base de datos es una estructura de dos dimensiones de datos con celdas organizadas en filas y columnas. La memoria de computadora sin embargo está organizada como una estructura lineal. Para almacenar una tabla en memoria lineal, existen dos opciones, como se muestra en la figura segunda. Una fila tiene un almacenamiento orientado a almacenar una tabla como una secuencia de registros, cada uno de los cuales contiene los campos de una fila. A la inversa, en una columna se almacenan los valores (registros) en ubicaciones de memoria contiguas.
 

El concepto de almacenamiento de datos en columnas  se ha utilizado durante bastante tiempo. Históricamente fue utilizado principalmente para el análisis y almacenamiento de datos donde las funciones de agregado jugaban un papel importante. Usando esta forma de almacenar los datos en columnas, las aplicaciones OLTP requieren un enfoque equilibrado de la inserción y la indexación de los datos de las columnas para minimizar errores de caché.


La base de datos SAP HANA permite al desarrollador especificar si una tabla se almacena en modo de columnas o filas. Por tanto, es posible alterar una tabla existente basada en columnas a una basada en filas y viceversa. Ver el SAP HANA SQL Reference, para mas detalles.

Las tablas basadas ​​en columnas tienen una serie de ventajas en las siguientes circunstancias:

 - Los cálculos se ejecuta normalmente en una o sólo unas pocas columnas.
 - En la tabla se hace una búsqueda basada en los valores de varias columnas.
 - La tabla tiene un gran número de columnas.
 - La tabla tiene un gran número de filas y  son requeridas operaciones con columnas como (agregado, escaneado, etc.)
 - Las altas tasas de compresión puede lograrse porque la mayoría de las columnas contienen solo unos pocos valores distintos. (en comparación con el número de filas).

Las Tablas basadas en filas  tienen ventajas en las siguientes circunstancias:

La aplicación sólo necesita procesar un solo registro a la vez (muchos selecciones y / o actualizaciones de los registros individuales).

- Normalmente, la aplicación necesita acceder a un completo registro (o fila).
- Las columnas contienen principalmente valores distintos además de que la tasa de compresión sería baja.
- No hay agregación ni busquedas rápidas.
- La tabla tiene un pequeño número de registros. (e. g. configuration tables).

Para habilitar las transferencias de datos on-the-fly, informes ad-hoc, y para beneficiarse de mecanismos de compresión, se recomienda que los datos de transacciónes se almacenen en una tablas basadas en columnas. La base de datos de SAP HANA  permite la unión de tablas basadas en filas con tablas basadas en columnas. Sin embargo, es más eficiente para unir tablas que se encuentren o en filas o en columnas. Por ejemplo, los datos maestros que frecuentemente se unen con los datos de transacciones también deben ser almacenados en las tablas en columnas.

2.1.3- Ventajas de las Tablas en columnas.

Si se cumplen los criterios anteriormente mencionados  para las tablas basadas en columnas, estas tienen varias ventajas que se explican en esta sección. No debe dar la impresión de que las tablas en columnas son siempre la mejor opción. También hay situaciones en las que las tablas basadas en filas son mas ventajosas.

Ventaja: Mayores tasas de compresión de datos
 
El objetivo de mantener todos los datos relevantes en la memoria principal, esto se puede lograr con un costo menor si ultilizamos datos comprimidos. El almacenamiento en columnas de datos permite una compresión altamente eficiente. Especialmente si se ordena una columna, normalmente habrá varios valores contiguos colocados adyacentes entre sí en la memoria. En este caso, los métodos de compresión, tales como run-length encoding, cluster coding or dictionary coding, son los que podríamos utilizar. Esto es especialmente ventajoso para aplicaciones en las que muchas de las columnas de la tabla contienen solamente unos pocos valores distintos en comparación con el número de filas. Ejemplos extremos son códigos como códigos de país o códigos postales, otros ejemplos válidos son números de cliente y cuenta, códigos de región, códigos de canal de ventas, o los códigos de estado. Muchos de estos últimos se utilizan como claves externas de otras tablas de la base de datos, e. g. tablas que contienen los datos de pedidos de los clientes y los registros contables.  

Este alto grado de redundancia dentro de una columna permite una compresión eficaz de los datos. En el almacenamiento basado en filas, posiciones sucesivas de memoria contienen datos de diferentes columnas, por lo que algunos métodos de compresión, no se pueden utilizar. En el almacenamiento por columnas se puede lograr un factor de compresión de 5, en comparación con los sistemas tradicionales de almacenamiento orientados en filas.

Técnicas de compresión:
 
Run-length encoding. Si los datos de una columna se ordena hay una alta probabilidad de que dos o más elementos contengan los mismos valores. Al ejecutar Run-length encoding  cuenta el número de elementos de la columna consecutivos con los mismos valores. Para lograr esto, la columna original se reemplaza con una lista de dos columnas. La primera columna contiene los valores que aparecen en la columna de la tabla original y la segunda columna contiene las ocurrencias que tiene un determinado valor que se repite. A partir de este informción la columna original puede ser reconstruida.
 
Cluster encoding. Esta técnica de compresión funciona mediante la búsqueda de múltiples ocurrencias de la misma secuencia de valores dentro de la columna original. La columna comprimida consta de una lista de dos columnas con lo que la primera columna contiene los elementos de una secuencia particular y la segunda columna contiene los números de filas donde la secuencia comienza en la columna original. Muchos programas populares de compresión de datos utilizan esta técnica para comprimir archivos de texto.
 
Dictionary encoding. Son columnas de las tablas que contienen sólo un número relativamente pequeño de valores distintos que pueden ser efectivamente comprimidos mediante la enumeración de los distintos valores y almacenar sólo los números. Esta técnica requiere que una tabla adicional, el diccionario, que se mantiene en la primera columna  que contiene los valores originales y en la segunda los números que representan los valores. Esta técnica conduce a tasas de compresión alta, es muy común, e. g. en los códigos de país o números clientes, pero pocas veces se considera como una técnica de compresión.

Ventajas: Alto rendimento en operaciones con columnas.

Existen operaciones con columnas para la organización de datos en columnas únicas, tales como la búsqueda o agregaciones, que pueden ser implementadas en una matriz almacenados en ubicaciones de memoria contiguas. Tales operaciones tienen localidad espacial alta y eficiente y pueden ser ejecutadas en la caché de la CPU.

Con un almacenamiento basado en filas, las mismas operaciónes serían mucho más lentas porque los datos de la misma columna se distribuyen a través de la memoria y la CPU se ralentiza por fallos de la caché.
 
Supongamos que se desea agregar la suma de todas las cantidades de ventas en el ejemplo de la figura 2 utilizando una tabla basada en filas. La transferencia de datos desde la memoria principal a la memoria caché CPU, pasa siempre en bloques de tamaño fijo llamadas "líneas de caché" (por ejemplo, 64 bytes). Con una organización de los datos basados en filas, puede ocurrir que cada línea de caché sólo contiene una "venta" valor (almacenado en 4 bytes), mientras que los bytes restantes se utilizan para los otros campos del registro de datos. Para cada valor necesario para la agregación  haría falta un nuevo acceso a la memoria principal. Esto demuestra que una organización basada en filas cuando se realizan operaciónes, estas son relentizadas por fallos de caché que hacen que la CPU tenga que esperar a que los datos requeridos esten disponibles. Con un almacenamiento basado en columnas, todos los valores de las ventas se almacenan en memoria contigua, así que la línea de caché que contienen 16 valores que son todos necesarios en el cálculo de la suma. Además, el hecho de que las columnas se almacenan en memoria contigua  los controladores de memoria permiten precargar los datos, que reduce aún más el número de fallos de caché.


Como se explicó anteriormente, los datos con organización columnar también permiten una compresión de datos altamente eficiente. Esto no sólo ahorra memoria, sino que también aumenta la velocidad por las siguientes razones:

- Los datos comprimidos se pueden cargar en la memoria caché de la CPU más rápidamente. Esto es debido a que el factor limitante es el transporte de datos entre la memoria y la caché de la CPU, y por lo tanto la ganancia de rendimiento supera el tiempo de cálculo adicional necesario para la descompresión.
 
- Con la codificación de diccionario, las columnas se almacenan como secuencias de bits codificados por números enteros. Eso significa se puede ejecutar un chequeo por la igualdad entre los números enteros (por ejemplo durante las exploraciones o las operaciones de combinación). Esto es mucho más rápido que comparando, por ejemplo, valores de cadena.
 
- Compresión puede acelerar las operaciones tales como exploraciones y agregaciones si el operador es consciente de la compresión. Dada una tasa de buena compresión, el calculo de la suma de los valores codificados, comprimida en una columna será mucho más rápido si en la columna hay muchos campos con el mismo valor por lo que se podría sustituir por una sola multiplicación. Un estudio científico reciente mostró una ganancia de rendimiento de factor de 100 a 1000 cuando se comparan las operaciones sobre valores enteros codificados comprimidos con operaciones sobre los datos sin comprimir. 


Ventaja: Eliminación de índices adicionales


El almacenamiento de datos en columnas, en muchos casos, elimina la necesidad de estructuras con índices adicionales. El almacenamiento de datos de las columnas es funcionalmente similar a tener un índice integrado para cada columna. La velocidad de barrido de la columna en memoria y los mecanismos de compresión - especialmente la compresion del diccionario- permiten operaciones de lectura con un rendimiento mucho mas alto. En muchos casos no se requiere tener índices adicionales. La eliminación de índices adicionales reduce la complejidad y elimina esfuerzo para definir y mantener los metadatos.

Ventaja: Paralelización

 El sistema basado en almacenamiento en columnas también hace que sea fácil de ejecutar operaciones en paralelo usando múltiples núcleos del procesador. En un almacenaje en columnas ya están los datos verticalmente divididos. Esto significa que las operaciones en diferentes columnas pueden ser fácilmente procesadas en paralelo. Si varias columnas necesitan operaciones de búsqueda o agregados, cada una de estas operaciones puede ser asignada a un núcleo de procesador diferente. Además las operaciones en una columna se pueden paralelizar por reparto de la columna en múltiples secciones que se pueden procesar por diferentes núcleos de procesador en paralelo.

Ventaja: Eliminación de los Agregados.
 
Las aplicaciones tradicionales de negocios utilizan técnicas específicas para aumentar el rendimiento de lectura de los agregados . Esto significa que los desarrolladores de aplicaciones hacen definir tablas adicionales en los que la aplicación usa y almacena redundantemente los resultados de los agregados (por ejemplo, sumas) computado en otras tablas. Los agregados se calculan y almacenan ya sea después de cada operación de escritura de los datos agregados, o en las horas programadas. 
 
Con una velocidad de exploración de varios gigabytes por milisegundo, las columnas alojadas en la memoria permiten calcular los agregados de grandes cantidades de datos sobre la marcha con un alto rendimiento. Se espera que esto elimine la necesidad de agregados en muchos casos.
 
En las aplicaciones financieras, los distintos tipos de totales y los saldos son datos de cantidad tipicamente persistentes. Por ejemplo, contabilidad general, cuentas por cobrar por pagar, cuentas, libro de caja, libro mayor de materiales, etc, usando un almacenamiento en forma de columnas en memoria, estas cantidades así como todos los totales y los saldos de los elementos del documento de contabilidad se pueden calcular sobre la marcha con un alto rendimiento.

La eliminación de los agregados tiene varias ventajas:
 
La ventaja principal es el simplificado del modelo de datos. Ya que los agregados , hace que tengamos tablas adicionales que se necesitan y por tanto hacen que el modelo de datos sea más complejo. En la aplicación SAP Business de finanzas, por ejemplo, los totales y los saldos persistentes se almacenan con un esquema en estrella (véase la sección 2.3.1).  Se han introducido objetos específicos de negocio para los totales y balances, y cada una de ellos se guardan en tablas de varias dimensiones.

De todas estas tablas se pueden quitar, si los totales y los saldos se calculan sobre la marcha. Un modelo de datos simplificado hace que el desarrollo sea más eficiente, elimina errores de programación y aumenta la mantenibilidad.

Simplifica la lógica de la aplicación.

Se necesitan programar funciones y métodos de agregación especiales para actualizar los valores agregados a intervalos de tiempo determinados (por ejemplo una vez al día). Al eliminar los agregados persistentes, esta lógica adicional de actualización de los valores persistentes en la base de datos, ya no es necesaria.

Mayor nivel de concurrencia. 

Con los agregados después de cada operación de escritura se produce un bloqueo para actualizar los agregados. Esta concurrencia límita y puede llevar a problemas de rendimiento. Sin agregados, sólo se escriben las posiciones del documento, y esto se puede hacer al mismo tiempo sin ningún tipo de bloqueo.

Contemporaneidad de los valores agregados. 

Con la agregación en tiempo de ejecución, los valores agregados están siempre al día mientras que los agregados peremanentes se actualizan sólo a unas horas precisas.
 

 2.2- Descripción de la Arquitectura

El diagrama de bloques en la figura 4 proporciona una visión general de la arquitectura conceptual de la base de datos de SAP HANA. En la parte superior del diagrama se puede ver que hay clientes que se conectan al sistema de base de datos. Una conexión de cliente forma una sesión dentro de la base de datos, y se comunican por sentencias SQL .

En la base de datos SAP HANA, cada sentencia SQL es procesada en el contexto de una transacción. 

Las nuevas sesiones se asignan implícitamente a una nueva transacción. El administrador de transacciones es el componente que coordina las transacciones de bases de datos, los controles de aislamiento transaccional y hace un seguimiento de la ejecución y bloqueo de transacciones. Cuando una transacción se confirma o se revierte, el administrador de transacciones informa a los motores de almacenamiento involucrados acerca de este evento, para que puedan llevar a cabo las acciones necesarias. El administrador de transacciones coopera con la capa persistente para lograr transacciones rápidas y duraderas.

Las peticiones de los clientes son analizadas y ejecutadas por un conjunto de componentes como procesamiento de solicitudes y de control de ejecución. La figura 4 muestra las principales funciones de esta capa: 

- El analizador de la petición analiza la solicitud del cliente y lo envía al componente responsable.


- Las instrucciones de definición de datos se envían al gestor de metadatos y las invocaciones de objetos  se remite al almacen de objetos. Los estados de manipulación de datos se reenvían al optimizador que crea un plan de ejecución optimizado que se pasa a la capa de ejecución.

La base de datos SAP HANA también ha incorporado soporte para modelos específicos (por ejemplo, para la planificación financiera) y ofrece capacidades de scripting que permite cálculos específicos de la aplicación para funcionar dentro de la base de datos. La base de datos SAP HANA tiene su propio lenguaje de scripts llamado SQLScript que está diseñado para permitir optimizaciones y paralelización en el tratamiento de los datos. SQLScript se basa en funciones que operan sobre tablas utilizando consultas SQL para el procesamiento conjunto de los datos.

La base de datos SAP HANA también contiene un componente llamado el motor de planificación que permite a las aplicaciones de planificación financiera ejecutar operaciones básicas de planificación de la capa de base de datos. Una operación básica como es la creación de una nueva versión de un conjunto de datos como una copia de uno ya existente. Por ejemplo: los datos de planificación para un nuevo año se crea como una copia de los datos del año anterior. Esto requiere el filtrado por año y la actualización de la dimensión de tiempo. Otro ejemplo para una operación de planificación es la operación de desagregación que distribuye los valores objetivo de mayor a niveles de agregación inferiores basado en una función de distribución.
  
Las características de las bases de datos de SAP HANA  como el SQLScript y operaciones de planificación se implementan utilizando una infraestructura común en las funciones integradas. 
Los metadatos se pueden acceder a través del gestor de metadatos. Los metadatos de la base de datos de SAP HANA se compone de una variedad de objetos, como las definiciones de tablas relacionales, columnas, vistas e índices, las definiciones de las funciones y los metadatos SQLScript. Los metadatos de todos estos tipos se almacenan en un catálogo común para todos en la base de datos SAP HANA  "in-memory", en la memoria de almacenamiento de columna, almacén de objetos y basada en disco. Los metadatos se almacenan en tablas forma de filas. Las características de la base de datos de SAP HANA que se verán en los capítulos siguientes, como soporte de transacciones, versión multi-control de concurrencia, también se utilizan para la gestión de los metadatos.
 
Las tablas formadas por filas y las tablas columnares se pueden combinar en una instrucción SQL, los motores correspondientes deben ser capaces de utilizar los resultados intermedios creados por una y otra.  

Una diferencia importante entre los dos motores es la forma en que procesan datos: Las tablas formadas por filas usan operadores at-a-time usando iteradores. 

Las operaciones con los datos en forma de columnas  (como exploración, agregado y así sucesivamente) requieren que toda la columna está disponible en ubicaciones de memoria contiguas. Para el intercambio de resultados intermedios, la consultas de fila puede proporcionar resultados a la consulta columna y los datos se transforman como filas completas en la memoria mientras que en las columnas se pueden exponer los resultados utilizando la interfaz necesaria para almacenar fila.

La "capa de persistente" es responsable de la durabilidad de las transacciones. Se asegura de que la base de datos se restaura al estado más reciente después de un reinicio. 

Para lograr este objetivo de forma eficiente la capa persistente utiliza una combinación de escritura registros, paginación  y puntos de retorno. La capa persistente ofrece interfaces para la escritura y lectura de datos. SAP HANA  también contiene un componente que gestiona el registro de transacciones. Las entradas de los registros se pueden escribir implícitamente por la capa de persistencia cuando se escriben datos a través de la interfaz de persistencia o explícitamente por medio de una interfaz de registro.
 
El "authorization manager" es invocado por otros componentes de la base de datos de SAP HANA para comprobar si el usuario tiene los privilegios necesarios para ejecutar las operaciones solicitadas. SAP HANA permite la concesión de privilegios a usuarios o roles. Un privilegio otorga el derecho a realizar una operación determinada (por ejemplo, crear, actualizar, seleccionar, ejecutar, y así sucesivamente) en un objeto determinado (por ejemplo, una tabla, vista, función SQLScript, y así sucesivamente).  

La base de datos SAP HANA soporta privilegios que representan filtros o limitaciones jerarquicas en la obtención de detalles para las consultas analíticas. Los privilegios nos permiten conceder acceso a los valores con una cierta combinación de atributos. Esto podría, por ejemplo, utilizarse para restringir el acceso a un cubo con datos de ventas según valores con atributos de dimensión de la región = 'US' y año = '2010 '. Al igual que los privilegios se definen también los valores de atributos de dimensión y no en los metadatos,  se evalúan dinámicamente durante la ejecución de la consulta.

Los usuarios se autentican ya sea por la base de datos SAP HANA a sí mismo (entrar con usuario y contraseña) o autenticación puede ser delegada a un proveedor de autenticación externos, tales como un directorio LDAP.  

2.3- Conceptos de base de datos:  Tablas, Modelos y procesamiento de la vista.

SAP HANA base de datos es un sistema de base de datos muy capaz, pero requiere un poco de comprensión, y para ser utilizado correctamente, para obtener un buen rendimiento. En esta sección analizaremos algunos conceptos clave de la base de datos SAP HANA. Se mostrará también un análisis de cómo se puede abordar el modelado para lograr unos buenos resultados.

2.3.1- Tablas, Vistas, y  Esquemas en forma de estrella.

 La base de datos SAP HANA permite dar forma a los datos en forma de tablas y vistas. Las tablas son estructuras de datos tabulares, cada fila da identificación de una entidad en particular, y cada columna tiene un nombre único. Los campos de datos de una fila se le llaman los atributos de la entidad. La palabra "atributo" se utiliza con diferentes significados en este documento. Se puede indicar una columna de la tabla, un campo de datos particular de una fila de la tabla, o el contenido de un campo de datos. El significado respectivo dependerá del contexto.

Las vistas son combinaciones y selecciones de datos modelado de las tablas para servir a un propósito en particular. Visto siempre aparecen como tablas de lectura mecánica, es decir, operaciones de base de datos que leídas de las tablas también se puede utilizar para leer datos de vistas. Por ejemplo, puede crear vistas que sólo tienen que seleccionar algunas columnas de una tabla o vistas que seleccionan algunas columnas y algunas filas de acuerdo a un modelo de filtro.

En aplicaciones que usan los esquemas de base de datos en estrellas son un patrón general: Las tablas  son listados de las transacciones comerciales, mientras que los datos de enlace suelen ser datos maestros. Estas tablas que se enlazan son a menudo llamadas tablas de dimensiones. Una tabla es adjacente a las tablas que está ligada, en las tablas de dimensiones a menudo se llama un esquema en estrella porque cuando se expresa gráficamente parece ver como una estrella. En SAP HANA pueden ser creados esquemas en estrellas usando tablas o vistas.
 
2.3.2- SAP HANA Modelado.

Antes de continuar a discutir la forma de modelo en SAP HANA, en primer lugar, es importante comprender cada uno de los diferentes tipos de vistas de modelado SAP HANA  y sus capacidades. 

Vistas Atributo.

Vistas atributo se utilizan para definir combinaciones entre las tablas, y explicar el sistema de forma razonable para estas uniones a realizar. También se puede utilizar para seleccionar un subconjunto de las columnas y filas de una tabla.

Una de las aplicaciones de los puntos de vista de atributos es unir varias tablas para crear una tabla de dimensión única al utilizar esquemas de estrella. La vista dimensión de atributo resultante puede entonces ser unido a una tabla de hechos a través de una vista analítica (véase a continuación) para dar sentido a sus datos. Por ejemplo vistas de atributos se pueden utilizar para unir a los empleados a unidades organizativas que podría unir a una operación de venta a través de un punto de vista analítico.

Vistas analíticas

Vistas analíticas suelen definirse para tablas que en la que al menos una que contiene los datos transaccionales. Las vistas analíticas pueden crear una selección de medidas, añadir atributos y unir puntos de vista de los atributos. Puntos de vista analíticos aprovechan la potencia de computación de SAP HANA para calcular los datos agregados, e. g. el número de coches vendidos por país, o el consumo máximo de energía por día. Se definen en el vector al menos uno, i. e. una tabla que contiene e. g. una fila por cada coche vendido o una fila por lectura del medidor de potencia, o hablando más en general, alguna forma de registros de transacciones comerciales. Las tablas se pueden unir para permitir el acceso a datos más detallados utilizando una vista analítica única. Las vistas analíticas se pueden definir en una sola tabla o tablas combinadas.

Las vistas analíticas pueden contener dos tipos de atributos (o columnas), también llamados valor y  clave. Las cantidades o valores son atributos para los cuales deben definir una función de agregación. Si las vistas analíticas se utilizan en instrucciones SQL (ver más abajo), entonces las cantidades deben enviarse agregadas. O bien utilizando el SUM funciones SQL (<column <nombre), MIN (<column <nombre) o MAX (<column <nombre). Estos atributos normales puede ser manejados como columnas. Por ello no hay necesidad de que sean datos agregados.

En el modelo de vistas analíticas hacen uso del esquema en estrella, lo cual permite que se pueda tener acceso a las tablas de varias dimensiones. 

Las vistas analíticas se puede definir en una sola tabla o tablas combinadas (inner join).

Vistas analíticas pueden contener dos tipos de atributos (o columnas), las medidas de las llamadas y cifras clave. Las cantidades son atributos para los que la agregación se deben definir. Si las vistas analíticas se utilizan en instrucciones SQL (ver más abajo), entonces las medidas deben ser agregadas por ejemplo, utilizando la función SUMA SQL (<column <nombre), MIN (<column <nombre) o MAX (<column <nombre). Los atributos normales pueden ser manejados como columnas regulares. Para ellos no hay necesidad de crear agregados.

Vistas de cálculo

Las Vistas de cálculo se utilizan para proporcionar compuestos de otras vistas. Básicamente se basan en una combinación o unión de dos o más flujos de datos o invocar funciones genéricas de SQL.

Las vistas de cálculo se definen como cualquiera de las vistas gráficas, pero no con el  SQLScript (con excepciones, véase más adelante). Dependiendo de la forma en que se crean. Se pueden utilizar de la misma manera como vistas analíticas. Sin embargo, en contraste con vistas analíticas que es posible unir varias tablas, en una vista de cálculo siempre tienen al menos una medida.

Las vistas gráficas pueden ser modeladas utilizando las funciones de modelado gráfico del "Modeler SAP HANA". En las vistas se crean secuencias de comandos y secuencias de instrucciones SQL.

Como se mencionó antes vistas cálculo no se crean utilizando  SQLScript, sin embargo, existen excepciones a esta regla. El SQLScripts con las propiedades siguientes se pueden utilizar en las vistas de cálculo:

- No hay parámetros de entrada.
- Siempre de sólo lectura (no realizar cambios en la base de datos).
- Sin efectos secundarios.

2.3.3- SAP HANA Visión de los procesos.

Una explicación básica de que y como son los procesos en  SAP HANA es fundamental para asegurarnos de que la transferencia de datos en el sistema de base de datos se reduce al mínimo.
 
Una visión simplificada del sistema se ilustra en el diagrama a continuación.

Del diagrama se puede ver que SAP HANA tiene tres tipos de vistas que se utilizan según los requisitos del modelado.

- Vista de cálculo - se utiliza en la parte superior de una vista analítica y de las vistas de atributos para realizar cálculos complejos que no pueden ser alcanzados por el atributo o vistas analíticas sola.
  
- Vistas analíticas - se utiliza para el cálculo y agregación ", basada en esquema en estrella" o similar.

- Vistas Atributos a utilizarse para todo tipo de combinaciones.
 
El optimizador SQL elije la mejor forma de llamar a las diferentes funciones del sistema de base de datos basado en los modelos y las consultas involucradas.
 
Este diagrama está un tanto simplificado. Por ejemplo. A una vista analítica con un atributo calculado o que incluya atributos de vistas que contienen un atributo calculado, se convertirá en una vista de cálculo.


Esto debe ser tenido en cuenta durante el modelado, ya que puede tener un gran impacto sobre el rendimiento del modelo de datos. 
    

Guía para el modelado – Minimizando la transferencia de datos.

Como se ha subrayado muchas veces ya en este documento, uno de los objetivos principales durante el modelado es reducir al mínimo la transferencia de datos. Esto es válido tanto a nivel interno, como entre las vistas de bases de datos SAP HANA, y por lo tanto entre SAP HANA y la aplicación del usuario final. Por ejemplo, el usuario final no tendrá que ver a 1 millón de filas de datos. Nunca sería capaz de entender tanta información. Esto significa que los datos, siempre que sea posible, deberán agregarse y ser filtrados a un tamaño manejable antes de salir de la capa de datos.

Al decidir sobre los registros que deben ser presentado en un informe, un enfoque de mejores prácticas es pensar en  " el conjunto a un nivel determinado o no". Un conjunto de datos se puede agregar por una región, una fecha, o algún otro grupo con el fin de minimizar la cantidad de datos que se pasan entre las vistas.

Reglas básicas del modelado a seguir - un ejemplo

 
Para este ejemplo, el requisito es que las dos tablas estén unidas por sus claves. Esto lleva a la pregunta de cómo los datos deben ser tratados.

Como se mencionó antes, siempre se habla en terminos de conjuntos de datos, no filas (o registros) de datos. La imagen de la izquierda muestra un diseño pobre, ya que se unirán a las claves de las tablas. Al hacerlo, se tiene que tocar cada registro individual durante la consulta. Esto es costoso en tiempos de ejecución debido a la utilización de uniones de los datos en la vista de cálculo.

En el caso de que ambos puntos de vistas sean analíticos generará una gran cantidad de registros, este "Join" debe ser evitado y reemplazado por otra unión . Un "Join" puede ser utilizado cuando uno de los puntos de vista analítico tienen un pequeño número de registros (menos de un millón) en una vista de cálculo.

Antes de la operación, que transfiere los datos desde el punto de vista analítico a la vista de cálculo, los datos deben ser minimizados. El número de registros generados por una vista analítica se puede reducir por adición y mediante la aplicación de criterios de filtro. Estas observaciones pueden ser utilizados durante la creación de puntos de vista de cálculo para evitar problemas de actuaciones.

La imagen de la derecha muestra una manera más eficiente de la construcción de la vista. Tenga en cuenta que las dos vistas analíticas separadas inicialmente son agrupados por región y luego se juntan a través de una union. Esto es más eficiente que los "joins" a nivel de fila.
 

Utilice en el procesamiento masivo de datos como se mencionó en la sección anterior, utilizando un "enfoque conjunto" y no un "enfoque en filas" para el procesamiento de datos y siempre dará mejor rendimiento.

El código siguiente es un ejemplo de una consulta pobre:

 

La consulta siguiente es un ejemplo de una forma más eficaz de obtener los mismos datos. Es mucho más eficaz si está consultando en contra de conjunto de datos, en lugar de todos los datos.

Es muy importante evitar bucles al modelar ya que esto causará un rendimiento muy pobre. Esto es especialmente cierto cuando la cantidad de datos en la tabla que va a ser recorrida es muy grande (cientos de millones de entradas de datos).