Descripción de un esquema de estrella e importancia para Power BI

Este artículo va dirigido a los modeladores de datos de Power BI Desktop. Describe el diseño del esquema de estrella y su relevancia para desarrollar modelos semánticos de Power BI optimizados para el rendimiento y la facilidad de uso.

Importante

Los modelos semánticos de Power BI dependen de Power Query para importar o conectarse a datos. Esto significa que debe usar Power Query para transformar y preparar los datos de origen, lo que puede resultar difícil cuando tiene grandes volúmenes de datos o necesita implementar conceptos avanzados como dimensiones que cambian lentamente (que se describen más adelante en este artículo).

Cuando se le presentan estos desafíos, se recomienda desarrollar primero un almacenamiento de datos y procesos de extracción, transformación y carga (ETL) para cargar periódicamente el almacenamiento de datos. Después, el modelo semántico puede conectarse al almacenamiento de datos. Para obtener más información, vea Modelado dimensional en Microsoft Fabric Warehouse.

Sugerencia

Este artículo no pretende proporcionar una explicación completa del diseño del esquema de estrella. Para obtener más información, consulte directamente el contenido publicado con mayor difusión, como The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3ª edición, 2013) de Ralph Kimball y otros.

Información general del esquema de estrella

El esquema de estrella es un enfoque de modelado maduro ampliamente adoptado por los almacenes de datos relacionales. Requiere que los modeladores clasifiquen las tablas del modelo como dimensiones o hechos.

• Las tablas de dimensiones describen entidades empresariales (las cosas que se modelan). Las entidades pueden incluir productos, personas, lugares y conceptos, incluido el propio tiempo. La tabla más coherente de un esquema de estrella es una tabla de dimensiones de fecha. Una tabla de dimensiones contiene una columna de clave (o columnas) que actúa como identificador único y otras columnas. Otras columnas admiten el filtrado y la agrupación de los datos.
• Las tablas de hechos almacenan observaciones o eventos, y pueden ser pedidos de venta, saldos de existencias, tipos de cambio, temperaturas, etc. Una tabla de hechos contiene columnas clave de dimensiones que se relacionan con tablas de dimensiones y columnas de medidas numéricas. Las columnas de clave de dimensiones determinan la dimensionalidad de una tabla de hechos, mientras que los valores de clave de dimensiones determinan la granularidad de una tabla de hechos. Por ejemplo, considere una tabla de hechos diseñada para almacenar destinos de venta con dos columnas Date clave de dimensión y ProductKey. Resulta fácil comprender que la tabla tiene dos dimensiones. Pero la granularidad no se puede determinar sin tener en cuenta los valores de clave de dimensiones. En este ejemplo, considere que los valores almacenados en la Date columna son el primer día de cada mes. En este caso, la granularidad está en el nivel mes-producto.

Normalmente, las tablas de dimensiones contienen un número relativamente pequeño de filas. Por otro lado, las tablas de hechos pueden contener un gran número de filas y seguir creciendo con el tiempo.

Normalización frente a desnormalización

Para comprender algunos conceptos de los esquemas de estrella descritos en este artículo, es importante conocer dos términos: normalización y desnormalización.

Normalización es el término que se usa para describir los datos almacenados de una manera que reduce los datos repetitivos. Considere una tabla de productos que tiene una columna de valor de clave única, como la clave de producto y otras columnas que describen las características del producto, como el nombre del producto, la categoría, el color y el tamaño. Una tabla de ventas se considera normalizada cuando almacena solo claves, como la clave de producto. En la imagen siguiente, observe que solo la ProductKey columna registra el producto.

Pero si la tabla de ventas almacena detalles de los productos más allá de la clave, se considera desnormalizada. En la imagen siguiente, observe que las columnas relacionadas con el ProductKey producto y otras columnas relacionadas con el producto registran.

Cuando se extraen datos de un archivo de exportación o de un extracto de datos, es probable que representen un conjunto de datos desnormalizado. En este caso, use Power Query para transformar y dar forma a los datos de origen en varias tablas normalizadas.

Como se describe en este artículo, debe esforzarse por desarrollar modelos semánticos de Power BI optimizados con tablas que representan datos de dimensiones y hechos normalizados. Sin embargo, hay una excepción en la que una dimensión de copo de nieve podría desnormalizarse para generar una sola tabla de modelos.

Relevancia del esquema de estrella para los modelos semánticos de Power BI

