Usar modelos compuestos en Power BI Desktop

Anteriormente en Power BI Desktop, cuando se usaba DirectQuery en un informe, no se permitía usar ninguna otra conexión de datos en ese informe, ya fuese que se tratara de DirectQuery o importación. Con los modelos compuestos esa restricción ya no existe. Un informe puede incluir sin problemas conexiones de datos de más de una conexión de datos de DirectQuery o de importación, en la combinación de su preferencia.

La funcionalidad de modelos compuestos de Power BI Desktop consta de tres características relacionadas:

• Modelos compuestos: permiten que un informe tenga dos o más conexiones de datos de grupos de origen diferentes. Estos grupos de origen pueden ser una o varias conexiones de DirectQuery y una conexión de importación, dos o más conexiones de DirectQuery, o bien cualquier combinación de ellas. En este artículo se describen los modelos compuestos en detalle.

• Relaciones de varios a varios: con los modelos compuestos, puede establecer relaciones de varios a varios entre las tablas. Este enfoque elimina los requisitos de valores únicos en tablas. También permite descartar las soluciones alternativas anteriores, como el hecho de presentar nuevas tablas solo para establecer relaciones. Para más información, consulte Relaciones de varios a varios en Power BI Desktop.

• Modo de almacenamiento: ahora puede especificar los objetos visuales que consultan los orígenes de datos back-end. Esta característica permite mejorar el rendimiento y reducir la carga de back-end. Anteriormente, incluso los objetos visuales simples, como las segmentaciones, iniciaban consultas a los orígenes de back-end. Para más información, consulte Administración del modo de almacenamiento en Power BI Desktop.

Usar modelos compuestos

Con los modelos compuestos puede conectarse a diferentes clases de orígenes de datos al usar Power BI Desktop o el servicio Power BI. Puede realizar esas conexiones de datos de dos maneras:

• Mediante la importación de datos a Power BI, que es la manera más común para obtener datos.
• Mediante una conexión directa a los datos en su repositorio de origen inicial con DirectQuery. Para más información sobre DirectQuery, vea DirectQuery en Power BI.

Al usar DirectQuery, los modelos compuestos permiten crear un modelo de Power BI (como un archivo .pbix de Power BI Desktop único) que tiene como resultado una de las siguientes acciones o ambas:

• Combina los datos de uno o varios orígenes de DirectQuery.
• Combina los datos de orígenes de DirectQuery e importa los datos.

Por ejemplo, mediante el uso de modelos compuestos, puede crear un modelo que combine los siguientes tipos de datos:

• Datos de ventas de un almacenamiento de datos empresarial.
• Datos de objetivos de ventas de una base de datos de SQL Server departamental.
• Datos importados a partir de una hoja de cálculo.

Un modelo que combina datos de más de un origen de DirectQuery o que combina DirectQuery con datos importados se conoce como un modelo compuesto.

Puede crear relaciones entre las tablas como siempre, incluso cuando las tablas procedan de orígenes diferentes. Cualquier relación entre orígenes se crea con una cardinalidad de varios a varios, independientemente de su cardinalidad real. Puede cambiar a una cardinalidad de uno a varios, de varios a uno o de uno a uno. Sea cual sea la cardinalidad que se establezca, las relaciones entre orígenes tienen un comportamiento diferente. No se pueden usar las funciones de expresiones de análisis de datos (DAX) para recuperar valores en el lado one del lado many. Es posible que también observe un impacto en el rendimiento en comparación con las relaciones de varios a varios dentro del mismo origen.

Nota

En el contexto de los modelos compuestos, todas las tablas importadas son efectivamente un solo origen, independientemente del origen de datos.

Ejemplo de un modelo compuesto

Un ejemplo de modelo compuesto podría ser un informe que se conecte a un almacenamiento de datos corporativos en SQL Server mediante el uso de DirectQuery. En este caso, el almacenamiento de datos contiene datos de Sales by Country (Ventas por país), Quarter (Trimestre) y Bike (Product) (Bicicleta [Producto]), como se muestra en la siguiente imagen:

En este momento, podría crear objetos visuales sencillos con campos de este origen. La siguiente imagen muestra las ventas totales por ProductName para un trimestre seleccionado.

Pero, ¿qué ocurre si tiene datos en una hoja de cálculo de Excel sobre el administrador de productos asignado a cada artículo con la prioridad de marketing? Si quiere conocer el valor de Sales Amount (Cantidad de ventas) por Product Manager (Administrador de producto), es posible que no se puedan agregar estos datos locales en el almacenamiento de datos corporativos. O bien, en el mejor de los casos, se trata de una tarea que puede llevar meses.

Es posible importar los datos de ventas del almacenamiento de datos, en lugar de usar DirectQuery. Después, se podrían combinar los datos de ventas con los datos que haya importado desde la hoja de cálculo. Este enfoque es poco razonable, por los motivos que han llevado a usar DirectQuery en primer lugar. Los motivos pueden incluir:

• Alguna combinación de las reglas de seguridad aplicadas en el origen subyacente.
• Existencia de la necesidad de poder consultar los datos más recientes.
• Dimensiones de los datos, que pueden ser bastante grandes.

