Pribadi

Archive for the ‘Technology Tips & Info’ Category

 

Fennec alpha 2

Fennec alpha 2

Langsung aja ke TKP di Fennec alpha 2.

Iklan

Biasanya jika sedang mendalami data warehouse, akan menemui dua tokoh dalam beberapa literatur. Ralph Kimball dan Bill Inmon. Keduanya cukup populer, dan cukup kontroversial karena kedua pendekatan mereka dalam membangun data warehouse sangat kontradiksi.

Penjelasan sederhana dari pendekatan Ralph Kimball adalah bahwa data warehouse berawal dari kumpulan data mart (bottom-up approach) yang berada dalam sebuah lingkungan enterprise (sebuah buzzword yang hampir semua orang memiliki pandangan yang berbeda, enterprise). Dalam desainnya, informasi dalam data warehouse selalu disajikan dalam bentuk dimensional. Fact, measure dan dimension adalah kata kunci dari pendekatan bapak yang satu ini.

Berbeda dengan Bill Inmon yang menegaskan bahwa data warehouse sebaiknya dibangun jika desain arsitektur data warehouse sudah dibuat (top-down approach). Karena data warehouse merupakan bagian dari business intelegent (apa lagi neh?) maka segala informasi berasal dari satu data warehouse. Data warehouse 3rd normal form atau 3NF adalah kata kunci beliau.

Antara pendekatan Ralph Kimball dan Bill Inmon, manakah yang harus digunakan?

Kebanyakan artikel pasti tidak akan menyalahkan kedua pendekatan ini. Karena keduanya memang bisa diterapkan. Namun jika semakin mendalami data warehouse, pendekatan Ralph Kimball akan terlihat masuk akal. Bukan karena pendekatan Bill Inmon salah, melainkan karena pendekatan Ralph Kimball sangat mudah untuk diimplementasikan. Kita tidak perlu memahami seluruh data enterprise untuk memulai sebuah data warehouse. Kata mereka, untuk memulai akan sangat mudah dengan Ralph Kimball, namun akan banyak mengalami kesulitan pada jangka panjang. Susah dikelola! Benarkah?

Selain dibutuhkan pemahaman yang menyeluruh terhadap data enterprise, pendekatan Bill Inmon sangat susah untuk dimulai. Namun dalam jangka waktu yang panjang, akan sangat mudah dalam mengelolanya (jika desainnya memang sudah benar!?). Karena pendekatan Bill Inmon susah dalam tahap desain awal, maka sangat wajar jika kebanyakan perusahaan konsultan yang bergerak dalam data warehouse menawarkan cetak biru (blueprint) desain data warehouse “best practice” dengan pendekatan 3NF. Agar para perusahaan tak perlu bersusah payah mendesain dari awal mengenai desain data warehouse di bidang usahanya. Mereka menyebutnya data model.

Jika harus memilih di antara kedua pendekatan tersebut, apa yang akan saya pilih?

Sebelum saya memilih, perlu saya jelaskan apa sebenarnya data warehouse pada kenyataannya. Saya bukan ingin menjelaskan pemodelan yang biasa ditemui di banyak literatur yang mengatakan 3NF atau dimension. Tapi saya akan mencoba mejelaskan data warehouse dari sudut pandang berbeda. Ukuran atau size. Saya coba ambil contoh model SalesFact dari artikel pak Toto mengenai Perancangan Data Warehouse.

Ukuran 1 dantum/tuple/record = ~40 bytes, rincian sebagai berikut:

  • kode_barang > varchar(5) = ~7 bytes.
  • kode_periode > varchar(8) = ~10 bytes.
  • kode_lokasi > varchar(5) = ~7 bytes.
  • total_penjualan > double = ~8 bytes.
  • total_penerimaan > double = ~8 bytes.

Karena menggunakan pendekatan dimension maka potensi jumlah record dalam sebulan sekitar 60.000 record, rincian sebagai berikut:

  • kode_barang.
    Jika seandainya menjual 100 jenis barang.
  • kode_periode.
    Asumsi bahwa varchar(8) akan berisi info “YYYYMMDD” (contoh: “20080925”), berarti summary per hari, yaitu 30 hari.
  • kode_lokasi
    Jumlah cabang yang dimiliki perusahaan ini, anggaplah ada sekitar 20 (biar gampang hitungnya huehuehuehue).

