Migrando do SQL para o Pandas – Parte 2

No primeiro post sobre esse assunto, falei sobre como implementar no Pandas o SELECT e também as clausula WHERE. Para acessar a primeira parte é só clicar aqui.

Agora vou mostrar como tratar funções de agrupamento, junções e uniões.

Group By

O GROUP BY é utilizado para separar os registros selecionados em grupos específicos. Com os agrupamentos criados, podemos aplicar as funções de agregação, que podem ser contar os registros do grupo, somar valores, valores máximos e mínimos e etc.

Vamos a um exemplo

No código abaixo, contamos os registros agrupados pela coluna sex.

SELECT sex, count(*)
FROM tips
GROUP BY sex;
/*
Female     87
Male      157
*/ 

O equivalente no Pandas pode ser:

In [18]: tips.groupby('sex').size()
Out[18]: 
sex
Female     87
Male      157
dtype: int64

Perceba que no pandas usamos size() e não count(). Isso acontece porque count() é aplicado a cada coluna, retornando o número de registros não nulos de cada uma.

Também é possível a busca de várias agregações em uma única instrução. Nesse caso, devemos utilizar a função agg() e passar um dicionário com as colunas e a função desejada. Bem de boa:

SELECT day, AVG(tip), COUNT(*)
FROM tips
GROUP BY day;
/*
Fri   2.734737   19
Sat   2.993103   87
Sun   3.255132   76
Thur  2.771452   62
*/
In [21]: tips.groupby('day').agg({'tip': np.mean, 'day': np.size})
Out[21]: 
           tip  day
day                
Fri   2.734737   19
Sat   2.993103   87
Sun   3.255132   76
Thur  2.771452   62

Inner Join

Utilizadíssimo nos selects, o inner join é um tipo de junção que busca apenas os dados que existem nas duas tabelas juntadas. Vamos considerar os seguintes DataFrames como exemplo:

In [23]: df1 = pd.DataFrame({'key': ['A', 'B', 'C', 'D'],
   ....:                     'value': np.random.randn(4)})
   ....: 

In [24]: df2 = pd.DataFrame({'key': ['B', 'D', 'D', 'E'],
   ....:                     'value': np.random.randn(4)})
   ....: 

Assumimos que temos as mesmas tabelas na base com a mesma estrutura

SELECT *
FROM df1
INNER JOIN df2
  ON df1.key = df2.key;
# merge performs an INNER JOIN by default
In [25]: pd.merge(df1, df2, on='key')
Out[25]: 
  key   value_x   value_y
0   B -0.282863  1.212112
1   D -1.135632 -0.173215
2   D -1.135632  0.119209

O método merge()permite também que o join seja feito por colunas com nomes diferentes:

[in] df1 = pd.DataFrame({'fruta': ['maçã', 'laranja', 'pera', 'pêssego'],
                    'value': [1, 2, 3, 5]})
[in] df2 = pd.DataFrame({'alimento': ['maçã', 'pão', 'pera', 'pêssego'],
                    'value': [5, 6, 7, 8]})
[in] df1.merge(df2, left_on='fruta', right_on='alimento', 
                        suffixes=('_fruta', '_alimento'))
  
[out]
        fruta	value_fruta	alimento	value_alimento
0	maçã	1	        maçã	        5
1	pera	3	        pera	        7
2	pêssego	5	        pêssego	        8

Left (Outer) Join

O left join traz todos os registros da primeira tabela declarada (da esquerda) e se houverem dados tabela relacionada também serão projetados. No exemplo, utilizo o mesmo data frame do inner join. No pandas, o tipo de junção é passada no parâmetro how do merge().

-- mostra todos os registros de df1
SELECT *
FROM df1
LEFT OUTER JOIN df2
  ON df1.key = df2.key;
# mostra todos os registros de df1
In [28]: pd.merge(df1, df2, on='key', how='left')
Out[28]: 
  key   value_x   value_y
0   A  0.469112       NaN
1   B -0.282863  1.212112
2   C -1.509059       NaN
3   D -1.135632 -0.173215
4   D -1.135632  0.119209

Union

No pandas temos o mesmo resultado usando a função concat().

In [31]: df1 = pd.DataFrame({'city': ['Chicago', 'San Francisco', 'New York City'],
   ....:                     'rank': range(1, 4)})
   ....: 

