Uso de modelos compuestos en Power BI

Los modelos semánticos de Power BI pueden incluir tablas de uno o varios orígenes de datos mediante cualquiera de los modos de almacenamiento de tablas admitidos. Cuando las tablas usan diferentes modos de almacenamiento, el modelo es un modelo semántico compuesto. Para el modo de almacenamiento de tablas de DirectQuery, el modelo se compone cuando las tablas de DirectQuery usan orígenes de datos diferentes.

Por ejemplo, si se conecta a otro modelo semántico de Power BI mediante DirectQuery (que agrega tablas en modo de almacenamiento directQuery) y también tiene tablas locales en modo de importación, el modelo se convierte en un modelo compuesto porque contiene tablas con diferentes modos de almacenamiento.

Tipos de modelos compuestos

Existen diferentes tipos de modelos compuestos en función de la combinación de modos de almacenamiento de tablas en el modelo semántico. Cada tipo tiene sus propias consideraciones para la funcionalidad y las herramientas.

Creación de modelos compuestos en Power BI Desktop

En Power BI Desktop, puede crear modelos semánticos con tablas de importación o DirectQuery localmente. A continuación, puede agregar más tablas desde el botón obtener datos de la cinta de opciones en el otro modo de almacenamiento para crear un modelo compuesto.

Agregar tablas de DirectQuery desde otro modelo semántico de Power BI tiene varias rutas diferentes de creación.

1. En un archivo de Power BI en blanco, primero conéctese al modelo semántico de Power BI. Una vez conectado en directo, tiene la opción de realizar cambios en este modelo. Al seleccionar Realizar cambios en este modelo en la cinta de opciones o pie de página, se convierte la conexión dinámica a una conexión directQuery. La conexión de DirectQuery crea un nuevo modelo semántico local con las tablas en modo de almacenamiento de DirectQuery. Puede agregar nuevas tablas en el modo de almacenamiento import o DirectQuery, así como proporcionar la opción de invalidar algunas propiedades de columna en el modelo semántico de origen.

2. En un modelo semántico con tablas de importación o DirectQuery ya, conéctese a un modelo semántico de Power BI y las tablas que elija se agreguen como DirectQuery.

Los modelos semánticos creados con tablas de Direct Lake se editan en directo en Power BI Desktop. Puede agregar más tablas de Direct Lake. Para agregar tablas de importación, abra el modelo semántico en el modelado web de Power BI. Para agregar tablas DirectQuery, use XMLA.

Puede editar dinámicamente un modelo semántico de Direct Lake e importarlo en Escritorio, pero no puede agregar más tablas. Solo puede agregar tablas desde el modelado web de Power BI para Direct Lake e importar modelos compuestos.

Creación de modelos compuestos en el modelado web

En el modelado web de Power BI, puede crear modelos semánticos con tablas de importación o Direct Lake. No se pueden agregar tablas de DirectQuery. Puede agregar más tablas en el otro modo de almacenamiento para crear un modelo compuesto.

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 semántico que combina tablas de más de un origen de DirectQuery, o que combina tablas de DirectQuery, Direct Lake e importación es un modelo semántico 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.

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. Puede ver y modificar el modo de almacenamiento en el panel Propiedades . Para ver el modo de almacenamiento:

1. En la vista Modelo , seleccione la tabla.
2. En el panel Propiedades , expanda la sección Opciones avanzadas y, a continuación, expanda la lista Modo de almacenamiento .

También puede ver el modo de almacenamiento en el tooltip de cada tabla al pasar el cursor sobre ella en el panel Datos.

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.

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 sus datos se actualizan al actualizar 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.

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 recuperan de otro origen. En el ejemplo anterior, el objeto visual que muestra (Sales Amount) by Product Manager envía una consulta SQL a la base de datos relacional Sales. 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 seguimientos o registros de auditoría puede ver esta información, incluso sin permisos para los datos de su origen original. En este ejemplo, el administrador necesita permisos para el archivo de Excel.

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

Para confirmar que ha considerado cualquier implicaciones de seguridad, Power BI Desktop muestra un mensaje de advertencia al crear un modelo compuesto.

Además, si un autor agrega Table1 del modelo A a un modelo compuesto (vamos a llamarlo Modelo C como referencia), un usuario que ve un informe basado en el modelo C podría consultar cualquier tabla del modelo A que no esté protegida por 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 recupera de un origen, mediante las credenciales del usuario que abre el archivo, se envía a otro origen de datos como parte de la consulta. El autor malintencionado del archivo de Power BI Desktop podría ver la 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

