MODUL DATA WAREHOUSE

(CSD310)

MODUL 3
SIKLUS HIDUP PEMBANGUNAN DATA WAREHOUSE

DISUSUN OLEH
Ir. Munawar, MMSI., M.Com., PhD

UNIVERSITAS ESA UNGGUL

2020

Universitas Esa Unggul

http://esaunggul.ac.id 0 / 23
 SIKLUS HIDUP DATAWAREHOUSE

A. Kemampuan Akhir Yang Diharapkan

Setelah mempelajari modul ini, diharapkan mahasiswa mampu :

1. Memahami berbagai siklus hidup pembangunan data warehouse
2. Merinci tahapan pembangunan data warehouse

B. Uraian Perkuliahan
1. Siklus Data Warehouse
1.1. Pendahuluan
Pembangunan DW adalah proses yang sangat kompleks yang membutuhkan
metodologi khusus agar bisa sukses diimplementasikan. Banyaknya vendor
penyedia framework untuk pembangunan DW telah memberikan persoalan baru
kepada organisasi yang berniat untuk membangun DW, karena tidak adanya
standard baku yang bisa dijadikan pedoman. Masing-masing vendor menyediakan
platform dan teknologi yang satu dengan yang lain tidak kompetibel. Butuh ekstra
tenaga dan waktu untuk melakukan seleksi platform dan framework mana yang
paling sesuai dengan kondisi organisasi.
Meskipun banyak artikel tentang pembangunan DW telah ditulis, namun
hingga saat ini belum ada standar baku yang disetujui bersama tentang siklus hidup
pembangunan DW. Secara umum metode pembangunan DW yang paling sering
digunakan adalah sebagai berikut (Rizzi, 2009):
(1) analisis kebutuhan (requirements analysis), yang menentukan informasi yang
saling terkait dengan proses pengambilan keputusan dengan
mempertimbangkan persyaratan pengguna atau data riil yang ada di sumber
data operasional;
(2) desain konseptual (conceptual analysis), yang dimaksudkan untuk memperoleh
skema konseptual implementasi yang independen dan ekspresif (tidak
tergantung ke suatu vendor tertentu) untuk data mart (DM) atau DW;
(3) desain logik (logical design), yang memperoleh skema konseptual dan
menghasilkan skema logik yang sesuai melalui model logik yang dipilih; dan
(4) desain fisik (physical design), yang menunjukkan semua persoalan yang terkait
dengan implementasi seperti arsitektur DW.

Universitas Esa Unggul

http://esaunggul.ac.id 1 / 23
 REQUIREMENTS
ANALYSIS
requirements
CONCEPTUAL
DESIGN
conceptual
LOGICAL
schema
DESIGN
logical
PHYSICAL schema
DESIGN
physical
schema

Gambar 3.1. Fase – Fase Utama Pembangunan Data Warehouse (sumber : Rizzi,
2009)
1.2. Analisis Kebutuhan (Requirements Analysis)
Analisis kebutuhan memegang peran penting di proyek DW, dalam hal
minimalisasi tingkat kegagalan. Analisis kebutuhan adalah dasar dari semua
kegiatan proyek sistem dan mempengaruhi sebagian besar siklus hidup dari system
(Kimball et al, 2008). Meskipun penting, ternyata perusahaan atau organisasi kurang
memberikan perhatian pada analisis kebutuhan dan sering mengabaikan aspek ini
dalam proyek DW (Rizzi et al, 2006). Hal ini terutama karena (1) proyek DW adalah
proses jangka panjang, di mana sebagian besar persyaratan tidak dapat diidentifikasi
pada awal proyek, dan (2) sangat sulit untuk mendapatkan kebutuhan di seluruh
bagian organisasi/ perusahaan, disamping juga karena factor bahwa yang namanya
kebutuhan relative tidak stabil dari waktu ke waktu karena terkait dengan informasi
yang harus diperoleh dari sumber data (Winter dan Strauch, 2003). Rata-rata,
analisis kebutuhan gagal diidentifikasi dalam pengembangan DW, sehingga dapat
menghambat keberhasilan proyek DW (Schiefer et al, 2002).
Analisis kebutuhan untuk DW berbeda dengan analisis kebutuhan untuk sistem
informasi. Identifikasi informasi yang relevan untuk pengambilan keputusan adalah
fokus utama dari analisis kebutuhan untuk pembangunan DW. Pendekatan dan
instrumen yang digunakan untuk analisis kebutuhan meliputi (a) wawancara, (b)
lokakarya, (c) pembuatan prototipe, (d) pembuatan skenario dan (e) analisis area
subjek (Paim dan Castro, 2003; Sen dan Sinha, 2007). Wawancara adalah teknik
dasar untuk mendapatkan kebutuhan pengguna berdasarkan wawancara satu per

Universitas Esa Unggul

