Resultados de busca

Recente os dataholics tiveram um desafio e não encontraram nenhum material em português que pudesse ajudar a traçar o melhor caminho. Após muitas pesquisas, encontraram um conteúdo que o ajudaram a solucionar. A partir disso, com o objetivo de ajudar outros profissionais que possam passar pelo mesmo desafio, Luiz Otávio escreveu este artigo: Sumário Artigo em português Artigo em inglês Artigo em português Fala pessoal, tudo bem? Espero que sim. Sou Luiz Otávio, consultor de Business Intelligence aqui na Dataside e hoje, vou falar de uma solução construída no Power BI usando DAX. Essa solução se refere a um desafio que tivemos em um projeto junto ao nosso cliente. O desafio era: “Filtrar os últimos 12 meses de vendas a partir de um filtro de mês selecionado”. No primeiro momento pensei: “Wow, como farei isso em DAX?”. Vem comigo que te explico como resolver esse problema. Inicialmente, realizei diversos desenvolvimentos, nos quais infelizmente não tive sucesso. Procurei materiais em português e encontrei pouquíssimo conteúdo que pudesse me ajudar a resolver o desafio. Ou seja, há uma carência de material em solo brasileiro. Sendo assim, realizei pesquisas em inglês e, para minha sorte, encontrei o riquíssimo material do Jason Thomas em seu blog SQL Jason, o qual recomendo que você também consulte. E então eu já gostaria de dizer ao Jason: Obrigado, amigo!! Ok, vamos agora então ao desenvolvimento da solução. Entendendo os dados e o cenário: Primeiramente, observe que tenho duas tabelas: uma tabela fato denominada “fVendas” e uma dimensão, denominada “dCalendário”. Como podemos ver na imagem abaixo, há um relacionamento entre elas. E caso você não tenha uma tabela dimensão de Datas em seu modelo de dados, pare a leitura por aqui e crie uma. Posteriormente, observe que em minha tabela fato, há uma coluna de Mês/Ano. E é obrigatório tê-la. Você vai entender o porquê no último tópico do artigo “Visualizando o resultado”. Desenvolvendo o cálculo DAX: Vamos iniciar nossa medida DAX através de variáveis. Criando a primeira variável “MaxFacDate” –  basicamente pedimos ao Power BI que ignore o filtro de data que aplicamos no slicer e encontre o maior valor de Data na coluna Data Faturamento, da tabela fVendas. Depois, criamos outra variável – Essa variável, através da função ENDOFMONTH, nos permite encontrar o último dia do mês referente ao mês filtrado no slicer. E na nossa última variável – usamos a função EDATE para dizer assim ao Power BI: “Quero que você busque qual é o último dia de 11 meses atrás, com base no mês filtrado pelo slicer”. Observe que o primeiro argumento da função EDATE é a nossa última variável criada FDate. E para finalizar nossa solução, aplicamos um return. No return, dizemos assim ao Power BI: “Se, o maior valor de data na tabela fVendas for menor ou igual ao maior valor de data na tabela dCalendário E se, o maior valor de data na tabela fVendas for maior que a variável Edate, então eu quero que você faça um cálculo alterando o contexto de filtro da minha medida Soma de Vendas ignorando o filtro da tabela dCalendário. Caso nada disso seja verdadeiro, eu quero que você apenas retorne a medida Soma de Vendas, sem nenhuma alteração de contexto”. Visualizando o resultado: Observe o mês no slicer: Setembro/2018. Veja no gráfico os últimos 12 meses a partir do mês selecionado. Obs.: no eixo X do gráfico, deverá ser usado a coluna Mês/Ano da tabela fato e não da dimensão, pois no cálculo do return, pedimos que ele ignore qualquer filtro vindo da tabela dimensão dCalendário Isso é tudo pessoal. Espero que esse material possa ajudá-los, como também me ajudou. E mais uma vez, obrigado Jason Thomas, nos ajudou a criarmos um grande resultado de valor ao nosso cliente. ________________________________________________________________________________ Artigo em inglês Hey folks, how is everything? I hope you’re doing well. I am Luiz Otávio, Business Intelligence Consultant here in Dataside and today I’m going to speak about a solution built in Power BI using DAX. This solution refers to a challenge we had in a Project alongside our client. The challenge was: “Filter the last 12 months of sales from a selected month filter”. At first, I thought: “Wow”, how am I supposed to do that in DAX?” Hop in and I’ll explain you how to solve this problem Initially, I performed several developments which unfortunately were unsuccessful. I looked for materials in Portuguese, and found very few contents that could help me to solve the challenge. That is, lack of material on Brazilian soil. So, I did some research in English and luckily, I found the very rich material by Jason Thomas on his SQL blog Jason. So, I would like to say to Jason: Thank you, my friend. Ok, now let’s get to the development of the solution. Understanding the scenario First, notice that I have two tables: a fact table called fVendas and a dimension called dCalendar. As we can see in the image below, there is a relationship between them. And if you don’t have a Dates dimension table in your data model, stop reading here and create one. Later, note that in my fact table, there is a Month / Year column. And it is mandatory to have it. You will understand why in the last topic of the article “Visualizing the result”. Developing measure in DAX Let’s start our DAX measure through variables. Creating the first variable “MaxFacDate”. Basically, we asked Power BI to ignore the date filter we applied to the slicer and find the highest Date value in the Billing Date column of the fSales table. Then, we create another variable. This variable, using the ENDOFMONTH function, does not allow you to find the last day of the month for the filtered month in the slicer. And in our last variable, we used the EDATE function to say to Power BI, “I want you to have a lookup for the last day of 11 months ago, based on the month filtered by the slicer.” Notice that the first argument of the EDATE function is our last created variable FDate. And to end our solution, we apply a return. On the return, we say to Power BI: “If the largest date value in the fVendas table is smaller or equal to the largest date value in the dCalendar table And if the largest date value in the fVendas table is greater than the Edate variable, then I want you to do a calculation by changing the filter context for my Sum of Sales measure bypassing the filter in the Calendar table. If none of this is true, I want you to just return the Sum of Sales measure, without any change in context. Visualizing the result Observe the month in the slicer: September/ 2016. See the graph for the last 12 months from the selected month. Note: in the X axis of the graph, the Month / Year column of the fact table should be used and not of the dimension, since in the calculation of the return, we ask that it ignore any filter coming from the dimension table. That’s all folks. I hope that this material can help you as it helped me. And again, thanks Jason Thomas, you helped us to create a great result of value for our client.