Al usar DirectQuery, considere siempre el rendimiento. Asegúrese de que el origen de back-end tiene suficientes recursos 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 enviar consultas a varios orígenes. A menudo, una consulta pasa sus resultados a un segundo origen. Esta situación puede generar las siguientes formas de ejecución:

• Consulta de origen que incluye un gran número de valores literales: por ejemplo, un objeto visual que solicita importe de ventas total para un conjunto de administradores de productos seleccionados primero tendría que buscar qué productos administran esos administradores de productos. Esta secuencia debe producirse antes de que el objeto visual envíe una consulta SQL que incluya todos los identificadores de producto en una WHERE cláusula .

• 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 mediante una columna de otro origen, y si el origen externo no admite el paso eficaz de muchos valores literales que definen la agrupación, debe enviar una consulta SQL por grupo por valor.

  Objeto visual que solicita un recuento distinto de CustomerAccountNumber de la tabla SQL Server para los Product Managers que se importan de la hoja de cálculo. Es necesario pasar los detalles de la tabla de Product Managers 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 los dos orígenes sigue siendo baja (unos pocos miles), el rendimiento no debería verse afectado. A medida que crece esta cardinalidad, preste más atención al impacto 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 visual de tabla simple con totales realiza 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 agrega otra conexión 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 como otro grupo de origen:

Grupos de origen y relaciones

Un modelo compuesto tiene dos tipos de relaciones:

• Relaciones intragrupo de origen. Estas relaciones conectan elementos dentro de un grupo de origen. 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 siguiente imagen, agregamos tres relaciones entre grupos de origen, en las que se relacionan las tablas entre los distintos grupos de origen:

Local y remoto

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

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

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

Los grupos de cálculo ayudan a reducir el número de medidas redundantes y agrupar expresiones de medida comunes. Los casos de uso típicos son los cálculos de inteligencia de tiempo en los que desea cambiar de los valores reales a cálculos desde el inicio del mes, desde el inicio del trimestre, o desde el inicio del año. 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, se aplica el grupo de cálculo, incluso si define la medida en el modelo remoto o en el modelo local. Sin embargo, si una medida no hace referencia exclusivamente a elementos de un único grupo de origen remoto, pero hace referencia 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 Reseller Sales.
• 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 Internet Sales no se ve afectada por el grupo de cálculo definido en el modelo remoto porque no forman parte del mismo modelo. Sin embargo, el grupo de cálculo puede cambiar el resultado de la medida Reseller Sales , ya que están en el mismo modelo. Este dato significa que los resultados devueltos por la medida Ventas totales se deben evaluar cuidadosamente. Imagine que usa 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

Mediante el uso de modelos compuestos con modelos semánticos de Power BI y Analysis Services, puede crear un modelo compuesto mediante 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. Los autores de informes que desean combinar los datos de su modelo semántico empresarial con otros datos que poseen, como una hoja de cálculo de Excel, o que desean personalizar o enriquecer los metadatos de su modelo semántico empresarial, encuentran esta funcionalidad especialmente útil.

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

Para crear y usar modelos compuestos en modelos semánticos de Power BI, su entorno debe tener habilitados los siguientes conmutadores:

• Permitir puntos de conexión XMLA y analizar en Excel con modelos semánticos locales. Si deshabilita este interruptor, no 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 deshabilita este modificador, los usuarios no pueden realizar conexiones dinámicas a modelos semánticos de Power BI para que el botón Realizar cambios en este modelo no esté disponible.
• 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 configuración "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 configuración está habilitada de forma predeterminada, deshabilitarla impide que los usuarios publiquen nuevos modelos compuestos en 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. Los usuarios todavía pueden crear el modelo compuesto en Power BI Desktop, pero no pueden publicarlo en el servicio. En su lugar, al crear una conexión directQuery al modelo semántico de Power BI, seleccione 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, usted no puede publicar el informe en el servicio. Al publicar el informe y el modelo, verá el siguiente mensaje de error y la publicación será bloqueada:

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 conexiones siguen funcionando independientemente del ajuste del interruptor. Además, los informes publicados que usan un modelo compuesto en un modelo semántico de Power BI siguen funcionando incluso si el interruptor está desactivado después de ser publicados.

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

Para crear un modelo compuesto en un modelo semántico de Power BI o en un modelo de Analysis Services, el informe necesita 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 qué conexiones se usan en el modelo, compruebe la barra de estado 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 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 Realizar cambios en este modelo se encuentra en la pestaña Modelado. En Vista de Modelo, el botón se encuentra en la pestaña Inicio.