Aquí es donde aparecen los modelos compuestos. Los modelos compuestos le permiten conectarse al almacenamiento de datos mediante DirectQuery y luego usar Obtener datos para más orígenes. En este ejemplo, establecemos primero la conexión de DirectQuery al almacén de datos corporativos. Utilice Obtener datos, elija Excel y, después, vaya a la hoja de cálculo que contiene los datos locales. Por último, importe la hoja de cálculo que contiene los valores Product Names (Nombres de producto), Sales Manager (Administrador de ventas) asignado y Priority (Prioridad).

En la lista Campos, puede ver dos tablas: la tabla Bike (Bicicleta) original de SQL Server y una tabla ProductManagers nueva. La nueva tabla contiene los datos importados de Excel.

Del mismo modo, en la vista Relaciones de Power BI Desktop, ahora se ve otra tabla denominada ProductManagers (Administradores de productos).

Ahora necesitamos relacionar estas tablas con las otras en el modelo. Como siempre, creamos una relación entre la tabla Bike (Bicicleta) de SQL Server y la tabla ProductManagers importada. Es decir, la relación se establece entre Bike[ProductName] y ProductManagers[ProductName] . Como se ha explicado anteriormente, todas las relaciones entre el origen tienen la cardinalidad de varios a varios de forma predeterminada.

Una vez que se ha establecido esta relación, se muestra en la vista Relaciones en Power BI Desktop tal como se esperaría.

Ahora podemos crear objetos visuales mediante cualquiera de los campos de la lista Campos. Este enfoque combina sin problemas datos de varios orígenes. Por ejemplo, el valor SalesAmount (Cantidad de ventas) total para cada Product Manager (Administrador de productos) se muestra en la siguiente imagen:

En el ejemplo siguiente se muestra un caso común de una tabla de dimensiones, como Producto o Cliente, que se extiende con algunos datos adicionales que se importan desde otro lugar. También es posible hacer que las tablas usen DirectQuery para conectarse a diversos orígenes. Para continuar con el ejemplo, imaginemos que Sales Targets (Objetivos de ventas) por Country (País) y Period (Período) se almacenan en una base de datos departamental independiente. Como es habitual, puede usar Obtener datos para conectarse a esos datos, tal como se muestra en la siguiente imagen:

Como ha hecho antes, puede crear relaciones entre la tabla nueva y las demás tablas del modelo. Después, puede crear objetos visuales que combinen los datos de la tabla. Volvamos a examinar la vista Relaciones, donde establecimos relaciones nuevas:

La siguiente imagen se basa en los nuevos datos y las relaciones que hemos creado. El objeto visual en la esquina inferior izquierda muestra el valor Sales Amount (Cantidad de ventas) total frente a Target (Objetivo), mientras que el cálculo de la varianza muestra la diferencia. Los datos de Sales Amount (Cantidad de ventas) y Target (Objetivo) proceden de dos bases de datos de SQL Server diferentes.

Establecer el modo de almacenamiento

Cada tabla de un modelo compuesto tiene un modo de almacenamiento que indica si la tabla se basa en DirectQuery o en importación. El modo de almacenamiento se puede ver y modificar en el panel Propiedad. Para mostrar el modo de almacenamiento, haga clic en una tabla en la lista Campos y, después, seleccione Propiedades. En la siguiente imagen se muestra el modo de almacenamiento para la tabla SalesTargets (Objetivos de ventas).

El modo de almacenamiento también se puede ver en la información sobre herramientas de cada tabla.

En el caso de los archivos de Power BI Desktop (. .pbix) que contengan tablas DirectQuery e Importación, la barra de estado mostrará un modo de almacenamiento denominado Combinado. Puede seleccionar ese término en la barra de estado y cambiar fácilmente todas las tablas para la importación.

Para más información sobre el modo de almacenamiento, consulte Administración del modo de almacenamiento en Power BI Desktop.

Nota

Puede usar el modo de almacenamiento mixto en Power BI Desktop y en el servicio Power BI.

Tablas calculadas

Puede agregar tablas calculadas a un modelo en Power BI Desktop que use DirectQuery. Las expresiones de análisis de datos (DAX) que definen la tabla calculada pueden hacer referencia a cualquier tabla importada o de DirectQuery, o una combinación de ambas.

Las tablas calculadas siempre se importan y los datos se actualizan cuando se actualizan las tablas. Si una tabla calculada hace referencia a una tabla DirectQuery, los objetos visuales que hagan referencia a la tabla DirectQuery siempre mostrarán los valores más recientes en el origen subyacente. Como alternativa, los objetos visuales que hacen referencia a la tabla calculada muestran los valores en el momento de la última actualización de la tabla calculada.

Importante

Las tablas calculadas no son compatibles con el servicio Power BI con esta característica menos que cumpla requisitos específicos. Para obtener más información, consulte la sección Trabajo con un modelo compuesto basado en un modelo semántico de este artículo.

Implicaciones de seguridad

Los modelos compuestos tienen algunas implicaciones de seguridad. Una consulta enviada a un origen de datos puede incluir valores de datos que se han recuperado desde otro origen de datos. En el ejemplo anterior, el objeto visual que muestra Sales Amount (Cantidad de ventas) por Product Manager (Administrador de productos) envía una consulta SQL para la base de datos relacional Sales (Ventas). La consulta SQL puede contener los nombres de Product Managers (Administradores de producto) y sus productos asociados.

Por tanto, la información almacenada en la hoja de cálculo ahora se incluye en una consulta enviada a la base de datos relacional. Si esta información es confidencial, se deben considerar las implicaciones de seguridad. En concreto, tenga en cuenta lo siguiente:

