Modo DirectQuery (SSAS Tabular)

Analysis Services permite recuperar datos y crear informes a partir de un modelo tabular mediante la recuperación de datos y agregados directamente desde un sistema de base de datos relacional mediante el modo DirectQuery. En este tema se presentan las diferencias entre los modelos tabulares estándar que solo residen en la memoria y los modelos tabulares que pueden consultar un origen de datos relacional y se explica cómo puede crear e implementar un modelo para su uso en el modo DirectQuery.

Secciones de este tema:

• Ventajas del modo DirectQuery

• Creación de modelos para su uso con el modo DirectQuery

  • Orígenes de datos para modelos directQuery

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

  • Compatibilidad de fórmulas para modelos directQuery

  • Seguridad en modo DirectQuery

  • Seguridad en modo DirectQuery

• Propiedades de DirectQuery

• Temas y tareas relacionados

Ventajas del modo DirectQuery

De forma predeterminada, los modelos tabulares usan una memoria caché en memoria para almacenar y consultar datos. Dado que los modelos tabulares usan datos que residen en la memoria, incluso las consultas complejas pueden ser increíblemente rápidas. Sin embargo, hay algunas desventajas en el uso de datos almacenados en caché:

• Los datos no se actualizan cuando cambian los datos de origen. Debe procesar el modelo para obtener actualizaciones de los datos.

• Al desactivar el equipo que hospeda el modelo, la memoria caché se guarda en el disco y se debe volver a abrir al cargar el modelo o abrir el archivo PowerPivot. Las operaciones de guardar y cargar pueden llevar mucho tiempo.

En cambio, el modo DirectQuery usa datos almacenados en una base de datos de SQL Server. Por lo general, se importan todos o un pequeño ejemplo de los datos en la memoria caché al crear el modelo y, al implementar el modelo, se especifica que el origen de datos para las consultas en el modelo debe ser SQL Server, no los datos almacenados en caché. Las consultas DAX sobre los datos son traducidas por Analysis Services a instrucciones SQL equivalentes contra el origen de datos relacional especificado.

Hay muchas ventajas para implementar un modelo mediante el modo DirectQuery:

• Es posible tener un modelo sobre conjuntos de datos demasiado grandes para caber en la memoria en el servidor de Analysis Services.

• Se garantiza que los datos son up-to-date y no hay sobrecarga de gestión adicional por mantener una copia separada de los datos. Los cambios en los datos de origen subyacentes se pueden reflejar inmediatamente en las consultas en el modelo de datos.

• DirectQuery puede aprovechar la aceleración de consultas del lado proveedor, como la proporcionada por índices de columna optimizados para memoria xVelocity.

• Se garantiza que cualquier medida de seguridad impuesta por la base de datos back-end se aplique utilizando seguridad a nivel de fila. Por el contrario, si usa datos almacenados en caché, puede ser difícil asegurarse de que la caché está protegida exactamente como en el servidor.

• Si el modelo contiene fórmulas complejas que podrían requerir varias consultas, Analysis Services puede realizar la optimización para asegurarse de que el plan de consulta de la consulta ejecutada en la base de datos back-end será lo más eficaz posible.

Creación de modelos para su uso con el modo DirectQuery

Los modelos tabulares se crean mediante el diseñador de modelos SQL Server Data Tools (SSDT). El diseñador de modelos crea todos los modelos en memoria, lo que significa que, al modelar, si los datos son demasiado grandes para caber en la memoria, solo debe importar un subconjunto de datos en la memoria caché utilizada por la base de datos del área de trabajo.

Cuando esté listo para cambiar al modo DirectQuery, puede cambiar una propiedad que habilita el modo DirectQuery. Para obtener más información, consulte Habilitar el modo de diseño 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 seguir trabajando con los datos almacenados en caché. El diseñador de modelos también le notificará las características del modelo que no son compatibles con el modo DirectQuery. En la lista siguiente se resumen los requisitos principales que se deben tener en cuenta:

• Orígenes de datos: Los modelos de DirectQuery solo pueden usar datos de un único origen de datos de SQL Server. Cuando el modo DirectQuery se ha activado para un modelo, no puede usar ningún otro tipo de datos en el diseñador de modelos, incluidas las tablas agregadas por operaciones de copiar y pegar. Todas las demás opciones de importación están deshabilitadas. Las tablas incluidas en una consulta deben formar parte del origen de datos de SQL Server. Consulte Orígenes de datos para modelos directQuerypara obtener más información.

