Memahami skema bintang dan pentingnya Power BI

Artikel ini menargetkan Power BI Desktop pemodel data. Artikel ini menjelaskan desain skema bintang dan relevansinya untuk mengembangkan model data Power BI dioptimalkan untuk performa dan kegunaan.

Artikel ini tidak dimaksudkan untuk memberikan diskusi lengkap tentang desain skema bintang. Untuk detail selengkapnya, lihat langsung ke konten yang diterbitkan, seperti Toolkit Gudang Data: Panduan Definitif untuk Pemodelan Dimensi (edisi ke-3, 2013) oleh Ralph Kimball dan lainnya.

Gambaran umum skema bintang

Skema bintang adalah pendekatan pemodelan matang yang diadopsi secara luas oleh gudang data relasional. Skema bintang membutuhkan pemodel untuk mengklasifikasikan tabel model sebagai dimensi atau fakta.

Tabel dimensi menjelaskan entitas bisnis—hal-hal yang Anda modelkan. Entitas dapat mencakup produk, orang, tempat, dan konsep termasuk waktu itu sendiri. Tabel paling konsisten yang akan Anda temukan dalam skema bintang adalah tabel dimensi tanggal. Tabel dimensi berisi kolom kunci (atau kolom) yang bertindak sebagai pengidentifikasi unik, dan kolom deskriptif.

Tabel fakta menyimpan pengamatan atau kejadian, dan dapat berupa pesanan penjualan, saldo stok, nilai tukar, suhu, dll. Tabel fakta berisi kolom kunci dimensi yang berhubungan dengan tabel dimensi, dan kolom ukuran numerik. Kolom kunci dimensi menentukan dimensi tabel fakta, sedangkan nilai kunci dimensi menentukan granuralitas tabel fakta. Misalnya, pertimbangkan tabel fakta yang didesain untuk menyimpan target penjualan yang memiliki dua kolom kunci dimensi Tanggal dan ProductKey. Sangat mudah untuk memahami bahwa tabel memiliki dua dimensi. Namun, granuralitas tidak dapat ditentukan tanpa mempertimbangkan nilai kunci dimensi. Dalam contoh ini, pertimbangkan bahwa nilai yang disimpan di kolom Tanggal adalah hari pertama setiap bulan. Dalam kasus ini, granuralitas berada pada tingkat produk bulan.

Umumnya, tabel dimensi berisi jumlah baris yang relatif kecil. Tabel fakta, di sisi lain, dapat berisi jumlah baris yang sangat besar dan terus bertambah seiring waktu.

Normalisasi vs. denormalisasi

Untuk memahami beberapa konsep skema bintang yang dijelaskan dalam artikel ini, penting untuk mengetahui dua istilah: normalisasi dan denormalisasi.

Normalisasi adalah istilah yang digunakan untuk menjelaskan data yang disimpan dengan cara yang mengurangi data berulang. Pertimbangkan tabel produk yang memiliki kolom nilai kunci unik, seperti kunci produk, dan kolom tambahan yang menjelaskan karakteristik produk, termasuk nama produk, kategori, warna, dan ukuran. Tabel penjualan dianggap dinormalisasi ketika hanya menyimpan kunci, seperti kunci produk. Dalam gambar berikut, perhatikan bahwa hanya kolom ProductKey yang merekam produk.

Namun, jika tabel penjualan menyimpan detail produk di luar kunci, tabel tersebut dianggap di-denormalisasi. Dalam gambar berikut, perhatikan bahwa ProductKey dan kolom terkait produk lainnya merekam produk.

Saat Anda sumber data dari file ekspor atau ekstrak data, kemungkinan data tersebut mewakili sekumpulan data yang dinormalisasi. Dalam hal ini, gunakan Power Query untuk mengubah dan membentuk data sumber menjadi beberapa tabel yang dinormalisasi.

Seperti yang dijelaskan dalam artikel ini, Anda harus berusaha untuk mengembangkan model data Power BI yang dioptimalkan dengan tabel yang mewakili data fakta dan dimensi yang dinormalisasi. Namun, ada satu pengecualian di mana dimensi snowflake harus didenormalisasi untuk menghasilkan satu tabel model.

Relevansi skema bintang dengan model Power BI

