Unified Dimensional Model

Un usuario que desee recuperar información directamente de un origen de datos, como una base de datos de ERP (Planeamiento de recursos de empresa), se enfrenta a varios retos importantes:

• Con frecuencia, resulta difícil comprender el contenido de estos orígenes de datos, ya que están diseñados desde la perspectiva de los sistemas y los programadores, en lugar de los usuarios finales.
• La información interesante para el usuario se distribuye generalmente en varios orígenes de datos heterogéneos. Aunque sólo se manejen distintas bases de datos relacionales, el usuario debe comprender los detalles de cada una, como el dialecto de SQL que se utiliza. Además, los orígenes de datos pueden ser de tipos muy distintos, ya que no sólo incluyen bases de datos relacionales, sino también archivos y servicios Web.
• Mientras que muchos orígenes de datos están concebidos para contener una gran cantidad de detalles de los niveles de transacción, con frecuencia las consultas que admiten la toma de decisiones corporativas precisan información agregada y de resumen. Al aumentar el volumen de datos, el tiempo necesario para recuperar los valores de resumen para un análisis de un usuario final interactivo puede ser prohibitivo.
• Por lo general, las reglas de negocios no están encapsuladas en los orígenes de datos. Los usuarios deben realizar su propia interpretación de los datos.

La función de un modelo UDM (Unified Dimensional Model) es aproximar los orígenes de datos al usuario. Un UDM se genera a partir de uno o varios orígenes de datos físicos. El usuario emite consultas en el UDM mediante diversas herramientas de cliente, como Microsoft Excel.

Existen ventajas para el usuario final aun cuando el modelo UDM sólo se genere como una fina capa sobre el origen de datos: un modelo de datos más sencillo y más fácil de comprender, el aislamiento de orígenes de datos de servidor heterogéneos y un rendimiento mejorado para las consultas de tipo de resumen. En algunos escenarios, un modelo UDM simple se puede generar automáticamente. Una mayor inversión en la generación del modelo UDM puede generar ventajas adicionales por la gran cantidad de metadatos que puede proporcionar el modelo.

El modelo UDM proporciona las siguientes ventajas:

• Mejora notablemente el modelo del usuario.
• Proporciona consultas de alto rendimiento que admiten un análisis interactivo, incluso con grandes volúmenes de datos.
• Captura las reglas de negocio del modelo para proporcionar un análisis mejorado.
• Admite "cerrar el ciclo", lo que permite que los usuarios actúen según los datos que ven.

Modelo básico del usuario final

Imagine un ejemplo en el que un usuario desee comparar las ventas con las cuotas de distintos períodos.

Los datos de ventas se almacenan en la base de datos principal Sales and Inventory, que también contiene otras tablas. Incluso después de identificar las tablas relevantes, puede que el usuario observe que los datos de una entidad única, como Product, se reparten en distintas tablas. Dado que la integridad referencial se aplica en la lógica de la aplicación, no se definen relaciones entre las tablas. Las cuotas de venta se almacenan en la base de datos de otra aplicación. Ninguna base de datos captura las reglas de negocio, como el hecho de que al comparar las cuotas con las ventas reales, debe utilizarse la fecha de envío del pedido, en lugar de las otras fechas para pedidos (fecha de pedido, fecha de entrega, fecha programada, etc.).

Obtener acceso directo a los orígenes de datos

En primer lugar, imagine que el usuario obtuviese acceso directo a los orígenes de datos. En la siguiente ilustración se muestra un ejemplo de una consulta que se genera con una herramienta de ejemplo.

Hasta el momento, el usuario ha progresado considerablemente. Este progreso incluye:

• Buscar tablas de su interés entre una gran cantidad de tablas con nombres cifrados.
• Identificar las columnas que se deben utilizar para combinar las tablas.
• Seleccionar las columnas que contienen los detalles de interés, de muchas tablas con gran cantidad de detalles orientados al sistema. Por ejemplo, de las 11 columnas de las tablas que almacenan detalles sobre categorías de producto, sólo dos columnas con nombre son relevantes para el usuario.

A continuación, el usuario debe descubrir si se deben utilizar combinaciones "externas" o "internas" y cómo agrupar los detalles para obtener los agregados deseados.