Vamos de assunto técnico? O #dataholic Fábio Oliveira escreveu um artigo compartilhando conhecimentos valiosos. Bora conferir! Neste artigo mostrarei um caso onde precisei alterar algumas configurações que vem por default na instância SQL Server, independente de ser no Azure, Amazon ou On Premises. Ao tentar alterar os parâmetros referentes à paralelismo no RDS, me deparei com o seguinte erro: Ok, estranho, mas é assim que funciona por lá! Ao criarmos uma instância RDS, existe uma opção de Parameter Groups, como o próprio nome já diz, são grupos de parâmetros que associamos à nossa instância: Cada edição e versão do SQL Server no RDS, tem seu próprio Default para o Parameter Group, vamos verificar: Vá na sua instância RDS -> Configuration: Aqui você encontra todas configurações à nível de instância, fique a vontade para explorar esta tela. Percebam que o Cost Threshold for parallelism e o MAXDOP estão default: Agora ficou fácil resolver né? Só que não… Não conseguimos alterar o default do RDS: Com isso, precisamos criar um novo Parameter Group: Defina para qual família estará disponível este Parameter Group, o nome e a descrição: Com o Parameter Group criado, volte à tela para alterarmos os valores que precisamos: Defina os novos valores e clique em Save Changes: Próximo passo agora é associar o novo Parameter Group à nossa instância RDS: Vá até Database Options e escolha o novo: Aqui você tem opção de aplicar somente na sua janela de manutenção ou aplicar imediatamente: A instância ficará em Modifying. Porém não sofrerá nenhum shutdown. Após aplicar a modificação, para que seja de fato aplicada, é necessário realizar o reboot: Este sim causará a indisponibilidade para aplicar o novo Parameter Group: Após o reboot, as alterações foram salvas: Agora você tem seu Parameter Group com as configurações para aquela determinada instância. E se eu quiser alterar mais algum parâmetro, terei indisponibilidade novamente? Depende… Na tela do Parameter Group, a coluna Apply Type tem 2 tipos: Static Dynamic No Static, você pode alterar o valor, porém é necessário um reboot do servidor para surtir efeito. Já no Dynamic não é necessário reboot. Exemplo do fill factor, há indisponibilidade: Fontes: Working with DB parameter groups – Amazon Relational Database Service Modifying an Amazon RDS DB instance – Amazon Relational Database Service É isso pessoal, para mim é muito interessante compartilhar conhecimento e poder ajudar outras pessoas.  Espero que tenham gostado. Deixe seu like e compartilhe!

