Uso de DirectQuery para conjuntos de datos de Power BI y Azure Analysis Services (versión preliminar)

  • Artículo
  • 16 minutos para leer

Con DirectQuery para los conjuntos de datos de Power BI y Azure Analysis Services (AAS) , puede usar DirectQuery para conectarse a los conjuntos de datos de Power BI o AAS y, si lo desea, combinarlo con otros datos importados y otra instancia de DirectQuery. Esta característica resultará especialmente útil para autores de informes que quieran combinar los datos de su modelo semántico empresarial con otros datos que posean, como una hoja de cálculo de Excel, o que quieran personalizar o enriquecer los metadatos de su modelo semántico empresarial.

Habilitación de la característica en versión preliminar

Como la funcionalidad está actualmente en versión preliminar, primero debe habilitarla primero. Para hacerlo, en Power BI Desktop, vaya a Archivo > Opciones y configuración > Opciones y, en la sección Características en vista previa, active la casilla DirectQuery para conjuntos de datos de Power BI y Analysis Services para habilitar esta característica en vista previa (GB). Para que el cambio se aplique, puede que tenga que reiniciar Power BI Desktop.

Uso de DirectQuery para conexiones dinámicas

El uso de DirectQuery para los conjuntos de datos de Power BI y Azure Analysis Services requiere que el informe tenga un modelo local. Puede empezar a partir de una conexión dinámica y agregar o actualizar a un modelo local, o bien empezar con una conexión de DirectQuery o datos importados, lo que crea automáticamente un modelo local en el informe.

Para ver las conexiones que se usan en el modelo, compruebe la barra de estado que se encuentra en la esquina inferior derecha de Power BI Desktop. Si solo está conectado a un origen de Azure Analysis Services, verá un mensaje similar a la imagen siguiente:

Conexión solo de Azure Analysis Services

Si está conectado a un conjunto de datos de Power BI, verá un mensaje en el que se le indicará el conjunto de Power BI al que está conectado:

Conexión del conjunto de datos de Power BI

Si quiere personalizar los metadatos de los campos del conjunto de datos con conexión dinámica, seleccione Hacer cambios en este modelo en la barra de estado. Como alternativa, puede hacer clic en el botón Hacer cambios en este modelo que está en la cinta de opciones, tal como se muestra en la imagen siguiente. En Vista de informe, el botón Hacer cambios en este modelo en la pestaña Modelado. En Vista de modelo, el botón está en la pestaña Inicio.

Botón Hacer cambios en este modelo

Al seleccionar el botón, se muestra un cuadro de diálogo para confirmar la incorporación de un modelo local. Seleccione Agregar un modelo local para permitir la creación de columnas nuevas o modificar los metadatos para los campos los conjuntos de Power BI o Azure Analysis Services. En la imagen siguiente se muestra el cuadro de diálogo que aparece.

Cuadro de diálogo Crear modelo local

Cuando establece una conexión dinámica a un origen de Analysis Services, no hay ningún modelo local. Si desea usar DirectQuery para orígenes con conexión dinámica, como conjuntos de datos de Power BI y Azure Analysis Services, debe agregar un modelo local al informe. Al publicar un informe con un modelo local en el servicio Power BI, también se publica un conjunto de datos para ese modelo local.

Encadenamiento

Los conjuntos de datos, y los conjuntos de datos y los modelos en que se basan, conforman una cadena. Este proceso, denominado encadenamiento, le permite publicar un informe y un conjunto de datos en función de otros conjuntos de datos de Power BI, una característica que antes no era posible.

Por ejemplo, imagine que un colega suyo publica un conjunto de datos de Power BI denominado Ventas y presupuesto basado en un modelo de Azure Analysis Services denominado Ventas, y lo combina con una hoja de Excel denominada Presupuesto.

Cuando publica un informe (y conjunto de datos) nuevo denominado Ventas y presupuesto Europa que se basa en el conjunto de datos Ventas y presupuesto de Power BI que publicó su colega, y le hace algunas modificaciones o extensiones adicionales, efectivamente agrega un informe y un conjunto de datos a una cadena de longitud tres, que empezó con el modelo Ventas de Azure Analysis Services y finaliza con el conjunto de datos Ventas y presupuesto Europa de Power BI. En la imagen siguiente se muestra este proceso de encadenamiento.

