Business Intelligence

Nuevo Hyperion ya disponible

Desde la compra de Hyperion por parte de Oracle, se ha venido sucediendo una auténtica revolución en el campo del Business Intelligence, en donde parecía que lo más importante eran los movimientos empresariales y el ajuste de licencias, precios, plantillas, cargos, etc….

Pero poco a poco, van apareciendo nuevas versiones de cada uno de los productos. El mas reciente es Hyperion:

Hyperion Essbase

Se acaba de presentar la nueva version de Oracle EPM System 11.1 (antiguo Hyperion Systems 9.5), y ya esta disponible para descargar.

Esta versión es inicialmente sólo para Windows y tiene mejoras en el IDE de Essbase con Essbase Studio. Ahora la cuestión es como unimos esto con el antiguo OLAP de Oracle (Express Server, ahora AW) y con la version Enterprise basada en los componentes de Siebel. Un puzzle, todavía dificil de encajar.

Ahora bien… la pregunta es: Cómo se integrará Hyperion Essbase con Oracle Business Intelligence Enterprise Edition (OBIEE)?

Una de las preguntas que mas se hacen los clientes actuales de Hyperion es como se integrarán sus soluciones en el nuevo OBIEE. Si funcíonará correctamente, si habrá que hacer algún tipo de migración, etc…
La respuesta parece ser que habrá dos formas de posible integración:

– Essbase será una fuente mas para OBIEE, permitiendo combinar análisis MOLAP y ROLAP.
– Y al revés, sobre todo para los cubos financieros, que OBIEE sea una fuente para Essbase y de ahí se carguen lso datos.

Muy abiertas las posibilidades como veis, lo que puede inducir a ciertas dudas sobre su concrección o mejor opción para abordar la integración.
Se trata de encontrarle un hueco a la potente tecnología y base instalada de Essbase (planning), y el lanzamiento de la nueva aplicación de desarrollo y la posibilidad de hacer ‘drill to detail’ van en la buena linea.

En cualquier caso, un tema esta claro. En BI, con la variedad de tecnologías y aplicaciones existentes es muy dificil esperar una integración completa y habrá que analizar herramienta a herramienta que es lo mas conveniente para cada cliente.
Por nuestra parte (que seguimos añorando el viejo MOLAP Express Server, ahora AW… lo seguimos viendo como perdedor en este proceso de integración), pero puede ser una buena oportunidad para conocer el peso que tendrán las antiguas Siebel e Hyperion en la nueva linea BI de Oracle.

Business Intelligence

SQL Server Integration Services (SSIS) 10 Quick Best Practices

1.      La característica más deseada en el desarrollo de paquetes SSIS es la reusabilidad. En otros aspectos, podemos llamarles como los paquetes estándar que pueden ser reutilizados durante el desarrollo de diferentes componentes ETL. En SSIS, esto puede fácilmente lograrse mediante características de template. SSIS template packages son paquetes reutilizables que se pueden usar en cualquier proyecto SSIS en cualquier número de veces.

Nota: Por default  son almacenados en:

Drive:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\ProjectItems\DataTransformationProject\DataTransformationItems

2.      Evite utilizar el punto (.) en la Convención de nomenclatura para sus nombres de paquete. El Punto (.) en la  Convención de la nomenclatura  a veces se confunde con el Convenio de  nombres de objeto de SQL Server y por lo tanto debe evitarse. Buen enfoque sería utilizar subrayado (_) en lugar de utilizar el punto. También asegúrese de que los nombres de paquete no debe exceder  más de 100 caracteres. Durante la implementación del paquete en SQL Server, es notificado que  cualquier carácter más de 100 es eliminado automáticamente del nombre del paquete. Esto podría resultar que el paquete SSIS falle durante el tiempo de ejecución, especialmente cuando se utiliza “Execute Package Tasks” en el paquete.

3.      El flujo de datos desde upstream a downstream en un paquete es una tarea intensiva de memoria, en la mayoría de los pasos y nivel de componente tenemos que  comprobar cuidadosamente y estar seguros de que las columnas innecesarias no sean pasadas al downstream. Esto ayuda a evitar la sobrecarga de tiempo de ejecución adicional del paquete y a su vez mejora el rendimiento general de la ejecución del paquete.