Desain skema bintang dan banyak konsep terkait yang diperkenalkan dalam artikel ini sangat relevan dengan pengembangan model Power BI yang dioptimalkan untuk performa dan kegunaan.

Pertimbangkan bahwa setiap visual laporan Power BI menghasilkan kueri yang dikirim ke model Power BI (yang layanan Power BI memanggil model semantik—yang sebelumnya dikenal sebagai himpunan data). Kueri ini digunakan untuk memfilter, mengelompokkan, dan meringkas data model. Model yang dirancang dengan baik, adalah model yang menyediakan tabel untuk pemfilteran dan pengelompokan, dan tabel untuk dirangkum. Desain ini cocok dengan prinsip skema bintang:

• Tabel dimensi mendukung pemfilteran dan pengelompokan
• Dukungan tabel fakta ringkasan

Tidak ada properti tabel yang diatur pemodel untuk mengonfigurasi jenis tabel sebagai dimensi atau fakta. Hal ini sebenarnya ditentukan oleh hubungan model. Hubungan model menetapkan jalur propagasi filter di antara dua tabel, dan merupakan properti Kardinalitas dari hubungan yang menentukan jenis tabel. Kardinalitas hubungan yang sama adalah satu-ke-banyak atau kebalikannya banyak-ke-satu. Sisi "satu" selalu merupakan tabel jenis dimensi sementara sisi "banyak" selalu merupakan tabel jenis fakta. Untuk informasi selengkapnya tentang hubungan, lihat Hubungan model di Power BI Desktop.

Desain model yang terstruktur dengan baik harus menyertakan tabel yang merupakan tabel jenis dimensi atau tabel jenis fakta. Hindari mencampur dua jenis bersama-sama untuk satu tabel. Kami juga menyarankan agar Anda harus berusaha untuk memberikan jumlah tabel yang tepat dengan hubungan yang tepat. Penting juga bahwa tabel jenis fakta selalu memuat data pada butir yang konsisten.

Terakhir, penting untuk dipahami bahwa desain model yang optimal adalah bagian sains dan seni bagian. Terkadang Anda dapat memutuskan dengan panduan yang baik ketika masuk akal untuk melakukannya.

Ada banyak konsep tambahan yang terkait dengan desain skema bintang yang dapat diterapkan ke model Power BI. Konsep-konsep ini meliputi:

• Ukuran
• Kunci pengganti
• Dimensi Snowflake
• Dimensi pemutaran peran
• Mengubah dimensi secara perlahan
• Dimensi sampah
• Dimensi degenerasi
• Tabel fakta tanpa fakta

Tindakan

Dalam desain skema bintang, ukuran adalah kolom tabel fakta yang menyimpan nilai yang akan diringkas.

Dalam model Power BI, ukuran memiliki definisi yang berbeda—tetapi serupa—. Ini adalah rumus yang ditulis dalam Data Analysis Expressions (DAX) yang mencapai ringkasan. Ekspresi pengukuran sering memanfaatkan fungsi agregasi DAX seperti SUM, MIN, MAX, AVERAGE, dll. untuk menghasilkan hasil nilai skalar pada waktu kueri (nilai tidak pernah disimpan dalam model). Ekspresi pengukuran dapat berkisar dari agregasi kolom sederhana hingga rumus yang lebih canggih yang menggantikan konteks filter dan/atau propagasi hubungan. Untuk informasi selengkapnya, baca artikel Dasar-Dasar DAX di Power BI Desktop.

Penting untuk dipahami bahwa model Power BI mendukung metode kedua untuk mencapai ringkasan. Kolom apa pun—dan biasanya kolom numerik—dapat diringkas oleh visual laporan atau Tanya Jawab Umum. Kolom-kolom ini disebut sebagai langkah-langkah implisit. Mereka menawarkan kenyamanan bagi Anda sebagai pengembang model, karena dalam banyak kasus Anda tidak perlu membuat langkah-langkah. Misalnya, kolom Jumlah Penjualan penjual Adventure Works dapat diringkas dengan berbagai cara (jumlah, jumlah, rata-rata, median, min, maks, dll.), tanpa perlu membuat ukuran untuk setiap jenis agregasi yang mungkin.