Você conhece os 5 V’s do Big Data? O #dataholic Lucas Costa escreveu um artigo para explicar melhor sobre eles. Bora conferir! Muitos já ouviram falar do famigerado Big Data, porém nem todos sabem o que exatamente define o termo. Big Data não é uma tecnologia específica e sim um conceito, porém existem tecnologias que nos auxiliam a executar este conceito com mais facilidade. Como é o caso do Databricks, ferramenta que utilizamos constantemente aqui na Dataside. Não entrarei no mérito de descrever as capacidades desta poderosa ferramenta neste artigo, acredito que a ele mereça uma postagem a parte. Portanto, se você tem interesse neste assunto, fique ligado em posts futuros aqui no nosso blog. Big Data em sua tradução literal não nos diz muita coisa, apenas que são “dados grandes” ou uma quantidade “grande de dados”.  Com isso, muitas interpretações errôneas do termo podem surgir. O objetivo desta postagem é clarear o que realmente define Big Data, os 5 V’s: Volume Velocidade Variedade Veracidade Valor O Big Data surgiu a partir da crescente quantidade de dados que geramos diariamente em nossas vidas e das diversas fontes em que estes dados são gerados. Um estudo da International Data Corporation (IDC) reportou que em 2018 existiam cerca de 33 Zettabytes de dados no mundo e estimam que até 2025 existirão cerca de 175 Zettabytes. Para conseguirmos visualizar melhor quão massiva é esta quantidade, podemos considerar que em média um computador pessoal possui um HD de 1 Terabyte de capacidade de armazenamento. 1 Zettabyte corresponde ao equivalente de 1 BILHÃO de Terabytes! Muita coisa né? Esta quantidade enorme de dados se encaixa em nosso primeiro V, o Volume. Nem todas as empresas possuem um volume tão massivo de dados, muitas não chegam na casa dos Terabytes. Volume não é a única característica importante para que seu negócio possa aplicar soluções de Big Data. Muitos acreditam que Big Data se refere unicamente ao tamanho da base, uma concepção errada e, infelizmente, comum. Agora olhe a sua volta. Quantos dos objetos que você possui já geraram dados? Quantos deles geram dados ativamente ou passivamente? Quantos sites e softwares que você utiliza capturam seus dados? Para você entender melhor do que estou falando, irei dar o exemplo de uma caneca que estou usando para tomar café enquanto escrevo. A primeiro momento, pode parecer que ela nunca gerou dados. Afinal, é só uma caneca. Ela não tem wi-fi ou coisas do tipo. E de fato a caneca em si nunca gerou. Porém desde o momento em que eu a comprei até a chegada dela em minha casa, diversos dados foram gerados. Como por exemplo: Utilizei meu celular para encontrar um site que vendia canecas e acessá-lo. Agora a Google sabe da minha busca e interesse em canecas. Eu naveguei no site, clicando em vários produtos. Agora o site sabe quais produtos eu tenho maior interesse e quais produtos recomendar para mim. Claro, considerando que o site faça recomendações inteligentes. Eu me cadastrei no site, fornecendo meus dados pessoais como nome, idade e endereço. Além de outros dados coletados pelos cookies do site. O vendedor recebeu meu pedido, armazenando e alterando dados do estoque e de vendas. O produto foi encaminhado para uma transportadora, que gerou dados desde o recebimento de meu produto até a entrega dele. Após eu ter recebido a caneca, recebi um e-mail solicitando uma avaliação do produto. E então eu o avaliei. Se levarmos em conta todos os tipos de dado que foram gerados, todos os dispositivos que geraram os dados e todos os formatos e fontes em que eles foram armazenados, temos nosso segundo V, a Variedade. Pense bem na velocidade em que todos estes dados são gerados. Não só por esta compra, mas por todas as outras pessoas que acessam a internet. Independentemente do que elas estejam fazendo. Pense na velocidade em que sua última compra online foi aprovada e na velocidade em que seu aplicativo de cartão de crédito gerou uma notificação em seu celular informando a origem da compra e seu valor. No quão rápida foi a atualização de seu saldo na aplicação. Questão de segundos, certo? Talvez até mesmo milissegundos. Pois aí entramos em nosso terceiro V, a Velocidade. O quarto V a ser abordado é a Veracidade. Veracidade nada mais é que a qualidade e precisão dos dados. Imagine o transtorno do vendedor ao descobrir que a caneca que estava sendo anunciada no site, a mesma que comprei, não está mais disponível no estoque. Os dados do site estavam desatualizados, mesmo que o processo de atualização do site seja feito de forma automática. Acontece que ocorreram diversas compras dessa caneca em um curto período e o processamento dos dados de venda é feito uma vez por dia. Ou seja, os valores que eram exibidos no site não eram os corretos e isso só iria mudar no dia seguinte. O transtorno é grande e poderia ser evitado se os dados fossem verídicos, precisos e atualizados em real-time. Agora imagine que este mesmo vendedor está analisando sua base de dados completa. Existem dezenas de milhares de dados, de diversos períodos e fontes, diversos setores e times. Para converter estes dados em insights, é necessário definir qual pergunta ele deseja responder. Nem toda informação armazenada é útil ou relevante para responder perguntas específicas do negócio. Saber filtrar e selecionar quais dados são úteis para tomada de decisão é um fator de extrema importância. Não é à toa que este é o nosso quinto e último V, o Valor. Valor que os dados geram para o negócio em si. Aqui na Dataside oferecemos soluções de Big Data para os mais diversos tipos de negócio! Ficou interessado? Que tal mandar uma mensagem para a gente? Pensou em dados, pensou Dataside!