Maka dalam sebulan akan membutuhkan ruang data sebesar 2.400.000 bytes atau 2,4 Mb. Sangat kecil jika dibandingkan dengan ruang data yang dijual di pasar (sudah ada 1 tera byte loh!). Tunggu dulu, ini baru data sebulan. Apa gunanya kalau cuma data sebulan (ya ada seh gunanya, tapi). Setidaknya menyimpan hingga 6 -24 bulan. Supaya dapat terlihat trend data dan pola statistiknya. Jadi berapa ukurannya? 57.600.000 bytes atau 57 MB.

Masih terhitung kecil? Apakah kamu pernah memperhatikan bahwa data yang disimpan dalam database akan bertambah besar? Akan ada kebutuhan untuk indeks, spool dan temp (bergantung jenis database yang digunakan). 

Tapi, karena jumlah ukuran data yang terlibat masih kecil, maka keputusan memilih menggunakan pendekatan manapun akan sama saja. Susah untuk dikelola? Ah bercanda.

Namun bagaimana membangun data warehouse jika dihadapkan data super besar?

Dalam contoh di atas, kalau menurut opini saya, IMHO katanya, tidak perlulah menggunakan data warehouse pendekatan Inmon atau Kimball. Kenapa tidak simpan saja detail per transaksi? Bukankah akan jadi lebih akurat dan lagipula tidak membutuhkan ruang data yang besar.

Lain halnya jika dihadapkan dengan data super besar dan super kompleks. Barulah data warehouse sangat diperlukan (benarkah?). Namun, seperti apa sebenarnya data super besar dan super kompleks itu?

Salah satu contoh yang sempat terpikir adalah operator seluler dengan jumlah pelanggan yang diklaim sebanyak 58 juta orang (wah jika 1 record adalah 1 byte, maka 58 juta akan menjadi 58 Mb, hmmm). Seandainya perusahaan telekomunikasi ini ingin menyimpan info mengenai:

  • nomor pelanggan > varchar(18) = ~12 bytes.
  • waktu melakukan layanan > varchar(8) = ~ 10 bytes (jika pakai char(8) akan menjadi 4 bytes loh).
  • layanan telekomunikasi yang digunakan (SMS, voice, GPRS dll) > varchar(3) = ~5 bytes.
  • total penggunaan layanan > double = ~8 bytes.
  • lokasi penggunaan > varchar(5) = ~7 bytes.
  • total durasi/byte data yang digunakan > double = ~8 bytes.
  • total pendapatan > double = ~8 bytes.

Jadi 1 record berukuran sekitar 51 bytes. Hitungan belum selesai:

  • nomor pelanggan.
    Ada sekitar 58.000.000 pelanggan.
  • waktu melakukan layanan.
    Kurang lebih sama dengan contoh sebelumnya 30 hari.
  • layanan telekomunikasi yang digunakan (SMS, voice, GPRS dll).
    Hmmm, SMS, voice dan GPRS berarti cuma 3.
  • lokasi penggunaan.
    Kalau kata iklan bahwa sudah menjangkau lebih dari 1000 kecamatan di Indonesia. 

Akan ada sekitar 5.220.000.000.000 bytes (atau 5,22 Tb) data dalam sebulan. Jika disimpan dalam 24 bulan berarti menjadi 125,28 Tb. 

Dengan ukuran data sebesar itu, pemilihan dimension pada pendekatan Kimball harus benar-benar memilih tingkat granularitas yang mumpuni (bisa tidak?). Jika menggunakan Inmon maka harus mempersiapkan budget yang tidak sedikit untuk investasi perangkat keras. Karena 3NF boros ruang penyimpanan!

Ketika dihadapkan data yang super besar, kedua pendekatan ini harus benar-benar dipertimbangkan. Namun kebanyakan profesional IT akan memilih pendekatan 3NF-nya bapak Inmon (atau cuma profesional IT sales?). Karena sudah terbukti sebagai “best practice”. Cukup investasi di satu sisi saja: budget. 

Pada kenyataannya, hampir semua data warehouse memiliki kondisi seperti ini. Boros ruang penyimpanan! Dan dalam bisnis, keborosan merupakan  sesuatu yang harus dihindari, kecuali dalam tujuan riset akademis di kampus. Selebihnya kita harus dapat menjustifikasi bahwa ROI menggunakan data warehouse masuk dalam profitabilitas jangka pendek (karena jangka panjang sudah pasti). Maukah perusaahaan bertaruh dana dalam jumlah yang tidak sedikit dalam membangun data warehouse yang notabene tidak memiliki hubungan langsung dengan penjualan barang atau layanan?

