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.

About justindeveloper

I am MCP (Microsoft Certified Professional). MCTS (Microsoft Certified Technology Specialist) and MCPD (Microsoft Certified Professional Developer), also I am SAP Business One Certified!! Desarrollando desde el IDE de Visual Studio NET 2003 hasta ahora con el Visual Studio NET 2010. Desde Microsoft SQL Server 2000 hasta ahora con el Microsoft SQL Server 2008 R2 y tambien con SharePoint, desde WSS 3.0 y MOSS 2007 y ahora familirizandome con el Sharepoint Foundation 2010 & Sharepoint Server 2010. The software development will follow being every time more wonderful!
This entry was posted in Business Intelligence. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s