http://esaunggul.ac.id 2 / 23
satu (Sen dan Sinha, 2007). Workshop bisa digunakan untuk mengeksplorasi subjek
tertentu secara lebih rinci (wikipedia.com). Area subjek adalah cara umum untuk
menggambarkan informasi yang berkaitan dengan konsep spesifik yang penting
tentang organisasi (Sen dan Sinha, 2007). Prototipe adalah model awal untuk
menguji konsep atau proses (wikipedia.com). Biasanya prototype ini digabungkan
dengan skenario untuk lebih memperjelas konsep (Go and Carroll, 2004). Dalam
penyusunan skenario ini, keterlibatan pengguna sangat diperlukan guna
mendapatkan kesepahaman tentang kegiatan bersama. Analisis tugas berbasis
skenario berfungsi sebagai alat yang berguna untuk membangun hipotetis dalam
membuat konsep kegiatan terkait pembangunan DW.
Hingga saat ini, untuk mendefinisikan kebutuhan dalam pembangunan DW bisa
dikategorikan menjadi beberapa pendekatan, dimana masing-masing pendekatan ini
biasanya digunakan secara terpisah:
1. Pendekatan berbasis data (data-driven) (juga disebut supply-driven) (Oliveira
et al, 2012; Niedrite et al, 2009; Artz, 2005; List et al, 2002) adalah teknik
bottom-up berdasarkan eksplorasi sumber data yang dirancang untuk
mengidentifikasikan semua data yang ada. Secara khusus, pendekatan ini
digunakan untuk membangun DW hanya berdasarkan pada data yang benar-
benar ada dalam sistem operasional dan mengabaikan tujuan bisnis dan
kebutuhan pengguna. Kebutuhan organisasi tidak teridentifikasi atau hanya
diidentifikasi sebagian.
2. Pendekatan berbasis proses (process-driven) yang mengidentifikasi proses
bisnis yang paling penting yang memerlukan pengukuran dan kontrol (Oliveira
et al, 2012; Niedrite et al, 2009; Rizzi, 2009; Lujan-Mora, 2002) dan kemudian
menyelaraskan proses ini dengan strategi organisasi. DW dirancang
berdasarkan beberapa proses bisnis yang saling terkait (Lujan-Mora, 2002)
dimana masing-masing proses menjelaskan proses bisnis yang spesifik.
3. Pendekatan berbasis tujuan (goal-driven) biasanya merupakan metode top-
down yang menekankan keselarasan pengembangan DW dengan strategi
perusahaan dan tujuan bisnis (Oliveira et al, 2012; Frendi dan Salinesi, 2003).
Visi yang berbeda-beda dari beberapa manajemen puncak yang diperoleh
dengan wawancara ditafsirkan dan digabungkan untuk memperoleh pandangan
yang konsisten. Hasil yang diperoleh pada selanjutnya diterjemahkan ke dalam
indikator kinerja (KPI) yang dapat diukur (Niedrite et al, 2009)

Universitas Esa Unggul

http://esaunggul.ac.id 3 / 23
 4. Pendekatan berbasis pengguna (user-driven) adalah teknik bottom-up yang
menekankan keterlibatan pengguna akhir dalam pengembangan DW (Oliveira
et al, 2012; List et al, 2002; Kaldeich dan Oliveira, 2004) untuk menentukan
informasi bisnis yang diperlukan dari sudut pandang pengguna yang berbeda-
beda. Pendapat para pengguna ini kemudian digabungkan untuk mendapatkan
seperangkat skema multidimensional yang spesifik.
5. Pendekatan karena factor dorongan dari eksternal (externally-driven) seperti
untuk mematuhi peraturan pemerintah (contoh DW bagi perbankan karena
adanya peraturan dari bank sentral – BI, DW bagi organisasi yang sudah
melantai di bursa saham dan lain-lain) (Frolick dan Ariyachandra, 2006).
Pendekatan ini biasanya dilaksanakan dengan cara top-down dan berfungsi
sebagai pendorong utama pertumbuhan inisiatif DW.
Kelebihan dan kekurangan masing-masing pendekatan ini bisa disarikan pada Table
3.1

Table 3.1. Kelebihan dan Kekurangan Teknik Analisis Kebutuhan Data Warehouse
Analisis
Kelebihan Kekurangan
Kebutuhan
User-driven  Keterlibatan pengguna • Ketidakfahaman pengguna tentang
akhir sangat menentukan DW, strategi bisnis maupun proses
kesuksesan penggunaan yang ada di organisasi akan
DW (Niedrite et al, 2009). berakibat ketidaksesuaian pada
skema yang dihasilkan sangat tinggi
(Niedrite et al, 2009).
• Butuh waktu lama untuk bisa
mendapatkan konsensu bersama
apa yang benar-benar dibutuhkan
karena banyaknya pengguna
dengan sudaut pandang masing-
masing yang bisa jadi berbeda-
beda. (Niedrite et al, 2009; Lujan-
Mora, 2002).
Data-driven  Cara paling cepat untuk  Beberapa model mungkin tidak
mendapatkan model merefleksikan fakta yang

Universitas Esa Unggul

http://esaunggul.ac.id 4 / 23
 untuk DW (Niedrite et al, dibutuhkan untuk tujuan bisnis
2009) (Niedrite et al, 2009).
 Sederhana (Winter and  Keterlibatan pengguna terbatas
Strauch, 2003) (Winter and Strauch, 2003).
 Sangat stabil (Winter and  Skema multidimensi tidak bisa
Strauch, 2003) diperoleh jika data sumber nya tidak
ada meski dibutuhkan oleh
pengguna (Winter and Strauch,
2003).
Goal-driven  Identifikasi indikator yang  Dapat diandalkan untuk mendorong
relefan dengan partisipasi manajemen puncak
pembangunan DW bisa dalam proses analisis kebutuhan
diperoleh (Niedrite et al, (Lujan-Mora, 2002)
2009; Lujan-Mora, 2002).  Memerlukan karyawan yang sangat
terampil dalam menerjemahkan
persyaratan tingkat tinggi ke dalam
KPI yang dapat diukur (Niedrite et
al, 2009; Lujan-Mora, 2002).
 Prediksi kebutuhan semua
manajemen senior sulit dicapai
(Niedrite et al, 2009).
Process-driven  Semua proses bisnis  Model yang didapat lebih
yang penting dan merefleksikan proses bisnis, bukan
indikator pengukurannya proses pengambilan keputusan
bisa diidentifikasi (Niedrite et al, 2009).
(Niedrite et al, 2009;
Lujan-Mora, 2002).
 Kebutuhan bisnis mudah
diadaptasikan dengan
lingkungan bisnis (Guo et
al, 2006).
Externally-  Memenuhi tuntutan  Kadangkala butuh data eksternal
driven undang-undang terkait untuk bisa memenuhi informasi
dengan operasional yang dibutuhkan oleh UU

Universitas Esa Unggul

http://esaunggul.ac.id 5 / 23
 bisnis (Frolick and
Ariyachandra, 2006).