• Compatibilidad con columnas calculadas: Las columnas calculadas no se admiten para los modelos de DirectQuery. Sin embargo, puede crear medidas y KPI, que funcionan sobre conjuntos de datos. Consulte la sección sobre validación para obtener más información.

• Uso limitado de funciones DAX: Algunas funciones DAX no se pueden usar en el modo DirectQuery, por lo que debe reemplazarlas por otras funciones o crear los valores mediante columnas derivadas en el origen de datos. El diseñador de modelos proporciona validación en tiempo de diseño para los errores que surgen al crear fórmulas incompatibles con el modo DirectQuery. Consulte las secciones siguientes para obtener más información: Validación.

• Compatibilidad de fórmulas: En determinados casos conocidos, la misma fórmula puede devolver resultados diferentes en un modelo almacenado en caché o híbrido en comparación con un modelo directQuery que usa solo el almacén de datos relacional. Estas diferencias son consecuencia de las diferencias semánticas entre el motor de análisis en memoria (VertiPaq) de xVelocity y SQL Server. Para obtener más información sobre estas diferencias, consulte esta sección: Compatibilidad de fórmulas.

• Seguridad: Puede usar diferentes métodos para proteger modelos en función de cómo se implementen. Los datos almacenados en caché para los modelos tabulares se protegen 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 para que los usuarios que abran un informe basado en un modelo de solo DirectQuery puedan ver solo los datos que se les permiten con sus permisos en SQL Server. Consulte 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 puede usar MDX para crear consultas. Esto significa que no puede usar el cliente dinámico de Excel, ya que Excel usa MDX.

  Sin embargo, puede crear consultas contra un modelo DirectQuery en SQL Server Management Studio si usa una consulta de tabla DAX como parte de una instrucción Execute XMLA. Para obtener más información, vea [Referencia de sintaxis de consulta DAX](/dax/dax-syntax-reference)

Cuando haya resuelto todos los problemas de diseño y probado el modelo, estará listo para la implementación. En este punto, puede establecer el método preferido para responder a las consultas en el modelo. ¿Desea que los usuarios tengan acceso a la memoria caché o usen siempre solo el origen de datos relacional?

Si implementa el modelo en modo híbrido, la memoria caché sigue estando disponible y se puede usar para las consultas. Un modo híbrido proporciona muchas opciones:

• Cuando tanto la memoria caché como el origen de datos relacional están disponibles, puede establecer el método de conexión preferido, pero en última instancia, el cliente decide qué fuente se utiliza, mediante la propiedad DirectQueryMode de la cadena de conexión.

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

• Una vez implementado el modelo, puede cambiar el método de conexión preferido. Por ejemplo, puede usar un modo híbrido para las pruebas y cambiar el modelo solo al modo Solo DirectQuery después de probar exhaustivamente los informes o consultas que usan el modelo. Para obtener más información, vea Establecer o cambiar el método de conexión preferido para DirectQuery.

Orígenes de datos para modelos directQuery

En cuanto cambie el entorno de diseño para habilitar el modo DirectQuery, los orígenes de datos de la base de datos del área de trabajo se validan para asegurarse de que proceden de un único origen de datos de SQL Server. Los datos de otros orígenes, incluidos los datos pegados por copia, no se permiten en los modelos de DirectQuery.

Si piensa usar el modelo en modo DirectQuery, debe asegurarse de que todos los datos que necesita para los informes se almacenan en la base de datos de SQL Server especificada. 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 una base de datos de SQL Server que actúa como origen de datos de DirectQuery.

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

Al crear un modelo para su uso en el modo DirectQuery, debe cargar inicialmente alguna parte de los datos en la memoria caché. Si los datos que va a usar finalmente son demasiado grandes para caber en la memoria, puede usar la opción Vista previa y filtro en el Asistente para importación de tablas para seleccionar un subconjunto de datos, o escribir un script SQL para obtener los datos que desee.

Para ver y resolver 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. Los errores de validación que son más difíciles de resolver normalmente están relacionados con fórmulas que no se admiten en el modo DirectQuery. Consulte la sección Compatibilidad de fórmulas para obtener información general sobre los errores relacionados con las fórmulas y las columnas calculadas.

En la lista siguiente se describen otras consideraciones que se deben tener en cuenta al crear un modelo para el acceso a DirectQuery:

• Cuando se encuentra en modo solo DirectQuery , los resultados de un informe pueden variar en función del contexto de seguridad del usuario que esté viendo los resultados. Debe probar modelos con credenciales diferentes para asegurarse de que los usuarios obtienen los resultados esperados.

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