• Cualquier administrador de la base de datos que pueda ver los seguimientos o registros de auditoría puede ver esta información, incluso sin permisos para los datos de su fuente original. En este ejemplo, el administrador necesitaría permisos para el archivo de Excel.

• Se debe considerar la configuración de cifrado para cada origen. Lo habitual es querer evitar tener que recuperar la información desde un origen mediante una conexión cifrada y, después, incluirla de forma accidental en una consulta enviada a otro origen mediante una conexión no cifrada.

Con el fin de permitir la confirmación de que se consideraron todas las implicaciones de seguridad, Power BI Desktop muestra un mensaje de advertencia cuando se realiza una acción para crear un modelo compuesto.

Además, si un autor agrega Table1 de Model A a un modelo compuesto (que se denomina Model C para referencia), un usuario que vea un informe basado en Model C podría consultar cualquier tabla de Model A que no esté protegida mediante la seguridad de nivel de fila (RLS).

Por motivos similares, se debe tener cuidado al abrir un archivo de Power BI Desktop enviado desde un origen que no es de confianza. Si el archivo contiene modelos compuestos, la información que alguien recupere de un origen, con las credenciales del usuario que abre el archivo, se enviará a otro origen de datos como parte de la consulta. El autor del archivo de Power BI Desktop malintencionado podría ver esta información. Por lo tanto, al abrir inicialmente un archivo de Power BI Desktop que contiene varios orígenes, Power BI Desktop muestra una advertencia. La advertencia es similar a la mostrada al abrir un archivo que incluye consultas SQL nativas.

Implicaciones de rendimiento

Siempre se debe considerar el rendimiento al usar DirectQuery, principalmente para garantizar que el origen de back-end tenga los recursos suficientes para proporcionar una buena experiencia para los usuarios. Para que la experiencia se considere buena, los objetos visuales deben actualizarse en cinco segundos o menos. Para más información sobre el rendimiento, vea DirectQuery en Power BI.

El uso de modelos compuestos agrega otras consideraciones de rendimiento. Un solo objeto visual puede producir que se envíen consultas a varios orígenes, lo que a menudo pasa los resultados de una consulta a un segundo origen. Esta situación puede generar las siguientes formas de ejecución:

• Consulta de origen con un gran número de valores literales: por ejemplo, un objeto visual que solicita el valor Cantidad de ventas total para un conjunto de Administradores de productos seleccionado primero tendría que determinar qué elementos Productos administraban. Esta secuencia debe realizase antes de que el objeto visual envíe una consulta SQL que incluya todos los identificadores de producto en una cláusula WHERE.

• Consulta de origen con un nivel de granularidad inferior y en la que los datos se agregan de forma local posteriormente: cuando el número de Productos que cumplen los criterios de filtro de Administrador de productos aumenta, puede resultar ineficaz o imposible incluir todos los productos en una cláusula WHERE. En su lugar, puede consultar el origen relacional en el nivel inferior de Product (Producto) y después agregar los resultados localmente. Si la cardinalidad de los Productos (Productos) supera un límite de 1 millón, la consulta generará un error.

• Varias consultas de origen, una por grupo por valor: cuando la agregación usa DistinctCount y se agrupa por una columna de otro origen, y si el origen externo no admite pasar de manera eficaz varios valores literales que definen la agrupación, es necesario enviar una consulta SQL por grupo por valor.

  Un objeto visual que solicita un recuento distinto de CustomerAccountNumber de la tabla de SQL Server por Administradores de productos importados de la hoja de cálculo necesitaría pasar los detalles de la tabla Administradores de productos en la consulta enviada a SQL Server. Esta acción es inviable a través de otros orígenes, por ejemplo, Redshift. En su lugar, habría una consulta SQL enviada por el administrador de ventas, hasta algún límite práctico, momento en el cual se generaría un error en la consulta.

Cada uno de estos casos tiene sus propias implicaciones en el rendimiento y los detalles exactos varían en función de cada origen de datos. Aunque la cardinalidad de las columnas usadas en la relación que combina ambos orígenes permanece baja (unos pocos miles), el rendimiento no debería verse afectado. A medida que crece esta cardinalidad, debe prestar más atención a la repercusión en el rendimiento resultante.

Además, el uso de las relaciones de varios a varios significa que se deben enviar consultas independientes al origen subyacente de cada nivel total o subtotal, en lugar de agregar localmente los valores detallados. Un objeto visual de tabla simple con totales podría enviar dos consultas de origen en lugar de una.

Grupos de origen

Un grupo de origen es una colección de elementos como tablas y relaciones, de un origen de DirectQuery o de todos los orígenes de importación implicados en un modelo de datos. Un modelo compuesto está formado por uno o varios grupos de origen. Considere los siguientes ejemplos:

• Un modelo compuesto que se conecta a un modelo semántico de Power BI llamado Ventas y enriquece el modelo semántico agregando una medida de Ventas YTD, que no está disponible en el modelo semántico original. Este modelo consta de un grupo de origen.
• Un modelo compuesto que combina datos importando una tabla de una hoja Excel llamada Objetivos y un archivo CSV llamado Regiones, y realizando una conexión DirectQuery a un modelo semántico de Power BI llamado Ventas. En este caso, hay dos grupos de origen, como se muestra en la siguiente imagen:
  • El primer grupo de origen contiene las tablas de la hoja de Excel Destinos y el archivo CSV Regiones.
  • El segundo grupo de origen contiene los elementos del modelo semántico de Power BI de Ventas.