In [32]: df2 = pd.DataFrame({'city': ['Chicago', 'Boston', 'Los Angeles'],
   ....:                     'rank': [1, 4, 5]})
SELECT city, rank
FROM df1
UNION ALL
SELECT city, rank
FROM df2;
/*
         city  rank
      Chicago     1
San Francisco     2
New York City     3
      Chicago     1
       Boston     4
  Los Angeles     5
*/
In [33]: pd.concat([df1, df2])
Out[33]: 
            city  rank
0        Chicago     1
1  San Francisco     2
2  New York City     3
0        Chicago     1
1         Boston     4
2    Los Angeles     5

Em SQL, UNION é similar do UNION ALL, porém o UNION remove os registros duplicados.

SELECT city, rank
FROM df1
UNION
SELECT city, rank
FROM df2;
-- notice that there is only one Chicago record this time
/*
         city  rank
      Chicago     1
San Francisco     2
New York City     3
       Boston     4
  Los Angeles     5
*/

No Pandas, o método drop_duplicates() pode ser usado em conjunto com o concat() para repetir esse comportado.

In [34]: pd.concat([df1, df2]).drop_duplicates()
Out[34]: 
            city  rank
0        Chicago     1
1  San Francisco     2
2  New York City     3
1         Boston     4
2    Los Angeles     5

Por hoje era isso…

Trouxe apenas um resumo do que me ajudou bastante a pensar mais como pandas e menos sql. Espero que possa ajudar mais alguém. Vou deixar o link da documentação do pandas, especificamente dessa parte, com vários outros exemplos.

https://pandas.pydata.org/docs/getting_started/comparison/comparison_with_sql.html?highlight=database

Um abraço e até a próxima 😊

Migrando do SQL para o Pandas

Eu acho a documentação do Pandas sensacional e tem um item que ajudou muito em converter meu raciocínio forjado no SQL para os objetos do Pandas.

Estou falando da página “Comparison with other tools”, que além do SQL mostra exemplos de R, SAS e Stata de forma simples e direta.

Vou mostrar alguns exemplos, mas recomendo a leitura diretamente na documentação para uma visão mais abrangente.

Select

Com certeza, a primeira palavra que digitamos quando começamos no SQL. Com este comando de DML, buscamos selecionar informações da base de dados. Podemos informar do SGDB quais as colunas a serem retornadas ou trazer todas usando o popular select * from table. No exemplo abaixo, buscamos algumas colunas da tabela tips, limitando a 5 linhas de retorno:

SELECT total_bill, tip, smoker, time
FROM tips
LIMIT 5;

No Pandas o mesmo resultado é obtido passa uma lista de nomes de colunas para nosso DataFrame:

In [6]: tips[['total_bill', 'tip', 'smoker', 'time']].head(5)
Out[6]: 
   total_bill   tip smoker    time
0       16.99  1.01     No  Dinner
1       10.34  1.66     No  Dinner
2       21.01  3.50     No  Dinner
3       23.68  3.31     No  Dinner
4       24.59  3.61     No  Dinner

Where

As vezes esquecido nos updates e deletes (brincadeira!), a cláusula WHERE no SQL especifica que uma instrução deve afetar apenas as linhas que atendem aos critérios especificados. No exemplo abaixo, queremos ver todas as linhas da tabela tips onde o time for igual a dinner.

SELECT *
FROM tips
WHERE time = 'Dinner'
LIMIT 5;

No Pandas, o DataFrame pode ser filtrado de várias maneiras. A mais intuitiva é usando a indexação booleana, que não vem ao caso agora. Vamos ao código:

In [8]: tips[tips['time'] == 'Dinner'].head(5)
Out[8]: 
   total_bill   tip     sex smoker  day    time  size
0       16.99  1.01  Female     No  Sun  Dinner     2
1       10.34  1.66    Male     No  Sun  Dinner     3
2       21.01  3.50    Male     No  Sun  Dinner     3
3       23.68  3.31    Male     No  Sun  Dinner     2
4       24.59  3.61  Female     No  Sun  Dinner     4

Esse post tá ficando maior do que eu imaginei. Vou quebra-lo em algumas outras partes para não cansar 😁

Em seguida, vou trazer exemplos de GROUP BY, JOIN, UNION, funções de agregação, UPDATE e DELETE.

Até breve!

