Pemodelan Data Dimensional dengan OLAP

1

• Pemodelan Data Dimensional dengan OLAP

2
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).

3
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).

4
Multidimensional Representation
Penjualan
Waktu
Produk
Wilayah
Data Cube Representation
5
Dimensional Data Model

• Penjualan per jenis produk dalam 6 bulan
  terakhir
• Penjualan per dealer antara tahun 1990 dan 1995

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 fakta
Tabel-tabel dimensi
Info Waktu
6
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.

7
Dimension Hierarchy
Dimensi Dealer
Dimensi Produk
Total
Total
Wilayah
Pabrik
Distrik
Merk
Agen
Produk
8
3-D Data Cubes
Kubus 3-dimensi
Tabel fakta
sale
prod-Id
store-Id
tgl
jumlah
p1
s1
1
12
p2
s1
1
11
tgl 2
p1
s3
1
50
p2
s2
1
8
tgl 1
p1
s1
2
44
p1
s2
2
4
9
Operations on Dimensional Models

• Operasi analisa
• Slice dice
• Role up drill down
• Pivot

Rabu
Hari
Selasa
Senin
Pelanggan
10
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

11
Slicing
tgl 2
tgl 1
WAKTU tanggal 1
12
Slice Pivot
Penjualan
(juta )
Waktu
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
Penjualan
(juta )
Tgl-1
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
13
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

14
Roll-up vs Drill-down
Contoh penghitungan total
tgl 2
. . .
tgl 1
129
15
Hierarchy-based Aggregation
toko
wilayah
negara
(toko s1 di wilayah A toko s2, s3 di wilayah B)
16
Cubes with Aggregate Data

• Data agregat disimpan (dihitung dan ditam-bahkan)
  dalam tabel fakta, untuk mening-katkan kinerja
  query.

tgl 2
penjualan(,p2,)
tgl 1
17
Other Operations

• Operasi kalkulasi
• Ranking
• Misal top 20 produk dengan penjualan tertinggi.
• Fungsi waktu
• Penghitungan rata-rata per hari.

18
OLAP Application Architecture

• Arsitektur 3-lapis (3-tier)

Client
MDBMS Server
RDBMS Server
(OLAP Server)
Multi-dimensional access
Warehouse data
Multi-dimensionaldata
Meta data
Tier 3
Derived data
SQL-Reach Through
Tier 1
Tier 2
19
Storage Technology

• OLAP Technology
• ROLAP
• MOLAP
• HOLAP
• Bagaimana memilih?

20
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)

21
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.

22
OLAP Operations in RDBM

• Roll-up
• Total amounts untuk day 1 dalam SQL
• SELECT sum(amt) FROM SALE WHERE date 1

sale
prodId
storeId
date
amt
p1
s1
1
12
p2
s1
1
11
81
p1
s3
1
50
p2
s2
1
8
p1
s1
2
44
p1
s2
2
4
23
OLAP Operations in RDBM (2)

• Total amounts menurut date dalam SQL
• SELECT date, sum(amt) FROM SALE GROUP BY date

24
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

result
prodId
date
sum
p1
1
62
p2
1
19
p1
2
48
rollup
drill-down
25
Implementasi ROLAP

• Skema Bintang dan Keping Salju

26
Star Schema
27
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 merepresentasi-kan
  hirarki dimensi, metadata tidak rumit, low
  maintenance, jumlah operasi join minimal.

28
Star Schema Example
29
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.

30
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).

31
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.

32
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
Tabel Fakta Kota
Tabel Fakta Distrik
Kode_Kota KEY_PRODUK KEY_PERIODE
Kode_Distrik KEY_PRODUK KEY_PERIODE
KODE_AGEN
KEY_PRODUK
Nilai Jumlah Biaya
KEY_PERIODE
Nilai Jumlah Biaya
Nilai Jumlah Biaya
tabel agregat (rangkuman)
33
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
  ter-denormalisasi untuk query-query kompleks dan
  ad-hoc.

34
Snowflake Schema (3)

• 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.

35
Multiple Aggregate Tables
Distrik
Kota
Tabel-tabel fakta agregat
Bulanan
Kuartalan
Tahunan
36
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.

37
Conformed Dimensions
Subject 1
Subject 2
38
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.

39
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

40
HOLAP

• Gabungan ROLAP dengan MOLAP
• Menyimpan data rinci dengan RDBMS dan data
  agregat dengan MDBMS
• Akses data secara MOLAP.

41

• ROLAP,
• MOLAP or
• HOLAP

?
42
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.

43
Use MOLAP when ...

• Data yang tersedia berupa data agregat
• Hanya membutuhkan data agregat
• Contoh
• Analisa dan penyusunan anggaran oleh bagian
  keuangan
• Analisa penjualan
• Dsb.

44
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.

45

• Teknik-teknik ROLAP

46
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

47
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.

48
Surrogate Key Example
key pengganti
key asli
KEY_PEG
010234
010456
010478
020125
020136
020167
030224
030350
49
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)

50
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.

51
Type 1 Change Example
Dimensi PELANGGAN
Koreksi kesalahan nama
52
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) ...

53
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)

54
Type 2 Change Example
1
2
Perubahan status record dimensi PELANGGAN 3
periode historis untuk pelanggan yang sama
55
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.

56
Type 3 Change Example
Dimensi Salesman
Sales Key 101724 Sales Code AM203 Nama Arman
Munawar Wilayah Lama Jakarta Pusat Wilayah
Jakarta Selatan Daerah DKI Jakarta ?
Nilai atribut ganda/paralel
57
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.

58
Partitioned Dimension
statis
PELANGGAN Key Pelanggan Nama Alamat Kode
Pos Telp ?
PELANGGAN Key Pelanggan Nama Alamat Kode
Pos Telp ?
PENJUALAN Key Pelanggan Key Perilaku ? Metrics
PENJUALAN Key Pelanggan ? Metrics
sesudah
sebelum
PERILAKU Key Perilaku Key Pelanggan Rating
Kredit Status Nikah Range Pembelian Tingkat
Penghasilan Kepemilikan Rumah ?
banyak berubah
tabel fakta
59
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.