Modo DirectQuery (SSAS tabular)

Analysis Services le permite crear modelos tabulares e informes que recuperan datos y los agregan directamente desde un sistema de base de datos relacional mediante el modo DirectQuery. Entre las ventajas que se suelen citar del uso del modo DirectQuery se incluyen la posibilidad de consultar conjuntos de datos muy grandes que no caben en la memoria y actualizar los datos en tiempo real.

En este tema se presentan las diferencias entre los modelos tabulares estándar que residen únicamente en la memoria y los modelos tabulares que pueden realizar consultas en un origen de datos relacional, y se explica cómo crear e implementar un modelo para utilizar en el modo DirectQuery.

Secciones de este tema:

• Información general del modo DirectQuery

• Crear modelos para su uso en el modo DirectQuery

  • Orígenes de datos para los modelos DirectQuery

  • Restricciones de validación y de diseño para el modo DirectQuery

  • Compatibilidad de las fórmulas

  • Conectar con los modelos DirectQuery

  • Seguridad

• Propiedades de DirectQuery

• Temas y tareas relacionados

Información general del modo DirectQuery

De forma predeterminada, los modelos tabulares utilizan una caché en memoria para almacenar los datos y realizar consultas en ellos. Dado que los modelos tabulares utilizan datos que residen en memoria, incluso las consultas más complejas pueden resultar increíblemente rápidas. Sin embargo, el uso de datos en caché tiene algunas desventajas:

• Los datos no se actualizan cuando cambian los datos de origen. Es necesario procesar el modelo para conseguir actualizaciones de los datos.

• Cuando se apaga el equipo que hospeda el modelo, el contenido de la memoria caché se guarda en el disco y deberá abrirse de nuevo al cargar el modelo o abrir el archivo de PowerPivot. Las operaciones de guardado y de carga pueden requerir mucho tiempo.

En cambio, un modelo tabular en el modo DirectQuery emplea datos almacenados en una base de datos de SQL Server o en un almacenamiento de datos de SQL Server PDW. En tiempo de diseño, se importan todos los datos o una pequeña muestra de los datos de la memoria caché y se genera el modelo de la forma habitual. Cuando esté listo para implementar el modelo, cambie el modo de funcionamiento a DirectQuery. Después de cambiar el modo de funcionamiento, cualquier consulta del modelo usará el origen de datos relacional especificado (SQL Server o SQL Server PDW), no los datos almacenados en memoria caché.

Cuando se crean informes o consultas en el modelo, puede usar DAX, pero Analysis Services traduce las consultas de DAX a instrucciones equivalentes de Transact-SQL en el origen de datos relacional especificado.

La implantación de un modelo mediante el modo DirectQuery ofrece muchas ventajas:

• Es posible tener un modelo acerca de los conjuntos de datos que son demasiado grandes para caber en la memoria del servidor de Analysis Services.

• La actualización de los datos está garantizada, y no existe una sobrecarga adicional de administración al no tener que mantener otra copia de estos. Los cambios en el origen de datos subyacente se pueden reflejar inmediatamente en las consultas realizadas en el modelo de datos.

• DirectQuery puede beneficiarse de la aceleración de consultas del proveedor, como la proporcionada por los índices de columnas optimizadas de memoria xVelocity. Los índices de almacenamiento de columnas xVelocity se incluyen tanto en SQL Server 2012 como en SQL Server PDW para admitir el rendimiento mejorado de DirectQuery.

• La aplicación de la seguridad requerida por la base de datos back-end se garantiza mediante la seguridad de nivel de filas. En cambio, si usa datos en caché, puede resultar difícil garantizar que la memoria caché esté protegida exactamente como en el servidor.

• Si el modelo contiene fórmulas complejas que requieren varias consultas, Analysis Services puede realizar la optimización para asegurarse de que el plan de consulta para la consulta ejecutada en la base de datos back-end sea tan eficaz como sea posible.

Diseñar modelos para el modo DirectQuery

Todos los modelos tabulares se crean mediante el diseñador de modelos en SQL Server Data Tools (SSDT), que siempre crea los modelos en memoria de forma predeterminada. Esto significa que si trabaja con datos demasiado grandes que no caben en la memoria, debe trabajar en un subconjunto menor de datos durante el tiempo de diseño y tener acceso al origen de datos completo solo después de que se implemente el modelo. Existen varias formas de trabajar con un subconjunto menor de datos:

• Al agregar datos al modelo mediante el Asistente para la importación de tablas, use un filtro para importar únicamente un subconjunto de datos en la memoria caché usada por la base de datos del área de trabajo. Después de implementar el modelo, puede editar la definición de la consulta para quitar o modificar el filtro.

