LANDASAN TEORI
Teknologi informasi diharapkan untuk membawa perusahaan untuk mempunyai langganan yang berbahagia, memperoleh laba yang tinggi serta mempertinggi pangsa pasar. Bagaimana caranya agar suatu perusahaan dapat membahagiakan langganan, mempertinggi laba, dan meningkatkan pangsa pasar pada saat yang bersamaan?
Salah satu jawabannya ialah dengan khasanah data. Khasanah data, atau proses untuk mengumpulkan data historis organisasi ke dalam suatu tempat penyimpanan terpusat, telah menjadi populer dan teknologi kunci. Pada Business Week terbitan 31 Juli 1995 bagian Information Management, seperti dikutip oleh Gill dan Rao (1996, pp3), ada pernyataan “Khasanah data adalah trend terbesar dalam manajemen informasi dewasa ini. Ini adalah teknologi yang mungkin pada akhirnya akan membuat impian yang selama ini dikejar oleh ahli teori manajemen sejak tahun 1960-an menjadi kenyataan”.
Chief Information Officers melalui survei tahunannya pada tahun 1995, seperti dikutip oleh Gill dan Rao (1996, pp3), mengidentifikasikan 10 issue teratas untuk eksekutif seperti di bawah ini menurut urutan prioritas:
1. Menyelaraskan tujuan SI dan perusahaan
2. Memulai sistem informasi yang cross-functional 3. Mengorganisasi dan membudidayakan data 4. Mengimplementasikan rekayasa ulang bisnis 5. Memperbaiki sumber daya SI
6. Memungkinkan perubahan
7. Berhubungan dengan pelanggan atau vendor 8. Menciptakan arsitektur informasi
9. Meng-update sistem yang sudah usang 10. Memperbaiki proses pengembangan sistem
Sangat menarik jika kita memperhatikan bahwa teknologi khasanah data dengan tepat dapat menjawab tiga issue teratas.
2.1. Apa yang Dimaksud Dengan Khasanah Data?
Menurut Inmon (1996, pp33), yang sering dianggap sebagai bapak khasanah data, “Khasanah data adalah koleksi data yang berorientasi subyek, terintegrasi, berdimensi waktu, dan tidak gampang berubah yang digunakan untuk mendukung proses pembuatan keputusan manajemen”.
Menurut beberapa organisasi, khasanah data adalah suatu arsitektur. Bagi yang lain, khasanah data adalah suatu tempat penyimpanan data yang konsisten secara semantis (terpisah dan tidak mengganggu sistem operasi dan produksi yang ada). Bagi lainnya, khasanah data adalah suatu proses terus menerus yang menampung data dari sumber-sumber yang bervariasi, termasuk data historis dan sindikasi untuk mendukung kebutuhan yang berkelanjutan untuk penampilan data yang terstruktur dan/atau ad hoc, pelaporan analitis, dan pembuatan keputusan.
Walaupun ada beberapa variasi, kebanyakan tempat khasanah data menggunakan karakteristik yang dipopulerkan oleh Bill Inmon, yaitu:
Area subyek merupakan koleksi dari seluruh data di dalam organisasi yang berhubungan dengan satu topik tertentu yang penting pagi pembuat keputusan.
•
Data terintegrasiData harus ditransformasikan ke dalam pengukuran, referensi dan format penyimpanan yang sama agar data tersebut dapat berguna. Contohnya, sebuah perusahaan asuransi mungkin mempunyai informasi mengenai polis yang berbeda dari langganan yang sama yang disimpan dalam beberapa basis data yang menggunakan teknologi yang berbeda secara radikal..
•
Data warehouse merupakan sesuatu yang non-volatile.Informasi yang dimasukkan ke dalam khasanah data, dan kemudian diakses untuk pembuatan keputusan. Ini berlawanan dengan sebuah sistem operasional yang di-update bersamaan dengan terjadinya peristiwa baru.
•
Informasi berorientasikan waktuKhasanah data merupakan suatu sequence dari snapshot informasi organisasi yang diambil pada interval waktu yang telah ditentukan, seperti setiap hari, atau setiap minggu.
2.2. Perbedaan Antara Basis Data Khasanah Data dan Operasional(OLTP) Basis data dan teori basis data telah ada untuk waktu yang cukup lama. Penggunaan basis data mula-mula terfokus pada suatu basis data tunggal untuk melayani semua tujuan dari komunitas pengolahan informasi - mulai dari transaksi, kemudian pengolahan batch sampai pengolahan analitis. Kebanyakan, fokus dari pada sistem basis data mula-mula adalah untuk pengolahan operasional, terutama transaksional.
Pada tahun-tahun belakangan ini, gagasan yang lebih canggih untuk basis data muncul - yaitu satu untuk melayani kebutuhan operasional sedangkan yang lain untuk melayani kebutuhan analitis.
Menurut Inmon (1996, pp vii-viii) pemisahan antara basis data operasional dan analitis terjadi karena berbagai sebab, antara lain:
♦ Data untuk melayani kebutuhan operasional secara fisik berbeda dari data yang digunakan untuk melayani kebutuhan informasi atau analitis.
♦ Teknologi pendukung untuk pengolahan operasional secara fundamental berbeda dengan teknologi yang digunakan untuk mendukung kebutuhan informasional atau analitis.
♦ Komunitas user untuk data operasional adalah berbeda dari komunitas untuk data informasional atau analitis.
♦ Karakteristik pengolahan untuk lingkungan operasional berbeda secara fundamental berbeda dengan lingkungan informasional atau analitis.
Perbedaan antara basis data khasanah data dan operasional (OLTP) menyebabkan pendekatan yang berbeda dalam masing-masing basis data masih menurut Inmon (1996, pp18), dapat diringkaskan sebagai berikut:
Data Operasional Data Khasanah Data
•
detil•
ringkasan, atau telah disaring•
akurat, nilai sampai saat itu•
menyajikan nilai seputar rentang waktu•
melayani komunitas clerical•
melayani komunitas manajerial•
dapat di-update•
tidak dapat di-update•
dijalankan berulang-ulang•
dijalankan pada saat tertentu•
kebutuhan untuk pengolahan diketahuisebelumnya
•
kebutuhan untuk pengolahan tidak sepenuhnya diketahui sebelumnya•
selaras dengan SDLC•
tidak selaras dengan SDLC•
sensitif akan performance/kinerja•
tidak sensitif akan performance/kinerja•
diakses satu unit per waktu•
diakses satu set per waktu•
transaction driven•
analysis driven•
pengontrolan dari update menjadiperhatian utama (kepemilikan data)
•
pengontrolan update tidak menjadi masalah•
ketersediaan harus tinggi•
ketersediaan agak santai•
dikelola secara keseluruhan•
dikelola per subset•
struktur statis; isinya berubah-ubah•
struktur fleksibel•
tidak ada redundansi•
redundansi merupakan suatu yang sering ditemui•
jumlah data yang dipakai dalam proses kecil•
jumlah data yang dipakai dalam proses besar•
melayani operasi harian•
melayani kebutuhan manajerial•
kemungkinan diakses tinggi•
kemungkinan diakses rendah 2.3. Beberapa Manfaat Khasanah DataSejalan dengan mulai diimplementasikannya khasanah data dalam perusahaan, maka para user akan mulai menemukan cara-cara baru untuk menggunakan informasi dari khasanah data dalam rangka mendukung banyak aktivitas, seperti yang dikemukakan oleh Harjinder dan Prakash (1996, pp18-19) di bawah ini:
•
Meningkatkan fokus langgananKhasanah data mengandung informasi historis yang dapat dianalisa per langganan, misalnya. Analisis seperti itu akan menghasilkan preferensi pembelian langganan, waktu pembelian, siklus anggaran, dan selera pengeluaran. Informasi ini bisa dipergunakan oleh departemen Penjualan dan Pemasaran untuk menyesuaikan kampanye penjualan bagi langganan.
•
Memposisikan kembali produk dan mengelola portofolio produkDengan makin lamanya produk berada di pasaran, menjadi makin penting bagi perusahaan untuk menganalisa portofolio produk mereka untuk menentukan produk mana yang harus dilanjutkan, produk mana yang harus ditarik, dan produk mana yang harus diposisikan ulang. Informasi historis yang terkandung didalam khasanah data memungkinkan perusahaan untuk membandingkan kinerja produk per kwartalan, tahunan, dan per geografi, agar dapat menyesuaikan strategi produk mereka.
Dengan menghubungkan khasanah data dengan informasi eksternal, seperti Dow Jones atau jasa layanan langganan (jasa sindikasi), perusahaan dapat menganalisa dampak lingkungan pada rencana pemasaran mereka.
•
Menganalisa operasi dan melihat sumber labaSeringkali, sangat berguna bagi suatu bisnis untuk mengetahui faktor-faktor yang menyumbangkan keuntungan bagi perusahaan. Faktor-faktor ini adalahseperti langganan, produk, jasa, unit usaha, lokasi dan pasar. Perusahaan telah mempunyai data ini selama bertahun-tahun lamanya. Mampu untuk menganalisa tumpukan data ini untuk mengetahui sumber dari keuntungan merupakan manfaat yang sangat berguna dari khasanah data.
•
Mengelola hubungan langgananKhasanah data menyediakan setumpuk data historis untuk mengidentifikasi sumber frustrasi langganan, juga kesempatan untuk hubungan yang lebih dekat. Contohnya, hubungan yang banyak antara beberapa sales perusahaan dengan langganan yang sama dapat membingungkan langganan. Khasanah data mengintegrasikan berbagai sistem aplikasi dan dapat menuntun berbagai saat untuk berhubungan dengan langganan.
•
Mengelola biaya dari aktiva perusahaanKhasanah data mengintegrasikan daftar bahan yang dipergunakan oleh berbagai produk dan jasa yang ditawarkan oleh perusahaan. Menggunakan view yang terintegrasi ini memungkinkan perusahaan untuk mengidentifikasi item-item yang umum digunakan dalam berbagai produk. Ini dapat menjadi dasar untuk mengatur jumlah pembelian dengan harga yang didiskon dari
supplier. Juga dapat menjadi basis untuk mengkonsolidasikan supplier. Melihat sejarah pembelian juga dapat memungkinkan perusahaan untuk mengelola pengeluaran dan persediaannya sesuai dengan pola konsumsi.
2.4. Arsitektur OLAP (On-Line Analytical Processing)
Dewasa ini banyak teori atau sebutan mengenai arsitektur untuk OLAP, beberapa diantaranya seperti ROLAP, HOLAP, MOLAP atau DOLAP, serta banyak lagi yang lainnya. Meskipun mempunyai banyak variasi, namun dalam prinsipnya, seperti yang dikatakan oleh Pendse (1997), hanya ada tiga tempat di mana data dapat disimpan, dan tiga tempat di mana mayoritas dari perhitungan multidimensional dilakukan. Ini berarti, walaupun secara teori ada 9 kemungkinan arsitektur, hanya ada 6 arsitektur yang mungkin dilakukan.
2.4.1. Data Staging
Kebanyakan data di aplikasi OLAP berasal dari sistem yang lain. Namun di beberapa aplikasi (seperti perencanaan dan anggaran) data mungkin dapat diambil secara langsung oleh aplikasi OLAP. Ketika data berasal dari sistem yang lain, biasanya perlu bagi data tersebut untuk disimpan di bentuk yang terpisah dan terduplikasi untuk kebutuhan aplikasi OLAP.
Tempat inilah yang kemudian dinamakan dengan khasanah data, atau yang mungkin sekarang lebih umum disebut dengan data mart. Ada beberapa alasan utama untuk penduplikasian ini:
Aplikasi OLAP seringkali besar, namun digunakan untuk analisis interaktif yang susah diprediksikan. Hal ini menjadikan data harus dapat diakses secara cepat, yang mengakibatkan data harus disimpan di dalam struktur yang terpisah dan teroptimisasi, sehingga dapat diakses tanpa merusak kinerja sistem operasional.
• Banyak sumber data
Kebanyakan aplikasi OLAP memerlukan data dari berbagai sistem. Proses untuk menggabungkan beberapa sumber data ini dapat menjadi sangat kompleks, karena masing-masing sistem mungkin mempunyai sistem pengkodean yang berbeda dan mempunyai periode yang berbeda.
• Pembersihan data
Sangat umum bagi sistem transaksi untuk mempunyai data yang banyak salahnya, sehingga perlu “dibersihkan” sebelum siap untuk dianalisa.
• Penyesuaian data
Banyak alasan yang menyebabkan data harus disesuaikan sebelum dapat digunakan untuk analisis.
Agar hal ini dapat dilakukan tanpa mempengaruhi sistem transaksi, data OLAP harus disimpan secara terpisah.
• Waktu
Jika data dari aplikasi OLAP datang dari berbagai sistem, adalah sangat mungkin jika mereka di-update pada siklus yang berbeda. Agar analisis dapat berdasarkan pada data yang konsisten, maka data harus dipisahkan.
Mayoritas aplikasi OLAP mempunyai dimensi waktu, dan dapat digunakan untuk analisis trend. Namun ini membutuhkan data historis untuk disimpan selama beberapa tahun, yang tentunya tidak mungkin dapat dilakukan oleh sistem operasional.
• Ringkasan
Data operasional biasanya sangat detil, namun kebanyakan aktivitas pembuatan keputusan membutuhkan data pada tingkatan yang lebih tinggi. Untuk efisiensi, biasanya informasi harus disimpan pada tingkat ringkasan/summary, dan ini tentunya tidak mungkin dilakukan di sistem pengolahan transaksi.
• Meng-update data
Jika aplikasi memperbolehkan user untuk mengubah atau memasukkan data, tentunya penting bagi aplikasi untuk memiliki basis data yang terpisah agar tidak menghapus data operasional.
2.4.2. Menyimpan Data OLAP Aktif
Ada tiga alternatif untuk menyimpan data ini, yaitu:
• Basis data relasional
Pilihan ini paling sering dilakukan, terutama jika data bersumber dari RDBMS (Relational Database Management System), misalnya khasanah data menggunakan RDBMS ataupun sistem operasionalnya yang menggunakan RDBMS. Dalam kebanyakan kasus, data akan disimpan dalam struktur yang tidak ternormalisasi seperti star schema, atau snowflake; basis data yang ternormalisasi tidak akan cocok untuk kinerja dan alasan yang lainnya. Seringkali, data ringkasan akan disimpan dalam tabel aggregate.
• Basis data multidimensional
Dalam kasus ini, data aktif disimpan di basis data multidimensional. Biasanya merupakan hal yang lazim, terkadang wajib bagi data untuk dikalkulasi sebelumnya dan hasilnya disimpan dalam bentuk struktur array.
• File client-based
Dalam kasus ini, ekstrak data yang relatif kecil diletakkan di mesin client. Data ini mungkin telah didistribusikan sebelumnya, atau dibuat berdasarkan permintaan (mungkin melalui web). Seperti juga basis data multidimensional, data aktif mungkin disimpan di disk atau RAM, dan beberapa produk hanya membolehkan akses baca (read access).
2.4.3. Pengolahan Data OLAP
Pengolahan data OLAP juga dipisahkan menjadi tiga alternatif, yaitu: • Basis data relasional
Pilihan ini bukan merupakan pilihan yang tepat untuk melakukan kalkulasi multidimensional yang kompleks, sekalipun data disimpan dalam RDBMS. SQL tidak mempunyai kemampuan untuk melakukan kalkulasi multidimensional dalam satu statement tunggal, dan SQL yang kompleks merupakan keharusan untuk melakukan fungsi multidimensional.
• Mesin server multidimensional
Ini merupakan pilihan yang populer untuk melakukan kalkulasi multidimensional di aplikasi OLAP client/server, dan digunakan di banyak produk.
• Client
Dengan asumsi bahwa kebanyakan user mempunyai PC yang cukup kuat, banyak vendor yang mengambil keuntungan dari ini untuk melakukan beberapa perhitungan multidimensional. Dengan makin populernya thin-client, maka arsitektur ini harus ditinggalkan dan berpindah ke server aplikasi web yang baru.
2.4.4. Matriks Arsitektur OLAP
Tiga tempat untuk menyimpan data multidimensional, dan juga tiga lokasi yang sama untuk mesin multidimensional; ini memberikan sembilan kemungkinan untuk pilihan penyimpanan/pengolahan. Tapi beberapa kemungkinan ini tidak masuk akal: misalnya, akan sangat aneh bila menyimpan data di basis data multidimensional, tapi melakukan pengolahan di RDBMS; jadi hanya enam pilihan di bawah ini yang masuk akal.
Tabel 2.1. Matriks Arsitektur OLAP
Alternatif Penyimpanan Data Multidimensional Alternatif
Pengolahan Data
RDBMS Server basis data Multidimensional
File client RDBMS 1
DSS Agent/Server
Server basis data Multidimensional 2 DB2 OLAP Server DecisionSuite Express(ROLAP mode)
Holos (ROLAP mode) 4 CFO Vision Commander Decision Essbase Express Gentia Holos Pilot TM1 File client 3 MetaCube PowerPlay (Server option) 5 Commander FDC Cross Target Hyperion Enterprise 6 BrioQuery PowerPlay BusinessObjects Personal Express TM1 Perspectives
Sebutan yang sering dipakai adalah:
♦ Produk Relational OLAP (ROLAP) adalah produk yang berada di kotak 1, 2 dan 3.
♦ MDB (atau dikenal juga dengan MOLAP) adalah yang berada di kotak 4 dan 5.
♦ Produk Desktop OLAP (DOLAP) adalah yang berada di kotak 6. ♦ Produk Hybrid OLAP (HOLAP) adalah yang berada di kotak 2 dan 4.
2.5. Star Schema
2.5.1. Model Data Hubungan Entiti
Perbedaan yang paling penting antara sistem OLTP dan khasanah data menurut Kimball (1996, pp3) adalah organisasi dari data di dalam sistem, atau dapat dikatakan dengan lebih sederhana, model data. Untuk mengerti mengapa data diorganisasikan dengan begitu berbeda, kita perlu kembali kepada issue dari kinerja transaksi. Banyak keajaiban dari kinerja transaksi bersumber dari teknik yang disebut pemodelan hubungan entity (ERD). Pemodelan hubungan entiti menekankan untuk menghilangkan semua redundansi dari data. Jika tidak ada redundansi dari data, maka transaksi yang mengubah data (atau menambah atau men-delete data) hanya perlu berhubungan dengan basis data di satu tempat saja. Inilah rahasia di balik perubahan phenomenal dalam kecepatan pengolahan data sejak awal tahun 80-an.
2.5.1.1. Karakteristik dari ERD untuk OLTP • Diagram ERD sangat simetris
Semua tabel kelihatan sama. Tidak ada cara untuk mengetahui tabel mana yang terpenting atau terbesar. Tidak ada cara untuk mengetahui tabel mana yang menyimpan ukuran numerik dari bisnis dan tabel mana yang menyimpan keterangan obyek yang statis atau hampir statis.
• Banyak jalan untuk menghubungkan antar dua tabel
Di dalam ERD, kita dapat menghubungkan dua tabel dengan cara atau jalan yang berbeda-beda. Banyak yang mengatakan bahwa tentu saja, karena ini adalah basis data relasional. Tidak perduli jalan mana yang dipilih, setiap jalan
yang berbeda akan menghasilkan jawaban yang sama. Ini adalah salah satu takhyul dari basis data relasional. Sayangnya, jalan yang dipilih ternyata dapat memberikan jawaban yang berbeda-beda. Untuk dapat mengertinya, ingat bahwa di dalam basis data relasional kita perlu membangun “jembatan data” di antara tabel untuk menghubungkan elemen data di antara tabel-tabel yang jauh. Jembatan-jembatan data ini hampir selalu diimplementasikan sebagai inner join yang menjembatani dari satu elemen data ke elemen data yang lain. Jadi secara umum, setiap jalan akan memberikan jawaban yang berbeda.
• End User tidak akan meng-query langsung dari basis data
Untuk query yang melibatkan banyak record atau tabel, ERD terlalu kompleks bagi user untuk dimengerti, dan terlalu kompleks bagi software untuk menavigasinya.
2.5.1.2. Model Dimensional / Star Join Schema
Kios IS, end user, dan bahkan sindikasi supplier data seperti A.C. Nielsen, IRI, IMS dan Walsh America telah merumuskan sebuah struktur “kubus data” sederhana yang cocok dengan kebutuhan end user akan kesederhanaan. Struktur ini disebut model dimensional. Model dimensional ini ditunjukkan dalam gambar di bawah ini:
Gambar 2.1. Model Dimensional
Nama lain untuk model dimensional ini adalah star join schema atau sering disingkat star schema. Ini adalah nama yang telah lama digunakan para perancang basis data untuk menggambarkan model dimensional karena diagram ini kelihatan seperti sebuah bintang, dengan satu tabel pusat yang besar di tengah dan tabel-tabel lebih kecil yang lain yang digambarkan dalam pola menyebar di sekeliling tabel pusat.
Tidak seperti model ERD, model dimensional sangat asimetris. Ada satu tabel besar dominan di tengah skema. Ini adalah merupakan satu-satunya tabel di dalam skema dengan banyak join yang menghubungkannya dengan tabel-tabel lain. Tabel yang di tengah tersebut dinamakan tabel fact, sedangkan tabel yang lain disebut dengan tabel dimensi. Sedangkan level detil dari data yang disimpan, apakah per hari atau per minggu atau per bulan, disebut dengan granularity dari tabel fact tersebut.
• Tabel Fact
Tabel fact adalah tempat di mana ukuran numerik dari bisnis disimpan. Setiap ukuran ini diambil dari persimpangan antara semua dimensi. Fact yang paling berguna adalah fact yang berupa numerik, terus menerus dinilai, dan dapat ditambahkan (additive). Alasannnya adalah dalam hampir dari semua query yang akan masuk ke dalam tabel fact, kita akan meminta ratusan, ribuan, dan bahkan jutaan records yang akan digunakan oleh DBMS untuk membuat set jawaban. Jumlah records yang banyak ini akan dikompres ke dalam beberapa row untuk jawaban user. Satu-satunya cara untuk mengkompres records ini ke dalam set jawaban adalah dengan menambahkan mereka. Jadi jika ukuran adalah numerik dan mereka dapat ditambahkan (additive), maka kita akan dengan mudah dapat membuat set jawaban.
• Tabel Dimensi
Tabel dimensi adalah tempat di mana keterangan tekstual dari dimensi bisnis di simpan. Masing-masing keterangan tekstual membantu untuk menerangkan anggota dari masing-masing dimensi yang bersangkutan. Contohnya, setiap record di dimensi produk merepresentasikan satu produk spesifik. Dalam suatu basis data yang terdesain dengan baik, suatu tabel dimensi produk akan mempunyai banyak atribut (field). Atribut yang terbaik adalah atribut yang tekstual, diskrit dan digunakan sebagai pemfilter dan judul row dalam set jawaban user. Karena atribut dimensi memainkan peran untuk menerangkan salah satu item dari dimensi, maka atribut ini paling berguna jika mereka adalah teks.
Granularity penting karena menentukan dimensionalitas dari basis data, dan tentunya juga mempunyai efek terhadap besarnya basis data.
2.5.2. Langkah-Langkah Dalam Proses Desain
1. Langkah pertama dalam mendesain adalah menentukan proses bisnis yang akan dibuat modelnya, dengan menggabungkan pengertian dari bisnis dengan pengertian data apa yang tersedia.
2. Langkah kedua dalam mendesain adalah menentukan granularity dari tabel fact di setiap proses bisnis.
3. Langkah ketiga adalah menentukan dimensi-dimensi apa saja yang akan masuk dalam model.
4. Langkah keempat adalah memilih secara hati-hati fact-fact apa yang akan tampil di dalam tabel fact.
2.5.3. Pertimbangan Dalam Perancangan/Desain
2.5.3.1. Snowflake
Dimensi dengan hirarki sering didekomposisikan oleh perancang basis data yang bermaksud baik ke dalam struktur snowflake. Masing-masing dari hubungan many-to-one dijadikan tabel terpisah. Contoh dari snowflake dapat dilihat dari gambar di bawah ini:
Gambar 2.2.Model Snowflake
Ahli komputer akan berpikir bahwa diagram ini kelihatan menarik. Sayangnya, kebanyakan user akan terintimidasi oleh diagram ini. Jika kita mengesampingkan semua keberatan teknis, efek dari end user kita cukup untuk merekomendasikan kita agar tidak menggunakan snowflake untuk merepresentasikan hirarki.
Alasan umum untuk menggunakan struktur snowflake adalah untuk menghemat tempat penyimpanan. Dalam suatu tabel produk besar tipikal berukuran 100MB, maka memungkinkan untuk membayangkan menghemat beberapa MB dengan tidak meng-copy field teks yang paling sering berulang ribuan kali.
Namun, dalam kalkulasi disk space dari khasanah data kita cenderung akan melihat seperti di bawah ini:
Tabel 2.2.Perhitungan Manfaat Snowflake
Ukuran data tabel fact 30 GB
Ukuran index tabel fact 20 GB
Ukuran tabel dimensi terbesar (produk) 0.1 GB
Penghematan karena snowflake 0.005 GB (mungkin) Total ukuran basis data tanpa snowflake (dibulatkan) 50 GB
Total ukuran basis data dengan snowflake (dibulatkan) 50 GB
Dengan kata lain, snowflake tidaklah relevan dalam issue dari perencanaan kapasitas disk dari khasanah data.
2.5.3.2. Dimensi Yang Berubah Secara Perlahan (Slowly Changing
Dimensions)
Seringkali, dimensi seperti produk dan langganan dianggap independen dari waktu. Hal ini tidak benar di dalam dunia nyata. Perlahan-lahan keterangan dan formulasi dari produk akan berubah. Terutama langganan juga berubah secara pasti. Orang mengubah nama mereka, menikah dan bercerai, mempunyai lebih banyak anak, dan mengubah alamat mereka.
Ketika kita menemukan suatu dimensi yang berubah secara perlahan, ada tiga pilihan yang dapat diambil. Masing-masing pilihan akan menghasilkan derajat pelacakan perubahan yang berbeda seiring berjalannya waktu:
• Menimpa nilai yang lama di record dimensi dan dengan begitu akan kehilangan kemampuan melacak sejarah yang lama.
• Membuat record dimensi tambahan pada waktu perubahan dengan nilai atribut baru, dan dengan demikian mensegmentasikan sejarah secara sangat akurat antara keterangan lama dan keterangan baru.
• Membuat field-field “berjalan” baru di dalam record dimensi asli untuk menyimpan nilai atribut baru, sementara menyimpan nilai atribut asli juga, dengan demikian akan mampu untuk menerangkan sejarah ke depan dan kebelakang dari perubahan baik dari sisi nilai atribut asli atau dari sisi nilai atribut berjalan.
2.6. Metodologi Perancangan Khasanah Data
Perancangan khasanah data ini akan dilaksanakan dengan menggunakan metodologi yang telah disarikan dari Wells (1996, pp1-30) di bawah ini:
2.6.1. Perencanaan (Planning)
2.6.1.1. Pemilihan Strategi Implementasi Tersedia beberapa strategi implementasi yaitu:
•
Pendekatan top downDalam pendekatan ini, kebutuhan bisnis yang akan dipenuhi oleh khasanah data yang diusulkan diidentifikasi terlebih dahulu. Ini merupakan pendorong utama untuk implementasi khasanah data. Seringkali, ini merupakan tugas yang sulit karena khasanah data lebih sering merupakan kemampuan daripada feature (khasanah data menyimpan informasi dan mengorganisasi informasi ini untuk selanjutnya dapat ditampilkan oleh tools eksternal).
Oleh karena itu, end user tidak dapat mengeksploitasi kemampuan yang ada di dalam khasanah data tanpa tools eksternal yang memanfaatkan kemampuan ini. Karenanya, adalah sulit untuk memformulasikan scope dari kemampuan, kecuali dalam terminologi bisnis yang luas, seperti “Khasanah data akan memuat informasi mengenai langganan, supplier, pasar dan produk”. Formulasi scope (yang kemudian menjadi formulasi kebutuhan) dispesifikasikan sebagai batasan data yang mendefinisikan teritori khasanah data.
Tabel di bawah ini menunjukkan pro dan kontra dalam penggunaan pendekatan top down dalam implementasi khasanah data:
Tabel 2.3.Pro dan Kontra Pendekatan Top Down
Pro Kontra
Kebutuhan bisnis secara jelas menetapkan batasan dari implementasi khasanah data dan oleh karena itu dapat menjadi cara yang cost effective dan berfokus dalam mengimplementasikan solusi khasanah data.
Kesempatan terkadang berada di luar horison bisnis yang sedang berjalan. Kesempatan yang hilang bisa berasal dari fokus yang terlalu banyak.
Teknologi dikendalikan oleh bisnis dan bukan sebaliknya.
Teknologi dapat menyediakan dorongan kepada bisnis dan keuntungan kompetitif yang mulanya tidak terlalu jelas bagi bisnis. Mudah untuk mengkomunikasikan
keuntungan dari khasanah data kepada pembuat keputusan dan investor.
Ekspektasi awal mungkin akan membatasi pencarian potensial payoff yang lebih tinggi.
Pendekatan top down berguna dalam kasus di mana teknologi sudah matang dan dimengerti dengan baik, dan di mana masalah bisnis yang akan dipecahkan jelas dan dimengerti dengan baik. Menerapkan pendekatan top down memberikan pelengkap yang
bagus bagi teknologi dan sasaran bisnis, dan jika dilakukan secara baik, memberikan efek maksimum atas investasi yang dilakukan.
•
Pendekatan bottom upPendekatan bottom up biasanya dimulai dengan eksperimen dan prototipe yang berbasis teknologi. Suatu subset dari masalah bisnis yang spesifik dan dimengerti dengan baik dipilih, dan suatu solusi diformulasikan untuk subset ini. Mengimplementasikan solusi bottom up biasanya lebih cepat karena melibatkan lebih sedikit orang yang membuat lebih sedikit keputusan untuk memecahkan masalah bisnis yang lebih kecil.
Tabel 2.4.Pro dan Kontra Pendekatan Bottom Up
Pro Kontra
Kebutuhan untuk implementasi dan mulai terkadang melebihi analisis top down dan pertimbangan jangka panjang.
Setelah implementasi awal, adalah baik untuk melangkah ke belakang dan melihat bagaimana solusi dapat dieskalasi untuk melayani seluruh perusahaan.
Dalam organisasi yang teknologinya masih baru, pendekatan ini memungkinkan organisasi untuk mengevaluasi keuntungan teknologi tanpa komitmen besar.
Kegagalan dari suatu proyek bottom up dapat menunda implementasi dari teknologi yang secara potensial menguntungkan.
Keterlibatan dari lebih sedikit orang yang bekerja dalam scope yang lebih sempit dapat mempercepat implementasi dan pengambilan keputusan.
Tim awal harus melangkah ke belakang dan mengembangkan tim yang lebih besar untuk memperluas scope dari implementasi awal.
Dalam area khasanah data, pendekatan bottom up digunakan untuk mengimplementasikan data mart, suatu EIS yang kecil, atau khasanah data departemen
yang secara jelas diarahkan untuk menjawab query-query tertentu. Tabel di bawah ini memperlihatkan pro dan kontra menggunakan pendekatan bottom up dalam mengimplementasikan khasanah data.
Pendekatan bottom up berguna untuk membuat penilaian teknologi dan merupakan teknik yang bagus untuk organisasi yang bukan merupakan implementor teknologi tingkat tinggi. Pendekatan ini juga merupakan cara yang baik bagi perusahan yang teknologinya belum terlalu matang untuk mengambil keuntungan dari teknologi tanpa menempatkan dirinya pada resiko yang besar.
•
Kombinasi dari top down dan bottom upPada kombinasi dari pendekatan top down/bottom up, organisasi dapat mengeksploitasi natur yang terencana dan strategis dari pendekatan top down sementara mempertahankan implementasi yang cepat dari pendekatan bottom up. Pendekatan ini bergantung pada dua komponen:
♦ Tim arsitektur top down, standard, dan desain yang akan membawa know-how dari proyek ke proyek dan dapat melangkah mundur serta mengubah keputusan taktis menjadi strategis.
♦ Tim proyek bottom up yang diarahkan untuk mengimplementasi solusi bisnis yang sangat fokus, sempit tetapi menjangkau jauh ke depan dalam waktu yang pendek.
Kombinasi dari pendekatan top down/botom up paling cocok untuk pengimplementasian cepat dari teknologi khasanah data sementara mempertahankan potensi untuk membangun solusi strategis yang mempunyai nilai jangka panjang.
2.6.1.2. Pemilihan Metodologi Pengembangan
Tersedia dua teknik populer dalam metodologi pengembangan, yaitu:
•
Metode Analisis dan Desain Terstruktur (Waterfall)Dalam metode ini, satu set kebutuhan mula-mula dikumpulkan. Kebutuhan ini kemudian dianalisa dan secara progresif dipisahkan. Desain kemudian dibangun, menggunakan hasil dari analisis. Desan dimulai dari level abstrak dan kemudian dipisahkan ke level yang lebih konkrit sampai pemrograman muncul.
•
Metode Pengembangan SpiralDalam metode ini, penekanan adalah pada kecepatan dan delivery dengan pengenalan bahwa kebutuhan tidak dapat diidentifikasikan atau dispesifikasikan mula-mula. Pendekatan ini berdasarkan pada observasi bahwa adalah lebih mudah mengarahkan ulang sistem yang berdasarkan kebutuhan baru daripada membangun solusi yang lengkap berdasarkan kebutuhan yang tidak memadai atau tidak tersedia.
Dalam domain pengembangan produk, metode pengembangan spiral digunakan bila situasi di bawah ini muncul:
♦ Arah dari pasar dan kebutuhannya tidak dapat diprediksikan dengan jelas di depan.
♦ Waktu untuk memasarkan merupakan bahan penting dari implementasi produk.
♦ Pengembangan iteratif penting untuk perbaikan pasar.
♦ Keuntungan kompetitif datang dari perubahan yang cepat yang dilakukan secara berkelanjutan.
♦ Organisasi membutuhkan setidaknya enam bulan untuk mengadopsi release software berikutnya.
Pengembangan khasanah data mempunyai seluruh karakteristik tersebut, oleh karena itu, metode pengembangan spiral merupakan pilihan yang tepat bagi metodologi pengembangan untuk khasanah data.
2.6.2. Kebutuhan
2.6.2.1. Pendefinisian Kebutuhan Pemilik
Pendefinisian kebutuhan pemilik akan meliputi: ♦ Penetapan subyek area
♦ Penetapan level detil (granularity) ♦ Penetapan dimensi (dimensions) 2.6.2.2. Pendefinisian Kebutuhan Arsitek
Pendefinisian kebutuhan arsitek meliputi: ♦ Arsitektur data
♦ Arsitektur aplikasi ♦ Arsitektur teknologi
2.6.2.3. Pendefinisian Kebutuhan End-user Pendefinisian kebutuhan end-user meliputi: ♦ Alur kerja (workflow)
♦ Kebutuhan query ♦ Kebutuhan pelaporan
2.6.3. Analisis
Fase analisis dari daur hidup pengembangan khasanah data meliputi penerjemahan dari kebutuhan yang telah diperoleh menjadi satu set spesifikasi yang dapat menunjang desain. Secara abstrak, ada tiga masukan spesifikasi utama untuk khasanah data, yaitu: kebutuhan fokus bisnis, spesifikasi kebutuhan sumber data, dan spesikasi kebutuhan pemakaian.
Proses dari analisis selanjutnya adalah:
♦ Menurunkan model data logical dan physical untuk khasanah data
♦ Mendefinisikan proses yang dibutuhkan untuk menghubungkan sumber data, khasanah data, dan tools akses dari end-user secara bersama-sama.
2.6.4. Desain
Pada fase desain, model logical yang telah dikembangkan pada fase analisis akan diterjemahkan menjadi model physical. Proses yang diidentifikasikan dalam fase analisis untuk menghubungkan sumber data ke khasanah data, dan data warehouse ke tools di workstation end-user akan diterjemahkan menjadi desain untuk program yang akan mengerjakan tugas yang dibutuhkan oleh proses-proses tersebut.
Fase desain akan meliputi:
