kelompok 4

36
Candra Dwi Putro 09.04.111.00092 Merlien N. Febriyati 09.04.111.00056 Ryna Selvia Putri 09.04.111.00090 arehouse ata

Upload: candra-dwi-putro

Post on 06-Aug-2015

18 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Kelompok 4

• Candra Dwi Putro 09.04.111.00092• Merlien N. Febriyati 09.04.111.00056• Ryna Selvia Putri 09.04.111.00090

arehouseata

Page 2: Kelompok 4

Prinsiples Of Dimensional

Modeling

Page 3: Kelompok 4

Dari Requirement sampai Data Design

Requirements Definition merupakan bagian dari data design untuk data warehouse. Data Design terdiri dari struktur data yang merupakan kelompok elemen data. Logical data design menentukan masukan dari berbagai elemen data yang dibutuhkan dan dikombinasikan elemen data ke dalam struktur data. Logical data design juga menentukan relationships diantara struktur data.

Page 4: Kelompok 4

FROM REQUIREMENTS TO DATA DESIGN

Page 5: Kelompok 4

Design DecisionsSebelum membuat Dimensional Data Model, kita harus menentukan desainnya :

- Choosing the Process- Choosing the Grain- Identifying and conforming the dimension- Choosing the facts- Choosing the duration of the database

Page 6: Kelompok 4

Dimensional Modeling Basics

Dimensional modeling berasal dari business dimensions yang akan dimasukkan ke Logical data model. Ini adalah teknik Logical Design untuk membangun business dimensions dan metric yang akan dianalisa pada dimensi ini.Teknik Modeling ini dapat memberikan high performance untuk query dan analysis.

Multidimensional information package diagram adalah pondasi untuk dimensional model. Oleh karena itu, dimensional model terdiri dari spesifik struktur data yang diperlukan untuk merepresentasikan business dimensions. Struktur Data ini berisi facts atau metrics.

Page 7: Kelompok 4

Example of Dimensional Model

• contoh information package diagram untuk Automaker Sales, disitu terdapat 3 type entity : - measurements or metrics, - business dimensions, dan - atribut untuk masing-masing Business Dimension.

• saat memakai Dimensional Model untuk merepresentasikan informasi Automaker sales yang berisi paket informasi (Information Package).kita pakai kembali data structure untuk menampilkan tiga data entity ini.hal ini dapat dilakukan, yaitu pertama kita memakai kebutuhan atau metrics yang sebenarnya adalah information package diagram. Ini adalah fact untuk analisa.

Page 8: Kelompok 4

Pada automaker sales diagram, fact tersebutterdiri dari :

Page 9: Kelompok 4

Example of Dimensional Model

Page 10: Kelompok 4

Example of Dimensional Model

Daftar relasi data item dengan product dimension adalah sebagai berikut:

Page 11: Kelompok 4

Example of Dimensional Model

menunjukkan bagaimana berbagai dimension tables dibentuk dari informationpackage diagram. Lihat bagaimana masing-masing dimension table dibuat.

Page 12: Kelompok 4

Kriteria untuk menggabungkan tabel kedalam model dimensi

• Model harus menyediakan akses data terbaik.• Seluruh model harus query-centric.• Itu harus dioptimalkan untuk queries dan analisis. • Model harus menunjukkan bahwa tabel-tabel dimensi berinteraksi

dengan fact table.• Hal itu juga harus menjadi terstruktur sedemikian rupa sehingga setiap

dimensi dapat berinteraksi sama dengan fact table.• Model harus memungkinkan menelusuri atau menggulung sepanjang

dimensi hierarki.

Page 13: Kelompok 4

E-R Modeling Vs Dimensional Modeling

Kita telah familiar dengan data modeling untuk operasional atau OLTP sistem.E-R modeling untuk membuat data model sistem.

Untuk Dimensional Model sesuai digunakan untuk modeling data warehouse.

Page 14: Kelompok 4

E-R Modeling Vs Dimensional Modeling

• Use of CASE ToolsKamu dapat menggunakan case tool untuk define table, atribut, dan relationship. menentukan primary key dan foreign key. membuat entity relationship digram. semuanya sangat mudah dibuat dengan user interface. Setelah initial model dibuat, ditambahi add field,edit, delete, pencarian, buat relasi baru dengan mudah. Banyak ditemukan fungsi yang useful pada case tool ini karena ability to forward-engineering.

• Use Dimensional ModelingUntuk Modeling data warehouse, lebih cocok dengan teknik Dimensional Modeling. Kita bisa buat fact table, dimension table, dan estabelich the relationship diantara masing-masing dimension table dan fact table. Hasilnya adalah START schema. Kita dapat forward-engineer the dimensional START model kedalam relational schema untuk memilih database management system.

Page 15: Kelompok 4

STAR SCHEMABentuk dimensional model seperti suatu formasi bintang, dengan fact table pada intibintang dan dimention table diantara ujung bintang. Dimensional Model ini disebutSTART SCHEMA.

Page 16: Kelompok 4

STAR SCHEMA

• Asumsinya adalah schema manufacturing company dan marketing department yang ingin menentukan bagaimana melakukan order yang diterima dari perusahaan tersebut.

• Meliputi fact table adalah 4 dimensi tabel customer, salesperson, order date, and product. Dilihat dari Marketing Department user akan menganalisa order menggunakan dollar amounts, cost, profit margin and sold quantity. Informasi ini terdapat pada struktur fact table. User akan menganalisa measurement dengan merinci nomor kombinasi dari customer,salesperson, date, and product.