Namun, ada tiga alasan menarik bagi Anda untuk mengambil langkah-langkah, bahkan untuk ringkasan tingkat kolom sederhana:

• Ketika Anda tahu penulis laporan Anda akan mengkueri model dengan menggunakan Ekspresi Multidmensional (MDX), model harus menyertakan langkah-langkah eksplisit. Langkah-langkah eksplisit ditentukan dengan menggunakan DAX. Pendekatan desain ini sangat relevan ketika himpunan data Power BI dikueri dengan menggunakan MDX, karena MDX tidak dapat mencapai ringkasan nilai kolom. Terutama, MDX akan digunakan saat melakukan Analisis di Excel, karena PivotTable mengeluarkan kueri MDX.
• Ketika Anda tahu penulis laporan Anda akan membuat laporan Power BI yang diberi nomor halamman menggunakan desainer kueri MDX, model harus menyertakan langkah-langkah eksplisit. Hanya desainer kueri MDX yang mendukung agregat server. Jadi, jika penulis laporan perlu memiliki langkah-langkah yang dievaluasi oleh Power BI (bukan oleh mesin laporan yang diberi nomor halaman), mereka harus menggunakan desainer kueri MDX.
• Saat Anda perlu memastikan bahwa penulis laporan Anda hanya dapat meringkas kolom dengan cara tertentu. Misalnya, kolom Harga Unit penjualan penjual (yang mewakili laju per unit) dapat diringkas, tetapi hanya dengan menggunakan fungsi agregasi tertentu. Ini tidak boleh dijumlahkan, tetapi tepat untuk meringkas dengan menggunakan fungsi agregasi lain seperti min, maks, rata-rata, dll. Dalam hal ini, pemodel dapat menyembunyikan kolom Harga Satuan, dan membuat pengukuran untuk semua fungsi agregasi yang sesuai.

Pendekatan desain ini berfungsi dengan baik untuk laporan yang ditulis dalam layanan Power BI dan untuk Tanya Jawab Umum. Namun, Power BI Desktop koneksi langsung memungkinkan penulis laporan menampilkan bidang tersembunyi di panel Bidang, yang dapat mengakibatkan menghindari pendekatan desain ini.

Kunci pengganti

Kunci pengganti adalah pengidentifikasi unik yang Anda tambahkan ke tabel untuk mendukung pemodelan skema bintang. Menurut definisi, kunci pengganti tidak ditentukan atau disimpan dalam data sumber. Umumnya, kunci pengganti ditambahkan ke tabel dimensi gudang data relasional untuk menyediakan pengidentifikasi unik untuk setiap baris tabel dimensi.

Power BI hubungan model didasarkan pada satu kolom unik dalam satu tabel, yang menyebarluaskan filter ke satu kolom dalam tabel yang berbeda. Saat tabel jenis dimensi dalam model Anda tidak menyertakan satu kolom unik, Anda harus menambahkan pengidentifikasi unik untuk menjadi sisi "satu" dari hubungan. Dalam Power BI Desktop, Anda dapat dengan mudah mencapai persyaratan ini dengan membuat kolom indeks Power Query.

Anda harus menggabungkan kueri ini dengan kueri sisi "banyak" sehingga Anda juga dapat menambahkan kolom indeks ke dalamnya. Saat Memuat kueri ini ke model, Anda kemudian dapat membuat hubungan satu-ke-banyak antara tabel model.

Dimensi Snowflake

Dimensi snowflake adalah kumpulan tabel yang dinormalisasi untuk satu entitas bisnis. Misalnya, Adventure Works mengklasifikasikan produk berdasarkan kategori dan subkategori. Kategori ditetapkan ke subkategori, dan produk pada gilirannya ditugaskan ke subkategori. Di gudang data relasional Adventure Works, dimensi produk dinormalisasi dan disimpan dalam tiga tabel terkait: DimProductCategory, DimProductSubcategory, dan DimProduct.

Jika Anda menggunakan imajinasi, Anda dapat menggambarkan tabel yang dinormalisasi yang diposisikan ke luar dari tabel fakta, membentuk desain snowflake.

