256+ değişkenli tabloları nasıl işleyebilirim?

Nüfus sayımı verileriyle çalışıyorum ve her biri 600 sütun / değişken içeren birkaç CSV dosyası indirdim. Hepsini sorgulanabilir bir veritabanında saklamak istiyorum, ancak şimdiye kadar denediğim her şey (MS Access, Arc geodatabase tablosu) tabloyu 256 sütuna kesiyor. DBA olmayan biri tarafından erişilebilen büyük tabloları işlemek için herhangi bir çözüm var mı?

database census csv

— scoball
kaynak

Herhangi bir miktarda DB Normalizasyonu ile, bu büyük tabloların Sayım birimi (blok belki?) UID ile ilgili birkaç (veya birçok) daha küçük tablolara ayrılması gerektiğinden şüpheleniyorum.

— Roy

Yanıtlar:

PostgreSQL'in "sütun türlerine bağlı olarak" 250 ile 1600 arasında bir sütun sınırı vardır ve PostGIS uzantısıyla uzamsal verileri ve sorguları destekler. Bu yüzden iki şey yapmaya meyilli olurum:

İlk olarak, bir sütunun serbest metin yerine bir kategoriyi temsil ettiği durumlarda, bu kategorilerle ayrı bir tablo oluşturun ve sütunu, kategori tablosuna başvurarak bir tamsayı kimliği ve yabancı anahtar kısıtlaması ile değiştirin.

İkincisi, büyük tabloyu mantıksal bir şekilde ikiye veya daha fazlasına bölerek Üçüncü Normal Formu kırın ve aralarında bire bir ilişki kurun. Bu belki de en verimli değildir, ancak nadiren bazı verilere ihtiyacınız varsa, sorgu sadece istediğiniz tablolarda olabilir.

Tamamen farklı bir alternatif, MongoDB, CouchDB ve benzeri gibi bir "NOSQL" veritabanı kullanmak olacaktır. "Satır" boyutuna ilişkin kablo bağlantılı sınırlamalar yoktur ve bir kayıt için veri yoksa herhangi bir yer kaplaması gerekmez.

Uzamsal destek, bu tür bigtable veritabanları için iyi değildir, ancak MongoDB, 2B uzamsal sorguları ve verileri destekler ve CouchDB'nin benzer işlevselliğe sahip olduğu görülmektedir.

— MerseyViking
kaynak

+1 Birleştirme çözümü (paragraf 3) aslında son derece verimli olabilir, çünkü Sayım verileri ilgili alan gruplarına sahip olma eğilimindedir ve herhangi bir özel analiz için genellikle bu gruplardan sadece az sayıda gerekir. Bu şekilde binlerce alana (abartmıyorum: bu yaygındır) düzinelerce tablodan mantıklı bir şekilde kırılabilir ve herhangi bir harita veya analiz için bu tabloların sadece az bir kısmına erişilmesi gerekir.

— whuber

@MerseyViking, Verileri tabloları işleyen herhangi bir programa aktaramazsa, tabloları nasıl (scoball) nasıl bölebilir veya diğer işlemleri yapabilir? veriler CSV'de.

— Pablo

@Pablo, MerseyViking'e haksızlık ettiğinizi düşünüyorum: tabloları içe aktarmak için bir komut dosyası yazmanıza izin verilirse - esas olarak çözümünüzü uygulamak için zorlandınız - o zaman o da ve zorluk yok tamamen genel ve esnek olan bir yazı yazarken. (Bunu deneyimlerden biliyorum çünkü son derece büyük Sayım veritabanları için yaptım.) Ayrıca, 256 alan sınırlaması etrafında çalışan birçok alternatif önermektedir.

— whuber

"burada bir sütun serbest metin yerine bir kategoriyi temsil eder" Bu sütunları manuel olarak eşlemeniz gerekir.

— Pablo

@Pablo Yalnızca yetersiz yazılım kullanıyorsanız :-). Paragraf 2-3'teki iş akışı, örneğin hemen hemen her modern istatistik programı kullanılarak sadece birkaç komutla yapılabilir. (Tabii ki bir veritabanında yerine böyle bir programı kullanan savunan değilim, ben sadece doğru o işaret ediyorum paketi araçları, bu cevap her şey kolay ve verimli yapılabilir.)

— whuber

Son zamanlarda 2172 sütun içeren İstatistik Kanada nüfus sayımı profili CSV dosyalarıyla aynı sorunu ele aldım. ArcGIS'e erişiminiz varsa, csv'nizi bir ESRI Dosya Coğrafi Veritabanına (FGDB) aktarabilirsiniz. ESRI'ya göre, FGDB biçimi bir özellik sınıfı veya tablosundaki 65.534 alanı işleyebilir .

