| Tipe SCD | Prinsip | Kapan Dipakai |
|---|---|---|
| Type 1 | Overwrite, histori hilang | Data tidak penting historinya, hanya kondisi terkini |
| Type 2 | Tambah baris baru, histori lengkap | Histori sangat penting, perlu audit & analisis tren |
| Type 3 | Tambah kolom histori, hanya 1 langkah terakhir | Cukup tahu perubahan terakhir, histori lengkap tidak diperlukan |
Isi Catatan
Apa itu SCD?
SCD (Slowly Changing Dimension) adalah teknik dalam Data Warehouse untuk mengelola perubahan data pada tabel dimensi dari waktu ke waktu. Data dimensi (misalnya alamat pelanggan, jabatan pegawai, kategori produk) bisa berubah, dan SCD menentukan bagaimana perubahan itu disimpan di Data Warehouse.
Tujuan SCD:
Memelihara integritas data historis
Mendukung analisis tren dari waktu ke waktu
Memungkinkan audit perubahan data
Menyesuaikan kebutuhan pelaporan bisnis
Jenis-jenis SCD:
Tipe
Cara Kerja
Type 1
Menimpa data lama (Overwrite)
Type 2
Menambah baris baru (New Record)
Pratinjau Lampiran
Klik gambar atau PDF untuk membuka preview tanpa pindah halaman.
Galeri Gambar
Bagikan:
Type 3
Menambah kolom histori (New Column)
SCD Type 1 — Overwrite Existing Data
Cara kerja: Ketika terjadi perubahan, data lama langsung ditimpa oleh data baru. Hanya data terbaru yang tersimpan, histori hilang.
Contoh:
Sebelum:
CustomerID
Nama
Kota
C001
Budi
Jakarta
Setelah update (overwrite):
CustomerID
Nama
Kota
C001
Budi
Bandung
Kelebihan
Kekurangan
Cocok untuk
Sederhana, penyimpanan kecil, ETL lebih mudah
Kehilangan histori, tidak cocok untuk analisis perubahan
Koreksi kesalahan data, data yang tidak butuh histori (mis. email, no. telp)
SCD Type 2 — Add New Record
Cara kerja:
Record lama ditutup (EndDate diisi)
Current = N (tidak aktif)
Buat record baru
Current = Y (aktif)
Histori lengkap tetap tersimpan
Contoh:
Sebelum:
CustomerKey
CustomerID
Nama
Kota
StartDate
EndDate
Current
1
C001
Budi
Jakarta
2023-01-01
9999-12-31
Y
Setelah perubahan (pindah ke Bandung):
CustomerKey
CustomerID
Nama
Kota
StartDate
EndDate
Current
1
C001
Budi
Jakarta
2023-01-01
2024-06-30
N
2
C001
Budi
Bandung
2024-07-01
9999-12-31
Y
Kenapa perlu Surrogate Key? Satu CustomerID bisa punya banyak versi data, jadi dibutuhkan CustomerKey yang unik untuk setiap baris — CustomerID sama, tapi CustomerKey berbeda per versi.
Kelebihan
Kekurangan
Cocok untuk
Histori lengkap, mendukung audit, analisis perubahan lebih baik
Ukuran tabel bertambah, ETL lebih kompleks, query lebih rumit
Histori sangat penting, audit diperlukan, analisis tren jangka panjang
SCD Type 3 — Add New Column
Cara kerja: Ketika terjadi perubahan, nilai lama disimpan di kolom histori (*_Lama), sedangkan nilai baru disimpan di kolom saat ini (*_Sekarang). Hanya menyimpan 1 langkah perubahan terakhir.
Contoh:
Sebelum:
CustomerID
Nama
Kota Lama
Kota Sekarang
C001
Budi
(null)
Jakarta
Setelah perubahan (pindah ke Bandung):
CustomerID
Nama
Kota Lama
Kota Sekarang
C001
Budi
Jakarta
Bandung
Jika berubah lagi (ke Surabaya):
CustomerID
Nama
Kota Lama
Kota Sekarang
C001
Budi
Bandung
Surabaya
Perhatikan: histori Jakarta hilang, karena Type 3 hanya menyimpan perubahan terakhir.
Kelebihan
Kekurangan
Cocok untuk
Mudah diterapkan, menyimpan perubahan terakhir
Histori terbatas, tidak cocok untuk analisis jangka panjang
Perubahan terakhir cukup penting, histori lengkap tidak diperlukan
Perbandingan Ketiga Tipe
Aspek
Type 1 (Overwrite)
Type 2 (New Record)
Type 3 (New Column)
Penyimpanan histori
Tidak ada
Lengkap, semua versi tersimpan
Terbatas, hanya 1 perubahan terakhir
Kompleksitas ETL
Rendah
Tinggi
Sedang
Kebutuhan storage
Kecil
Besar (bertambah tiap perubahan)
Sedang (tetap, hanya nambah kolom)
Kemudahan query
Mudah
Perlu filter Current = Y atau rentang tanggal
Mudah, tinggal baca 2 kolom
Kemampuan analisis historis
Tidak ada
Sangat baik (bisa analisis tren)
Terbatas (hanya 1 langkah ke belakang)
Kesesuaian untuk kasus retail
Data non-kritis (email, no telp)
Atribut penting untuk analisis bisnis (kota, status member)
Atribut yang cukup tahu "sebelum vs sesudah" saja
Tugas Analisis: Studi Kasus Pelanggan C001
Data Kasus
Tahun
Perubahan
2023 (Data Awal)
CustomerID: C001, Nama: Budi, Kota: Jakarta, Status Member: Silver
2024
Pelanggan berpindah domisili dari Jakarta → Bandung
2025
Status keanggotaan berubah dari Silver → Gold
1. Identifikasi Perubahan Data
Ada dua atribut pada tabel dimensi pelanggan yang mengalami perubahan dari tahun 2023 hingga 2025:
Kota — berubah dari Jakarta (2023) menjadi Bandung (2024). Ini adalah atribut alamat/domisili yang bisa berubah karena pelanggan pindah tempat tinggal.
Status Member — berubah dari Silver (2023/2024) menjadi Gold (2025). Ini adalah atribut tingkat keanggotaan yang berubah karena pencapaian tertentu (misalnya total belanja atau poin loyalitas).
2. Analisis Kebutuhan Bisnis
a. Apakah histori perubahan kota pelanggan perlu disimpan?
Tergantung kebutuhan analisis. Jika perusahaan ingin menganalisis pola migrasi pelanggan antar wilayah (misalnya untuk menentukan lokasi cabang baru atau strategi pemasaran regional), maka histori kota perlu disimpan. Namun jika kota hanya dipakai untuk keperluan pengiriman/kontak saat ini, histori tidak terlalu penting.
b. Apakah histori perubahan status member perlu disimpan?Perlu. Status member berkaitan langsung dengan program loyalitas dan strategi retensi pelanggan. Perusahaan perlu tahu kapan pelanggan naik level (Silver → Gold) untuk mengukur efektivitas program loyalitas, menghitung waktu rata-rata kenaikan tingkat, dan mengevaluasi dampaknya terhadap penjualan.
c. Dampak jika histori perubahan tidak disimpan:
Perusahaan kehilangan kemampuan untuk menganalisis tren perpindahan domisili maupun kenaikan tingkat keanggotaan dari waktu ke waktu.
Laporan historis (misalnya "berapa lama rata-rata pelanggan menjadi Silver sebelum naik ke Gold") menjadi tidak mungkin dibuat.
Data pada laporan lama bisa jadi tidak konsisten dengan kondisi saat transaksi terjadi (misalnya transaksi tahun 2023 seharusnya dikaitkan dengan status Silver dan kota Jakarta, bukan kondisi terbaru).
Proses audit dan evaluasi program bisnis menjadi lebih sulit dilakukan.
3. Implementasi SCD Type 1 (untuk kasus ini, sebagai pembanding)
a. Struktur tabel dimensi setelah perubahan (SCD Type 1):
DimPelanggan (
CustomerID VARCHAR,
Nama VARCHAR,
Kota VARCHAR,
StatusMember VARCHAR
)
b. Kondisi sebelum dan sesudah perubahan:
Sebelum (2023):
CustomerID
Nama
Kota
StatusMember
C001
Budi
Jakarta
Silver
Sesudah (2025, dua perubahan sekaligus ditimpa):
CustomerID
Nama
Kota
StatusMember
C001
Budi
Bandung
Gold
Data Jakarta dan status Silver langsung hilang, tertimpa oleh data terbaru.
c. Kelebihan dan kekurangan SCD Type 1 pada kasus ini:
Kelebihan: struktur tabel sangat sederhana, mudah di-query, ukuran tabel tetap kecil.
Kekurangan: perusahaan sama sekali tidak bisa melihat bahwa Budi pernah tinggal di Jakarta atau pernah berstatus Silver. Ini merugikan untuk analisis migrasi pelanggan maupun evaluasi program loyalitas, sehingga kurang cocok dipakai untuk kedua atribut ini.
4. Implementasi SCD Type 2
a. Desain tabel dimensi menggunakan SCD Type 2:
DimPelanggan (
CustomerKey INT PRIMARY KEY, -- surrogate key
CustomerID VARCHAR,
Nama VARCHAR,
Kota VARCHAR,
StatusMember VARCHAR,
StartDate DATE,
EndDate DATE,
Current CHAR(1) -- 'Y' / 'N'
)
b. Atribut yang diperlukan:
Surrogate Key (CustomerKey) — id unik per baris/versi, karena satu CustomerID bisa punya beberapa baris.
StartDate — tanggal mulai berlakunya versi data tersebut.
EndDate — tanggal berakhirnya versi data tersebut (9999-12-31 jika masih berlaku).
Current Flag — penanda apakah baris tersebut adalah versi terbaru (Y) atau sudah tidak berlaku (N).
c. Gambaran seluruh histori perubahan pelanggan C001 dalam satu tabel:
CustomerKey
CustomerID
Nama
Kota
StatusMember
StartDate
EndDate
Current
1
C001
Budi
Jakarta
Silver
2023-01-01
2023-12-31
N
2
C001
Budi
Bandung
Silver
2024-01-01
2024-12-31
N
3
C001
Budi
Bandung
Gold
2025-01-01
9999-12-31
Y
Dengan struktur ini, seluruh perjalanan pelanggan — dari Jakarta/Silver, pindah ke Bandung, hingga naik status ke Gold — tercatat lengkap dan bisa ditelusuri per periode waktu.
d. Kelebihan dan kekurangan SCD Type 2 pada kasus ini:
Kelebihan: histori lengkap tersimpan untuk kedua atribut (kota dan status member), mendukung analisis tren migrasi maupun evaluasi program loyalitas dari waktu ke waktu, serta mendukung kebutuhan audit.
Kekurangan: ukuran tabel bertambah setiap kali ada perubahan (di kasus ini menjadi 3 baris untuk 1 pelanggan), query menjadi lebih kompleks karena harus memfilter Current = 'Y' atau menyaring berdasarkan rentang tanggal, dan proses ETL menjadi lebih rumit dibanding Type 1.
b. Bagaimana data lama dan data baru disimpan dalam satu tabel:
Setelah perubahan kota (2024):
CustomerID
Nama
KotaLama
KotaSekarang
StatusLama
StatusSekarang
C001
Budi
Jakarta
Bandung
(null)
Silver
Setelah perubahan status member (2025) — kolom kota tidak berubah lagi, tapi status ditimpa ke kolom histori:
CustomerID
Nama
KotaLama
KotaSekarang
StatusLama
StatusSekarang
C001
Budi
Jakarta
Bandung
Silver
Gold
Perhatikan: karena Type 3 hanya menyimpan 1 langkah perubahan per atribut, informasi bahwa kota "Jakarta" itu terjadi di 2023 (bukan langsung sebelum jadi Gold) tidak tercermin secara eksplisit — hanya "lama vs sekarang" saja, tanpa tanggal.
c. Kelebihan dan kekurangan SCD Type 3 pada kasus ini:
Kelebihan: struktur tabel tetap ringkas (tidak bertambah baris), mudah dibaca untuk melihat kondisi "sebelum vs sesudah" langsung dalam satu baris.
Kekurangan: hanya menyimpan 1 langkah perubahan terakhir. Jika status member berubah lagi di masa depan (misalnya Gold → Platinum), maka histori Silver akan hilang. Untuk kasus pelanggan C001 yang mengalami 2 kali perubahan berbeda (kota lalu status), Type 3 juga tidak bisa mengaitkan kapan tepatnya masing-masing perubahan terjadi, sehingga kurang ideal untuk analisis tren jangka panjang.
6. Perbandingan SCD untuk Kasus Ini
Aspek
Type 1
Type 2
Type 3
Penyimpanan histori
Tidak ada
Lengkap (3 versi tercatat)
Hanya 1 langkah terakhir
Kompleksitas ETL
Rendah
Tinggi (perlu update EndDate & Current, insert baris baru)
Sedang (update kolom lama/baru)
Kebutuhan storage
Paling kecil
Bertambah seiring jumlah perubahan
Tetap, hanya nambah kolom
Kemudahan query
Paling mudah
Perlu filter Current/tanggal
Mudah, cukup baca 2 kolom
Kemampuan analisis historis
Tidak bisa
Bisa analisis tren lengkap per periode
Terbatas, hanya bisa lihat "terakhir vs sebelumnya"
Kesesuaian untuk kasus retail (loyalitas & migrasi pelanggan)
Kurang cocok
Paling cocok
Cukup cocok untuk kebutuhan sederhana
7. Rekomendasi
Untuk atribut Kota:
Direkomendasikan menggunakan SCD Type 2. Alasan: histori domisili pelanggan bermanfaat untuk analisis pola migrasi dan segmentasi wilayah dari waktu ke waktu, sehingga perusahaan bisa melihat kapan pelanggan pindah dan menganalisis tren perpindahan secara akurat berdasarkan periode. Jika kebutuhan bisnis hanya sekadar tahu domisili sebelumnya tanpa perlu tanggal pastinya, Type 3 juga masih bisa dipertimbangkan sebagai opsi yang lebih ringan.
Untuk atribut Status Member:
Direkomendasikan menggunakan SCD Type 2. Alasan: status keanggotaan sangat erat kaitannya dengan program loyalitas dan strategi retensi pelanggan. Perusahaan perlu mengetahui kapan pelanggan naik/turun level secara historis, lengkap dengan tanggal, agar bisa mengevaluasi efektivitas program loyalitas, menghitung rata-rata waktu kenaikan level, dan mengaitkan setiap transaksi historis dengan status member yang berlaku saat itu — sesuatu yang tidak bisa dilakukan dengan Type 1 (histori hilang) maupun Type 3 (hanya 1 langkah terakhir).
Ringkasan
Tipe SCD
Prinsip
Kapan Dipakai
Type 1
Overwrite, histori hilang
Data tidak penting historinya, hanya kondisi terkini
Type 2
Tambah baris baru, histori lengkap
Histori sangat penting, perlu audit & analisis tren
Type 3
Tambah kolom histori, hanya 1 langkah terakhir
Cukup tahu perubahan terakhir, histori lengkap tidak diperlukan