Si agregó otra conexión de DirectQuery a otro origen, como una conexión de DirectQuery a una base de datos de SQL Server denominada Inventario, los elementos de ese origen se agregan a otro grupo de origen:

Nota:

La importación de datos desde otro origen no agregará otro grupo de origen, ya que todos los elementos de todos los orígenes importados se encuentran en un grupo de origen.

Grupos de origen y relaciones

Hay dos tipos de relaciones en un modelo compuesto:

• Relaciones intragrupo de origen. Estas relaciones relacionan elementos dentro de un grupo de origen juntos. Estas relaciones siempre son normales a menos que sean de varios a varios, en cuyo caso están limitadas.
• Relaciones entre grupos de origen. Estas relaciones comienzan en un grupo de origen y terminan en un grupo de origen diferente. Estas relaciones siempre son relaciones limitadas.

Obtenga más información sobre la distinción entre las relaciones normales y limitadas y su impacto.

Por ejemplo, en la imagen siguiente, se han agregado tres relaciones entre grupos de origen, que relacionan tablas entre los distintos grupos de origen:

Local y remoto

Cualquier elemento de un grupo de origen que sea de DirectQuery se considera remoto, a menos que el elemento se haya definido localmente como parte de una extensión o enriquecimiento del origen de DirectQuery y no forme parte del origen remoto, como una medida o una tabla calculada. Una tabla calculada basada en una tabla del grupo de origen DirectQuery pertenece al grupo de origen "Import" y se considera local. Cualquier elemento que se encuentra en el grupo de origen "Importar" se considera local. Por ejemplo, si define la siguiente medida en un modelo compuesto que usa una conexión DirectQuery al origen de inventario, la medida se considera local:

[Average Inventory Count] = Average(Inventory[Inventory Count])

Grupos de cálculo, consulta y evaluación de medidas

Los grupos de cálculo proporcionan una manera de reducir el número de medidas redundantes y de agrupar expresiones de medida comunes. Los casos de uso típicos son los cálculos de inteligencia de tiempo en los que quiere poder cambiar de los cálculos actuales a los de mes a fecha, trimestre a fecha o año a fecha. Al trabajar con modelos compuestos, es importante tener en cuenta la interacción entre los grupos de cálculo y si una medida solo hace referencia a elementos de un único grupo de origen remoto. Si una medida solo hace referencia a elementos de un único grupo de origen remoto y el modelo remoto define un grupo de cálculo que afecta a la medida, ese grupo de cálculo se aplica, aunque si la medida se haya definido en el modelo remoto o en el modelo local. Pero si una medida no hace referencia a elementos de un único grupo de origen remoto exclusivamente, sino a elementos de un grupo de origen remoto en el que se aplica un grupo de cálculo remoto, los resultados de la medida podrían verse afectados por el grupo de cálculo remoto. Considere el ejemplo siguiente:

• Ventas de revendedor es una medida definida en el modelo remoto.
• El modelo remoto contiene un grupo de cálculo que cambia el resultado de Ventas de revendedor
• Ventas por Internet es una medida definida en el modelo local.
• Ventas totales es una medida definida en el modelo local y tiene la siguiente definición:

[Total Sales] = [Internet Sales] + [Reseller Sales]

En este escenario, la medida Ventas por Internet no se ve afectada por el grupo de cálculo definido en el modelo remoto, ya que no forma parte del mismo modelo. Pero el grupo de cálculo puede cambiar el resultado de la medida Ventas de revendedor, ya que está en el mismo modelo. Este dato significa que los resultados devueltos por la medida Ventas totales se deben evaluar cuidadosamente. Imagine que usamos el grupo de cálculo en el modelo remoto para devolver resultados de año a fecha. El resultado devuelto por Ventas de revendedor es ahora un valor anual a fecha, mientras que el resultado devuelto por Ventas por Internet sigue siendo actual. El resultado de Ventas totales ahora es inesperado, ya que agrega un resultado actual a un resultado anual a la fecha.

Modelos compuestos en modelos semánticos de Power BI y Analysis Services

Uso de modelos compuestos con modelos semánticos de Power BI y Analysis Services, puede crear un modelo compuesto utilizando una conexión DirectQuery para conectarse a modelos semánticos de Power BI, Azure Analysis Services (AAS) y SQL Server 2022 Analysis Services. Con un modelo compuesto, puede combinar los datos de estos orígenes con otros datos de DirectQuery e importados. Esta función 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.

Administración de modelos compuestos en modelos semánticos de Power BI

Para permitir la creación y el consumo de modelos compuestos en modelos semánticos de Power BI, su inquilino debe tener habilitados los siguientes conmutadores:

• Permitir puntos de conexión XMLA y analizar en Excel con modelos semánticos locales. Si este interruptor está deshabilitado no se puede realizar una conexión DirectQuery a un modelo semántico de Power BI.
• Los usuarios pueden trabajar con modelos semánticos de Power BI en Excel mediante una conexión dinámica. Si este conmutador está deshabilitado, los usuarios no pueden realizar conexiones dinámicas con los modelos semánticos de Power BI, por lo que no se puede acceder al botón Realizar cambios en este modelo.
• Permitir la conexión DirectQuery a los modelos semánticos de Power BI. Consulte los párrafos siguientes para obtener más información sobre este conmutador y el efecto que tiene la acción de deshabilitarlo.

