Comment puis-je gérer des tableaux avec plus de 256 variables?

Je travaille avec des données de recensement et j'ai téléchargé plusieurs fichiers CSV, chacun avec 600 colonnes / variables. Je voudrais les stocker tous dans une base de données interrogeable, mais tout ce que j'ai essayé jusqu'à présent (MS Access, table de géodatabase Arc) tronque la table à 256 colonnes. Existe-t-il des solutions pour gérer les grandes tables accessibles à quelqu'un qui n'est pas un DBA?

database census csv

— scoball
source

Avec n'importe quelle quantité de normalisation de base de données, je soupçonne que ces énormes tables devraient être séparées en plusieurs (ou plusieurs) tables plus petites se rapportant à leur UID d'unité de recensement (bloc peut-être?).

— Roy

Réponses:

PostgreSQL a une limite de colonnes comprise entre 250 et 1600 "selon les types de colonnes" et prend en charge les données spatiales et les requêtes avec l'extension PostGIS. Je serais donc enclin à faire deux choses:

Tout d'abord, lorsqu'une colonne représente une catégorie plutôt que du texte libre, créez un tableau séparé avec ces catégories et remplacez la colonne par un ID entier et une contrainte de clé étrangère, faisant référence au tableau des catégories.

Deuxièmement, brisez la troisième forme normale en divisant la grande table en deux ou plus de manière logique et établissez une relation un à un entre eux. Ce n'est peut-être pas le plus efficace, mais si vous avez rarement besoin de certaines données, la requête peut simplement être sur les tables que vous souhaitez.

Une autre alternative complètement différente consisterait à utiliser une base de données "NOSQL" telle que MongoDB, CouchDB, etc. Il n'y a pas de limites câblées à la taille des "lignes" et si les données ne sont pas présentes pour un enregistrement, elles n'ont pas besoin de prendre de la place.

La prise en charge spatiale n'est pas aussi bonne pour ces types de bases de données bigtable, mais MongoDB prend en charge les requêtes et données spatiales 2D, et CouchDB semble avoir des fonctionnalités similaires.

— MerseyViking
source

+1 La solution de jointure (paragraphe 3) peut en fait être extrêmement efficace, car les données du recensement ont tendance à avoir des groupes de champs liés et pour toute analyse particulière, il suffit souvent d'un petit nombre de ces groupes. De cette façon, des milliers de champs (je n'exagère pas: c'est courant) peuvent être répartis logiquement sur des dizaines de tables et seul un petit nombre de ces tables doivent être accessibles pour une carte ou une analyse particulière.

— whuber

@MerseyViking, comment pourrait-il (@scoball) diviser des tables ou effectuer les autres opérations mentionnées s'il ne peut pas importer les données dans un programme qui manipule des tables? les données sont en CSV.

— Pablo

@Pablo, je pense que vous êtes injuste envers MerseyViking: si vous êtes autorisé à écrire un script pour importer des tables - auquel vous êtes essentiellement obligé pour mettre en œuvre votre solution - alors il en est de même, et il n'y a aucune difficulté par écrit celui qui est complètement général et flexible. (Je le sais par expérience parce que je l'ai fait pour des bases de données de recensement extrêmement volumineuses.) De plus, il suggère de nombreuses alternatives qui fonctionnent autour de la limitation de 256 champs.

— whuber

"où une colonne représente une catégorie plutôt que du texte libre" Vous devez mapper manuellement ces colonnes.

— Pablo

@Pablo Uniquement si vous utilisez un logiciel inadéquat :-). Le flux de travail dans les paragraphes 2-3 peut être effectué avec seulement quelques commandes en utilisant presque n'importe quel programme statistique moderne, par exemple. (Bien sûr, je ne préconise pas l'utilisation d'un tel programme au lieu d'une base de données; je souligne simplement qu'avec la suite d'outils appropriée , tout dans cette réponse peut être accompli facilement et efficacement.)

— whuber

J'ai récemment traité le même problème avec les fichiers CSV des profils de recensement de Statistique Canada contenant 2172 colonnes. Vous pouvez importer votre csv dans une géodatabase fichier ESRI (FGDB) si vous avez accès à ArcGIS. Selon ESRI, le format FGDB peut gérer 65 534 champs dans une classe d'entités ou une table .

