data warehouse

FAKULTAS
TEKNOLOGI INFORMASI
UNIVERSITAS
BUDI LUHUR
Pemodelan Data
Dimensional
dengan OLAP
www.bl.ac.id
Universitas Budi Luhur
Pertemuan ke-14
HAL : 1
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
DW-based Decision Support System
• Tujuan: untuk mendapatkan keputusan yang lebih
tepat secara lebih cepat.
• Prinsip: data sebagai representasi lingkungan:
situasi konsumen, pasar & persaingan, kemampuan
perusahaan sendiri.
– Dibangun diatas data warehouse
– Gabungan dari pelaporan (reporting), analisa
pemodelan dan eksplorasi data (query).
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 2
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
OnLine Analysis Processing (OLAP)
• Merepresentasikan data dengan kubus multidimensional:
lebih mudah dibaca
• Aspek: ukuran (metric) dan dimensi (dimension)
– Ukuran: besaran data
– Dimensi: konteks data (parameter bisnis)
– Contoh: melihat penjualan (ukuran) menurut wilayah,
waktu, dan produk (dimensi-dimensi)
• Ukuran disimpan dalam tabel fakta (fact table), dimensi
dalam tabel dimensi (dimension table).
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 3
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Multidimensional Representation
Penjualan
Finance DB
W
i
l
a
y
a
h
Produk
Account DB
Ad Hoc
Product DB
Data Cube Representation
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 4
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Dimensional Data Model
“Penjualan per jenis produk dalam 6 bulan terakhir”
“Penjualan per dealer antara tahun 1990 dan 1995”
Info Agen
Ukuran numerik
dari tabel fakta
Kolom-kolom kunci dari tabel fakta
juga kunci dari tabel-tabel dimensi
Kode Produk Kode Waktu Kode Agen Penjualan Jumlah
Info Produk
Tabel-tabel
dimensi
GASAL 2008/2009
...
...
...
...
...
Tabel fakta
Info Waktu
PERANCANGAN BASIS DATA (KP130)
HAL : 5
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Dimensions
• Dimensi dapat memiliki atribut
– Misal, dimensi dealer memiliki atribut alamat,
nama manajer, dsb
– Misal, dimensi produk memiliki harga, merk,
warna.
• Dimensi umumnya memiliki hirarki
– Misal, dimensi waktu: hari  bulan  kuartal
– Misal, dimensi produk: produk  jenis produk 
merk
• Skala dimensi tergantung dari kerincian (granularity)
dari tabel fakta.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 6
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Dimension Hierarchy
Dimensi Dealer
Dimensi Produk
Total
Wilayah
Distrik
Agen
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
Total
Pabrik
Merk
Produk
HAL : 7
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
3-D Data Cubes
Kubus 3-dimensi:
Tabel fakta:
sale
prod-Id
p1
p2
p1
p2
p1
p1
store-Id
s1
s1
s3
s2
s1
s2
GASAL 2008/2009
tgl
1
1
1
1
2
2
jumlah
12
11
50
8
44
4
tgl 2
tgl 1
p1
p2
p1
p2
s1
44
s1
12
11
PERANCANGAN BASIS DATA (KP130)
s2
4
s2
s3
s3
50
8
HAL : 8
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Operations on Dimensional Models
• Operasi analisa
– Slice & dice
– Role up & drill down
– Pivot
Produk
850
323
714
Rabu
Selasa
001
Senin
002
Pelanggan
Penjualan $
003
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 9
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Slice, Dice & Pivot
• Slicing & Dicing
– Mengambil potongan kubus berdasarkan nilai
tertentu pada satu atau beberapa dimensinya
• Pivoting
– Menampilkan nilai-nilai ukuran dalam tata letak
tabel yang berbeda
– Menggabungkan dua atau lebih dimensi kedalam
hierarki sub-dimensi dalam tampilan tabel
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 10
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Slicing
tgl 2
tgl 1
p1
p2
p1
p2
s1
44
s1
12
11
s2
4
s2
s3
s3
50
8
WAKTU = tanggal 1
p1
p2
GASAL 2008/2009
s1
12
11
s2
s3
50
8
PERANCANGAN BASIS DATA (KP130)
HAL : 11
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Slice
&
Pivot
Produk
Toko t1
Toko t2
Electronics
Toys
Clothing
Cosmetics
Electronics
Toys
Clothing
Cosmetics
Produk
Toko t1
Toko t2
GASAL 2008/2009
Electronics
Toys
Clothing
Cosmetics
Electronics
Toys
Clothing
Penjualan
(juta $)
Waktu
Tgl-1 Tgl-2
$5.2
$1.9
$2.3
$1.1
$8.9
$0.75
$4.6
$1.5
Penjualan
(juta $)
Tgl-1
Toko t1 Toko t2
$5.2
$8.9
$1.9
$0.75
$2.3
$4.6
$1.1
$1.5
PERANCANGAN BASIS DATA (KP130)
HAL : 12
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Roll-up & Drill-down
• Roll-up
– Generalisasi satu atau beberapa dimensi dengan
merangkum nilai-nilai ukurannya
– Generalisasi: naik ke tingkat atasnya dalam hirarki
dimensi
• Drill-down
– Memilih dan menampilkan data rincian dalam satu
atau beberapa dimensi
– Kebalikan dari operasi roll-up
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 13
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Roll-up vs Drill-down
Contoh: penghitungan total
tgl 2
tgl 1
p1
p2
p1
p2
s1
44
s2
4
s1
12
11
s2
s3
...
s3
50
8
sum
p1
p2
s1
56
11
s2
4
8
rollup
drill-down
GASAL 2008/2009
s1
67
s2
12
s3
50
s3
50
129
p1
p2
sum
110
19
PERANCANGAN BASIS DATA (KP130)
HAL : 14
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Hierarchy-based Aggregation
tgl 2
tgl 1
p1
p2
p1
p2
s1
44
s1
12
11
s2
4
s2
s3
s3
50
8
toko
wilayah
negara
p1
p2
GASAL 2008/2009
wil A
56
11
wil B
54
8
(toko s1 di wilayah A;
toko s2, s3 di wilayah B)
PERANCANGAN BASIS DATA (KP130)
HAL : 15
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Cubes with Aggregate Data
• Data agregat disimpan (dihitung dan ditam-bahkan)
dalam tabel fakta, untuk mening-katkan kinerja query.
*
tgl 2
tgl 1
p1
p2
*
p1
p2
s1
*
12
11
23
GASAL 2008/2009
p1
p2
*
s1
44
s2
44
8
8
s1
56
11
67
s2
4
s3
4
50
50
s2
4
8
12
s3
*
62
19
81
s3
50
*50
48
48
*
110
19
129
penjualan(*,p2,*)
PERANCANGAN BASIS DATA (KP130)
HAL : 16
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Other Operations
Operasi kalkulasi:
• Ranking
– Misal: top 20% produk dengan penjualan
tertinggi.
• Fungsi waktu
– Penghitungan rata-rata per hari.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 17
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
OLAP Application Architecture
• Arsitektur 3-lapis (3-tier)
RDBMS Server
MDBMS Server
Client
(OLAP Server)
Multidimensional
access
SQL-Read
Warehouse
data
Meta data
Derived
data
Multidimensional
Viewer
Multidimensional
data
Tier 3
SQL-Reach
Through
Tier 1
Tier 2
Report
Viewer
SQL-Read
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 18
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Storage Technology
OLAP Technology:
• ROLAP
• MOLAP
• HOLAP
• Bagaimana memilih?
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 19
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
ROLAP
• Relational DBMS dengan SQL standard dengan
optimasi kinerja (minimasi operasi join)
• Membutuhkan tambahan meta layer khusus
• Membutuhkan tambahan front end layer khusus
• Skema data: bintang (star) dan kristal salju
(snowflake)
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 20
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
ROLAP (2)
• Keuntungan:
– Dapat menampung volume data besar
(scalability)
– Menggunakan teknologi yang telah mapan
(RDB): kinerja lebih baik/teruji
– Memungkinkan DW untuk berubah
(berevolusi) tanpa harus merubah skema
data.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 21
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
OLAP Operations in RDBM
 Roll-up:
