Desenhar esquema estrela para modelos semânticos

Escolheste como os dados fluem para o teu modelo semântico. Agora desenhe o esquema estrela que o organize para consultas claras e com desempenho. Um esquema estrela liga tabelas de factos a tabelas de dimensões através de relações, criando os caminhos de filtro dos quais dependem os relatórios e o consumo de IA. Se está familiarizado com a construção de esquema estrela no Power BI Desktop, esta unidade foca-se nas decisões de design de relações que importam à medida que os modelos crescem em complexidade e escala.

Esquema estrela num modelo semântico

Num esquema estrela, tabelas de factos armazenam eventos de negócio mensuráveis (como transações de vendas, linhas de encomenda e visitas à web), e tabelas de dimensões fornecem o contexto descritivo (como detalhes do produto, informação do cliente e atributos de data). As tabelas de dimensões filtram tabelas de factos através de relações, o que permite aos utilizadores segmentar métricas por qualquer atributo descritivo.

Num modelo semântico Fabric, este padrão fornece propagação eficiente de filtros tanto para relatórios analíticos como para a utilização por sistemas de IA. Quando o Copilot ou um agente de dados gera uma consulta em linguagem natural, um esquema de estrela bem organizado dá à IA caminhos claros para os dados corretos. Relações ambíguas ou circulares confundem tanto os consumidores de relatórios como as ferramentas de IA.

Como o modo de armazenamento afeta as relações

As relações num modelo semântico comportam-se de forma diferente dependendo do modo de armazenamento. Compreender estas diferenças é essencial para desenhar esquemas de estrelas que funcionem bem em diferentes cenários.

Relações diretas com lagos

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

• As colunas chave de dimensão têm baixa cardinalidade relativa em comparação com as linhas da tabela de factos.
• A integridade referencial é mantida nos dados fonte. Quando a integridade referencial se mantém, o motor utiliza INNER joins em vez de LEFT OUTER joins, o que melhora o desempenho das consultas.
• As colunas usadas nas relações são indexadas nas tabelas Delta subjacentes.

Relações entre fontes

Modelos semânticos Fabric podem ligar tabelas de diferentes armazenamentos de dados. Uma tabela de factos de um lakehouse pode ter uma relação com uma tabela de dimensão de um armazém, ou com uma tabela acedida através de um endpoint de análise SQL. Estas ligações entre fontes utilizam capacidades de modelos compostos.

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

Tipos de relação

Relações um-para-muitos

Um para muitos é o tipo de relação mais comum num esquema estrela. Um valor único numa tabela de dimensões relaciona-se com muitas linhas numa tabela de factos. Por exemplo, uma linha de produto na dimensão de produto corresponde a milhares de linhas de encomendas na tabela de factos de vendas.

Configure relações um-para-muitos, com a direção do filtro a fluir da dimensão (o lado "um") para a tabela de factos (o lado "muitos"). Este é o modelo padrão de filtro de esquema em estrela.

Relações muitos-para-muitos

São necessárias relações muitos-para-muitos quando nenhuma das tabelas tem valores únicos para a coluna de relações. Use uma tabela ponte para resolver estas relações. Uma mesa bridge situa-se entre duas mesas e contém combinações únicas das teclas de cada lado.

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

Direção do filtro

Na maioria das implementações de esquemas em estrela, utiliza-se filtragem de direção única da dimensão para o facto. Isto proporciona uma propagação previsível do filtro e evita ambiguidade nos resultados das consultas.

A filtragem bidirecional é por vezes necessária para relações muitos-para-muitos ou quando as tabelas de dimensões precisam de ser filtradas por valores na tabela de factos. Use filtros bidirecionais com moderação porque podem degradar o desempenho da consulta e criar comportamentos inesperados de filtros nos relatórios.

Integridade referencial

A definição Assumir integridade referencial indica ao motor usar junções INNER em vez de junções LEFT OUTER ao consultar numa relação. Nos modos Direct Lake e DirectQuery, esta definição pode melhorar significativamente o desempenho porque reduz o número de linhas processadas pelo motor.

Ative esta configuração quando tiver a certeza de que cada valor de chave estrangeira na tabela de factos tem um valor correspondente na tabela de dimensões. Se a integridade referencial for violada, as linhas com chaves não correspondidas desaparecem silenciosamente dos resultados das consultas.

Relações inativas e relação USE

Só pode existir uma relação ativa entre duas tabelas simultaneamente. Quando precisar de múltiplos caminhos de relacionamento (como uma data de encomenda e uma data de envio, ambos relacionados com a mesma dimensão de data), torne uma relação ativa e as outras inativas.

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

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

Este padrão mantém o modelo limpo, ao mesmo tempo que suporta múltiplas perspetivas analíticas sobre os mesmos dados.

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

Os dados de origem chegam frequentemente num esquema floco de neve normalizado, onde as tabelas de dimensões são divididas em múltiplas tabelas relacionadas. Por exemplo, uma dimensão de Produto pode ser separada em tabelas de Produto, Subcategoria e Categoria, cada uma ligada através de chaves estrangeiras.

Num modelo semântico, tens duas opções: achatar o floco de neve num esquema em estrela, ou preservar a estrutura normalizada.

Esquema estrela achatado

Achatamento significa combinar as tabelas de dimensão normalizadas numa única tabela de dimensão desnormalizada. A tabela de Produtos incluiria diretamente as colunas de Subcategoria e Categoria, eliminando as tabelas e relações extra.

Nivelar quando:

• A tabela de dimensões combinadas ainda é pequena em relação à tabela de factos (o que quase sempre acontece com as dimensões).
• Queres caminhos de filtro mais simples da dimensão para o facto. Cada filtro passa por uma relação em vez de uma cadeia.
• O consumo de IA é uma prioridade. Menos tabelas e relações mais simples dão ao Copilot e aos agentes de dados caminhos mais claros para os dados certos.

Achatar tabelas de dimensões durante a preparação de dados em casas de lagos ou fluxos de dados, antes de os dados chegarem ao modelo semântico. Use fusões Power Query, junções SQL ou transformações de cadernos para combinar as tabelas normalizadas numa única dimensão.

Preservar a estrutura dos flocos de neve

Em alguns casos, manter a estrutura normalizada faz sentido:

• A hierarquia dimensional tem múltiplos níveis, e o achatamento criaria dezenas de colunas redundantes.
• Múltiplas tabelas de factos partilham tabelas de subdimensão (como uma tabela de Categorias partilhada usada tanto por factos de Vendas como de Inventário), e a desnormalização criaria cópias inconsistentes.
• A segurança ao nível de linha precisa de ser aplicada a um nível específico da hierarquia.

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

Quando usar modelos compostos para cenários de origem cruzada

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

• Tabelas de factos numa casa de lago com tabelas de dimensões mantidas num armazém.
• Dados em streaming em tempo real de uma casa de eventos combinados com dados históricos numa casa de lago.
• Dados de referência de uma fonte externa (Import) combinados com tabelas de factos nativas do Fabric (Direct Lake).

Nestes cenários, configure o modo de armazenamento de cada tabela de forma independente e verifique se as relações entre fontes funcionam de forma aceitável nos volumes de dados esperados.