Sin embargo, el usuario se enfrenta a tareas más difíciles. Por ejemplo, ¿cómo puede combinar datos procedentes de otro origen de datos? Aunque una de las bases de datos admitiese consultas distribuidas, la mayoría de los usuarios no podría generar la consulta necesaria y puede que las herramientas le sean de escasa utilidad para realizar esta tarea. El ejemplo de código muestra una forma de consultar datos externos.

SELECT Quotas.QuotaAmount, Quotas.EmployeeId, …
FROM OPENROWSET('SQLOLEDB','seattle1';
'Sales';'MyPass',
   'SELECT * FROM Forecasts.dbo.SalesQuota’ ) As Quotas

Cuando se utilizan otros orígenes de datos, como los servicios Web, el usuario se enfrenta a otro gran obstáculo para determinar cómo se realizan las llamadas remotas correctas y cómo se procesa el XML devuelto para combinarlo con los demás datos.

Por último, después de realizar este trabajo para una consulta, es necesario repetir gran parte del mismo para la siguiente consulta y todas las consultas correctas.

Obtener acceso a los orígenes de datos mediante un UDM

Por contraste, en el siguiente diagrama se muestra un ejemplo de cómo vería la generación de una consulta un usuario que obtiene acceso a un modelo UDM simple generado sobre estos orígenes de datos.

La interfaz de diseño que se muestra en este ejemplo está disponible en las herramientas de desarrollo incluidas en Microsoft SQL Server 2005. Con todo, se podría usar cualquier interfaz compatible con el modelo UDM, incluidas herramientas cliente como Office Excel u Office Web Components (OWC), o una de las muchas herramientas de análisis y creación de informes.

La vista de árbol de la izquierda presenta el contenido del modelo UDM. En este ejemplo, observe los siguientes aspectos:

• Sólo se muestran los elementos relevantes y orientados al usuario. No se muestran las columnas del sistema, como los identificadores de fila o la fecha de última modificación.
• Se utilizan nombres descriptivos, en lugar de las convenciones de nomenclatura orientadas al programador que se utilizan en la base de datos subyacente.

El modelo UDM también agrupa los atributos de cada entidad comercial en "dimensiones" independientes, como Product o Employee. El cliente puede consultar Product Color, Subcategory y Category en este ejemplo sin necesidad de realizar explícitamente combinaciones entre las diversas tablas implicadas.

Las columnas que representan valores de transacciones, o medidas, se presentan a continuación "medidas". Por ejemplo, los usuarios suelen estar interesados en agregar columnas como importe de ventas o cuota de venta. Este método de presentación de datos como "medidas" y "dimensiones" se denomina modelado dimensional.

En el lado derecho del diagrama se muestran los elementos incluidos en la consulta actual. En este caso, para solicitar el "importe de venta y cuota por categoría de producto", el usuario define la consulta con sólo arrastrar los tres elementos relevantes desde la vista de árbol hasta el lado derecho de la interfaz de diseño. El usuario no tiene que especificar los detalles necesarios para obtener acceso a los dos orígenes de datos distintos ni realizar las combinaciones correctas entre las distintas tablas.

El modelo define el uso del formato predeterminado más sencillo: por ejemplo, el uso de símbolos de moneda. También pueden definirse formatos más complejos, incluido el formato condicional, como mostrar un valor en rojo si se encuentra por debajo de determinado umbral.

El mismo modelo admite diversas consultas. Por ejemplo, los resultados se pueden desglosar por empleado con sólo arrastrar un atributo de la dimensión Employee.

Ampliar el modelo básico

En el ejemplo anterior se demuestra cómo incluso un modelo UDM simple puede simplificar significativamente la exploración básica de datos. Sin embargo, existen otros retos que tener en cuenta al proporcionar a los usuarios acceso a datos. Por ejemplo:

• Un modelo UDM que admite diversos tipos de consultas de distintos usuarios podría alcanzar un gran tamaño. ¿Cómo se puede asegurar que un usuario que trabaja en determinada tarea no se ve inundado de información irrelevante?
• ¿Cómo se solucionan los requisitos de los usuarios globales, que desean ver los informes en su lengua materna?
• ¿Cómo se simplifica la consulta de preguntas comunes sobre aspectos temporales? Por ejemplo, puede que un usuario desee mostrar ventas comparadas con el mismo período del año pasado.

En esta sección se proporcionan algunas respuestas a estas preguntas para mostrar cómo el modelo UDM admite la ampliación del modelo básico para habilitar una exploración de datos más avanzada.

Jerarquías

Aunque la consolidación de todos los atributos de una entidad en una dimensión simplifica en gran medida el modelo al usuario, existen relaciones entre los atributos que no puede expresar una lista simple. En el caso anterior, Category, SubCategory y SKU definen una de las jerarquías en las que pueden organizarse los productos. El modelo UDM permite definir estas jerarquías porque los usuarios a menudo desean realizar análisis en función de ellas. Por ejemplo, después de ver los totales por Category, el usuario podría obtener más detalles en SubCategory y, desde ahí, más detalles en el nivel SKU inferior. Cada jerarquía es una secuencia de atributos que puede utilizarse para simplificar los escenarios de aumento o reducción de detalles en las consultas.

El siguiente diagrama es un ejemplo de cómo podrían aparecer jerarquías en una interfaz que se muestra al usuario final. El modelo contiene varias jerarquías diferentes en las que se pueden organizar los productos. La consulta que se muestra responde a esta pregunta: “mostrar ventas y cuotas por categoría de producto y desglosar en subcategorías”. Para definir la consulta, se arrastró la jerarquía “Products By Category” hasta la cuadrícula. Para ver los datos detallados, el usuario hace doble clic en la categoría “Bike” para expandir las subcategorías.

El modelo UDM controla los detalles sobre cómo moverse por los niveles de una jerarquía. También controla detalles, como el hecho de que Quotas no está disponible en el nivel SubCategory, sólo en el nivel Category.

Un tipo especial de jerarquía es la jerarquía de elementos primarios y secundarios, que contiene entidades que mantienen una relación intrincada entre sí. En la siguiente ilustración, la dimensión Employee posee una jerarquía denominada "Employees By Organization Structure". El uso de esta jerarquía simplifica el desplazamiento por la relación de elementos primarios y secundarios, y el análisis de valores resumidos en cada nivel de la organización. Por ejemplo, la cuota del vicepresidente de ventas, Charles Marshall, incluye la suma de las cuotas de venta de todos los empleados, además de las cuotas de venta asociadas directamente a él.

Categorización

Los usuarios aplican de forma natural categorizaciones a los datos. Por ejemplo, un usuario podría decir "estos atributos son datos personales de los empleados" o "este atributo es una dirección de correo electrónico". El modelo UDM proporciona dos mecanismos destinados específicamente a ofrecer un valor adicional con estas categorizaciones:

• Las dimensiones, los atributos y demás objetos pueden colocarse en categorías semánticamente significativas, lo que permite utilizar el objeto de manera más inteligente en una herramienta de cliente. Por ejemplo, puede marcarse un atributo como dirección URL. El informe que contiene este atributo podría luego permitir la exploración con los valores de la dirección URL. Se puede marcar otro atributo como dirección de correo electrónico. En este caso, un cliente de informes podría abrir automáticamente un nuevo mensaje de correo electrónico tras alguna acción del usuario.
• Las medidas, las jerarquías y demás objetos se pueden agrupar en carpetas que tengan sentido para el usuario. Esta agrupación permite que la herramienta de informes muestre grandes cantidades de atributos de manera manejable. Por ejemplo, puede crearse un grupo de atributos denominado "Customer Demographics".

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 las cuotas de venta para el año fiscal 2001. 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.

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 muestra 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 conecte 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 francés, el modelo y los resultados de las consultas aparecerían en francés, como se muestra en la ilustración.

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 usuario 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 mal.

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").

El uso de los KPI permite que las herramientas cliente presenten medidas relacionadas de forma que el usuario las entienda inmediatamente. En la siguiente ilustración se muestra un ejemplo de cómo una herramienta cliente puede mostrar tres KPI organizados en carpetas para mostrar.

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 precalculados 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 Hincame 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 puede invocarse luego en MDX para su uso en cálculos.

El cliente queda aislado de los detalles de estos cálculos. En las aplicaciones cliente, sólo parece que el modelo dispone de medidas más útiles. 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.

Integración con minería de datos

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.

Hacer que los datos se puedan procesar

Al ver datos con frecuencia, un usuario se plantea inmediatamente otras preguntas o la necesidad de realizar alguna acción. Por ejemplo:

• "¿Cuáles son las ventas detalladas que contribuyen a esa cifra?"
• "La cuota es muy baja, necesito aumentarla".
• "Parece extraño, voy a marcar el número con un comentario"
• "¿Qué detalles de la promoción tenemos en el sitio Web?"

No es suficiente presentar los datos a los usuarios de una forma fácil de comprender. También es necesario facilitarles la realización de una acción según los datos que vean.

El modelo UDM admite esta característica de dos formas:

• Permite que se vuelvan a escribir cambios en los datos.
• Habilita la asociación de acciones a los datos.

Reescritura

El modelo UDM no es de sólo lectura. En el modelo UDM también pueden actualizarse los datos. En el caso de medidas, las actualizaciones pueden almacenarse de forma independiente de los valores originales, como diferencias de esos valores.

Además, también es posible actualizar los números de resumen. Por ejemplo, considere un escenario de Budgeting. El importe presupuestado se puede llegar a conocer hasta un nivel detallado (por equipo y cuenta), pero inicialmente los valores sólo se conocen en un nivel más resumido (por departamento y tipo de cuenta).

Acciones

El modelo UDM admite acciones como un vínculo entre los datos y una acción realizada basada en los datos. Los principales tipos de acciones son:

• Dirección URL: Ir a una dirección URL específica. Este tipo de acción admite que se dirija al usuario a una dirección URL para que obtenga información adicional o a una aplicación basada en Web que le permita realizar una nueva tarea. Por ejemplo:
  • Para un producto, ir al sitio Web de la compañía en donde se describe el producto.
  • Para una combinación de producto y almacén, ir a la aplicación de administración de inventarios basada en Web y convertir el producto y el almacén en parámetros para permitir aumentar el nivel de inventario de seguridad.
• Informes: Ejecutar un informe específico. Por ejemplo, para un producto dado, la acción puede ejecutar un informe con parámetros del producto que proporcione la descripción del producto y el estado de pedido actual.
• Obtención de detalles: Obtener los detalles del nivel inferior de detalle disponible. Por ejemplo, un usuario que observa las ventas totales por producto y cliente puede obtener los detalles para ver las transacciones de venta que contribuyen al total.

Las acciones pueden asociarse con regiones específicas de datos. Por ejemplo, podría aplicarse una acción para explorar una página Web para cada producto, pero la acción para ver las transacciones de transferencia de inventario detalladas se aplicaría a cada valor de Quantity por producto y almacén.

Aunque las acciones se definan como parte del modelo UDM, es responsabilidad de la aplicación cliente recuperar los detalles de las acciones aplicables, ofrecerlas al usuario e iniciar la acción necesaria.

Seguridad

Puede controlarse el acceso al modelo UDM. Las principales características de seguridad son las siguientes:

• El modelo UDM proporciona una seguridad basada en funciones. Se pueden definir funciones, conceder permisos a las funciones e incluir usuarios como miembros de cada función. Los permisos actuales de un usuario son el conjunto de los permisos concedidos a las funciones a las que pertenece el usuario. Los permisos de una función pueden incluir "denegaciones seguras", que quitan derechos con independencia de otras funciones a las que pueda pertenecer el usuario.
• Los permisos administrativos (por ejemplo, para cambiar un modelo UDM) pueden concederse con independencia de los permisos de acceso. Además, se pueden definir permisos independientes para la lectura de metadatos del objeto y para el acceso de lectura y escritura a los datos.
• Pueden protegerse los datos en niveles de granularidad hasta las celdas individuales. Por ejemplo, se puede limitar la posibilidad de que los usuarios vean las ventas del producto "Widget" al cliente "ACME". La seguridad también puede ser condicional; por ejemplo, puede permitirse que una función vea el salario total de un departamento sólo si éste cuenta con más de cinco empleados.
• Los permisos pueden definir si deben usarse los totales visuales, en cuyo caso los totales sólo reflejan los miembros de nivel inferior en los que tiene permisos el usuario. El acceso a celdas también puede ser contingente, lo que significa que sólo se pueden ver las celdas derivadas de otras celdas si también se pueden ver las demás celdas. Por ejemplo, si los beneficios se derivan de ingresos y gastos, los usuarios sólo pueden ver los beneficios de los productos para los que tienen permisos para ver tanto los ingresos como los gastos.

Vea también

Otros recursos

Conceptos de Analysis Services

Ayuda e información

Obtener ayuda sobre SQL Server 2005