Como vocês sabem, na #Dataside amamos compartilhar conhecimento, então o Rafael Bezerra escreveu um artigo especial para explicar melhor sobre como criar medida que apresente Dias, Horas, Minutos e Segundos. Boa leitura! Olá Gente, há algum tempo tive a necessidade de desenvolver uma medida que apresentasse Dias, Horas, Minutos e Segundos. Quando concluí, achei interessante compartilhar tal conhecimento com vocês! Então, vamos estudar como criá-la? Para não estender muito essa postagem, já trago o cálculo de horas em formato decimal. Nossa coluna explorada foi a [Tempo Dec] 2. No nosso exemplo, a Medida criada para apresentar somente horas reflete um total de: 3. Vamos a Prática! Precisei adaptar a lógica e extrair os dias, transformando a apresentação da informação do seguinte modo: A Medida foi desenvolvida por meio de variáveis e, possui 05 blocos de desenvolvimento, vamos comentá-los: Bloco 1: Extrair o inteiro da hora que está em formato [Tempo Decimal]. VAR Vl = SUM ( fDados[Tempo Dec] ) • realizando a soma total do tempo VAR vHr = INT(Vl) reservando apenas o inteiro da soma do tempo, que é a “hora” Com a Variável vHr tempos o total de Horas Bloco 2: Extrair os Segundos de Horas da diferença decimal do tempo [Vl] e calcular os Minutos e Segundos,               posteriormente obter o total em horas VAR vSegHora = (Vl-vHr)*3600 Reservamos a diferença decimal do tempo [Vl] e o inteiro da hora [vHr] e depois multiplicar por 3600 segundos que equivale a 1 hora. VAR vMinDec = Divide(vSegHora,60) Como já temos a hora em segundos, precisamos extrair os minutos. Portanto, dividimos por 60, pois 01 hora possui 60 minutos. VAR vMin = INT(vMinDec) Agora que já temos os Minutos em modo decimal, precisamos reservar o inteiro dele, que será nosso minutos. VAR vSegDec = (vMinDec-vMin)*60 Nesse cálculo, vamos obter a diferença dos minutos decimais e o seu inteiro para extrair os segundos. VAR vSeg = ROUND ( vSegDec, 0 ) Por último, vamos reservar o arredondamento dos Segundos da nossa Com o bloco 1 e bloco 2 temos o total de horas Bloco 3: Nesse bloco, iremos calcular os dias VAR vDiasDec = DIVIDE(vHr,24) Para obter os dias, chamamos a variável [vHr], construída no bloco 1, que são as horas por inteiro e dividimos por 24, que é o total de horas em um dia. VAR dd = IF(vHr>=24, INT(vDiasDec), 0) Usamos o a Função IF, para extrair os dias inteiros, onde: Se vHr>=24, termos 1 dia ou mais. Então, extrairmos os dias com função [INT(vDiasDec)] Se não for, significa que é menor que 24 horas. Então, significa que não haverá dias somente horas, portanto pedimos que retorne 0. Essa variável é o pulo do Gato! Bloco 4: Nesse bloco, iremos calcular as Horas. VAR hh = INT((vDiasDec-dd)*24) Vamos calcular a nossa hora, pegando o inteiro da diferença de [vDiasDec] pelo resultado da variavel [dd] multiplicando 24 horas. Bloco 5: Chegamos no Final, já temos todos os cálculos necessário. E Rafael, o que é preciso agora? Agora, vamos arrumar esses cálculos para eles se apresentarem bonitinhos no visual. Para evitar, que nossa medida retorne apenas [1] dígito em cada cálculo, criaremos variáveis para melhorar a visualização. A função [LEN] pesquisará os cálculos. Se a variável contiver [1] dígito, será adicionado a ela um “0” a esquerda, caso contrário, queremos apenas a própria variável. VAR vDD = IF ( LEN ( dd ) = 1, “0” & dd, dd ) VAR vHH = IF ( LEN ( hh ) = 1, “0” & hh, hh ) VAR vMM = IF ( LEN ( vMin ) = 1, “0” & vMin, vMin ) VAR vSS = IF ( LEN ( vSeg ) = 1, “0” & vSeg, vSeg ) Vamos criar nossa variável Sucesso? Fácil! Precisamos apenas concatenar as variáveis e convertê-las para inteiro. VAR TMP = CONVERT ( vDD & vHH & vMM & vSS, INTEGER  ) Pronto! Agora basta chamá-la RETURN TMP E Agora, Rafael? Simples, basta alterarmos o formato da medida para apresentar os Dias, Horas, Minutos e Segundos e posteriormente incluir no visual. Espero que esse conteúdo tenha te ajudado. Se você gostou, deixe o like e compartilhe. 🙂

Neste artigo, o dataholic Gabriel Carvalho aborda sobre dois caminhos para pensar visualmente para análise de dados. No meu último post “Aprenda a pensar visualmente” falei um pouco da importância do pensamento visual na hora de preparar uma visualização de dados. Se você ainda não viu, dá uma olhadinha: APRENDA A PENSAR VISUALMENTE (dataside.com.br) Com isso resolvi explorar melhor o conceito de pensamento visual para análise de dados e como podemos usar isso no nosso no dia a dia. Vamos lá: Recentemente estava lendo um livro chamado “Good Chart” do autor Scott Berinato, editor sênior na Harvard Business Review. Ele descreve uma maneira muito interessante de apresentar informações, inicialmente respondendo a duas perguntas iniciais: 1. A informação é conceitual ou baseada em dados? 2. Estou declarando algo ou explorando algo? Obs: Nesse post foquei em responder a primeira pergunta 😊 CONCEITUAL OU BASEADA EM DADOS O que essas duas palavrinhas querem dizer? As informações do tipo conceitual têm o significado de apresentar uma ideia e tem o objetivo de simplificar o conceito de algo. Por exemplo, conceito de funil de vendas de acordo com Rock Content: “O funil de vendas, também chamado de pipeline, é um modelo estratégico que mostra a jornada do cliente do primeiro contato com a sua empresa até a concretização da venda — em alguns casos, além dela. Em outras palavras, ele é uma representação do caminho que o cliente faz até fechar a compra. Um processo que consiste em conduzir ou acompanhar o seu cliente a partir do momento em que ele toma conhecimento de uma solução vendida pela sua empresa até o fechamento do negócio”. E geralmente esse conceito é traduzido da seguinte forma: Temos aqui uma visualização conceitual. Basicamente é trazer o conceito de algo para o formato visual, facilitando a leitura e entendimento. Já a informação do tipo Baseada em dados é o tipo de apresentação que estamos acostumados a fazer, baseada em estatística e tem o objetivo de informa algo (Qual foi meu faturamento no mês passado? Quantos produtos eu vendi no ano passado?). E esse tipo de informação é representada usando gráficos como na imagem abaixo: E qual o sentido de saber se a informação que você está querendo apresentar é conceitual ou baseada em dados? Como isso pode me ajudar? Algumas vezes um gráfico baseado em dados assume uma forma conceitual e vice-versa, e é nesse momento que o pensamento visual faz toda a diferença e exige muita criatividade sua. Vamos pegar o exemplo do funil de vendas. O gerente de marketing quer saber como está o desempenho de determinada campanha e ele tem como indicadores as etapas do funil de vendas: Visitas Leads Oportunidades Clientes Você provavelmente escolheria esse tipo de visual para apresentar essa informação né? rsrs É mais intuitivo, fácil, além de ser uma visualização padrão no Power BI, concordo plenamente!! Porém, podemos fazer da visualização de dados algo mais conceitual, juntando as duas coisas e gerar uma entrega totalmente personalizada, única e didática. Conseguiu entender a importância do conceito por trás dos dados? A análise de dados e o conceito das informações andam juntos. Se você gostou, deixe seu comentário para a gente saber e compartilhar mais conteúdos como esse!! Abraços 😊