Dalam Power BI Desktop, Anda dapat memilih untuk meniru desain dimensi snowflake (mungkin karena data sumber Anda melakukannya) atau mengintegrasikan (mendenormalisasi) tabel sumber ke dalam satu tabel model. Umumnya, manfaat tabel model tunggal melebihi manfaat dari beberapa tabel model. Keputusan yang paling optimal dapat bergantung pada volume data dan persyaratan kegunaan untuk model.

Saat Anda memilih untuk meniru desain dimensi snowflake:

• Power BI memuat lebih banyak tabel, yang kurang efisien dari perspektif penyimpanan dan performa. Tabel ini harus menyertakan kolom untuk mendukung hubungan model, dan dapat menghasilkan ukuran model yang lebih besar.
• Rantai penyebaran filter hubungan yang lebih panjang perlu dilalui, yang kemungkinan akan kurang efisien daripada filter yang diterapkan ke satu tabel.
• Panel Bidang menyajikan lebih banyak tabel model untuk melaporkan penulis, yang dapat menghasilkan pengalaman yang kurang intuitif, terutama ketika tabel dimensi snowflake hanya berisi satu atau dua kolom.
• Tidak dimungkinkan untuk membuat hierarki yang mencakup tabel.

Saat Anda memilih untuk berintegrasi ke dalam satu tabel model, Anda juga dapat menentukan hierarki yang mencakup butir dimensi tertinggi dan terendah. Mungkin, penyimpanan data denormalisasi redundan dapat mengakibatkan peningkatan ukuran penyimpanan model, terutama untuk tabel dimensi yang sangat besar.

Dimensi yang berubah secara perlahan

Dimensi yang berubah secara perlahan (SCD) adalah dimensi yang secara tepat mengelola perubahan anggota dimensi dari waktu ke waktu. Ini berlaku ketika nilai entitas bisnis berubah dari waktu ke waktu, dan secara ad hoc. Contoh dimensi yang berubah secara perlahan adalah dimensi pelanggan, khususnya kolom detail kontaknya seperti alamat email dan nomor telepon. Sebaliknya, beberapa dimensi dianggap berubah dengan cepat ketika atribut dimensi sering berubah, seperti harga pasar saham. Pendekatan desain umum dalam hal ini adalah untuk menyimpan nilai atribut yang berubah dengan cepat dalam ukuran tabel fakta.

Teori desain skema bintang mengacu pada dua jenis SCD umum: Jenis 1 dan Jenis 2. Tabel jenis dimensi dapat berupa Jenis 1 atau Jenis 2, atau mendukung kedua jenis tersebut secara bersamaan untuk kolom yang berbeda.

SCD Tipe 1

SCDJenis 1 selalu mencerminkan nilai terbaru, dan bila perubahan dalam data sumber terdeteksi, data tabel dimensi akan ditimpa. Pendekatan desain ini bersifat umum untuk kolom yang menyimpan nilai tambahan, seperti alamat email atau nomor telepon pelanggan. Saat alamat email pelanggan atau nomor telepon berubah, tabel dimensi memperbarui baris pelanggan dengan nilai baru. Seolah-olah pelanggan selalu memiliki informasi kontak ini.

Refresh yang tidak bertambah secara bertahap dari tabel jenis dimensi model Power BI mencapai hasil SCD Jenis 1. Jenis ini me-refresh data tabel untuk memastikan nilai terbaru dimuat.

SCD Tipe 2

SCDJenis 2 mendukung pembuatan versi anggota dimensi. Jika sistem sumber tidak menyimpan versi, maka biasanya proses beban gudang data yang mendeteksi perubahan, dan mengelola perubahan dalam tabel dimensi dengan tepat. Dalam hal ini, tabel dimensi harus menggunakan kunci pengganti untuk memberikan referensi unik ke versi anggota dimensi. Hal ini juga mencakup kolom yang menentukan validitas rentang tanggal versi (misalnya, StartDate dan EndDate) dan mungkin kolom bendera (misalnya, IsCurrent) untuk dengan mudah memfilter menurut anggota dimensi saat ini.