El diseño de esquema de estrella y muchos conceptos relacionados presentados en este artículo son muy importantes para desarrollar modelos de Power BI optimizados para el rendimiento y la facilidad de uso.

Tenga en cuenta que cada objeto visual de informe de Power BI genera una consulta que se envía al modelo semántico de Power BI. Por lo general, las consultas filtran, agrupan y resumen los datos del modelo. Por tanto, un modelo bien diseñado es aquel que proporciona tablas para filtrar y agrupar y tablas para resumir. Este diseño se ajusta bien a los principios de los esquemas de estrella:

• Las tablas de dimensiones habilitan el filtrado y la agrupación.
• Las tablas de hechos habilitan el resumen.

No hay ninguna propiedad de tabla que los modeladores establezcan para establecer el tipo de tabla como dimensión o hecho. De hecho, viene determinado por las relaciones del modelo. Una relación de modelo establece una ruta de propagación de filtro entre dos tablas y es la propiedad de cardinalidad de la relación que determina el tipo de tabla. Una cardinalidad de relación común es uno a varios o su inversa varios a uno. El lado "uno" siempre es una tabla de dimensiones mientras que el lado "varios" siempre es una tabla de hechos.

Un diseño de modelo bien estructurado incluye tablas que son tablas de dimensiones o tablas de hechos. Evite mezclar los dos tipos en una sola tabla. También se recomienda que se esfuerza por entregar el número correcto de tablas con las relaciones correctas en su lugar. También es importante que las tablas de hechos siempre carguen datos de forma coherente.

Por último, es importante entender que un diseño óptimo del modelo es en parte ciencia y en parte arte. A veces puede tener sentido comenzar con una buena orientación.

Hay muchos conceptos relacionados con el diseño de esquema de estrella que se pueden aplicar a un modelo semántico de Power BI. Entre estos conceptos se incluyen los siguientes:

• Medidas
• Claves suplentes
• Dimensiones de copo de nieve
• Dimensiones realizadoras de roles
• Dimensiones de variación lenta
• Dimensiones no deseadas
• Dimensiones degeneradas
• Tablas de hechos sin hechos

Medidas

En el diseño de esquemas de estrella, una medida es una columna de tabla de hechos que almacena valores que se van a resumir. En un modelo semántico de Power BI, una medida tiene una definición diferente, pero similar. Un modelo admite medidas explícitas e implícitas.

• Las medidas explícitas se crean expresamente y se basan en una fórmula escrita en Expresiones de análisis de datos (DAX) que logra el resumen. Las expresiones de medida suelen usar funciones de agregación DAX como SUM, MIN, MAX, AVERAGE, y otras para generar un resultado de valor escalar en el momento de la consulta (los valores nunca se almacenan en el modelo). La expresión de medida puede abarcar desde agregaciones de columnas simples hasta fórmulas más sofisticadas que invalidan las propagaciones de contexto o de relación de filtrado. Para obtener más información, lea sobre los conceptos básicos de DAX en Power BI Desktop.
• Las medidas implícitas son columnas que se pueden resumir mediante un objeto visual de informe o Q&A. Ofrecen una comodidad para usted como desarrollador de modelos, ya que en muchas instancias no es necesario crear medidas (explícitas). Por ejemplo, la columna de ventas Sales Amount de revendedores de Adventure Works se puede resumir de varias maneras (suma, recuento, promedio, mediana, mínimo, máximo y otros), sin necesidad de crear una medida para cada tipo de agregación posible.

En el panel Datos, las medidas explícitas se representan mediante el icono de la calculadora, mientras que las medidas implícitas se representan mediante el símbolo sigma (∑).

Sin embargo, hay tres razones convincentes por las que puede crear medidas, incluso para resúmenes simples de nivel de columna:

• Cuando sepa que los autores de informes consultarán el modelo semántico mediante expresiones multidimensionales (MDX), el modelo debe incluir medidas explícitas. Esto se debe a que MDX no puede lograr el resumen de los valores de columna. En particular, MDX se usa al realizar Análisis en Excel porque las tablas dinámicas emiten consultas MDX.

• Cuando sepa que los autores de informes crearán informes paginados de Power BI mediante el diseñador de consultas MDX, el modelo semántico debe incluir medidas explícitas. Solo el diseñador de consultas MDX admite agregados de servidor. Por tanto, si los autores del informe necesitan que Power BI evalúe las medidas (y no lo haga el motor de informes paginados), tendrán que usar el diseñador de consultas MDX.

• Cuando quiera controlar cómo los autores de informes resumen las columnas de maneras específicas. Por ejemplo, la columna ventas Unit Price de revendedores (que representa una tasa por unidad) se puede resumir, pero solo mediante funciones de agregación específicas. Nunca se debe sumar, pero es adecuado resumir mediante otras funciones de agregación como min, max o average. En esta instancia, el modelador puede ocultar la Unit Price columna y crear medidas para todas las funciones de agregación adecuadas.

  Este enfoque de diseño funciona bien con los informes creados en el servicio Power BI y con Preguntas y respuestas. Sin embargo, las conexiones dinámicas de Power BI Desktop permiten a los autores de informes mostrar campos ocultos en el panel Datos, lo que puede dar lugar a evitar este enfoque de diseño.

Claves suplentes

Una clave suplente es un identificador único que se agrega a una tabla para admitir el modelado de esquemas de estrella. Por definición, no se define ni se almacena en los datos de origen. Normalmente, las claves suplentes se agregan a las tablas de dimensiones del almacén de datos relacionales para proporcionar un identificador único para cada fila de la tabla de dimensiones.

Las relaciones del modelo semántico de Power BI se basan en una sola columna única de una tabla, que propaga los filtros a una sola columna de una tabla diferente. Cuando una tabla de dimensiones del modelo semántico no incluye una sola columna única, debe agregar un identificador único para convertirse en el lado "uno" de una relación. En Power BI Desktop, puede lograr este requisito agregando una columna de índice de Power Query.

Debe combinar esta consulta con la consulta "varios" para poder agregarle también la columna de índice. Al cargar estas consultas en el modelo semántico, puede crear una relación uno a varios entre las tablas del modelo.

Dimensiones de copo de nieve

Una dimensión de copo de nieve es un conjunto de tablas normalizadas para una sola entidad de negocio. Por ejemplo, Adventure Works clasifica los productos por categoría y subcategoría. Los productos se asignan a subcategorías y, a su vez, las subcategorías se asignan a categorías. En el almacenamiento de datos relacionales de Adventure Works, la dimensión del producto se normaliza y almacena en tres tablas relacionadas: DimProductCategory, DimProductSubcategoryy DimProduct.

Si usa su imaginación, puede imaginarse las tablas normalizadas colocadas hacia fuera de la tabla de hechos, formando un diseño de copo de nieve.

En Power BI Desktop, puede elegir imitar un diseño de dimensión de copo de nieve (quizás porque los datos de origen lo hacen) o combinar las tablas de origen para formar una sola tabla de modelo desnormalizada. Por lo general, las ventajas de una sola tabla del modelo compensan las ventajas de varias tablas del modelo. La decisión óptima puede depender de los volúmenes de datos y de los requisitos de facilidad de uso del modelo.

Si elige imitar un diseño de dimensiones de copo de nieve:

• Power BI carga más tablas, lo que resulta menos eficaz desde el punto del vista del almacenamiento y el rendimiento. Estas tablas deben incluir columnas para admitir las relaciones del modelo, lo que puede dar lugar a un mayor tamaño del modelo.
• Es necesario recorrer cadenas de propagación de filtros de relación más largas, lo que podría ser menos eficaz que los filtros aplicados a una sola tabla.
• El panel Datos presenta más tablas de modelos a los autores de informes, lo que puede dar lugar a una experiencia menos intuitiva, especialmente cuando las tablas de dimensiones de copo de nieve contienen solo una o dos columnas.
• No es posible crear una jerarquía que incluya columnas de más de una tabla.

Si elige integrar en una sola tabla del modelo, además puede definir una jerarquía que abarque el mayor y menor nivel de detalle de la dimensión. Posiblemente, el almacenamiento de datos desnormalizados redundantes puede dar lugar a un aumento del tamaño de almacenamiento del modelo, especialmente para las tablas de dimensiones grandes.

Dimensiones de variación lenta

Una dimensión que cambia lentamente (o SCD) es una que administra adecuadamente el cambio de miembros de dimensión a lo largo del tiempo. Se aplica cuando los valores de entidad empresarial cambian lentamente con el tiempo de una manera no planeada. Un buen ejemplo de scD es una dimensión de cliente, ya que sus columnas de detalles de contacto, como la dirección de correo electrónico y el número de teléfono cambian con poca frecuencia. Por el contrario, algunas dimensiones se consideran rápidamente cambiantes cuando un atributo de dimensión cambia a menudo, como el precio de mercado de una acción. El enfoque de diseño común en estas instancias es almacenar los valores de atributo de variación rápida en una medida de tabla de hechos.

