Skema dimensional dengan OLAP digunakan untuk memodelkan data dalam sistem pendukung keputusan berbasis data warehouse. Skema ini merepresentasikan data secara multidimensi dalam bentuk kubus data untuk memudahkan analisis dan pengambilan keputusan. Terdapat dua skema utama yaitu skema bintang dan skema salju yang mengorganisasikan tabel fakta dan dimensi.

1. HAL : 1
Pemodelan Data
Dimensional dengan
OLAP
5/22/2023

2. HAL : 2
 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).
5/22/2023
DW-based Decision Support System

3. HAL : 3
 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).
5/22/2023
OnLine Analysis Processing (OLAP)

4. HAL : 4
5/22/2023
W
i
l
a
y
a
h
Produk
Finance DB
Ad Hoc
Penjualan
Account DB
Product DB
Multidimensional Representation
Data Cube Representation

5. HAL : 5
“Penjualan per jenis produk dalam 6 bulan terakhir”
“Penjualan per dealer antara tahun 1990 dan 1995”
5/22/2023
Kode Produk Kode Waktu Kode Agen Penjualan Jumlah
Info Produk
Info Waktu
. . .
Ukuran numerik
dari tabel fakta
Kolom-kolom kunci dari tabel fakta
juga kunci dari tabel-tabel dimensi
Info Agen
Dimensional Data Model
. . .
. . .
. . .
. . .
Tabel-tabel
dimensi
Tabel fakta

6. HAL : 6
 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.
5/22/2023
Dimensions

7. HAL : 7
5/22/2023
Dimensi Dealer Dimensi Produk
Distrik
Wilayah
Total
Merk
Pabrik
Total
Agen Produk
Dimension Hierarchy

8. HAL : 8
5/22/2023
Kubus 3-dimensi:
Tabel fakta:
sale prod-Id store-Id tgl jumlah
p1 s1 1 12
p2 s1 1 11
p1 s3 1 50
p2 s2 1 8
p1 s1 2 44
p1 s2 2 4
tgl 2 s1 s2 s3
p1 44 4
p2 s1 s2 s3
p1 12 50
p2 11 8
tgl 1
3-D Data Cubes

9. HAL : 9
 Operasi analisa
◦ Slice & dice
◦ Role up & drill down
◦ Pivot
5/22/2023
Pelanggan
Senin
Rabu
Selasa
Produk
850
001
002
003
Penjualan $
323 714
Operations on Dimensional Models

10. HAL : 10
 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
5/22/2023
Slice, Dice & Pivot

11. HAL : 11
5/22/2023
tgl 2 s1 s2 s3
p1 44 4
p2 s1 s2 s3
p1 12 50
p2 11 8
tgl 1
s1 s2 s3
p1 12 50
p2 11 8
WAKTU = tanggal 1
Slicing

12. HAL : 12
5/22/2023
Produk
Tgl-1 Tgl-2
Toko t1 Electronics $5.2
Toys $1.9
Clothing $2.3
Cosmetics $1.1
Toko t2 Electronics $8.9
Toys $0.75
Clothing $4.6
Cosmetics $1.5
Produk
Toko t1 Toko t2
Toko t1 Electronics $5.2 $8.9
Toys $1.9 $0.75
Clothing $2.3 $4.6
Cosmetics $1.1 $1.5
Toko t2 Electronics
Toys
Clothing
(juta $)
Tgl-1
Penjualan
(juta $)
Waktu
Penjualan
Slice
&
Pivot

13. HAL : 13
 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
5/22/2023
Roll-up & Drill-down

14. HAL : 14
5/22/2023
tgl 2 s1 s2 s3
p1 44 4
p2 s1 s2 s3
p1 12 50
p2 11 8
tgl 1
s1 s2 s3
p1 56 4 50
p2 11 8
s1 s2 s3
sum 67 12 50
sum
p1 110
p2 19
129
. . .
drill-down
rollup
Contoh: penghitungan total
Roll-up vs Drill-down