4.      Al configurar cualquier administrador de conexión OLEDB como una fuente de datos, evitar el uso de  tabla o vista como modo de acceso de datos, esto es similar a “SELECT * FROM <TABLE_NAME>”, y como la mayoría de nosotros sabe, SELECT * es nuestro enemigo, esto toma todas las columnas en cuenta, incluidos aquellos que no son incluso necesarios. Siempre intentar usar  SQL Command para el modo de acceso a datos e incluir solamente nombres de las columnas necesarias en su sentencia T-SQL SELECT. De esta manera puede bloquear el paso de columnas innecesarias al downstream.

5.      En sus tareas de flujo de datos, utilice el administrador de conexión de archivos planos cuidadosamente, crear el Flat File connection manager con configuración predeterminada utilizará tipo de datos String [DT_STR] por defecto para todos los valores de columna. Esto siempre podría no ser una opción correcta porque puede tener algunas columnas de origen de tipo numérico, entero o booleanas, pasarlos como String a downstream tomaría espacio en memoria innecesaria y puede causar algún error en las etapas posteriores de la ejecución del paquete.

6.      La ordenación de datos es una operación de mucho tiempo, en SSIS puedes ordenar los datos procedentes de upstream utilizando Sort transformation, sin embargo se trata de una tarea intensiva de memoria y en varias ocasiones el resultado es degradante en el rendimiento general de la ejecución del paquete. Una buena práctica, sabemos que los datos vienen en la mayoría de las tablas de base de datos de SQL Server, es mejor realizar la operación de ordenación a nivel de base de datos donde se puede realizar la ordenación dentro de la consulta. Esto es en efecto bueno, porque el ordenamiento en la base de datos de SQL Server es mucho más refinado y ocurre a nivel de SQL Server. A su vez el resultado general mejora el rendimiento en la ejecución del paquete.

7.      Durante el desarrollo de paquetes SSIS, la mayor parte del tiempo uno tiene que compartir su paquete con otros miembros del equipo o uno tiene que implementar el mismo paquete en cualquier otro sistema de desarrollo, UAT o producción. Algo que un desarrollador debe asegurarse es de utilizar el nivel de protección del paquete correcto. Si alguien va con el nivel de protección del paquete predeterminado EncryptSenstiveWithUserKey entonces el mismo paquete podría no ser ejecutado como se esperaba en otros entornos porque  el paquete fue cifrado con una clave personal de usuario. Para hacer que la ejecución del paquete sea suave a través de otros entornos, uno debe primero comprender el comportamiento de propiedad de nivel de protección del paquete.

                DTSProtectionLevel Enumeration

                Namespace: Microsoft.SqlServer.Dts.Runtime
                Assembly: Microsoft.SqlServer.ManagedDTS (in microsoft.sqlserver.manageddts.dll)

                DontSaveSensitive: La Información sensible no es guardada en el paquete

                EncryptAllWithPassword: Cifra el paquete entero utilizando una contraseña

                EncryptAllWithUserKey: Cifra el paquete entero utilizando claves basados en el perfil del usuario. Sólo el mismo usuario utilizando el mismo perfil puede cargar el paquete.

                EncryptSensitiveWithPassword: Cifra sólo la información sensible que contiene en el paquete con una contraseña. DPAPI se utiliza para este cifrado

                EncryptSensitiveWithUserKey: Cifra todo el paquete con claves basados en el usuario actual.  Sólo el mismo usuario utilizando el mismo perfil puede cargar el paquete. Si un usuario diferente abre el paquete, la información confidencial se sustituye por los espacios en blanco. DPAPI se utiliza para este cifrado.

                ServerStorage: Cifra el paquete en una base de datos de MSDB de SQL Server. Esta opción es compatible sólo cuando un paquete se guarda en SQL Server. No es compatible cuando se guarda un paquete al sistema de archivos. El control de acceso de que quien puede descifrar el    paquete está controlado por los roles de base de datos SQL Server.

                En general, para evitar el error de implementación del paquete de un sistema a otro sistema, establezca nivel de protección de paquete en DontSaveSenstive.

8.      Esto es una buena práctica,  Utilizar Sequence Containers en paquetes SSIS para agrupar los distintos componentes en el nivel de Control Flow. Esto ofrece un conjunto rico de Facilidades

          Proporciona un alcance para las variables que puede utilizar un grupo de tareas relacionadas y contenedores

          Proporciona la facilidad para administrar propiedades de múltiples tareas estableciendo la propiedad a nivel de Sequence container

          Proporcionar facilidad para establecer el nivel de aislamiento de transacción en nivel de Sequence container