Dans mon cas, j'ai pu importer mon fichier CSV 2172 colonnes dans une table FGDB sans aucun problème.

Une fois que vous avez placé la table entière dans la FGDB, vous pouvez la découper comme vous le souhaitez (par exemple, logiquement ou en fonction des limitations de la base de données), en vous assurant de conserver une colonne d'ID unique, pour vous assurer de pouvoir la réunir à nouveau en tant que nécessaire.

— Brent Edwards
source

Intéressant! J'ai essayé de faire une importation de csv vers la géodatabase fichier. Quand je l'ai installé, j'ai regardé la liste des variables qu'il allait importer et il a cessé de les lister après 256 variables, donc je n'ai pas continué. Je vais jeter un autre regard.

— scoball

Consultez ce lien: assets.nhgis.org/How_to_Import_256_Columns_GIS.pdf

— Brent Edwards

Les géodatabases fichier ont des limites élevées, il est donc possible que quelque chose se soit produit lors de l'importation.

— nicksan

En bref:
mon option pour les données avec beaucoup d'attributs ou avec un type d'attribut variable pour chaque objet est d'utiliser le modèle de données KEY / VALUE, il peut être implémenté et fonctionne très bien, en sql (je recommanderais postgresql + postgis).

Description:
1) Vous avez un tableau pour les caractéristiques, disons, les points. Ce tableau contient un ID et la GÉOMÉTRIE pour chaque point.

2) Vous avez une table de plus pour les «attributs» qui sont les paires clé / valeur. Cette table a les colonnes ID, POINT_ID (FK), KEY (varchar), VALUE (varchar).

Maintenant, chaque point pourrait avoir des attributs virtuellement infinis stockés comme ça:

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

OpenStreetMaps fonctionne comme ça et fonctionne très bien, voir ici et ici .

Pour importer les données, je suggérerais un script python.

— Pablo
source

Ceci est souvent appelé la forme «longue» des données et il est bon de le savoir. Bien qu'il soit acceptable pour un stockage flexible, il est inutile pour tout type d'analyse multivariée (qui serait une analyse comparant deux ou plusieurs attributs).

— whuber

@whuber, ce n'est pas inutile pour une analyse multivariée, mais en effet vous avez besoin d'un logiciel très structuré ou de bonnes compétences en programmation car les données doivent être préparées, spécifiquement, transférées dans une table. Ici, j'utilise la combinaison de postgis + django (framework web python) pour travailler les données du sol (ph, al, clay, etc.) lorsque j'ai besoin de mettre des extraits des données dans des tableaux avant le traitement. Ce modèle a été choisi car la même structure traitera d'autres données ponctuelles arbitraires.

— Pablo

Assez juste: j'aurais dû dire "inutile tel quel". À condition que toutes les informations soient conservées - et elles le sont - vous pouvez toujours traiter les données dans le format de votre choix. Le traitement est relativement facile en utilisant les méthodes de @ MerseyViking par rapport à l'approche clé / valeur. De plus, lorsque les tables deviennent vraiment grandes, nous commençons à nous préoccuper de la taille totale. La redondance dans le stockage clé / valeur est si grande qu'elle est rarement utilisée pour l'analyse de très grands ensembles de données (je ne peux pas parler de la fréquence de son utilisation uniquement pour le stockage.)

— whuber

Je ne suis pas d'accord avec sa solution car il n'est pas facile, pour ne pas dire impossible, de diviser ou de manipuler des tables si vous ne pouvez pas ouvrir les données dans une base de données. L'utilisateur doit envoyer des données directement à la base de données via un script, et avec le modèle clé / valeur, vous pouvez utiliser le même script pour toutes les données sans avoir besoin de mapper les colonnes ou de catégoriser les attributs.

— Pablo

Votre solution semble, de votre propre aveu, être aussi complexe sur le plan programmatique que la mienne - nécessitant de "bonnes compétences en programmation". J'ai simplement préconisé de conserver les données sous la forme la plus efficace pour un SGBDR tel que PostgreSQL. En outre, cela semble être un point discutable, car la réponse de Brent montre que la limite de 256 colonnes est fausse.

— MerseyViking