Konsep Model Dimensional

Beberapa konsep penting dalam model dimensional adalah pengertian dimensi, atribut, pengukuran dan tabel fakta.

a. Model Hirarki

Dimensi terdiri dari daftar atribut yang digunakan untuk mengelompokkan dan menganalisis informasi. Beberapa atribut berelasi dan dapat dikelompokkan kedalam suatu hirarki. Sebagai contoh, product category, product subcategory dan product stock-keeping unit (SKU) dapat dikelompokkan kedalam sebuah hirarki disebut sebagai Product Categorization. Ketika hirarki digunakan dalam sebuah query, hasilnya akan memperlihatkan total setiap product category dan kemudian mengijinkan user untuk menyusun dalam subcategory dan kemudian membuat product stock-keeping unit (SKU) kedalam subcategory.

Hirarki bermanfaat untuk menguasai sejumlah besar informasi dengan cara menyajikan informasi ringkas dan memudahkan user untuk mencari informasi yang lebih detil pada bidang yang menarik minat mereka. Teknologi OLAP memiliki tipikal dibangun berdasarkan konsep hirarki, dalam kenyataannya, banyak sekali perangkat OLAP sebelumnya yang membolehkan user membuat query dengan menggunakan konsep hirarki yang didefinisikan sebelumnya. Alasannya adalah karena aggregat-aggregat yang merupakan sumber unjuk kerja OLAP didesan dengan model hirarki.

b.  Model Star dan Snowflake

Model dimensional yang paling sederhana adalah model “star” seperti gambar dibawah ini.

Model ini merupakan desain model dimensional dengan satu tabel untuk setiap dimensi seperti Product atau Customer. Artinya bahwa tabel-tabel tidak sebenuhnya mengikuti aturan normalisasi, karena atribut seperti product category description diulang pada setiap record product untuk category tertentu. Pada periode beberapa waktu lalu, star schema merupakan desain yang atraktif karena user dapat mengakses database relasional secara langsung tanpa khawatir dengan masalah relasi antar table dimensi dan karena database relasional tidak dapat digunakan dengan sangat baik untuk melakukan optimasi query dalam menghadapi skema yang lebih komplek.

Penyelesaian dengan BI Modern mempunyai pendekatan yang seluruhnya berbeda untuk mendapatkan dua keuntungan utama dari tabel satu dimensi dalam star schema: Jika user mengakses semua informasi dari OLAP cube, kinarja query dan penggunaannya diperoleh dari OLAP bukan dari database relasional.

Struktur data pada OLAP jauh lebih sederhana, mengingat data-data yang akan tersimpan didalamnya tidak banyak mengalami perubahan dimana lebih banyak transaksi selection (read only – hanya baca) daripada DML. Jika pada OLTP, konsep ACID (atomicity, consistency, isolation, durability) menjadi properti utama yang harus melekat pada setiap transaksi data dari dan ke aplikasi klien maka dalam OLAP yang lebih diutamakan adalah kecepatan perolehan datanya (data retrieval). Tidak hanya struktur basis datanya yang berbeda, namun konfigurasi server basis datanya pun akan berbeda antara OLAP dan OLTP.

Star Schema

Dalam data warehouse, data-datanya akan disimpan dalam tabel fakta dan tabel dimensi. Tabel fakta akan menyimpan data-data utama sementara tabel dimensi mendeskripsikan setiap nilai dari suatu dimensi dan dapat direlasikan ke tabel fakta jika diperlukan. Data fakta merupakan data yang terukur besarannya, semisal jumlah siswa, banyaknya rupiah yang diperoleh, rata-rata IPK, dan sejenisnya. Untuk lebih menjelaskan data fakta, maka kondisi saat data tersebut diukur turut disampaikan. Data kondisi inilah yang dipetakan dalam bentuk data dimensi. Kondisi yang dipetakan dalam dimensi umumnya berupa kondisi waktu, kondisi produk atau item, dan kondisi geografinya. Mendesain struktur star schema, dimulai dengan menentukan data apa yang ingin dilihat oleh pengguna (besarannya) dan bagaimana pengguna melihat data tersebut (kondisi atau dimensinya).