Al seleccionar el botón, aparece un cuadro de diálogo que confirma la adición de un modelo local. Seleccione Agregar un modelo local para habilitar la creación de nuevas columnas o modificar los metadatos de los campos de 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. Al publicar 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, le permite publicar un informe y un modelo semántico basado en otros modelos semánticos de Power BI.

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. A continuación, cree y publique un modelo y un informe semántico compuesto, denominado Sales and Budget Europe, mediante el modelo semántico De ventas y presupuesto de Power BI con sus propias modificaciones. Este modelo semántico es el tercero de la cadena.

1. La primera cadena es el modelo de Servicios de Análisis de Ventas.
2. La segunda cadena es el modelo semántico compuesto de Ventas y Presupuesto de Power BI.
3. La tercera cadena es el modelo semántico compuesto de Ventas y Presupuesto de Europa de Power BI.

En la imagen siguiente se muestra este proceso de encadenamiento.

La longitud de la cadena en la imagen anterior es tres, que es la longitud máxima. 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 necesitan permisos adecuados para todos los modelos y modelos semánticos de la cadena.

El propietario del modelo compuesto necesita 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 requiere permisos de compilación en los modelos semánticos usados como orígenes.

Los usuarios que ven los informes mediante el modelo compuesto suelen necesitar 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.

En el ejemplo siguiente se muestran los permisos necesarios:

• 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 que usa 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 que usa 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 que usan el modelo compuesto A debe tener permisos delectura para el modelo compuesto A y el modelo semántico B, mientras que un usuario que vea los informes que usan 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.

Si algún modelo semántico 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 modelo semántico de la cadena está en un área de trabajo pro, el usuario que accede a él necesita una licencia Pro. Si todos los modelos semánticos de la cadena están en capacidades Premium o en Fabric F64 o una mayor capacidad, un usuario puede acceder a ellos mediante una licencia gratuita.

Advertencia de seguridad

Al usar los modelos compuestos en modelos semánticos de Power BI y la característica modelos de Analysis Services , verá un cuadro de diálogo de advertencia de seguridad, que se muestra en la imagen siguiente.

Los datos podrían ser enviados desde un origen de datos a otro. Esta advertencia de seguridad se aplica a la combinación de DirectQuery e importación de orígenes en un modelo de datos. Para obtener más información sobre este comportamiento, consulte Uso de modelos compuestos en Power BI Desktop.

Escenarios admitidos

Puede crear modelos compuestos mediante el uso de datos de modelos semánticos de Power BI o modelos de Analysis Services para atender los escenarios siguientes:

• Conexión a datos de varios orígenes: 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 usan campos de orígenes de datos diferentes
• Creación de nuevas columnas para tablas a partir de modelos semánticos de Power BI o modelos de Analysis Services
• Creación de objetos visuales que usan columnas de orígenes de datos diferentes
• Quitar una tabla del modelo mediante la lista de campos para mantener los modelos tan concisos y reducidos como sea posible (si te conectas a una perspectiva, no puedes quitar tablas del modelo).
• Especifique qué tablas se van a cargar, en lugar de tener que cargar todas las tablas cuando solo desee un subconjunto específico de tablas. Consulte Carga de un subconjunto de tablas más adelante en este documento.
• Especifique si desea agregar las tablas que agregue más adelante al modelo semántico después de realizar la conexión en el 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 compilar informes en el servicio Power BI en un modelo compuesto basado en otro modelo semántico, debe establecer 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 modelos semánticos remotos de Power BI usan el inicio de sesión único. Actualmente, no se admite la autenticación con una entidad de servicio.

• Las reglas de RLS se aplican al origen en el que se definen, pero no se aplican a ningún otro modelo semántico del modelo. RLS definido en el informe no se aplica a orígenes remotos y RLS establecido en orígenes remotos no se aplican a otros orígenes de datos. Además, no puede definir RLS en una tabla cargada desde un origen remoto y RLS definida en tablas locales no filtra ninguna tabla cargada 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 fecha seleccionando la flecha hacia abajo en el nombre del campo y seleccionando el nombre de ese campo en lugar de usar la 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.

• Puede establecer una bandera para desaconsejar el encadenamiento en un modelo para evitar que se cree o extienda una cadena. Para más información, vea Administración de conexiones de DirectQuery a un modelo semántico publicado.

• Power Query no muestra la conexión a un modelo semántico de Power BI ni a un modelo de Analysis Services.

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 se admite el uso de Power BI Embedded con modelos semánticos que incluyen una conexión de DirectQuery a un modelo externo de Analysis Services (Azure Analysis Services/SQL Server Analysis Services).
• No se admite la publicación de un informe en web mediante la característica publicar en 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 asumir el control de un modelo semántico que usa la función DirectQuery para otros modelos semánticos.
• Al igual que con cualquier origen de datos de DirectQuery, las jerarquías definidas en un modelo de Analysis Services o el modelo semántico de Power BI no se muestran al conectarse al modelo o al modelo semántico en modo DirectQuery mediante Excel.