• Use un origen de datos de almacenamiento provisional y diseñe el modelo mientras las tablas de ensayo solo contienen un subconjunto de datos.

• Agregue particiones a las tablas para administrar la cantidad de datos que es necesario procesar en cualquier momento.

Cuando esté listo para cambiar al modo DirectQuery, puede cambiar una propiedad que habilite este modo. Para obtener más información, vea Habilitar el modo de diseño de DirectQuery (SSAS tabular).

Al hacerlo, el diseñador de modelos configura automáticamente la base de datos del área de trabajo para que se ejecute en un modo híbrido que le permita continuar trabajando con los datos en caché. Asimismo, el diseñador de modelos le notificará acerca de las características del modelo que son incompatibles con el modo DirectQuery. En la lista siguiente se resumen los principales requisitos que se han de tener en cuenta:

• Orígenes de datos: los modelos DirectQuery solo pueden usar datos de un único origen de datos relacional. El origen puede ser una instancia de SQL Server o una instancia de SQL Server PDW. Una vez habilitado el modo DirectQuery para el modelo, no se puede usar ningún otro tipo de datos en el diseñador de modelos, incluidas las tablas agregadas por operaciones de cortar y pegar. El resto de las opciones de importación están deshabilitadas. Además, todas las tablas incluidas en una consulta deben formar parte del origen de datos especificado. Para obtener más información, vea Orígenes de datos.

• Compatibilidad con columnas calculadas: las columnas calculadas no se admiten en los modelos DirectQuery. Sin embargo, puede crear medidas y KPI que actúen sobre conjuntos de datos. Para obtener más información, vea la sección que trata sobre la validación.

• Uso limitado de las funciones DAX: algunas funciones DAX no se pueden usar en el modo DirectQuery, por lo que deberá sustituirlas por otras funciones o crear los valores mediante columnas derivadas del origen de datos. El diseñador de modelos proporciona validación en tiempo de diseño para cualquier error que pueda surgir al crear fórmulas incompatibles con el modo DirectQuery. Para obtener más información, vea esta sección: Validación.

• Compatibilidad con fórmulas: en algunos casos conocidos, la misma fórmula puede devolver resultados distintos en un modelo en caché o híbrido en comparación con un modelo DirectQuery que use solamente el almacén de datos relacional. Estas diferencias son consecuencia de las diferencias semánticas entre el motor analítico en memoria xVelocity (VertiPaq) y SQL Server. Para obtener más información sobre estas diferencias, vea esta sección: Compatibilidad con fórmulas.

• Seguridad: puede utilizar métodos diferentes para proteger los modelos dependiendo de cómo se implementen estos. Los datos almacenados en caché para los modelos tabulares están protegidos mediante el modelo de seguridad de la instancia de Analysis Services. Los modelos de DirectQuery se pueden proteger mediante roles, pero también puede usar la seguridad definida en el almacén de datos relacional. El modelo se puede configurar de modo que los usuarios que abran un informe basado en un modelo Solo DirectQuery puedan ver solo los datos que tengan autorizados en virtud de sus permisos de SQL Server. Vea esta sección para obtener más información: Seguridad.

• Restricciones de cliente: cuando un modelo está en modo DirectQuery, solo se puede consultar mediante DAX. No se puede utilizar MDX para crear consultas. Esto significa que no podrá utilizar el cliente dinámico de Excel, porque Excel usa MDX.

  Sin embargo, puede crear consultas acerca de un modelo DirectQuery en SQL Server Management Studio si utiliza una consulta de tabla de DAX como parte de una instrucción EXECUTE de XMLA. Para obtener más información, vea Referencia de la sintaxis de las consultas DAX.

Una vez haya resuelto todos los problemas de diseño y probado el modelo, estará listo para la implementación. En este momento, puede establecer el método preferido para responder a las consultas sobre el modelo. ¿Desea que los usuarios obtengan acceso a la memoria caché, o que utilicen siempre solamente el origen de datos relacional?

Si implementa el modelo en un modo híbrido, la memoria caché seguirá estando disponible y se podrá utilizar con las consultas. Un modo híbrido le ofrece muchas opciones:

• Si tanto la memoria caché como el origen de datos relacional están disponibles, puede establecer el método de conexión preferido, pero será el cliente el que en última instancia decida el origen que se usará, mediante la propiedad de cadena de conexión DirectQueryMode.

• También puede configurar particiones en la memoria caché de tal manera que la partición principal utilizada para el modo DirectQuery no se procese nunca y deba hacer siempre referencia al origen relacional. Hay muchas maneras de utilizar particiones para optimizar el diseño del modelo y la creación de informes. Para obtener más información, vea Particiones y el modo DirectQuery (SSAS tabular).

