Perkhidmatan Middleware: Data Quality Assurance - dummies

Anda harus menubuhkan dua perkhidmatan jaminan kualiti (QA) yang berbeza dalam aliran perkhidmatan middleware. Anda perlu melaksanakan tugas QA pertama terhadap ekstrak dari sumber data sebelum anda melakukan lebih banyak perkhidmatan middleware.

Jaminan kualiti data: bahagian I

Cobalah untuk menangkap (dan membetulkan) kesilapan dan masalah seawal mungkin. Menggerakkan data ke bawah saluran paip ke arah gudang data adalah sia-sia jika masalah sangat penting yang sama ada memerlukan lebih banyak usaha untuk membetulkan kemudian dalam proses atau hanya tidak dapat diperbetulkan.

Jadi, apakah jenis masalah yang perlu anda cari? Berikut adalah beberapa:

• Nilai dalam unsur data yang melebihi julat munasabah: Pelanggan telah menyerahkan 150 juta pesanan pembelian pada bulan lalu, misalnya, atau pekerja telah bekerja dengan syarikat itu selama 4, 297 tahun, mengikut pangkalan data pekerja dan tarikh penyewaan yang disimpan.

• Nilai dalam elemen data yang tidak sesuai dengan senarai rasmi dan lengkap nilai yang dibenarkan: Nilai mungkin mempunyai kod A, sebagai contoh, apabila satu-satunya nilai yang dibenarkan untuk medan tersebut ialah M dan F. (Jika medan itu dilabel JANTINA, A mungkin berdiri untuk androgynous!)

• Ketidakkonsistenan salib jadual: Untuk penyertaan dalam jadual CUSTOMER_ORDER, tiada penyertaan yang sepadan (seperti yang dikenal pasti oleh CUSTOMER_ID) ada di CUSTOMER_MASTER_TABLE.

• Ketidaksesuaian lintas bidang: Rekod yang mempunyai keadaan atau kod pos yang salah untuk bandar yang ditunjukkan.

• Nilai hilang: Rekod yang telah hilang nilai dalam medan tertentu di mana mereka harus mempunyai kandungan.

• Jurang data: Sebagai contoh, jadual sumber harus mengandungi satu baris data yang merangkumi jumlah unit yang dijual dan dolar jualan untuk setiap bulan dalam tempoh dua tahun yang lalu. Walau bagaimanapun, bagi sejumlah besar pelanggan, tiada baris ada sekurang-kurangnya satu daripada bulan tersebut.

• Data tidak lengkap: Jika maklumat mengenai setiap produk yang dijual oleh syarikat sepatutnya tersedia, sebagai contoh, semua produk yang termasuk dalam ekstrak?

• Pelanggaran terhadap peraturan perniagaan: Jika peraturan perniagaan menyatakan bahawa hanya satu grosir yang dapat menjual produk kepada salah satu pelanggan perusahaan, Anda harus memeriksa apakah ada rekening pelanggan menunjukkan penjualan yang dilakukan melalui lebih dari satu grosir, yang mana boleh menunjukkan data yang salah di sumbernya.

• Data rasuah sejak ekstrak terakhir: Jika pengekstrakan berlaku bulanan, sebagai contoh, anda perlu menjejaki nilai data atau jumlah yang harus tetap, seperti SALES PER PELANGGAN PER BULAN.Jika, dalam bulan berikutnya, nilai JUALAN BAGI PELANGGAN PER BULAN untuk pelanggan yang diberikan untuk bulan sebelumnya, data yang mendasari mungkin telah rosak.

• Ketidakkonsistenan ejaan: Nama pelanggan dibuang beberapa cara yang berbeza, contohnya.

Apa yang anda lakukan apabila anda mencari masalah? Anda boleh mencuba salah satu teknik berikut:

• Memohon peraturan pembetulan automatik. Apabila anda mencari ejaan yang tidak konsisten, contohnya, lakukan pencarian dalam jadual induk pembetulan ejaan sebelumnya dan secara automatik membuat perubahan dalam data.

• Tetapkan rekod untuk ahli pasukan untuk menganalisa dan membetulkan kemudian. Dalam kes ini, anda boleh melakukan bahagian manusia QA bersempena dengan pembetulan automatik.

  Sebagai contoh, pembetulan automatik dibuat, jika boleh, dan laporan tentang masalah lain dimasukkan ke dalam fail berasingan dan dihantar kepada orang QA. Apabila orang QA membuat semua pembetulan manual, anda menggabungkan pembetulan semula ke dalam data yang telah melalui proses QA automatik.

• Keluarkan jet anda. Jika anda menemui masalah yang cukup serius atau memerlukan jumlah penyelidikan yang tidak pasti, pertimbangkan menghentikan proses keseluruhan sehingga selepas anda mencari dan membetulkan masalah tersebut.

Anda boleh membuat proses QA jauh lebih cekap, dan lebih kurang bermasalah, jika anda melakukan analisis sistem sumber menyeluruh. Sekiranya anda mempunyai idea yang cukup baik mengenai jenis masalah data yang mungkin anda dapati dalam setiap sumber data, anda boleh memprogram semula proses QA anda untuk mengesan dan (mudah-mudahan) membetulkan masalah tersebut sebelum meneruskan.

Secara sejarah, organisasi merawat proses QA gudang data sebagai aliran satu arah. Masalah diperbetulkan sebelum data dipindahkan terus ke aliran proses middleware tetapi tidak pernah diperbetulkan dalam sumber data. Kebanyakan gudang data baru mempunyai gelung maklum balas terbina dalam dari proses QA yang membetulkan isu kualiti data dalam data sumber.

Jaminan kualiti data: bahagian II

Setelah selesai proses transformasi, data mesti QA'd - sekali lagi. Anda tidak pernah tahu apa jenis kesalahan atau percanggahan proses transformasi yang mungkin telah dimasukkan ke dalam data. Selepas perubahan berlaku, sebarang proses QA terdahulu tidak sah lagi.

Jalankan data yang disatukan dan diubah melalui jenis langkah QA yang dibincangkan di sini. Walaupun anda mungkin tidak menemui banyak kesilapan asas (seperti kesilapan ejaan atau nilai yang berada di luar jangkauan) jika anda melakukan kerja yang teliti pada QA peringkat pertama, anda masih ingin memastikan. Tambahan pula, pastikan kod atau skrip yang digunakan untuk transformasi data tidak secara tidak sengaja menyebabkan kesilapan baru untuk merayap.

Matlamat QA peringkat kedua ini adalah untuk memastikan data yang disatukan dan berubah bersedia untuk dimasukkan ke dalam gudang data - sebaik sahaja satu langkah lagi berlaku, jika perlu.