Laporan Power BI yang angkanya benar saat dikelompokkan per produk, tetapi keliru saat dikelompokkan per pelanggan, biasanya bukan masalah rumus DAX. Penyebabnya ada satu lapis di bawahnya: filter tidak sampai ke tabel fakta, atau sampai lewat jalur yang tidak Anda maksud.
Dimensi memfilter, fakta menjumlahkan
Dalam desain star schema, tabel model dibagi dua peran. Tabel dimensi menyimpan entitas seperti produk, pelanggan, dan tanggal; tugasnya memfilter dan mengelompokkan. Tabel fakta menyimpan kejadian seperti transaksi penjualan; tugasnya diringkas.
Yang sering terlewat: tidak ada properti yang bisa dicentang untuk menandai sebuah tabel sebagai dimensi atau fakta. Yang menentukan adalah kardinalitas relasinya. Pada relasi satu ke banyak, sisi "satu" selalu tabel dimensi dan sisi "banyak" selalu tabel fakta. Karena itu satu tabel besar hasil ekspor, yang mencampur atribut produk dan nilai transaksi dalam satu baris, tidak menyediakan jalur propagasi filter apa pun untuk dilalui.
Dokumentasi Microsoft menganjurkan setiap tabel model berperan sebagai dimensi saja atau fakta saja, tidak dicampur, dan tabel fakta selalu dimuat pada tingkat rincian yang konsisten.
Biaya bentuk snowflake
Kalau sumber datanya sudah ternormalisasi bertingkat, misalnya produk, subkategori, lalu kategori di tiga tabel terpisah, Anda boleh meniru bentuk itu di model. Microsoft mencatat empat biayanya secara terbuka: lebih banyak tabel yang dimuat sehingga ukuran model naik, rantai propagasi filter yang lebih panjang, panel Data yang lebih ramai bagi penyusun laporan, dan hierarki yang tidak bisa dibentuk dari kolom lintas tabel. Umumnya menggabungkannya jadi satu tabel dimensi lebih menguntungkan.
Ingin mendalaminya lebih terstruktur? Taalenta punya kelas Membangun Data Dashboard dengan Power BI.
Hanya satu relasi aktif antara dua tabel
Tabel tanggal sering perlu dipakai untuk tanggal pesan, tanggal kirim, dan tanggal terima sekaligus. Anda memang boleh membuat tiga relasi antara tabel tanggal dan tabel fakta, tetapi hanya satu yang bisa aktif. Sisanya nonaktif dan hanya bisa dipanggil lewat fungsi USERELATIONSHIP di dalam measure.
Akibat praktisnya konkret: dengan satu jalur aktif, Anda tidak bisa membuat satu visual yang memplot penjualan berdasarkan tanggal pesan berdampingan dengan penjualan berdasarkan tanggal kirim. Jalan keluar yang lazim adalah membuat tabel dimensi terpisah untuk tiap peran, lalu menamai kolomnya secara khas, misalnya Tahun Kirim, bukan Tahun.
Filter dua arah: batasi, jangan jadikan kebiasaan
Panduan Microsoft menyebutnya jelas: minimalkan relasi dua arah, karena menambah beban pemrosesan kueri dan bisa membingungkan pembaca laporan. Ada tiga keadaan yang membenarkannya:
- Relasi satu ke satu, yang memang selalu dua arah dan tidak bisa diatur lain.
- Relasi banyak ke banyak antar dua tabel dimensi, yang butuh tabel jembatan dan satu relasi dua arah agar filter menembusnya.
- Analisis antar dimensi, ketika tabel fakta diperlakukan sebagai jembatan.
Untuk kebutuhan yang paling sering muncul, yaitu slicer yang hanya menampilkan pilihan yang ada datanya, ada cara yang lebih murah: buat measure penjumlah, lalu pasang filter visual pada slicer dengan kondisi bukan kosong. Hasilnya sama tanpa menambah relasi dua arah. Kalau memang perlu dua arah, aktifkan di dalam measure memakai fungsi CROSSFILTER, bukan di properti relasinya.
Jangan hubungkan dua tabel fakta secara langsung
Menghubungkan tabel pesanan dan tabel pengiriman langsung dengan kardinalitas banyak ke banyak memang bisa dan terlihat praktis. Dua konsekuensinya tidak terlihat di layar: visual hanya bisa memfilter atau mengelompokkan lewat kolom kunci di satu tabel saja, dan bila data punya masalah integritas, sebagian baris bisa hilang dari hasil kueri karena relasi semacam itu diperlakukan sebagai relasi terbatas. Menambahkan tabel dimensi bersama lalu menghubungkan keduanya dengan relasi satu ke banyak memerlukan pekerjaan awal yang lebih banyak, tetapi kesalahan datanya muncul ke permukaan alih-alih tersembunyi.
Daftar periksa singkat
- Setiap tabel berperan tunggal: dimensi atau fakta.
- Semua relasi idealnya satu ke banyak, arah filter tunggal.
- Setiap tabel dimensi punya satu kolom pengenal unik.
- Relasi dua arah hanya untuk tiga kasus di atas, dan dihitung jumlahnya.
- Tabel fakta dimuat pada satu tingkat rincian yang tetap.
Sumber
- Microsoft Learn, Understand star schema and the importance for Power BI, https://learn.microsoft.com/en-us/power-bi/guidance/star-schema
- Microsoft Learn, Bi-directional relationship guidance, https://learn.microsoft.com/en-us/power-bi/guidance/relationships-bidirectional-filtering
- Microsoft Learn, Many-to-many relationship guidance, https://learn.microsoft.com/en-us/power-bi/guidance/relationships-many-to-many