9.      Si diseña una solución ETL para una necesidad de negocio para una empresa pequeña, mediana o grande, siempre es bueno tener una característica de reinicio de los paquetes con errores desde el punto del error. SSIS tiene una característica llamada Checkpoint para soportar el reinicio de paquetes con errores desde el punto del error. Sin embargo, tiene que configurar la característica de Checkpoint a nivel del package.

                Las siguientes propiedades de paquete se debe establece para implementar el punto de control  (Checkpoint)

          CheckpointFileName: Especifica el nombre del archivo de punto de control

          CheckpointUsage: Especifica si se utilizan los puntos de control.

          SaveCheckpoints: Indica si el paquete guarda los puntos de control. Esta propiedad debe establecerse en True para reiniciar un paquete desde un punto de error.

10.  Execute SQL Task es nuestro mejor amigo en SSIS; podemos ejecutar uno o múltiples instrucciones de SQL a la vez, todos los stored procedures que contenga nuestra DB, volver a crear nuestras tablas de hecho y de dimensiones antes de cargar datos en ellos . La belleza de este componente es que puede devolver resultados en diferentes maneras por ejemplo, una fila individual, conjunto de resultados y XML. Puede crear diferente tipo de conexión utilizando este componente como OLEDB, ODBC, ADO, ADO.NET y el tipo de SQL Mobile, etc.. Yo prefiero usar este componente la mayor parte del tiempo con mi ForEach Loop container para definir el bucle de iteración sobre la base de resultado retornado por el Execute SQL Task.

Jonnathan De La Barra Sonrisa

Business Intelligence

Analysis Services (SSAS 2005) Parte II

Tiempo

La información temporal se registra generalmente en el origen de datos subyacente con los tipos de datos DateTime o Date. Aunque los usuarios con conocimientos de SQL o XPath pueden extraer la información de fecha necesaria para los datos totales por año, les resultaría difícil plantear una consulta con preguntas en función de otros aspectos temporales, como "Mostrar las ventas por día de la semana" o "Desglosar por año fiscal, comenzando el 1 de julio".

Sin embargo, el modelo UDM posee un conocimiento integrado del tiempo, que incluye los siguientes calendarios:

ü  Natural

ü  Fiscal

ü  De informes ("445", etc.)

ü  De fabricación (13 períodos)

ü  ISO8601

Por lo tanto, el modelo puede incluir una dimensión de tiempo que proporcione un amplio conjunto de atributos que definan detalles de cada día.

En la siguiente ilustración se muestran los resultados cuando el usuario opta por ver el importe y la cantidad de órdenes de venta para el año fiscal 2002. Para ello, sólo tiene que arrastrar el elemento relevante del árbol hasta el área de filtro. El modelo UDM sabe cómo traducir esa acción del usuario en un intervalo de fechas y además comprende la regla de negocio que indica que deben incluirse en la consulta los pedidos enviados en estas fechas, no los programados ni los hechos. El modelo UDM realiza implícitamente la combinación correcta.

SSAS_04

Además, el modelo UDM proporciona soporte específico para responder preguntas comunes relativas al tiempo, incluidas las comparaciones entre períodos, como "comparar este mes con el mismo mes del año pasado".

Traducciones

En los ejemplos anteriores, el contenido del modelo y los datos se muestran en un solo idioma. Sin embargo, los usuarios internacionales tienen que ver a menudo los metadatos en su propio idioma.

Para solucionarlo, el modelo UDM ofrece la traducción de metadatos en todos los idiomas. Una aplicación cliente que se conecta mediante una configuración regional específica recibiría los metadatos en el idioma correspondiente.

El modelo también puede proporcionar traducciones de datos. Un atributo puede asignarse a diferentes elementos en el origen de datos y ofrecer las traducciones de estos elementos en distintos idiomas. Por ejemplo, si el usuario se conecta mediante la misma herramienta utilizada en los ejemplos anteriores, pero desde un equipo con configuración regional en español, el modelo y los resultados de las consultas aparecerían en español, como se muestra en la ilustración.

 SSAS_05

Perspectivas

Aunque el modelo utilizado en este ejemplo es de tamaño reducido, los modelos reales pueden tener un ámbito más amplio, con decenas de medidas y dimensiones, y cada dimensión con decenas o cientos de atributos. Por lo general, los usuarios asignados a una tarea específica no necesitan ver el modelo completo. Para no abrumar a los usuarios con el tamaño total del modelo, es preciso poder definir una vista que muestre un subconjunto del modelo.

