Masalah umum adalah seluruh subarea pemrograman yang disebut pembersihan data yang merupakan bagian dari subarea yang lebih besar yang disebut integrasi data . Menghindari masalah-masalah semacam ini kemungkinan besar menjadi alasan migrasi dari lembar-lembar Excel dan mengapa pengembang senior tidak ingin membiarkan bidang menjadi nol. Saya tidak berpikir itu tidak masuk akal untuk mengatakan bahwa ini adalah salah satu sumber kompleksitas yang lebih besar dalam migrasi data.
Hanya memilih untuk menggunakan NULL kapan pun Anda bisa, kemungkinan besar adalah hal yang salah untuk dilakukan, apalagi mengubah model data untuk membuat lebih banyak bidang dapat dibatalkan. Excel memiliki pemeriksaan integritas yang lemah atau tidak ada yang kemungkinan menjadi penyebab banyak masalah ini. Hal yang salah untuk dilakukan adalah menghapus pemeriksaan integritas di database baru dan membuang sampah ke dalamnya. Ini hanya akan melanggengkan masalah dan menambah kompleksitas yang signifikan pada integrasi di masa depan yang harus berurusan dengan data yang tidak masuk akal.
Beberapa perbedaan kemungkinan disebabkan oleh ketidaksesuaian model data. Berurusan dengan ini sebagian besar masalah menjadi (akrab) akrab dengan kedua model data dan mengetahui bagaimana memetakan yang lama ke yang baru. Selama yang baru adalah mampu menangkap yang lama. (Jika tidak, tim Anda kemungkinan memiliki masalah yang sangat besar.) Ini dapat dengan mudah memerlukan lebih banyak pekerjaan daripada hanya menyalin kolom. Darkwing memberikan contoh yang bagus tentang hal ini (dan juga mengapa memasukkan NULL secara membabi buta adalah hal yang salah untuk dilakukan). Menguraikannya, jika model lama memilikiReceivedDate dan InProgressbit dan model baru memiliki StartDatedan ProcessingEndTime, Anda akan perlu memutuskan apakah dan bagaimana untuk mengatur ProcessingEndTime. Bergantung pada bagaimana penggunaannya, pilihan yang masuk akal (tapi sewenang-wenang) mungkin untuk membuatnya sama denganStartDate (atau tidak lama kemudian jika itu akan menyebabkan masalah).
Namun, beberapa perbedaan kemungkinan karena data yang "harus" ada di sana yang hilang atau rusak. (Kemungkinan besar dari kesalahan entri data atau migrasi masa lalu atau bug yang tidak ditangani dengan baik dalam sistem pemrosesan data.) Jika tidak ada seorang pun di tim Anda yang mengantisipasi hal ini, maka Anda (secara kolektif) telah menyiapkan diri Anda untuk menghabiskan 20% dari waktu proyek sedang " hampir selesai. (Itu nomor yang dibuat-buat, tetapi bisa jadi jauhlebih buruk dari itu, atau lebih baik. Itu tergantung pada seberapa banyak data yang salah, seberapa penting itu, seberapa rumit itu, seberapa mudah untuk mendapatkan keterlibatan dari mereka yang bertanggung jawab atas data, dan faktor-faktor lain.) Setelah Anda menentukan bahwa data itu "seharusnya ada "di sana tetapi hilang. Biasanya Anda akan berusaha menentukan tingkat masalah dengan menanyakan sumber data lama. Jika lusinan atau ratusan entri, maka itu mungkin kesalahan entri data dan pelanggan yang bertanggung jawab atas data harus mengatasinya secara manual (yaitu memberi tahu Anda apa nilai yang seharusnya.) Jika jutaan entri (atau sebagian kecil dari data) , maka Anda mungkin perlu mempertimbangkan kembali apakah Anda benar mengidentifikasi bahwa itu "harus" ada. Ini mungkin menunjukkan kesalahan pemodelan di sistem baru.
Sebagai contoh, bayangkan faktur yang memiliki jumlah dan total per item (tetapi bukan harga satuan), kecuali bahwa beberapa jumlah itu hilang secara misterius. Berbicara kepada orang yang memproses faktur semacam itu dapat menghasilkan satu (atau lebih) dari skenario berikut: 1) "oh, jumlah kosong berarti jumlah 1", 2) "oh, saya tahu barang-barang itu berharga sekitar $ 1.000 jadi, jelas ini adalah pesanan untuk 2 ", 3)" ketika itu terjadi, saya mencari harga di sistem lain ini dan membaginya ", 4)" Saya mencarinya di sistem lain ", 5)" itu bukan data nyata ", 6)" tidak pernah melihat itu sebelumnya ".
Seperti yang disarankan, ini dapat menunjukkan beberapa cara untuk secara otomatis menyelesaikan situasi, tetapi Anda harus berhati-hati bahwa solusi berlaku untuk semua kasus. Sudah biasa bagi sistem lain untuk terlibat yang dapat memeriksa silang data, dan ini adalah hal yang baik. Namun, seringkali merupakan hal yang buruk sejauh mungkin sulit untuk mendapatkan akses ke dan berintegrasi dengan sistem-sistem ini untuk melakukan pemeriksaan silang, dan seringkali terungkap bahwa sistem saling bertentangan bukan hanya dengan satu data hilang. Beberapa intervensi manual sering diperlukan, dan tergantung pada skala, mungkin memerlukan tooling dan interface yang akan dibuat khusus untuk tugas pembersihan data. Seringkali yang dilakukan adalah data yang diimpor sebagian tetapi baris dengan data yang hilang dikirim ke tabel terpisah di mana mereka dapat ditinjau.