The Denny Depok

He…he…he… jangan kaget sama judul saya. Saya emang terkenal sebagai orang yang sering berlebihan dan sok tau, jadi mohon dimaklumi Hari ini kita sebagai orang IT harus berduka karena kisruh DPT bukan lagi mencoreng muka praktisi IT, tapi sudah menyayat-yayat, menginjak-injak dan membuang kekubangan penuh lumpur dan sampah (—> berlebihan deh….)

Ok gini deh, semua pasti sudah tau dong kalo DPT dipermasalahin oleh Mega/Pro dan JK/Win. Kedua pasangan tadi menuduh ada ketidakberesan DPT dan berpotensi menimbulkan permasalahan sampai 25 juta suara (ini saya tonton wawancara pak prabowo di metrotv). Saya sendiri gak yakin yang bermasalah sampe sebesar itu, tapi yang bikin sedih adalah pernyataan ketua KPU, dalam penolakannya ketua KPU menyangsikan kalau DPT yang bermasalah sebesar itu, tapi dia tidak menutup kemungkinan ada data double untuk NIK yang sama. Oke, mendengar ini saya cukup bingung….. Trus diwawancara yang berbeda, perwakilan KPU menyatakan bahwa ada kesulitan untuk mengatur data sampai ratusan juta. Saya cuma manggut-manggut sambil nyoba-nyoba  fasilitas searching google dan bing untuk nemuin data sampai milyaran ato bahkan triliunan record.

Oke kita simulasiin langkah pengelolaan data di KPU sebagai gambaran bagi anda yang enggak mendalami IT. Tapi sebelum mulai, saya mo bilang langkah ini bisa dilakukan oleh semua mahasiswa informatika yang sudah ambil mata kuliah database. Mungkin sebagian besar mahasiswa tersebut jauh lebih baik daripada saya yang biasanya cuma koding di daerah sistem dan komponen.

Pertama adalah kita harus mengelola data ratusan juta record, pilihan paling masuk akal tentu saja dengan  menggunakan database. Database yang mana ? Saya sih enggak tau, tapi tahun 2004 KPU menggunakan SQLServer, kemungkinan tahun ini sama, lagi pula KPU seperti punya kedekatan dengan Microsoft. Langkah selanjutnya yang paling tepat adalah melakukan analisa data apa saja yang peru dicatat, fieldnya apa saja dan hubungan antar data bagaimana. Kalau kosultan IT sedikit profesional (cukup sedikit aja), pasti menelurkan diagram ER, saya gambarkan sedikit deh, hubungan antara pemilih dan  TPS (ini yang dipermasalahin sekarang kan ?).  Jadi sejelek-jeleknya kayak gini :

Maksud gambar diatas, ada data Pemilih dan data TPS yang memiliki hubungan 1 TPS terdaftar n (lebih dari 1) pemilih. Dari diagram diatas, kita bisa mengharapkan database kita bisa menjawab pertanyaan-pertanyaan seperti “Siapa saja pemilih yang terdaftar ?”, “Siapa sajakah yang terdaftar di TPS x ?”, “Pemilih x terdaftar di TPS mana ?” dan banyak pertanyaan lain yang berhubungan dengan pemilih dan TPS.

Langkah selanjutnya adalah mengimplementasikan ke dalam table fisik. Tentu aja yang paling gampang adalah Pemilih jadi satu table dan TPS jadi satu table. Untuk menghindari data double, maka table Pemilih dan TPS diberi primary key yaitu NIK dan TPS_ID. Sedangkan untuk menyimpan hubungan antara table Pemilih dangan table TPS, karena hubungannya 1 ke N, maka diimplentasikan dengan menitipkan ID table yang kecil di table yang besar, dalam hal ini kita menambahkan field TPS_ID di table Pemilih. Dengan demikian bisa tercapai database yang bisa menjawab semua pertanyaan diatas, dan membuang jauh-jauh pernyataan bahwa ada kemungkinan data double untuk NIK yang sama.

Sedangkan untuk menjawab pertanyaan ada tidak orang yang sama dicatat 2 kali (dengan 2 NIK), kita bisa melakukan query dengan contoh sebagai berikut :

select nik, count(*) from pemilih group by (nama+alamat) having count(*) > 0

Atau sql semacam diatas untuk membantu pengecekan data double.

Kemudian untuk menjawab kesulitan pengelolaan data ratusan juta record, ya jangan pesimis dulu… Google yang datanya super duper besar bisa menampilkan hasil dalam hitungan milidetik. Kalau ratusan juta sih bukan masalah. Lagi pula yang mengimplementasi database ratusan juta bukan cuma KPU, saya secara pribadi pernah mengimplementasikan yang datanya bertambah 800 ribu perhari, dan sistem tersebut harus membuat laporan bulanan (24 juta-an record) dan tahunan (280 juta-an record). Pengolahan data sebanyak itu tentu perlu kekuatan prosesor dan memori yang mumpuni, tapi bukan hambatan karena KPU punya dana cukup untuk beli server seperti itu (dan sepertinya sudah ada, karena punya kenalan yang ikutan tender server KPU di daerah, speknya cukup tinggi).

Desain database yang baik, seperti penggunaan index yang tepat dan penggunaan segmentasi data yang tepat akan membuat pengolahan data ratusan juta tersebut bukan masalah besar. Perlu waktu, tentu saja, tapi bukan hal yang tidak mungkin.

Saya sih tidak tahu cara kerja konsultan IT di KPU, mudah-mudahan jauh lebih baik dari pada simulasi amatiran saya ini. Sepertinya IT KPU harus meklarifikasikan cara kerja sendiri karena menurut saya pemberitaan yang beredar sudah sangat mencederai profesi konsultan IT. Mungkin yang berkembang saat ini cuma kecurangan, tapi saya yakin isu tersebut akan berkembang termasuk juga pada kapabilitas praktisi IT di indonesia dalam mengimplementasikan tugas-tugas yang sebenarnya sangat sederhana dan mudah untuk dilakukan.

Tapi mendengar pemberitaan sekarang, saya jadi menduga kalau konsultan IT KPU melakukan langkah yang berbeda, yaitu pada langkah pertama, jadi bukannya pakai database tapi pakai software pengolah data favorit sepanjang masa : MS Excel

July 6th, 2009 | Category: Gosip, Programming | Subscribe to comments | Leave a comment | Trackback URL