Perlu sejumlah pendekatan yang terintegrasi guna mendapatkan model data

yang benar-benar mencerminkan kebutuhan suatu organisasi (Niedrite et al, 2009).
Semua pendekatan yang dibahas di atas sifatnya saling melengkapi dan harus
digunakan secara paralel untuk mewujudkan desain yang optimal (Oliveira et al,
2012; Guo et al, 2006; List et al, 2002).
Pada satu kasus bisa jadi membutuhkan gabungan antara pendekatan
berorientasi tujuan (goal-driven) dan pendekatan berbasis data (data-driven). Metode
goal-driven awalnya digunakan untuk mennetukan kebutuhan bisnis dengan
menggunakan pertanyaan untuk menjawab metrik tentang tujuan organisasi
(Vassiliadis, 2000) agar bisa dimasukkan ke dalam data. Hasilnya adalah skema
bintang yang diturunkan dari KPI guna mengevaluasi tujuan organisasi. Selanjutnya
skema data yang berasal dari data operasional diuji dengan teknik semi-otomatis
(misal menggunakan star join graph) untuk mendapatkan kandidat fact, dimensi dan
hirarki. Hasil dari kedua proses ini kemudian digabungkan untuk mendapatkan model
multidimensional dari data mart yang paling sesuai dengan skema bintang.
Guo et al (2006) juga mengusulkan metode campuran yang menggabungkan
tiga pendekatan dasar: goal-driven, data-driven dan user-driven. Pendekatan
berbasis tujuan (goal-driven) digunakan untuk menentukan area subjek dan
merumuskan definisi KPI utama serta target pengguna. Pada metode berbasis data
(data-driven), fokus utamanya adalah pemilihan sistem sumber untuk eksploitasi
informasi. Sementara dengan pendekatan berbasis pengguna (user-driven), fokus
utamanya lebih ke pemilihan pengguna yang akan diwawancarai. Hasil dari goal-
driven dapat disempurnakan dengan menggunakan dua metode lainnya, sehingga
memungkinkan perolehan skema multidimensi yang lebih komprehensif.
Oliveira et al (2012) mengintegrasikan goal-driven, data-driven, process-driven,
user-driven dan technological-driven dalam merancang DW. Pendekatan baru:
berbasis teknologi sangat penting karena kemampuannya dapat mengatasi
persoalan yang dihadapi DW terkait dengan teknologi. Hanya sayang, technological-
driven yang dimaksud ternyata hanya spesifik untuk teknologi tertentu yang
digunakan oleh suatu organisasi. Bukan teknologi yang bebas platform yang tidak
terikat pada suatu vendor tertentu.

Universitas Esa Unggul

http://esaunggul.ac.id 6 / 23
1.3. Disain Konseptual (Conceptual Design)
Desain konseptual mengakomodasi abstraksi tingkat tinggi dalam
merepresentasikan proses dan arsitektur DW di semua aspek yang terlibat. Disain
konseptual memungkinkan penuangan ide tentang cara-cara pengguna dalam
mempersepsikan domain aplikasi (Saxena dan Agarval, 2014) melalui skema
multidimensional. Skema ini mendefinisikan fakta (fact) dan properties dengan
membedakan antara dimensi dan kategori ke dalam hirarki.
Desain konseptual adalah fondasi penting untuk pembangunan DW karena
mendokumentasikan semua kebutuhan pengguna. Hanya sayang, hingga saat ini
belum ada satupun standar yang bisa diterima oleh semua pihak terkait dengan
disain konseptual, meski sudah ada beberapa model yang telah diusulkan oleh para
peneliti. Biasanya vendor mengembangkan dan mengusulkan metode desain
konseptual eksklusif milik mereka sendiri (Rizzi et al, 2006).
Saat ini, pendekatan yang ada untuk pemodelan multidimensional dapat
dibingkai menjadi berbasis entitas (E/R), berorientasi objek atau model ad hoc (Sen
dan Sinha, 2005). Beberapa peneliti dan praktisi berpendapat bahwa ekstensi E / R
harus digunakan karena alasan berikut:
(1) E / R telah teruji untuk waktu yang cukup lama (bertahun-tahun);
(2) E / R adalah alat yang biasa digunakan oleh banyak desainer;
(3) berbagai domain aplikasi dapat secara fleksibel diadaptasikan ke E / R;
(4) hasil penelitian substansial yang ada telah menggunaka E / R (Sapia et al,
1999; Tryfona et al, 1998).

Namun pendukung model berorientasi objek mengemukakan argumen berikut:

(1) sifat statis dan dinamis sistem informasi dapat lebih terwakili dengan model-
model ini;
(2) kebutuhan dan kendala dapat dinyatakan dalam mekanisme yang baik;
(3) pemodelan data saat ini didominasi oleh pendekatan berorientasi objek;
(4) UML saat ini sudah menjadi standard baku yang diakui banyak pihak (Lujan-
Mora, 2002).
Sebaliknya model ad hoc melengkapi perspektif desainer dalam hal aspek-aspek
berikut:
(1) notasinya lebih efektif;

Universitas Esa Unggul

http://esaunggul.ac.id 7 / 23
 (2) pemodelan multidimensional bisa diekspresikan secara lebih baik dengan model
ad hoc
(3) paling mudah dibaca oleh pengguna awam (Rizzi, 2009).

Multidimensional Entity Relationship (ME/R) berkaitan dengan model