La teoría de diseño de esquemas de estrella hace referencia a dos tipos de SCD comunes: Tipo 1 y tipo 2. Una tabla de dimensiones podría ser tipo 1 o tipo 2, o admitir ambos tipos simultáneamente para columnas diferentes.

SCD de tipo 1

Una SCD de tipo 1 siempre refleja los valores más recientes y, cuando se detectan cambios en los datos de origen, se sobrescriben los datos de la tabla de dimensiones. Este enfoque de diseño es común para las columnas que almacenan valores auxiliares, como la dirección de correo electrónico o el número de teléfono de un cliente. Cuando cambia la dirección de correo electrónico o el número de teléfono de un cliente, la tabla de dimensiones actualiza la fila del cliente con los nuevos valores. Es como si el cliente tuviera siempre esta información de contacto.

Una actualización no incremental de una tabla de dimensiones de modelo de Power BI logra el resultado de un SCD de tipo 1. Actualiza los datos de la tabla para garantizar que se carguen los valores más recientes.

SCD de tipo 2

Una SCD de tipo 2 admite el control de versiones de los miembros de la dimensión. Si el sistema de origen no almacena versiones, normalmente es el proceso de carga del almacenamiento de datos que detecta los cambios y administra correctamente el cambio en una tabla de dimensiones. En este caso, la tabla de dimensiones debe usar una clave suplente para proporcionar una referencia única a una versión del miembro de la dimensión. También incluye columnas que definen la validez del intervalo de fechas de la versión (por ejemplo, StartDate y EndDate) y, posiblemente, una columna de marca (por ejemplo, IsCurrent) para filtrar fácilmente por miembros de la dimensión actuales.

Por ejemplo, Adventure Works asigna cada vendedor a una región de ventas. Cuando un vendedor se reasigna a otra región, debe crearse una nueva versión del vendedor para asegurarse de que los hechos históricos sigan asociados a la región anterior. Para admitir un análisis histórico preciso de ventas por vendedor, la tabla de dimensiones debe almacenar versiones de vendedores y sus regiones asociadas. La tabla también debe incluir valores de fecha de inicio y finalización para definir la validez temporal. Las versiones actuales pueden definir una fecha de finalización vacía (o 31/12/9999), lo que indica que la fila es la versión actual. La tabla también debe tener una clave suplente porque la clave de negocio (en esta instancia, el identificador de empleado) no será única.

Es importante comprender que si los datos de origen no almacenan versiones, debe usar un sistema intermedio (como un almacenamiento de datos) para detectar y almacenar los cambios. El proceso de carga de la tabla debe conservar los datos existentes y detectar los cambios. Cuando se detecta un cambio, el proceso de carga de la tabla debe hacer que expire la versión actual. Para registrar estos cambios actualiza el valor EndDate e inserta una versión nueva con el valor StartDate que comienza a partir del valor EndDate anterior. Además, los hechos relacionados deben usar una búsqueda basada en tiempo para recuperar el valor de clave de dimensión pertinente para la fecha de los hechos. Un modelo semántico de Power BI usa Power Query, por lo que no puede generar este resultado. Pero puede cargar datos de una tabla de dimensiones SCD de tipo 2 previamente cargada.

Sugerencia

Para obtener información sobre cómo implementar una tabla de dimensiones scD de tipo 2 en un almacenamiento de Fabric, consulte Administración de cambios históricos.

El modelo semántico de Power BI debe admitir la consulta de datos históricos para un miembro, independientemente del cambio, y para una versión del miembro, que representa un estado determinado del miembro en el tiempo. En el contexto de Adventure Works, este diseño permite consultar el vendedor con independencia de la región de ventas asignada, o una versión determinada del vendedor.

Para lograr este requisito, la tabla de dimensiones del modelo semántico de Power BI debe incluir una columna para filtrar el vendedor y otra columna para filtrar una versión específica del vendedor. Es importante que la columna de versión proporcione una descripción no ambigua, como David Campbell (12/15/2008-06/26/2019) o David Campbell (06/27/2019-Current). También es importante educar a los autores y usuarios de informes sobre los aspectos básicos de la SCD de tipo 2 y cómo lograr diseños de informe adecuados mediante la aplicación de los filtros correctos.

