kelompok 4
TRANSCRIPT
• Candra Dwi Putro 09.04.111.00092• Merlien N. Febriyati 09.04.111.00056• Ryna Selvia Putri 09.04.111.00090
arehouseata
Prinsiples Of Dimensional
Modeling
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.
FROM REQUIREMENTS TO DATA DESIGN
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
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.
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.
Pada automaker sales diagram, fact tersebutterdiri dari :
Example of Dimensional Model
Example of Dimensional Model
Daftar relasi data item dengan product dimension adalah sebagai berikut:
Example of Dimensional Model
menunjukkan bagaimana berbagai dimension tables dibentuk dari informationpackage diagram. Lihat bagaimana masing-masing dimension table dibuat.
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.
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.
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.
STAR SCHEMABentuk dimensional model seperti suatu formasi bintang, dengan fact table pada intibintang dan dimention table diantara ujung bintang. Dimensional Model ini disebutSTART SCHEMA.
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.
STAR SCHEMA
Inside a Dimension Table
Inside the Fact Table
The Factless Fact Table
ADVANTAGES OF THE STAR SCHEMA
• Easy for Users to Understand• Optimizes Navigation• Most Suitable for Query Processing
• Tabel dimensi lebih stabil• Perubahan tabel dimensi terjadi pada jumlah
baris dan atributnya.
Update Tabel Dimensi
• 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
• Type 1 Changes• Type 2 Changes• Type 3 Changes
Klasifikasi Perubahan Tabel Dimensi
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• Large Dimensions• Rapidly Changing Dimensions• Junk Dimensions
MISCELLANEOUS DIMENSIONS
• Memiliki banyak baris• Memiliki banyak atribut
Large Dimensions
Multiple Hierarchies
• 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
• 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