O nosso dataholic, Igor Abdo, identificou uma dúvida muito comum durante as consultorias sobre qual seria a melhor versão do Power BI e escreveu uma artigo especial para abordar o tema. Confira! Falaaa pessoal! Só alegria? Então, o artigo de hoje, será sobre um assunto que pegamos muito em consultoria. “Igor, qual é melhor, Power BI Pro, Premium ou Embedded?” Ai minha resposta: “Depende” Let’s go folks. Vou explicar alguns conceitos bem básicos e tentar chegar em um raciocínio. Power BI Pro Neste caso, você adquire uma licença de desenvolvimento do Power BI. Este modelo de licenciamento é recomendado para empresas que não precisam de muitos usuários acessando a ferramenta. Ou seja, cada usuário que for desenvolver e que for consumir, precisa de uma licença Pro. Quando você adquire este recurso, em termos, você esta “alugando” uma máquina na nuvem da Microsoft para colocar seus relatórios, mas esta “máquina” não é exclusivamente sua, ou seja, você pode estar compartilhando recursos com outras empresas. Dependendo do tamanho dos reports ou necessidades de desenvolvimento, isto não importa muito. Você não terá alguns recursos exclusivos das demais licenças, mas a maioria das features estão disponíveis. Custo Inicial: U$9,99/mês por usuário. Power BI Premium Neste caso, você já estará em uma das melhores licenças do Power BI, em que você aluga uma “máquina” somente sua, ou seja, a sua empresa não compartilha recursos com as demais. Você terá muitas features exclusivas no licenciamento Premium, como relatórios paginados, uso de arquivos XMLA, processos exclusivos em Dataflow, e poderá alugar máquinas predefinidas com base dos seus relatórios. Neste caso, vale a pena, quando você tem mais de 500 usuários, ou tem uma massa muito grande de desenvolvimento. Caso queira, comente se quer saber mais sobre o Premium. Outra vantagem, é que os usuários que vão somente visualizar, não precisam de licenças Pro, e sim, somente a free. Só vai adquirir Pro, quem for desenvolver. Custo Inicial: U$ 5.000/mês + licenças Pro para quem for desenvolver. Power BI Embedded Este cara aqui tem recursos muito similares ao Premium, mas um dos pontos diferenciais, é que você contrata ele direto no Azure, e você paga por hora de uso, ou seja, se eu contrato uma máquina, eu tenho os recursos exclusivos, mas caso eu queira pausar, eu não pago por isto, sendo assim, só pago quando uso. Diferente no Premium, que usando ou não, é pago mensalmente. Outra vantagem, é que você pode inserir os reports do Power BI dentro de aplicações. Por exemplo, você tem um ERP e quer inserir dentro dele os relatórios do Power BI. Através de códigos, você faz toda a autenticação para inserir seus gráficos. Custo Inicial: U$ 735,91/mês ou U$1,0081/hora + licenças Pro para quem for desenvolver. PPU (preview) E temos o Power BI Premium Per User, mas este vamos deixar para um próximo post. Resumo da ópera. Tudo depende, depende de: · Quantidade de usuários que vão acessar; · Quantidade de relatórios; · Quantidade de perfomance necessária; · Uso ou não do Power BI em aplicações de terceiros. · Entre outros fatores. Nada esta gravado em pedra, e tudo é questão de análise. Ficou alguma dúvida? Deixe nos comentários. Abraços e até mais! PowerBI