Como quebrar linha no IBM DB2

Quando for necessário uma quebra de linha para utilização em um select ou atualizar um campo a maneira mais fácil é concatenar os caracteres ‘CR LF’, na prática fica assim:

SELECT 'LINHA1' || chr(10) || chr(13) || 'LINHA 2' FROM SUA_TABELA

Resultado

Como quebrar linha no db2

 

 

 

 

 

 

Até a próxima

O que você precisa saber antes de contratar um sistema de gestão para sua empresa

Eu costumo dizer que software é o resultado de uma série de pensamentos lógicos que são automatizados a fim de resolver problema de forma rápida e com menor custo, ou, resumidamente, um raciocínio materializado.

Um dos problemas dos sistemas de gestão que tenho visto é baixa capacidade de adaptação ou evolução. Se o software é o fruto de um raciocínio e o raciocínio muda, nada mais obvio que o sistema evoluir junto. Porém, o cenário que temos em muitas empresas não é exatamente esse. Isso pode acontecer por vários fatores mas existem dois, em especial, que, na minha opinião, resumem tudo.

o que voce precisa saber antes de contratar um sistema de gestao para sua empresa

O primeiro é a finalidade do projeto, isto é, qual problema deve ser resolvido. Um exemplo da minha vida profissional é o Sapu2.0, da Universidade Católica de Pelotas onde trabalhei durante alguns anos. O sistema foi desenvolvido com o foco no aluno e no professor. E cumpria perfeitamente essa função. Com o passar do tempo, foi incorporando funcionalidades administrativas da Universidade, o que o fez perder as caraterísticas iniciais, parando de evoluir nas suas funções originais e crescendo como um anexo de luxo ao ERP da UCPel. O motivo disso é simples: era mais fácil, mais rápido e mais barato desenvolver no Sapu do que em qualquer outra plataforma (pensando apenas em custos de desenvolvimento) e o resultado foi um sistema mediano, que deixou de atender bem aos alunos e aos professores, não acompanhando a evolução do ensino, e, também, burocratizando os processos administrativos, uma vez que os usuários precisavam consultar/replicar informações no Sapu e no ERP. Hoje em dia, tanto o sapu2.0 quanto o ERP foram descontinuados e substituídos por um sistema próprio desenvolvido internamente na Universidade.
Já o segundo fator é a capacidade de evolução do sistema como um todo. O gestor, no momento da contratação, precisa ter em mente que os modelos de trabalho e negócio mudam, às vezes radicalmente e num curto período de tempo, e ele não poderá esperar meses por uma atualização que adapte o software à nova realidade (que já pode ser outra no momento da entrega). Por isso, o sistema deve ter, como característica fundamental, uma alta capacidade de parametrização. Possibilitando inclusive, a alteração de regras de negócio em alto nível, ou seja, sem a necessidade de programação.

Esses dois fatores podem ser evitados se forem levados em consideração na definição da arquitetura do sistema. Infelizmente, essa etapa é muita das vezes atropelada pelo curto prazo de entrega do projeto, onde a programação, em si, é priorizada. Acontece também pelo fato da empresa fornecedora sempre utilizar o mesmo framework para todos os projetos, o que, muitas vezes, impossibilita a adesão de novas tecnologias e melhores práticas de desenvolvimento.

Apesar disso, amigo gestor, o mais importante é que o software de gestão esteja alinhado com o seu negócio e não o contrário. Se algum processo da sua empresa precisa ser modificado (de forma significativa) para se adequar ao sistema é hora de ligar o sinal de alerta.

Se você concorda, discorda ou tem algo a acrescentar, fique a vontade para comentar!

Curta a página da fourb no facebook!

 

Software é o que você xinga. Hardware é o que você bate! Mas porquê?

Já percebeu como ficamos irritados quando o sistema de gestão realiza uma operação diferente do esperado, ou pior, não executa a função solicitada e não resta  alternativa a não ser pegar o telefone e ligar para a TI?
Então ouve-se a frase: “você já abriu um chamado?” 💻 E a raiva só aumenta! 😂
Vamos analisar as razões disso tudo e entender como podemos melhorar a nossa relação com sistemas que amamos odiar!

Uma das frases mais manjadas nos ambientes de TI é: “Software é o que você xinga. Hardware é o que você bate!“. Quase todo mundo que trabalha diretamente com algum sistema de gestão já ouviu essa frase, mas você já se perguntou porque nos revoltamos tanto com os programas que usamos diariamente?

