'Düzenli Veri' Oluşturmaya İlişkin En İyi Uygulamalar


12

Hadley Wickham geçen sene JSS'de veri manipülasyonu ve analiz yapmak için verileri "optimal" duruma getirme hakkında "Düzenli Veri" ( link ) adlı yıldız bir makale yazdı . Ancak, bir çalışma ortamında tablo verilerinin sunulması açısından en iyi uygulamaların neler olduğunu merak ediyordum? İş arkadaşınızın sizden ona bazı veriler vermenizi istediğini varsayalım. Bu verileri yapılandırırken kullandığınız bazı genel kurallar nelerdir? "Düzenli Veriler" bölümündeki yönergeler, veri olmayan profesyonellerle veri paylaştığınız durumlarda da geçerli mi? Açıkçası, bu çok bağlama özgüdür, ancak üst düzey 'en iyi uygulamaları' soruyorum.


Bu çalışma henüz İstatistik Yazılımında yayınlanmamıştır.
Nick Cox

3
R etiketi burada gereksiz görünüyor. Soru, belirli yazılım seçeneklerini aşmaktadır.
Nick Cox

Yanıtlar:


10

Hadley'den beklendiği gibi, makalesi düzenli verilerin iyi bir tanımını içeriyor ve makalesindeki hemen hemen her şeye katılıyorum ve bunun sadece "veri profesyonelleri" için geçerli olmadığına inanıyorum. Bununla birlikte, bazı temel sorunlardan kaçınılması durumunda, yaptığı bazı noktaların düzeltilmesi nispeten kolaydır (örneğin, yazdığı paketlerle). Bu sorunların çoğu, Excel'in yaygın kullanımının bir sonucudur. Excel değerli bir araçtır ve yararları vardır, ancak bazı özellikleri veri analistleri için sorunlara neden olur.