konseptual berdasarkan E / R (Sapia et al, 1998) sebagai solusi atas ketidakcocokan
ER terkait dengan konsep multidimensional dan sifat agregasi dari aplikasi OLAP
(Torlone, 2008).
Dalam model berorientasi objek, kelas dimensi dan kelas fakta dapat digunakan
untuk mewakili dimensi dan fakta (Lujan-Mora et al, 2002). Kelas fakta dianggap
sebagai kelas komposit dalam hubungan agregasi bersama dari kelas n-dimensi.
Dimensional Fact Model (DFM) dibangun dari skema ER operasional
berdasarkan analisis kebutuhan. DFM adalah kumpulan skema fakta terstruktur
pohon yang unsur-unsurnya adalah fakta, atribut, dimensi, dan hierarki (Golfarelli,
2010). Skema fakta disusun sebagai pohon yang akarnya adalah fakta. Meski
berdayaguna, DFM tidak mendukung hierarki generalisasi / spesialisasi dan
hubungan banyak ke banyak (Kamble, 2008).
Model fakta (fact schema) terutama menggunakan konsep entitas-hubungan
sebagai dasar untuk solusi yang diusulkan (Husemann et al, 2000). Model ini
menggunakan hubungan struktural antara entitas fakta dan entitas tetangganya
untuk menemukan dimensi.
Dalam model multidimensi, fakta dan dimensi adalah representasi data, di
mana setiap fakta terkait dengan beberapa dimensi. Fakta mencerminkan transaksi
data penting di suatu organisasi yang dapat digunakan untuk keperluan analisis.
Dimensi mewakili perspektif bisnis dalam kaitannya dengan analisis fakta, seperti
penjualan berdasarkan geografi (Cabibbo dan Torlone 2000). Dimensi dapat
didefinisikan ke dalam hierarki. Tingkat hierarkis, seperti hari, minggu, bulan dan
tahun, dapat dimasukkan ke dalam dimensi. Untuk analisis, fakta harus
dikarakteristikkan dengan langkah-langkah (misal produk terjual dan harga) dalam
bentuk atribut numerik yang dapat diringkas (diagregasikan). Perbandingan
penggunaan disain konseptual ini bisa dilihat pada Gambar 3.2.

Universitas Esa Unggul

http://esaunggul.ac.id 8 / 23
Gambar 3.2. Pemodela fakta penjualan menggunakan M E/R (Sapia et al, 1999),
UML class diagram (Lujan-Mora et al, 2002), fact schema (Husemann et al, 2000)
and a dimensional fact model (DFM) (Golfarelli, 2010)

1.4. Disain Logik (Logical Design)

Desain logik adalah tahapan berikutnya dalam pembangunan DW setelah
disain konseptual. Disain logik berhubungan erat dengan kinerja sistem, karena
terkait dengan struktur data yang akan diterapkan oleh DM atau DW khususnya
dalam hal query pencarian dan ruang penyimpanan (Trujilo et al, 2000). Desain logik
sangat relevan di lingkungan relasional OLAP (ROLAP), karena sangat mudah
diturunkan dari lingkungan multidimensional OLAP (MOLAP).
Data OLAP disimpan dalam format ROLAP, MOLAP dan hybrid OLAP (HOLAP)
(Arun Sen, 2007). Dalam ROLAP, data DW disimpan dalam format relasional dan
ditampilkan secara virtual kepada pengguna dalam bentuk multidimensi sementara
mesin OLAP tetap berada di situs klien. Dalam MOLAP, data dan presentasi disusun
dalam format multidimensional melalui penggunaan basis data multidimensi

Universitas Esa Unggul

http://esaunggul.ac.id 9 / 23
sementara mesin OLAP tetap berada di server khusus. Dalam HOLAP, database
relasional digunakan untuk menyimpan data dalam format non-agregat, sedangkan
di MOLAP, database digunakan untuk menyimpan data dalam format ringkasan dan
agregasi. Format mana pun dapat digunakan untuk merujuk yang lain, dengan
struktur yang memiliki indeks untuk catatan relasional.
Pilihan ROLAP atau MOLAP tergantung pada kompleksitas query dan kinerja.
MOLAP bisa digunakan pada kondisi basis data multidimensional mengingat
kemampuan OLAP dalam melakukan query yang kompleks dan respons yang
sangat baik. ROLAP dapat digunakan dalam tabel relasional ketika kompleksitas
query nya rendah dan respons nya minimal dengan pertimbangan multidimensional
bisa dihasilkan dengan cepat (on the fly).
Dalam pemodelan multidimensional, database target biasanya bersifat
relasional atau multidimensi. Dalam format relasional, kubus data diimplementasikan
menggunakan format skema bintang, konstelasi (canstellation), dan snow flake.
Namun perlu diingat, format relasional lah yang didukung oleh banyak vendor.
Skema bintang terdiri dari tabel fakta besar dan sejumlah tabel dimensi yang
lebih kecil. Fakta merupakan informasi kuantitatif yang akan dianalisis, sementara
tabel dimensi berisi informasi yang relevan yang menggambarkan entitas bisnis
organisasi yang direpresentasikan sebagai hierarki. Hirarki dalam skema bintang
dapat dirincikan hingga ke tabel dimensi.
Sebuah skema canstellation bisa terdiri dari beberapa tabel fakta yang berbagi
banyak tabel dimensi. Berbagai tabel fakta dapat dihubungkan satu sama lain untuk
mengaktifkan fungsi drill-down. Skema canstellation lebih rumit daripada skema
bintang karena banyak variasi dalam agregasi yang dapat digunakan.
Skema snowflake adalah varian dari skema bintang dan secara eksplisit
menampilkan semua hierarki. Skema snowflake dapat dikembangkan dari skema
bintang dengan memperluas hierarki melalui normalisasi di setiap dimensi (Moody
dan Kortink, 2000).

Universitas Esa Unggul

http://esaunggul.ac.id 10 /
23
Gambar 3.3. Skema bintang (star) untuk penjualan/ sales (Moody and Kortink, 2000)

Gambar 3.4. Skema Snowflake untuk penjualan/ sales (Moody and Kortink, 2000)

Gambar 3.5. Skema Canstellation untuk penjualan/ sales (Moody and Kortink, 2000)
Perlu dilakukan perbandingan yang komprehensif untuk melakukan pemilihan
pemodelan multidimensionalitas agar sesuai dengan kondisi organisasi. Salah satu
teknik untuk penilaian pemodelan multidimensionalitas bisa menggunakan kriteria :

