PL-300: dominar relações, cardinalidade e direção de filtro
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:
Importa as tabelas: traz as tabelas Sales, Customers e Dates (podes usar o ficheiro de exemplo Contoso ou a sample database).
Abre "Model" (Vista de Modelo) e arrasta a coluna chave (por exemplo Customers[CustomerID]) para Sales[CustomerID] para criar a relação automaticamente.
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.
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.
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.