El proceso de encadenar conjuntos de datos

La cadena de la imagen anterior tiene una longitud de tres, que es la máxima longitud permitida durante este período de versión preliminar. No se permite ir más allá de una cadena con longitud de tres, ya que generaría un error.

Advertencia de seguridad

El uso de la característica DirectQuery para conjuntos de datos de Power BI y Azure Analysis Services (AAS) le mostrará un cuadro de diálogo con una advertencia de seguridad, como se ve en la imagen siguiente.

Advertencia de seguridad

Los datos se pueden insertar de un origen de datos a otro, que es la misma advertencia de seguridad que aparece al combinar DirectQuery e importar orígenes en un modelo de datos. Para más información sobre este comportamiento, consulte este artículo sobre cómo usar modelos compuestos en Power BI Desktop.

Características y escenarios que se deben probar

En la lista siguiente se brindan sugerencias sobre cómo puede explorar la característica DirectQuery para conjuntos de datos de Power BI y Azure Analysis Services (AAS) para que pueda hacer lo siguiente:

  • Conectarse a datos de varios orígenes: importaciones (como archivos), conjuntos de datos de Power BI, Analysis Services.
  • Crear relaciones entre distintos orígenes de datos.
  • Escribir medidas que usen campos de distintos orígenes de datos.
  • Crear columnas nuevas para tablas de conjuntos de datos de Power BI y Azure Analysis Services.
  • Crear objetos visuales que usen columnas de distintos orígenes de datos.

A partir de la versión de abril de 2021 de Power BI Desktop, también se puede conectar a una perspectiva al realizar una conexión de DirectQuery a un modelo de Azure Analysis Services, si hay una perspectiva disponible.

A partir de la versión de octubre de 2021 de Power BI Desktop, tiene más control sobre las conexiones:

  • Puede quitar una tabla del modelo mediante la lista de campos para mantener los modelos lo más concisos y ligeros posibles (si se conecta a una perspectiva, no puede quitar tablas del modelo).
  • Puede especificar qué tablas cargar, en lugar de tener que cargarlas todas cuando solo quiere un subconjunto específico de tablas.
  • Puede especificar si quiere agregar tablas que se agreguen posteriormente al conjunto de datos después de establecer la conexión en el modelo.
  • Con la versión de octubre de 2021, se han realizado mejoras de rendimiento con la ejecución en paralelo de consultas del modelo y el almacenamiento en caché inteligente.

Consideraciones y limitaciones