Además, para las capacidades Premium y Premium por usuario, la opción de "Punto de conexión XMLA" debe habilitarse y establecerse en "Solo lectura" o "Lectura y escritura".

Los administradores de inquilinos pueden habilitar o deshabilitar las conexiones DirectQuery a los modelos semánticos de Power BI en el portal de administración. Aunque esta opción está habilitada por defecto, si se deshabilita, los usuarios dejarán de publicar nuevos modelos compuestos en los modelos semánticos de Power BI en el servicio.

Los informes existentes que usan un modelo compuesto en un modelo semántico de Power BI siguen funcionando y los usuarios podrán seguir creando el modelo compuesto en el uso de Desktop, pero no pueden publicar en el servicio. En cambio, cuando cree una conexión DirectQuery con el modelo semántico de Power BI seleccionando Realizar cambios en este modelo, verá el siguiente mensaje de advertencia:

De este modo, podrá seguir explorando el modelo semántico en su entorno local de Power BI Desktop y crear el modelo compuesto. Sin embargo, no puede publicar el informe en el servicio. Al publicar el informe y el modelo, verá el mensaje de error siguiente y se bloquea la publicación:

El cambio no afecta a las conexiones activas con los modelos semánticos de Power BI, ni a las conexiones dinámicas o DirectQuery con Analysis Services. Estas siguen funcionando independientemente de si la opción se desactivó. Además, cualquier informe publicado que use un modelo compuesto en un modelo semántico de Power BI seguirá funcionando aunque se haya desactivado el interruptor después de su publicación.

Crear un modelo compuesto sobre un modelo semántico o un modelo

Crear un modelo compuesto sobre un modelo semántico de Power BI o un modelo de Analysis Services requiere que su 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 Analysis Services, verá un mensaje similar a la imagen siguiente:

Si está conectado a un modelo semántico de Power BI, verá un mensaje que le indica a qué modelo semántico de Power BI está conectado:

Si desea personalizar los metadatos de los campos de su modelo semántico conectado en directo, seleccione Realizar cambios en este modelo en la barra de estado. Como alternativa, puede seleccionar 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.

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 nuevas columnas o la modificación de los metadatos, para los campos de los modelos semánticos de Power BI o Analysis Services. En la imagen siguiente se muestra el cuadro de diálogo.

Cuando establece una conexión dinámica a un origen de Analysis Services, no hay ningún modelo local. Para utilizar DirectQuery para los orígenes conectados en directo, como los modelos semánticos de Power BI y Analysis Services, debe agregar un modelo local a su informe. Cuando se publica un informe con un modelo local en el servicio Power BI, también se publica un modelo semántico para ese modelo local.

Encadenamiento

Los modelos semánticos y los modelos semánticos en los que se basan forman una cadena. Este proceso, denominado encadenamiento, permite publicar un informe y un modelo semántico basado en otros modelos semánticos de Power BI, una función que antes no era posible.

Por ejemplo, imagine que su colega publica un modelo semántico de Power BI llamado Ventas y Presupuesto basado en un modelo de Analysis Services llamado Ventas, y lo combina con una hoja de Excel llamada Presupuesto.

Cuando usted publica un nuevo informe (y modelo semántico) llamado Ventas y Presupuesto de Europa basado en el modelo semántico de Power BI Ventas y Presupuesto publicado por su colega, haciendo algunas modificaciones o extensiones al hacerlo, usted está agregando efectivamente un informe y modelo semántico a una cadena de longitud tres, que comenzó con el modelo de Servicios de Análisis de Ventas, y termina con su modelo semántico de Power BI Ventas y Presupuesto de Europa. En la imagen siguiente se muestra este proceso de encadenamiento.

La cadena de la imagen anterior tiene una longitud de tres, que es la máxima longitud permitida. No se permite ir más allá de una cadena con longitud de tres, ya que generaría un error.

Permisos y licencias

Los usuarios que acceden a los informes mediante un modelo compuesto deben tener los permisos adecuados para todos los modelos semánticos y modelos de la cadena.

El propietario del modelo compuesto requiere permiso de compilación en los modelos semánticos usados como orígenes para que otros usuarios puedan acceder a esos modelos en nombre del propietario. Como resultado, la creación de la conexión de modelo compuesto en Power BI Desktop o la creación del informe en Power BI requieren permisos de compilación en los modelos semánticos usados como orígenes.

Los usuarios que ven informes mediante el modelo compuesto normalmente requerirán permisos de lectura en el propio modelo compuesto y los modelos semánticos usados como orígenes. Los permisos de compilación pueden ser necesarios si los informes están en un área de trabajo Pro. Estos modificadores de inquilino deben estar habilitados para el usuario.

Los permisos necesarios se pueden ilustrar con el ejemplo siguiente:

• Modelo compuesto A (propiedad del propietario A)

  • Origen de datos A1: modelo semántico B.
    El propietario A debe tener permiso de compilación en el modelo semántico B para que los usuarios vean el informe mediante el modelo compuesto A.

• Modelo compuesto C (propiedad del propietario C)

  • Origen de datos C1: modelo semántico D
    El propietario C debe tener permiso de compilación en el modelo semántico D para que los usuarios vean el informe mediante el modelo compuesto C.
  • Origen de datos C2: modelo compuesto A
    El propietario C debe tener permiso de compilación en el modelo compuesto A y permiso de lectura en el modelo semántico B.

