Bagaimana saya bisa menangani tabel dengan 256+ variabel?

Saya bekerja dengan data sensus dan mengunduh beberapa file CSV, masing-masing dengan 600 kolom / variabel. Saya ingin menyimpan semuanya dalam basis data yang dapat query, tetapi semua yang saya coba sejauh ini (MS Access, Arc tabel geodatabase) memotong tabel menjadi 256 kolom. Apakah ada solusi untuk menangani tabel besar yang dapat diakses oleh seseorang yang bukan DBA?

database census csv

— scoball
sumber

Dengan jumlah Normalisasi DB berapa pun, saya menduga bahwa tabel besar ini harus dipisahkan menjadi beberapa (atau banyak) tabel kecil yang terkait dengan unit Sensus mereka (mungkin blok?) UID.

— Roy

Jawaban:

PostgreSQL memiliki batas kolom antara 250 dan 1600 "tergantung pada jenis kolom", dan mendukung data spasial dan pertanyaan dengan ekstensi PostGIS. Jadi saya akan cenderung melakukan dua hal:

Pertama, di mana kolom mewakili kategori daripada teks bebas, buat tabel terpisah dengan kategori tersebut, dan ganti kolom dengan ID integer dan batasan kunci asing, dengan merujuk tabel kategori.

Kedua, pilah Bentuk Normal Ketiga dengan memecah tabel besar menjadi dua atau lebih secara logis, dan buatlah hubungan satu-ke-satu di antara mereka. Ini mungkin bukan yang paling efisien, tetapi jika Anda jarang memerlukan beberapa data, maka kueri bisa saja di tabel yang Anda inginkan.

Alternatif lain yang sangat berbeda adalah menggunakan database "NOSQL" seperti MongoDB, CouchDB, dan sebagainya. Tidak ada batasan terprogram untuk ukuran "baris", dan jika data tidak ada untuk catatan, itu tidak perlu mengambil ruang apa pun.

Dukungan spasial tidak sebaik jenis database bigtable ini, tetapi MongoDB mendukung permintaan dan data spasial 2D, dan CouchDB tampaknya memiliki fungsi yang sama.

— MerseyViking
sumber

+1 Solusi gabungan (paragraf 3) sebenarnya bisa sangat efisien, karena data Sensus cenderung memiliki kelompok bidang terkait dan untuk analisis tertentu seringkali hanya perlu sejumlah kecil kelompok ini. Dengan cara ini, ribuan bidang (saya tidak membesar-besarkan: ini biasa) dapat dipecah secara logis di lusinan tabel dan hanya sejumlah kecil dari tabel tersebut yang perlu diakses untuk peta atau analisis tertentu.

— whuber

@MerseyViking, Bagaimana mungkin dia (@scoball) membagi tabel atau melakukan operasi lain yang disebutkan jika dia tidak dapat mengimpor data ke program apa pun yang memanipulasi tabel? data dalam CSV.

— Pablo

@Pablo, saya pikir Anda tidak adil terhadap MerseyViking: jika Anda diizinkan untuk menulis skrip untuk mengimpor tabel - yang pada dasarnya harus Anda lakukan untuk mengimplementasikan solusi Anda - maka begitu juga dia, dan tidak ada kesulitan secara tertulis yang sepenuhnya umum dan fleksibel. (Saya tahu ini dari pengalaman karena saya telah melakukannya untuk database Sensus yang sangat besar.) Selain itu, dia menyarankan banyak alternatif yang bekerja di sekitar 256 keterbatasan lapangan.

— whuber

"Di mana kolom mewakili kategori daripada teks gratis" Anda harus memetakan kolom-kolom itu secara manual.

— Pablo

@Pablo Hanya jika Anda menggunakan perangkat lunak yang tidak memadai :-). Alur kerja dalam paragraf 2-3 dapat dilakukan hanya dengan beberapa perintah menggunakan hampir semua program statistik modern, misalnya. (Tentu saja saya tidak menganjurkan menggunakan program seperti itu sebagai pengganti basis data; Saya hanya menunjukkan bahwa dengan rangkaian alat yang tepat , segala sesuatu dalam jawaban ini dapat dicapai dengan mudah dan efisien.)

— whuber

Saya baru-baru ini berurusan dengan masalah yang sama persis dengan file CSV profil Sensus Statistik Kanada yang berisi 2.172 kolom. Anda dapat mengimpor csv Anda ke ESRI File Geodatabase (FGDB) jika Anda memiliki akses ke ArcGIS. Menurut ESRI, format FGDB dapat menangani 65.534 bidang dalam kelas fitur atau tabel .