15. HAL : 15
5/22/2023
wil A wil B
p1 56 54
p2 11 8
toko
wilayah
negara
(toko s1 di wilayah A;
toko s2, s3 di wilayah B)
tgl 2 s1 s2 s3
p1 44 4
p2 s1 s2 s3
p1 12 50
p2 11 8
tgl 1
Hierarchy-based Aggregation

16. HAL : 16
 Data agregat disimpan (dihitung dan ditam-
bahkan) dalam tabel fakta, untuk mening-katkan
kinerja query.
5/22/2023
* s1 s2 s3 *
p1 56 4 50 110
p2 11 8 19
* 67 12 50 129
tgl 2 s1 s2 s3 *
p1 44 4 48
p2
* 44 4 48
s1 s2 s3 *
p1 12 50 62
p2 11 8 19
* 23 8 50 81
tgl 1
Cubes with Aggregate Data
penjualan(*,p2,*)

17. HAL : 17
Operasi kalkulasi:
 Ranking
◦ Misal: top 20% produk dengan penjualan tertinggi.
 Fungsi waktu
◦ Penghitungan rata-rata per hari.
5/22/2023
Other Operations

18. HAL : 18
 Arsitektur 3-lapis (3-tier)
5/22/2023
Multi-
dimensional
access
Multidimensional
Viewer
Report
Viewer
Client
MDBMS Server
Multi-
dimensional
data
SQL-Read
RDBMS Server
Warehouse
data
Meta data
Derived
data SQL-Reach
Through
SQL-Read
Tier 1 Tier 2
Tier 3
OLAP Application Architecture
(OLAP Server)

19. HAL : 19
OLAP Technology:
 ROLAP
 MOLAP
 HOLAP
 Bagaimana memilih?
5/22/2023
Storage Technology

20. HAL : 20
 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)
5/22/2023
ROLAP

21. HAL : 21
 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.
5/22/2023
ROLAP (2)

22. HAL : 22
 Roll-up:
Total amounts untuk day 1 dalam SQL:
SELECT sum(amt) FROM SALE WHERE date = 1
5/22/2023
sale prodId storeId date amt
p1 s1 1 12
p2 s1 1 11
p1 s3 1 50
p2 s2 1 8
p1 s1 2 44
p1 s2 2 4
81
OLAP Operations in RDBM

23. HAL : 23
 Total amounts menurut date dalam SQL:
SELECT date, sum(amt) FROM SALE GROUP BY
date
5/22/2023
result date sum
1 81
2 48
sale prodId storeId date amt
p1 s1 1 12
p2 s1 1 11
p1 s3 1 50
p2 s2 1 8
p1 s1 2 44
p1 s2 2 4
OLAP Operations in RDBM (2)

24. HAL : 24
 Total amounts menurut date dan product-ID
dalam SQL:
SELECT prodId, date, sum(amt) FROM SALE
GROUP BY date, prodId
5/22/2023
result prodId date sum
p1 1 62
p2 1 19
p1 2 48
drill-down
rollup
sale prodId storeId date amt
p1 s1 1 12
p2 s1 1 11
p1 s3 1 50
p2 s2 1 8
p1 s1 2 44
p1 s2 2 4
OLAP Operations in RDBM (3)

25. HAL : 25
Skema Bintang dan Keping Salju
5/22/2023

26. HAL : 26
5/22/2023
Star Schema

27. HAL : 27
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
merepresentasi-kan hirarki dimensi, metadata
tidak rumit, low maintenance, jumlah operasi
join minimal.
5/22/2023
Classical Star Schema

28. HAL : 28
5/22/2023

29. HAL : 29
 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.
5/22/2023
Problems with Aggregates

30. HAL : 30
 … 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).
5/22/2023
Problems with Aggregates (2)

31. HAL : 31
 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.
5/22/2023
From Star to Snowflake

