Dimensões Irregulares no Power BI

Olá, alguém poderia me ajudar?

Oi Daniel,

Não tenho conhecimento técnico em BI, mas achei esses artigos que podem te ajudar:

https://stoneridgesoftware.com/creating-hierarchies-in-power-bi/

https://docs.microsoft.com/pt-br/power-bi/desktop-inline-hierarchy-labels

Pedi para o time de produção enviar sua dúvida para um reply mais técnico, ok?

Desculpe não conseguir ajudar mais,

Abcs

Natan, infelizmente estes links não ajudam, eles só servem para dimensões regulares. Vou aguardar a resposta do time de produção.

Alguma posição do time de produção?

Daniel

Aqui irei tratar de coisas que não foram discutidas neste curso. Elas farão parte de um curso de Power BI avançado ainda em planejamento.

Mas, para não deixa-lo sem resposta, vai 3 maneira de fazer isto. Duas através dos dados e uma terceira dentro do próprio Power BI.

Seja o seguinte exemplo:

Arquivo FUNCIONARIO:

(TABELA 1 - Ver nos posts a seguir esta tabela)

Traduzindo para tabela teremos:

TABELA: Funcionario.

(TABELA 2 - Ver nos posts a seguir esta tabela)

Hierarquia

(TABELA 3 - Ver nos posts a seguir esta tabela)

No Curso de Power Bi não vimos este processo de trabalhar com hierarquias Pai-Filho.

O dado tem que chegar no Power Bi de forma hierárquica. Logo você deve proceder da seguinte maneira:

A) No Processo de ETL transformar o dado de Pai-Filho em hierárquico, ou seja:

Tabela Transformada dentro do DW.

(TABELA 4 - Ver nos posts a seguir esta tabela)

B) Construir um OLAP usando o Microsoft Analyiss Services. Lá é possível criar uma dimensão PAI-FILHO. No Analysis Service você irá determinar o nome dos níveis e de quantos níveis a transformação de PAI-FILHO para hierarquia terá.

Um exemplo é no vídeo:

C) Podemos efetuar transformações no POWER BI. Não é o mais indicado porque você está transferindo para a ferramenta de relatório a transformação do dado. Para mim o POWER BI deve apenas exibir a informação e não transforma-la.

Mas OK. E se eu quiser fazer isso? Transformar dentro do POWER BI?

a) Carregar a tabela PAI-FILHO para o Power BI b) Ir em Data View c) Crie uma nova coluna (New Column) d) Coloque como fórmula desta nova coluna usando a linguagem DAX (Não vista no nosso treinamento):

Path = PATH(Funcionario[Nome],Funcionario[Nome Chefe]).

Teria então:

(TABELA 5 - Ver nos posts a seguir esta tabela)

Depois ir criando coluna por coluna para cada nível:

Level 1 = PATHITEM(Funcionario[Path],1) Level 2 = PATHITEM(Funcionario[Path],2) Level 3 = PATHITEM(Funcionario[Path],3) Level 4 - PATHITEM(Funcionario[Path],4)

Terá então:

(TABELA 6 - Ver no post a seguir)

Com as colunas Nível 1, 2 3 e 4 você irá trabalhar os seus Dashboards.

Att

Victorino.

TABELA 1

TABELA 2

TABELA 3

TABELA 4

TABELA 5

TABELA 6

Perfeito, antes de fechar o tópico, poderia me esclarecer só mais uma ultima coisa, "Guy in a cube" e "Guru do Excel" falam muito de utilizar a linguagem M para obter dados do BI, enquanto aqui na Alura e muitos outros profissionais mais clássicos utilizam mais a metodologia do Microsoft Visual Studio (MVS)/SQL. Além das opções de "dimensão de alteração lenta" de histórico e fixo, quais são as vantagens que você Victorino Vila vê em utilizar MVS quando comparado com a linguagem "M", que ao meu ver é uma linguagem simples de se entender, devido à UI simplificada que o Power Query proporciona?

Daniel

Para mim como devemos proceder para a construção de um BI:

• Modelagem
• Construção de um Dw
• ETL para deixar o dado pronto no DW
• OLAP baseado no DW se necessário
• Dashbords para visualizar o DW

No que diz respeito ao último tópico ferramentas de Dashboards devem apenas exibir os dados existentes no DW sem nenhuma, ou com pouca transformação. Porque?

Nas empresas o ETL é a regra de negócio e não deve ficar sobre a esfera de quem faz o relatório. Isso porque o usuário pode não consultar o dado apenas através do Power Bi mas podemos ter DWs sendo consumidos por Tableau, QLIK, ODBC direto pelo Excel, na mesma empresa, no mesmo DW, e o número a ser exebido deve ser o mesmo. Se eu uso uma linguagem como DAX ou M para transformar o dado na camada de exibição, o outro usuário, que usa outra ferramenta, ou repete o mesmo no seu relatório ou vai ver coisas diferentes. E então a regra de negócio definida pela empresa para um indicador fica inconsistênte.

Quand me merguntam sobre o que é melhor, linguagem X ou Y, eu sempre respondo que a melhor linguagem é aquela que você domina. Isso porque, de modo mais fácil ou mais difícil, todas oferecem a mesma coisa.

Para mim o certo é: Em que momento do processo de construção do Bi você vai usá-la. Se o M é restrito ao Power BI eu sou contra. Se o SQL está restrito a preparação do dado, fora da camada de exibição, e sim na preparação do dado para o DW sou a favor.

Estes forum citados por você, como o próprio nome diz em um deles, as vezes, querem transformar o Power Bi em um grande planilhão. Num Bi sério o que menos devemos ter são planilhões.

Imagina que você tenha um BI, lindo e pefeito, com milhares de Dashboards sendo construído pelo Power Bi e, dentro dele, centenas de funções de transformações em DAX ou M, associados aos Dashbords lendo de fontes de dados diretamente do operacional. E então seu usuári o diz: Power Bi tá caro. Quero usar agora o Pentharo Dashboard que é free. Ferrou !!! Você vai ter que refazer tudo.

Ai a pergunta: Porque as ferramentas de Dash (E isso não se resumo apenas ao Power BI mas as outras também tem estas funcionalidades) disponibilizam estas ferramentas de transformações dentro delas? Isso chama-se capitalismo. O fabricante que manter você fiel a ferramenta. Por isso ele incentiva a proceder desta maneira, programando dentro do Dash, e dificultando uma futura migração. Ou então pessoas ou grupos de programadores e formadores de opinião incentivam o uso de A ou B para manter sua influencia dentro do cliente ou até mesmo para manter seu emprego com medo do novo ou de um desafio.

Por isso sigo a metodologia. Os instrumentos para implementa-la utilizo aquele que melhor convém, no momento, ou restrito ao que o cliente disponibiliza para minhas consultorias. Apenas seguindo os passos que repito abaixo:

• Modelagem;
• Construção de um Dw;
• ETL para deixar o dado pronto no DW;
• OLAP baseado no DW se necessário;
• Dashbords para visualizar o DW;

Um abraço

Victorino.

Victorino, muito obrigado, foi muito esclarecedor. Como a pergunta original era sobre dimensões irregulares, no PBI, marquei ela como resposta oficial, mas esse texto que redigiu é muito esclarecedor. Que tal eu refazer essa pergunta em um novo tópico para ficar mais fácil de outros estudantes da Alura encontrarem esse resposta se estiverem com alguma dúvida parecida?