Desain Data Warehouse (I): Dimensional Modelling Yudi Agusta, PhD Data Warehouse and Data Mining, Lecture 3 Copyright © Yudi Agusta, PhD 2006
Lecture’s Structure
Merancang Sebuah Data Warehouse Skema Perancangan Database Skema Perancangan Data Warehouse OLAP vs ROLAP Rancangan Berdimensi Tahapan dan Proses Perancangan Contoh kasus: Retail
Mendisain Sebuah Data Warehouse
Mendisain database untuk data warehouse adalah problem utama dalam mendisain data warehouse Ada dua pendekatan utama dalam perancangan data warehouse
Pemodelan dan normalisasi entity relationship (ER) Pemodelan berdimensi
1
Schema Desain Untuk Database
Schema Entity Relationship (Simple)
Perancangan Database Menggunakan Pendekatan E-R yang Tradisional
Entities and Relationships Aturan Normalisasi
Umumnya 3NF Menjaga integritas database dengan menghindari anomalies Setiap hal logical direpresentasikan cuman sekali
Pemikiran yang berbeda antara logical dan physical
2
Contoh Normalisasi Sebuah perusahaan manufaktur membuat produk dari beberapa komponen. Setiap produk mempunyai suatu nomor produk yang tersendiri, nama dan waktu perakitan. Semua komponen mempunyai nomor komponen tersendiri, diskripsi, kode supplier dan harga.
Permasalahan
Sejumlah atribute yang bukan merupakan atribute kunci tidak tergantung pada primary key Ketergantungan berarti bahwa kita data mengerjakan satu atribute sekali kalau yang lain sudah dimasukkan
ProductCode Æ Name ProductCode Æ Time ComponentCode Æ Diskripsi ComponentCode Æ Supplier ComponentCode Æ Cost ComponentCode, Product Code Æ Quantity
Database Yang Sudah Dinormalisasikan
Product (ProductCode, Name, Time) Parts (ProductCode, ComponentCode, Qty) Component (ComponentCode, Description, Supplier, Cost) Parts
Product
Component
3
Isi Database Ternormalisasi
Rancangan Database Tradisional
Tables dalam jumlah yang besar
Umumnya digunakan
Oracle Financials 1.800, SAP 7 sampai 8.000 Terasa natural sekali kamu bisa menggunakannya
Penelitian menunjukkan bahwa mereka tidak mudah dimengerti oleh profesional IT
Khususnya konsep-konsep seperti abstraction, generalisation, sub-types dll
Model Berdimensi Terhubung (Star-Join Schema)
4
Star Schema (Dengan Atribut)
Snowflake Schema
Pendekatan Pada Perancangan Data Warehouse
Ada banyak sekali pendekatan yang diajukan oleh para pengembang dan konsultan mengenai data warehouse Ini harus diperhatikan sebagai satu kesatuan proses perkembangan data warehouse sepenuhnya
5
Apa sebenarnya multi-dimensional database?
Suatu pendekatan pada perancangan database yang dapat memberikan database yang mudah dimengerti dan mudah dinavigasikan
Tujuannya adalah untuk mendorong pengertian, eksplorasi dan pembelajaran
Setiap nomor mempunyai satu set atribut yang terasosiasikan
Apa yang direpresentasikan, kapan dibuat, darimana datangnya, produk apa saja yang terkait, promosi apa, dll
Multi-Dimensionality
Biasanya mengenai ruangan informasi dalam bentuk cubes atau hyper cubes atau n-cubes Setiap atribut terkait dengan setiap nomor merepresentasikan suatu dimensi
Ukuran, waktu, tempat, produk, lokasi dll
Tampilan database yang dihasilkan mudah untuk dinavigasikan dan dipindahkan
Slice and dice Report template
OLAP and ROLAP
OLAP – On-Line Analytical Processing
Codd 1993 Biasanya pendekatan untuk mendisain DSS yang berfokus pada data
Sejumlah OLAP tools mempunyai cara mereka sendiri untuk menyimpan data (MDDB) Beberapa memperlihatkan seperti data itu sendiri berada di dalam cubes, tetapi sebenarnya merupakan query dari sebuah relational database (ROLAP) Melakukan hal yang berbeda – dijelaskan belakangan
6
Dimensi
Star schema mungkin (umumnya) mempunyai 10-15 dimensi Tampilan yang dimiliki pengguna mengenai database mencakup 6-7 dimensi Sistem umum (seperti EIS) mungkin mempunyai 20 tampilan yang berbeda dan 45 fact tables yang mempunyai dasar yang berbeda Table dimensi dapat mempunyai banyak fact di dalamnya
Pendekatan Kimball (1996) terhadap disain berdimensi
Pendekatan Kimball (1996)
Kelebihan
Pemodelan berdimensi, mudah untuk dimengerti Performance fisiknya sangat mengesankan
Kekurangan
Integrasi Mapping dari pemodelan berdimensi ke sistem yang sudah ada
7
Tahapan dalam Proses Disain 1. 2. 3. 4.
Memilih proses bisnis Memilih inti dari fact table Memilih dimensi Memilih fact yang terukur (umumnya numeric, additive quantities) 5. Melengkapi tabel dimensi
(Kimball, 1996)
Tahapan Ekstra Dalam Proses Disain
Menentukan strategi untuk mengubah dimensi secara pelan-pelan Membuat agregat dan komponen penyimpanan fisik lainnya Menentukan waktu histori dari database Menentukan tingkat keperluan data yang mana yang perlu diekstrak dan diload ke dalam data warehouse
KimbalL (1996)
Contoh: Usaha Retail
Perusahaan grocery besar dengan perkiraan 500 outlet Setiap outlet mempunyai sekitar 60000 produk dalam tampilannya SKU – Stock Keeping Unit UPC – Universal Product Code
8
Usaha Retail
Perlu untuk memaksimalkan keuntungan dan tetap menjaga stok agar tetap ada Keputusan penting untuk masalah harga dan promosi Tipe promosi adalah:
Discount harga sementara Reklame surat kabar Tampilan lemari dan lorong Kupon
Usaha Retail
Memilih Proses Bisnis
Memilih inti dari tabel fact
Memilih dimensi
Pergerakan barang harian SKU by store by promotion by day Waktu, Produk, Toko dan Promosi
Dimensi Usaha Retail
9
Usaha Retail
Memilih fact terukur
Usaha Retail: Dimensi
Lengkapi tabel dimensi
Usaha Retail: Dimensi Produk
10
Usaha Retail: Dimensi Toko
Usaha Retail: Dimensi Promosi
Catatan Untuk Masalah Hierarchies
Kimball sedikit salah menyampaikan sedikit dalam hal ini
Hirarki yang jelas tidak diperlukan untuk mendukung drilling down
Detailnya sering harus disimpan secara eksplisit Hirarki di dalam dimensi sangat penting
Memungkinkan untuk melakukan drill up dan drill down Contoh: day, week, month, quarter, year Hirarki independen yang berkelipatan
11