Jadi, jika dihadapkan data super besar, pendekatan apa yang saya pilih?

Terus terang saya setuju dengan pendapat Bill Inmon bahwa data warehouse adalah bagian dari business intelegent. Namun saya sangat tidak setuju jika harus mendesain secara komprehensif arsitektur data warehouse sebelum implementasi. Lagipula, cetak biru “best practice” tawaran dari pihak konsultan pun tidak bisa langsung dipakai dan diterapkan. Kenyataannya, saya perlu memahami data enterprise terlebih dahulu agar bisa diterjemahkan pada cetak biru tersebut (termasuk mempelajari cetak birunya). Sangat tidak mudah.

Dengan pendekatan Kimball pun saya tidak bisa memastikan tingkat granularitas data yang dibutuhkan oleh perusahaan. Bisa jadi data warehouse yang saya bangun bersifat GIGO (Garbage In Garbage Out). Artinya saya menyimpan informasi yang tidak dibutuhkan oleh bisnis, karena saya merasa bahwa ada data sekiranya bisnis akan membutuhkan. Dan hal ini menyebabkab ruanya penyimpanan menjadi tempat penyimpanan data yang tidak diperlukan. Hal ini pun dapat terjadi pada pendekatan Inmon. 

Karena saya sependapat bahwa data warehouse adalah bagian dari business intelegence maka sudah seharusnya saya memilih dengan menggunakan sudut pandang bisnis. Ada sebuah pendekatan lagi yang menurut saya sangat cocok dilakukan dalam membangun data warehouse: “business-led approach”. kata kuncinya adalah pendekatan business-led dan Rob Mattison. Ada yang pernah dengar?

Sudah cukup lama tidak menulis artikel mengenai IT atau Information Technology, mau saya coba mulai lagi dengan artikel ringan mengenai fenomena tingkah laku orang IT di kebanyakan perusahaan. Sindrom atau gejala Santa Klaus pada orang IT.

Sebuah fenomena yang terjadi antara hubungan entitas IT dan entitas  bisnis. Entitas IT telah menjadi pengurus atau pengelola sumber daya IT. Sedangkan entitas bisnis telah menjadi peminta-minta, meminta agar urusan atau pekerjaan mereka menjadi lebih mudah, nyaman dan menguntungkan. Karena entitas IT memiliki kontrol pada sumber daya IT maka dengan segala upaya agar semua permintaan dapat terpenuhi. Fenomena inilah yang disebut sebagai sindrom Santa Klaus.

Namun sayangnya entitas IT hanya bisa memberikan berdasarkan kebutuhan yang paling mudah dipenuhi. Dengan berkembangnya kompleksitas bisnis, permintaan entitas bisnis akan semakin kompleks dan beragam. Di sinilah momen di mana entitas IT sudah tidak mampu lagi menjadi Santa Klaus. Entitas bisnis sudah tidak lagi bisa tersenyum puas dan senang terhadap performa entitas IT. 

Fenomena ini terjadi karena entitas IT terhadap entitas bisnis berfokus pada nilai kepuasan entitas bisnis. Apakah ini salah? Tidak, namun terkadang bisa jadi salah.

Dalam studi kasus data warehouse, dengan fokus seperti di atas, entitas IT memiliki kecenderungan melakukan metodologi arsitektur “dump and run”. Banyak sekali perusahaan yang memanfaatkan teknologi data warehouse menggunakan pendekatan ini. Bahkan kebanyakan skripsi atau tugas besar kuliah S1 pun arsitektur ini sangat populer.

Fact and Dimensional in Point of Sales (Data Warehouse Toolkit, Ralph Kimball, Page 22)

Oke, kita punya desain Operasional Data Store dan spesifikasi log dari transaksi. Selanjutnya mendesain arsitektur data warehouse menggunakan info tersebut. Pendekatan ini sangat umum terjadi. 

Permasalahan akan muncul ketika dihadapkan sebuah log transaksi yang memiliki volume luar biasa (kira-kira 1 hari berjumlah lebih dari 10 GBytes). Arsitektur data ware house sudah dibuat, namun bagaimana menjustifikasi kebutuhan terhadap hardware maupun software yang mampu memberikan performa terbaik kepada entitas bisnis? Padahal data warehouse ini sendiri belum memberikan keuntungan yang nyata terhadap perusahaan (karena memang belum berjalan). Kalau pun sudah berjalan, apakah entitas bisnis akan menggunakan semua data tersebut. Tidak semua data yang disimpan merupakan informasi yang dapat memajukan perusahaan, lalu kenapa terus saja disimpan di sana? Bukankah dengan tidak menyimpannya maka IT dapat mengefesiensikan storage dari data warehouse.

