Transcript Document

Pemodelan Data
Dimensional dengan
OLAP
7/18/2015
HAL : 1
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).
7/18/2015
HAL : 2
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).
7/18/2015
HAL : 3
Multidimensional Representation
Penjualan
Finance DB
W
i
l
a
y
a
h
Produk
Account DB
Ad Hoc
Product DB
Data Cube Representation
7/18/2015
HAL : 4
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
...
...
...
...
...
Tabel fakta
Info Waktu
7/18/2015
HAL : 5
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/18/2015
HAL : 6
Dimension Hierarchy
Dimensi Dealer
Dimensi Produk
Total
Wilayah
Total
Pabrik
Distrik
Merk
Agen
Produk
7/18/2015
HAL : 7
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
tgl
1
1
1
1
2
2
jumlah
12
11
50
8
44
4
tgl 2
tgl 1
p1
p2 s1
p1
12
p2
11
s1
44
s2
4
s2
s3
s3
50
8
7/18/2015
HAL : 8
Operations on Dimensional Models

Operasi analisa
◦ Slice & dice
◦ Role up & drill down
◦ Pivot
Rabu
Produk
850
323
714
Selasa
001
Senin
002
Pelanggan
Penjualan $
003
7/18/2015
HAL : 9
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
7/18/2015
HAL : 10
Slicing
tgl 2
tgl 1
p1
p2 s1
p1
12
p2
11
s1
44
s2
4
s2
s3
s3
50
8
WAKTU = tanggal 1
p1
p2
s1
12
11
s2
s3
50
8
7/18/2015
HAL : 11
Slice
&
Pivot
Produk
Toko t1
Toko t2
Electronics
Toys
Clothing
Cosmetics
Electronics
Toys
Clothing
Cosmetics
Produk
Toko t1
Toko t2
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
7/18/2015
HAL : 12
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
7/18/2015
HAL : 13
Roll-up vs Drill-down
Contoh: penghitungan total
tgl 2
tgl 1
p1
p2 s1
p1
12
p2
11
s1
44
s2
4
s2
s3
...
s3
50
8
sum
p1
p2
s1
56
11
s2
4
8
rollup
drill-down
s1
67
s2
12
s3
50
s3
50
129
p1
p2
sum
110
19
7/18/2015
HAL : 14
Hierarchy-based Aggregation
tgl 2
tgl 1
p1
p2 s1
p1
12
p2
11
s1
44
s2
4
s2
s3
s3
50
8
toko
wilayah
negara
p1
p2
wil A
56
11
wil B
54
8
(toko s1 di wilayah A;
toko s2, s3 di wilayah B)
7/18/2015
HAL : 15
Cubes with Aggregate Data

Data agregat disimpan (dihitung dan ditambahkan) dalam tabel fakta, untuk mening-katkan
kinerja query.
p1
p2
*
s1
s1
56
11
67
s2
44
4
s2
44
s3
4
50
*
tgl 2
tgl 1
p1
p2
*
p1
p2
s1
*
12
11
23
8
8
50
s2
4
8
12
s3
*
62
19
81
s3
50
*50
48
48
*
110
19
129
penjualan(*,p2,*)
7/18/2015
HAL : 16
Other Operations
Operasi kalkulasi:


Ranking
◦ Misal: top 20% produk dengan penjualan tertinggi.
Fungsi waktu
◦ Penghitungan rata-rata per hari.
7/18/2015
HAL : 17
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
Tier 1
Multidimensional
Viewer
Multidimensional
data
Tier 3
SQL-Reach
Through
Tier 2
Report
Viewer
SQL-Read
7/18/2015
HAL : 18
Storage Technology
OLAP Technology:
 ROLAP
 MOLAP
 HOLAP

Bagaimana memilih?
7/18/2015
HAL : 19
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)
7/18/2015
HAL : 20
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.
7/18/2015
HAL : 21
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
storeId
s1
s1
s3
s2
s1
s2
date
1
1
1
1
2
2
amt
12
11
50
8
44
4
81
7/18/2015
HAL : 22
OLAP Operations in RDBM (2)

sale
Total amounts menurut date dalam SQL:
SELECT date, sum(amt) FROM SALE GROUP BY
date
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
date
1
2
7/18/2015
sum
81
48
HAL : 23
OLAP Operations in RDBM (3)

