jbptunikompp-gdl-mirakanias-25645-20-pt14-pem-p (1).ppt

UNIVERSITAS
BUDI LUHUR
FAKULTAS
TEKNOLOGI INFORMASI
www.bl.ac.id
HAL : 1
Pemodelan Data
Dimensional
dengan OLAP
Universitas Budi Luhur
Pertemuan ke-14

PERTEMUAN 14 – KASUS DATA WAREHOUSE DATABASE
HAL : 2
GASAL 2008/2009 PERANCANGAN BASIS DATA (KP130)
• 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).
DW-based Decision Support System

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).
OnLine Analysis Processing (OLAP)

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

HAL : 5
“Penjualan per jenis produk dalam 6 bulan terakhir”
“Penjualan per dealer antara tahun 1990 dan 1995”
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

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

HAL : 7
Dimensi Dealer Dimensi Produk
Distrik
Wilayah
Total
Merk
Pabrik
Total
Agen Produk
Dimension Hierarchy

HAL : 8
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

HAL : 9
• Operasi analisa
– Slice & dice
– Role up & drill down
– Pivot
Pelanggan
Senin
Rabu
Selasa
Produk
850
001
002
003
Penjualan $
323 714
Operations on Dimensional Models

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
Slice, Dice & Pivot

HAL : 11
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

HAL : 12
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

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
Roll-up & Drill-down

HAL : 14
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

HAL : 15
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

HAL : 16
*
• Data agregat disimpan (dihitung dan ditam-bahkan)
dalam tabel fakta, untuk mening-katkan kinerja query.
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,*)

HAL : 17
Operasi kalkulasi:
• Ranking
– Misal: top 20% produk dengan penjualan
tertinggi.
• Fungsi waktu
– Penghitungan rata-rata per hari.
Other Operations

HAL : 18
• Arsitektur 3-lapis (3-tier)
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)

HAL : 19
OLAP Technology:
• ROLAP
• MOLAP
• HOLAP
• Bagaimana memilih?
Storage Technology

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

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

HAL : 22
 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
p1 s3 1 50
p2 s2 1 8
p1 s1 2 44
p1 s2 2 4
81
OLAP Operations in RDBM

HAL : 23
 Total amounts menurut date dalam SQL:
SELECT date, sum(amt) FROM SALE GROUP BY
date
result date sum
1 81
2 48
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)

HAL : 24
 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
drill-down
rollup
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)

HAL : 25
Implementasi ROLAP
Skema Bintang dan Keping Salju

HAL : 26
Star Schema

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.
Classical Star Schema

HAL : 28
Star
Schema
Example

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.
Problems with Aggregates

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).
Problems with Aggregates (2)

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.
From Star to Snowflake

HAL : 32
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)

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.
Snowflake Schema (2)

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.
Snowflake Schema (3)

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

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.
Multiple DW Subjects

HAL : 37
Conformed Dimensions
Subject 1 Subject 2

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

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
MOLAP (2)

HAL : 40
• Gabungan ROLAP dengan MOLAP
– Menyimpan data rinci dengan RDBMS dan
data agregat dengan MDBMS
– Akses data secara MOLAP.
HOLAP

HAL : 41
ROLAP,
MOLAP or
HOLAP
?

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.
Use ROLAP when ...

HAL : 43
• Data yang tersedia berupa data agregat
• Hanya membutuhkan data agregat
• Contoh:
– Analisa dan penyusunan anggaran oleh bagian
keuangan
– Analisa penjualan
– Dsb.
Use MOLAP when ...

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.
Use HOLAP when ...

HAL : 45
Teknik-teknik ROLAP

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
Dealing with Dimension Changes

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.
Surrogate Key

HAL : 48
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

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)
Slowly Changing Dimensions

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.
Type 1 Changes

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

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

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)
Type 2 Changes (2)

HAL : 54
Key Pelanggan: 100237
Kode Pelanggan: N203077
Nama: Nia Daniati
Status Nikah: tidak
Kode Pos: Jakarta 12345

Nama: Nia Darmawan
Status Nikah: menikah
Berlaku Mulai: 10-07-2002
Berlaku Sampai: 04-01-2003
Nama: Nia Darmawan
Status Nikah: menikah
Alamat: Jl. Barito 26
Berlaku Mulai: 05-01-2003

1
2
Perubahan status record
dimensi PELANGGAN:
3 periode historis untuk
pelanggan yang sama

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.
Type 3 Changes

HAL : 56
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

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.
Rapidly Changing Dimensions

HAL : 58
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

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.
Slowly-Changing Dimension Policy

jbptunikompp-gdl-mirakanias-25645-20-pt14-pem-p (1).ppt

Recommended

Recommended

More Related Content

Similar to jbptunikompp-gdl-mirakanias-25645-20-pt14-pem-p (1).ppt

Similar to jbptunikompp-gdl-mirakanias-25645-20-pt14-pem-p (1).ppt (16)

Recently uploaded

Recently uploaded (20)

jbptunikompp-gdl-mirakanias-25645-20-pt14-pem-p (1).ppt