32. HAL : 32
5/22/2023
KODE_AGEN
Dimensi Agen
Nama Agen
Alamat
No Telpon
Kode_Distrik
Nama Distrik
Kode_Kota
Nama Kota
Manajer Kota
Kode_Distrik
Nama Distrik
Kode_Kota
Kode_Kota
Nama Kota
Manajer Kota
KODE_AGEN
KEY_PRODUK
KEY_PERIODE
Nilai
Jumlah
Biaya
Tabel Fakta Utama
Nilai
Jumlah
Biaya
Tabel Fakta Distrik
Kode_Distrik
KEY_PRODUK
KEY_PERIODE Nilai
Jumlah
Biaya
Tabel Fakta Kota
Kode_Kota
KEY_PRODUK
KEY_PERIODE
Aggregate Fact Tables
tabel agregat (rangkuman)

33. HAL : 33
 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
ter-denormalisasi: untuk query-query kompleks
dan ad-hoc.
5/22/2023
Snowflake Schema (2)

34. HAL : 34
 Prakteknya:
◦ Mulai dengan skema bintang, lalu buat
kembang-kristal salju-nya dengan query.
◦ Keuntungan: referential integrity terjamin.
 Kelebihan:
◦ Kinerja pemrosesan query tinggi untuk query-
query yang melibatkan agregasi (hitungan
total).
 Kelemahan:
◦ Rumit dalam pemeliharaan dan metadata-nya
◦ Jumlah tabel dalam database membengkak.
5/22/2023
Snowflake Schema (3)

35. HAL : 35
5/22/2023
Info Agen
Info Produk
Info Waktu
Multiple Aggregate Tables
Kode Produk Kode Waktu Kode Agen Nilai Jumlah
. . . . . .
. . .
. . .
. . .
Produk Waktu Agen Nilai Jml
. . . . . .
. . .
. . .
. . .
Produk Waktu Agen Nilai Jml
. . . . . .
. . .
. . .
. . .
Distrik
Kota
Produk Waktu Agen Nilai Jml
. . . . . .
. . .
. . .
. . .
Produk Waktu Agen Nilai Jml
. . . . . .
. . .
. . .
. . .
Produk Waktu Agen Nilai Jml
. . . . . .
. . .
. . .
. . .
Bulanan
Kuartalan
Tahunan
Tabel-tabel
fakta agregat

36. HAL : 36
 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.
5/22/2023
Multiple DW Subjects

37. HAL : 37
5/22/2023
Conformed Dimensions
Subject 1 Subject 2

38. HAL : 38
 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.
5/22/2023
MOLAP

39. HAL : 39
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
5/22/2023
MOLAP (2)

40. HAL : 40
 Gabungan ROLAP dengan MOLAP
◦ Menyimpan data rinci dengan RDBMS dan data
agregat dengan MDBMS
◦ Akses data secara MOLAP.
5/22/2023
HOLAP

41. HAL : 41
ROLAP,
MOLAP or
HOLAP
5/22/2023
?

42. HAL : 42
 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.
5/22/2023
Use ROLAP when ...

43. HAL : 43
 Data yang tersedia berupa data agregat
 Hanya membutuhkan data agregat
 Contoh:
◦ Analisa dan penyusunan anggaran oleh bagian
keuangan
◦ Analisa penjualan
◦ Dsb.
5/22/2023
Use MOLAP when ...

44. HAL : 44
 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.
5/22/2023
Use HOLAP when ...

45. HAL : 45
Teknik-teknik ROLAP
5/22/2023

46. HAL : 46
 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
5/22/2023
Dealing with Dimension Changes

47. HAL : 47
 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.
5/22/2023
Surrogate Key