O #dataholic Matheus Rafael escreveu um artigo que vai responder à essa pergunta bem frequente. Bora conferir?! Fala galera, tudo certo? Me chamo Matheus Rafael e em meu primeiro post no blog da Dataside escolhi compartilhar como resolver uma necessidade bem frequente quando desenvolvemos cálculos utilizando a linguagem DAX no Power BI. Preparados? Então, vamos lá! O total da minha tabela não é a soma das linhas, e agora? Digamos que eu precise criar uma tabela com o valor da venda por produto e fazer este mesmo valor ao quadrado. No Power BI então, inserimos em uma tabela a coluna Itens, o valor da venda e o cálculo para elevar ao quadrado. Assim, obtemos o seguinte resultado: Podemos notar que nos itens os valores aparecem perfeitamente, porém, o total não corresponde com a soma, como é na coluna Venda Total, pois, 115.000 deveria ser o resultado correto em Valor ao Quadrado. Portanto, como resolvemos? Este é um problema bem recorrente no dia a dia de quem desenvolve medidas em DAX, sejam das mais básicas, como a do exemplo apresentado, ou medidas mais complexas. Isto ocorre devido a forma como o Power BI faz o cálculo “por baixo dos panos”, pois ele percorrerá a tabela linha a linha e trará o resultado de acordo com esta característica, apresentado logo abaixo. Então, precisamos alterar o contexto da medida Valor ao Quadrado, para que o total seja a soma das linhas. Desta forma, utilizaremos três expressões bem conhecidas na linguagem DAX. A CALCULATE, SUMX e VALUES. Primeiramente, iniciaremos utilizando a SUMX e dentro do argumento Table, aplicaremos a VALUES com a coluna Itens. No argumento “Expression” da SUMX, inserimos a estrutura da medida Valor ao Quadrado dentro de uma CALCULATE, para que seja feita a transição de contexto do total para a soma das linhas. Então, temos o valor esperado no cálculo Total Ajustado. Podemos ler a medida Total Ajustado da seguinte forma: “Power BI, calcula pra mim a soma linha a linha (SUMX), dos Itens da tabela Produtos ( VALUES ( Produtos[Itens] ) ), alterando o contexto da soma de Venda Total ao quadrado ( Obs.: Este cálculo funciona tanto chamando a medida dentro da CALCULATE, quanto montando sua estrutura diretamente (como no exemplo mostrado acima), basta que indiquemos corretamente qual a coluna principal – VALUES ( Produtos[Itens] ). **Chamando a medida dentro da CALCULATE Espero que esta dica tenha te ajudado e continue ligado em nosso blog!!! #godataholics PowerBI dataholic dataside

Para quem ama as facilidades que a organização e a produtividade geram no dia a dia, o Microsoft Teams é uma ferramenta indispensável. A #dataholic Letícia Carvalho, escreveu um artigo em que compartilha como usamos a função de aprovação no time de marketing da Dataside e que você também pode usar com sua equipe, até mesmo em outros setores. Bora conferir? Eu já disse aqui que amo facilidades? Pois é! Eu vim de agências de publicidade, de multinacionais e também de projetos independentes. Algo que me despertava interesse era a organização e produtividade (algo que eu amo). Já utilizei alguns sistemas, planilhas compartilhadas e offline. Hoje, aqui na Dataside, eu utilizo os recursos da Microsoft para controlar pautas, jobs e aprovações. É um APP isso? Preciso usar o Flow? Eu achei que seria algo complexo, mas eu pesquisei e encontrei duas formas bem legais. Uma delas é utilizando o Power Automate (Flow | um processo um pouco mais longo) e utilizando a aplicação do próprio Teams (é dessa que vamos falar hoje!). São apenas 5 passos! 1- Instale o Microsoft Teams em seu computador. 2- Selecione a aba “Equipes“, no canto esquerdo. 3- Escolha o canal a inserir a aprovação: 4- Selecione a caixa “Nova Conversa”, no campo inferior do chat. 5- Ainda no campo inferior do chat, selecione o ícone que aparece três pontinhos “…”. Procure pelo APP “Aprovações”. 6. Selecione o APP “Aprovações” e siga os passos que aparecerão em sua tela: Nome da solicitação: Insira o nome do job, vai facilitar para os aprovadores. Aprovadores: Insira o e-mail dos responsáveis pela aprovação do job. Lembre-se: somente poderá aprovar, pessoas que fizerem parte do canal. Detalhes adicionais: Insira todos os detalhes que o receptor da mensagem (aprovadores) precisarão para entender o seu job. Exemplo: Legenda ou briefing. Anexos: Carregue o arquivo a ser aprovado. Aqui na Dataside nós utilizamos o Sharepoint. Respostas personalizadas: Aqui, você pode personalizar a respostas que o aprovador deverá escolher. Exemplo: “Ok”ou “Ajustar”. Sumário Prontinho! Prontinho! A sua solicitação foi enviada ao chat! Para aprovar, os aprovadores precisam clicar em “Exibir Detalhes” e aprovar ou não o job. Ah, você também pode “Exibir detalhes” e ver quem ainda não aprovou! OBS: você também pode criar um canal, no canto esquerdo da sua janela (onde aparecem as opções de Equipes, Chats e Atividades) se sua equipe toda precisar acessar esses materiais. A opção que expliquei é para aprovações em um único chat. Por hoje é isso, pessoal! Curtiu? Compartilhe com os amigxs 🙂 Gestão Liderança dataside dataholic

