Desain Data Warehouse (Dimensional Modelling)

Presentasi berjudul: "Desain Data Warehouse (Dimensional Modelling)"— Transcript presentasi:

1 Desain Data Warehouse (Dimensional Modelling)

2 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

3 Perancangan Database Menggunakan Pendekatan E-R yang Tradisional
Entities and Relationships Aturan Normalisasi (Umumnya 3NF) Menjaga integritas database dengan menghindari anomali (proses pada basis data yang memberikan efek samping yang tidak diharapkan, misalnya menyebabkan ketidak konsistenan data atau membuat sesuatu data menjadi hilang ketika data lain dihapus)

4 Bentuk Normal Pertama (1NF)
Definisi bentuk normal pertama adalah sbb: Suatu relasi dikatakan dalam bentuk normal pertama jika dan hanya jika setiap atribut bernilai tunggal untuk setiap baris.

5 Bentuk Normal Kedua (2NF)
Bentuk normal kedua didefinisikan berdasarkan dependensi Fungsional Suatu relasi berada dalam bentuk normal kedua(2NF) jika dan hanya jika:Telah melalui bentuk normal pertama Semua atribut bukan kunci memiliki ketergantungan sepenuhnya terhadap kunci primer

6 Ketergantungan fungsi sepenuhnya
Suatu atribut Y mempunyai ketergantungan fungsi penuh terhadap atribut X, jikaY mempunyai ketergantungan fungsi terhadap X Y tidak memiliki dependensi terhadap bagian dari X Definisi diatas dituangkan dalam bentuk notasi X  Y Contoh: Nilai : (NPM, Kd-Mt-Kul, Nilai) {NPM, Kd-Mt-Kul}  Nilai NPM  Nilai (Tidak memiliki dependency) Kd-Mt-Kul  Nilai (Tidak memiliki dependency)

7 Berdasarkan diagram dependensi fungsional diatas, pendekomposisian akan menghasilkan dua buah relasi, yang misalnya disebut dengan PEGAWAI dan HISTORY PEGAWAI seperti berikut ini.

8 Bentuk Normal ketiga (3NF)
Definisi Bentuk normal ketiga: Suatu relasi berada dalam bentuk normal ketiga (3NF) jika Telah melalui bentuk normal Kedua Semua atribut bukan kunci tidak memiliki dependensi transitif terhadap kunci primer Khusus untuk Relasi PEGAWAI sudah dapat memenuhi syarat untuk bentuk normal ketiga (3NF), karena TGLLAHIR dan ALAMATtidak memiliki hubungan transitif terhadap NIP.

9 Ketergantungan transitif
Suatu Atribut Z mempunyai ketergantungan transitif terhadap X, bila: Y memiliki ketergantungan fungsi terhadap X Z memiliki ketergantungan fungsi terhadap Y Definisi diatas dituangkan dalam bentuk notasi X  Y  Z Contoh: JADWAL : (MT-KULIAH, RUANG, LANTAI, WAKTU) Dengan demikian notasi dapat ditulis : MT-KULIAH  RUANG  LANTAI LANTAI ketergantungan transitif terhadap MT-KULIAH.

10 Namun Relasi HISTORY-PEGAWAI belum termasuk
normal 3NF dan harus didekomposisi lagi, Menjadi:

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

12 Database Yang Sudah Dinormalisasikan
Product (ProductCode, Name, Time) Parts (ProductCode, ComponentCode, Qty) Component (ComponentCode, Description, Supplier, Cost) Parts Product Component

13 Isi Database Ternormalisasi

14 Conceptual Modeling of Data Warehouses
Modeling data warehouses: (Dimensional Modeling) Star schema: A fact table in the middle connected to a set of dimension tables Snowflake schema: A refinement of star schema where some dimensional hierarchy is normalized into a set of smaller dimension tables, forming a shape similar to snowflake Fact constellations: Multiple fact tables share dimension tables, viewed as a collection of stars, therefore called galaxy schema or fact constellation

15 Example of Star Schema item branch time Sales Fact Table time_key
day day_of_the_week month quarter year time item_key item_name brand type supplier_type item Sales Fact Table time_key item_key branch_key branch_key branch_name branch_type branch location_key street city province_or_street country location location_key units_sold dollars_sold avg_sales Measures

16 Example of Snowflake Schema
time_key day day_of_the_week month quarter year time item_key item_name brand type supplier_key item supplier_key supplier_type supplier Sales Fact Table time_key item_key branch_key location_key street city_key location branch_key branch_name branch_type branch location_key units_sold city_key city province_or_street country dollars_sold avg_sales Measures

17 Example of Fact Constellation
time_key day day_of_the_week month quarter year time item_key item_name brand type supplier_type item Shipping Fact Table Sales Fact Table time_key item_key time_key shipper_key item_key from_location branch_key branch_key branch_name branch_type branch location_key to_location location_key street city province_or_street country location dollars_cost units_sold units_shipped dollars_sold avg_sales shipper_key shipper_name location_key shipper_type shipper Measures

18 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

19 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

20 Tahapan dalam Proses Disain
1. Memilih proses bisnis 2. Memilih inti dari fact table 3. Memilih dimensi 4. Memilih fact yang terukur (umumnya numeric, additive quantities) 5. Melengkapi tabel dimensi (Kimball, 1996)

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

22 Contoh: Usaha Retail Perusahaan grocery besar dengan perkiraan 500 outlet Setiap outlet mempunyai sekitar produk dalam tampilannya SKU – Stock Keeping Unit UPC – Universal Product Code

23 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

24 Usaha Retail Memilih Proses Bisnis Memilih inti dari tabel fact
Pergerakan barang harian Memilih inti dari tabel fact SKU by store by promotion by day Memilih dimensi Waktu, Produk, Toko dan Promosi

25 Usaha Retail Memilih fact terukur

26 Usaha Retail: Dimensi Lengkapi tabel dimensi

27 Usaha Retail: Dimensi Produk

28 Usaha Retail: Dimensi Toko

29 Usaha Retail: Dimensi Promosi

30 Catatan Untuk Masalah Hierarchies
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

31 Star

32 Star Schema

33 Terms Fact table Dimension tables Measures

34 Dimension Hierarchies
sType store city region è snowflake schema è constellations

35 Cube Fact table view: Multi-dimensional cube: dimensions = 2

36 3-D Cube Fact table view: Multi-dimensional cube: dimensions = 3 day 2

37 Aggregates Add up amounts for day 1 In SQL: SELECT sum(amt) FROM SALE
WHERE date = 1 81

38 Aggregates Add up amounts by day
In SQL: SELECT date, sum(amt) FROM SALE GROUP BY date

39 Another Example Add up amounts by day, product
In SQL: SELECT date, sum(amt) FROM SALE GROUP BY date, prodId rollup drill-down

40 Aggregates Operators: sum, count, max, min, median, ave
Using dimension hierarchy average by region (within store) maximum by month (within date)

41 Cube Aggregation Example: computing sums . . . 129 rollup drill-down
day 2 . . . day 1 129 drill-down rollup

42 Cube Operators . . . sale(c1,*,*) 129 sale(c2,p2,*) sale(*,*,*) day 2

43 Extended Cube * day 2 sale(*,p2,*) day 1

44 Aggregation Using Hierarchies
day 2 day 1 customer region country (customer c1 in Region A; customers c2, c3 in Region B)

45 Pivoting Fact table view: Multi-dimensional cube: day 2 day 1