Misalnya, Adventure Works menugaskan staf penjualan ke wilayah penjualan. Saat staf penjualan memindahkan wilayah, versi staf penjualan baru harus dibuat untuk memastikan bahwa fakta historis tetap terkait dengan wilayah sebelumnya. Untuk mendukung analisis historis yang akurat tentang penjualan menurut staf penjualan, tabel dimensi harus menyimpan versi staf penjualan dan wilayah yang terkait. Tabel juga harus menyertakan nilai tanggal mulai dan berakhir untuk menentukan validitas waktu. Versi saat ini dapat menentukan tanggal akhir yang kosong (atau 31/12/9999), yang menunjukkan bahwa baris tersebut adalah versi saat ini. Tabel juga harus menentukan kunci pengganti karena kunci bisnis (dalam hal ini, ID karyawan) tidak akan unik.

Penting untuk dipahami bahwa ketika data sumber tidak menyimpan versi, Anda harus menggunakan sistem perantara (seperti gudang data) untuk mendeteksi dan menyimpan perubahan. Proses pemuatan tabel harus mempertahankan data yang ada dan mendeteksi perubahan. Ketika perubahan terdeteksi, proses pemuatan tabel akan berhenti menggunakan versi saat ini. Hal ini mencatat perubahan ini dengan memperbarui nilai EndDate dan memasukkan versi baru dengan nilai StartDate yang dimulai dari nilai EndDate sebelumnya. Selain itu, fakta terkait harus menggunakan pencarian berbasis waktu untuk mengambil nilai kunci dimensi yang relevan dengan tanggal fakta. Model Power BI menggunakan Power Query tidak dapat menghasilkan hasil ini. Namun, ini dapat memuat data dari tabel dimensi SCD Jenis 2 yang telah dimuat sebelumnya.

Model Power BI harus mendukung kueri data historis untuk anggota, terlepas dari perubahan, dan untuk versi anggota, yang mewakili status anggota tertentu pada waktunya. Dalam konteks Adventure Works, desain ini memungkinkan Anda untuk mengkueri staf penjualan terlepas dari wilayah penjualan yang ditetapkan, atau untuk versi tenaga penjualan tertentu.

Untuk mencapai persyaratan ini, tabel jenis dimensi model Power BI harus menyertakan kolom untuk memfilter tenaga penjualan, dan kolom yang berbeda untuk memfilter versi tenaga penjualan tertentu. Penting bahwa kolom versi menyediakan deskripsi non-ambigu, seperti "Michael Blythe (15/12/2008-06/26/2019)" atau "Michael Blythe (saat ini)". Penting juga untuk mendidik penulis laporan dan konsumen tentang dasar-dasar SCD Jenis 2, dan cara mencapai desain laporan yang sesuai dengan menerapkan filter yang benar.

Ini juga merupakan praktik desain yang baik untuk menyertakan hierarki yang memungkinkan visual menelusuri tingkat versi.

Dimensi pemutaran peran

Dimensi bermain peran adalah dimensi yang dapat memfilter fakta terkait secara berbeda. Misalnya, di Adventure Works, tabel dimensi tanggal memiliki tiga hubungan dengan fakta penjualan pengecer. Tabel dimensi yang sama dapat digunakan untuk memfilter fakta berdasarkan tanggal pemesanan, tanggal pengiriman, atau tanggal pengiriman.

Di gudang data, pendekatan desain yang diterima adalah menentukan tabel dimensi tanggal tunggal. Pada waktu kueri, "peran" dimensi tanggal ditetapkan oleh kolom fakta yang Anda gunakan untuk menggabungkan tabel. Misalnya, saat Anda menganalisis penjualan berdasarkan tanggal pesanan, gabungan tabel berkaitan dengan kolom tanggal pesanan penjualan penjual.

Dalam model Power BI, desain ini dapat ditiru dengan membuat beberapa hubungan antara dua tabel. Dalam contoh Adventure Works, tabel penjualan tanggal dan penjual akan memiliki tiga hubungan. Meskipun desain ini memungkinkan, penting untuk dipahami bahwa hanya ada satu hubungan aktif antara dua tabel model Power BI. Semua hubungan yang tersisa harus diatur ke tidak aktif. Memiliki satu hubungan aktif berarti ada penyebaran filter default dari tanggal ke penjualan penjual. Dalam hal ini, hubungan aktif diatur ke filter paling umum yang digunakan oleh laporan, yang di Adventure Works adalah hubungan tanggal pesanan.

