Introdução

Neste primeiro post, estou registrando que a base de dados SIC 81933249327.xlsb, elencada adiante, apresentou muitos problemas que impossibilita uma análise direta, e aqui servirá de guia para saber o que foi feito ou não. Considero que o formato de dados binário, com a terminação .xlsb, não é muito amigável para a manipulação e tratamento dos dados.

Ao usarmos o R, a função readxlsb::read_xlsb() apresentou limitações significativas. Com isso em mente, fizemos parte das alterações diretamente no Excel, tendo visto a minha familiridade com o seu uso. Por exemplo, a primeira tentativa de unir a base de dados em uma só foi a partir do seguinte código:

data <- readxlsb::read_xlsb(path = "dados/SIC 81933249327.xlsb",
  sheet = c("Base de Dados (1)", 
            "Base de Dados (2)",
            "Base de Dados (3)"))

Limpeza no Excel

Descrição da base de dados:

Manuseando a base de dados no Excel, foi possível observar que não há um padrão para tratar dados vazios ou nulos. Por vezes, eles aparecem como NULL³, 0, 99999 ou como células vazias. Por padrão, sempre que uma coluna possui um caractere textual, mesmo que seja somente um, esta coluna sempre será lida como <chr> ao invés de outro formato, como <dttm> (data) ou dbl (numérico).

Agora, a base de dados se aproxima muito com o que gostaríamos de ter como produto final. Por enquanto, estamos lendo uma “aba” (sheet) por vez porque estávamos impossibilitados de ler tudo de uma vez, ao utilizar a função readxlsb:read_xlsb. Haviam dois problemas:

1. Nosso arquivo era muito grande, e estava demorando muito para carregar (cerca de horas!);

2. O arquivo, que estava salvo inicialmente no formato binário do Excel, possuía muitas células “sobrescritas”, fazendo com que os dados fossem armazenados de maneira e com o formato inadequado.

Portanto, foi necessário ajustar parte dos dados no Excel, como demonstrado acima.

Ademais, a Base de Dados (3) possuía algumas diferenças, como nas seguintes colunas:

1. A coluna COR_CUTIS estava registrada como COR_CURTIS;

2. Havia uma coluna chamada LOGRADOURO_VERSAO que não constava no dicionário da base original, tampouco apresentava informações relevantes;

3. Há uma coluna diferente (extra), chamada CIRCUNSTANCIA. Acredita-se ser devido ao fato de que é provável que os dados dessa Base de Dados (3) seja oriundo da PCSP e não da PMSP.

Analisando a base de dados

Inicialmente, vamos analisar a base de dados que conta com o bind_rows(), que uniu as três primeiras abas dos dados, porque as colunas tinham os menos nomes e mesmas características. O bind_rows()faz com que a nossa base de dados tenha um formato mais longo, ao invés de mais largo.

A nossa base de dados final, bd_final.xlsx, contém 41 colunas e 486.061 linhas. Os dados vão de 2002 a 2023. Ao todo, temos 622 municípios disponíveis na base para o Estado de São Paulo.

A Tabela abaixo apresenta a porcentagem de registros de Boletins de Ocorrência (BOs) por cor dos adolescentes:

É possível ver que há uma predominância de adolescentes pardos, seguidos de brancos. Se analisarmos de maneira conjunta os adolescentes pretos e pardos, configurando a categoria “negro” de acordo com o IBGE, observamos que essa população está sobrerepresentanda em nossa amostra, com um total de 57.6%.

Na Figura abaixo, podemos ver como se distribui o número de registros ao longo dos anos, para todo o Estado de São Paulo. Nos indagamos: o que aconteceu entre os anos de 2014 e 2017, para que houvesse um decréscimo no número de registros, logo após o ápice da série histórica?

São questões como essa que motivam a investigação desse problema de pesquisa.

Dados ausentes

Outro ponto interessante a se investigar é como se comportam os valores ausentes na nossa base de dados. Como vimos na Seção de Limpeza, nossa base de dados não apresenta um comportamento padrão quanto ao tratamento de dados ausentes. Eles são representandos de diversas formas, tanto como NULL, NA, 9999 etc. Isso dificulta um pouco o trabalho de organização da base. Ademais, é interessante observar aquilo que não está registrado em nossa base.

O pacote naniar possui uma função que pode ser interessante para nos auxiliar a vislumbrar quais são as variáveis mais ausentes na nossa base.

Observamos que a variável CIRCUNSTANCIA é a que mais apresenta valores faltantes. Isso se dá porque ela é uma variável presente somente na base de dados que constam dados do Sistema de Polícia Judiciária, que continha 23.869 registros, representando aproximadamente 4,9% dos dados. Ao fazermos o join das bases de dados, essa coluna atribuiu valores ausentes (NAs) às demais bases. Ademais, é possível verificar que as variáveis CEP e LOGRADOURO apresentam muitos NAs. Isto é particularmente desvanjatoso para os propositos da minha pesquisa pois ela se trata, em síntese, da investigação dos padrões de atuação das polícias de São Paulo, e um dado muito importante seria justamente aquele que possibilita o georreferenciamento das ocorrências.