• START schema adalah struktur yang mudah dipahami oleh user. Struktur menggambarkan user secara normal memandang kebutuhan kritis terhadap Business Dimension mereka.

Page 17: Kelompok 4

STAR SCHEMA

Page 18: Kelompok 4

Inside a Dimension Table

Page 19: Kelompok 4

Inside the Fact Table

Page 20: Kelompok 4

The Factless Fact Table

Page 21: Kelompok 4

ADVANTAGES OF THE STAR SCHEMA

• Easy for Users to Understand• Optimizes Navigation• Most Suitable for Query Processing

Page 22: Kelompok 4

• Tabel dimensi lebih stabil• Perubahan tabel dimensi terjadi pada jumlah

baris dan atributnya.

Update Tabel Dimensi

Page 23: Kelompok 4

• Konstan seiring waktu• Pada dimensi yang banyak, perubahan terjadi secara

perlahan• Product key dari catatan sumber tidak berubah• Deskrpisi dan atribut lainnya berubah secara perlahan

seiring waktu • Pada sistem OLTP, nilai baru akan menimpa nilai yang lama• Menimpa atribut tabel dimensi bukan pilihan utama

dalam data warehouse• Perubahan pada tabel dimensi bergantung pada tipe

perubahan dan informasi yang disimpan dalam data warehouse

Prinsip Perubahan Tabel Dimensi

Page 24: Kelompok 4

• Type 1 Changes• Type 2 Changes• Type 3 Changes

Klasifikasi Perubahan Tabel Dimensi

Page 25: Kelompok 4

• Berhubungan dengan koreksi kesalahan dalam sistem sumber

• Prinsipnya :– Perubahan sistem sumber tidak memiliki makna– Nilai lama dalam sistem perlu dibuang– Perubahan dalam sistem sumber tidak disimpan

dalam data warehouse

Type 1 Changes: Correction of Errors

Page 26: Kelompok 4

• Timpa nilai atribut dalam baris tabel dimensi dengan nilai baru

• Nilai lama atribut tidak disimpan• Tidak ada perubahan lain dalam baris tabel

dimensi• Key dalam tabel dimensi atau nilai kunci

lainnya tidak mempengaruhi• Paling mudah diterapkan

Penerapan Type 1 Changes Dalam Data Warehouse

Page 27: Kelompok 4

• Berhubungan dengan perubahan besar dalam sistem sumber

• Kebutuhan untuk menyimpan history dalam data warehouse

• Jenis partisi perubahan dalam data warehouse• Setiap perubahan untuk atribut yang sama

harus dipertahankan

Type 2 Changes: Preservation of History

Page 28: Kelompok 4

• Tambahkan baris tabel dimensi baru dengan nilai baru untuk atribut yang berubah

• Tanggal efektif mungkin dimasukkan dalam tabel dimensi

• Tidak ada perubahan pada baris asli pada tabel dimensi

• Key baris asli tidak berubah• Baris baru disisipkan dengan key pengganti baru

Penerapan Type 2 Changes Dalam Data Warehouse

Page 29: Kelompok 4

• Berhubungan dengan perubahan sementara pada sistem sumber

• Kebutuhan untuk melacak history dengan nilai lama dan baru dari atribut yang berubah

• Digunakan untuk membandingkan kinerja di seluruh transisi

• Menyediakan kemampuan untuk melacak maju atau mundur

Type 3 Changes: Tentative Soft Revisions

Page 30: Kelompok 4

• Tambahkan field “lama” dalam tabel dimensi untuk atribut yang berubah

• Masukkan nilai atribut yang ada dalam field “saat ini” ke dalam field “lama”

• Jaga nilai atribut baru dalam field “saat ini”• Mungkin, ditambahkan tanggal efektif “saat

ini” untuk atribut• Key baris tidak terpengaruh

Penerapan Type 3 Changes Dalam Data Warehouse

Page 31: Kelompok 4

• Tidak membutuhkan baris dimensi baru• Query yang sudah ada akan dialihkan ke nilai

“saat ini”• Setiap query yang perlu menggunakan nilai

“lama” harus direvisi• Teknik berkerja baik untuk satu perubahan

“lunak ” pada suatu waktu

Penerapan Type 3 Changes Dalam Data Warehouse – Cont’d

Page 32: Kelompok 4

• Large Dimensions• Rapidly Changing Dimensions• Junk Dimensions

MISCELLANEOUS DIMENSIONS

Page 33: Kelompok 4

• Memiliki banyak baris• Memiliki banyak atribut

Large Dimensions

Page 34: Kelompok 4

Multiple Hierarchies

Page 35: Kelompok 4

• Saat tabel desain dibuat datar, memungkinkan cross-browsing diantara berbagai atribut dimensi

• Saat baris tambahan pada tabel dimensi dibuat, struktur dasar dimensi masih dipertahankan

• Hanya ketika query pengguna akhir didasarkan pada atribut yang berubah berada dibanyak baris untuk pelanggan yang sama

Rapidly Changing Dimensions

Page 36: Kelompok 4

• Sebagian besar bidang berakhir dalam tabel dimensi. Anda akan melihat bahwa beberapa bidang seperti penanda lain dan bidang tekstual yang tersisa dalam struktur sumber data. Ini termasuk penanda ya / tidak, kode tekstual, dan teks bentuk bebas.

• Namun, banyak bendera dan teks bisa menjadi nilai sesekali dalam permintaan. Ini tidak dapat dimasukkan sebagai bidang yang signifikan dalam dimensi utama. Pada saat yang sama, penanda dan teks tidak dapat dibuang baik

Junk Dimensions