O dataholic Abraão Vasconcelos compartilhou com a gente seu conhecimento sobre o operador CUBE. Bora conferir?? Você já ouviu falar do operador CUBE no SQL Server? Para entender o que esse operador faz, vamos começar criando um sistema bastante simples de locação de carros. create table carro ( car_cod int not null primary key identity(1,1), car_marca varchar(50) not null, car_modelo varchar(50) not null ) insert into carro values (‘Toyota’, ‘Modelo 1’), (‘BMW’, ‘Modelo 3’), (‘Mercedes-Benz’, ‘Modelo 2’) create table cliente( cli_id int not null primary key identity(1,1), cli_nome varchar(1000) not null ) insert into cliente values (‘Cliente A’), (‘Cliente B’), (‘Cliente C’),(‘Cliente D’), (‘Cliente E’), (‘Cliente F’), (‘Cliente G’) create table locacao( loc_cod int not null primary key identity(1,1), loc_car_cod int not null references carro(car_cod), loc_cli_cod int not null references cliente(cli_id), loc_dt date not null ) insert into locacao values (1, 3,’2019-04-21′),(2, 3, ‘2019-05-31’),(3, 1, ‘2015-03-25’), (2, 4, ‘2016-04-15’),(3, 5, ‘2013-02-09’),(1, 2, ‘2014-12-04’),(3, 2, ‘2014-07-01’), (3, 2, ‘2019-07-11′), (3,4,’2019-01-10′), (1,3,’2014-06-14′), (1,3,’2014-09-08′), (3,4,’2015-02-18′), (3,1,’2015-12-17′),(1,3,’2013-11-15’) Agora imagine que nós precisamos montar um relatório capaz de agrupar todos os nossos dados por ANO e Marca. O objetivo deste relatório é trazer o número total de vezes que os carros de uma determinada Marca foram alugados em cada ano. Neste momento não nos interessa saber o modelo do carro. Conseguimos montar este relatório utilizando a cláusula GROUP BY. Agora imagine que precisamos exibir em nosso relatório o número total de locações para cada marca, esta nova informação considera todos os anos. E para deixar o nosso relatório mais completo, mostraremos o total de locações por ano, ou seja, não importa a marca, queremos saber o total em cada ano. Vamos resolver este problema pegando a consulta anterior e colocando as colunas do group by dentro do operador cube. Também vamos comentar a cláusula order by. Veja que as linhas com os valores que representam os totais mostram NULL para Ano e Marca. Vamos tratar estas duas colunas usando expressões CASE. E agora conseguimos ver o nosso relatório completo com a ajuda do CUBE! Não esqueça de digitar todos estes códigos no seu ambiente de testes! Gostou desse conteúdo? Deixe seu comentário para gente saber e compartilhar mais conteúdos com esse tema 😊

O dataholic Gabriel Carvalho produziu um conteúdo especial para te ajudar a entender melhor sobre visualização de dados. Bora conferir?! Fala pessoal!! Me chamo Gabriel, sou consultor de Business Intelligence e muito apaixonado por design e visualização de dados. Nesse meu primeiro post do ano eu gostaria de falar um pouco sobre como construir um bom gráfico e a importância disso. A visualização de informação sempre esteve presente no nosso dia a dia, em placas de trânsito, folders, anúncios na internet, aplicativos, etc. Principalmente nas empresas, que por traz dos dashboards e relatórios existe uma pessoa que irá tomar alguma decisão importante. É justamente esse ponto que eu irei me basear para este artigo. O que é um bom gráfico para tomada de decisão? O que eu devo considerar? Será que eu uso gráfico de barras ou gráfico de linhas? É melhor tirar o eixo Y e deixar os rótulos? Será que eu deixo essa informação em primeiro ou jogo ela lá pra baixo? São essas e milhares de outras dúvidas que eu tive quando estava construindo meus primeiros dashboards. Obs: Meus projetos sempre voltavam com pedidos para reorganizar os objetos na tela e ajuste de cores rsrs. CONSTRUINDO UM GRÁFICO Em todos os projetos que eu participei, sempre utilizei o PowerBI e de todas as minhas dúvidas a mais pertinente era: “Será que é melhor o gráfico de linhas ou de barras?”, “e como saber que um é melhor do que o outro?”. Existem técnicas e boas práticas para apresentar dados que dependem muito do objetivo do projeto e do dashboard. Na imagem abaixo você pode ver vários tipos de visualizações separadas por objetivo: E de fato isso é muito útil no dia a dia e me ajuda no desenvolvimento dos projetos. Com base nesse mapa mental podemos concluir que, se quisermos mostrar o faturamento de uma empresa por ano a melhor opção seria o gráfico de barras? A minha resposta para isso é…. depende!! Veja o exemplo abaixo: Se considerarmos as boas práticas, sim, esse é um bom gráfico. Ele está sem ruídos, a cor é agradável aos olhos, o título e eixo não estão chamando mais atenção do que o dado, possui rótulos discretos e conta uma boa história (queda no faturamento a partir de julho). Mas se o seu usuário quiser identificar a queda no faturamento de uma forma mais rápida e visual? Um gráfico de linhas pode suprir essa necessidade: Repare que a queda está mais visível no gráfico de linhas. Chamando muito mais atenção do que o gráfico de barras. Porém, não sabemos se realmente os dois gráficos estão cumprindo com seus objetivos. Para julgar o valor de uma visualização você precisa saber o contexto em que ela está inserida. Se a necessidade do usuário for de identificar as quedas e a variação do faturamento, o gráfico de linhas poderá ser o ideal. Se a necessidade for apenas de acompanhar o faturamento mês-a-mês, o gráfico de barras pode ser a melhor opção. O que importa é o contexto em que cada visualização está inserida!! E para entender esse contexto você deve fazer algumas perguntas de grande valor antes: · Quem quer ver isso? · O que eles querem? · O que eles precisam? · Que ideia eu quero transmitir? · O que eu posso mostrar? · O que eu devo mostrar? · Depois de tudo isso, como vou construir? A qualidade de uma visualização não é medida pelo quão bem ela segue as regras de apresentação apenas. Esse conteúdo foi útil para você? Deixe seu comentário para gente saber e compartilhar mais conteúdos com esse tema 😊

