Wie kann ich mit Tabellen mit mehr als 256 Variablen umgehen?

Ich arbeite mit Volkszählungsdaten und habe mehrere CSV-Dateien mit jeweils 600 Spalten / Variablen heruntergeladen. Ich möchte sie alle in einer abfragefähigen Datenbank speichern, aber alles, was ich bisher versucht habe (MS Access, Arc-Geodatabase-Tabelle), schneidet die Tabelle auf 256 Spalten ab. Gibt es Lösungen für den Umgang mit großen Tabellen, auf die jemand zugreifen kann, der kein DBA ist?

database census csv Scoball
quelle

Bei jeder Menge an DB-Normalisierung vermute ich, dass diese riesigen Tabellen in mehrere (oder viele) kleinere Tabellen aufgeteilt werden sollten, die sich auf ihre UID der Census Unit (Block vielleicht?) Beziehen.

Roy

Antworten:

PostgreSQL hat ein Spaltenlimit zwischen 250 und 1600 "abhängig von den Spaltentypen" und unterstützt räumliche Daten und Abfragen mit der PostGIS-Erweiterung. Ich wäre also geneigt, zwei Dinge zu tun:

Wenn eine Spalte eine Kategorie anstelle von freiem Text darstellt, erstellen Sie zunächst eine separate Tabelle mit diesen Kategorien und ersetzen Sie die Spalte durch eine Ganzzahl-ID und eine Fremdschlüsseleinschränkung, wobei Sie auf die Kategorietabelle verweisen.

Zweitens: Brechen Sie die dritte Normalform, indem Sie den großen Tisch auf logische Weise in zwei oder mehr Teile aufteilen und eine Eins-zu-Eins-Beziehung zwischen ihnen herstellen. Dies ist vielleicht nicht die effizienteste, aber wenn Sie selten einige der Daten benötigen, kann sich die Abfrage nur auf den gewünschten Tabellen befinden.

Eine andere völlig andere Alternative wäre die Verwendung einer "NOSQL" -Datenbank wie MongoDB, CouchDB usw. Es gibt keine fest verdrahteten Grenzen für die Zeilengröße. Wenn für einen Datensatz keine Daten vorhanden sind, muss kein Speicherplatz belegt werden.

Die räumliche Unterstützung ist für diese Arten von Bigtable-Datenbanken nicht so gut, aber MongoDB unterstützt räumliche 2D-Abfragen und -Daten, und CouchDB scheint ähnliche Funktionen zu haben.

MerseyViking
quelle

+1 Die Join-Lösung (Absatz 3) kann tatsächlich äußerst effizient sein, da Volkszählungsdaten in der Regel Gruppen verwandter Felder enthalten und für eine bestimmte Analyse häufig nur eine kleine Anzahl dieser Gruppen benötigt wird. Auf diese Weise können Tausende von Feldern (ich übertreibe nicht: das ist üblich) logisch über Dutzende von Tabellen aufgeteilt werden, und für eine bestimmte Karte oder Analyse muss nur auf eine kleine Anzahl dieser Tabellen zugegriffen werden.

whuber

@MerseyViking, wie könnte er (@scoball) Tabellen teilen oder die anderen genannten Operationen ausführen, wenn er die Daten nicht in ein Programm importieren kann, das Tabellen manipuliert? Die Daten sind in CSV.

Pablo

@Pablo, ich denke, Sie sind MerseyViking gegenüber unfair: Wenn Sie ein Skript zum Importieren von Tabellen schreiben dürfen - zu dem Sie im Wesentlichen gezwungen sind , um Ihre Lösung zu implementieren -, ist er es auch, und es gibt keine Schwierigkeiten schriftlich eine, die ganz allgemein und flexibel ist. (Ich weiß das aus Erfahrung, weil ich es für extrem große Volkszählungsdatenbanken gemacht habe.) Außerdem schlägt er viele Alternativen vor, die die Beschränkung auf 256 Felder umgehen.

whuber

"wobei eine Spalte eher eine Kategorie als freien Text darstellt" Sie müssen diese Spalten manuell zuordnen.

Pablo