• Una vez implementado el modelo, puede cambiar el método de conexión preferido. Por ejemplo, puede utilizar un modo híbrido para las pruebas, y cambiar el modelo a Solo DirectQuery únicamente después de probar exhaustivamente los informes o las consultas utilizadas por este. Para obtener más información, vea Establecer o cambiar el método de conexión preferido para DirectQuery.

Orígenes de datos para los modelos DirectQuery

Tan pronto como cambie el entorno de diseño para habilitar el modo DirectQuery, se validarán los orígenes de datos de la base de datos del área de trabajo para garantizar que provienen de un único origen de datos relacional. Los datos de otros orígenes, incluidos los datos de copiar y pegar, no se admiten en los modelos DirectQuery.

Si tiene previsto usar el modelo en el modo DirectQuery, debe asegurarse de que todos los datos que necesita para la creación de informes estén almacenados en el origen de datos especificado. Si los datos que necesita para el modelado no están disponibles en ese origen, considere la posibilidad de usar Integration Services u otras herramientas de almacenamiento de datos para importar los datos en la base de datos o en el almacenamiento de datos que actúa como origen de datos DirectQuery.

Restricciones de validación y de diseño para el modo DirectQuery

Al crear un modelo para su uso en el modo DirectQuery, se deben cargar inicialmente parte de los datos en la memoria caché. Si los datos que va a usar no caben en la memoria, puede emplear la opción Vista previa y filtrar del Asistente para la importación de tablas con el fin de seleccionar un subconjunto de datos, o escribir un script SQL que le permita obtener los datos que desea. Otra posibilidad consiste en almacenar provisionalmente un subconjunto de los datos en un almacenamiento de datos y aumentar el almacenamiento de datos una vez finalizada la fase de diseño.

Advertencia
Puesto que el modo DirectQuery no admite el uso de columnas calculadas, debe quitar todas las columnas calculadas. Puede convertir algunas columnas calculadas en medidas, pero en otros casos es posible que genere columnas derivadas como parte de la consulta o el script de importación de datos, o que las agregue en el origen de datos relacional.

Para ver y resolver los errores de validación, abra la Lista de errores en SQL Server Data Tools. Los errores críticos que impiden el uso del modo DirectQuery se muestran en la pestaña Errores. Debe corregir estos errores antes de cambiar al modo DirectQuery. Generalmente, los errores de validación más difíciles de resolver están relacionados con las fórmulas que no se admiten en el modo DirectQuery. Vea la sección Compatibilidad de las fórmulas para obtener información general sobre los errores relacionados con las fórmulas y las columnas calculadas.

La lista siguiente describe otras consideraciones que se han de tener en cuenta al crear un modelo para el acceso DirectQuery:

• En el modo Solo DirectQuery, los resultados del informe pueden variar en función del contexto de seguridad del usuario que esté viendo los resultados. Debe probar los modelos con distintas credenciales para asegurarse de que los usuarios consiguen los resultados previstos.

• Si configura un modelo para que funcione en el modo híbrido, lo que permite el uso de la memoria caché o de los datos del origen relacional, debe tener en cuenta la posibilidad de que los clientes vean resultados diferentes, en función del modo especificado en la cadena de conexión. Si necesita asegurarse de que los usuarios del informe vean solo los datos del origen relacional, debe borrar la memoria caché o cambiar el modelo a DirectQueryOnly.

Compatibilidad de las fórmulas para los modelos DirectQuery

Algunos modelos pueden contener fórmulas que no se admiten en el modo DirectQuery; en estos casos, es necesario volver a diseñar el modelo para evitar los errores de validación. Entre las restricciones de las fórmulas que se admiten en el modo DirectQuery están las siguientes:

• Las columnas calculadas no se admiten en ningún modelo tabular que tenga habilitado el modo DirectQuery, ni siquiera en modelos híbridos. Si necesita columnas calculadas en un modelo, considere la posibilidad de convertirlas en columnas derivadas utilizando Transact-SQL en la definición de importación.

• Los modelos DirectQuery admiten el uso de fórmulas DAX en las medidas, que se convierten en operaciones basadas en conjuntos en el almacén de datos relacional. También se admiten las medidas que puede crear mediante medidas implícitas.

• No se admiten todas las funciones. Puesto que Analysis Services convierte todas las fórmulas DAX y las definiciones de medida en instrucciones SQL cuando se consulta un modelo DirectQuery, las fórmulas que contengan elementos que no se puedan convertir en Transact-SQL desencadenarán errores de validación en el modelo. Por ejemplo, las funciones de la inteligencia de tiempo no se admiten. Incluso las funciones admitidas pueden comportarse de forma diferente, como las funciones estadísticas. Para obtener una lista completa de problemas de compatibilidad, vea Compatibilidad de las fórmulas en el modo DirectQuery.

