Projetar esquema de estrela para modelos semânticos

Você escolheu como os dados fluem para seu modelo semântico. Agora, projete o esquema de estrela que o organiza para consultas claras e performantes. Um esquema estrela conecta tabelas de fatos às tabelas de dimensão por meio de relacionamentos, criando os caminhos de filtragem nos quais os relatórios e o consumo de IA se baseiam. Se você estiver familiarizado com a criação de esquema de estrela no Power BI Desktop, esta unidade se concentrará nas decisões de design de relacionamento que são importantes à medida que os modelos crescem em complexidade e escala.

Esquema de estrela em um modelo semântico

Em um esquema estrela, as tabelas de fatos armazenam eventos comerciais mensuráveis (como transações de vendas, linhas de pedidos e visitas à Web) e tabelas de dimensão fornecem o contexto descritivo (como detalhes do produto, informações do cliente e atributos de data). As tabelas de dimensão filtram tabelas de fatos por meio de relações, o que permite que os usuários cortem as métricas por qualquer atributo descritivo.

Em um modelo semântico do Fabric, esse padrão fornece propagação clara de filtro tanto para relatórios quanto para consumo de inteligência artificial. Quando Copilot ou um agente de dados gera uma consulta de linguagem natural, um esquema de estrela bem organizado fornece à IA caminhos claros para os dados certos. Relações ambíguas ou circulares confundem consumidores de relatório e ferramentas de IA.

Como o modo de armazenamento afeta as relações

As relações em um modelo semântico se comportam de forma diferente dependendo do modo de armazenamento. Entender essas diferenças é essencial para criar um esquema estrela que tenha um bom desempenho em diferentes cenários.

Relações do Direct Lake

No modo Direct Lake, o mecanismo lê relações diretamente dos metadados da tabela Delta. As relações têm o melhor desempenho quando:

• As colunas de chave de dimensão têm baixa cardinalidade em relação às linhas da tabela de fatos.
• A integridade referencial é mantida nos dados de origem. Quando a integridade referencial é mantida, o mecanismo usa junções INNER em vez de junções LEFT OUTER, o que melhora o desempenho da consulta.
• As colunas usadas em relações são indexadas nas tabelas Delta subjacentes.

Relações entre fontes

Fabric modelos semânticos podem conectar tabelas de diferentes armazenamentos de dados. Uma tabela de fatos de um data lakehouse pode ter uma relação com uma tabela de dimensões de um armazém de dados ou com uma tabela acessada por meio de um endpoint de análise SQL. Essas conexões entre fontes usam recursos de modelo composto.

Quando as tabelas vêm de fontes diferentes, o modo de armazenamento para cada tabela determina como a relação funciona no momento da consulta. O mecanismo resolve cada lado de forma independente e une os resultados.

Tipos de relacionamentos

Relacionamento um para muitos

O tipo de relação mais comum em um esquema de estrela é o de um para muitos. Um valor exclusivo em uma tabela de dimensões está relacionado a muitas linhas em uma tabela de fatos. Por exemplo, uma linha de produto na dimensão Produto corresponde a milhares de linhas de pedido na tabela de fatos Vendas.

Configure relações um-para-muitos com a direção do filtro fluindo da dimensão (o lado "um") para a tabela de fatos (o lado "muitos"). Esse é o padrão de filtro do esquema de estrela.

Relacionamento muitos para muitos

Relações muitos-para-muitos são necessárias quando nenhuma das tabelas possui valores exclusivos na coluna de relação. Use uma tabela de ponte para resolver essas relações. Uma tabela intermediária fica entre duas tabelas e contém combinações únicas das chaves de cada lado.

Por exemplo, se um cliente pode ter várias contas e uma conta pode pertencer a vários clientes, uma tabela de ponte Customer-Account resolve a relação. A tabela de ponte tem relações um para muitos com as tabelas Cliente e Conta.

Direção do filtro

Na maioria das implementações de esquema estrela, use a filtragem de direção única de dimensão para fato. Isso fornece propagação de filtro previsível e evita ambiguidade nos resultados da consulta.

Às vezes, a filtragem bidirecional é necessária para relações muitos para muitos ou quando as tabelas de dimensão precisam ser filtradas por valores na tabela de fatos. Use filtros bidirecionais com moderação porque eles podem degradar o desempenho da consulta e criar um comportamento de filtro inesperado em relatórios.

