Praktik pemodelan data yang baik sangat penting untuk membangun laporan Power BI yang dioptimalkan untuk kinerja dan dapat diskalakan sesuai kebutuhan.
Tutorial ini menggunakan dataset contoh yang disediakan oleh Microsoft tetapi telah disesuaikan untuk mencerminkan praktik terbaik pemodelan data yang akan kita bahas dalam artikel ini. Anda dapat mengunduh dataset tersebut di sini.
Apa itu Pemodelan Data?
Pemodelan data adalah proses membuat representasi visual tentang keterhubungan antar struktur data, beserta informasi mengenai atribut individual yang ada di dalam struktur data tersebut.
Dalam pembahasan pemodelan data secara umum, istilah yang paling sering Anda dengar adalah skema bintang (star schema). Ini adalah pendekatan yang banyak diadopsi untuk merancang gudang data dan basis data relasional, dan direkomendasikan juga untuk digunakan di Power BI.
Ada dua manfaat utama menggunakan skema bintang:
- Kegunaan: Skema bintang membuat model data Anda lebih rapi dan terorganisasi, serta laporan Anda lebih mudah digunakan.
- Kinerja: Skema bintang memungkinkan Anda dengan mudah menskalakan laporan ke volume data yang sangat besar. Perhitungan DAX juga lebih cepat dan penyegaran laporan Power BI secara keseluruhan menjadi lebih cepat.
Bagaimana cara kerja skema bintang?
Skema bintang terdiri dari sebuah tabel fakta pusat dengan beberapa tabel dimensi yang bercabang dari tabel fakta tersebut, mirip tampilan sebuah bintang. Idealnya, praktik yang baik adalah hanya memiliki satu tabel fakta dalam model data. Namun, dimungkinkan untuk menyertakan beberapa tabel fakta di Power BI.
Skema bintang Power BI. Gambar oleh Penulis
Tabel fakta terdiri dari nilai-nilai yang dapat diringkas dan diagregasi, serta satu atau lebih kunci yang menautkan ke tabel dimensi. Tujuan kunci adalah untuk membuat koneksi antar tabel. Jika Anda memiliki model data yang kompleks atau volume data besar, sebaiknya kunci menggunakan nilai numerik, bukan string teks, karena hal ini dapat meningkatkan kinerja model.
Tabel fakta sebaiknya sangat ramping dan memuat sesedikit mungkin kolom. Kolom apa pun yang mendeskripsikan fitur suatu dataset, seperti Nama Produk atau Kategori Produk, harus dipisahkan dari tabel fakta (jika belum dipisahkan di gudang data) ke tabel dimensinya masing-masing. Proses ini disebut normalisasi data, dan tujuannya adalah menghindari pengulangan.
Tabel dimensi mendeskripsikan fitur-fitur dataset, di mana fitur-fitur tersebut dikelompokkan secara logis dalam tabel terpisah untuk menghindari pembengkakan satu tabel atau menyulitkan pembuatan relasi. Tabel dimensi harus berisi nilai unik untuk fitur yang dideskripsikannya, dan kolom-kolomnya akan bertugas memfilter atau mengelompokkan data dalam laporan Power BI.
Perluasan dari skema bintang adalah skema serpihan salju (snowflake). Dalam pendekatan ini, tabel dimensi dibagi lebih lanjut jika suatu fitur memiliki kategori atau subkategori tambahan. Dalam kasus kita, ada tabel Products yang memuat Product ID, Product Name, dan Product Category. Pada skema serpihan salju, tabel Products hanya akan berisi Product ID dan Product Name, sedangkan Product Category akan dipisahkan lagi ke tabelnya sendiri dengan Product Category ID dan Product Category.
Skema serpihan salju Power BI. Gambar oleh Penulis
Namun, penggunaan skema serpihan salju dapat menambah kompleksitas model data secara tidak perlu; menyertakan tabel ekstra ini dapat menurunkan kinerja dan membuat pembuatan relasi menjadi sulit serta membingungkan.
Cara Membuat Relasi di Power BI
Ada dua cara untuk membuat relasi di Power BI:
- Pilih sebuah field dari satu tabel dan seret ke field di tabel kedua yang ingin Anda hubungkan relasinya.
- Pilih Manage Relationships dari pita dan pilih “New” untuk menambahkan relasi menggunakan jendela yang akan kita bahas selanjutnya (namun dimulai dalam keadaan kosong).
Secara default, Power BI akan mencoba menyimpulkan relasi antar tabel; ini tidak selalu tepat, sehingga Anda mungkin ingin mematikan fitur ini di pengaturan atau menghapus relasi apa pun yang dibuat secara otomatis. Untuk mengedit relasi, klik kanan garis penghubung di antara keduanya dan pilih “Properties”.
Jendela ini memiliki 2 opsi menarik saat mendefinisikan relasi: kardinalitas dan arah penyaringan silang. Pilihan untuk masing-masing opsi ini dapat berdampak besar pada laporan yang dihasilkan, jadi pilihlah dengan cermat. Mari kita uraikan masing-masing opsi tersebut.
Membuat relasi di Power BI. Gambar oleh Penulis
Kardinalitas
Ada 4 pilihan kardinalitas: many-to-one, one-to-one, one-to-many, atau many-to-many.
Saat membuat relasi, direkomendasikan agar field penghubung berisi nilai unik setidaknya pada 1 tabel. Ini memungkinkan Anda menggunakan opsi one-to-many atau many-to-one dalam model data.
Pada data kita, ada relasi antara tabel Financials dan tabel Products menggunakan field Product ID. Tabel Products memiliki nilai unik untuk field Product (setiap produk hanya muncul sekali di tabel). Namun, tabel Financials dapat menampilkan setiap produk beberapa kali berdasarkan tanggal, negara, segmen, dan sebagainya.
Opsi many-to-many adalah yang paling bermasalah, dan meskipun sangat berguna dalam model yang kompleks, opsi ini hanya boleh dipilih jika Anda sepenuhnya memahami konsekuensi dari relasi tersebut.
Untuk menggambarkan di mana relasi many-to-many dapat menimbulkan masalah, kita membuat tabel Sales Target tahunan berdasarkan Kategori Produk dalam model data. Kita perlu dapat melaporkan angka penjualan dan target ini berdampingan dalam visual yang sama. Ini dapat dicapai dengan membuat relasi many-to-many antara tabel Sales Target dan tabel Product.
Relasi many-to-many di Power BI. Gambar oleh Penulis
Pada visual tabel berikut, kita dapat melihat nilai penjualan dan target berdampingan untuk setiap kategori produk.
Kategori produk, penjualan, dan jumlah. Gambar oleh Penulis
Namun, jika kita mencoba menampilkan tabel ini pada tingkat Produk, nilai target akan benar-benar tidak akurat. Ini karena perbedaan tingkat granularitas data; karena target penjualan hanya ada pada tingkat kategori produk, Power BI tidak dapat secara wajar menampilkan target tersebut pada tingkat produk, sehingga targetnya sekadar diduplikasi untuk setiap produk dalam kategori produk. Jika Anda tidak mengetahui bahwa ini bisa menjadi konsekuensi dari penggunaan relasi many-to-many, hal ini bisa sangat bermasalah untuk pelaporan bisnis.
Kategori produk, penjualan, dan jumlah. Gambar oleh Penulis
Arah Penyaringan
Opsi cross filter direction memberi pilihan antara satu arah (single) atau dua arah (both). Relasi mengalir dari tabel dengan nilai unik ke tabel dengan banyak nilai. Dalam kasus kita, relasi mengalir dari tabel Products ke tabel Financials. Ini berarti jika cross filter direction disetel ke single, maka tabel Financials dapat difilter oleh field product dan product category di tabel Products. Namun, tabel Products tidak dapat difilter menggunakan field product ID di tabel Financials, atau menggunakan fitur lain yang ada di tabel dimensi lainnya.
Arah tunggal direkomendasikan untuk sebagian besar kasus. Ini karena relasi dua arah (menggunakan opsi ‘both’) tidak hanya akan menurunkan kinerja model, tetapi juga dapat menimbulkan ambiguitas saat memfilter data.
Dalam kasus kita, perhatikan relasi antara tabel Product, Countries, dan Financials. Keduanya adalah relasi satu arah, one-to-many. Ini berarti memfilter laporan berdasarkan negara tidak akan secara otomatis memfilter tabel Product. Untuk menggambarkan hal ini, perhatikan slicer di bawah. Memilih suatu negara (misalnya USA) tidak akan membuat slicer produk menyesuaikan hanya untuk produk yang relevan dengan negara tersebut.
Slicer di Power BI. Gambar oleh Penulis
Namun, dengan mengubah relasi antara tabel Products dan tabel Financials menjadi dua arah, kita dapat memungkinkan penyaringan mengalir ke tabel Products. Dalam kasus ini, kita melihat bahwa produk Carretera tidak muncul di slicer Product karena tidak ada penjualan untuk produk tersebut di United States of America.
Slicer di Power BI. Gambar oleh Penulis
Sebagai alternatif, untuk menghindari penggunaan relasi dua arah, Anda dapat menambahkan filter pada visual slicer untuk mengecualikan item yang kosong. Perlu dicatat bahwa Anda perlu melakukan ini pada setiap visual yang menggunakan field lintas tabel dimensi.
Filter dan slicer di Power BI. Gambar oleh Penulis
Cara Mengoptimalkan Model Power BI Anda
Faktor terpenting dalam mengoptimalkan model Power BI Anda adalah menggunakan praktik pemodelan data yang baik seperti yang dijabarkan dalam tutorial ini. Sering kali, model data yang baik saja sudah memungkinkan sebuah laporan Power BI menskalakan hingga jutaan dan miliaran baris data sambil tetap mempertahankan tingkat kinerja yang layak.
Namun, ada beberapa hal lain yang dapat Anda lakukan untuk mengoptimalkan model Power BI, selain mengikuti praktik pemodelan data yang baik, seperti:
- Mematikan time intelligence – Fitur di Power BI ini secara otomatis membuat hierarki tanggal/waktu setiap kali field tanggal ditambahkan ke visual. Setiap kali salah satu hierarki ini dibuat, pada dasarnya itu menambahkan tabel tambahan ke model data. Seperti yang dapat Anda bayangkan, ini dapat secara signifikan membengkakkan laporan Power BI, memperlambat perenderan visual, dan meningkatkan waktu penyegaran. Sebaiknya matikan fitur ini dan sebagai gantinya gunakan tabel tanggal khusus untuk semua hierarki tanggal/waktu.
- Hanya memuat kolom yang benar-benar Anda perlukan – Dengan Power Query editor, sebaiknya hapus kolom apa pun yang tidak Anda perlukan atau tidak Anda gunakan dalam laporan. Salah satu field yang paling umum biasanya dipertahankan untuk jaga-jaga adalah field Row ID. Field ini unik untuk dataset Anda, contohnya Order ID untuk setiap transaksi dalam tabel Orders. Sering kali, field ID ini juga disimpan sebagai teks yang semakin membengkakkan model. Jika field ID tidak secara eksplisit digunakan dalam relasi, biasanya tidak perlu dimuat ke dalam model Anda.
- Hanya memuat baris yang Anda perlukan – Jangan terjebak dalam anggapan bahwa Anda perlu mengimpor semua data bisnis ke laporan Power BI. Terutama jika bisnis Anda sudah berjalan lama, ini bisa berarti laporan Anda memuat sejumlah besar data yang sebenarnya tidak diperhatikan siapa pun. Kuncinya adalah berbicara dengan pengguna bisnis dari laporan dan cari tahu tepatnya seberapa banyak data historis yang perlu mereka lihat. Jika mereka memang perlu melihat data lama, Anda dapat mempertimbangkan hanya mengimpor versi yang diringkas dari tabel tersebut alih-alih setiap transaksi satu per satu.