Compatibilidad de fórmulas para modelos directQuery

Algunos modelos pueden contener fórmulas que no se admiten en el modo DirectQuery y el modelo debe rediseñarse para evitar errores de validación. Las restricciones en las fórmulas que se admiten en el modo DirectQuery incluyen lo siguiente:

• 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 para un modelo, considere la posibilidad de convertirlas en columnas derivadas mediante Transact-SQL en la definición de importación.

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

• No se soportan todas las funciones. Dado que Analysis Services convierte todas las fórmulas DAX y las definiciones de medida en instrucciones SQL al consultar un modelo de DirectQuery, cualquier fórmula que contenga elementos que no se puedan convertir en Transact-SQL desencadenará errores de validación en el modelo. Por ejemplo, no se admiten funciones de inteligencia temporal. Incluso las funciones admitidas pueden comportarse de forma diferente, como las funciones estadísticas. Para obtener una lista completa de los problemas de compatibilidad, consulte Compatibilidad de fórmulas en modo DirectQuery.

• Algunas fórmulas del modelo pueden validarse al cambiar el modelo al modo DirectQuery, pero devuelven resultados diferentes cuando se ejecutan en la memoria caché frente al almacén de datos relacional. Esto se debe a que los cálculos en la memoria caché usan la semántica del motor de análisis en memoria xVelocity (VertiPaq), que contiene muchas características destinadas a emular el comportamiento de Excel, mientras que las consultas en los datos almacenados en el almacén de datos relacional usan necesariamente la semántica de SQL Server. Para obtener una lista de funciones DAX que podrían devolver resultados diferentes cuando el modelo se implementa en tiempo real, consulte Compatibilidad de fórmulas en modo DirectQuery.

Conexión a los modelos de DirectQuery

Los clientes que usan MDX como lenguaje de consulta no se pueden conectar a modelos que usan el modo DirectQuery. Por ejemplo, si intenta crear una consulta MDX en un modelo de DirectQuery, obtendrá un error que indica que no se encuentra el cubo o que no se ha procesado. Puede crear consultas en modelos directQuery mediante Power View, fórmulas DAX o consultas XMLA. Para obtener más información sobre cómo puede realizar consultas ad hoc en modelos tabulares, vea Acceso a datos del modelo tabular.

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

Seguridad en modo DirectQuery

Durante la creación de modelos, especifique los permisos que se usan para recuperar los datos de origen. Estas suelen ser tus propias credenciales o una cuenta que se utiliza para el desarrollo. Sin embargo, al cambiar el modelo para usar el 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 ven el mismo modelo o informe pueden ver datos diferentes, en función del contexto de seguridad del usuario.

• Si se conserva la caché del modelo, la memoria caché se protege mediante el modelo de seguridad (roles) de Analysis Services. La memoria caché puede contener datos a los que el diseñador de modelos tiene privilegios de acceso, pero el usuario no. Los diseñadores de modelos e informes deben borrar la memoria caché o proteger estos datos mediante el control del acceso a través de roles.

• Un modelo que responde a las consultas de la caché no puede suplantar al usuario actual al conectarse al origen de datos. Si quiere suplantar al usuario actual al conectarse al origen de datos, debe usar el modo DirectQuery.

• Si el modelo de informe requiere seguridad, tiene dos opciones: puede usar roles de Analysis Services o puede establecer permisos de nivel de fila en el origen de datos. La seguridad en el origen de datos relacional se usa para controlar el acceso a las tablas y no se admite la seguridad de nivel de columna. Por lo tanto, si los usuarios de una región no tienen permiso para ver las cifras de ventas de diferentes regiones, un informe que incluye una medida basada en la tabla Sales devolvería espacios en blanco o un error.

La propiedad de configuración de suplantación especifica las credenciales que se utilizan al conectarse a un modelo mediante DirectQuery, ya sea para un modelo solo de DirectQuery o para un modelo híbrido que proporciona respuestas a consultas mediante DirectQuery. La propiedad tiene los siguientes valores:

Predeterminado
Usa las credenciales especificadas en el Asistente para 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 del usuario actual para conectarse al origen de datos.

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

Propiedades de DirectQuery

En la tabla siguiente se enumeran las propiedades que puede establecer en SQL Server Data Tools y en SQL Server Management Studio para habilitar DirectQuery y controlar el origen de datos que se usan para las consultas en el modelo.

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

Temas y tareas relacionados

Véase también

Particiones (SSAS tabular)
Proyectos de modelo tabular (SSAS tabular)
Analizar en Excel (SSAS tabular)