Planificar respuestas a los riesgos negativos de un proyecto

En la gestión de un proyecto, una vez que se han identificado los riesgos, clasificado y analizado, el siguiente paso debería ser planificar la respuesta de los riesgos que se van a controlar y gestionar.


En la gestión de un proyecto, una vez que se han identificado los riesgos, clasificado y analizado, el siguiente paso debería ser planificar la respuesta que daremos a los riesgos que se van a controlar y gestionar.

Como señalábamos en una entrada anterior, los riesgos de alta probabilidad y alto impacto, no deberían ser ignorados, en general, ningún riesgo debería ser rechazado, especialmente los que hubiesen obtenido, como resultado del uso de la matriz “Probabilidad vs. Impacto”, el resultado “Planificar Respuesta” requieren una atención especial para proponer un plan de acción si estos se produjesen.

El planteamiento de una respuesta debería seguir alguna de las siguientes estrategias:

  • Mitigar la probabilidad o impacto del riesgo. Reducir la probabilidad o el impacto, o ambos se justifican siempre cuando las acciones que se emprendan para este fin sean rentables con relación al impacto del riesgo.
  • Planificar una contingencia. La alta probabilidad de un riesgo justifica el planteamiento de un plan de contingencia, esto también incluye la identificación de condiciones de su activación (descripción del momento).
  • Transferir el riesgo a otra parte. Trasladar el riesgo no lo elimina, lo externaliza (por ejemplo la contratación de seguros o suscripción de garantías)
  • Evitar el riesgo. El beneficio de una tarea no justifica el costo que puede significar el impacto de un riesgo si este ocurriese, si fuese así se podría eliminar la actividad o sustituirla por otra.
  • Aceptar el riesgo.  El costo de cualquier respuesta es superior al coste del impacto del riesgo, la alternativa para este caso es aceptar que el riesgo puede ocurrir y gestionarlo de la mejor manera si este se concretara.

Referencia: ISBN 978-84-415-3225-0

Carga y descarga en memoria de tablas SAP HANA Database

Normalmente SAP HANA Database gestiona la carga y descarga de tablas en memoria de manera automática con el fin de tener los datos necesarios en memoria, pero sin embargo, es posible «forzar» la carga y descarga de tablas o columnas de tablas si fuese necesario.


Normalmente SAP HANA Database gestiona la carga y descarga de tablas en memoria de manera automática con el fin de tener los datos necesarios en memoria, pero sin embargo, es posible «forzar» la carga y descarga de tablas o columnas de tablas si fuese necesario.

Las tablas con almacenamiento basado en filas son cargadas en memoria desde que la base de datos es iniciada y permanecen en memoria durante todo su funcionamiento, no pueden ser descargadas.

Las tablas con almacenamiento basado en columnas se cargan bajo demanda, columna por columna en los primeros accesos (este comportamiento se conoce como Lazy Loading) de este modo, columnas que nunca se utilizan no son cargadas, haciéndose un uso más eficiente de la memoria. Este es el comportamiento por defecto (algoritmo “least recently used”), pero sin embargo en la definición de la tabla vía SAP HANA Studio se puede indicar que columnas se cargarán cuando la base de datos se ponga en funcionamiento. (También vía la consola SQL se puede utilizar las sentencias LOAD y UNLOAD para cargar y descarga tablas o determinadas columnas de una tabla)

Nota: Para cargar una tabla en memoria es necesario tener el privilegio UPDATE SQL sobre la tabla.

La «arquitectura» de las tablas basadas en columnas de SAP HANA

La denominada Column Store es un componente de toda la ingeniería que conforma la plataforma SAP HANA, gestiona en memoria las tablas con almacenamiento basado en columnas. La “Column Store” optimiza las operaciones de lectura y escritura, a través de dos estructuras de datos que tienen las tablas: «main storage» y «delta storage».


La denominada Column Store es un componente de toda la ingeniería que conforma la plataforma SAP HANA, gestiona en memoria las tablas con almacenamiento basado en columnas. La “Column Store” optimiza las operaciones de lectura y escritura, a través de dos estructuras de datos que tienen las tablas: «main storage» y «delta storage».

The In-Memory Computing Engine of SAP HANA

La denominada “main storage” contiene los datos comprimidos para llevarlos a memoria, esta área es utilizada para las tareas de búsqueda y cálculos sobre los datos.  En cuanto a las tareas de grabación, se realizan sobre otra estructura, denominada “delta storage”, la cual utiliza una compresión básica que optimiza las tareas de actualización de los datos.  Las tareas de lectura se realizan sobre ambas áreas de datos.

