Como lidar com tabelas com mais de 256 variáveis?

Estou trabalhando com dados do censo e baixei vários arquivos CSV, cada um com 600 colunas / variáveis. Gostaria de armazená-los todos em um banco de dados passível de consulta, mas tudo o que tentei até agora (tabela do MS Access, Arc geodatabase) trunca a tabela para 256 colunas. Existem soluções para lidar com tabelas grandes acessíveis a alguém que não é um DBA?

database census csv

— scoball
fonte

Com qualquer quantidade de normalização do banco de dados, suspeito que essas tabelas enormes devam ser separadas em várias (ou muitas) tabelas menores relacionadas à UID da unidade do Censo (talvez bloco?).

— Roy

Respostas:

O PostgreSQL possui um limite de coluna entre 250 e 1600 "dependendo dos tipos de coluna" e suporta dados e consultas espaciais com a extensão PostGIS. Então, eu estaria inclinado a fazer duas coisas:

Primeiro, onde uma coluna representa uma categoria em vez de texto livre, crie uma tabela separada com essas categorias e substitua a coluna por um ID inteiro e restrição de chave estrangeira, referenciando a tabela de categoria.

Em segundo lugar, quebre a Terceira Forma Normal dividindo a grande mesa em duas ou mais, de alguma maneira lógica, e estabeleça um relacionamento individual entre elas. Talvez isso não seja o mais eficiente, mas se você raramente precisar de alguns dados, a consulta poderá estar apenas nas tabelas que você deseja.

Outra alternativa completamente diferente seria usar um banco de dados "NOSQL", como MongoDB, CouchDB e assim por diante. Não há limites físicos para o tamanho da "linha" e, se os dados não estiverem presentes em um registro, eles não precisarão ocupar espaço.

O suporte espacial não é tão bom para esses tipos de bancos de dados grandes, mas o MongoDB suporta consultas e dados espaciais em 2D, e o CouchDB parece ter uma funcionalidade semelhante.

— MerseyViking
fonte

+1 A solução de junção (parágrafo 3) na verdade pode ser extremamente eficiente, porque os dados do Censo tendem a ter grupos de campos relacionados e, para qualquer análise específica, geralmente é necessário apenas um pequeno número desses grupos. Dessa maneira, milhares de campos (não exagero: isso é comum) podem ser divididos logicamente em dezenas de tabelas e apenas um pequeno número dessas tabelas precisa ser acessado para qualquer mapa ou análise em particular.

— whuber

@MerseyViking, como ele (@scoball) pode dividir tabelas ou executar as outras operações mencionadas se ele não pode importar os dados para qualquer programa que manipule tabelas? os dados estão em CSV.

— Pablo

@ Pablo, acho que você está sendo injusto com o MerseyViking: se você tem permissão para escrever um script para importar tabelas - às quais você é essencialmente obrigado a implementar sua solução - então ele também é, e não há dificuldade por escrito, que seja completamente geral e flexível. (Eu sei disso por experiência própria, porque fiz isso para bancos de dados do Censo extremamente grandes.) Além disso, ele sugere muitas alternativas que resolvem a limitação de 256 campos.

— whuber

"onde uma coluna representa uma categoria em vez de texto livre" Você precisa mapear manualmente essas colunas.

— 1513 Pablo Pablo

@ Pablo Somente se você estiver usando software inadequado :-). O fluxo de trabalho nos parágrafos 2-3 pode ser realizado com apenas alguns comandos, usando praticamente qualquer programa estatístico moderno, por exemplo. (É claro que não estou defendendo o emprego de um programa como esse no lugar de um banco de dados; estou apenas apontando que, com o conjunto adequado de ferramentas, tudo nesta resposta pode ser realizado com facilidade e eficiência.)

— whuber

Recentemente, lidei com o mesmo problema com os arquivos CSV do perfil de censo do Statistics Canada contendo 2172 colunas. Você pode importar seu csv para um geodatabase de arquivo ESRI (FGDB) se tiver acesso ao ArcGIS. De acordo com a ESRI, o formato FGDB pode manipular 65.534 campos em uma classe ou tabela de recurso .

