Modelado multidimensional
Anuncio
Elegir una experiencia de modelado tabular o multidimensional en SQL Server 2012 Analysis Services Artículo técnico de Microsoft Business Intelligence Autores Consultoría Hitachi: Liz Vitt: autor Scott Cameron: autor Hilary Feier: revisor Microsoft: T.K. Anand: revisor Ashvini Sharma: revisor Fecha de publicación: mayo de 2012 Corresponde a: SQL Server 2012 Analysis Services Resumen: en estas notas del producto se incluye una orientación práctica para ayudar a quienes toman decisiones y a los profesionales de BI a evaluar si lo que mejor se adecúa como su próxima solución de BI es el modelado multidimensional o el tabular de Analysis Services de SQL Server 2012. Copyright Este documento se proporciona "tal cual". La información y los puntos de vista que se ofrecen en él, incluidas las direcciones URL y otras referencias a sitios web de Internet, pueden sufrir modificaciones sin previo aviso. Usted acepta el riesgo de utilizarlo. En este documento no se proporciona ningún derecho legal de ninguna propiedad intelectual de ningún producto de Microsoft. Puede copiar y utilizar este documento para su propia referencia. © 2012 Microsoft Corporation. Todos los derechos reservados. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 2 Contenido Introducción .................................................................................................................................................. 5 Elementos del modelado BISM .............................................................................................................. 5 Modelado multidimensional ............................................................................................................... 5 Modelado tabular ................................................................................................................................... 6 Herramientas de análisis de cliente BISM ........................................................................................... 7 Modelo de datos.......................................................................................................................................... 7 Relaciones de datos ............................................................................................................................... 7 Relaciones de uno a varios.............................................................................................................. 7 Relaciones de varios a varios.......................................................................................................... 8 Relaciones de referencia .................................................................................................................. 8 Jerarquías ................................................................................................................................................... 9 Jerarquías estándar ............................................................................................................................ 9 Jerarquías desiguales ........................................................................................................................ 9 Jerarquías de elementos primarios y secundarios .................................................................. 9 Características de modelado adicionales .....................................................................................10 Lógica empresarial ....................................................................................................................................12 Transformaciones de fila ....................................................................................................................12 Valores agregados ................................................................................................................................13 Cálculos .....................................................................................................................................................13 Escenarios de lógica empresarial ....................................................................................................15 Lógica de jerarquía...........................................................................................................................15 Resúmenes personalizados ...........................................................................................................15 Medidas semiaditivas ......................................................................................................................16 Inteligencia de tiempo ....................................................................................................................17 KPI ..........................................................................................................................................................17 Conversión de moneda ..................................................................................................................17 Conjuntos con nombre ...................................................................................................................17 Acceso a datos y almacenamiento ......................................................................................................19 Rendimiento y escalabilidad .............................................................................................................19 Modelos multidimensionales .......................................................................................................19 Modelos tabulares............................................................................................................................20 Programación .........................................................................................................................................22 Seguridad .....................................................................................................................................................22 Seguridad de filas y atributos ...........................................................................................................23 Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 3 Seguridad dinámica..............................................................................................................................23 Seguridad de celda y avanzada .......................................................................................................23 Resumen .......................................................................................................................................................24 Para obtener más información .............................................................................................................29 Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 4 Introducción El modelado de datos es una disciplina que los profesionales de BI llevan varios años poniendo en práctica con un objetivo común: organizar la información dispar en un modelo analítico que satisfaga las necesidades de la empresa en cuanto a sus procesos de informes y análisis de un modo eficaz y, al mismo tiempo, eficiente. A medida que el modelado de datos evoluciona con el tiempo gracias a la aparición de nuevas tecnologías y herramientas, las organizaciones se enfrentan al desafío cada vez mayor de combinar sus paradigmas de modelado de un modo coherente y fluido que no solo satisfaga sus diversas necesidades de análisis sino que también permita una experiencia de análisis común dentro de la empresa. Con la versión SQL Server 2012, Microsoft aborda este objetivo y este desafío gracias a la incorporación del modelo semántico de BI (BISM), un modelo único que es capaz de admitir una amplia variedad de informes y análisis al tiempo que combina de fondo dos experiencias de modelado de Analysis Services: El modelado multidimensional, que se incluyó por primera vez en SQL Server 7.0 OLAP Services y siguió proporcionándose en SQL Server 2012 Analysis Services, permite a los profesionales de BI crear cubos multidimensionales sofisticados utilizando el procesamiento analítico en línea (OLAP) tradicional. El modelado tabular, que se proporcionó inicialmente en PowerPivot para Microsoft Excel 2010, proporciona diversas funciones de modelado de datos de autoservicio a los analistas de datos y de negocio. La experiencia de modelado tabular es más accesible para estos usuarios, que, en muchos casos, llevan años trabajando con los datos en herramientas de productividad de escritorio como Excel y Microsoft Access. En SQL Server 2012, el modelado tabular se ha mejorado para permitir a los profesionales de BI la creación de modelos tabulares en Analysis Services o la importación de un modelo tabular de PowerPivot en Analysis Services. Tenga en cuenta que un modelo de PowerPivot no se puede importar en un modelo multidimensional de Analysis Services. El objeto de estas notas del producto es ofrecerle una orientación práctica que pueda servirle de ayuda para decidir qué tipo de modelado de SQL Server 2012 Analysis Services, el tabular o el multidimensional, es el que mejor se adapta como su siguiente solución de BI. Las descripciones y las recomendaciones de productos de este documento son para SQL Server 2012 Analysis Services, que se lanzó en marzo de 2012. Las características y las recomendaciones de productos pueden cambiar a medida que el modelado multidimensional y tabular de Analysis Services evolucione en versiones futuras de SQL Server. Elementos del modelado BISM Antes de profundizar en los detalles de las diferencias entre el modelado multidimensional y el tabular, comencemos con una explicación breve de los elementos de cada una de las experiencias de modelado BISM que SQL Server 2012 Analysis Services ofrece. Modelado multidimensional Como principio fundamental, el modelado multidimensional crea cubos compuestos de medidas y dimensiones según los datos incluidos en una base de datos relacional. Para usar este paradigma, el servidor de Analysis Services debe configurarse para operar en modo multidimensional, su configuración predeterminada. En este modo, el motor OLAP usa el modelo multidimensional para agregar por anticipado grandes volúmenes de datos que agilicen las respuestas de las consultas. El motor OLAP puede almacenar estas agregaciones en el disco con almacenamiento OLAP multidimensional (MOLAP) o en la base de datos relacional con almacenamiento OLAP relacional (ROLAP). Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 5 Entre las características clave del modelado multidimensional se incluyen: Modelo de datos enriquecido: el modelo multidimensional de SQL Server 2012 Analysis Services va por la sexta versión y proporciona una amplia funcionalidad para modelar las medidas y las dimensiones a partir de los conjuntos de datos simples o complejos que se suelen encontrar en los almacenamientos de datos. Los conjuntos de datos más complejos suelen incluir características avanzadas como son las relaciones de varios a varios, las jerarquías de elementos primarios y secundarios y la localización. El modelo multidimensional proporciona esta funcionalidad directamente. Análisis sofisticado: el modelo multidimensional también proporciona un lenguaje de consulta y cálculo avanzado denominado Expresiones multidimensionales (MDX). Mediante MDX puede crear sofisticados cálculos y una lógica de negocio que permitan operar en cualquier parte del espacio multidimensional para llevar a cabo asignaciones financieras, cálculos de series temporales o métrica semiaditiva. Aunque el modelado multidimensional tiene unas ventajas considerables como es un modelado completo de los datos y un análisis sofisticado, a menudo acarrea también desventajas, como es la posibilidad de alargar los ciclos de desarrollo y menoscabar la capacidad de adaptarse rápidamente a las condiciones empresariales en continuo cambio. Además, la experiencia multidimensional tiende a requerir conocimientos avanzados de Expresiones multidimensionales y modelado. Modelado tabular El modelado tabular organiza los datos en tablas relacionadas. Si desea utilizar el modelado tabular, Analysis Services debe configurarse para trabajar en modo tabular. En este modo, puede usar el motor en memoria xVelocity (antes Vertipaq) para cargar los datos tabulares en memoria a fin de agilizar la respuesta de las consultas o bien puede utilizar DirectQuery para pasar las consultas a la base de datos de origen y aprovechar así sus capacidades de procesamiento de consultas. Entre las características clave del modelado tabular se incluyen: La familiaridad: el trabajo con datos tabulares es una tarea conocida para muchos usuarios que suelen trabajar con tablas almacenadas en bases de datos relacionales, Excel o Access. Además, los cálculos se escriben con Expresiones de análisis de datos (DAX), un lenguaje de fórmulas que se considera una extensión del de Excel. Por tanto, los conocimientos necesarios para generar modelos tabulares son más comunes o se aprenden con mayor facilidad en comparación con los que se requieren para generar modelos multidimensionales. La flexibilidad: dado que no es necesaria una organización rígida de los datos en forma de medidas y dimensiones, el modelado tabular puede acelerar los ciclos de desarrollo, al requerir una menor preparación previa de los datos y un diseño menos riguroso que los modelos multidimensionales. Esta arquitectura de datos también puede acomodarse más a los cambios del modelado de datos con el tiempo cuando es necesario actualizar las relaciones y los cálculos según las necesidades empresariales en continua evolución. Aunque la familiaridad y la flexibilidad son ventajas clave del modelado tabular, también acarrea algunas desventajas. Por ejemplo, el modelado tabular puede no ser adecuado para aquellas soluciones que tengan conjuntos de datos muy complejos o que requieran una lógica empresarial sofisticada. Los usuarios del lenguaje DAX a menudo pueden crear fórmulas DAX para proporcionar funciones analíticas que no están disponibles en el modelo tabular. Por lo tanto, en estos casos, puede ser más conveniente y eficaz usar las funciones avanzadas que se proporcionan en el modelado multidimensional. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 6 Herramientas de análisis de cliente BISM Tanto si elige el modelado multidimensional como si prefiere el tabular, es importante tener en cuenta que puede utilizar las herramientas de cliente que generan MDX o DAX para consultar el modelo. Excel y SQL Server Reporting Services son ejemplos de herramientas de cliente que generan consultas con MDX y Power View es un ejemplo de herramienta de cliente que genera consultas con DAX. Esta indicación tiene dos excepciones: Power View, una característica del complemento Microsoft SQL Server 2012 Reporting Services para Microsoft SharePoint Server 2010 Enterprise Edition, es una herramienta interactiva de exploración y visualización de datos. Si desea usar Power View o cualquier otro cliente de análisis que utilice DAX para consultar un BISM, es necesario utilizar un modelo tabular. Se espera que las versiones futuras de SQL Server permitan usar DAX para consultar los modelos multidimensionales de modo que una herramienta de cliente como Power View pueda acceder a ellos. Los modelos tabulares configurados para usar DirectQuery requieren una herramienta de cliente que genere consultas DAX como Power View. Se espera que las versiones futuras de SQL Server permitan que los modelos tabulares configurados para usar DirectQuery acepten consultas MDX. Modelo de datos Las características de un modelo de datos son una consideración esencial en la elección de la experiencia de modelado. Relaciones de datos Un requisito fundamental de cualquier modelo de datos es representar correctamente cómo se interrelacionan y se conectan los datos concretos dentro del modelo, como las piezas de un rompecabezas. Tanto los modelos tabulares como los multidimensionales requieren la definición de relaciones entre las tablas de datos de origen. Las relaciones comunes que se observan en el modelado de datos son relaciones de uno a varios, de varios a varios y de referencia. Relaciones de uno a varios En una relación de uno a varios, un solo registro de una tabla se relaciona con varios registros de otra tabla. Un ejemplo de relación de uno a varios es un cliente que tiene varios pedidos. Tanto los modelos de datos tabulares como los multidimensionales tratan las relaciones de uno a varios. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 7 Relaciones de varios a varios En una relación de varios a varios, muchos registros de una tabla se relacionan con muchos registros de una segunda tabla. Por ejemplo, un solo cliente tiene una relación de uno a varios con pedidos; sin embargo, cada cliente puede clasificarse en uno o varios perfiles de cliente (como deportista, jugador ocasional y experto en fitness). Al analizar los pedidos por perfil de cliente puede producirse una doble contabilidad al tener que contar los elementos de varios a varios: el pedido de una bicicleta por parte de un cliente que sea un deportista y también un experto en fitness podría fácilmente contabilizarse dos veces cuando los pedidos del perfil de cliente se sumen para obtener los pedidos totales. Generalmente, las relaciones de varios a varios se administran dividiéndolas en dos relaciones de uno a varios con una tabla puente o intermedia según se muestra en la ilustración 1. Id. de cliente 1 … Nombre de cliente Elizabeth Johnson … Id. de cliente Pedido de ven... Importe de ... 1 1 1 … Tabla de clientes Id. de cliente 1 1 1 … S9100 S9101 S9102 … $ $ $ 4.000 2.500 7.000 … Tabla de pedidos de venta Perfil de cliente Deportista Jugador ocasional Experto en fitness … Tabla intermedia o puente para asignar el perfil de cliente Ilustración 1. Ejemplo de varios a varios En los modelos multidimensionales, puede definir y generar relaciones de varios a varios directamente en el modelo de datos identificando la tabla puente y después relacionando dicha tabla con otras del modelo. Al agregar, Analysis Services aplica una operación sum distinct para asegurarse de que los totales de los datos se suman correctamente y no se agregan valores por error. Los modelos tabulares de SQL Server 2012 Analysis Services no admiten la definición de relaciones de varios a varios. Sin embargo, puede utilizar el lenguaje DAX para crear fórmulas con las que se soluciona el problema de las relaciones varios a varios. Relaciones de referencia Un modelo de datos puede contener un conjunto de atributos comunes relacionados con varias entidades. Por ejemplo, los atributos geográficos se relacionan con los clientes, los proveedores y los almacenes. En el modelado multidimensional debe crear una dimensión que contenga los atributos comunes y después crear relaciones de dimensión de referencia a cada una de las dimensiones relacionadas. En el modelado tabular no hay ninguna necesidad de crear relaciones de referencia. En un modelo tabular, lo único que debe hacer es crear relaciones entre la tabla que contiene los atributos comunes y las tablas que contienen las entidades relacionadas. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 8 Jerarquías Las jerarquías clasifican los datos en una estructura de árbol para facilitar el análisis minucioso. Jerarquías estándar Las jerarquías estándar se componen de los niveles pedidos que proceden de las columnas de los datos de origen. Por ejemplo, una jerarquía de producto puede organizar los productos en subcategorías, que a su vez se pueden organizar en categorías. En este caso, tendría una jerarquía con tres niveles, en la que cada nivel procedería de una columna independiente en los datos de origen. Las jerarquías sencillas como la de productos descrita aquí se admiten tanto en el modelo tabular como en el dimensional. Observe que, dentro de los modelos multidimensionales, se agrega un paso para crear las relaciones de atributo, que es la identificación explícita de las relaciones de uno a varios entre los atributos de cada dimensión. Es muy aconsejable definir las relaciones de atributo porque posibilitan un diseño más eficaz de los agregados calculados previamente y porque la semántica de MDX se basa en este tipo de relaciones. El modelado tabular es más sencillo porque no crea relaciones de atributo. Los modelos tabulares no calculan previamente las agregaciones y la semántica de DAX no se basa en la identificación de las relaciones de uno a varios entre atributos, por lo que en el modelado tabular no hay ningún equivalente a las relaciones de atributo del modelado multidimensional. Jerarquías desiguales Las jerarquías desiguales se producen cuando un elemento de datos determinado falta en el árbol de jerarquía. Por ejemplo, una jerarquía desigual de productos se produce si hay productos que nunca se asignan a una subcategoría, aunque tengan asignaciones de categoría de producto. En estas situaciones, en lugar de mostrar un hueco en el árbol, puede optar por ocultar el hueco para facilitar el análisis minucioso. Los modelos multidimensionales permiten usar directamente las jerarquías desiguales mientras que los modelos tabulares no admiten esta capacidad. Jerarquías de elementos primarios y secundarios Las jerarquías de elementos primarios y secundarios proporcionan un diseño jerárquico más complicado. No todas las bifurcaciones de una jerarquía de elementos primarios y secundarios tienen el mismo número de niveles. Por ejemplo, una relación de elementos primarios y secundarios entre un empleado y su jefe podría generar una jerarquía en la que algunos jefes solo tuvieran informes directos mientras que otros tuvieran informes directos que a su vez también tuvieran sus propios informes directos. Para modelar este tipo de jerarquía, se crea una relación entre dos columnas en una tabla de datos de origen, según se muestra en la ilustración 2. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 9 Manager Director Ken J. Sánchez Ken J. Sánchez Brian S. Welcker Ken J. Sánchez Amy E. Alberts Brian S. Welcker Jae B. Pak Amy E. Alberts David M. Bradley Ken J. Sanchez Kevin F. Brown David M. Bradley Employee Empleado Datos de origen primarios y secundarios Árbol de jerarquía de elementos primarios y secundarios Ilustración 2. Jerarquía de elementos primarios y secundarios Los modelos multidimensionales proporcionan directamente una funcionalidad que permite definir y generar jerarquías de elementos primarios y secundarios según las relaciones de los datos de origen. En los modelos tabulares, puede aprovechar las funciones DAX para crear fórmulas que navegan por la estructura de elementos primarios y secundarios y la usan en los cálculos. Para obtener más información sobre el uso de jerarquías de elementos primarios y secundarios en los modelos tabulares, vea Descripción de las funciones para jerarquías de elementos primarios y secundarios en DAX (http://msdn.microsoft.com/es-es/library/gg492192(v=sql.110).aspx). Características de modelado adicionales Además de las jerarquías y las relaciones de los datos, hay características de modelado adicionales que pueden ayudarle a elegir la mejor experiencia de modelado: Las perspectivas permiten definir un subconjunto de un modelo de datos para facilitar la exploración por parte de los usuarios finales. Hay perspectivas disponibles tanto en los modelos multidimensionales como en los modelos tabulares. Las traducciones permiten que los modelos multidimensionales muestren la dimensión, los atributos, las medidas, los miembros calculados y otros valores de los miembros de dimensión y nombres de objeto en el idioma especificado por la configuración de la localización del equipo. Para habilitar esta característica, es necesario que el desarrollador del modelo proporcione los nombres de objeto traducidos y haga referencia a las columnas en los datos de origen que contienen los valores traducidos de los miembros de dimensión. Los modelos tabulares no proporcionan esta funcionalidad. Las acciones permiten a los usuarios finales ejecutar un informe de Reporting Services, navegar a una dirección URL o iniciar una operación externa según el contexto de la celda donde se produce la acción. Por ejemplo, mediante una acción, un usuario final puede iniciar una página web que muestre el catálogo de productos de la empresa filtrado automáticamente según el producto o los productos que el usuario examinaba. Las acciones que admiten directamente los modelos multidimensionales y muchas herramientas de cliente (como Excel y Reporting Services) permiten a los usuarios la ejecución de acciones. En SQL Server 2012 no se admite la posibilidad de crear acciones en un modelo tabular mediante SQL Server Data Tools. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 10 La obtención de detalles le permite navegar a los datos detallados almacenados en el modelo. La obtención de detalles está disponible tanto en el modelado multidimensional como en el tabular. Los modelos multidimensionales también permiten crear acciones de obtención de detalles para que pueda personalizar la experiencia de obtención de detalles especificando las columnas que se devolverán en la obtención de detalles y el espacio del cubo donde la acción se habilitará. La reescritura es una característica que suele ser necesaria en las aplicaciones de presupuesto y previsión. En estos casos, los usuarios empresariales suelen realizar análisis del tipo "y si" donde cambian y actualizan los valores de datos del modelo y luego los publican para que otros los vean. Los modelos multidimensionales permiten la reescritura de datos. En SQL Server 2012, los modelos tabulares no admiten esta funcionalidad. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 11 Lógica empresarial La lógica empresarial puede agregar un valor tremendo a cualquier modelo de datos mediante cálculos y reglas de negocios que mejoran los datos para el análisis del usuario final. Tanto el modelado tabular como el multidimensional ofrecen completos lenguajes de fórmulas para implementar la lógica empresarial. El modelado multidimensional saca provecho de MDX mientras que el modelado tabular usa DAX. Antes de ahondar un poco en algunos escenarios avanzados de lógica empresarial de cada paradigma, es importante establecer una descripción de referencia del modo en que la lógica empresarial se puede aplicar mediante transformaciones de nivel de fila, valores agregados y cálculos en el modelado multidimensional y tabular. Transformaciones de fila Puede que tenga que realizar cálculos y transformaciones de datos que no estén siempre disponibles en los datos de origen. Por ejemplo, los datos de origen pueden tener una columna Cantidad de ventas y una columna Tasa de intercambio diario pero faltar las ventas convertidas a la divisa extranjera, o los datos de origen pueden tener el nombre y el apellido del empleado pero faltar su nombre completo concatenado. Observe que, en estos ejemplos, el cálculo o manipulación de datos debe producirse en los datos sin agregar de las filas. En el modelado multidimensional, las transformaciones de fila en los datos sin agregar deben realizarse antes de que se carguen los datos en el modelo o cuando este se consulta. Puede transformar los atributos de dimensión, como los nombres de empleados, ya sea aplicando la transformación en el sistema de origen de datos o escribiendo una expresión SQL que se aplique cuando Analysis Services consulte la base de datos de origen. Las transformaciones de fila de los datos numéricos pueden realizarse con una expresión SQL antes de que los datos se carguen en Analysis Services o la transformación puede aplicarse con una expresión MDX dentro de una instrucción Scope de modo que el cálculo se aplique en las filas. Si la transformación se aplica antes de que se carguen los datos, Analysis Services puede agregar los valores numéricos. Si la transformación se aplica mediante una instrucción scope, la agregación se produce en el momento de la consulta. En el modelado tabular, las transformaciones de fila se crean con columnas calculadas. Al crear una columna calculada, se agrega la columna a una tabla específica en el modelo y para definir la columna se usan fórmulas DAX. La fórmula se evalúa entonces para cada registro de dicha tabla y se carga en memoria como cualquier otra columna del modelo. Esta flexibilidad permite mejorar los datos directamente en el modelo tabular en función de sus requisitos específicos de análisis y reduce la necesidad de realizar modificaciones en los orígenes de datos de nivel superior que pueden o no acomodarse a sus cambios de forma oportuna. Las columnas calculadas proporcionan una forma muy cómoda de crear y de conservar los cálculos que se deben realizar en un nivel detallado en los datos antes de agregarse. Aunque esta flexibilidad es eficaz, observe que las columnas calculadas no están pensadas para realizar la limpieza de muchos datos ni para las transformaciones de datos que encontraría en los procesos de carga, extracción y transformación (ETL). Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 12 Valores agregados En el modelado multidimensional, se usan medidas para crear valores agregados. El motor OLAP de Analysis Services agrega previamente las medidas de un cubo con funciones de agregado como SUM, COUNT, MIN, MAX y DISTINCT COUNT, entre otras. Durante el procesamiento de los cubos, cada medida se agrega de arriba abajo a través de todas las jerarquías. Dado que este procesamiento se produce antes del análisis del usuario final, las medidas agregadas previamente pueden proporcionar enormes ventajas en el rendimiento de las consultas. Cuando crea una medida en el cubo, existe una relación de uno a uno entre una medida de cubo y una columna numérica en los datos de origen. Por tanto, en el modelado multidimensional, las medidas son útiles cuando es necesario realizar la agregación ascendente de los elementos de datos numéricos que (1) existen en los datos de origen en el nivel mínimo de detalle y (2) requieren un resumen que se aprovecha de una de las funciones de agregado originales de los cubos. En el modelado tabular, también se usan medidas para crear valores agregados. Para crear una medida, seleccione una columna y después especifique la función de agregación (SUM, COUNT, DISTINCT COUNT, MIN, MAX o AVERAGE), o bien puede escribir una expresión DAX que especifique la función que desea utilizar para agregar la medida. En el modelado tabular, los datos de fila se almacenan en memoria y los agregados se calculan en el momento de la consulta. Como se explica en la sección siguiente, en el modelado tabular, también se pueden usar medidas para aplicar cálculos. Esto puede incluir los cálculos que se basan en varias columnas agregadas. Cálculos En el modelado multidimensional, se usa MDX para crear cálculos. MDX es un lenguaje tanto de consultas como de expresiones con funciones que pueden entender directamente el diseño de las dimensiones, las jerarquías, las relaciones de atributo y las medidas de un cubo. Esta descripción original le permite crear expresiones concisas y eficaces que aplican la lógica empresarial en varios contextos de datos. Los cálculos de MDX se crean y almacenan en el script de cálculo del cubo, donde puede controlar el orden en el que se aplica la lógica. Los miembros calculados son los cálculos más comunes de MDX. Se evalúan en el momento de la consulta, una vez que los datos se agregan previamente. Se pueden crear en cualquier dimensión. Cuando se crean en la dimensión de medidas, se suele hacer referencia a ellos como medidas calculadas. Los miembros calculados pueden ser bastante simples, con operaciones aritméticas básicas como las ventas por unidad (ventas / unidad) o el gasto por persona (gasto / recuento). También pueden ser más complejos cuando es necesario aplicar reglas de negocios específicas como el resumen del promedio del tercer período o el margen de YTD. Por ejemplo, si desea calcular las ventas del período de tiempo actual como un porcentaje del período de tiempo primario, puede utilizar el siguiente cálculo de MDX. [Measures].[Sales Amount] / ([Date].[Calendar].CurrentMember.Parent,[Measures].[Sales Amount]) Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 13 Al crear un miembro calculado en una dimensión que no sea la de medidas, se agrega un valor a un atributo en la dimensión. Por ejemplo, si tuviera un atributo de dimensión que contuviera una lista de colores, podría desear agregar los colores primarios del miembro calculado que sumarían los valores de los colores rojo, verde y azul. En el modelado tabular, la creación de una medida es similar a la creación de un miembro calculado en la dimensión de medidas de un modelo multidimensional. En el modelado tabular, no puede agregar un valor a una columna de una tabla, de modo que ese modelado no admite el equivalente de la creación de un miembro calculado en una dimensión que no sea la dimensión de medidas de un modelo multidimensional. Las asignaciones de ámbito son más avanzadas que las medidas calculadas pero también son más eficaces. Según se indica en la sección "Transformación de filas" anterior, podría usar una instrucción Scope de forma que los cálculos se apliquen en las filas. Sin embargo, también puede usar una instrucción Scope para especificar cualquier rango de celdas de cubo donde desee aplicar un cálculo. Las asignaciones de ámbito se compilan anticipadamente a las consultas y permiten que Analysis Services proporcione una forma de ejecución optimizada cuando el cálculo se consulta. Dada su eficiencia, las asignaciones de ámbito no solo pueden hacer el trabajo de varias medidas calculadas sino que también pueden hacerlo más eficazmente. Por ejemplo, en una solución de presupuestos, desea asignar el presupuesto del año próximo para que el área Este tenga el noventa por ciento del presupuesto del año actual. Desea que el nuevo presupuesto de la región Oeste sea del setenta y cinco por ciento del presupuesto del año actual. Desea que el nuevo presupuesto de la región Sur sea del ciento cinco por ciento del presupuesto del año actual y que el nuevo presupuesto de la región Norte sea el mismo que su presupuesto del año actual. En lugar de escribir una única medida calculada compleja con instrucciones IF anidadas o varias medidas calculadas que segreguen cada escenario de presupuesto individualmente, puede utilizar asignaciones de ámbito para aplicar eficazmente estas proporciones en la región y después agregar los totales de los datos. Por ejemplo, si deseara convertir el importe de las ventas en una divisa extranjera mediante tasas de cambio diarias, podría usar la expresión MDX siguiente: Scope([Date].[Date]); This = [Measures].[Sales Amount] * [Measures].[Daily FX Rate]; End Scope; En el modelado tabular, para crear los cálculos se usa DAX. Como se mencionó anteriormente, en el modelo tabular, los cálculos de fila se aplican creando columnas calculadas. También puede aplicar los cálculos cuando crea una medida escribiendo una expresión DAX. Dado que usa explícitamente una combinación de funciones de agregación y de fila DAX, las medidas de los modelos tabulares son muy flexibles. Puede aplicar las funciones de filas y después aplicar una función de agregación de modo que la medida aplique los cálculos antes de la agregación o puede aplicar primero las funciones de agregación y después aplicar las funciones de fila de modo que la medida aplique los cálculos después de las agregaciones. DAX puede evaluar dinámicamente una fórmula en varios contextos de datos diferentes (no solo la vista actual de una hoja de cálculo de Excel o una tabla dinámica) mediante un conjunto especial de funciones denominadas funciones FILTER. En el sentido más amplio, estas funciones tienen un fin similar a las asignaciones de ámbito de Analysis Services en que le permiten definir y realizar un cálculo sobre un conjunto específico de filas. Por ejemplo, puede utilizar funciones FILTER para controlar el ejemplo del presupuesto descrito anteriormente. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 14 Escenarios de lógica empresarial Ahora que conoce bien cómo puede crear y aplicar lógica empresarial básica en MDX y DAX, considere los siguientes escenarios de cálculo para comparar y contrastar las experiencias de modelado tabular y de modelado multidimensional. Lógica de jerarquía Según se ha indicado anteriormente, las jerarquías proporcionan un modo de que los usuarios empresariales exploren los datos en profundidad o los resuman durante el análisis de datos. En algunas situaciones, resulta útil crear cálculos que naveguen por la jerarquía. Por ejemplo, considere una dimensión de producto donde tiene un producto y una categoría y una subcategoría de producto. Para cada nivel de la jerarquía, desea agregar un cálculo que mida el modo en que los miembros de cada nivel contribuyen al total de ventas del elemento primario. Esto se conoce como porcentaje del cálculo primario determinado que debe navegar por la jerarquía para devolver el valor deseado. Tanto MDX como DAX proporcionan funciones para trabajar con los datos que se organizan en una jerarquía y crean cálculos como un porcentaje de elementos primarios; sin embargo, las funciones MDX tienden a ser más sencillas y más fáciles de utilizar. Por ejemplo, en MDX, esta la expresión que proporciona el porcentaje de elementos primarios de la dimensión de productos. [Measures].[Sales Amount] / ([Product].[Product Categories].CurrentMember.Parent, [Measures].[Sales Amount]) Esta expresión más compleja se requiere para crear el mismo porcentaje de cálculos primarios utilizando DAX. IF( ISFILTERED(Product[Product]) ,[Sales]/CALCULATE([Sales],ALL(Product[Product])) ,IF( ISFILTERED(Product[Subcategory]) ,[Sales]/CALCULATE([Sales],ALL(Product[Subcategory])) ,1 ) ) Resúmenes personalizados Aunque el resumen uniforme de los datos es aplicable en muchos escenarios, también hay situaciones en las que se desea tener un control más exhaustivo sobre el modo en que los datos se acumularán. Un ejemplo de esto es el caso de los modelos financieros en los que hay un gráfico de cuentas (normalmente, en forma de elementos primarios y secundarios) con la lógica de resumen específica necesaria para cada cuenta. Como se muestra aquí, el cálculo del margen bruto son las ventas netas menos el costo de ventas total, y el cálculo del beneficio operativo es el margen bruto menos los gastos de funcionamiento. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 15 Los modelos multidimensionales no solo permiten usar directamente las jerarquías de elementos primarios y secundarios, también ofrecen funciones integradas de inteligencia para las cuentas, lo que posibilita aplicar fácilmente los operadores unarios y las fórmulas MDX en las cuentas que permiten el resumen de los datos. En los modelos tabulares, la inteligencia de cuentas o elementos primarios y secundarios no está integrada, pero puede generar su propia solución utilizando una combinación de columnas calculadas y de medidas para crear la jerarquía de elementos primarios y secundarios, y aplicar el resumen personalizado. Medidas semiaditivas En general, las medidas semiaditivas son aquellas que se agregan uniformemente en todas las dimensiones a excepción de la fecha. Algunos ejemplos de medidas semiaditivas son el saldo de apertura y el de cierre. Con estas medidas, desea aplicar una lógica especial para sumar correctamente los datos por período de tiempo. Entonces, el cierre del inventario actual del mes de marzo no es la suma del inventario disponible de todos los días de marzo. Además, este cierre también debe funcionar correctamente en todos los atributos de fecha como el trimestre y el año. Por ejemplo, el cierre del inventario disponible para el primer trimestre debe ser el mismo que el notificado el 31 de marzo (suponiendo que el 31 de marzo sea el último día del primer trimestre). Los modelos multidimensionales proporcionan directamente compatibilidad con las medidas semiaditivas a través de funciones especiales de agregado como son First Child, Last Child, FirstNonEmptyChild y LastNonEmptyChild. Si estas funciones de agregado no satisfacen los requisitos de su lógica concreta, también puede escribir fórmulas de MDX personalizadas. Los modelos tabulares proporcionan funciones similares como ClosingBalanceMonth y OpeningBalanceMonth. Hay funciones adicionales aplicables a través de otros atributos de fecha como el trimestre y el año. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 16 Inteligencia de tiempo Casi todas las soluciones de BI que encuentre requerirán inteligencia de tiempo. La inteligencia de tiempo incluye la capacidad de calcular resúmenes hasta la fecha y comparaciones con años anteriores. Tanto MDX como DAX proporcionan funciones de series de tiempo; sin embargo, cada uno utiliza un diseño ligeramente diferente de modelo de datos. Los modelos multidimensionales ofrecen directamente funciones de inteligencia de tiempo a través del Asistente de Business Intelligence de Analysis Services. Con este asistente, los cálculos de tiempo se pueden agregar al diseño de la dimensión de tiempo y también aplicarse a todas las medidas del modelo. Aunque a través del asistente se pueden crear los cálculos en el momento de la compilación, también puede escribir sus propios cálculos MDX dentro del modelo multidimensional. En los modelos tabulares, aunque no haya ningún asistente para crear cálculos de inteligencia de tiempo, puede crear los cálculos manualmente creando fórmulas DAX que aprovechen funciones como TOTALMTD, TOTALYTD o SAMEPERIODSLASTYEAR. KPI Los indicadores clave de rendimiento (KPI) identifican las medidas especiales que se desea supervisar con respecto a un valor de destino mediante un indicador visual como una palabra irrelevante. Tanto los modelos multidimensionales como los tabulares proporcionan compatibilidad con los KPI. Ambos ofrecen la posibilidad de asignar un destino para una medida y usar la comparación de la real con la de destino para evaluar el estado de rendimiento de la misma. Los modelos multidimensionales permiten además evaluar la tendencia del KPI y asignar un indicador visual independiente para representar cómo se comporta el KPI con el tiempo. Conversión de moneda Las conversiones de moneda requieren la conversión de los datos de una o varias monedas de origen en una o varias monedas de un informe. Por ejemplo si una organización procesa las transacciones de ventas en EUR, JPY y dólares estadounidenses, para consolidar los informes de ventas en toda la organización, debe convertir las transacciones de venta en una o varias monedas para el informe. Para implementar conversiones de moneda en cualquiera de los tipos de modelado, debe acceder a los datos de la tasa de cambio de moneda e incluirlos en el modelo. En los modelos multidimensionales, puede utilizar el Asistente de Business Intelligence de Analysis Services para crear cálculos de conversión de moneda MDX optimizados para admitir diversas monedas de informes y de origen. En un modelo tabular, puede generar su propia solución de conversión de moneda creando fórmulas DAX. Conjuntos con nombre En el modelado multidimensional, los conjuntos con nombre permiten devolver un conjunto de miembros de dimensión que suelen usarse en las aplicaciones de informes. Por ejemplo, puede crear un conjunto con nombre para devolver los últimos doce meses. Crear este conjunto con nombre dentro de un cubo le permite definir de forma centralizada la lógica de conjuntos, para acceder al conjunto desde cualquier aplicación de informes y simplificar la lógica almacenada dentro de la aplicación de informes. Para crear el conjunto con nombre Últimos 12 meses, podría utilizar la siguiente expresión MDX. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 17 Create Set CurrentCube.[Últimos 12 meses] As Max([Date].[Calendar].[Month]).Lag(11):Max([Date].[Calendar].[Month]) Los conjuntos con nombre no están disponibles en el modelado tabular. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 18 Acceso a datos y almacenamiento Rendimiento y escalabilidad El rendimiento y la escalabilidad son los factores esenciales que deben considerarse en una solución BI. Dado que cada uno de los tipos de modelado saca provecho de diferentes tecnologías subyacentes, tiene distintas características de rendimiento y se comporta de forma diferente en este sentido, para considerar convenientemente qué tipo de modelado se adecúa mejor a sus necesidades debe conocer todas estas diferencias. Modelos multidimensionales Como se indicó anteriormente en las notas del producto, los modelos multidimensionales de Analysis Services usan un motor OLAP. En el disco, los datos OLAP se pueden almacenar en las arquitecturas de datos MOLAP y ROLAP. En MOLAP, los datos se almacenan en el disco en formato multidimensional optimizado con la compresión triple típica. En ROLAP, los datos se almacenan en la base de datos relacional de origen. Al pensar en el rendimiento, normalmente será útil considerarlo en dos depósitos: el rendimiento de las consultas y el del procesamiento. Rendimiento de las consultas El rendimiento de las consultas afecta directamente a la calidad de la experiencia del usuario final. Por tanto, es la prueba comparativa principal que se usa para evaluar el éxito de una implementación de OLAP. Analysis Services proporciona varios mecanismos para acelerar el rendimiento de las consultas, como son las agregaciones, el almacenamiento en caché y la recuperación de datos indizada. Además, puede mejorarlo optimizando el diseño de los atributos de dimensiones, los cubos y las consultas MDX. Una de las principales formas de optimizar el rendimiento de las consultas es mediante agregaciones. Una agregación es un resumen precalculado de los datos que se usa para mejorar el rendimiento de las consultas en los modelos multidimensionales. Al consultar un modelo multidimensional, el procesador de consultas de Analysis Services descompone la consulta en solicitudes para el motor de almacenamiento OLAP. Para cada solicitud, el motor de almacenamiento primero intenta recuperar los datos de la memoria caché del motor de almacenamiento en memoria. Si no hay datos disponibles en la memoria caché, intenta recuperarlos de una agregación. Si no hay ninguna agregación, los recupera de las particiones de un grupo de medida. El diseño de agregaciones de datos implica identificar el esquema más eficaz de agregaciones para la carga de trabajo de las consultas. Cuando diseñe las agregaciones, debe considerar las ventajas de las consultas que estas ofrecen en comparación con el tiempo necesario para crearlas y actualizarlas. De hecho, agregar agregaciones innecesarias puede empeorar el rendimiento de las consultas porque, al acertarse poco, la agregación se pasa a la memoria caché de archivos a costa de sacar alguna otra cosa. Caching también es importante para la optimización del rendimiento de las consultas de Analysis Services. Debe tener memoria suficiente para almacenar todos los datos de dimensiones más el espacio para almacenar en caché los resultados de la consulta. Durante la consulta, la memoria se utiliza principalmente para almacenar los resultados en memoria caché de las memorias cachés del motor de almacenamiento y del procesador de consultas. Para optimizar las ventajas del almacenamiento en caché, a menudo puede aumentar la capacidad de respuesta de las consultas cargando previamente los datos en una o en ambas memorias caché. Esto se puede hacer ejecutando previamente una o varias consultas o mediante la instrucción create cache. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 19 Rendimiento del procesamiento El procesamiento es la operación que actualiza los datos en una base de datos de Analysis Services. Cuanto más rápido es el rendimiento del procesamiento, antes pueden los usuarios acceder a los datos actualizados. Analysis Services proporciona varios mecanismos para influir en el rendimiento del procesamiento, como son un diseño eficaz de las dimensiones, las agregaciones y las particiones, y una estrategia económica de procesamiento (por ejemplo, la incremental frente a la actualización completa o el almacenamiento automático en caché). Puede utilizar las particiones para separar los datos de medida (normalmente, los de la tabla de hechos) en unidades físicas. El uso eficaz de las particiones puede mejorar el rendimiento de las consultas y del procesamiento, así como facilitar la administración de datos. Puede tener un diseño de agregaciones independiente y una programación independiente de las actualizaciones para cada partición, lo que puede optimizar en gran medida el rendimiento del procesamiento. También puede tener una combinación de particiones MOLAP y ROLAP para cada tabla de hechos. Este tipo de estrategia de partición se puede utilizar para permitir las consultas en tiempo real o el acceso a conjuntos de datos demasiado grandes para procesarse en un cubo. El uso de técnicas de optimización del procesamiento y las consultas como estas puede ayudarle a ampliar los modelos multidimensionales para tratar terabytes de datos. Para obtener más información sobre la optimización del rendimiento, vea la Guía de rendimiento de Analysis Services 2008 R2 (http://sqlcat.com/sqlcat/b/whitepapers/archive/2011/10/10/analysis-services-2008-r2performance-guide.aspx). Modelos tabulares Los modelos tabulares usan el motor analítico xVelocity, que permite el procesamiento de datos en memoria; o DirectQuery, que pasa consultas a la base de datos de origen para aprovechar sus capacidades de procesamiento de consultas. Las bases de datos de columnas y el procesamiento de datos en memoria presentan ventajas similares. Las bases de datos de columnas permiten una mayor compresión que el almacenamiento tradicional, que suele ser de hasta una décima parte, según la cardinalidad de los datos. La cardinalidad de los datos se centra en caracterizar la distribución de los datos en una única columna. Una alta cardinalidad de los datos significa que los valores de una columna son únicos (por ejemplo, el número de cliente). Una cardinalidad baja de los datos significa que los valores de una columna pueden repetirse (por ejemplo, el sexo y el estado civil). Cuanto menor es la cardinalidad de los datos, mayor es la compresión, lo que significa que caben más datos en la memoria en un momento dado. Como modeladores de datos, es importante conocer la cardinalidad de los datos para determinar qué conjuntos de datos son más adecuados para el modelo tabular así como los requisitos de memoria asociados para admitirlo. Rendimiento de las consultas Cuando un usuario consulta un modelo tabular, el motor realiza exámenes de memoria para recuperar los datos y calcular las agregaciones simultáneamente sin tener que procesar la E/S de disco. Este enfoque puede proporcionar un rendimiento muy alto en las consultas sin requerir una administración especial de la optimización y la agregación. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 20 La manera mejor y más sencilla de optimizar el rendimiento de las consultas para los modelos tabulares es maximizar la memoria disponible. Desde la perspectiva de la escalabilidad, el volumen de datos está limitado principalmente por la memoria física. Se recomienda encarecidamente proporcionar suficiente memoria para contener todos los datos del modelo tabular. En los escenarios en los que la memoria está limitada, el motor en memoria también permite una paginación básica según la memoria física. Además, hay opciones de configuración del servidor que permiten al departamento de TI administrar de modo más específico la memoria disponible para los modelos tabulares. Para obtener más información sobre la configuración de memoria del modelo tabular, vea Propiedades de memoria (http://msdn.microsoft.com/es-es/library/ms174514.aspx). Rendimiento del procesamiento Los modelos tabulares presentan dos diferencias principales en el rendimiento del procesamiento con respecto a los modelos multidimensionales: A diferencia de los modelos multidimensionales, los modelos tabulares cargan los datos directamente en memoria y no necesitan escribir datos en el disco Dado que los modelos tabulares no clasifican los datos en grupos de medidas y dimensiones, el procesamiento puede ser mucho más flexible. Ambas diferencias implican que hay menos sobrecarga con cada actualización de datos, lo que, a su vez, puede agilizar los tiempos de cambio y aumentar la agilidad. Observe este ejemplo. En una organización es común que los agentes de ventas vayan de una región a otra regularmente. Los usuarios empresariales desean ver los datos de ventas acumuladas por las últimas asignaciones de agentes de ventas y de región. En un modelo multidimensional, para realizar esta tarea, primero debe actualizar la dimensión correspondiente a la organización de ventas. Una vez actualizada dicha dimensión, debe actualizar la partición del grupo de medidas de ventas. Al actualizar la partición de ventas, se actualizan tanto los datos detallados como las agregaciones. El paso final de la preparación de los datos (como recomendación) es avisar a la memoria caché de consultas de Analysis Services de que recupere los datos más útiles del disco para la memoria. Según el diseño del modelo de datos, el tamaño de los datos y su elección específica de técnicas de procesamiento (incremental frente a procesamiento completo), esto podría demorarse minutos u horas. Por suerte, hay diversas de técnicas probadas que los profesionales de BI usan cada día para optimizar el procesamiento de los modelos multidimensionales, ya que equilibran los requisitos de procesamiento de datos con las exigencias de disponibilidad. Ahora suponga el mismo escenario en un modelo tabular. En dicho modelo, no existe el concepto de grupos de medidas y dimensiones. En su lugar, los datos se organizan en tablas que tienen relaciones entre sí. Suponga que los datos de la organización de ventas y los datos de ventas están cada uno en sus tablas respectivas con una relación basada en el agente individual de ventas. Con este diseño, al actualizar la tabla de organización de ventas, actualiza automáticamente las columnas calculadas, las relaciones y las jerarquías de usuario afectadas. Esto significa que los datos de ventas reflejan automáticamente los resúmenes actualizados de la región de ventas sin necesidad de volver a procesar los datos de ventas. Esta flexibilidad puede proporcionar ventajas significativas cuando tiene dimensiones que cambian con rapidez y necesita que los datos reflejen las actualizaciones más recientes. Además, observe que, con los modelos tabulares, tampoco es necesario generar agregaciones, escribir los datos en disco, ni copiar la memoria caché de consultas para obtener los datos en memoria. Con los modelos tabulares, los datos se pasan del disco directamente a la memoria y están listos para moverse. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 21 Al igual que los modelos multidimensionales, los modelos tabulares permiten dividir los datos de la tabla en particiones, eliminando la necesidad de un procesamiento innecesario de los datos. Por ejemplo, puede dividir las tablas más grandes en varias particiones, por ejemplo, en una partición mensual para cada mes del año actual y luego en una partición anual para cada uno de los años anteriores. Este método le permite aislar aquellas particiones de procesamiento que requieren una actualización. A diferencia de lo que ocurre en los modelos multidimensionales, tenga en cuenta que, aunque puede procesar varias tablas en paralelo, no puede procesar las particiones de una tabla individual en paralelo. DirectQuery Como alternativa del modo en memoria xVelocity de los modelos tabulares, los profesionales de BI también pueden generar modelos tabulares con el modo DirectQuery. DirectQuery está disponible para los modelos tabulares con orígenes de datos de SQL Server. DirectQuery permite invalidar el procesamiento de datos pasando cálculos y consultas DAX a la base de datos de origen para aprovecharse de las capacidades de SQL Server. Esto es especialmente útil con volúmenes grandes de datos que tienen que actualizarse con frecuencia. Sin embargo, con DirectQuery, las columnas calculadas y las funciones DAX no se admiten. Programación Los Objetos de administración de análisis (AMO) constituyen la API para desarrollar y administrar los objetos de Analysis Services. Esta API se creó antes de que el modelado tabular se agregara a Analysis Services y, por tanto, solo contiene las clases para los objetos asociados tradicionalmente al modelado multidimensional: cubos, dimensiones, grupos de medidas, scripts MDX, etcétera. Sin embargo, esta API se puede utilizar para desarrollar y administrar modelos tabulares. Es una de las ventajas que presenta el modelo semántico de BI al encapsular el modelado multidimensional y el tabular. Mientras que los modelos tabulares y dimensional son distintos internamente, el BISM muestra la misma interfaz externa. Aunque puede utilizar AMO para programar tanto modelos tabulares como multidimensionales, es una interfaz menos intuitiva para los modelos tabulares. Para obtener más información, incluido un ejemplo de código AMO de modelo tabular, vea Tutoriales de Analysis Services (http://msdn.microsoft.com/eses/library/hh231701.aspx) Seguridad Tener una estrategia adecuada de seguridad de datos es importante para asegurarse de que las personas adecuadas tengan acceso a los datos pertinentes. Las organizaciones deben controlar el acceso a los datos para mantener protegidos los activos de datos y cumplir la legislación relativa a la privacidad. Los modelos multidimensionales y los modelos tabulares proporcionan un sólido conjunto de funciones que satisface una amplia variedad de requisitos de seguridad. Existen pequeñas diferencias en las funciones que es importante comprender antes de elegir la experiencia de modelado que mejor satisfará sus necesidades de seguridad. En Analysis Services, para administrar la seguridad de los proyectos tabulares y multidimensionales, se crea un rol y se conceden permisos al mismo. A continuación, se agregan los grupos y nombres de usuario de Windows al rol, con lo que se concede el acceso a los usuarios correspondiente según los permisos del rol. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 22 Seguridad de filas y atributos En un proyecto multidimensional, se usa el concepto de seguridad de los datos de dimensiones para administrar el acceso de las filas. Para implementar la seguridad de los datos de dimensiones para un rol, conceda o deniegue el acceso a los datos de dimensión seleccionando los miembros de dimensión o anulando su selección. También puede implementar una configuración de seguridad más compleja definiendo un conjunto de miembros con una expresión MDX. También especifica si se debe conceder o denegar acceso a los nuevos miembros de dimensión. El acceso que conceda o deniegue a un miembro de dimensión afectará al acceso que un rol tiene a los miembros de dimensión relacionados. Por ejemplo, si limita un rol de modo que solo pueda tenerse acceso a él en la subcategoría de producto de bicicletas de montaña, los miembros del rol solo pueden ver la categoría de producto de bicicletas y los productos y ventas que pertenezcan a la subcategoría de bicicletas de montaña. En un proyecto tabular, la seguridad de las filas se implementa concediendo acceso a las filas de una tabla. En un proyecto tabular de SQL Server Data Tools, los permisos se conceden especificando una expresión DAX que filtre las filas en una tabla. El rol tiene acceso a las nuevas filas de la tabla si cumplen el filtro DAX. El acceso concedido a una fila de una tabla repercute en el acceso que un rol tiene a las filas de las tablas relacionadas. Si dos tablas tienen una relación de uno a varios, los filtros de fila de la tabla en uno de los lados de la relación filtran las filas de la tabla del lado "varios", pero no el otro. Por ejemplo, si limita un rol de modo que solo pueda ver la fila de bicicletas de montaña en la tabla de subcategorías de producto, los miembros del rol solo pueden ver las filas de las tablas de ventas y productos relacionadas con la subcategoría de bicicletas. No obstante, los miembros del rol todavía podrán ver todas las filas de la tabla de categorías de productos (bicicletas, ropa, etc.). Seguridad dinámica Es posible que una organización tenga que limitar el acceso a los datos en función del identificador de un usuario u otros criterios dinámicos. Por ejemplo, los asociados solo pueden ver sus propios datos de recursos humanos y rendimiento. Sin embargo, crear un rol de seguridad para cada individuo de una organización puede resultar poco práctico. En su lugar, puede implementar la seguridad dinámica, que permite dirigir la lógica de seguridad según un identificador de usuario o algún otro criterio dinámico. Tanto los proyectos tabulares como los multidimensionales admiten la seguridad dinámica. Puede configurar la seguridad dinámica, basada en el usuario, si los datos contienen una relación entre los identificadores de usuario y los usuarios de datos tienen permiso de acceso, incluyendo la relación en la expresión MDX o DAX que se use para administrar los permisos. Seguridad de celda y avanzada En muchas aplicaciones, es necesario restringir el acceso a los datos usando criterios más complejos que una simple fila de una tabla. Suponga, por ejemplo, una encuesta de satisfacción de los empleados que comparta los resultados de las agregaciones de una encuesta de opinión. Estos modelos a menudo contienen datos confidenciales y las respuestas individuales de la encuesta se deben proteger. Aunque el modelo no puede contener los nombres de las personas, si el tamaño de la muestra es lo suficientemente pequeño, puede deducirse la identidad de cada destinatario. En estos casos, puede ser conveniente implementar una lógica más compleja que observe el tamaño de la muestra y solo permita el acceso a la medida resultante si el número de respuestas es mayor que cierta cantidad. Además, puede haber preguntas concretas y combinaciones métricas que desearía restringir específicamente para que solo las vieran en el departamento de Recursos humanos. Los proyectos multidimensionales que permiten directamente implementar capacidades avanzadas de seguridad no están disponibles en un proyecto tabular. En un proyecto multidimensional puede implementar la seguridad de las celdas para restringir el acceso a una celda o grupo de celdas concretas del modelo. La seguridad de las celdas no se proporciona en un modelo tabular. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 23 Además, los proyectos multidimensionales también le permiten controlar el uso de totales visuales, conceder o denegar permisos para obtener datos detallados y crear miembros predeterminados para cada rol. En un proyecto multidimensional, los valores de resumen agregados previamente se calculan cuando los datos se procesan en un modelo para mejorar los tiempos de respuesta de las consultas. Por ejemplo, las ventas de todos los productos son un valor precalculado. La seguridad de los datos de dimensiones se aplica una vez procesados estos, de modo que, aunque solo se conceda permiso a un usuario para acceder a la categoría de bicicletas, de forma predeterminada, el valor de las ventas de todos los productos será la suma de las ventas de accesorios, bicicletas, ropa, etcétera. Esto puede ser o no el valor que desea que vean los miembros del rol. En este caso, si desea que el valor de las ventas para todos los productos se limite al valor de ventas de bicicletas, debe habilitar los totales visuales. Al habilitar los totales visuales, se restringen los valores de resumen de modo que deben ser iguales a la suma de los valores de detalle a los que un rol tiene permiso de acceso. Este cambio afecta al tiempo de respuesta de las consultas, ya que los valores de resumen deben calcularse en el momento de la consulta. Los proyectos tabulares no precalculan los valores de resumen, de modo que estos son siempre iguales que la suma de los valores de detalle, es decir, los totales visuales siempre están habilitados en un modelo tabular. En un modelo multidimensional, puede habilitar el permiso para obtener detalles de los datos rol por rol. En un modelo tabular, los roles no se utilizan para controlar el acceso a la función de obtención de detalles. En su lugar, todos los roles pueden obtener detalles. En un modelo multidimensional, puede especificar un miembro predeterminado para cada atributo de una dimensión. Un miembro predeterminado se comporta como un filtro que se aplica de modo automático. Por ejemplo, si el miembro predeterminado de Año es 2012, de forma predeterminada solo se muestran los datos para 2012. Sin embargo, un usuario puede elegir ver datos de otro año o los de todos los años. En un modelo multidimensional, puede configurar un miembro predeterminado para cada atributo que se aplique a todos los roles o puede especificar otro miembro predeterminado diferente rol por rol. En un modelo tabular, no puede especificar un valor predeterminado. En cambio, si se desea un filtro predeterminado, tendrá que configurar esa capacidad en la herramienta de análisis e informe. Resumen En SQL Server 2012, Microsoft incluyó por primera vez el Modelo semántico de Business Intelligence (BISM, Business Intelligence Semantic Model) para dar cabida una amplia variedad de necesidades de informes y análisis. Las dos experiencias de modelado encapsuladas en el BISM, el modelado multidimensional y el modelado tabular, le proporcionan características complementarias para aprovechar las funciones que mejor se adaptan a sus necesidades. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 24 El modelado tabular proporciona una experiencia de modelado accesible directamente a través de funciones que satisfarán la mayoría de las necesidades de informes y análisis. La mayor parte de los usuarios ya saben trabajar con las tablas y las relaciones y aprenden rápidamente a implementar la lógica empresarial con un lenguaje DAX como el de Excel. La facilidad de uso y el modelado simplificado y flexible que proporciona la experiencia tabular implica que las soluciones se pueden desarrollar rápidamente. El motor xVelocity en memoria con columnas proporciona una respuesta extremadamente rápida a las consultas en conjuntos de datos que pueden contener mil millones de registros. Los modelos tabulares admiten todas las herramientas de análisis e informes que generan consultas MDX, como Excel y Reporting Services, y también admiten Reporting Services Power View, que genera consultas DAX. El modelado multidimensional ofrece numerosas funciones para ayudar a superar los desafíos de BI más complejos y a mayor escala. El modelo de datos multidimensional combinado con MDX proporciona directamente la funcionalidad necesaria para crear modelos sofisticados e implementar una lógica empresarial compleja. El almacenamiento de datos en disco, los agregados precalculados y el almacenamiento en caché en memoria posibilitan que los modelos multidimensionales crezcan hasta un tamaño de varios terabytes y agilicen la respuesta de las consultas. Gracias a la seguridad de las celdas, puede satisfacer rigurosos requisitos de seguridad. En resumen, el modelado tabular proporciona una experiencia de modelado simplificada a través de funciones que deberían satisfacer la mayoría de sus necesidades de informes y análisis. Si requiere un modelado, una lógica empresarial o una seguridad complejos, o si necesita una solución a muy gran escala, el modelado multidimensional puede ser la mejor solución para sus necesidades. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 25 En la tabla siguiente se proporciona una comparación resumida de las características de los modelos multidimensional y tabular. Grupo de características Modelo de datos Modelo de datos Criterios de decisión Tiempo de la solución Curva de aprendizaje Relaciones de datos Multidimensional/ Tabular / / / Jerarquías / Modelo de datos Lógica empresarial Lógica empresarial Lógica empresarial Características de modelado de datos adicionales Idioma de cálculo Cálculos Funciones de agregación / / / / Modelado multidimensional Mayor tiempo de la solución. Modelado tabular Menor tiempo de la solución. El modelado dimensional y el lenguaje MDX crean una curva de aprendizaje más escarpada pero proporcionan funciones más complejas. El modelado relacional y el lenguaje DAX al estilo de Excel crean una curva de aprendizaje menos escarpada pero las funciones complejas pueden requerir expresiones DAX sofisticadas. Uno a varios. La relación varios a varios requiere expresiones DAX. El modelado de las relaciones entre tablas crean relaciones de referencia. Compatibilidad con las jerarquías estándar. Las jerarquías de elementos primarios y secundarios requieren expresiones DAX. Perspectivas y obtención de detalles. Uno a varios. Varios a varios. Las relaciones de referencia deben modelarse explícitamente. Compatibilidad con las jerarquías estándar, desiguales y de elementos primarios y secundarios Perspectivas, traducciones, acciones, obtención de detalles, procedimientos almacenados y reescritura. MDX Compatibilidad con cálculos comunes y complejos. Sum, Count, Min, Max, Distinct Count, None, ByAccount, AverageOfChildren, FirstChild, LastChild, FirstNonEmpty y LastNonEmpty. DAX Compatibilidad con cálculos comunes y muy complejos. Sum, Count, Min, Max, Average, DistinctCount y varias funciones de inteligencia de tiempo como FirstDate, LastDate, OpeningBalanceMonth y ClosingBalanceMonth. Grupo de características Lógica empresarial Criterios de decisión Lógica de jerarquía Multidimensional/ Tabular / Lógica empresarial KPI Lógica empresarial Conversión de moneda Acceso a datos y almacenamiento Acceso a datos y almacenamiento Escala / / / Rendimiento / Acceso a datos y almacenamiento Orígenes de datos Acceso a datos y almacenamiento Lenguaje de consulta Modelado multidimensional Funciones para navegar por las jerarquías estándar y de elementos primarios y secundarios. Real, objetivo, estado y tendencia con indicadores gráficos Admite la conversión de varias monedas con el Asistente de Business Intelligence. Escala extremadamente grande (varios terabytes) Índices y valores de medidas preagregados almacenados en el disco. Datos de dimensión y resultados de consultas almacenados en la memoria caché. Compresión de datos aproximadamente tres veces. Bases de datos relacionales. / / MDX Modelado tabular Funciones DAX para navegar por las jerarquías de elementos primarios y secundarios, expresiones DAX para implementar la lógica en dimensiones estándar. La lógica de la jerarquía normalmente es más difícil con DAX. Real, objetivo y con indicadores gráficos. Implementación con expresiones DAX. Escala grande (mil millones de registros) Almacenamiento de datos basado en columnas en memoria. Compresión de datos aproximadamente diez veces. Bases de datos relacionales, Excel, Text, fuentes OData, Azure Data Market, Analysis Services. DAX MDX (solo modo en memoria) Grupo de características Acceso a datos y almacenamiento Criterios de decisión Almacenamiento de datos Multidimensional/ Tabular / Acceso a datos y almacenamiento Acceso a datos y almacenamiento Compresión de datos Herramientas de cliente / / Acceso a datos y almacenamiento Programación Seguridad Seguridad / / : menos funciones. : más funciones. Modelado multidimensional MOLAP: datos agregados, de dimensiones y hechos almacenados en el disco. Datos de dimensión y resultados de consultas almacenados en la memoria caché. ROLAP: datos agregados, de dimensiones y hechos almacenados en una base de datos relacional. Normalmente, tres veces. Excel, Reporting Services, Microsoft PerformancePoint y otras herramientas de cliente de terceros. Reporting Services Power View se admitirá en versiones futuras de SQL Server. XMLA, ASSL, ADOMD.NET, MSOLAP, AMO, Windows PowerShell para AMO. Se han desarrollado para usarse con modelos multidimensionales. Miembro de dimensión y seguridad en las celdas. Seguridad dinámica. Modelado tabular En memoria: todos los datos almacenados en caché en memoria que utilizan el motor analítico xVelocity orientado a columnas DirectQuery: datos almacenados en SQL Server 2012. Normalmente, diez veces. Reporting Services Power View, Excel, Reporting Services, PerformancePoint y otras herramientas de cliente de terceros. XMLA, ASSL, ADOMD.NET, MSOLAP, AMO, PowerShell para AMO. Disponibles pero menos intuitivos para usarse con modelos tabulares. Seguridad en las filas. Seguridad dinámica. Para obtener más información Sitio web de SQL Server http://www.microsoft.com/sqlserver/ SQL Server TechCenter http://technet.microsoft.com/es-es/sqlserver/ SQL Server DevCenter http://msdn.microsoft.com/es-es/sqlserver/ Blog del equipo de Analysis Services y PowerPivot http://blogs.msdn.com/b/analysisservices/ Analysis Services http://msdn.microsoft.com/es-es/library/bb522607.aspx Modelado multidimensional (SSAS) http://msdn.microsoft.com/es-es/library/hh230904.aspx Modelado tabular (SSAS tabular) http://msdn.microsoft.com/es-es/library/hh212945.aspx Característica por modo de servidor o tipo de solución (SSAS) http://msdn.microsoft.com/es-es/library/hh212940(v=sql.110).aspx ¿Le sirvió de ayuda este documento? Por favor, proporciónenos su opinión. Díganos, en una escala de 1 (poco útil) a 5 (excelente), cómo calificaría este documento y por qué lo valora con esta puntuación. Por ejemplo: ¿Lo valora positivamente debido a que tiene buenos ejemplos, capturas de pantalla excelentes, una redacción comprensible u otra razón? ¿Lo valora negativamente debido a que sus ejemplos son escasos, las capturas de pantalla son borrosas o su redacción es poco clara? Esta información nos ayudará a mejorar la calidad de las notas del producto que publicamos. Enviar comentarios. Elegir un paradigma de modelado de datos en SQL Server 2012 Analysis Services 29