Dalam kasus saya, saya dapat mengimpor file CSV lebar 2172 kolom saya ke tabel FGDB tanpa masalah.

Setelah Anda memasukkan seluruh tabel ke dalam FGDB, Anda dapat mengirisnya sesuka Anda (mis. Secara logis atau berdasarkan batasan db), memastikan bahwa Anda menyimpan kolom id yang unik, untuk memastikan bahwa Anda dapat bergabung kembali bersama sebagai dibutuhkan.

— Brent Edwards
sumber

Menarik! Saya mencoba melakukan impor dari csv ke file geodatabase. Ketika saya mengaturnya saya melihat daftar variabel yang akan diimpor dan berhenti mendaftar mereka setelah 256 variabel, jadi saya tidak melanjutkan. Saya akan melihat lagi.

— scoball

Lihat tautan ini: assets.nhgis.org/How_to_Import_256_Columns_GIS.pdf

— Brent Edwards

File Geodatabases memiliki batas tinggi, jadi ada kemungkinan sesuatu terjadi dalam impor.

— nicksan

Pendek:
Opsi saya untuk data dengan banyak atribut atau dengan tipe atribut variabel untuk setiap objek adalah dengan menggunakan model data KUNCI / VALUE, dapat diterapkan, dan bekerja dengan sangat baik, dalam sql (saya akan merekomendasikan postgresql + postgis).

Deskripsi:
1) Anda memiliki satu tabel untuk fitur, katakanlah, poin. Tabel ini memuat ID dan GEOMETRI untuk setiap poin.

2) Anda memiliki satu tabel lagi untuk 'atribut' yang merupakan pasangan kunci / nilai. Tabel ini memiliki ID kolom, POINT_ID (FK), KEY (varchar), VALUE (varchar).

Sekarang setiap titik dapat memiliki atribut yang hampir tak terbatas disimpan seperti itu:

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

OpenStreetMaps berfungsi seperti itu dan bekerja dengan sangat baik, lihat di sini dan di sini .

Untuk mengimpor data, saya akan menyarankan sebuah skrip python.

— Pablo
sumber

Ini sering disebut bentuk "panjang" dari data dan baik untuk diketahui. Meskipun tidak apa-apa untuk penyimpanan fleksibel, tidak berguna untuk segala jenis analisis multivarian (yang mana akan menjadi analisis yang membandingkan dua atau lebih atribut).

— whuber

@whuber, ini tidak berguna untuk analisis multivariat, tetapi memang Anda membutuhkan perangkat lunak yang sangat terstruktur atau keterampilan pemrograman yang baik karena data perlu disiapkan, khususnya, ditransfer ke meja. Di sini saya menggunakan kombinasi postgis + django (kerangka web python) untuk mengerjakan data tanah (ph, al, clay, dll) ketika saya perlu, saya menaruh kutipan data ke dalam tabel sebelum diproses. Model ini dipilih karena struktur yang sama akan memproses data tepat waktu sewenang-wenang lainnya.

— Pablo

Cukup adil: Aku seharusnya mengatakan "tidak berguna apa adanya." Asalkan semua informasi disimpan - dan memang begitu - Anda selalu dapat memproses data ke dalam format apa pun yang Anda inginkan. Pemrosesannya relatif mudah menggunakan metode @ MerseyViking dibandingkan dengan pendekatan kunci / nilai. Juga, ketika tabel menjadi sangat besar kita mulai khawatir tentang ukuran total. Redundansi dalam penyimpanan kunci / nilai sangat besar sehingga jarang digunakan untuk analisis kumpulan data yang sangat besar (saya tidak dapat berbicara dengan frekuensi penggunaannya murni untuk penyimpanan.)

— whuber

Saya tidak setuju dengan solusinya karena Tidak mudah, tidak untuk mengatakan mustahil, untuk membagi atau memanipulasi tabel jika Anda tidak dapat membuka data dalam database. Pengguna perlu mengirim data langsung ke database melalui skrip, dan dengan model kunci / nilai Anda dapat menggunakan skrip yang sama untuk data apa pun tanpa perlu memetakan kolom atau mengkategorikan atribut.

— Pablo

Solusi Anda tampaknya, menurut pengakuan Anda sendiri, sama kompleksnya dengan program saya - membutuhkan "keterampilan pemrograman yang baik". Saya hanya menganjurkan menyimpan data dalam bentuk yang paling efisien untuk RDBMS seperti PostgreSQL. Selain itu, tampaknya menjadi titik diperdebatkan karena jawaban Brent menunjukkan batas 256 kolom adalah palsu.

— MerseyViking