Total amounts untuk day 1 dalam SQL:
SELECT sum(amt) FROM SALE WHERE date =
1
sale
prodId
p1
p2
p1
p2
p1
p1
GASAL 2008/2009
storeId
s1
s1
s3
s2
s1
s2
date
1
1
1
1
2
2
amt
12
11
50
8
44
4
81
PERANCANGAN BASIS DATA (KP130)
HAL : 22
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
OLAP Operations in RDBM (2)
 Total amounts menurut date dalam SQL:
SELECT date, sum(amt) FROM SALE GROUP BY
date
sale
prodId
p1
p2
p1
p2
p1
p1
GASAL 2008/2009
storeId
s1
s1
s3
s2
s1
s2
date
1
1
1
1
2
2
amt
12
11
50
8
44
4
result
PERANCANGAN BASIS DATA (KP130)
date
1
2
sum
81
48
HAL : 23
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
OLAP Operations in RDBM (3)
 Total amounts menurut date dan product-ID dalam
SQL:
SELECT prodId, date, sum(amt) FROM SALE
GROUP BY date, prodId
sale
prodId
p1
p2
p1
p2
p1
p1
storeId
s1
s1
s3
s2
s1
s2
date
1
1
1
1
2
2
amt
12
11
50
8
44
4
result prodId
p1
p2
p1
date
1
1
2
sum
62
19
48
rollup
drill-down
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 24
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Implementasi ROLAP
Skema Bintang dan Keping Salju
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 25
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Star Schema
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 26
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Classical Star Schema
Skema Bintang Dasar:




Tabel fakta tunggal berisi data rinci dan agregat.
Satu kolom kunci (key) untuk tiap dimensi sebagai kunci primer
(primary key) tabel fakta.
Nilai-nilai kolom kunci asing (foreign key) telah terdefinisi.
Setiap dimensi direpresentasikan dalam satu tabel yang
umumnya sangat ter-denormalisasi.
• Keuntungan:
Mudah dipahami, mudah untuk merepresentasikan hirarki dimensi, metadata tidak rumit, low
maintenance, jumlah operasi join minimal.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 27
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Star
Schema
Example
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 28
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Problems with Aggregates
• Sumber masalah: penggabungan data rinci dan
agregat dalam tabel fakta tunggal.
• Solusi: tabel-tabel dimensi harus memiliki indikator
level (tingkat agregasi) yang dapat digunakan
sebagai kondisi syarat dalam query
• Akibat: kinerja pemrosesan query untuk tingkat
agregat rendah, apalagi dengan besarnya tabel fakta.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 29
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Problems with Aggregates (2)
• … Tabel-tabel dimensi harus memiliki indikator level (tingkat
agregasi) yang dapat digunakan sebagai kondisi syarat dalam
query
SELECT A.STORE_KEY, A.PERIOD_KEY,
A.dollars FROM Fact_Table A WHERE
A.STORE_KEY IN
(SELECT STORE_KEY FROM Store_Dimension B
WHERE region = “North” AND level = 2) AND … )
• Indikator level berpotensi menjadi sumber kesalahan: sangat
mudah terlupakan, berakibat nilai yang dihasilkan salah
(menjerumuskan).
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 30
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
From Star to Snowflake
• Alternatif solusi: normalisasi tabel dimensi
berdasarkan atribut level, lalu tabel-tabel dimensi
kecil yang dihasilkan diacukan pada tabel-tabel fakta
tersendiri untuk setiap level.
• Skema kristal salju (snowflake) diperoleh.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 31
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Aggregate Fact Tables
Dimensi Agen
KODE_AGEN
Kode_Distrik
Kode_Kota
Nama Agen
Alamat
No Telpon
Kode_Distrik
Nama Distrik
Kode_Kota
Nama Kota
Manajer Kota
Nama Distrik
Kode_Kota
Nama Kota
Manajer Kota
Tabel Fakta Utama
KODE_AGEN
KEY_PRODUK
KEY_PERIODE
Nilai
Jumlah
Biaya
Tabel Fakta Distrik
Kode_Distrik
KEY_PRODUK
KEY_PERIODE
Nilai
Jumlah
Biaya
Tabel Fakta Kota
Kode_Kota
KEY_PRODUK
KEY_PERIODE
Nilai
Jumlah
Biaya
tabel agregat (rangkuman)
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 32
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Snowflake Schema (2)
• Attribut level tidak diperlukan lagi.
• Setiap tabel dimensi tambahan memiliki satu kolom
kunci (key) untuk setiap level dalam hirarki dimensi.
• Tabel dimensi pada level terendah menggabungkan
atribut-atribut tabel dimensi lainnya.
• Level terendah masih berupa tabel fakta yang terdenormalisasi: untuk query-query kompleks dan adhoc.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 33
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Snowflake Schema (3)
• Prakteknya:
– Mulai dengan skema bintang, lalu buat kembangkristal salju-nya dengan query.
– Keuntungan: referential integrity terjamin.
• Kelebihan:
– Kinerja pemrosesan query tinggi untuk queryquery yang melibatkan agregasi (hitungan total).
• Kelemahan:
– Rumit dalam pemeliharaan dan metadata-nya
– Jumlah tabel dalam database membengkak.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 34
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Multiple Aggregate Tables
Kode Produk Kode Waktu Kode Agen
Nilai
Jumlah
Info Agen
...
Info Produk
...
...
Distrik
...
...
...
...
... ...
...
...
Bulanan
...
Tabel-tabel
fakta agregat
Kuartalan
Produk Waktu Agen Nilai Jml
Tahunan
Produk Waktu Agen Nilai Jml
...
...
. . .Produk
. . .Waktu
. . . Agen Nilai Jml
...
GASAL 2008/2009
...
Kota
Produk Waktu Agen Nilai Jml
Produk Waktu Agen Nilai Jml
...
Info Waktu
...
...
...
... ...
...
...
...
...
PERANCANGAN BASIS DATA (KP130)
...
HAL : 35
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Multiple DW Subjects
• DW dengan topik (business subject) banyak
– Setiap topik direpresentasikan oleh sebuah tabel
fakta
– Data masing-masing topik mungkin diperoleh dari
sistem aplikasi sumber yang berbeda
– Dimensi-dimensi yang dipakai oleh lebih dari satu
tabel fakta harus seragam (conformed) baik dalam
hal nama dan nilai atribut-atribut maupun
hierarkinya.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 36
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Conformed Dimensions
Subject 1
GASAL 2008/2009
Subject 2
PERANCANGAN BASIS DATA (KP130)
HAL : 37
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
MOLAP
• Menyimpan data sesuai dengan struktur kubus:
– Ukuran disimpan dalam array multi dimensi
– Array di-indeks oleh dimensi
• Akses langsung ke array
• Teknologi proprietary
• Belum ada standard access API/language
• Ada juga yang internalnya menggunakan RDBMS.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 38
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
MOLAP (2)
Keuntungan:
• Kinerja pemrosesan query tinggi dibanding ROLAP
• Lebih efisien, fleksibel dan intuitif dalam
merepresentasikan hierarki-hierarki dimensi
Kelemahan:
• Volume data (scalability) umumnya terbatas
• Relatif mahal dan bukan open architecture
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 39
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
HOLAP
• Gabungan ROLAP dengan MOLAP
– Menyimpan data rinci dengan RDBMS dan
data agregat dengan MDBMS
– Akses data secara MOLAP.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 40
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
ROLAP,
MOLAP or
HOLAP
GASAL 2008/2009
?
PERANCANGAN BASIS DATA (KP130)
HAL : 41
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Use ROLAP when ...
• Data pada tingkat transaksi (lowest granularity level)
• Hanya membutuhkan data rinci
• Banyak menggunakan query ad-hoc (bukan hasil
prekomputasi)
• Contoh:
– Telekomunikasi: call data records (CDRs)
– Situs e-Commerce
– Perusahaan kartu kredit.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 42
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Use MOLAP when ...
• Data yang tersedia berupa data agregat
• Hanya membutuhkan data agregat
• Contoh:
– Analisa dan penyusunan anggaran oleh bagian
keuangan
– Analisa penjualan
– Dsb.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 43
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Use HOLAP when ...
• Menggunakan OLAP baik dengan data rincian
maupun agregat
• User groups dengan kebutuhan yang
bervariasi
• Volume data rinci yang tinggi
• Contoh:
– Ritel
– Bank dan penyedia jasa finansial.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 44
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Teknik-teknik ROLAP
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 45
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Dealing with Dimension Changes
 Kunci pengganti (surrogate key)