Un usuario que vea los informes mediante el modelo compuesto A debe tener permisos de lectura para el modelo compuesto A y el modelo semántico B, mientras que un usuario que vea los informes mediante el modelo compuesto C debe tener permisos de lectura en el modelo compuesto C, el modelo semántico D, el modelo compuesto A y el modelo semántico B.

Nota:

Consulte este blogpost para obtener información importante sobre los permisos necesarios para los modelos compuestos en los modelos semánticos de Power BI y los modelos de Analysis Services.

Si algún conjunto de datos de la cadena está en un área de trabajo Premium por usuario, el usuario que accede a él necesita una Licencia Premium por usuario. Si algún conjunto de datos de la cadena está en un área de trabajo Pro, el usuario que accede a él necesita una licencia Pro. Si todos los conjuntos de datos de la cadena están en capacidades Premium o una capacidad de Fabric F64 o superior, un usuario puede acceder a él mediante una licencia gratuita.

Advertencia de seguridad

El uso de la característica Modelos compuestos en modelos semánticos de Power BI y modelos de Analysis Servicesle presenta un cuadro de diálogo de advertencia de seguridad, que se muestra en la imagen siguiente.

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.

Escenarios admitidos

Puede crear modelos compuestos utilizando datos de modelos semánticos de Power BI o modelos de Analysis Services para dar servicio a los siguientes escenarios:

• Conexión a datos de diversas fuentes: Importación (como archivos), modelos semánticos de Power BI, modelos de Analysis Services
• Crear relaciones entre distintos orígenes de datos.
• Escribir medidas que usen campos de distintos orígenes de datos.
• Creación de nuevas columnas para tablas a partir de modelos semánticos de Power BI o modelos de Analysis Services
• Crear objetos visuales que usen columnas de distintos orígenes de datos.
• Con la lista de campos, puede quitar una tabla del modelo a fin de 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. Consulte Carga de un subconjunto de tablas más adelante en este documento.
• Puede especificar si desea agregar cualquier tabla que se agregue más adelante al modelo semántico después de realizar la conexión en su modelo.

Trabajar con un modelo compuesto basado en un modelo semántico

Cuando trabaje con modelos semánticos DirectQuery for Power BI y Analysis Services, tenga en cuenta la siguiente información:

• 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.

• No se pueden editar, eliminar o crear nuevas relaciones en el mismo modelo semántico de Power BI o fuente de Analysis Services. Si tiene acceso de edición a estos orígenes, en su lugar puede realizar los cambios directamente en el origen de datos.

• No se pueden cambiar los tipos de datos de las columnas que se cargan desde un modelo semántico de Power BI o una fuente de Analysis Services. Si necesita cambiar el tipo de datos, cámbielo en el origen o use una columna calculada.

• Para crear informes en el servicio Power BI sobre un modelo compuesto basado en otro modelo semántico, deben establecerse todas las credenciales.

• Las conexiones a un servidor local de Analysis Services de SQL Server 2022 y versiones posteriores o IaaS necesitan una puerta de enlace de datos local (modo Estándar).

• Todas las conexiones a los modelos semánticos remotos de Power BI se realizan utilizando el inicio de sesión único. Actualmente, no se admite la autenticación con una entidad de servicio.

• Las reglas RLS se aplican en la fuente en la que se definan, pero no se aplican a ningún otro modelo semántico del modelo. La RLS definida en el informe no se aplica a los orígenes remotos y la RLS establecida en orígenes remotos no se aplica a otros orígenes de datos. Además, no puede definir RLS en una tabla cargada desde un origen remoto y la RLS definida en tablas locales no filtra las tablas cargadas desde un origen remoto.

• Los KPI, la seguridad de nivel de fila y las traducciones no se importan desde el origen.

• 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):

  

  Para más información sobre el uso de columnas de fecha frente a jerarquías de fechas, consulte Aplicación de la fecha u hora automáticas en Power BI Desktop.

• 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. Para más información, vea Administración de conexiones de DirectQuery a un modelo semántico publicado.

• La conexión a un modelo semántico de Power BI o a un modelo de Analysis Services no se muestra en Power Query.

Las siguientes limitaciones se aplican cuando se trabaja con modelos semánticos DirectQuery for Power BI y Analysis Services:

• 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:
  • Modelos tabulares de SQL Server Analysis Services (SSAS) anteriores a la versión 2022
  • Modelos multidimensionales de SSAS
  • SAP HANA
  • SAP Business Warehouse
  • Modelos semánticos en tiempo real
  • Ejemplos de modelos semánticos
  • Ponerse al día con Excel Online
  • Datos importados desde archivos de Excel o CSV al servicio
  • Métricas de uso
  • Modelos semánticos almacenados en "Mi área de trabajo"
• Actualmente no es posible utilizar Power BI Embedded con modelos semánticos que incluyan una conexión DirectQuery a un modelo de Analysis Services.
• No se admite la publicación de un informe en la Web mediante la característica Publicar en la Web.
• No se admiten grupos de cálculo en orígenes remotos, con resultados de consulta no definidos.

• Las tablas calculadas y las columnas calculadas que hacen referencia a una tabla DirectQuery desde un origen de datos con autenticación de inicio de sesión único (SSO) son compatibles con el servicio Power BI con una conexión en la nube compartida asignada o control de acceso granular.