Preparem as anotações, porque com esse artigo escrito pelo #dataholic Lucas Porto, você vai aprender como importar dados do SQL Server 2019 para uma versão inferior. Fala pessoal, gostaria de compartilhar uma dica rápida com vocês. Essa vai para quem já se deparou com a situação de ter que realizar um restore em uma instância destino mais antiga que a de origem. Como sabemos, o SQL não possui a funcionalidade de realizarmos a restauração de um arquivo de backup padrão do SQL (.bak) para um outro servidor com um SQL mais antigo. Quando me deparei com essa situação, na qual foi solicitado uma restauração de um banco que estava em um SQL Server 2019 para um SQL Server 2008R2, não encontrei muitas soluções para isso. Irei escrever uma série de artigos indicando as maneiras mais simples e eficaz de fazer isso. Como primeiro caso, iremos utilizar o opção “Generate Scripts”, onde é possível transferirmos desde estruturas de tabelas até os próprios dados contidos nela. Esse método é indicado para banco de dados de poucos GBs, pois o tamanho do arquivo gerado pode inviabilizar a importação dele no banco de dados destino, devido ao longo tempo de execução. Para o exemplo, iremos utilizar o banco AdventureWorks, disponível no link abaixo: https://docs.microsoft.com/pt-br/sql/samples/adventureworks-install-configure?view=sql-server-2017 Primeiramente, devemos acessar a opção Generate Scripts, localizada na aba Tasks: Ao clicar, será aberto a tela abaixo, onde podemos clicar em avançar. Nesta etapa, podemos selecionar que objetos queremos importar como tabelas, views, procedures, entre outros: Como no nosso caso, iremos restaurar um banco por inteiro, deixamos a primeira opção selecionada e podemos avançar. Nessa próxima página, nos é mostrado diversas formas de salvarmos os scripts que serão gerados, porém, se salvarmos do modo que está, teremos apenas as estruturas das tabelas e objetos, onde os dados e outras configurações não existirão no conteúdo gerado. Para ajustarmos isso, devemos clicar em Advanced: Dentro dessa aba, podemos adicionar diversas opções em nosso script, onde definimos principalmente duas opções: “Script for Server Version” – A versão do banco de dados destino; “Types of data to script” – Onde escolhemos apenas os schemas, somente os dados ou ambos. Conforme o exemplo citado, iremos utilizar como banco destino um SQL Server 2008R2, exportando tanto os dados quanto os schemas: Após configurado, podemos dar um Ok e gerarmos o Script. No meu caso, irei importar para uma pasta existente em meu computador: Com isso, podemos avançar e confirmar as opções selecionadas: Após um tempo carregando, o script será gerado e estará disponível no caminho indicado. No nosso caso, o banco possuía 330MB e gerou um script com cerca de 780mil linhas, o que acaba sendo difícil de ser executado no SSMS. Desse modo, para executar o script no banco destino, preferi utilizar o sqlcmd, utilizando o “-i” para indicarmos onde estava nosso script (input) e o “-o” para indicarmos onde queremos a saída (output). Caso quisermos executar o comando no cmd via SQL Authentication, utilizaremos o comando abaixo: sqlcmd -S NomeDaInstância -U UserSQL -P Senha -i LocalDoArquivo -o LocalDaSaida Caso estejamos utilizando o modo de autenticação do Windows, utilizamos o comando abaixo: sqlcmd -S NomeDaInstância -i LocalDoArquivo -o LocalDaSaida Ao iniciarmos, a tela do cmd se manterá estática, porém podemos consultar o status através de nosso arquivo de output que foi criado: Esse processo pode demorar um pouco, dependendo do tamanho do banco de dados e do desempenho de seu hardware. No nosso caso, o processo durou cerca de 10 minutos. Após finalizado, o banco pode ser utilizado normalmente, onde os objetos já estão disponíveis para uso: É isso aí, pessoal. Esse foi um caso que ocorreu em meu dia a dia que achei interessante compartilhar, onde muitas vezes nos deparamos com essa situação e acabamos sem saída. Caso tenha ficado alguma dúvida, estou disposto a ajudar. Espero que tenham gostado e até mais! SQLserver

Com uma infinidade de dados gerados por dia, analisar e saber como usar tantas informações sem perder o que é importante acaba se tornando um desafio dentro das empresas. Por isso, é essencial o uso da tecnologia e, melhor, o uso da ferramenta certa. O Power BI é a ferramenta usada em Data Analytics, que garante vantagens como: Identificação de padrões; Tomadas de decisões de forma ágil; Desenvolvimento de produtos com assertividade; Elaboração de campanhas com alto engajamento. Com a análise de dados, as informações geradas ganham sentidos práticos essenciais para gerar ações que contribuam para o desenvolvimento de uma empresa. Poder visualizar os dados de forma prática, ágil e personalizada de acordo com cada necessidade, é possível com o Power BI. A ferramenta oferece recursos visuais para a construção de relatórios e gráficos analíticos, com a possibilidade de compartilhamento seguro entre equipes de setores diferentes por meio da nuvem. Ao total, o Power BI se apresenta de 8 formas diferentes. Para conhecê-las, é importante entender melhor sobre a interface do Power BI Desktop, como carregar os primeiros dados e criar os primeiros gráficos. Se você quer entender melhor sobre como o Power BI pode influenciar no crescimento do seu negócio, entre em contato com a gente! #powerbi #dataanalytics #dadosinteligentes #dataside #dataholics