El modelo UDM proporciona estas vistas, denominadas perspectivas. El modelo UDM puede presentar varias perspectivas, cada una de las cuáles sólo presenta determinado subconjunto del modelo (medidas, dimensiones, atributos, etc.) relevante para un grupo de usuarios concreto.

Cada perspectiva puede asociarse a las funciones de seguridad del rol que definen los usuarios a los que se permite ver dicha perspectiva.

Por ejemplo, puede definirse una perspectiva denominada "Seattle Inventory" que sólo incluya medidas del grupo de medida Inventory, oculte la jerarquía "Warehouse By Location" y establezca como ciudad predeterminada "Seattle".

Semántica de atributos

Un modelo UDM proporciona una semántica adicional para los atributos. Esta semántica tiene por objeto simplificar el uso de la información. Estos son algunos ejemplos de semántica que se pueden aplicar a los atributos:

ü  Nombres en lugar de claves: Si se observa la base de datos relacional, quizá no resulte evidente que EmployeeID es una clave única y sin significado generada por el sistema. Para resolver este problema, el modelo UDM permite que el atributo Employee tenga tanto una clave (el EmployeeID único) como un nombre (por ejemplo, una concatenación de FirstName y LastName). De este modo, una consulta del tipo "mostrar los empleados" distinguirá correctamente los empleados de igual nombre, mediante sus Id. únicos, y mostrará al usuario el nombre significativo.

 

ü  Ordenación: Los valores de atributos a menudo deben mostrarse con un orden fijo que no es un simple orden numérico o alfabético. El modelo UDM permite definir una ordenación predeterminada para administrar este requisito. Por ejemplo:

      • Los días de la semana se muestran como Domingo, Lunes, Martes, etc.
      • Las prioridades se muestran en el orden Alta, Media y Baja.

ü  Discretización: En los atributos numéricos, a veces no resulta útil mostrar los distintos valores del atributo. Por ejemplo, resulta menos útil ver las ventas para los distintos precios de un producto (9,97$, 10,05$, 10,10$, etc.) que verlas por intervalo de precios (<10$, 10$ – 15$, etc.). El modelo UDM permite discretizar los atributos en estos intervalos mediante distintos criterios.

Indicadores clave de rendimiento (KPI)

Las empresas suelen definir indicadores clave de rendimiento (KPI), que son medidas importantes para evaluar el estado de las mismas. El modelo UDM permite crear estos indicadores KPI, para que las empresas puedan agrupar y presentar datos de una manera más comprensible. Un KPI puede también utilizar un gráfico para mostrar el estado de una tendencia, como un semáforo para indicar los valores bueno, normal o malo.

Cada KPI del modelo UDM define hasta cuatro expresiones para cada medida de rendimiento:

ü  Valor real

ü  Valor objetivo

ü  Estado   Valor normalizado comprendido entre -1 y 1 que representa el estado real frente al objetivo (-1 es "muy malo" y 1 es "muy bueno").

ü  Tendencia   Valor normalizado entre -1 y 1 que representa la tendencia a lo largo del tiempo (-1 es "empeora" y 1 es "mejora").

SSAS_06
 

Rendimiento

La exploración interactiva de los usuarios precisa tiempos de respuesta breves. Este requisito constituye un reto debido a la gran cantidad de conjuntos de datos en los que se suele realizar la exploración.

Para mejorar el rendimiento, el modelo UDM proporciona servicios de almacenamiento en caché. Las cachés pueden almacenar los datos detallados leídos del origen de datos subyacente y los valores de agregado pre calculados a partir de dichos datos. Sin embargo, el uso de estos valores almacenados en la caché puede implicar cierto nivel de obsolescencia de los datos. Los requisitos empresariales dictarán cómo debe utilizarse la información actual. Puede que en algunos casos sea fundamental mostrar los datos más recientes, mientras que en otros casos sería completamente aceptable mostrar datos con una antigüedad de dos horas o dos días.

Para reflejar estas directivas que establecen la preponderancia de los datos, el modelo UDM permite administrar explícitamente la caché (por ejemplo, puede definirse una programación que actualice la caché diariamente a las 2 a.m.) o administrarla de forma transparente mediante el almacenamiento en caché automático. El usuario puede especificar el grado de actualización que deben tener los datos y el modelo UDM proporcionará la creación y administración automática de la caché para obtener el tiempo de respuesta más breve posible.

Análisis