48. HAL : 48
5/22/2023
Surrogate Key Example
NAMA NIP TGL_LAHIR ALAMAT DEPT
Andi Matalata 123456789 09-JAN-75 Jl. Kelinci 33 5
Nana Suryana 333445555 08-DEC-65 Jl. Kapuk 17 5
Sujono 999887777 19-JUL-58 Jl. Duren 20 4
Ahmad Qadri 987654321 19-JUN-72 Jl. Sawah 4A 4
Edi Harahap 666884444 15-SEP-62 Jl. Anggrek 3 5
Hermanto 453453453 31-JUL-69 Jl. Sawo 15 5
Ferdi Silalahi 987987987 29-MAR-69 Jl. Mawar 23 4
Frans Jaelani 888665555 10-NOV-67 Jl. Rawa 15 1
key asli
NAMA NIP TGL_LAHIR ALAMAT DEPT
Andi Matalata 123456789 09-JAN-75 Jl. Kelinci 33 5
Nana Suryana 333445555 08-DEC-65 Jl. Kapuk 17 5
Sujono 999887777 19-JUL-58 Jl. Duren 20 4
Ahmad Qadri 987654321 19-JUN-72 Jl. Sawah 4A 4
Edi Harahap 666884444 15-SEP-62 Jl. Anggrek 3 5
Hermanto 453453453 31-JUL-69 Jl. Sawo 15 5
Ferdi Silalahi 987987987 29-MAR-69 Jl. Mawar 23 4
Frans Jaelani 888665555 10-NOV-67 Jl. Rawa 15 1
KEY_PEG
010234
010456
010478
020125
020136
020167
030224
030350
key pengganti

49. HAL : 49
 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)
5/22/2023
Slowly Changing Dimensions

50. HAL : 50
 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.
5/22/2023
Type 1 Changes

51. HAL : 51
5/22/2023
Nama: Dony Wijaya
Alamat: Jl. Salemba Raya 4
Cust ID: 9901245

Nama: Donnie Wijaya
Alamat: Jl. Salemba Raya 4
Cust ID: 9901245

Koreksi kesalahan nama
Dimensi: PELANGGAN
Type 1 Change Example

52. HAL : 52
 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) ...
5/22/2023
Type 2 Changes

53. HAL : 53
 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)
5/22/2023
Type 2 Changes (2)

54. HAL : 54
5/22/2023
Key Pelanggan: 100237
Kode Pelanggan: N203077
Nama: Nia Daniati
Status Nikah: tidak
Alamat: Jl. Salemba Raya 7
Kode Pos: Jakarta 12345

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
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

1
2
Perubahan status record
dimensi PELANGGAN:
3 periode historis untuk
pelanggan yang sama
Type 2 Change Example

55. HAL : 55
 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.
5/22/2023
Type 3 Changes

56. HAL : 56
5/22/2023
Sales Key: 101724
Sales Code: AM203
Nama: Arman Munawar
Wilayah Lama: Jakarta Pusat
Wilayah: Jakarta Selatan
Daerah: DKI Jakarta

Sales Key: 101724
Sales Code: AM203
Nama: Arman Munawar
Wilayah: Jakarta Pusat
Daerah: DKI Jakarta

Nilai atribut ganda/paralel
Dimensi: Salesman
Type 3 Change Example

57. HAL : 57
 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.
5/22/2023
Rapidly Changing Dimensions

58. HAL : 58
5/22/2023
PELANGGAN
Key Pelanggan
Nama
Alamat
Kode Pos
Telp

PENJUALAN
Key Pelanggan

Metrics
PELANGGAN
Key Pelanggan
Nama
Alamat
Kode Pos
Telp

PERILAKU
Key Perilaku
Key Pelanggan
Rating Kredit
Status Nikah
Range Pembelian
Tingkat Penghasilan
Kepemilikan Rumah

PENJUALAN
Key Pelanggan
Key Perilaku

Metrics
statis
banyak berubah
tabel fakta
Partitioned Dimension
sebelum
sesudah

59. HAL : 59
 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.
5/22/2023
Slowly-Changing Dimension Policy