Benim durumumda, 2172 sütun genişliğindeki CSV dosyamı herhangi bir sorun olmadan bir FGDB tablosuna aktarabildim.

Tüm tabloyu FGDB'ye aldıktan sonra, istediğiniz şekilde birleştirebilirsiniz (örneğin, mantıksal olarak veya db sınırlamalarına dayalı olarak), benzersiz bir kimlik sütunu tuttuğunuzdan emin olarak, tekrar bir araya getirebilmenizi sağlamak için gerekli.

— Brent Edwards
kaynak

İlginç! Geoveritabanı csv bir ithalat yapmaya çalıştım. Ben kurarken içeri aktarılacak değişkenler listesine baktım ve 256 değişkenin ardından bunları listelemeyi bıraktım, bu yüzden devam etmedim. Bir daha bakacağım.

— scoball

Bu bağlantıya göz atın: asset.nhgis.org/How_to_Import_256_Columns_GIS.pdf

— Brent Edwards

Dosya Coğrafi Veritabanlarının yüksek sınırları vardır, bu nedenle içe aktarmada bir şey olabilir.

— nicksan

Kısa:
Her nesne için çok fazla özniteliğe veya değişken öznitelik türüne sahip veriler için seçeneğim KEY / VALUE veri modelini kullanmaktır, sql'de uygulanabilir ve çok iyi çalışır (postgresql + postgis'i öneririm).

Açıklama:
1) Diyelim ki, özellikler için bir tablonuz var. Bu tablo her nokta için bir kimlik ve GEOMETRİ içerir.

2) Anahtar / değer çiftleri olan 'özellikler' için bir tablonuz daha var. Bu tabloda ID, POINT_ID (FK), KEY (varchar), VALUE (varchar) sütunları bulunur.

Şimdi her bir noktanın neredeyse sonsuz nitelikleri şöyle depolanabilir:

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

OpenStreetMaps böyle çalışır ve çok iyi çalışır, buraya ve buraya bakın .

Verileri içe aktarmak için bir python betiği öneriyorum.

— Pablo
kaynak

Buna genellikle verinin "uzun" formu denir ve bunu bilmek iyidir. Esnek depolama için uygun olsa da, her türlü çok değişkenli analiz için işe yaramaz (bu, iki veya daha fazla özelliği karşılaştıran herhangi bir analiz olacaktır).

— whuber

@whuber, çok değişkenli analiz için işe yaramaz, ancak gerçekten çok yapılandırılmış bir yazılıma veya iyi programlama becerilerine ihtiyacınız vardır, çünkü verilerin özellikle bir tabloya aktarılması gerekir. Burada postgis + django (python web framework) kombinasyonunu kullanmadan önce toprak verilerini (ph, al, kil, vb.) İşlemden önce veri alıntılarını tablolara koydum. Bu model seçildi çünkü aynı yapı diğer keyfi dakik verileri işleyecek.

— Pablo

Yeterince adil: "Olduğu gibi işe yaramaz" demeliydim. Tüm bilgilerin saklanması şartıyla - ve her zaman - verileri her zaman istediğiniz formatta işleyebilirsiniz. @ MerseyViking'in yöntemleri kullanılarak, anahtar / değer yaklaşımına kıyasla işleme nispeten kolaydır. Ayrıca, tablolar gerçekten büyük olduğunda toplam boyut hakkında endişelenmeye başlarız. Anahtar / değer depolamasındaki fazlalık o kadar büyük ki, çok büyük veri kümelerinin analizi için nadiren kullanılır (yalnızca depolama için kullanım sıklığıyla konuşamam.)

— whuber

Onun çözümüne katılmıyorum çünkü veriyi bir veritabanında açamıyorsanız tabloları bölmek veya değiştirmek kolay değil, imkansız demek değil. Kullanıcının verileri bir komut dosyası aracılığıyla doğrudan veritabanına göndermesi gerekir ve anahtar / değer modeliyle, sütunları eşlemeye veya öznitelikleri sınıflandırmaya gerek kalmadan herhangi bir veri için aynı komut dosyasını kullanabilirsiniz.

— Pablo

Çözümünüz, kendi kabulünüzle, benimki kadar iyi programlama becerileri gerektiren programlı olarak karmaşık görünmektedir. Ben sadece PostgreSQL gibi bir RDBMS için en verimli bir formda veri tutmayı savundum. Ayrıca, tartışmalı bir nokta gibi görünüyor çünkü Brent'in cevabı 256 sütun sınırının sahte olduğunu gösteriyor.

— MerseyViking