Universitas Esa Unggul

http://esaunggul.ac.id 11 /
23
efisiensi, kegunaan, penggunaan kembali, fleksibilitas, redundansi dan kompleksitas
(Mishra et al, 2008)
Efisiensi adalah faktor yang paling penting untuk dipertimbangkan dalam
pemodelan multidimensional karena banyak menggunakan join dimana masing-
masing tabel yang di join bisa memiliki banyak data (Martyn, 20004). Skema bintang
adalah pilihan terbaik dalam hal efisiensi karena alasan-alasan berikut: (1) lebih
sedikit join yang diperlukan karena sudah dilakukan denormalisasi; (2) skema
bintang sudah dikenal oleh banyak tool; dan (3) operasi join pada skema bintang
mudah diperoleh dengan bantuan tool tertentu.
Sejumlah skema bintang dapat digabungkan secara hierarkis untuk membentuk
skema canstellation. Oleh karena itu perlu lebih banyak join untuk menautkan tabel
fakta. Demikian juga, perlu join lebih banyak untuk skema snowflake untuk
menghubungkan tabel dimensi. Namun, beberapa kasus menunjukkan bahwa
denormalisasi dalam skema bintang tumbuh dengan cepat, sehingga dalam konteks
ini skema snow flake adalah pilihan optimal dalam hal efisiensi.
Dilihat dari sisi penggunaan, skema bintang adalah struktur paling sederhana
karena hanya memerlukan jumlah tabel paling sedikit dibandingkan dengan dua
skema lainnya. Karakteristik ini memungkinkan formulasi query analitik yang mudah
mengingat hanya beberapa join yang dieksekusi. Oleh karena itu, di antara ketiga
skema, struktur skema bintang adalah yang paling mudah dipelajari.
Terkait dengan penggunaan ulang (reusability), di skema snowflake, tabel
dimensi disusun dalam bentuk normal. Akibatnya, berbagi tabel dimensi lebih mudah
dilakukan di skema snowflake dibandingkan dengan skema bintang dan
canstellation. Di skema bintang dan canstellation, berbagi tabel dimensi kurang
nyaman dilakukan karena denormalisasi data.
Fleksibilitas berkaitan dengan adaptasi terhadap perubahan. Di antara ketiga
teknik pemodelan multidimensional, skema bintang adalah yang paling fleksibel
dalam hal adaptasi terhadap sifat dinamis kebutuhan pengguna. Adaptasi ini
dimungkinkan oleh akses yang sama diantara dimensi ke tabel fakta.
Berikut ini adalah perbandingan pemodelan fakta diantara ketiga skema
tersebut sebagaimana bisa dilihat pada Tabel 3.3, Tabel 3.4.

Universitas Esa Unggul

http://esaunggul.ac.id 12 /
23
Tabel 3.3. Perbandingan skema untuk pemodelan multidimensional (sumber: Mishra
et al, 2008)
Skema bintang Skema Skema snowflake
(star) canstellation
Efisiensi Tinggi Tinggi Sedang
Penggunaan Tinggi Sedang Sedang
Penggunaan Rendah Rendah Tinggi
kembali
Fleksibilitas Tinggi Tinggi Sedang
Redundansi Tinggi Tinggi Rendah
Kompleksitas Rendah Sedang Sedang

Tabel 3.4. Perbandingan Skema untuk Data Warehouse

Skema DW Kelebihan Kekurangan
Star schema  Struktur paling sederhana  Sangat tidak
(Moody and Kortink, 2008) fleksibel
 Memungkinan pengurangan (Teklitz, 2000)
jumlah tabel sehingga bisa  Setiap GB data
dioptimalisasikan (Basaran, mentah
2005) membutuhkan
 Jumlah relasi diantara tabel tambahan ruang
bisa dikurangi (Basaran, dalam GB juga
2005). untuk agregasi
 Jumlah join dalam query (Teklitz, 2000)
pengguna bisa dikurangi  Butuh upaya lebih
(Basaran, 2005). untuk menjaga
 Kinerja query bisa dipercepat skema ketika
digunakan di DW
(Teklitz, 2000)
Fact  Hemat ruang penyimpanan  Kurang berguna
canstellation karena bisa dilakukan untuk organisasi
schema penggunaan ulang dimensi kecil karena
(Levene and Loizou, 2003). kompleks (Feng et

Universitas Esa Unggul

http://esaunggul.ac.id 13 /
23
 al, 2004)
Snowflake  Struktur hirarki setiap  Kompleksitas yang
schema dimensi bisa ditunjukkan tidak perlu
(Teklitz, 2000) meningkat (Teklitz,
 Mudah difahami (Arfaoui and 2000)
Akaichi, 2012)  Mengurangi kinerja
 Agregasi data bisa query (Teklitz, 2000)
diakomodasi (Arfaoui and
Akaichi, 2012)
 Mudah diperluas dengan
menambahkan atribut baru
tanpa mempengaruhi
program database yang
sudah ada (Arfaoui and
Akaichi, 2012).

Adapun implementasi kubus data di lingkungan pemodelan multidimensional bisa

menggunakan salah satu teknik berikut: condensed cubes, dwarfs dan QC-Tree.
Perbandingan ketiga teknik ini bisa dilihat pada Tabel 3.5

Tabel 3.5. Perbandingan Implementasi Pemodelan Multidimensional

Condensed cube (Feng Dwarf (Sismanis et al, QC-Tree
et al, 2004; Wang et al, 2003; Sismanis and (Lakshmanan,
2002) Roussopoulos, 2004) 2003)
Ukuran Ukuran jauh lebih kecil Kompresi tinggi ter Struktur sangat
cluster kompak

Kompresi  Perhitungan kubus  Butuh arsitektur Ramping dan

dilakukan sebelumnya lengkap agar bisa elegan
tanpa kompresi mendukung query,
 Tidak perlu kompresi update atau roll-up