Satu-satunya cara untuk menggunakan hubungan yang tidak aktif adalah dengan menentukan ekspresi DAX yang menggunakan fungsi USERELATIONSHIP. Dalam contoh kami, pengembang model harus membuat langkah-langkah untuk mengaktifkan analisis penjualan penjual berdasarkan tanggal pengiriman dan tanggal pengiriman. Pekerjaan ini bisa membosankan, terutama ketika tabel penjual mendefinisikan banyak langkah. Ini juga membuat kekacauan panel Bidang, dengan ukuran yang berlebihan. Ada batasan lain juga:

• Saat penulis laporan mengandalkan ringkasan kolom, daripada menentukan ukuran, penulis laporan tidak dapat mencapai ringkasan untuk hubungan yang tidak aktif tanpa menulis ukuran tingkat laporan. Pengukuran tingkat laporan hanya dapat ditentukan saat menulis laporan dalam Power BI Desktop.
• Dengan hanya satu jalur hubungan aktif antara tanggal dan penjualan penjual, tidak mungkin untuk memfilter penjualan penjual secara bersamaan dengan berbagai jenis tanggal. Misalnya, Anda tidak dapat menghasilkan visual yang membuat plot penjualan tanggal pesanan dengan penjualan yang dikirim.

Untuk mengatasi keterbatasan ini, teknik pemodelan Power BI umum adalah membuat tabel jenis dimensi untuk setiap instans pemutaran peran. Anda biasanya membuat tabel dimensi tambahan sebagai tabel terhitung, menggunakan DAX. Menggunakan tabel terhitung, model dapat berisi tabel Tanggal, tabel Tanggal Pengiriman, dan tabel Tanggal Pengiriman, masing-masing dengan hubungan tunggal dan aktif dengan kolom tabel penjualan penjual masing-masing.

Pendekatan desain ini tidak mengharuskan Anda untuk menentukan beberapa langkah untuk peran tanggal yang berbeda, dan memungkinkan pemfilteran simultan dengan peran tanggal yang berbeda. Namun, harga kecil untuk dibayar, dengan pendekatan desain ini adalah bahwa akan ada duplikasi tabel dimensi tanggal yang menghasilkan peningkatan ukuran penyimpanan model. Karena tabel jenis dimensi biasanya menyimpan lebih sedikit baris yang relatif terhadap tabel jenis fakta, itu jarang menjadi perhatian.

Amati praktik desain yang baik berikut saat Anda membuat tabel jenis dimensi model untuk setiap peran:

• Pastikan bahwa nama kolom dijelaskan sendiri. Meskipun dimungkinkan untuk memiliki kolom Tahun di semua tabel tanggal (nama kolom unik dalam tabelnya), kolom tersebut tidak menjelaskan sendiri dengan judul visual default. Pertimbangkan untuk mengganti nama kolom di setiap tabel peran dimensi, sehingga tabel Tanggal Pengiriman memiliki kolom tahun bernama Tahun Kapal, dll.
• Jika relevan, pastikan deskripsi tabel memberikan umpan balik kepada penulis laporan (melalui tips alat panel Bidang) tentang cara penyebaran filter dikonfigurasi. Kejelasan ini penting ketika model berisi tabel bernama umum, seperti Tanggal, yang digunakan untuk memfilter banyak tabel jenis fakta. Jika tabel ini memiliki, misalnya, hubungan aktif dengan kolom tanggal pesanan penjualan penjual, pertimbangkan untuk memberikan deskripsi tabel seperti "Memfilter penjualan penjual berdasarkan tanggal pesanan".

Untuk informasi selengkapnya, lihat Panduan hubungan aktif vs tidak aktif.

Dimensi sampah

Dimensi sampah berguna ketika ada banyak dimensi, terutama terdiri dari beberapa atribut (mungkin satu), dan ketika atribut ini memiliki beberapa nilai. Kandidat yang baik termasuk kolom status pesanan, atau kolom demografi pelanggan (jenis kelamin, kelompok usia, dll.).

Tujuan desain dimensi sampah adalah untuk mengonsolidasikan banyak dimensi "kecil" ke dalam satu dimensi untuk mengurangi ukuran penyimpanan model dan juga mengurangi kekacauan panel Bidang dengan memunculkan lebih sedikit tabel model.