• Si cambia el nombre de un área de trabajo después de configurar la conexión de DirectQuery, debe actualizar el origen de datos en Power BI Desktop para que el informe siga funcionando.
• 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 transferencia de un modelo semántico que utiliza la característica DirectQuery a otros modelos semánticos.
• Al igual que con cualquier fuente de datos DirectQuery, las jerarquías definidas en un modelo de Analysis Services o en un modelo semántico de Power BI no se muestran cuando se conecte al modelo o al modelo semántico en modo DirectQuery utilizando Excel.

Hay algunas otras cosas a tener en cuenta cuando se trabaja con DirectQuery para modelos semánticos de Power BI y Analysis Services:

• Usar columnas de baja cardinalidad en relaciones entre grupos de origen: al crear una relación entre dos grupos de origen diferentes, las columnas que participan en la relación (también denominadas columnas de combinación) deben tener una baja cardinalidad, idealmente 50 000 o menos. Esta consideración se aplica a columnas de clave que no sean de cadena; para las columnas de clave de cadena, consulte la siguiente consideración.
• Evitar utilizar columnas de clave de cadenas grandes en relaciones entre grupos de origen: al crear una relación entre grupos de origen, evite usar columnas de cadena grandes como columnas de relación, especialmente para las columnas que tienen una mayor cardinalidad. Cuando tenga que utilizar columnas de cadenas como columna de relación, calcule la longitud de cadena esperada para el filtro multiplicando la cardinalidad (C) por la longitud media de la columna de cadena (A). Asegúrese de que la longitud de cadena esperada sea inferior a 250 000, de modo que A ∗ C < 250 000.

Para obtener más consideraciones e instrucciones, consulte la guía del modelo compuesto.

Consideraciones sobre inquilinos

Cualquier modelo con una conexión DirectQuery a un modelo semántico de Power BI o a Analysis Services debe publicarse en el mismo inquilino, lo que es especialmente importante cuando se accede a un modelo semántico de Power BI o a un modelo de Analysis Services utilizando identidades invitadas B2B, como se muestra en el siguiente diagrama. 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.

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 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 modelo semántico publicado en el inquilino de Contoso no puede autenticarse correctamente contra el modelo de Analysis Services de Fabrikam (paso 3). Como resultado, el informe no funciona.

En este escenario, como el modelo de Analysis Services utilizado se hospeda en el inquilino de Fabrikam, el informe también se debe publicar en el inquilino de Fabrikam. Tras la publicación correcta en el inquilino de Fabrikam (paso 4), el modelo semántico puede acceder correctamente al modelo de Analysis Services (paso 5) y el informe funciona correctamente.

Trabajar con seguridad de nivel de objeto

Cuando un modelo compuesto obtiene datos de un modelo semántico de Power BI o de Analysis Services a través de DirectQuery, y ese modelo de origen está protegido por seguridad a nivel de objeto, los consumidores del modelo compuesto pueden notar 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 se crea un modelo compuesto sobre un modelo semántico de Power BI protegido por OLS o un modelo de Analysis Services a través de una conexión DirectQuery, el esquema del modelo de origen 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 ven los datos reales que no deberían ver, porque los datos no se encuentran en el modelo compuesto. En cambio, gracias a DirectQuery, se recupera según sea necesario del modelo semántico de origen, donde OLS bloquea el acceso no autorizado.

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

1. Admin_user publicó un modelo semántico de empresa utilizando un modelo semántico de Power BI o un modelo de Analysis Services que tiene una tabla Cliente y una tabla Territorio. Admin_user publica el modelo semántico en el servicio Power BI y establece reglas OLS que tienen el siguiente efecto:

   • 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 modelo semántico llamado "Modelo semántico financiero" y un informe llamado "Informe financiero" que se conecta mediante DirectQuery al modelo semántico de empresa 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 llamado "Informe de Marketing" que utiliza el modelo semántico de Finanzas como fuente. 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 ocurre cuando Marketing_user crea un nuevo modelo semántico y un informe que se conectan al modelo semántico de Finanzas con una conexión DirectQuery, ven la tabla Territorio en la lista de campos, ya que eso es lo que Finance_user podría ver, pero cuando intentan crear un visual que use esa tabla, son bloqueados por las reglas OLS en el modelo semántico de la empresa.

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. Las reglas OLS actualizadas solo se reflejan en el modelo semántico de Finanzas cuando se actualiza. Así, cuando Finance_user actualice el modelo semántico de Finanzas, la tabla Territorio ya no se mostrará en la lista de campos, y el visual del informe de Finanzas que utilice una columna de la tabla Territorio devuelve un error a Finance_user, porque ahora no se le permite acceder a la tabla Territorio.

En resumen:

• 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 muestra 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 modelo compuesto mismo.
• 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 bloquea cuando DirectQuery intente recuperar los datos con sus credenciales.
• Si el modelo de origen actualiza sus reglas OLS, esos cambios solo afectan al modelo compuesto cuando se actualice.

Carga de un subconjunto de tablas de un modelo semántico de Power BI o de un modelo de Analysis Services

Cuando se conecta a un modelo semántico de Power BI o a un modelo de Analysis Services mediante una conexión DirectQuery, puede decidir a qué tablas conectarse. También puede elegir agregar de forma automática cualquier tabla que pueda agregarse al modelo semántico o al modelo después de realizar la conexión con su modelo. Cuando se conecte a una perspectiva, su modelo contiene todas las tablas del modelo semántico y se ocultan las tablas no incluidas en la perspectiva. Además, todas las tablas que se puedan agregar a la perspectiva lo hacen automáticamente. En el menú Configuración, puede decidir conectarse automáticamente a las tablas que se agreguen al modelo semántico después de configurar la conexión por primera vez.

