Para o Exame DA-100 precisamos entender todo o funcionamento dos relacionamentos, mas aqui eu vou pontuar alguns tópicos que acho mais importantes:
- Both, relacionamentos bi-direcionais
Relacionamentos bi-direcionais são perigosos se vc não sabe exatamente o que está fazendo. Relacionamentos bi-direcionais podem causar ambiguidade no seu modelo de dados. O que é ambiguidade? É quando seu modelo tem mais de uma rota para filtrar uma mesma tabela e, com isso, pode gerar valores diferentes, literalmente exibindo números diferentes de acordo com a rota que seguir.
Direcionamento indica o sentido do filtro de uma tabela na outra, então em um modelo com direção única o que temos são tabelas dimensão filtrando tabelas fatos, mas não o contrário. Daí acaba acontecendo que nos slicers, nos filtros do relatório do power bi, as opções do filtro da dimensão não são afetados pelos resultados da fato, porque somente a dimensão filtra a fato e não vice-versa.
Daí o pessoal querendo filtrar os slicers da dimensão de acordo com a seleção que fazem na fato aplicam filtros bi-direcionais, mas existem outras formas de tratar isso no Power BI, não precisa ser necessariamente usando relacionamentos bi-direcionais. Vc pode fazer isso “visual level filters” nos slicers, por exemplo.
Para mais detalhes sobre esse tópico: https://www.sqlbi.com/articles/bidirectional-relationships-and-ambiguity-in-dax/
Uma forma muitas vezes mais segura de se utilizar filtros bi-direcionais, ou CROSSFILTER é através da função CROSSFILTER. Nessa função vc precisa passar uma relação que exista e mudar a direção dela. Exemplo:
#Customers CrossFilter =
CALCULATE (
COUNTROWS ( Customer ),
CROSSFILTER ( Sales[CustomerKey], Customer[CustomerKey], BOTH )
)
Na measure acima o que fizemos foi contar as linhas da tabela dimensão Customer usando o filtro entre a tabela Customer e a tabela Sales, porém com direção tipo BOTH. Isso vai possibilidade que os filtros aplicados na tabela fato Sales sejam aplicados à tabela dimensão Customer, logo iremos fazer COUNTROWS de Customer de acordo com filtros da fato Sales.
- Assume Referential Integrity
Essa opção só funciona no modo Direct Query e vem por padrão inativa. O que acontece é que, quando vc ativa essa opção o Power BI passa a tratar os JOINS entre as tabelas como INNER JOIN, já com essa opção inativa ele trata como LEFT JOIN. Ou seja, se vc ativar esteja certo de que o INNER JOIN vai funcionar para vc, caso contrário, vc deixará de ver qualquer registro que esteja null de algum lado do relacionamento. Claro que, ativando essa opção suas consultas vão ficar mais rápidas.
Para que Referential Integrity funcione bem você precisa garantir que a tabela de cima (ou a tabela do from) não tenha valores blanks ou nulls, e que a tabela de baixo (ou a tabela do to) possua todos registros de referência.
Por exemplo, no caso da relação com a tabela Depots descrita acima, resultaria no seguinte:
Um visual mostrando o total Order Qty mostra um valor de 40
Um visual mostrando o total Order Qty by Depot City mostraria um valor total de apenas 30, pois não incluiria a ID de pedido 1, onde DepotID é nulo.
- Apply Security Filter in Both Directions
Ativando essa opção o que acontece é que, mesmo em relacionamentos que sejam bi-direcionais, ou seja, aqueles relacionamentos com direção tipo both, ao tratar filtros de Row Level Security esse relacionamento será tratado como SINGLE direction. A razão para isso é que, ao aplicar um filtro de RLS numa dimensão, você provavelmente não queira filtrar outras dimensões automaticamente indiretamente.
Por exemplo, imagine que você criou um RLS para tabela de Geografia, de forma que vc quer que apenas as pessoas do Brasil vejam as vendas do Brasil, só que vc não quer que automaticamente sejam excluídos também os produtos que não foram vendidos no Brasil, vc quer ver esses produtos. Por isso, ao ativar essa opção o direcionamento do relacionamento passa a ser SINGLE.
- Múltiplos relacionamentos entre tabelas e Role Playing Dimensions
No Power BI apenas um relacionamento pode estar ativo por vez, porém podem haver momentos em que uma tabela se relaciona com outra várias vezes, por exemplo a tabela de data com a fatoVenda… Na fatoVenda pode ter data da venda, data da compra, data da emissão, cada uma dessas datas pode se relacionar com a dimensão data, porém só uma estará ativa.
Uma das formas mais indicadas para tratar esse cenário é criar medidas específicas para ativar os relacionamentos quando necessário, ou seja, se você precisa ver a quantidade de vendas pela data da venda e também pela data da compra vc pode usar a data da venda como relacionamento ativo, logo relacionamento padrão, e também adicionar uma measure para data da compra, assim:
#vendas por data da compra =
CALCULATE(
SUM(vendas[vendas]),
USERELATIONSHIP (date[datekey], vendas[data da compra] )
)
A função USERELATIONSHIP vai ativar a relação inativa e somar as vendas de acordo com essa relação.
Outra função que pode ser usada é o TREATAS, nesse caso você nem precisa ter uma relação inativa, o TREATAS vai criar a relação em tempo de execução. Exemplo:
#vendas por data da compra =
CALCULATE(
SUM(vendas[vendas]),
TREATAS ( VALUES(date[datekey]), vendas[data da compra] )
)
Nesse exemplo do TREATAS o que fizemos foi criar uma tabela em tempo de execução de date[datekey] e relacionar ela com vendas[data da compra], e com esse relacionamento virtual então fazemos o SUM de vendas[vendas].
Outra forma de lidar com múltiplos relacionamentos é implementando o que chamamos de Role Playing Dimensions. Role Playing Dimensions consiste basicamente em duplicar a tabela dimensão.
Ou seja, no nosso exemplo acima, em que temos a tabela dimensão Data relacionada com a fatoVendas várias vezes porque temos relacionamento pela data da venda, pela data da compra e pela data da emissão significa que teríamos 3 tabelas de dimensão data, uma tabela data-venda, outra tabela data-compra e outra tabela data-emissão.
Essa abordagem é bastante confusa para um usuário final e o uso de measures geralmente é mais recomendado.
- Weak Relationships
Falei mais sobre Weak Relationships nesse outro post aqui.
Weak Relationships acontecem quando temos relacionamentos do tipo muitos para muitos (N:N) e quando temos relacionamentos de qualquer tipo entre entidades via IMPORT e entidades via DIRECTQUERY.
Um relacionamento em um modelo de tabela (tabular model) pode ser STRONG ou WEAK. Em um relacionamento forte (strong), o mecanismo sabe que o lado ONE do relacionamento contém valores exclusivos. Se o mecanismo não puder garantir que o lado ONE do relacionamento contenha valores exclusivos, o relacionamento será fraco (weak).
Weak Relationships tem as seguintes restrições:
A função DAX RELATED não pode ser utilizada para trazer informações do lado UM (from).
Aplicar Row Level Security tem restrições de topologia
Strong relationships são materializadas durante o tempo de refresh dos dados criando “data structures” otimzadas que reduzem o tempo de join das tabelas em tempo de query (consulta). Essas “data structures” não são criadas para Weak relationships.
Uma característica muito importante nas Weak Relationships é de que nelas valores blanks não são apendados ao lado ONE caso o relacionamento não seja válido. Em Strong Relationships, sempre que existe um relacionamento onde no lado many existam dados que não estejam relacionados no lado ONE, então o power bi adiciona um registro blank no lado ONE, de forma que vc não perca esses dados quando for construir um gráfico ou tabela, por exemplo. Isso não acontece em Weak Relationships.
Olhe esse modelo:
Na imagem abaixo você tem um cenário ideal, onde todos BRANDS tem relacionamentos nas SALES AMOUNT e também na WEAK AMOUNT, ou seja, existe no relacionamento entre Product e Sales e Product e Sales Weak dados válidos para todos registros.
Só que, se você apagar da tabela PRODUCT todos registros do tipo BRAND = WIDE WORLD IMPORTERS, o que vai acontecer é isso:
Perceba que na relação Strong, da primeira coluna Sales Amount, o valor continuou aparecendo, porque o Power BI colocou blanks no lado One pra compensar. No entanto, na Weak Relationship isso não acontece e acabamos perdendo esses valores, o que gera um resultado completamente errado.
- Relacionamentos Muitos para Muitos (N:N)
Falei mais sobre Many to Many Relationships nesse outro post aqui!
Relacionamentos N:N entre dimensões, devem ser tratados usando CROSSFILTER BOTH.
Relacionamentos N:N entre dimensões e fato podem ser tratadas usando TREATAS ou com relacionamento N:N usando SINGLE direction.
Para entender melhor como funcionam relacionamentos muitos-para-muitos, ou N:N, precisamos entender o contexto dos dados e como funcionam as direções dos filtros.
Via de regra, evite utilizar filtros bi-direcionais. Quando esta for sua única escolha prefira optar pela função DAX CROSSFILTER. Esse cenário geralmente ocorre quando você tem um relacionamento entre duas dimensões com uma tabela no meio (bridge-table ou factlessFact table) e quer filtrar uma tabela fato através de uma dimensão que não chega na fato, mas que se relaciona com outra dimensão que, essa sim, se relaciona com a fato. Nesse caso um filtro BOTH entre as duas dimensões resolve o problem, pois permite que seu filtro navegue da dimensão que não se comunica com a fato até a próxima dimensão, que essa sim se comunica com a fato e então passa seu filtro até a fato. Isso se aplica a um cenário como o da imagem abaixo.
Quando estiver em uma situação de N:N em que não exista uma terceira tabela ou bridge-table, vc pode criar um relacionamento N:N desde que o filtro seja SINGLE e na direção saindo da dimensão e apontando para fato. Uma outra opção nesse caso seria utilizar o DAX TREATAS, onde vc pode criar um relacionamento virtual, ou seja, suas tabelas não precisam se relacionar e vc ainda consegue criar um relacionamento entre elas. Uma terceira opção, mais complexa e mais performática, é criar uma bridge table com DAX e relacionar essa bridge-table entre sua dimensão e fato, como nesse exemplo:
Mais sobre relacionamentos muitos para muitos: https://www.sqlbi.com/tv/different-types-of-many-to-many-relationships-in-power-bi/
Pedro Carvalho 
3 thoughts on “Power BI Relationships”