Tabel dimensi sampah biasanya merupakan produk Kartesius dari semua anggota atribut dimensi, dengan kolom kunci pengganti. Kunci pengganti menyediakan referensi unik untuk setiap baris dalam tabel. Anda dapat membuat dimensi di gudang data, atau dengan menggunakan Power Query untuk membuat kueri yang melakukan gabungan kueri luar penuh, lalu menambahkan kunci pengganti (kolom indeks).

Anda memuat kueri ini ke model sebagai tabel jenis dimensi. Anda juga perlu menggabungkan kueri ini dengan kueri fakta, sehingga kolom indeks dimuat ke model untuk mendukung pembuatan hubungan model "satu-ke-banyak".

Dimensi degenerasi

Dimensi degenerasi mengacu pada atribut tabel fakta yang diperlukan untuk pemfilteran. Di Adventure Works, nomor pesanan penjualan penjual adalah contoh yang baik. Dalam hal ini, tidak masuk akal desain model yang baik untuk membuat tabel independen yang hanya terdiri dari kolom yang satu ini, karena akan meningkatkan ukuran penyimpanan model dan menghasilkan kekacauan panel Bidang.

Dalam model Power BI, mungkin tepat untuk menambahkan kolom nomor pesanan penjualan ke tabel jenis fakta untuk memungkinkan pemfilteran atau pengelompokan menurut nomor pesanan penjualan. Ini adalah pengecualian untuk aturan yang sebelumnya diperkenalkan bahwa Anda tidak boleh mencampur jenis tabel (umumnya, tabel model harus jenis dimensi atau jenis fakta).

Namun, jika tabel penjualan penjual Adventure Works memiliki kolom nomor pesanan dan nomor baris pesanan, dan diperlukan untuk pemfilteran, tabel dimensi yang merosok akan menjadi desain yang baik. Untuk informasi selengkapnya, lihat Panduan hubungan satu-ke-satu (Dimensi degenerasi).

Tabel fakta tanpa fakta

Tabel fakta tanpa fakta tidak menyertakan kolom pengukuran apa pun. Tabel ini hanya berisi kunci dimensi.

Tabel fakta tanpa fakta dapat menyimpan pengamatan yang ditentukan oleh kunci dimensi. Misalnya, pada tanggal dan waktu tertentu, pelanggan tertentu masuk ke situs web Anda. Anda dapat menentukan ukuran untuk menghitung baris tabel fakta tanpa fakta untuk melakukan analisis kapan dan berapa banyak pelanggan yang telah masuk.

Penggunaan tabel fakta yang lebih menarik adalah menyimpan hubungan antar dimensi, dan itu adalah pendekatan desain model Power BI yang kami sarankan untuk menentukan hubungan dimensi banyak ke banyak. Dalam desain hubungan dimensi banyak ke banyak, tabel fakta tanpa fakta disebut sebagai tabel bridging.

Misalnya, pertimbangkan bahwa tenaga penjualan dapat ditetapkan ke satu atau beberapa wilayah penjualan. Tabel bridging akan dirancang sebagai tabel fakta tanpa fakta yang terdiri dari dua kolom: kunci tenaga penjualan dan kunci wilayah. Nilai duplikat dapat disimpan di kedua kolom.

Pendekatan desain banyak ke banyak ini didokumentasikan dengan baik, dan dapat dicapai tanpa tabel bridging. Namun, pendekatan bridging table dianggap sebagai praktik terbaik saat berkaitan dengan dua dimensi. Untuk informasi selengkapnya, lihat Panduan hubungan banyak-ke-banyak (Menghubungkan dua tabel jenis dimensi).

Konten terkait

Untuk informasi selengkapnya tentang desain skema bintang atau desain model Power BI, lihat artikel berikut ini:

• Artikel Wikipedia tentang pemodelan dimensional
• Membuat dan mengelola hubungan di Power BI Desktop
• Panduan hubungan satu ke satu
• Panduan hubungan banyak ke banyak
• Panduan hubungan dua arah
• Panduan hubungan aktif vs tidak aktif
• Pertanyaan? Coba tanyakan kepada Komunitas Power BI
• Ada saran? Sumbang ide untuk meningkatkan Power BI