• Algunas fórmulas del modelo pueden validarse al cambiar este al modo DirectQuery, pero devolver resultados diferentes cuando se ejecutan en la memoria caché o en el almacén de datos relacional. Esto es debido a que los cálculos en la memoria caché utilizan la semántica del motor analítico en memoria xVelocity (VertiPaq), que contiene muchas características cuya finalidad es emular el comportamiento de Excel, mientras que las consultas en los datos almacenados en el almacén de datos relacional utilizan necesariamente la semántica de SQL Server. Para obtener una lista de las funciones DAX que pueden devolver resultados diferentes cuando el modelo se implementa en tiempo real, vea Compatibilidad de las fórmulas en el modo DirectQuery.

Conectar con los modelos DirectQuery

Los clientes que utilicen MDX como lenguaje de consultas no podrán conectarse a los modelos que utilizan el modo DirectQuery. Si intenta crear una consulta MDX en un modelo DirectQuery, aparecerá un error que indica que no se puede encontrar el cubo o que este no se ha procesado. Puede crear consultas en los modelos DirectQuery utilizando Power View, fórmulas DAX o consultas XMLA. Para obtener más información sobre cómo realizar consultas ad hoc en modelos tabulares, vea Acceso a datos de modelos tabulares.

Si va a usar un modelo híbrido, puede especificar si los usuarios se conectarán a la memoria caché o usarán datos DirectQuery especificando la propiedad de cadena de conexión, DirectQueryMode.

La seguridad en el modo DirectQuery

Los permisos que se utilizan para recuperar los datos de origen se deben especificar durante el proceso de creación del modelo. A menudo, serán sus propias credenciales o una cuenta que se use para el desarrollo. Sin embargo, cuando se cambia el modelo al modo DirectQuery, el contexto de seguridad es más complejo:

• Considere si los usuarios tienen el nivel de acceso necesario a los datos del almacén de datos relacional.

• Los usuarios que tienen acceso al mismo modelo o informe pueden ver datos diferentes, dependiendo del contexto de seguridad del usuario.

• Si se ha conservado la memoria caché de modelos, dicha memoria debe protegerse con los (roles) de modelo de seguridad de Analysis Services. Es posible que la memoria caché contenga datos que puede ver el diseñador de modelos pero no otros usuarios. Los diseñadores de modelos y de informes deben borrar la memoria caché o proteger estos datos controlando el acceso a ellos mediante roles.

• Un modelo que responda a las consultas de la memoria caché no puede suplantar al usuario actual al conectarse al origen de datos. Si desea suplantar al usuario actual al conectarse al origen de datos, debe utilizar el modo DirectQuery.

• Si su modelo de informe requiere funciones de seguridad, dispone de dos opciones: utilizar los roles de Analysis Services o establecer permisos para el origen de datos en el nivel de fila. La seguridad en el origen de datos relacional se utiliza para controlar el acceso a las tablas, y no se admite la seguridad en el nivel de columna. Por lo tanto, si los usuarios de una región no tienen permiso para ver las cifras de ventas de otras regiones, un informe que incluya una medida basada en la tabla de ventas devolverá espacios en blanco o un error.

La propiedad de los valores de suplantación especifica las credenciales utilizadas al conectarse a un modelo con DirectQuery, ya sea para un modelo Solo DirectQuery o para un modelo híbrido que responda a consultas mediante DirectQuery. La propiedad tiene los siguientes valores:

• Valor predeterminado
  Utiliza las credenciales especificadas en el asistente para la importación para conectarse al origen de datos. Puede ser un usuario específico de Windows o la cuenta de servicio.

• ImpersonateCurrentUser
  Usa las credenciales de Windows del usuario actual para conectarse al origen de datos.

Para obtener información sobre cómo establecer estas propiedades, vea Escenarios de implementación de DirectQuery (SSAS tabular).

Propiedades de DirectQuery

La tabla siguiente enumera las propiedades que se pueden establecer en SQL Server Data Tools y SQL Server Management Studio para habilitar DirectQuery y controlar el origen de los datos utilizado para las consultas en el modelo.

Además, si el modelo incluye particiones, deberá elegir una que actuará como origen para las consultas en el modo DirectQuery. Para obtener más información, vea Particiones y el modo DirectQuery (SSAS tabular).

Temas y tareas relacionados

Vea también

Conceptos

Particiones (SSAS tabular)

Proyectos de modelos tabulares (SSAS tabular)

Analizar en Excel (SSAS tabular)