• Antisipasi perubahan dimensi bisnis
 Revisi insidentil dimensi bisnis
• Tipe 1: Koreksi kesalahan
• Tipe 2: Perubahan status
• Tipe 3: Nilai atribut paralel
 Dimensi bisnis yang sering berubah
 Aturan (policy) perubahan dimensi
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 46
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Surrogate Key
• Pemakaian kunci pengganti untuk mengantisipasi
perubahan nilai kunci
– Penggantian nama, nomor induk, kode, dsb.
– Masalah daur ulang kode atau nomor yang sudah
tidak digunakan.
• Nilai kunci pengganti adalah nomor unik yang
diciptakan oleh sistem
• Nilai kunci aslinya disimpan sebagai atribut dalam
tabel dimensi.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 47
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Surrogate Key Example
NAMA
NIP
TGL_LAHIR
ALAMAT
DEPT
Andi Matalata
Nana Suryana
Sujono
Ahmad Qadri
Edi Harahap
Hermanto
Ferdi Silalahi
Frans Jaelani
123456789
333445555
999887777
987654321
666884444
453453453
987987987
888665555
09-JAN-75
08-DEC-65
19-JUL-58
19-JUN-72
15-SEP-62
31-JUL-69
29-MAR-69
10-NOV-67
Jl.
Jl.
Jl.
Jl.
Jl.
Jl.
Jl.
Jl.
5
5
4
4
5
5
4
1
key pengganti
Kelinci 33
Kapuk 17
Duren 20
Sawah 4A
Anggrek 3
Sawo 15
Mawar 23
Rawa 15
key asli
KEY_PEG
NAMA
NIP
TGL_LAHIR
ALAMAT
DEPT
010234
010456
010478
020125
020136
020167
030224
030350
Andi Matalata
Nana Suryana
Sujono
Ahmad Qadri
Edi Harahap
Hermanto
Ferdi Silalahi
Frans Jaelani
123456789
333445555
999887777
987654321
666884444
453453453
987987987
888665555
09-JAN-75
08-DEC-65
19-JUL-58
19-JUN-72
15-SEP-62
31-JUL-69
29-MAR-69
10-NOV-67
Jl. Kelinci 33
Jl. Kapuk 17
Jl. Duren 20
Jl. Sawah 4A
Jl. Anggrek 3
Jl. Sawo 15
Jl. Mawar 23
Jl. Rawa 15
5
5
4
4
5
5
4
1
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 48
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Slowly Changing Dimensions
• Jenis perubahan insidentil pada tabel dimensi:
– Tipe 1: Koreksi kesalahan
• Misal: Kesalahan tulis nama pelanggan.
– Tipe 2: Pergantian status
• Misal: Dari status membujang ke status
menikah.
– Tipe 3: Nilai atribut ganda/paralel
• Misal: Jabatan rangkap karyawan.
• Proses updating dilakukan saat full refresh
(maintenance)
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 49
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Type 1 Changes
• Tipe 1: Koreksi Kesalahan
• Karakteristik:
– Nilai lama yang salah digantikan dengan nilai baru.
– Perubahan terjadi pada aplikasi sumber data tanpa
mengubah status record data yang bersangkutan.
– Nilai lama tidak diperlukan lagi oleh aplikasi
sumber data maupun DW.
• Implementasi:
– Nilai lama dalam tabel dimensi dibuang dan
digantikan dengan nilai baru.
– Tidak ada perubahan lain di tabel fakta dan
dimensi.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 50
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Type 1 Change Example
Dimensi: PELANGGAN
Nama: Dony Wijaya
Nama: Donnie Wijaya
Alamat: Jl. Salemba Raya 4
Alamat: Jl. Salemba Raya 4
Cust ID: 9901245
Cust ID: 9901245