ulang atau agregasi data
saat melakukan query  Granularitas bisa
diset untuk
Universitas Esa Unggul
http://esaunggul.ac.id 14 /
23
 pengecekan level
materialisasi

Dalam pemodelan multidimensional, sangat diperlukan teknik optimasi untuk

meminimalisir biaya untuk menjalankan query yang kompleks. Beberapa teknik yang
biasa digunakan diantaranya adalah index, materialised view dan fragmentasi data
(Aouiche, 2005). Tanpa teknik optimasi, query bisa dieksekusi dalam beberapa jam
atau bahkan beberapa hari karena kompleksnya query dan juga banyaknya join
diantara tabel-tabel dimensi.
Masalah kritis yang terkait dengan materialised view adalah kardinalitas yang
digunakan di view (Theodoratos dan Bouzeghoub, 2000; Vassiliadis, 2000). Jumlah
view yang mungkin diperoleh dari kubus teragregasi berbanding eksponensial
dengan jumlah atribut. Asumsi yang digunakan oleh sebagian besar pendekatan
adalah total ruang disk yang ditempati oleh materialisasi; dengan pendekatan seperti
itu, pengguna berusaha untuk membuat subset view yang guna mengatasi kendala
ini dan mengurangi beban kerja (Golfarelli et al, 2000; Gupta, 1997; Harinarayan et
al, 1996). Setelah DW terisi, kardinalitas view dapat diperkirakan secara akurat
dengan menggunakan teknik statistik berdasarkan : histogram (Muralikrishna dan
DeWitt, 1998) atau pengambilan sampel (Hou dan zsoyoglu, 1991). Namun, teknik
itu tidak dapat digunakan jika DW masih dalam fase pembangunan. Estimasi
kardinalitas view juga diperlukan untuk tujuan perancangan.
Index adalah teknik yang biasa digunakan di DW untuk meminimalkan waktu
pemanggilan hasil query (Poolet, 2008). Untuk pemanggilan data secara cepat dari
DW, berbagai teknik pengindeksan telah dikembangkan dan digunakan. Tabel 3.6
memberikan deskripsi singkat tentang beberapa teknik pengindeksan yang biasa
digunakan di DW.

Tabel 3.6. Beberapa Teknik Pengindeksan di DW (sumber: Jamil and Ibrahim, 2009)
Teknik Kelebihan Kekurangan
Pengindeksan
Indeks Bitmap  Banyak dipakai di lingkungan DW  Kinerjanya rendah
 Waktu respons nya bisa minimal kolom kardinalitas
 Ruang penyimpanan yang dibutuhkan datanya tinggi
paling kecil dibanding teknik indeksing  Perlu ekstra usaha jika
Universitas Esa Unggul
http://esaunggul.ac.id 15 /
23
 yang lain index dimodifikasi
 Kinerja sangat bagus meski dengan  Jika ada modifikasi di
memori atau CPU kecil index bitmap yang
 Pemeliharaannya efisine tidak tepat maka akan
terjadi concurrency
Index Cluster  Kinerja bisa dioptimalisasikan.  Biaya meningkat
 Bagus untuk query berbasis rentang, seiring dengan data
hanya membutuhkan data yang terurut yang tidak terurut
 Perlu pengurutan ulang
jika data ditambahkan
(Davidson, 2008;
Aizawa, 2002)

Index Hash  Data yang jumlahnya besar bisa  Menyebabkan kolusi

diminimalisir ( collusion)
(Delmarco, 2006).  Query berbasis
 Lookup bisa diminimalisir melalui rentang tidak didukung
fungsi hash, ukuran tabel dan struktur  Menyebabkan rantai
data internal. panjang pada hash
(http://en.wikipedia.org/wiki/Hash_table yang statis
).  Hash tidak mungkin
 Tidak perlu kunci untuk pengurutan dikembalikan
 Opsi terbaik untuk pemilihan yang
setara

Dalam konteks relasional, ada tiga jenis fragmentasi yang bisa diadopsi DW
(Ozsu dan Valduriez, 1991): fragmentasi vertikal, fragmentasi horizontal dan
fragmentasi campuran (hibrid). Pada dasarnya, fragmentasi vertikal membagi tabel
dengan kolom, sedangkan fragmentasi horizontal membagi tabel dengan baris.
Dalam fragmentasi horizontal, tabelnya sama dengan yang asli, kecuali barisnya
dibagi. Namun, dalam fragmentasi vertikal, satu tabel dibagi menjadi dua atau lebih
tabel. Di banyak kasus, fragmentasi horizontal atau vertikal sederhana tidak cukup
untuk memenuhi persyaratan aplikasi. Diperlukan fragmentasi campuran / hibrid
(fragmentasi horizontal yang diikuti oleh fragmentasi vertikal atau sebaliknya).
Universitas Esa Unggul
http://esaunggul.ac.id 16 /
23
 Fragmentasi horizontal dimaksudkan untuk meminimalkan akses data yang
tidak relevan, sedangkan fragmentasi vertikal dirancang untuk mempartisi suatu
relasi menjadi sekumpulan relasi yang lebih kecil sehingga hanya satu fragmen yang
dieksekusi oleh banyak aplikasi (Ozsu dan Valduriez, 1991; Bellatreche, 2000).
Selanjutnya, fragmentasi dapat diterapkan pada DM ketika pendekatan top-down
diterapkan (DM berasal dari DW).
Fragmentasi horizontal selanjutnya dibagi menjadi dua versi fragmentasi
(Ozsu dan Valduriez, 1991) yaitu: primer dan turunan. Kedua versi ini (primer dan
turunan) berhubungan dengan atribut. Untuk yang versi primer, atribut didefinisikan
pada relasi tersebut, sedangkan pada fragmentasi turunan, atribut didefinisikan pada
relasi yang lain (berdasarkan skema fragmentasi tabel lain).
Sebelum fragmentasi horisontal dilaksanakan, ukuran tabel dan subset tupel
yang sering di query secara bersamaan harus diuji terlebih dahulu. Semakin tinggi
jumlah baris, semakin rendah ukurannya; akibatnya, waktu respons kueri meningkat,
meskipun penggunaan beberapa baris memperburuk kualitas query. Persyaratan
dan data yang di query secara bersamaan harus berfungsi sebagai dasar untuk
keputusan apakah akan menambah jumlah baris atau tidak.

