Praktik Terbaik untuk Membuat 'Data Rapi'

Hadley Wickham menulis artikel bintang yang disebut "Tidy Data" ( tautan ) di JSS tahun lalu tentang manipulasi data dan memasukkan data ke dalam kondisi "optimal" untuk melakukan analisis. Namun, saya bertanya-tanya apa praktik terbaik dalam hal menyajikan data tabular dalam pengaturan kerja? Katakanlah rekan kerja Anda meminta Anda untuk memberinya beberapa data. Apa beberapa aturan umum yang Anda gunakan saat menyusun data itu? Apakah pedoman dalam "Data Rapi" sama berlaku dalam kasus di mana Anda berbagi data dengan profesional non-data? Jelas, ini sangat spesifik konteks tapi saya bertanya tentang 'praktik terbaik' tingkat tinggi.

Seperti yang dapat diharapkan dari Hadley, artikelnya berisi definisi data rapi yang bagus dan saya setuju dengan hampir semua yang ada di artikelnya dan percaya itu tidak hanya berlaku untuk "profesional data". Namun, beberapa poin yang ia buat relatif mudah untuk diperbaiki (misalnya, dengan paket yang ia tulis) jika beberapa masalah yang lebih mendasar dihindari. Sebagian besar masalah ini adalah hasil dari penggunaan Excel secara luas. Excel adalah alat yang berharga dan memiliki kelebihan, tetapi beberapa fasilitasnya menimbulkan masalah bagi analis data.

Beberapa poin (dari pengalaman saya):

1. Beberapa orang menyukai spreadsheet berwarna-warni dan menggunakan banyak opsi pemformatan. Ini semua baik-baik saja, jika itu membantu mereka mengatur data mereka dan menyiapkan tabel untuk presentasi. Namun, berbahaya jika warna sel benar-benar menyandikan data. Sangat mudah kehilangan data ini dan sangat sulit untuk mendapatkan data seperti itu diimpor ke dalam perangkat lunak statistik (misalnya, lihat pertanyaan ini di Stack Overflow).
2. Kadang-kadang saya mendapatkan beberapa data yang diformat dengan baik (setelah saya memberi tahu orang-orang bagaimana mempersiapkannya), tetapi meskipun meminta mereka untuk menggunakan kolom khusus atau file terpisah untuk komentar, mereka memutuskan untuk memberikan komentar di kolom nilai. Saya tidak hanya perlu berurusan dengan kolom ini dengan cara khusus ketika mengimpor data, tetapi masalah utamanya adalah bahwa saya perlu menelusuri semua tabel untuk melihat komentar seperti itu (yang biasanya tidak saya lakukan). Ini menjadi lebih buruk jika mereka menggunakan fasilitas komentar Excel.
3. Spreadsheet dengan beberapa tabel di dalamnya, beberapa baris tajuk atau sel yang terhubung menghasilkan pekerjaan manual untuk menyiapkannya untuk diimpor dalam perangkat lunak statistik. Analis data yang baik biasanya tidak menikmati pekerjaan manual semacam ini.
4. Tidak pernah menyembunyikan kolom di Excel. Jika tidak diperlukan, hapus saja. Jika dibutuhkan, tunjukkan.
5. xls dan turunannya bukan format file yang cocok untuk bertukar data dengan orang lain atau mengarsipkannya. Rumus diperbarui ketika file dibuka dan versi Excel yang berbeda mungkin menangani file secara berbeda. Saya merekomendasikan file CSV sederhana sebagai gantinya, karena hampir semua perangkat lunak terkait data dapat mengimpor itu (bahkan Excel) dan dapat diharapkan bahwa itu tidak akan segera berubah. Namun, perlu diketahui bahwa Excel membulatkan ke angka yang terlihat saat menyimpan ke CSV (dengan demikian membuang presisi).
6. Jika Anda ingin membuat hidup lebih mudah bagi orang lain, patuhi prinsip-prinsip yang diberikan dalam artikel Hadley. Memiliki kolom nilai untuk setiap variabel dan kolom faktor yang menentukan strata.

