Semoga Database Portal Akademik UNP Tidak Seperti Database Digital Library UNP
Awal dengar digilib dari bg aulia waktu diskusi malam kemaren. Sekilas saya mendengar databasedigital library UNP tidak dinormalisasi. di manual pemakaian yang field penerbit di entri atau diketikkan. yang otomatis akan membuat ambigu. kenapa? database akan menganggap beda ofset dan offset. dari sekian buah buku terbitan andi offset yang di entri pasti ada kesalahan huruf atau salah tulis atau salah ketik.
Setelah diskusi itu saya hanya mikir-mikir wah parah juga itu ko gak dibuat tabel masternya. nanti entri tinggal pilih penerbit kalau tidak ada di list bisa di add. jadi gak terjadi duplikasi data atau data ditulis berulang2. saya rasa dosen Sistem Basis Data saya Drs. Elfi Tasrif, MT akan lebih jelas menjelaskan kalau tentang database ini. database baginya sudah seperti makanan sehari2. normalisasi tabel, itulah inti kuliah databasenya. kalau tugas akhir database belum ok jangan berharap maju ke langkah berikutnya.(terbayang apa komentar dosen saya yang ceplas-ceplos ini kalao samapi lihat hal ini:p)
Kecemasan saya semakin besar karena pembuat softwaredigital library dan software portal akademik online di UNP saat ini adalah sama, Gamatechno(terakhir di cek webnya pindah dari cms sendiri ke joomla...). Kalau saja databaseportal akademik dibuat seperti databasedigilib bisa dikatakan database akademik UNP akan menuju kekacauan. semoga saja tidak :(
Sebenarnya memang tidak arif menyerahkan sistem akademik sebuah universitas pada seorang programmer. minimal 2 orang programmer dan 2 orang database enginer. Saya sangat berharap sekali database akademik yang telah dipakai beberapa semester ini dulu sudah di OK kan para ahli-ahli database di UNP terutama dari FT dan juga pak doni dari pustaka UNP yang awalnya membuat software pustaka dengan foxpro seingat saya. Tapi saya percaya pada tim IT UNP yang memang berisi dosen-dosen saya di FT dulu.
Barusan saya melihat langsung tampilan online digilib UNP dari laptop compaqmas eko. tampilan awal sederhana saja langsung menyuguhkan pencarian. dan pencarian tingkat lanjut. untuk mencoba pencarian saya masukkan kata INTERNET dan mengklik search. digilib mencari buku2 dan mendapatkan hasil 13 buah buku.
Setelah saya amati hasil pencarian ada yang lucu :p, terdapat 3 nama untuk penerbit yang sama dengan tulisan dan huruf yang berbeda. ada ANDI, Andi Ofset dan Andi. yang memang maksunya adalah Penerbit ANDI yogyakarta. saya jadi mikir. kalau saya cari berapa buku terbitan andi, berapakah hasilnya :D
Melihat hal ini baru saya teringat kata-kata bg aulia kemarin malam tentang field penerbit yang diketikkan. jadi memang databasenya tidak normal. atau mungkin juga hanya memang sekedar pemindahan dari tabel excel ke database :p.
Sekarang saya coba cari berdasarkan penerbit di pencarian tingkat lanjut, saya masukkan kata ANDI di field penerbit dan menghasilkan 197 buku dan... seperti sebelumnya akan banyak andi andi ofset nya. heheh(kayaknya programmernya offset neh :p) ada andi dengan satu F Andi Ofset dan ada dengan 2 F Andi Offset. ya sudah saya coba lihat halaman berikutnya...
Uppss..!!! :o :o
Hasil pencarian internet tadi hilang :o dan halaman menampilkan halaman 11-20 dari 38703 buku. yang kalau di teliti ini jumlah semua koleksi buku. ada kesalahan fatal disini karena keyword pencarian tak di bawa ke halaman berikutnya sehingga sistem menganggap input kosong dan menampilkan semua buku.. hufff :(
Mungkin masih ada lagi tapi saya sudahi saja, saya tulis di blog supaya jadi perhatian pihak kampus saya. berarti memang software hasil gamatechno tidak di cek dulu oleh tim IT UNP. Tadi juga sempat cek file css nya ada copyleftHerman Saksono, Gamatechno 2006. sekarang sudah 2010 :p. tapi walau 2006 gak nyangka juga gamatechno akan membuat software dengan kesalahan fatal seperti diatas. yang notabene adalah perusahaan dengan beberapa programmer dan database enginer(kalo salah maaf:))
Terpikir lagi software portal akademik apakah tidak seperti ini juga?atau agak seperti ini? wah terbayang kan kacawnya. ini database tidak main2, data ribuan mahasiswa dan ribuan nilai ratusan dosen....bla blabla
yup benar juga saya juga sering mengalaminya tapi gini dalam pembuatan database sederhana perpustakaan saja field2 yang akan ditulis berulang2 akan di pecah menjadi tabel baru dan menempatkan foreign id nya di tabel utama.masalah kecepatan tentu saja karena akan mengqueri nama ke tabel master penerbit. tapi apakah ini memberatkan sistem?gak terlalu lah. query dan script bisa di optimalkan termasuk mysqlnya .kalau ditanya pun klien pasti suka memilih penerbit dari pada mengetikkannya :D lagian jumlah penerbit kan gak sebanyak buku :p hal lain mengakalainya... database penerbit kan ada? ada ikatan atau persatuannya. toh ntar itu-itu juga penerbitnya. dalam sebulan gak akan sampe ratusan penerbit baru. jadi sebeanrnya ini memudahkan dan rapi. kalau kita mengorbankan database demi kemudahan otomatis untuk pengembangan kita telah menutupnya. akan sangat susah nantinya mengubah tabel2 lagi setelah database terisi jutaan entri.karena kalau dalam hal buku yang sering ditanya adalah?#berapa buku terbitan penerbit ini?#berapa buku yg ditulis orang ini?#berapa buku terbitan ini dan ditulis orang inidll(laporan gitulah..)tapi kalau tujuannya hanya cari judul buku saja sekedar informasi judul2 buku gpp, acceptedkalkulasi data akan bagus. kalau sekarang tentu kalau mau mencari hal di atas pake query LIKE:... WHERE penerbit LIKE %"andi"% gimana kalau ada penerbit anditama, andika, kickandi :p srikandi andia andie dll?(penerbit andi jadi ngiklan neh hehehe)apakah hasilnya nanti dapat di percaya? saya juga diatas pendapat pribadi. kalau ada yang salah mohon pencerahan. bukankah untuk masalah kandungan kita percaya doker kandungan... bukan tukang bangunan :)piss