En las secciones anteriores se explicaba cómo el modelo UDM admite la exploración interactiva de datos. No obstante, simplemente hacer que la información de los orígenes de datos subyacentes esté disponible, aunque sea de una forma más fácil de comprender y utilizar, no cumple el objetivo de incorporar la lógica de negocios en el modelo de los usuarios. Por lo tanto, el modelo UDM ofrece la posibilidad de definir cálculos simples y complejos en los datos.

Análisis básico

Por lo general, las consultas devuelven datos agregados. Por ejemplo, una consulta típica muestra las ventas por categoría, en lugar de mostrar todos y cada uno de los pedidos de ventas. No obstante, no existe nada en los datos relacionales subyacentes que defina cómo se debe agregar una determinada medida. Por ejemplo, el importe de ventas puede sumarse, pero el precio unitario se debe promediar. El modelo UDM agrega esta semántica.

El método de agregación puede definirse mediante varios esquemas:

ü  Puede utilizarse una función de agregación simple, como Sum, Count, Distinct Count, Max o Min.

ü  La agregación se puede definir como de suma parcial. Esto significa que se utiliza una función simple, como Sum, para todas las dimensiones excepto Time, en la que se utiliza Last Period. Por ejemplo, aunque el nivel Inventory puede sumarse de Product a Product Category, el nivel de inventario del mes no es la suma de los niveles de inventario de cada día, sino el nivel de inventario del último día del mes.

ü  La agregación puede basarse en el tipo de cuenta, como Iincame en lugar de Expense.

ü  Puede personalizarse la agregación para cumplir los requisitos especiales.

Un modelo UDM también puede contener miembros calculados. Estos miembros no tienen una asociación directa con el origen de datos pero se derivan de estos datos. Por ejemplo, puede definirse un miembro calculado, como Variance, para calcular la diferencia entre Sales y Quota.

De forma similar, el modelo UDM puede definir conjuntos de entidades de interés para el usuario; por ejemplo, los 10 clientes principales (por volumen de ventas) o los productos más importantes. Estos conjuntos pueden utilizarse con facilidad para restringir el ámbito de una consulta a un conjunto específico de entidades.

Análisis avanzado

Algunas veces los cálculos que necesitan los usuarios son bastante más complejos que el ejemplo "Variance" anterior. Éstos son algunos ejemplos de cálculos complejos:

ü  Mostrar la media móvil de tres meses para cada período.

ü  Comparar el crecimiento interanual de este período con el mismo período del año pasado.

ü  Si las ventas se muestran en la moneda base, volver a convertir las ventas a la moneda original utilizando la tasa de cambio media diaria en el momento de la venta.

ü  Calcular las ventas presupuestadas por categoría para el próximo año como un aumento del 10% sobre este año y asignar un presupuesto para cada producto según las ventas medias relativas de los últimos tres años.

El modelo UDM constituye un modelo completo para definir estos cálculos y se parece a una hoja de cálculo multidimensional, en la que el valor de una celda puede calcularse a partir de los valores de otras celdas. Sin embargo, ni siquiera esta metáfora puede describir adecuadamente la gran variedad de cálculos del modelo UDM. Una celda puede calcular su valor no sólo según el valor que hay en otra celda, sino también según el valor que suele haber en dicha celda. Por lo tanto, se admiten ecuaciones simultáneas; por ejemplo, los beneficios se derivan de los ingresos menos los gastos, pero las bonificaciones, que se incluyen en los gastos, se derivan de los beneficios.

Además de proporcionar el eficaz lenguaje MDX (Expresiones multidimensionales), que se ha diseñado específicamente para crear estos cálculos, el modelo UDM también permite la integración con Microsoft .NET. Esta integración permite escribir funciones y procedimientos almacenados en cualquier lenguaje .NET comprobable, como C#.NET o Visual Basic .NET. La función o el procedimiento almacenado pueden invocarse luego en MDX para su uso en cálculos.

El cliente queda aislado de los detalles de estos cálculos. En el siguiente ejemplo, el usuario ve varias medidas calculadas en función de Sales para los productos más rentables vendidos en Estados Unidos.

SSAS_07

Integración con Data Mining

La posibilidad de mostrar los datos en un formato completo y comprensible resulta de gran utilidad, pero los usuarios necesitan además poder inferir nueva información a partir de esos datos.

El modelo UDM contiene la tecnología de minería de datos para permitir minar los datos y utilizar los patrones descubiertos para la predicción.