sale
Total amounts menurut date dan product-ID
dalam SQL:
SELECT prodId, date, sum(amt) FROM SALE
GROUP BY date, prodId
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
7/18/2015
HAL : 24
Skema Bintang dan Keping Salju
7/18/2015
HAL : 25
Star Schema
7/18/2015
HAL : 26
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.
7/18/2015
HAL : 27
7/18/2015
HAL : 28
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.
7/18/2015
HAL : 29
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).
7/18/2015
HAL : 30
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.
7/18/2015
HAL : 31
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)
7/18/2015
HAL : 32
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.
7/18/2015
HAL : 33
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 queryquery yang melibatkan agregasi (hitungan
total).
Kelemahan:
◦ Rumit dalam pemeliharaan dan metadata-nya
◦ Jumlah tabel dalam database membengkak.
7/18/2015
HAL : 34
Multiple Aggregate Tables
Kode Produk Kode Waktu Kode Agen
Nilai
Jumlah
Info Agen
...
Info Produk
...
...
Distrik
...
Kota
Produk Waktu Agen Nilai Jml
Produk Waktu Agen Nilai Jml
...
...
...
...
...
... ...
...
...
Bulanan
Info Waktu
...
Tabel-tabel
fakta agregat
...
Kuartalan
Produk Waktu Agen Nilai Jml
Tahunan
Produk Waktu Agen Nilai Jml
...
...
. . .Produk
. . .Waktu
. . . Agen Nilai Jml
...
...
...
... ...
...
...
...
...
...
7/18/2015
HAL : 35
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.
7/18/2015
HAL : 36
Conformed Dimensions
Subject 1
Subject 2
7/18/2015
HAL : 37
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.
7/18/2015
HAL : 38
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
7/18/2015
HAL : 39
HOLAP

Gabungan ROLAP dengan MOLAP
◦ Menyimpan data rinci dengan RDBMS dan data
agregat dengan MDBMS
◦ Akses data secara MOLAP.
7/18/2015
HAL : 40
ROLAP,
MOLAP or
HOLAP
?
7/18/2015
HAL : 41
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.
7/18/2015
HAL : 42
Use MOLAP when ...



Data yang tersedia berupa data agregat
Hanya membutuhkan data agregat
Contoh:
◦ Analisa dan penyusunan anggaran oleh bagian
keuangan
◦ Analisa penjualan
◦ Dsb.
7/18/2015
HAL : 43
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.
7/18/2015
HAL : 44
Teknik-teknik ROLAP
7/18/2015
HAL : 45
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

7/18/2015
HAL : 46
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.
7/18/2015
HAL : 47
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
7/18/2015
HAL : 48
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)
7/18/2015
HAL : 49
Type 1 Changes

Tipe 1: Koreksi Kesalahan

Karakteristik:

Implementasi:
◦ 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.
◦ Nilai lama dalam tabel dimensi dibuang dan
digantikan dengan nilai baru.
◦ Tidak ada perubahan lain di tabel fakta dan
dimensi.
7/18/2015
HAL : 50
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
7/18/2015
HAL : 51
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) ...
7/18/2015
HAL : 52
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)
7/18/2015
HAL : 53
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
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

7/18/2015
HAL : 54
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.
7/18/2015
HAL : 55
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
7/18/2015
HAL : 56
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 atributatribut yang sering berubah ke tabel dimensi
baru.
◦ Tambahkan kunci primer tabel dimensi baru
tersebut ke tabel fakta sebagai kunci eksternal.
7/18/2015
HAL : 57
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
sesudah
PERILAKU
Key Perilaku
Key Pelanggan
Rating Kredit
Status Nikah
Range Pembelian
Tingkat Penghasilan
Kepemilikan Rumah

statis
PENJUALAN
Key Pelanggan
Key Perilaku

Metrics
banyak berubah
7/18/2015
HAL : 58
Slowly-Changing Dimension Policy



Tidak semua perubahan pada nilai atribut
harus/dapat diperlakukan sebagai perubahan
tipe 2 atau tipe 3.
Spesifikasi kebutuhan menentukan atributatribut 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.
7/18/2015
HAL : 59