Se recomienda incluir una jerarquía que permita a los objetos visuales explorar en profundidad el nivel de versión.

Dimensiones realizadoras de roles

Una dimensión realizadora de roles es una dimensión que puede filtrar datos relacionados de manera diferente. Por ejemplo, en Adventure Works, la tabla de dimensiones de fecha tiene tres relaciones con los hechos de ventas del revendedor. Se puede usar la misma tabla de dimensiones para filtrar los hechos por fecha de pedido, fecha de envío o fecha de entrega.

En un almacenamiento de datos, el enfoque de diseño aceptado es definir una sola tabla de dimensiones de fecha. En tiempo de consulta, el "rol" de la dimensión de fecha se establece mediante la columna de hechos que se usa para combinar las tablas. Por ejemplo, al analizar las ventas por fecha de pedido, la combinación de tabla se relaciona con la columna de fecha de pedido de ventas del distribuidor.

En un modelo semántico de Power BI, este diseño se puede imitar mediante la creación de varias relaciones entre dos tablas. En el ejemplo de Adventure Works, las tablas de fecha y ventas del distribuidor tendrían tres relaciones.

Aunque este diseño es posible, solo puede haber una relación activa entre dos tablas de modelos semánticos de Power BI. Todas las demás relaciones se deben establecer en inactivas. Tener una única relación activa significa que hay una propagación de filtro predeterminada de fecha a ventas de revendedor. En este caso, la relación activa se establece en el filtro más común que usan los informes, que en Adventure Works es la relación de fecha de pedido.

La única forma de usar una relación inactiva es definir una expresión DAX que use la función USERELATIONSHIP. En el ejemplo, el desarrollador del modelo debe crear medidas para habilitar el análisis de las ventas del distribuidor por fecha de envío y fecha de entrega. Este trabajo puede resultar tedioso, sobre todo si en la tabla del distribuidor se definen muchas medidas. También crea un panel De datos desordenado que tiene una sobreabundancia de medidas. También hay otras limitaciones:

• Cuando los autores de informes se basan en resumir columnas en lugar de definir medidas, no pueden lograr el resumen de las relaciones inactivas sin escribir una medida de nivel de informe. Las medidas de nivel de informe solo se pueden definir al crear informes en Power BI Desktop.
• Con solo una ruta de relación activa entre la fecha y las ventas del distribuidor, no es posible filtrar simultáneamente las ventas del distribuidor por diferentes tipos de fechas. Por ejemplo, no se puede generar un objeto visual que trace las ventas de fecha de pedido por ventas enviadas.

Para superar estas limitaciones, una técnica de modelado común de Power BI es crear una tabla de dimensiones para cada instancia de rol. Puede crear cada tabla de dimensiones como una consulta de referencia mediante Power Query o una tabla calculada mediante DAX. El modelo puede contener una Date tabla, una Ship Date tabla y una Delivery Date tabla, cada una con una relación única y activa con sus respectivas columnas de tabla de ventas de revendedores.

Este enfoque de diseño no requiere la definición de varias medidas para los distintos roles de fecha y permite el filtrado simultáneo mediante diferentes roles de fecha. Sin embargo, un precio menor para pagar con este enfoque de diseño es que habrá duplicación de la tabla de dimensiones de fecha, lo que da lugar a un mayor tamaño de almacenamiento del modelo. Dado que las tablas de dimensiones suelen almacenar menos filas en relación con las tablas de hechos, rara vez es un problema.

Se recomienda seguir los procedimientos de diseño recomendados al crear tablas de dimensiones de modelo para cada rol:

• Asegúrese de que los nombres de columna sean autodescriptivos. Aunque es posible tener una Year columna en todas las tablas de fechas (los nombres de columna son únicos dentro de su tabla), no se describe automáticamente con títulos visuales predeterminados. Considere la posibilidad de cambiar el nombre de las columnas de cada tabla de roles de dimensión para que la Ship Date tabla tenga una columna de año denominada Ship Year, etc.
• Cuando sea pertinente, asegúrese de que las descripciones de la tabla proporcionan comentarios a los autores de informes (a través de la información sobre herramientas del panel de datos ) sobre cómo se configura la propagación de filtros. Esta claridad es importante cuando el modelo contiene una tabla con nombre genérico, como Date, que se usa para filtrar muchas tablas de hechos. En caso de que esta tabla tenga, por ejemplo, una relación activa con la columna de fecha del pedido de ventas del revendedor, considere la posibilidad de proporcionar una descripción de tabla como Filters reseller sales by order date.

