Candra Dwi Putro Merlien N.

Febriyati Ryna Selvia Putri

09.04.111.00092 09.04.111.00056 09.04.111.00090

ata

arehouse

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 Decisions
Sebelum 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 tersebut terdiri 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 information package 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 Tools Kamu 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 Modeling Untuk 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 SCHEMA
Bentuk dimensional model seperti suatu formasi bintang, dengan fact table pada inti bintang dan dimention table diantara ujung bintang. Dimensional Model ini disebut START 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

Update Tabel Dimensi

Tabel dimensi lebih stabil Perubahan tabel dimensi terjadi pada jumlah baris dan atributnya.

Prinsip Perubahan 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

Klasifikasi Perubahan Tabel Dimensi

Type 1 Changes Type 2 Changes Type 3 Changes

Type 1 Changes: Correction of Errors

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

Penerapan Type 1 Changes Dalam Data Warehouse

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

Type 2 Changes: Preservation of History

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

Penerapan Type 2 Changes Dalam Data Warehouse

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

Type 3 Changes: Tentative Soft Revisions

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

Penerapan Type 3 Changes Dalam Data Warehouse

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 Contd

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

MISCELLANEOUS DIMENSIONS
Large Dimensions Rapidly Changing Dimensions Junk Dimensions

Large Dimensions
Memiliki banyak baris Memiliki banyak atribut

Multiple Hierarchies

Rapidly Changing Dimensions

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

Junk 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