3.1.4. Disain Fisikal (Physical Design)

Fase terakhir pembangunan DW adalah desain fisikal sehubungan dengan
desain arsitektur DW dan hubungannya dengan DM / Data Mart (Kimball et al, 2008).
Dua teknik utama untuk merancang DW adalah top-down dan bottom-up. Lihat
kembali pembahasan tentang hal ini di modul 2
Bagi sebagian besar perusahaan, pendekatan top-down adalah strategi yang
secara signifikan menguntungkan dalam hal biaya dan durasi implementasi. Ini juga
merupakan pilihan yang menarik bagi desainer (Kimball et al, 2008) terkait dengan
ukuran dan kompleksitas. Dengan kata lain, pengurangan ukuran DM
memungkinkan perusahaan untuk lebih cepat menutup investasi keuangan mereka
dalam pembangunan.
Para praktisi umumnya menerapkan pendekatan bottom-up dalam
pembangunan DW (Kimball et al, 2008; Imhoff et al, 2003), meski tetap dibantu
dengan penggunaan framework DW yang sudah mapan sebagai dasar untuk
membangun DM. Framework ini dapat juga digunakan untuk melakukan integrasi di
masa yang akan datang di antara DM yang berbeda. Namun harus diingat juga

Universitas Esa Unggul

http://esaunggul.ac.id 17 /
23
bahwa banyak kegagalan proyek DW karena disebabkan oleh kurangnya
pemahaman atas framework yang digunakan (Paim et al, 2002) terkait dengan
penggunaan bersama data yang sama oleh DM yang berbeda, meskipun data
tersebut dalam format atau struktur yang berbeda.

Secara singkat, tahapan pembangunan DW di atas bisa diringkas sebagaimana

diuraikan dalam Tabel 3.7 beikut

Tabel 3.7. Ringkasan fase pembangunan data warehouse berdasarkan literature

Task Tools
* Analisis kebutuhan - Interview
- Data driven - Subject area
- User driven - Prototype
- Goal driven - Scenario
- Process driven - JAD
- Externally driven
* Conceptual design - E/R
- Multidimensional modelling - Object oriented
- Ad hoc model
* Logical design
- Relational implementation - M E/R
Star, constellation, snowflake
* schemata - Fact schema
- Multidimensional implementation - UML class diagram
* Cubes, dwarfs and QC-Trees - DFM
- Data storage
* ROLAP, MOLAP, HOLAP
* Physical design
- DW architecture design
Independent data
* Bottom up - mart
* Top Down - Centralized DW with
dependent data mart
Centralized DW
- without dependent
data mart

Universitas Esa Unggul

http://esaunggul.ac.id 18 /
23
C. Latihan
a. Mengapa hingga saat ini belum ada kesepakatan baku tentang metodologi
pembangunan DW?
b. Apa dampaknya dari ketiadaan platform dan teknologi yang baku dalam
pembangunan DW?
c. Meskipun masih belum ada kesepakatan baku tentang fase-fase
pembangunan DW, namun sudah ada konvensi tentang fase-fase yang
biasa digunakan dalam pembangunan DW. Apa sajakah fase-fase
tersebut?

D. Kunci Jawaban

a. Terlalu kompleksnya pekerjaan yang harus dilakukan saat pembangunan

DW mengakibatkan tidak adanya kesepakatan tentang tahapan
pembangunan DW
b. Dampak dari tidak adanya platform dan teknologi yang baku dalam
pembangunan DW menyebabkan ketergantungan kepada vendor DW
yang sudah dipilih perusahaan/organisasi
c. Analisis kebutuhan, disain konseptual, disain logical, disain fisikal

Referensi
Aizawa, A. (2002). A method of cluster-based indexing of textual data. In
Proceedings of the 19thinternational conference on Computational linguistics -
Volume 1, International Conference On Computational Linguistics, Taipei,
Taiwan, pp. 1 – 7, 2002
Aouiche, K. 2005. Automatic selection of indexes in data warehouses. Research
report, Laboratory ERIC Lumière Lyon2University, Doctoral School in Cognitive
Science, December 8, 2005.
Arfaoui, N. and Akaichi, J. (2012). Data Warehouse: Conceptual and Logical
Schema – Survey. International Journal of Enterprise Computing and Business
Systems. ISSN (Online): 2230-8849. Vol. 2 Issue 1 January 2012
Artz, J. 2005. Data driven vs. metric driven data warehouse design. In Encyclopaedia
of Data Warehousing and Mining, (pp. 223 – 227). Idea Group

Universitas Esa Unggul