Integridade referencial

A configuração Assumir integridade referencial informa ao mecanismo para usar junções INNER em vez de junções LEFT OUTER ao realizar consultas entre relações. Nos modos Direct Lake e DirectQuery, essa configuração pode melhorar significativamente o desempenho porque reduz o número de linhas que o mecanismo processa.

Habilite essa configuração quando estiver confiante de que cada valor de chave estrangeira na tabela de fatos tem um valor correspondente na tabela de dimensões. Se a integridade referencial for violada, as linhas com chaves incompatíveis desaparecerão silenciosamente dos resultados da consulta.

Relações inativas e USERELATIONSHIP

Somente uma relação ativa pode existir entre duas tabelas de cada vez. Quando você precisa de vários caminhos de relação (como uma data de pedido e uma data de envio, ambos relacionados à mesma dimensão Data), torne uma relação ativa e as outras inativas.

Use a USERELATIONSHIP função no DAX para ativar uma relação inativa em um cálculo:

Shipped Amount =
CALCULATE(
    SUM(Sales[Amount]),
    USERELATIONSHIP(Sales[ShipDate], 'Date'[Date])
)

Esse padrão mantém o modelo limpo enquanto dá suporte a várias perspectivas analíticas nos mesmos dados.

Lidar com o esquema floco de neve em modelos semânticos

Os dados de origem geralmente chegam em um esquema de floco de neve normalizado, em que as tabelas de dimensão são divididas em várias tabelas relacionadas. Por exemplo, uma dimensão de produto pode ser separada em tabelas Product, Subcategory e Category, cada uma vinculada por meio de chaves estrangeiras.

Em um modelo semântico, você tem duas opções: achatar o floco de neve em um esquema estrela ou preservar a estrutura normalizada.

Nivelar no esquema de estrela

Nivelar significa combinar as tabelas de dimensão normalizadas em uma única tabela de dimensão desnormalizada. A tabela Produto incluiria as colunas Subcategoria e Categoria diretamente, eliminando as tabelas e relações extras.

Nivelar quando:

• A tabela de dimensões combinada ainda é pequena em relação à tabela de fatos, o que quase sempre ocorre com as dimensões.
• Você deseja caminhos de filtro mais simples de dimensão para fato. Cada filtro percorre uma relação em vez de uma cadeia.
• O consumo de IA é uma prioridade. Menos tabelas e relações mais simples dão a Copilot e agentes de dados caminhos mais claros para os dados certos.

Nivele tabelas de dimensão durante a preparação de dados em lakehouses ou fluxos de dados, antes que os dados atinjam o modelo semântico. Use mesclagens do Power Query, junções SQL ou transformações em notebooks para combinar as tabelas normalizadas em uma única dimensão.

Preservar a estrutura floco de neve

Em alguns casos, manter a estrutura normalizada faz sentido:

• A hierarquia de dimensões tem vários níveis e o nivelamento criaria dezenas de colunas redundantes.
• Várias tabelas de fatos compartilham tabelas de subdimensão (como uma tabela categoria compartilhada usada por fatos de Vendas e Inventário) e a desnormalização criaria cópias inconsistentes.
• A segurança em nível de linha precisa ser aplicada em um nível específico na hierarquia.

Ao preservar uma estrutura de floco de neve, configure as relações cuidadosamente. Cada relação na cadeia de relações deve usar a filtragem de direção única da tabela mais externa em direção à tabela de fatos, de modo que os filtros se propaguem corretamente. Um filtro na Categoria precisa passar pela Subcategoria, através do Produto, até a tabela de fatos.

Quando usar modelos compostos para cenários de origem cruzada

Use modelos compostos quando o esquema estrela abrange vários armazenamentos de dados Fabric ou inclui fontes externas. Cenários comuns incluem:

• Tabelas de fatos em um lakehouse com tabelas de dimensão mantidas em um armazém.
• Dados de streaming em tempo real de uma casa de eventos combinada com dados históricos em um lakehouse.
• Dados de referência de uma fonte externa (Importação) combinados com tabelas de fatos nativas do Fabric (Direct Lake).

Nesses cenários, configure o modo de armazenamento para cada tabela de forma independente e verifique se as relações entre fontes têm um desempenho aceitável em seus volumes de dados esperados.