Hay algunas consideraciones que debe tener en cuenta al usar DirectQuery para conjuntos de datos de Power BI y Azure Analysis Services (AAS) :

  • Si actualiza los orígenes de datos y hay errores en nombres de campos o tablas en conflicto, Power BI resuelve estos errores de manera automática.

  • Los usuarios necesitan permisos de "Compilación" en todos los conjuntos de datos de la cadena para acceder a un informe que aproveche esta característica.

  • Para generar informes en el servicio Power BI de un modelo compuesto basado en otro conjunto de datos, se deben establecer todas las credenciales. En la página de actualización de la configuración de credenciales, en el caso de los orígenes de Azure Analysis Services, aparecerá el error siguiente aunque las credenciales estén establecidas:

    Advertencia falsa sobre las credenciales

  • Como esto resulta confuso e incorrecto, nos ocuparemos de ello pronto.

  • Para poder realizar una conexión de DirectQuery en un conjunto de datos de Power BI, el inquilino debe tener habilitada la opción Permitir puntos de conexión XMLA y Analizar en Excel con conjuntos de datos locales.

  • Para las capacidades Premium, el "Punto de conexión XMLA" debe establecerse en "Solo lectura" o "Lectura y escritura".

  • Si usa un área de trabajo clásica en combinación con esta característica, no basta con establecer permisos en el propio conjunto de datos. En el caso de las áreas de trabajo clásicas, todos los usuarios que acceden a informes que aprovechan esta característica deben ser miembros del área de trabajo. Plantéese actualizar las áreas de trabajo clásicas a áreas de trabajo nuevas para evitar esta situación.

  • Las reglas de RLS se aplicarán en el origen en el que se definen, pero no se aplicarán a ningún otro conjunto de datos del modelo. La RLS definida en el informe no se aplicará a los orígenes remotos y la RLS establecida en orígenes remotos no se aplicará a otros orígenes de datos.

  • En esta versión preliminar, las carpetas de visualización, los KPI, las tablas de fecha, la seguridad de nivel de fila y las traducciones no se importarán desde el origen. De todos modos puede crear carpetas de visualización en el modelo local.

  • Puede que vea un comportamiento inesperado al usar una jerarquía de fechas. Para resolver este problema, use en su lugar una columna de fechas. Después de agregar una jerarquía de fechas a un objeto visual, puede cambiar a una columna de fechas si hace clic en la flecha hacia abajo que está en el nombre del campo y, luego, hace clic en el nombre de ese campo en lugar de usar Date Hierarchy (Jerarquía de fechas):

    Comportamiento inesperado de la jerarquía de fechas

    Para más información sobre el uso de las columnas de fechas en comparación con las jerarquías de fechas, visite este artículo.

  • Puede que vea mensajes de error nada útiles al usar las características de IA con un modelo que tiene una conexión de DirectQuery con Azure Analysis Services.

  • Si usa ALLSELECTED con un origen de DirectQuery se generarán resultados incompletos.

  • Filtros y relaciones:

    • Un filtro aplicado de un origen de datos a una tabla desde otro origen de DirectQuery solo se puede establecer en una sola columna.

    • No se recomienda ni se permite filtrar de manera cruzada dos tablas en un origen de DirectQuery mediante su filtrado con una tabla fuera del origen.

    • Un filtro solo puede tocar una vez una tabla. No se permite aplicar dos veces el mismo filtro a una tabla, a través de una o varias tablas fuera del origen de DirectQuery.

  • Durante la versión preliminar, la longitud máxima de una cadena de modelos es tres. No se permite ir más allá de una cadena con longitud de tres, lo que generaría un error.

  • Se puede establecer una marca para impedir el encadenamiento en un modelo a fin de evitar que se cree o se extienda una cadena. Vea Administración de conexiones de DirectQuery a un conjunto de datos publicado para obtener más información.

  • Al igual que con todas las conexiones de DirectQuery, la conexión a un conjunto de datos de Power BI no se mostrará en Power Query.

También hay algunas limitaciones que debe tener en cuenta:

  • Los parámetros de los nombres de servidor y base de datos están deshabilitados actualmente.

  • No se admite la definición de RLS en las tablas de un origen remoto.

  • No se admite el uso de ninguno de los orígenes siguientes como origen de DirectQuery:

  • En la actualidad, no se permite usar DirectQuery en conjuntos de datos de "Mi área de trabajo".

  • Actualmente, no se permite usar Power BI Embedded con conjuntos de datos que incluyan una conexión de DirectQuery a un modelo de conjuntos de Power BI o de Azure Analysis Services.

  • No se admiten grupos de cálculo en orígenes remotos, con resultados de consulta no definidos.

  • Las tablas calculadas no son compatibles con el servicio mediante esta característica.

  • En este momento, no se admite la ordenación por columna.

  • La actualización automática de páginas (APR) solo se permite en ciertos escenarios, en función del tipo de origen de datos. Para más información, consulte Actualización automática de páginas en Power BI.

  • Actualmente no se admite la toma de control de un conjunto de datos que usa la característica DirectQuery para otros conjuntos de datos.

  • Al igual que con cualquier origen de datos de DirectQuery, las jerarquías definidas en un modelo de Azure Analysis Services o un conjunto de datos Power BI no se mostrarán al conectarse al modelo o conjunto de datos en modo DirectQuery con Excel.

Consideraciones sobre inquilinos