Mungkin ada beberapa poin tambahan yang tidak terlintas di pikiran saya.

Pertama, saya biasanya orang yang mendapatkan data. Jadi ini dapat dibaca sebagai daftar keinginan saya.

• Karena itu poin saya yang paling penting adalah: berbicara dengan orang yang akan menganalisis data.

• Saya melihat sekilas di atas kertas: banyak yang ditulis Hadley dapat diringkas dengan 'menormalkan basis data relasional Anda'.

• Tetapi dia juga menyebutkan bahwa tergantung pada apa yang sebenarnya terjadi, masuk akal untuk memiliki variabel yang sama baik dalam bentuk panjang atau lebar.

  $I$$λ$$λ_i$$λ_i$$λ_i$

• Namun, ada beberapa keuntungan praktis untuk tampilan / distribusi data yang tidak dinormalkan:

  • Mungkin lebih mudah untuk memeriksa apakah data sudah lengkap .

  • Tabel yang terhubung seperti dalam basis data relasional yang dinormalisasi adalah OK jika data sebenarnya dalam basis data (dalam arti perangkat lunak). Di sana, Anda dapat menempatkan kendala yang memastikan kelengkapan. Jika data dipertukarkan dalam bentuk beberapa tabel, dalam praktiknya tautannya akan berantakan.

  • Normalisasi basis data menghilangkan redudansi. Dalam kehidupan lab nyata, redudansi digunakan untuk memeriksa integritas.
    Dengan demikian informasi yang berlebihan tidak boleh dihapus terlalu dini.

  • Memori / ukuran disk tampaknya kurang menjadi masalah saat ini. Tetapi juga jumlah data yang dihasilkan instrumen kita meningkat.

    Saya bekerja dengan instrumen yang dapat dengan mudah menghasilkan 250 GB data berkualitas tinggi dalam beberapa jam. 250 GB itu dalam format array. Memperluas ini ke bentuk panjang akan meledakkannya dengan faktor setidaknya 4: masing-masing dimensi array (lateral x dan y, dan panjang gelombang λ) akan menjadi kolom, ditambah satu kolom untuk intensitas). Selain itu, langkah pertama saya selama analisis data biasanya adalah untuk memasukkan data bentuk panjang yang dinormalisasi kembali ke bentuk spektra.

  • Biasanya, analisis data akan membutuhkan bentuk tertentu. Inilah mengapa saya menyarankan untuk berbicara dengan orang yang akan menganalisis data.

• Pekerjaan merapikan yang ditangani oleh poin-poin normalisasi ini membosankan dan bukan pekerjaan yang baik. Namun, dalam praktiknya saya biasanya menghabiskan lebih banyak waktu pada aspek lain dari kerapian

  • Memastikan integritas dan kelengkapan data dalam praktik adalah bagian besar dari pekerjaan data saya yang merapikan.

  • Data tidak berada dalam format yang mudah dibaca / beralih di antara format yang sedikit berbeda:

    Saya mendapatkan banyak data dalam bentuk banyak file, dan biasanya beberapa informasi disimpan dalam nama file dan / atau path: perangkat lunak instrumen dan / atau format file yang dihasilkan tidak memungkinkan untuk menambahkan informasi secara konsisten, jadi kami baik memiliki tabel tambahan (seperti dalam basis data relasional) yang menautkan informasi meta ke nama file atau nama file menyandikan informasi penting.

    Kesalahan ketik atau sedikit perubahan pada pola nama file menyebabkan banyak masalah di sini.

  • Merapikan dari sudut pandang pengukuran: menyingkirkan pengukuran palsu (biasanya disebabkan oleh proses fisik yang diketahui seperti seseorang tanpa sengaja menyalakan lampu, sinar kosmik mengenai detektor, pergeseran bingkai kamera, ...).