Para más información, consulte Instrucciones para relaciones activas frente a inactivas.

Dimensiones no deseadas

Una dimensión no deseada es útil cuando hay muchas dimensiones, especialmente si constan de pocos atributos (quizás uno) y si estos atributos tienen pocos valores. Los buenos candidatos incluyen columnas de estado de pedido o columnas demográficas del cliente, como el sexo o el grupo de edad.

El objetivo de diseño de una dimensión no deseado es consolidar muchas dimensiones pequeñas en una sola dimensión para reducir el tamaño de almacenamiento del modelo y también reducir el desorden del panel Datos al mostrar menos tablas de modelos.

Normalmente, una tabla de dimensiones no deseado es el producto cartesiano de todos los miembros de atributo de dimensión, con una columna de clave suplente para identificar de forma única cada fila. Puede compilar la dimensión en un almacenamiento de datos o al usar Power Query para crear una consulta que realice combinaciones de consulta externas completas y luego agregue una clave suplente (columna de índice).

Esta consulta se carga en el modelo como una tabla de dimensiones. También debe combinar esta consulta con la consulta de hechos para que la columna de índice se cargue en el modelo para admitir la creación de una relación de modelo de uno a varios.

Dimensiones degeneradas

Una dimensión degenerada hace referencia a un atributo de la tabla de hechos necesaria para el filtrado. En Adventure Works, el número de pedido de ventas del distribuidor es un buen ejemplo. En este caso, no tiene sentido crear una tabla independiente que consta solo de esta columna porque aumentaría el tamaño de almacenamiento del modelo y daría como resultado un desorden en el panel Datos .

En el modelo semántico de Power BI, puede ser adecuado agregar la columna número de pedido de ventas a la tabla de hechos para permitir el filtrado o la agrupación por número de pedido de ventas. Es una excepción a la regla anteriormente introducida que no debe mezclar tipos de tabla (por lo general, las tablas de modelo deben ser dimensiones o hechos).

Sin embargo, si la tabla de ventas de revendedores de Adventure Works tiene columnas de número de pedido y número de línea de pedido, y son necesarias para el filtrado, la creación de una tabla de dimensiones degenerada sería un buen diseño. Para más información, consulte Instrucciones para relaciones uno a uno (Dimensiones degeneradas).

Tablas de hechos sin hechos

Una tabla de hechos sin hechos no incluye ninguna columna de medida. Solo contiene claves de dimensión.

Una tabla de hechos sin hechos podría almacenar observaciones definidas por claves de dimensión. Por ejemplo, en una fecha y hora determinados, un cliente determinado inició sesión en el sitio web. Puede definir una medida para contar las filas de la tabla de hechos sin hechos para realizar análisis de cuándo y cuántos clientes han iniciado sesión.

Un uso más atractivo de una tabla de hechos sin hechos es almacenar relaciones entre dimensiones y es un enfoque de diseño de modelo semántico de Power BI que se recomienda para definir relaciones de dimensión de varios a varios. En un diseño de relaciones de dimensión de varios a varios, la tabla de datos sin datos se conoce como tabla de puente.

Por ejemplo, imagine que los vendedores pueden asignarse a una o más regiones de ventas. La tabla de puente se diseñaría como una tabla de hechos sin hechos de dos columnas: clave de vendedor y clave de región. Los valores duplicados se pueden almacenar en ambas columnas.

Este enfoque de diseño de varios a varios está bien documentado y se puede lograr sin una tabla de puente. Pero el enfoque de tabla de puente se considera el procedimiento recomendado al relacionar dos dimensiones. Para más información, consulte Instrucciones para relaciones de varios a varios (Relación de dimensiones varios a varios).

Contenido relacionado

Para obtener más información sobre el diseño del esquema de estrella o el diseño del modelo semántico de Power BI, consulte los artículos siguientes:

• Artículo de la Wikipedia sobre el modelado dimensional
• Relaciones de modelos en Power BI Desktop
• Instrucciones para relaciones uno a uno
• Instrucciones para relaciones de varios a varios
• Instrucciones para relaciones bidireccionales
• Instrucciones para relaciones activas frente a inactivas
• Modelado dimensional en Microsoft Fabric Warehouse
• ¿Tiene alguna pregunta? Intente preguntar a la comunidad de Fabric.
• ¿Sugerencias? Contribuir a ideas para mejorar Fabric