http://esaunggul.ac.id 19 /
23
Basaran, B. P. (2005). A Comparison of Data Warehouse Design Models, A Master’s
Thesis in Computer Engineering. 2005
Cabibbo, L. and Torlone, R. (2000). The design and development of a logical system
for OLAP. In Y. Kambayashi, M. Mohania, and A. Min Tjoa, editors.
Proceedings of the 2nd International Conference on Data Warehousing and
Knowledge Discovery, DaWaK’00, LNCS 1874. Springer, 2000. pages 1–10.
Davidson, S. B. (2008). Indexing, Sorting and Hashing, October 23, 2008,
www.seas.upenn.edu/~cse330/docs/14-Indexing.ppt
Feng, J., Fang, Q., and Ding. H. (2004). Prefixcube: Prefix-sharing condensed data
cube. In Proc. DOLAP, pages 38–47
Frendi, M. and Salinesi, C. (2003). Requirements engineering for data warehousing,
proceedings of REFSQ Workshop
Frolick, M. and Ariyachandra, T. (2006). Critical Success Factors in Business
Performance Management-Striving for Success. Information Systems
Management, 25, 113-120.
Go, K. and Carroll, J. (2004). Scenario-based task analysis. In D. Diaper & N.
Stanton (Eds.), The handbook of task analysis for human-computer interaction
(pp. 117–133). Mahwah, NJ: Lawrence Erlbaum Associates.
Golfarelli, M. (2010). From User Requirements to Conceptual Design in Data
warehouse Design. IGI Global. DOI: 10.4018/978-1-60566-756-0.ch001
Guo, Y., Tang, S., Tong, Y., & Yang, D. 2006. Triple-driven data modelling
methodology in data warehousing: a case study. In Proceedings ACM
International Workshop on Data Warehousing and OLAP, 59-66.
Husemann, B., Lechtenbörger, J., & Vossen, G. (2000). Conceptual data warehouse
design. In Proceedings of the International Workshop on Design and
Management of Data Warehouses, Stockholm, Sweden.
Hou, W. and Zsoyoglu, G. O. (1991). Statistical Estimators for Aggregate Relational
Algebra Queries. ACM Transactions on Database Systems, 16(4):600–654.
Jamil, S., and Ibrahim, R. (2009). Performance Analysis of Indexing Techniques in
DW. International Conference on Emerging Technologies. 978-1-4244-5632-
1/09 ©2009 IEEE
Kaldeich, C. and Oliveira, J. (2004). Data warehouse methodology: A process driven
approach. In Proceedings of CAISE, LNCS, 3084, 536-549.

Universitas Esa Unggul

http://esaunggul.ac.id 20 /
23
Kamble, A., S. (2008). Conceptual Model for Multidimensional Data. The Fifth Asia-
Pacific Conference on Conceptual Modelling (APCCM 2008). Australian
Computer Society, Inc.
Kimball, R. and Ross, M. (2013). Data Warehouse Toolkit. 3rd edition. Wiley
Publishing.
Lakshmanan, L. V. S., Pei, J. and Zhao, Y. (2003). QC-Trees: an efficient summary
structure for semantic OLAP. In Proc. ACM SIGMOD, pages 64–75.
Levene, M. and Loizou, G. (2003). Why is the Snowflake Schema a Good Data
Warehouse Design? In Source, Information Systems, pp. 225-240
List B., Bruckner R., Machaczek K., and Schiefer, J. (2002). A comparison of data
warehouse development methodologies: Case study of the process warehouse.
In Proc. DEXA
Lujan-Mora, S., Trujillo, J., and Song, I. (2002). Extending the UML for
multidimensional modelling. In Proceedings of UML, LNCS 2460, (pp. 290-304).
Springer.
Mishra, D., Yazici, A., and Basaran, B. P. (2008). A Case Study of Data Models in
Data Warehousing. IEEE. 978-1-4244-2624-9/08
Muralikrishna, M. and DeWitt, D.J. (1998). Equi-depth Histograms for Estimating
Selectivity Factors for Multi-Dimensional Queries. In Proc. ACM Sigmod Conf.,
pages 28–36, Chicago, IL.
Niedrite, L., Treimanis, M., Solodovnikova, D. and Grundmane, L. (2009).
Development of Data Warehouse Conceptual Models: Method Engineering
Approach. IGI Global
Oliveira, J.S., Alvaro, J.C. and Kaldeich, C. (2012). A Multi-Driven Approach to
Requirements Analysis of Data Warehouse Schema: A Case Study.
Paim, F. R. S., and Castro, J. B. (2003). DWARF: An Approach for Requirements
Definition and Management of Datawarehouse Systems. In Proceedings of the
11th IEEE International Conference on Requirement Engineering (pp 75-78)
Poolet , M. A. (2008). Indexing the data warehouse. SQL server magazine August
2008.
Rizzi, S. (2009). Conceptual Modelling Solutions for the Data Warehouse. IGI Global
Sapia, C., Blaschka, M., Hofling, G.and Dinter, B. (1999). Extending the E/R model
for the multidimensional paradigm. Lecture Notes in Computer Science, 1552,
105-116.

Universitas Esa Unggul

http://esaunggul.ac.id 21 /
23
Saxena and Agarval. (2014). Data Warehouse Designing : a Dimensional Modeling
and Entity Relationship
Schiefer, J., List, B. and Bruckner, R.M. (2002). A Holistic Approach for Managing
Requirements of Data Warehouse Systems. Eight Americas Conference on
Information Systems.
Sen, A. and Sinha, A. P. (2007). Toward Developing Data Warehousing Standards:
An Ontology-Based Review of Existing Methodology. IEEE TRANSACTIONS
ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND
REVIEWS, VOL. 37, NO. 1, JANUARY 2007
Sismanis, Y. and Roussopoulos, N. (2004). The complexity of fully materialized
coalesced cubes. In Proc. VLDB, pages 540–551.
Teklitz, F. (2000). The Simplification of Data Warehouse Design, Sybase
Theodoratos, D and Bouzeghoub, M. (2000). A General Framework for the View
Selection Problem for Data Warehouse Design and Evolution. In Proc. DOLAP,
pages 1–8, Washington, DC.
Torlone, R. (2008). Two approaches to the integration of heterogeneous data
warehouses. Distrib. Parallel Databases 23(1), 69–97
Tryfona N, Busborg F, and Christiansen, JGB. (1999). starER: A Conceptual Model
for Data Warehouse Design. (portal.acm.org/citation.cfm?id=319776)
Vassiliadis, P. (2000). Gulliver in the land of data warehousing: practical experiences
and observations of a researcher. In Proc. DMDW, pages 12/1–12/16,
Stockholm, Sweden.
Winter, R and Strauch, B. (2003). A method for demand-driven information
requirements analysis in data warehousing. In Proceedings of Hawaii
International Conference on System Sciences, Hawaii, 1359-1365

Universitas Esa Unggul

http://esaunggul.ac.id 22 /
23