Este cuadro de diálogo no se muestra para las conexiones dinámicas.

Nota:

Este cuadro de diálogo solo se mostrará si agrega una conexión DirectQuery a un modelo semántico de Power BI o un modelo de Analysis Services a un modelo existente. También puede abrir este cuadro de diálogo cambiando la conexión DirectQuery al modelo semántico de Power BI o al modelo de Analysis Services en la configuración de Origen de datos después de crearlo.

Configuración de reglas de desduplicación

Puede especificar reglas de deduplicación para mantener los nombres de medidas y tablas únicos en un modelo compuesto utilizando la opción Configuración del cuadro de diálogo mostrado anteriormente:

En el ejemplo anterior, agregamos " (marketing)" como sufijo a cualquier nombre de tabla o medida que esté en conflicto con otra fuente en el modelo compuesto. Puede:

• escribir un texto que se agregará al nombre de las tablas o medidas en conflicto
• especificar si desea que el texto se agregue a la tabla o al nombre de medida como prefijo o sufijo
• aplicar la regla de desduplicación a tablas, medidas o ambas
• Elija aplicar la regla de desduplicación solo cuando se produzca un conflicto de nombres o aplíquela todo el tiempo. El valor predeterminado es aplicar la regla solo cuando se produce la duplicación. En nuestro ejemplo, cualquier tabla o medida del origen de marketing que no tenga un duplicado en el origen de ventas no recibe un cambio de nombre.

Después de realizar las conexiones y configurar la regla de desduplicación, la lista de campos mostrará "Cliente" y "Cliente (marketing)" según la regla de desduplicación configurada en nuestro ejemplo:

Si no especifica una regla de desduplicación o las reglas de desduplicación especificadas no resuelven el conflicto de nombres, las reglas de desduplicación estándar se seguirán aplicando. Las reglas de desduplicación estándar agregan un número al nombre de un elemento en conflicto. Si hay un conflicto de nombres en la tabla "Cliente" una de las tablas "Cliente" se cambia el nombre "Cliente 2".

Modificaciones de XMLA y modelos compuestos

Al cambiar un modelo semántico mediante XMLA, debe actualizar la colección ChangedProperties y PBI_RemovedChildren para que el objeto modificado incluya las propiedades modificadas o eliminadas. Si no realiza esa actualización, las herramientas de modelado de Power BI podrían sobrescribir los cambios la próxima vez que el esquema se sincronice con su instancia de Lakehouse asociada.

Los modelos admitidos para cambiar un modelo semántico mediante XMLA son los siguientes:

• Cambio de nombre de tabla o columna (ChangeProperty = nombre)
• Quitar tabla (agregar tabla a PBI_RemovedChildren anotación en la expresión de consulta)

Consideraciones y limitaciones

Los modelos compuestos presentan algunas consideraciones y limitaciones:

Conexiones de modo mixto: cuando utilice una conexión de modo mixto que contenga datos en línea (como un modelo semántico de Power BI) y un modelo semántico local (como un libro de Excel), debe tener establecida una asignación de pasarela para que los visuales aparezcan correctamente.

En estos momentos, la actualización incremental solo es compatible con modelos compuestos que se conectan con orígenes de datos de SQL, Oracle y Teradata.

Los orígenes tabulares de Live Connect siguientes no se pueden usar con modelos compuestos:

• SAP HANA
• SAP Business Warehouse
• SQL Server Analysis Services anterior a la versión 2022
• Métricas de uso (Mi área de trabajo)

No se admite el uso de modelos semánticos de flujo continuo en modelos compuestos.

Las limitaciones existentes de DirectQuery siguen aplicándose cuando se usan los modelos compuestos. Muchas de esas limitaciones son ahora por tabla, en función del modo de almacenamiento de la tabla. Por ejemplo, una columna calculada en una tabla de importación puede hacer referencia a otras tablas que no están en DirectQuery, pero una columna calculada en una tabla DirectQuery puede hacer referencia solo a columnas de la misma tabla. Otras limitaciones se aplican al modelo como un todo, si cualquiera de las tablas dentro del modelo son DirectQuery. Por ejemplo, la característica Conclusiones rápidas no está disponible en un modelo si cualquiera de las tablas que este incluye tiene un modo de almacenamiento de DirectQuery.

Si usa la seguridad de nivel de fila en un modelo compuesto con algunas de las tablas en modo DirectQuery, debe actualizar el modelo para aplicar nuevas actualizaciones de las tablas de DirectQuery. Por ejemplo, si una tabla Users en el modo DirectQuery tiene nuevos registros de usuario en el origen, los nuevos registros solo se incluirán después de la siguiente actualización del modelo. El servicio Power BI almacena en caché la consulta Users para mejorar el rendimiento y no vuelve a cargar los datos del origen hasta la siguiente actualización manual o programada.

Contenido relacionado

Para obtener más información sobre los modelos compuestos y DirectQuery, consulte los siguientes artículos:

• Aplicación de relaciones de varios a varios en Power BI Desktop
• Administración del modo de almacenamiento en Power BI Desktop
• DirectQuery en Power BI
• Orígenes de datos de Power BI
• Relaciones de modelos en Power BI Desktop