Tabel dimensi memiliki primary key sederhana yang mengandung hanya satu atau dua kolom saja. Namun, tabel fakta akan memiliki sekumpulan foreign key yang disusun dari primary key komposit dan merupakan gabungan kolom-kolom tabel dimensi yang berelasi. Untuk lebih jelasnya, berikut contoh struktur star schema.

Untuk struktur star schema seperti diatas, data dalam tabel fakta yang diukur adalah hasil penjualan (dalam mata uang) berdasarkan dimensi atau kondisi produk yang dijual (product) serta waktu penjualan (time). Misalkan dimensi produk, yang menyimpan informasi-informasi seputar produk. Produk ini dapat dikelompokkan ke dalam kategori, dan di dalam kategori inipun bisa ditemukan sub-kategori. Jika kode produknya AB9001 merujuk pada kripik tempe, maka akan masuk ke dalam kategori Nabati, dan sub-kategori Tempe. Untuk lebih mengelompokkan produk tersebut, dapat pula dibuatkan sub-kategori berikutnya. Namun kunci dari informasi produk tersebut tersimpan dalam kolom di tabel dimensi, dan tidak dibutuhkan tabel lain untuk menjelaskan detil produk. Semakin beragam jenis kondisi data yang ingin diamati, maka akan semakin besar ukuran tabel fakta yang dimuat.

Dalam star schema, kueri yang terbentuk antara tabel fakta dan sejumlah tabel dimensi dinamakan star query. Setiap tabel dimensi direlasikan dengan tabel fakta berdasarkan kolom primary key dan foreign key, namun diantara masing-masing tabel dimensi tidak ada yang saling berelasi (tidak ada hubungan data). Kueri yang terbentuk menyebabkan proses eksekusi yang lebih optimal, karena rencana eksekusi kueri dalam DBMS akan lebih cepat dengan setiap tabel hanya berelasi dengan satu tabel yang lain.

Ada kalanya tabel dimensi mengandung data yang duplikat pada satu atau lebih kolom. Jika mengikuti azas normalisasi, maka struktur basis data yang terbentuk bukan lagi star schema namun akan menjadi snowflake schema.

Snowflake Schema

Struktur basis data ini lebih kompleks dari pada star schema, dengan menormalisasi tabel-tabel dimensi yang berukuran besar dengan satu atau lebih kolom yang memiliki duplikasi data. Misal jika tabel dimensi Product dinormalisasi maka akan menghasilkan struktur seperti berikut:

Tabel dimensi dinormalisasi untuk mengurangi redudansi data (duplikasi), sehingga struktur tabelnya akan lebih ramping. Dengan pengelompokan ini, data akan lebih mudah dibaca dan membantu pengembang aplikasi untuk menata desain antarmuka sistem dan filtering data. Struktur ini akan menghemat kapasitas storage, namun waktu eksekusi data akan lebih lama mengingat jumlah tabel dimensi yang direlasikan lebih banyak dan membutuhkan tambahan relasi foreign key. Kueri yang terbentuk lebih kompleks, yang mengakibatkan kinerja kueri menurun. Pada penerapan yang lebih umum, tabel dimensi tidak diturunkan dengan lebih banyak tabel dimensi lain dan pengaturan UI atau pengelompokan data diatur secara hard-coded di kode program aplikasinya.

Fokus penggunaan datawarehouse adalah kecepatan akses dan eksekusi data, bukanlah ukuran data yang lebih kecil atau struktur basis data yang lebih ramping. Sehingga bijaksana dalam menetapkan struktur data star maupun snowflake schema akan menentukan kinerja layanan datawarehouse yang dimiliki.