Desde o início da minha jornada como profissional de TI, há dez anos, ouço repetidamente as pessoas reclamarem dos sistemas que usam nos ambientes de trabalho. Nessa caminha já passei por diversas implantações onde pude observar alguns pontos comuns que quero compartilhar agora.

A primeira coisa que ouço é: “O sistema anterior era melhor! ” ou “Agora eu preciso fazer tudo isso pra gerar o relatório? Antes era só apertar F3!”. Talvez você, amigo leitor, já tenha falado, ou pelo menos pensado, isso.
Esse é um caso que eu chamo de Viúvos ou Viúvas de Sistemas e acontece muito. Normalmente, quando um novo software é implantado, uma série de processos (vou repetir muito essa palavra durante o texto) são revistos e melhorados, aliás no momento da implantação de um novo sistema é o período ideal para revisar e melhorar os processos da organização. Durante essa revisão dos procedimentos, problemas como retrabalho e falhas de comunicação são identificados, cabendo o novo software a função de resolvê-los. É aí que começa o ódio!

As pessoas se acostumam com uma forma (errada) de trabalhar, o que é restringido pelo novo sistema, e, portanto, se sentem obrigadas a realizar tarefas que antes eram esquecidas, mas de vital importância para o funcionamento da empresa. E o ódio ganha força.
Mas também acontece o inverso. Ainda na revisão dos processos, a política de acessos e disponibilização da informação pode ser alterada e algo que era livremente acessado pelos usuários fica restringido. Nesse momento, as linhas telefônicas do departamento de TI estão congestionadas de tanta gente ligando pra saber onde acessa o relatório, “que antes era só apertar F3!”.  😜

Claro que também não podemos nos redimir da responsabilidade. É papel sim do analisa de negócios/sistemas conduzir as análises para que o novo sistema entre da melhor forma possível em conjunto com as lideranças da empresa e, principalmente, durante a implantação trazer os usuários pra dentro do projeto. Eu vejo como um erro comum e gravíssimo dentro das empresas a prática justamente do contrário. As análises são feitas exclusivamente com os gestores. Os usuários finais têm acesso ao sistema, as vezes,  somente durante o treinamento, onde chegam com uma enorme resistência ao novo e prontos para apontar qualquer divergenciazinha do sistema ou forma de trabalho atual. As pessoas querem seguir fazendo exatamente a mesma coisa, só que numa outra interface. São poucos os que entendem que o que está mudando é o processo de trabalho e o sistema é só uma via dessa mudança. Nesse momento, o gestor que passou os requisitos nunca está presente no treinamento, e a gente antecipa o coffe breack (quando tem!). 😂

O que eu quero dizer com tudo isso é que se as pessoas que realmente vão utilizar o sistema se sentirem parte do projeto e entenderem o seu papel na implantação, dificilmente mostrarão alguma resistência, pois verão claramente os benefícios do novo software. Do contrário, elas se sentirão obrigadas a engolir um novo sistema, diferente de tudo o que estão acostumados, com outra filosofia, um caminhão de novas funcionalidades e uma interface competente diferente. E nesse caso, eu entendo o xingamento! 😕

Mas esse assunto rende muito pano pra manga, portanto, semana que vem vamos continuar analisando a nossa relação com os recursos de TI e entender o conceito de raciocínio materializado.

Se você concorda, discorda ou tem algo a acrescentar, fique a vontade para comentar!

Curta a página da fourb no facebook!

 

 

Hello world!

Reza a lenda que para aprender qualquer linguagem de programação, o primeiro programa escrito dever o “Hello world!”, que apenas mostra na tela essa saudação formada por duas palavrinhas.

Até hoje, no estudo de todas as linguagens que decidi aprender sempre comecei com esse programa , e tem dado certo (eu acho) 😄 , portanto vamos seguir assim!

Lenda ou não, achei legal trazer esse como primeiro assunto estre os vários que pretendo tratar aqui, no blog da fourb!

Bom, sem mais delongas, me chamo Fabrício Silva sou analista e desenvolvedor de sistemas de gestão e apps mobile e espero ajudar você e sua empresa a ter os melhores resultados com o uso correto e consciente dos recursos de software.

Obrigado e até a próxima!