A través de operaciones denominadas “delta merge” los cambios realizados en la “delta storage” pasan a la denominada “main storage”, luego de estas operaciones, el contenido de la main storage permanece en disco y si fuese necesario la optimización y compresión es actualizada.

Main Strorage and Delta Storage of the column tables

La denominada “delta storage” sólo existe en memoria, como parte del procedimiento contra fallos, el sistema va actualizado un log (delta log) con las últimas modificaciones que se realicen en una tabla, el contenido de estos ficheros es utilizado si el sistema se reinicia y se debe restituir las últimas operaciones que no fueros grabadas en disco.  Al realizar las operaciones “delta merge” los datos pasan a disco y el fichero log correspondiente queda limpio de operaciones.

SAP HANA, una base de datos con servidor web y servidor de aplicaciones incluido

SAP HANA Extended Application Services (conocido como XS) Es un nuevo componente que se introduce en la versión 1.0 SPS 05 de SAP HANA, se trata de un servidor de aplicaciones y servidor Web que permite cambiar el enfoque tradicional para desarrollar aplicaciones Modelo – Vista – Controlador (MVC).


SAP HANA Extended Application Services (conocido como XS) Es un nuevo componente que se introduce en la versión 1.0 SPS 05 de SAP HANA, se trata de un servidor de aplicaciones y servidor Web que permite cambiar el enfoque tradicional para desarrollar aplicaciones Modelo – Vista – Controlador (MVC).

Arquitectura tradicional de desarrollo de aplicaciones Model-View-Controller (MVC)

Con XS, SAP HANA redefine el comportamiento tradicional de una base de datos, permitiendo el desarrollo y ejecución de aplicaciones nativas que aprovechan las características del procesamiento en memoria.  Adicionalmente, al incluir la función de Control en la base de datos, se elimina sobrecargas y se logra mayor eficiencia entre la capa de interface de usuario y el procesamiento de los datos.

Arquitectura de desarrollo de aplicaciones con SAP HANA Extended Application Services

SAP HANA XS ofrece un amplio conjunto de características para cumbrir las funciones de servidor de aplicaciones y servidor web, sin tener que recurrir a productos adicionales. 

Referencia: (aquí)

Almacenamiento en SAP HANA, ¿filas o columnas?

SAP HANA soporta el almacenamiento basado en columnas (column-based storage) y basado en filas (row-based storage), y funciona mejor con el almacenamiento basado en columnas, las tablas de este tipo tienen una lectura optimizada y mejores niveles de compresión. En el futuro, algunas características como el particionado sólo estarán disponibles en tablas column-based storage.


SAP HANA soporta el almacenamiento basado en columnas (column-based storage) y basado en filas (row-based storage), y funciona mejor con el almacenamiento basado en columnas, las tablas de este tipo tienen una lectura optimizada y mejores niveles de compresión.  En el futuro, algunas características como el particionado sólo estarán disponibles en tablas column-based storage.

Pero no siempre es recomendable utilizar tablas basadas en columnas, las cuales están pensadas, principalmente, para grandes volúmenes de datos con lecturas y modificaciones masivas, por otro lado, las tablas basadas en filas son más eficientes en tareas de inserción y actualización, principalmente para pequeños conjuntos de datos con modificaciones individuales.  A continuación mencionamos algunos aspectos que podrían determinar el uso de uno u otro tipo de almacenamiento:

Column Store:

  • Los cálculos serán ejecutados sobre una o pequeños grupos de columnas.
  • La tabla tendrá varias columnas.
  • Gran número de filas que serán procesadas constantemente a nivel de columnas.
  • Las columnas tienen poca variedad de valores y se logrará un alto nivel de compresión.
  • Búsquedas a nivel de los valores de algunas columnas.

Row Store:

  • Se necesita procesar un registro a la vez.
  • Se requiere acceder a todo el registro (todas las columnas de una fila)
  • Las columnas tienen una amplia variedad de datos y los niveles de compresión serían bajos.
  • No se requiere agregaciones, ni búsquedas rápidas
  • La tabla tendrá un número reducido de filas (por ejemplo tablas de configuración)

 Nota: Las tablas de diferente tipo de almacenamiento pueden vincularse, pero resulta más recomendable que siempre sean del mismo tipo. El tipo de almacenamiento asignado a una tabla en su definición puede modificarse vía la sentencia ALTER TABLE ALTER TYPE.