No meu caso, consegui importar meu arquivo CSV de 2172 colunas para uma tabela FGDB sem problemas.

Depois de inserir a tabela inteira no FGDB, é possível dividi-la da maneira que desejar (por exemplo, logicamente ou com base em limitações de db), mantendo uma coluna de identificação exclusiva, para garantir que você possa juntá-la novamente como necessário.

— Brent Edwards
fonte

Interessante! Tentei fazer uma importação do csv para o arquivo geodatabase. Quando eu estava configurando, olhei para a lista de variáveis que iria importar e ela parou de listá-las após 256 variáveis, então não continuei. Vou dar outra olhada.

— scoball

Verifique este link: assets.nhgis.org/How_to_Import_256_Columns_GIS.pdf

— Brent Edwards

Os bancos de dados geográficos de arquivos têm limites altos, portanto, é possível que algo tenha acontecido na importação.

— Nicksan

Breve:
Minha opção para dados com muitos atributos ou com tipo de atributo variável para cada objeto é usar o modelo de dados KEY / VALUE, ele pode ser implementado e funciona muito bem no sql (eu recomendaria o postgresql + postgis).

Descrição:
1) Você tem uma tabela para recursos, digamos, pontos. Esta tabela contém um ID e a GEOMETRIA para cada ponto.

2) Você tem mais uma tabela para os 'atributos', que são os pares chave / valor. Esta tabela possui o ID das colunas, POINT_ID (FK), KEY (varchar), VALUE (varchar).

Agora, cada ponto pode ter atributos praticamente infinitos armazenados assim:

ID   POINT_ID   KEY   VALUE
1        1      type     burger shop
2        1      name     SuperBurger
3        1      address  123, a ST.

O OpenStreetMaps funciona assim e funciona muito bem, veja aqui e aqui .

Para importar os dados, sugiro um script python.

— Pablo
fonte

Isso geralmente é chamado de forma "longa" dos dados e é bom saber sobre isso. Embora seja aceitável o armazenamento flexível, é inútil para qualquer tipo de análise multivariada (que seria qualquer análise comparando dois ou mais atributos).

— whuber

@whuber, não é inútil para análises multivariadas, mas na verdade você precisa de um software muito estruturado ou de boas habilidades de programação porque os dados precisam ser preparados, especificamente, transferidos para uma tabela. Aqui eu uso a combinação de postgis + django (python web framework) para trabalhar dados do solo (ph, al, clay, etc) quando preciso colocar trechos dos dados nas tabelas antes do processamento. Esse modelo foi escolhido porque a mesma estrutura processará outros dados pontuais arbitrários.

— Pablo

É justo: eu deveria ter dito "inútil como está". Desde que todas as informações sejam mantidas - e é - você sempre pode processar os dados no formato que desejar. O processamento é relativamente fácil usando os métodos do @ MerseyViking em comparação com a abordagem de chave / valor. Além disso, quando as tabelas ficam realmente grandes, começamos a nos preocupar com o tamanho total. A redundância no armazenamento de chave / valor é tão grande que é raramente usado para a análise de grandes conjuntos de dados (eu não posso falar com a frequência de seu uso exclusivamente para o armazenamento.)

— whuber

Não concordo com a solução dele, porque não é fácil, para não dizer impossível, dividir ou manipular tabelas se você não pode abrir os dados em um banco de dados. O usuário precisa enviar dados diretamente para o banco de dados através de um script e, com o modelo de chave / valor, você pode usar o mesmo script para qualquer dado sem a necessidade de mapear as colunas ou categorizar os atributos.

— 1515 Pablo Pablo

Sua solução parece, por sua própria admissão, ser tão programaticamente complexa quanto a minha - necessitando de "boas habilidades de programação". Apenas advoguei manter os dados de uma forma mais eficiente para um RDBMS como o PostgreSQL. Além disso, parece ser um ponto discutível, porque a resposta de Brent mostra que o limite de 256 colunas é falso.

— MerseyViking