Koreksi kesalahan nama
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 51
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Type 2 Changes
• Tipe 2: Perubahan Status
• Karakteristik:
– Perubahan status record pada aplikasi sumber
data: nilai atribut baru menandai periode historis
baru (periode historis berganda).
– Nilai lama harus tetap disimpan sebagai data
historis DW.
• Implementasi:
– Tambahkan record baru dalam tabel dimensi
dengan nilai atribut baru (atribut yang lain sama
dengan record lama) ...
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 52
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Type 2 Changes (2)
• Implementasi:
– Tambahkan record baru dalam tabel dimensi
dengan nilai atribut baru (atribut yang lain sama
dengan record lama).
– Jika surrogate key digunakan, record baru ini
mendapat surrogate key baru.
– Tambahkan atribut berlaku_mulai dan berlaku_
sampai dalam tabel dimensi (jika belum ada)
– Tulis tanggal berlakunya perubahan (pada record
baru) dan tanggal tidak berlaku (pada record
lama/sebelumnya)
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 53
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Type 2 Change Example
Key Pelanggan: 100237
Kode Pelanggan: N203077
Nama: Nia Daniati
Status Nikah: tidak
Alamat: Jl. Salemba Raya 7
Kode Pos: Jakarta 12345

1
Key Pelanggan: 101724
Kode Pelanggan: N203077
Nama: Nia Darmawan
Status Nikah: menikah
Alamat: Jl. Salemba Raya 7
Kode Pos: Jakarta 12345
Berlaku Mulai: 10-07-2002
Berlaku Sampai: 04-01-2003
2
Perubahan status record
dimensi PELANGGAN:
3 periode historis untuk
pelanggan yang sama
GASAL 2008/2009
Key Pelanggan: 102015
Kode Pelanggan: N203077
Nama: Nia Darmawan
Status Nikah: menikah
Alamat: Jl. Barito 26
Kode Pos: Jakarta 14202
Berlaku Mulai: 05-01-2003