Jadi seharusnya apa fokus dari entitas IT terhadap entitas bisnis? Dan metodologi apa yang tepat diimplementasikan untuk data warehouse yang memiliki volume data luar biasa?

Kesan pertama dari Google Chrome, produk Google terbaru yang konon katanya merupakan tipe web browser dengan arsitektur berbeda dengan kebanyakan web browser pada umumnya, yang saya rasakan:

  • Cepat!!
  • Cepat!!
  • Ringan!
  • Halaman terkesan luas.
  • Tampilan simple dan elegan.

Terus terang, saya langsung jatuh cinta pada pandangan pertama. Sepertinya saya akan segera pindah dari Firefox 🙂 Tapi ada satu hal yang membuat saya tidak suka adalah konfigurasi proxy yang menyatu dengan konfigurasi Internet Explorer. Hal ini dikarenakan IE pada notebook kantor saya selalu direset menggunakan proxy default (yang lambat). Padahal saya ingin Chrome menggunakan konfigurasi proxy seperti pada Firefox sehingga saya bisa menggunakan proxy pilihan saya.

Oia, berikut teknologi serta konspirasi terkait dengan Chrome ini:

Gmail Redesign

Gmail Redesign

Buat yang merasa bosan dengan tampilan produk Google seperti GMail, GCal dan lain-lain, bisa mencoba ekstension Firefox bernama Google Redesign. Saat ini baru meredesign produk GMail dan GCal.

Buat yang khawatir jikalau produk ini kemungkinan disisipi kode berbahaya seperti mencatat password GMail kita. Jangan khawatir, karena ekstension ini mengubah stylesheet dari default Google saja. Silahkan mencoba!

Ada sebuah blog yang menawarkan NSP gratis dengan syarat yang sangat mudah. Berikut di kutip langsung dari blog tersebut:

Mau NSP Gratis?

Mau NSP Gratis?

Anda mau NSP Gratis? Dapatkan 10 NSP GRATIS  dari MobileIndonesia.net untuk tiap bulannya.

Caranya mudah, cukup dengan berkontribusi dalam MobileIndonesia.net dengan cara mengirimkan artikel/tulisan Anda, Anda berpeluang mendapatkan 10 NSP Gratis setiap bulannya.

Syaratnya :

  • Artikel ditulis dalam bahasa Indonesia.
  • Tema harus seputar teknologi telekomunikasi.
  • Tulisan adalah karya asli penulis atau dapat berupa saduran dari sumber lain dengan menyebutkan sumber aslinya.
  • Dikirimkan ke kahfi24@yahoo.com dalam format file Ms. Word.
  • Program ini hanya berlaku bagi pelanggan TELKOMSEL.

Setiap bulannya akan dipilih 4 orang pemenang dengan masing-masing pemenang mendapatkan 2 buah NSP gratis. Setiap pemenang boleh mendaftarkan 2 nomor HP.

Selain itu, MobileIndonesia.net (MI.net)  juga akan memberikan 2 NSP GRATIS tambahan buat 2 orang pengirim komentar favorit setiap bulannya.

Nama-nama pemenang akan diumumkan di MobileIndonesia.net pada setiap bulannya.

via Mobile Indonesia [dot] net.

Mesin Pencari Saingan Google

Cuil: Mesin Pencari Saingan Google

Cuil merupakan bahasa Irlandia kuno yang berarti pengetahuan. Cuil merupakan mesin pencari yang mengklaim telah merambah halaman Internet tiga kali lebih banyak dari Google dan sepuluh kali lebih banyak dari Microsoft. Cuil menggunakan mekanisme yang berbeda dengan umumnya mesin pencari yang menggunakan semacam matriks popularitas dari sebuah halaman situs seperti Google, melainkan dengan berdasarkan pada konten dan relevansinya terhadap kata kunci yang kita cari.

Perbedaan mendasar dari Cuil sebagai mesin pencari web adalah usulan terhadap hasil pencarian yang menggunakan sistematika kategori. Dengan adanya sistem kategori ini diharapkan pengguna dapat dengan mudah mendapatkan  apa yang sedang dicari.

Apakah Cuil lebih baik dari Google?

Dengar-dengar bahwa Cuil dikembangkan oleh mantan pegawai Google loh.


Categories

Archives

My Bookmarks