(+351) 21 24 10006  ·  info@bconcepts.pt
Carnaxide, Lisboa

PL-300: dominar relações, cardinalidade e direção de filtro

João Barros 21 de July de 2026 4 min de leitura

Vou ensinar uma competência prática do PL-300: criar e gerir relações entre tabelas no Power BI — incluindo cardinalidade, direção de filtro e quando usar relações inativas. Esta capacidade é crucial no exame e na prática porque garante que os cálculos DAX e as visualizações mostrem resultados correctos.

O que precisas de saber

Um modelo de dados no Power BI liga tabelas através de relações. Cada relação tem pelo menos três propriedades importantes:

  • Cardinalidade: One-to-many (1:*), One-to-one (1:1) ou Many-to-many (*:*). A cardinalidade define como as linhas se correspondem entre tabelas.
  • Direção de filtro cruzado: Single (num sentido) ou Both (em ambos os sentidos). Decide como os filtros fluem entre tabelas e afectam medidas/visualizações.
  • Activa / Inactiva: Apenas uma relação entre duas tabelas pode estar activa; relações inactivas podem ser usadas temporariamente com DAX (ex.: USERELATIONSHIP).

Exemplo simples: uma tabela Sales (vendas) com CustomerID e uma tabela Customers com CustomerID. O cenário típico é um relacionamento 1 (Customers) → * (Sales), direção de filtro Single (dos Customers para as Sales). Se existir também uma tabela Dates, ligas Dates[Date] a Sales[OrderDate] com uma relação 1:* e geralmente marcas Dates como "Marked as date table" para time intelligence.

Como funciona / Na prática

Aqui tens um passo-a-passo prático no Power BI Desktop para criar e ajustar relações correctamente:

  1. Importa as tabelas: traz as tabelas Sales, Customers e Dates (podes usar o ficheiro de exemplo Contoso ou a sample database).

  2. Abre "Model" (Vista de Modelo) e arrasta a coluna chave (por exemplo Customers[CustomerID]) para Sales[CustomerID] para criar a relação automaticamente.

  3. Clica duas vezes na linha da relação e define a Cardinalidade (geralmente One-to-many) e a Direção de filtro cruzado (Single é o padrão seguro). Se tiveres uma dimensão e uma fact table, usa Single do lado da dimensão para a fact.

  4. Se precisares de filtrar em ambos os sentidos (por exemplo para tabelas de dimensão que interagem directamente), considera Both com cuidado — pode resolver cenários mas também causar ambiguidades e impacto na performance.

  5. Se existirem duas possíveis relações entre as mesmas tabelas (ex.: Sales tem OrderDate e ShipDate ligados a Dates), deixa uma relação activa (ex.: OrderDate) e cria a outra como inactiva. Para usar a relação inactiva num cálculo, usa USERELATIONSHIP em DAX.

Exemplo de medida DAX que activa temporariamente uma relação inactiva entre Sales[ShipDate] e Dates[Date]:

TotalSalesByShipDate =
CALCULATE(
  SUM(Sales[SalesAmount]),
  USERELATIONSHIP(Dates[Date], Sales[ShipDate])
)

Outra função útil é CROSSFILTER, que altera a direção de filtro entre duas tabelas dentro de um cálculo:

MeasureBothDir =
CALCULATE(
  SUM(Sales[SalesAmount]),
  CROSSFILTER(Customers[CustomerID], Sales[CustomerID], Both)
)

Nota: usar CROSSFILTER ou definir relações para "Both" pode aumentar o custo de processamento; usa apenas quando necessário para a lógica do relatório.

Erros comuns

  • Cardinalidade errada: definir Many-to-many quando existe uma chave única causa cálculos inesperados. Verifica sempre se a coluna do lado "one" tem valores únicos.
  • Direções Both indiscriminadas: activar Both sem compreender o fluxo de filtros pode levar a ambiguidade e a resultados incorrectos. Só usa Both quando entenderes as consequências no modelo.
  • Não usar relações inactivas correctamente: tentar representar dois contextos de data com duas relações activas entre Sales e Dates causa erro; em vez disso, mantém uma activa e usa USERELATIONSHIP para a outra.

Como praticar

Pratica com dados reais: importa um conjunto de vendas (Sales), clientes (Customers) e calendário (Dates) e constrói cenários que exijam relações alternativas (OrderDate vs ShipDate). Cria medidas que usem USERELATIONSHIP e compara resultados com relações activas. Testa também cenários com dimension tables relacionadas entre si (p.ex., Products e Categories) para perceber quando Both é necessário.

Para preparação para o PL-300, usa o Practice Assessment OFICIAL da Microsoft (é gratuito) para avaliar onde estás mais fraco. Consulta também a study guide oficial da Microsoft para o PL-300 (gratuita) — ambos fornecem orientação sobre as skills measured. Estes recursos são a fonte correcta para prática e planeamento de estudo.

Em resumo

  • Relações definem como filtros e agregações fluem no modelo — configura cardinalidade e direção com intenção.
  • Usa relações inactivas + USERELATIONSHIP para alternar entre contextos (ex.: OrderDate vs ShipDate).
  • Evita usar Both indiscriminadamente; pode resolver problemas mas também introduzir ambiguidades e custos de performance.
  • Pratica com o sample dataset e usa o Practice Assessment e a study guide oficiais da Microsoft para orientar a preparação.