PERANCANGAN BASIS DATA (KP130)
HAL : 54
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Type 3 Changes
• Tipe 3: Nilai Atribut Paralel
• Karakteristik:
– Biasanya disebabkan oleh perubahan sementara nilai
atribut pada aplikasi sumber data.
– Nilai baru dan nilai lama masih digunakan/diperlukan
baik oleh aplikasi sumber data maupun DW.
• Implementasi:
– Tambahkan kolom nilai_lama dalam tabel dimensi,
dan pindahkan nilai yang lama ke kolom ini.
– Masukkan nilai baru pada kolom nilai aslinya.
– Jika perlu tambahkan/pakai kolom berlaku_mulai
untuk mencatat tanggal berlakunya perubahan.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 55
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Type 3 Change Example
Dimensi: Salesman
Sales Key: 101724
Sales Code: AM203
Nama: Arman Munawar
Wilayah: Jakarta Pusat
Daerah: DKI Jakarta

Sales Key: 101724
Sales Code: AM203
Nama: Arman Munawar
Wilayah Lama: Jakarta Pusat
Wilayah: Jakarta Selatan
Daerah: DKI Jakarta

Nilai atribut ganda/paralel
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 56
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Rapidly Changing Dimensions
• Problem:
– Dimensi yang sering dan banyak berubah.
– Perubahan pada tabel-tabel dimensi besar (misal:
dimensi customer dengan jutaan records) akan
sangat tidak efisien.
• Implementasi:
– Bagi/partisi tabel dimensi menjadi dua (atau lebih)
dimensi dengan mengeluarkan atribut-atribut yang
sering berubah ke tabel dimensi baru.
– Tambahkan kunci primer tabel dimensi baru
tersebut ke tabel fakta sebagai kunci eksternal.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 57
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Partitioned Dimension
PELANGGAN
Key Pelanggan
Nama
Alamat
Kode Pos
Telp

sebelum
PELANGGAN
Key Pelanggan
Nama
Alamat
Kode Pos
Telp

PENJUALAN
Key Pelanggan

Metrics
tabel fakta
GASAL 2008/2009
sesudah
PERILAKU
Key Perilaku
Key Pelanggan
Rating Kredit
Status Nikah
Range Pembelian
Tingkat Penghasilan
Kepemilikan Rumah

PERANCANGAN BASIS DATA (KP130)
statis
PENJUALAN
Key Pelanggan
Key Perilaku

Metrics
banyak berubah
HAL : 58
PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
Slowly-Changing Dimension Policy
• Tidak semua perubahan pada nilai atribut harus/dapat
diperlakukan sebagai perubahan tipe 2 atau tipe 3.
• Spesifikasi kebutuhan menentukan atribut-atribut
mana yang harus menerapkan pencatatan perubahan
tipe 2 dan tipe 3.
• Perubahan pada atribut-atribut lainnya diperlakukan
sebagai perubahan tipe 1: dilakukan dengan operasi
overwrite.
GASAL 2008/2009
PERANCANGAN BASIS DATA (KP130)
HAL : 59