Bazı noktalar (deneyimlerimden):

  1. Bazı insanlar renkli e-tabloları sever ve biçimlendirme seçeneklerini bol miktarda kullanır. Verilerini düzenlemelerine ve tabloları sunum için hazırlamalarına yardımcı olursa, her şey yolunda. Ancak, bir hücre renginin verileri gerçekten kodlaması tehlikelidir. Bu verileri kaybetmek kolaydır ve bu tür verilerin istatistiksel yazılıma aktarılması çok zordur (örn . Stack Overflow ile ilgili bu soruya bakın ).
  2. Bazen bazı güzel biçimlendirilmiş veriler alırım (insanlara nasıl hazırlayacağını söyledikten sonra), ancak yorum için özel bir sütun veya ayrı bir dosya kullanmalarını istemelerine rağmen, bir değer sütununa yorum yapmaya karar verirler. Sadece veri alırken bu sütun ile özel bir şekilde başa çıkmak zorunda değil, ama asıl sorun, (ki genellikle yapmazdım) bu tür yorumları görmek için tüm tabloyu kaydırmak gerekecek olmasıdır. Excel'in yorum yapma olanaklarını kullanırlarsa bu daha da kötüleşir.
  3. İçinde birkaç tablo, birden çok başlık satırı veya bağlı hücre bulunan e-tablolar, bunları istatistiksel yazılımda içe aktarmaya hazırlamak için el ile çalışmaya neden olur. İyi veri analistleri genellikle bu tür manuel çalışmalardan hoşlanmazlar.
  4. Asla Excel'de sütunları asla gizlemeyin. Gerekli değilse, silin. Gerekirse onlara gösterin.
  5. xls ve torunları başkalarıyla veri alışverişi yapmak veya arşivlemek için uygun dosya formatları değildir. Dosya açıldığında formüller güncellenir ve farklı Excel sürümleri dosyaları farklı şekilde işleyebilir. Bunun yerine basit bir CSV dosyası öneririm, çünkü neredeyse tüm veri ile ilgili yazılım bunu (Excel'i bile) içe aktarabilir ve yakında değişmeyeceği beklenebilir. Bununla birlikte, bir CSV'ye kaydederken Excel'in görünür basamaklara yuvarlandığını unutmayın (böylece hassasiyeti atarsınız).
  6. Hayatı başkaları için kolaylaştırmak istiyorsanız, Hadley'in makalesinde verilen ilkelere uyun. Her bir değişken için bir değer sütununa ve katmanları tanımlayan faktör sütunlarına sahip olun.

Muhtemelen aklıma gelmeyen birkaç ek nokta daha var.


1
"Asla, asla Excel'de sütunları gizlemeyin. Gerekmiyorsa silin. Gerekirse gösterin." Buna katılmıyorum. Gizli veriler / alanlar bir sorundur. Ancak veri sütunlarını silmek, elektronik tablolarda geri dönüşü olmayan bir işlem haline gelebilir. Uygulama belleği büyük bir endişe olmadıkça, sütunları saklamanızı tavsiye ederim çünkü bunlara karşı gizleme / filtreleme son derece kolaydır. Özellikle ters silme işlemine kıyasla.
Dan Nguyen

7

İlk olarak, genellikle verileri alan kişiyim. Yani bu benim istek listem olarak okunabilir.

  • Bu yüzden en önemli noktam: verileri analiz edecek kişiyle konuşun.

  • Makaleye hızlı bir bakış attı: Hadley'in yazdığı birçok şey 'ilişkisel veri tabanınızı normalleştirin' ile özetlenebilir.

  • Ancak, gerçekte olup bitenlere bağlı olarak, aynı değişkenin uzun veya geniş biçimde olması mantıklı olabileceğinden de söz eder.

    İşte bir örnek: Spektrumlarla ilgileniyorum. Fiziksel bir / spektroskopik açıdan, spektrum bir yoğunluk, örneğin bir dalga boyu fonksiyonu olarak : ı f (λ) =. Fiziksel nedenlerden dolayı, bu işlev süreklidir (ve sürekli olarak ayırt edilebilir). Belirli bir takdir sadece pratik nedenlerle gerçekleşir (örn. Dijital bilgisayarlar, ölçüm cihazları). Bu açıkça uzun bir forma işaret eder. Bununla birlikte, farklı kanallardaki (bir CCD / dedektör hattı veya dizisinin) farklı ölçer . Veri analizi ayrıca her bir değişkenini bir değişken olarak ele alır . Bu geniş form lehine olacaktır.Iλλiλiλi

  • Bununla birlikte, verilerin normalleştirilmemesi / dağıtılması için bazı pratik avantajlar vardır:

    • Verilerin eksiksiz olup olmadığını kontrol etmek çok daha kolay olabilir .

    • Veriler gerçekte bir veri tabanındaysa (yazılım anlamında) normalleştirilmiş ilişkisel veri tabanındaki gibi bağlı tablolar uygundur. Orada, tamlığı sağlayan kısıtlamalar koyabilirsiniz. Veriler birkaç tablo şeklinde değiştirilirse, pratikte bağlantılar bir karışıklık olacaktır.

    • Veri tabanı normalizasyonu yedekleri kaldırır. Gerçek laboratuvar ömründe, fazlalık bütünlüğü iki kez kontrol etmek için kullanılır.
      Bu nedenle gereksiz bilgiler çok erken çıkarılmamalıdır.

    • Bellek / disk boyutu günümüzde daha az sorun gibi görünüyor. Ancak enstrümanlarımızın ürettiği veri miktarı da artmaktadır.

      Birkaç saat içinde kolayca 250 GB yüksek kaliteli veri üretebilen bir cihazla çalışıyorum. Bu 250 GB bir dizi biçimindedir. Bunu uzun forma genişletmek onu en az 4 faktör kadar patlatacaktır: dizi boyutlarının her biri (yanal x ve y ve dalga boyu λ) bir sütun ve yoğunluk için bir sütun olacak). Buna ek olarak, veri analizi sırasında ilk adımım, normalize edilmiş uzun form verilerini tekrar spektrumlar halinde forma dökmek olacaktır.

    • Genellikle, veri analizi belirli bir forma ihtiyaç duyacaktır. Bu yüzden verileri analiz edecek kişiyle konuşmanızı tavsiye ederim.
  • Bu normalleştirme noktalarının ele aldığı toplama işi yorucu ve iyi bir iş değil. Ancak, uygulamada genellikle toplamanın diğer yönlerine çok daha fazla zaman harcıyorum

    • Uygulamada verilerin bütünlüğünü ve bütünlüğünü sağlamak, düzenli veri çalışmamın büyük bir parçası.

    • Veriler kolayca okunabilen bir formatta olmamak / biraz farklı formatlar arasında geçiş yapmak:

      Birçok dosya biçiminde çok fazla veri alıyorum ve genellikle bazı bilgiler dosya adı ve / veya yolunda depolanıyor: araç yazılımı ve / veya üretilen dosya biçimleri tutarlı bir şekilde bilgi eklemeye izin vermiyor, bu yüzden meta bilgileri bir dosya adına bağlayan ek bir tabloya (ilişkisel veri tabanındaki gibi) sahip olabilir veya dosya adı önemli bilgileri kodlar.

      Dosya adlarının desenindeki yazım hataları veya küçük değişiklikler burada çok fazla soruna neden olur.

    • Ölçüm açısından toplama: yanlış ölçümlerden kurtulma (genellikle yanlışlıkla ışığı açan biri, dedektöre çarpan kozmik ışınlar, kameranın çerçeve kaymaları, ... gibi bilinen fiziksel işlemlerden kaynaklanır.).

2
İlk noktanız için +1. Bu sadece veri kaydı ve aktarımı için iyi bir tavsiye değil, ideal olarak deneysel tasarım veya izleme ile ilgili geri bildirimle sonuçlanmalıdır.
Roland
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.