Cualquier modelo con una conexión de DirectQuery a un conjunto de datos de Power BI o a Azure Analysis Services se debe publicar en el mismo inquilino, lo que es especialmente importante al acceder a un conjunto de datos de Power BI o a un modelo de Azure Analysis Services mediante identidades de invitado B2B, tal como se muestra en el diagrama siguiente. Vea Usuarios invitados que pueden editar y administrar contenido a fin de encontrar la dirección URL del inquilino para la publicación.

Observe el diagrama siguiente. Los pasos numerados del diagrama se describen en los párrafos siguientes.

Diagrama de no conexión entre inquilinos

En el diagrama, Ash trabaja con Contoso y accede a datos proporcionados por Fabrikam. Con Power BI Desktop, Ash crea una conexión DirectQuery a un modelo de Azure Analysis Services que se hospeda en el inquilino de Fabrikam.

Para autenticarse, Ash utiliza una identidad de usuario invitado B2B (paso 1 del diagrama).

Si el informe se publica en el servicio Power BI de Contoso (paso 2), el conjunto de datos publicado en el inquilino de Contoso no se puede autenticar correctamente en el modelo de Azure Analysis Services de Fabrikam (paso 3). Como resultado, el informe no funcionará.

En este escenario, como el modelo de Azure Analysis Services utilizado se hospeda en el inquilino de Fabrikam, el informe también se debe publicar en el inquilino de Fabrikam. Después de la publicación correcta en el inquilino de Fabrikam (paso 4), el conjunto de datos puede acceder correctamente al modelo de Azure Analysis Services (paso 5) y el informe funcionará sin problemas.

Modelos compuestos con conexión DirectQuery a modelos de origen protegidos por seguridad de nivel de objeto

Cuando un modelo compuesto recibe datos de un conjunto de datos de Power BI o Azure Analysis Services a través de DirectQuery, y ese modelo de origen está protegido por la seguridad de nivel de objeto, los consumidores del modelo compuesto pueden experimentar resultados inesperados. En la sección siguiente se explica cómo pueden presentarse estos resultados.

La seguridad de nivel de objeto (OLS) permite a los autores de modelos ocultar objetos que integran el esquema del modelo (es decir, tablas, columnas, metadatos, etc.) de los consumidores del modelo (por ejemplo, un generador de informes o el autor de modelos compuestos). Al configurar OLS para un objeto, el autor del modelo crea un rol y, a continuación, quita el acceso al objeto para los usuarios que están asignados a ese rol. Desde el punto de vista de esos usuarios, el objeto oculto simplemente no existe.

OLS se define para el modelo de origen y se aplica en el mismo. No se puede definir para un modelo compuesto basado en el modelo de origen.

Cuando un modelo compuesto se basa en un conjunto de datos de Power BI protegido por OLS o un modelo de Azure Analysis Services a través de una conexión DirectQuery, el esquema de modelo del modelo de origen en realidad se copia en el modelo compuesto. Lo que se copia depende de lo que el autor del modelo compuesto tenga permitido ver en el modelo de origen según las reglas OLS que se apliquen. Los datos no se copian en el modelo compuesto; en su lugar, siempre se recuperan a través de DirectQuery desde el modelo de origen cuando es necesario. En otras palabras, la recuperación de datos siempre vuelve al modelo de origen, donde se aplican las reglas OLS.

Dado que el modelo compuesto no está protegido por reglas OLS, los objetos que ven los consumidores del modelo compuesto son los que el autor de dicho modelo podría ver en el modelo de origen, en lugar de aquellos a los que podría tener acceso. Esto puede resultar en las situaciones siguientes

  • Alguien que mira el modelo compuesto podría ver objetos que OLS oculta en el modelo de origen.
  • Por el contrario, es posible que NO vea un objeto en el modelo compuesto que SÍ puede ver en el modelo de origen, porque ese objeto estaba oculto para el autor del modelo compuesto debido a las reglas OLS que controlan el acceso al modelo de origen.