Al trabajar con DirectQuery para modelos semánticos de Power BI y Analysis Services, tenga en cuenta las instrucciones siguientes:

• 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

Debe publicar cualquier modelo que utilice una conexión de DirectQuery a un modelo semántico de Power BI o a Analysis Services en el mismo tenant. Este requisito es especialmente importante al acceder a un modelo semántico de Power BI o a un modelo de Analysis Services mediante identidades de invitado B2B, como se muestra en el diagrama siguiente.

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 los datos proporcionados por Fabrikam. Con Power BI Desktop, Ash crea una conexión DirectQuery a un modelo de Analysis Services que Fabrikam hospeda.

Para autenticarse, Ash usa una identidad de usuario invitado B2B (paso 1 en el diagrama).

Si Ash publica el informe en el servicio Power BI de Contoso (paso 2), el modelo semántico publicado en el tenant de Contoso no se puede autenticar exitosamente contra el modelo de Analysis Services de Fabrikam (paso 3). Como resultado, el informe no funciona.

En este escenario, dado que Fabrikam hospeda el modelo de Analysis Services, también debe publicar el informe en el arrendatario 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 componen el esquema del modelo (es decir, tablas, columnas, metadatos, etc.) de los consumidores del modelo (por ejemplo, un generador de informes o un autor de modelo compuesto). 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.

Al compilar un modelo compuesto sobre un modelo semántico de Power BI protegido por OLS o un modelo de Analysis Services a través de la conexión directQuery, copie el esquema del modelo del modelo de origen en el modelo compuesto. Lo que copies depende de lo que estés autorizado a ver en el modelo de origen, según las reglas OLS que se aplican allí. No copia los datos en el modelo compuesto: siempre se recupera a través de DirectQuery desde el modelo de origen cuando sea necesario. En otras palabras, la recuperación de datos siempre vuelve al modelo de origen, donde se aplican las reglas OLS.

Dado que las reglas OLS no protegen el modelo compuesto, los objetos a los que ven los consumidores del modelo compuesto son los que se pueden ver en el modelo de origen en lugar de a lo que podrían tener acceso. Esta situación podría dar lugar a los siguientes resultados:

• 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 publica un modelo semántico empresarial mediante un modelo semántico de Power BI o un modelo de Analysis Services que tiene una tabla Customer y una tabla Territory. 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.
• No se pueden definir reglas OLS en el propio modelo compuesto.
• Un consumidor de un modelo compuesto nunca ve los datos reales que no se supone que ven, ya que las reglas OLS pertinentes del modelo de origen los bloquean cuando DirectQuery intenta recuperar los datos mediante 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 de DirectQuery, se eligen las tablas a las que 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.

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 entre en conflicto con otro origen del modelo compuesto. Puede:

• Escriba un texto para agregar al nombre de las tablas o medidas en conflicto.
• Especifique si desea que el texto se agregue a la tabla o al nombre de medida como prefijo o un sufijo.
• Aplique la regla de desduplicación a tablas, medidas o ambos.
• 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 obtiene un cambio de nombre.

Después de realizar las conexiones y configurar la regla de desduplicación, la lista de campos muestra "Customer" y "Customer (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, se siguen aplicando las reglas de desduplicación estándar. Las reglas de desduplicación estándar agregan un número al nombre de un elemento en conflicto. Si hay un conflicto de nombre en la tabla "Customer", se cambia el nombre de una de las tablas "Customer" a "Customer 2".

Modificaciones de XMLA y modelos compuestos

Al cambiar un modelo semántico mediante XMLA, actualice las colecciones ChangedProperties y PBI_RemovedChildren para que el objeto modificado incluya las propiedades modificadas o eliminadas. Si no actualiza estas colecciones, las herramientas de modelado de Power BI podrían sobrescribir los cambios la próxima vez que el esquema se sincronice con el origen de datos.

Para más información sobre las etiquetas de linaje de objetos de modelo semántico, consulte etiquetas de linaje para modelos semánticos de Power BI.

Consideraciones y limitaciones

Los modelos compuestos presentan algunas consideraciones y limitaciones:

Conexiones en modo mixto : cuando se usa una conexión de modo mixto que contiene datos en línea (como un modelo semántico de Power BI) y un modelo semántico local (como un libro de Excel), debe establecer la asignación de puerta de enlace para que los objetos 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 incluyen 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