@Pablo Nur wenn Sie unzureichende Software verwenden :-). Der Workflow in den Absätzen 2-3 kann mit nur wenigen Befehlen beispielsweise mit fast jedem modernen Statistikprogramm ausgeführt werden. (Natürlich befürworte ich nicht, ein solches Programm anstelle einer Datenbank einzusetzen. Ich möchte nur darauf hinweisen, dass mit der richtigen

Tool-

Ich habe mich kürzlich mit genau demselben Problem mit CSV-Dateien mit dem Volkszählungsprofil von Statistics Canada befasst, die 2172 Spalten enthalten. Sie können Ihre CSV in eine ESRI File Geodatabase (FGDB) importieren, wenn Sie Zugriff auf ArcGIS haben. Laut ESRI kann das FGDB-Format 65.534 Felder in einer Feature-Class oder Tabelle verarbeiten .

In meinem Fall konnte ich meine 2172 spaltenweite CSV-Datei ohne Probleme in eine FGDB-Tabelle importieren.

Sobald Sie die gesamte Tabelle in die FGDB aufgenommen haben, können Sie sie nach Belieben aufteilen (z. B. logisch oder basierend auf DB-Einschränkungen). Stellen Sie dabei sicher, dass Sie eine eindeutige ID-Spalte behalten, um sicherzustellen, dass Sie sie wieder zusammenfügen können erforderlich.

Brent Edwards
quelle

Interessant! Ich habe versucht, einen Import von CSV in eine Datei-Geodatabase durchzuführen. Als ich es einrichtete, sah ich mir die Liste der Variablen an, die importiert werden sollten, und die Liste wurde nach 256 Variablen nicht mehr aufgelistet, sodass ich nicht fortfuhr. Ich werde noch einen Blick darauf werfen.

Scoball

Schauen Sie sich diesen Link an: assets.nhgis.org/How_to_Import_256_Columns_GIS.pdf

Brent Edwards

Datei-Geodatabases haben hohe Grenzwerte, daher ist beim Import möglicherweise etwas passiert.

Nicksan

Kurz:
Meine Option für Daten mit vielen Attributen oder mit variablem Attributtyp für jedes Objekt ist die Verwendung des KEY / VALUE-Datenmodells. Es kann in SQL implementiert werden und funktioniert sehr gut (ich würde postgresql + postgis empfehlen).

Beschreibung:
1) Sie haben eine Tabelle für Funktionen, z. B. Punkte. Diese Tabelle enthält eine ID und die GEOMETRIE für jeden Punkt.

2) Sie haben eine weitere Tabelle für die 'Attribute', die die Schlüssel / Wert-Paare sind. Diese Tabelle enthält die Spalten ID, POINT_ID (FK), KEY (varchar), VALUE (varchar).

Jetzt könnten für jeden Punkt praktisch unendlich viele Attribute gespeichert werden:

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

OpenStreetMaps funktioniert so und funktioniert sehr gut, siehe hier und hier .

Um die Daten zu importieren, würde ich ein Python-Skript vorschlagen.

Pablo
quelle

Dies wird oft als "lange" Form der Daten bezeichnet und ist gut zu wissen. Obwohl es für die flexible Speicherung in Ordnung ist, ist es für jede Art von multivariater Analyse nutzlos (dies wäre jede Analyse, bei der zwei oder mehr Attribute verglichen werden).

whuber

@whuber, es ist nicht nutzlos für multivariate Analysen, aber in der Tat benötigen Sie eine sehr strukturierte Software oder gute Programmierkenntnisse, da die Daten speziell vorbereitet und in eine Tabelle übertragen werden müssen. Hier verwende ich die Kombination von Postgis + Django (Python Web Framework), um Bodendaten (ph, al, ton usw.) zu bearbeiten, wenn ich vor der Verarbeitung Auszüge der Daten in Tabellen einfügen muss. Dieses Modell wurde gewählt, weil dieselbe Struktur andere beliebige pünktliche Daten verarbeitet.

Pablo

Fair genug: Ich hätte sagen sollen "nutzlos wie es ist". Vorausgesetzt, alle Informationen bleiben erhalten - und das ist es auch - können Sie die Daten jederzeit in einem beliebigen Format verarbeiten. Die Verarbeitung ist mit den Methoden von @ MerseyViking im Vergleich zum Schlüssel / Wert-Ansatz relativ einfach. Wenn die Tabellen sehr groß werden, machen wir uns auch Sorgen um die Gesamtgröße. Die Redundanz in der Schlüssel- / Wertspeicherung ist so groß, dass sie selten für die Analyse sehr großer Datensätze verwendet wird (ich kann nicht mit der Häufigkeit ihrer Verwendung nur für die Speicherung sprechen).

whuber

Ich bin mit seiner Lösung nicht einverstanden, weil es nicht einfach oder unmöglich ist, Tabellen zu teilen oder zu bearbeiten, wenn Sie die Daten in einer Datenbank nicht öffnen können. Der Benutzer muss Daten über einen Scrip direkt an die Datenbank senden. Mit dem Schlüssel- / Wertmodell können Sie denselben Scrip für alle Daten verwenden, ohne die Spalten zuordnen oder die Attribute kategorisieren zu müssen.

Pablo

Ihre Lösung scheint nach Ihren eigenen Angaben genauso programmatisch komplex zu sein wie meine - und erfordert "gute Programmierkenntnisse". Ich habe mich lediglich dafür ausgesprochen, die Daten in einer Form zu halten, die für ein RDBMS wie PostgreSQL am effizientesten ist. Außerdem scheint es ein strittiger Punkt zu sein, da Brents Antwort zeigt, dass das Limit von 256 Spalten falsch ist.

MerseyViking