Un punto importante es que, a pesar del caso descrito en la primera viñeta, los consumidores del modelo compuesto nunca verán los datos reales que no deberían ver, porque los datos no se encuentran realmente en el modelo compuesto. En su lugar, debido a DirectQuery, se recuperan según sea necesario del conjunto de datos de origen, donde OLS bloquea el acceso no autorizado.

Teniendo estos antecedentes esto en cuenta, considere el siguiente escenario.

Diagrama que muestra lo que sucede cuando un modelo compuesto se conecta a un modelo de origen protegido por la seguridad de nivel de objeto a través de Direct Query.

  1. Admin_user ha publicado un modelo semántico empresarial mediante un conjunto de datos de Power BI o un modelo de Azure Analysis Services que tiene una tabla Customer y una tabla Territory. Admin_user publica el conjunto de datos en el servicio Power BI y establece reglas OLS que tienen el efecto siguiente:

    • Los usuarios de finanzas no pueden ver la tabla Customer
    • Los usuarios de marketing no pueden ver la tabla Territory

  2. Finance_user publica un conjunto de datos denominado "Finance dataset" y un informe denominado "Finance report" que se conecta a través de DirectQuery con el modelo semántico empresarial publicado en el paso 1. El informe Finance report incluye un objeto visual que usa una columna de la tabla Territory.

  3. Marketing_user abre el informe Finance report. Se muestra el objeto visual que usa la tabla Territory, pero devuelve un error, porque cuando se abre el informe, DirectQuery intenta recuperar los datos del modelo de origen con las credenciales de Marketing_user, quien tiene bloqueada la visualización de la tabla Territory según las reglas OLS establecidas en el modelo semántico empresarial.

  4. Marketing_user crea un nuevo informe denominado "Marketing report" que usa el conjunto de datos Finance como origen. La lista de campos muestra las tablas y columnas a las que Finance_user tiene acceso. Por lo tanto, la tabla Territory se muestra en la lista de campos, pero la tabla Customer no. Sin embargo, cuando Marketing_user intenta crear un objeto visual que usa una columna de la tabla Territory, se devuelve un error, porque en ese momento DirectQuery intenta recuperar datos del modelo de origen mediante las credenciales de Marketing_user y las reglas OLS una vez más bloquean el acceso. Lo mismo sucede cuando Marketing_user crea un nuevo conjunto de datos y un informe que se conectan al conjunto de datos Finance mediante una conexión DirectQuery. Ve la tabla Territory en la lista de campos, ya que eso es lo que Finance_user podría ver, pero cuando intenta crear un objeto visual que use esa tabla, las reglas OLS lo bloquearán en el modelo semántico empresarial.

  5. Ahora supongamos que Admin_user actualiza las reglas OLS en el modelo semántico empresarial para impedir que Finance vea la tabla Territory.

  6. Solo cuando se actualice el conjunto de datos Finance, las reglas OLS actualizadas se aplicarán en él. Por lo tanto, cuando Finance_user actualiza el conjunto de datos Finance, la tabla Territory ya no se mostrará en la lista de campos y el objeto visual del informe Finance que usa una columna de la tabla Territory devolverá un error para Finance_user, porque ahora no tiene permiso para acceder a la tabla Territory.

Para resumir:

  • Los consumidores de un modelo compuesto ven los resultados de las reglas OLS que eran aplicables al autor del modelo compuesto cuando crearon dicho modelo. Por lo tanto, cuando se crea un nuevo informe basado en el modelo compuesto, la lista de campos mostrará las tablas a las que el autor del modelo compuesto tuvo acceso cuando creó el modelo, independientemente de a qué tenga acceso el usuario actual en el modelo de origen.
  • Las reglas OLS no se pueden definir en el propio modelo compuesto.
  • Un consumidor de un modelo compuesto nunca verá los datos reales que no debería ver, porque las reglas OLS pertinentes en el modelo de origen los bloqueará cuando DIrectQuery intente recuperar los datos con sus credenciales.
  • Si el modelo de origen actualiza sus reglas OLS, esos cambios solo afectarán al modelo compuesto cuando se actualice.

Pasos siguientes

Para más información acerca de DirectQuery, revise los siguientes recursos: