TOPICOS AVANZADOS DE BASES DE DATOS Unidad 3 3.2 Procesamiento y análisis en linea Olap OLAP es el acrónimo en inglés de procesamiento analítico en línea (On-Line Analytical Processing). Es una solución utilizada en el campo de la llamada Inteligencia empresarial (o Business Intelligence) cuyo objetivo es agilizar la consulta de grandes cantidades de datos. Para ello utiliza estructuras multidimensionales (o Cubos OLAP) que contienen datos resumidos de grandes Bases de datos o Sistemas Transaccionales (OLTP). Se usa en informes de negocios de ventas, marketing, informes de dirección, minería de datos y áreas similares. La razón de usar OLAP para las consultas es la velocidad de respuesta. Una base de datos relacional almacena entidades en tablas discretas si han sido normalizadas. Esta estructura es buena en un sistema OLTP pero para las complejas consultas multitabla es relativamente lenta. Un modelo mejor para búsquedas (aunque peor desde el punto de vista operativo) es una base de datos multidimensional. La principal característica que potencia a OLAP, es que es lo más rápido a la hora de ejecutar sentencias SQL de tipo SELECT, en contraposición con OLTP que es la mejor opción para operaciones de tipo INSERT, UPDATE Y DELETE. 3.2.1 Definiciones y conceptos Olap Definiciones Y Conceptos Olap El procesamiento analítico en línea (OLAP) le permite obtener acceso a datos organizados y agregados de orígenes de datos empresariales, como por ejemplo almacenamientos de datos, en una estructura multidimensional denominada cubo. Microsoft SQL Server 2005 Analysis Services (SSAS) proporciona herramientas y características para OLAP que puede utilizar para diseñar, implementar y mantener cubos y otros objetos compatibles. Antes de empezar a integrar cubos y otras funciones OLAP en las soluciones de Business Intelligence, asegúrese de que conoce los conceptos y decisiones siguientes. 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.Quota Amount?, Quotas.Employee Id?, FROM OPENROWSET( SQLOLEDB, seattle1 ; Sales ; My Pass?, SELECT * FROM Forecasts.dbo.Sales Quota? ) As Quotas Cuando se utilizan otros orígenes de datos, como los servicios Web, el usuario se enfrentan 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, Sub Category? 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 Sub Category 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 Sub Category, 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 Date Time? o Date. Aunque los usuarios con conocimientos de SQL o X Path 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) ISO 8601? 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 Employee ID? 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 Employee ID único) como un nombre (por ejemplo, una concatenación de First Name? y Last Name?). 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 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 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.
3.2.2 Requerimientos Funcionales Sistemas Olap El Online Anlytical Processing (OLAP) requiere la ejecución de operaciones costosas, como por ejemplo joins y aggregations. Esta situación se hace más compleja por el hecho de que las consultas OLAP deben realizarse sobre estructuras que tienen potencialmente millones de registros y porque los resultados tienen que ser entregados interactivamente al analista de negocios que opera el sistema. Dadas estas características, el énfasis en el ambiente OLAP está en el procesamiento eficiente de consultas. En términos técnicos, el sistema OLAP es una proyección multidimensional redundante de una relación. Computa todos los group by (tomando operadores SQL como ejemplo) y realiza una agregación de sus resultados en un espacio N-dimensional para responder consultas OLAP. Estas agregaciones son entonces almacenadas en tablas de sumarizacion derivadas o arreglos multidimensionales. Dado que estas agregaciones generalmente son muy grandes y que las consultas son a menudo complejas se hace necesario acelerar los tiempos de respuesta de las consultas usando mejores modelos, estructuras de datos, índices y métodos de compresión. Dado que los sistemas OLAP manejan enormes volúmenes de información se hace necesario contar con estructuras de índices eficientes, que consuman poco espacio y que su creación y mantenimiento consuman pocos recursos.