Baca dalam bahasa Inggris

Bagikan melalui


Memahami skema bintang dan pentingnya Power BI

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

Penting

Model semantik Power BI bergantung pada Power Query untuk mengimpor atau menyambungkan ke data. Itu berarti Anda harus menggunakan Power Query untuk mengubah dan menyiapkan data sumber, yang mungkin menantang ketika Anda memiliki volume data besar atau Anda perlu menerapkan konsep tingkat lanjut seperti mengubah dimensi secara perlahan (dijelaskan nanti di artikel ini).

Saat Anda dihadapkan dengan tantangan ini, kami sarankan Anda terlebih dahulu mengembangkan proses gudang data dan Ekstrak, Transformasi, dan Muat (ETL) untuk memuat gudang data secara berkala. Model semantik Anda kemudian dapat terhubung ke gudang data. Untuk informasi selengkapnya, lihat Pemodelan dimensi di Microsoft Fabric Warehouse.

Tip

Artikel ini tidak dimaksudkan untuk memberikan diskusi lengkap tentang desain skema bintang. Untuk informasi selengkapnya, lihat langsung ke konten yang diterbitkan secara luas, 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 lainnya. Kolom lain mendukung pemfilteran dan pengelompokan data Anda.
  • Tabel fakta menyimpan pengamatan atau peristiwa, dan dapat berupa pesanan penjualan, saldo saham, nilai tukar, suhu, dan banyak lagi. 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 dirancang untuk menyimpan target penjualan yang memiliki dua kolom Date kunci dimensi 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 dalam Date kolom 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 sejumlah besar baris dan terus bertambah dari waktu ke waktu.

Diagram memperlihatkan ilustrasi skema bintang.

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 lain yang menjelaskan karakteristik produk, seperti nama produk, kategori, warna, dan ukuran. Tabel penjualan dianggap dinormalisasi ketika hanya menyimpan kunci, seperti kunci produk. Dalam gambar berikut, perhatikan bahwa hanya kolom yang ProductKey merekam produk.

Diagram memperlihatkan tabel data yang menyertakan kolom Kunci 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.

Diagram memperlihatkan tabel data yang menyertakan Kunci Produk dan kolom terkait produk lainnya, termasuk Kategori, Warna, dan Ukuran.

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 semantik Power BI yang dioptimalkan dengan tabel yang mewakili fakta dan data dimensi yang dinormalisasi. Namun, ada satu pengecualian di mana dimensi snowflake mungkin didenormalisasi untuk menghasilkan satu tabel model.

Relevansi skema bintang dengan model semantik 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 semantik Power BI. Umumnya, kueri 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 memungkinkan pemfilteran dan pengelompokan.
  • Tabel fakta mengaktifkan ringkasan.

Tidak ada properti tabel yang diatur pemodel untuk mengatur jenis tabel sebagai dimensi atau fakta. Hal ini sebenarnya ditentukan oleh hubungan model. Hubungan model menetapkan jalur penyebaran filter antara dua tabel, dan itu adalah properti kardinalitas hubungan yang menentukan jenis tabel. Kardinalitas hubungan yang sama adalah satu-ke-banyak atau kebalikannya banyak-ke-satu. Sisi "satu" selalu merupakan tabel dimensi sementara sisi "banyak" selalu merupakan tabel fakta.

Diagram memperlihatkan ilustrasi konseptual skema bintang.

Desain model yang terstruktur dengan baik mencakup tabel yang merupakan tabel dimensi atau tabel fakta. Hindari mencampur dua jenis bersama-sama untuk satu tabel. Kami juga menyarankan agar Anda berusaha untuk memberikan jumlah tabel yang tepat dengan hubungan yang tepat. Penting juga bahwa tabel 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 yang terkait dengan desain skema bintang yang dapat diterapkan ke model semantik Power BI. Konsep-konsep ini meliputi:

Tindakan

Dalam desain skema bintang, ukuran adalah kolom tabel fakta yang menyimpan nilai yang akan diringkas. Dalam model semantik Power BI, pengukuran memiliki definisi yang berbeda—tetapi serupa—. Model mendukung langkah-langkah eksplisit dan implisit.

  • Langkah-langkah eksplisit dibuat secara tegas dan didasarkan pada rumus yang ditulis dalam Ekspresi Analisis Data (DAX) yang mencapai ringkasan. Mengukur ekspresi sering menggunakan fungsi agregasi DAX seperti SUM, , MIN, MAXAVERAGE, dan lainnya 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 tentang Dasar-Dasar DAX di Power BI Desktop.
  • Pengukuran implisit adalah kolom yang dapat diringkas oleh visual laporan atau Tanya Jawab. Mereka menawarkan kenyamanan bagi Anda sebagai pengembang model, karena dalam banyak instans Anda tidak perlu membuat langkah-langkah (eksplisit). Misalnya, kolom penjualan Sales Amount penjual Adventure Works dapat dirangkum dengan berbagai cara (jumlah, jumlah, rata-rata, median, min, maks, dan lainnya), tanpa perlu membuat ukuran untuk setiap jenis agregasi yang mungkin.

Di panel Data , langkah-langkah eksplisit diwakili oleh ikon kalkulator sementara ukuran implisit diwakili oleh simbol sigma (∑).

Diagram memperlihatkan ikon yang ditemukan di panel Data.

Namun, ada tiga alasan menarik mengapa Anda dapat membuat langkah-langkah, bahkan untuk ringkasan tingkat kolom sederhana:

  • Ketika Anda tahu penulis laporan Anda akan mengkueri model semantik dengan menggunakan Ekspresi Multidmensional (MDX), model harus menyertakan langkah-langkah eksplisit. Itu karena MDX tidak dapat mencapai ringkasan nilai kolom. Terutama, MDX digunakan saat melakukan Analisis di Excel karena PivotTable mengeluarkan kueri MDX.

  • Saat Anda mengetahui penulis laporan Anda akan membuat laporan paginasi Power BI dengan menggunakan perancang kueri MDX, model semantik 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 ingin mengontrol bagaimana penulis laporan Meringkas kolom dengan cara tertentu. Misalnya, kolom penjualan Unit Price 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, atau rata-rata. Dalam hal ini, pemodel dapat menyembunyikan Unit Price kolom, 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, koneksi langsung Power BI Desktop memungkinkan penulis laporan menampilkan bidang tersembunyi di panel Data, 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.

Hubungan model semantik Power BI didasarkan pada satu kolom unik dalam satu tabel, yang menyebarluaskan filter ke satu kolom dalam tabel yang berbeda. Saat tabel dimensi dalam model semantik Anda tidak menyertakan satu kolom unik, Anda harus menambahkan pengidentifikasi unik untuk menjadi sisi "satu" hubungan. Di Power BI Desktop, Anda bisa mencapai persyaratan ini dengan menambahkan kolom indeks Power Query.

Diagram memperlihatkan perintah Buat kolom indeks di Editor Power Query.

Anda harus menggabungkan kueri ini dengan kueri sisi "banyak" sehingga Anda juga dapat menambahkan kolom indeks ke dalamnya. Saat Anda memuat kueri ini ke model semantik, 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.

Diagram memperlihatkan contoh diagram snowflake yang terdiri dari tiga tabel terkait.

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

Diagram memperlihatkan contoh konseptual diagram snowflake yang terdiri dari tiga tabel terkait.

Di Power BI Desktop, Anda dapat memilih untuk meniru desain dimensi snowflake (mungkin karena data sumber Anda tidak) atau menggabungkan tabel sumber untuk membentuk tabel model tunggal yang didenormalisasi. 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 lama perlu dilalui, yang mungkin kurang efisien daripada filter yang diterapkan ke satu tabel.
  • Panel Data 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 terdiri dari kolom dari lebih dari satu 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 besar.

Diagram memperlihatkan contoh hierarki dalam tabel dimensi yang memiliki kolom seperti Kategori, Subkategori, dan Produk.

Dimensi yang berubah secara perlahan

Dimensi yang berubah secara perlahan (atau SCD) adalah dimensi yang mengelola perubahan anggota dimensi dengan tepat dari waktu ke waktu. Ini berlaku ketika nilai entitas bisnis berubah lambat dari waktu ke waktu dengan cara yang tidak diencana. Contoh yang baik dari SCD adalah dimensi pelanggan, karena kolom detail kontaknya seperti alamat email dan nomor telepon jarang berubah. 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 dimensi dapat berupa Tipe 1 atau Tipe 2, atau mendukung kedua jenis secara bersamaan untuk kolom yang berbeda.

SCD Tipe 1

SCD Tipe 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.

Diagram memperlihatkan contoh dimensi yang berubah secara perlahan jenis 1 di mana nomor telepon karyawan diperbarui.

Refresh non-inkremental tabel dimensi model Power BI mencapai hasil SCD Tipe 1. Jenis ini me-refresh data tabel untuk memastikan nilai terbaru dimuat.

SCD Tipe 2

SCD Tipe 2 mendukung pembuatan versi anggota dimensi. Jika sistem sumber tidak menyimpan versi, 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 menetapkan setiap tenaga penjual 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 mungkin menentukan tanggal akhir kosong (atau 31/12/9999), yang menunjukkan bahwa baris adalah versi saat ini. Tabel juga harus memiliki kunci pengganti karena kunci bisnis (dalam hal ini, ID karyawan) tidak akan unik.

Diagram memperlihatkan contoh dimensi tipe 2 yang berubah secara perlahan di mana wilayah penjualan karyawan diperbarui dengan membuat versi baru.

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 semantik Power BI menggunakan Power Query, sehingga tidak dapat menghasilkan hasil ini. Namun, ini dapat memuat data dari tabel dimensi SCD Jenis 2 yang telah dimuat sebelumnya.

Tip

Untuk mempelajari cara menerapkan tabel dimensi SCD Tipe 2 di gudang Fabric, lihat Mengelola perubahan historis.

Model semantik Power BI harus mendukung kueri data historis untuk anggota, terlepas dari perubahan, dan untuk versi anggota, yang mewakili status anggota tertentu tepat waktu. 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 dimensi model semantik 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 David Campbell (12/15/2008-06/26/2019) atau David Campbell (06/27/2019-Current). 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 adalah praktik desain yang baik untuk menyertakan hierarki yang memungkinkan visual menelusuri tingkat versi.

Diagram memperlihatkan panel Data dengan kolom untuk Salesperson dan Versi Salesperson.

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 penjual. Tabel dimensi yang sama dapat digunakan untuk memfilter fakta berdasarkan tanggal pemesanan, tanggal pengiriman, atau tanggal pengiriman.

Diagram memperlihatkan contoh konseptual dimensi dan hubungan peran tunggal. Tabel Tanggal memiliki dua hubungan dengan tabel fakta untuk tanggal pesanan dan 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 semantik Power BI, desain ini dapat ditiru dengan membuat beberapa hubungan di antara dua tabel. Dalam contoh Adventure Works, tabel penjualan tanggal dan penjual akan memiliki tiga hubungan.

Diagram memperlihatkan contoh dimensi dan hubungan peran tunggal. Tabel Tanggal memiliki tiga hubungan dengan tabel fakta.

Meskipun desain ini dimungkinkan, hanya ada satu hubungan aktif antara dua tabel model semantik 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 panel Data yang berantakan yang memiliki 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 dimensi untuk setiap instans pemutaran peran. Anda bisa membuat setiap tabel dimensi sebagai kueri referensi menggunakan Power Query, atau tabel terhitung menggunakan DAX. Model dapat berisi Date tabel, tabel, Ship Date dan Delivery Date tabel, masing-masing dengan hubungan tunggal dan aktif dengan kolom tabel penjualan penjual masing-masing.

Diagram memperlihatkan contoh dimensi dan hubungan bermain peran. Ada tiga tabel dimensi tanggal berbeda yang terkait dengan tabel fakta.

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 dimensi biasanya menyimpan lebih sedikit baris yang relatif terhadap tabel fakta, itu jarang menjadi perhatian.

Kami sarankan Anda mengikuti praktik desain yang baik saat membuat tabel dimensi model untuk setiap peran:

  • Pastikan bahwa nama kolom dijelaskan sendiri. Meskipun dimungkinkan untuk memiliki Year kolom 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 Ship Date tabel memiliki kolom tahun bernama Ship Year, dan sebagainya.
  • Jika relevan, pastikan deskripsi tabel memberikan umpan balik kepada penulis laporan (melalui tipsalat panel Data ) tentang cara penyebaran filter disiapkan. Kejelasan ini penting ketika model berisi tabel bernama generis, seperti Date, yang digunakan untuk memfilter banyak tabel fakta. Jika tabel ini memiliki, misalnya, hubungan aktif dengan kolom tanggal pesanan penjualan penjual, pertimbangkan untuk memberikan deskripsi tabel seperti Filters reseller sales by order date.

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 seperti jenis kelamin atau kelompok usia.

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

Tabel dimensi sampah biasanya merupakan produk Kartesius dari semua anggota atribut dimensi, dengan kolom kunci pengganti untuk mengidentifikasi setiap baris secara unik. 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).

Diagram memperlihatkan contoh tabel dimensi sampah. Status Pesanan memiliki tiga status sementara Status Pengiriman memiliki dua status. Tabel dimensi sampah menyimpan keenam kombinasi dari dua status.

Anda memuat kueri ini ke model sebagai tabel 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 untuk membuat tabel independen yang hanya terdiri dari kolom yang satu ini karena akan meningkatkan ukuran penyimpanan model dan mengakibatkan kekacauan panel Data .

Dalam model semantik Power BI, mungkin sesuai untuk menambahkan kolom nomor pesanan penjualan ke tabel 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 berupa dimensi atau fakta).

Diagram memperlihatkan panel Data dan tabel fakta penjualan, yang menyertakan bidang Nomor Pesanan.

Namun, jika tabel penjualan penjual Adventure Works memiliki kolom nomor pesanan dan nomor baris pesanan, dan diperlukan untuk pemfilteran, membuat 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 masuk.

Penggunaan tabel fakta yang lebih menarik adalah menyimpan hubungan antar dimensi, dan ini adalah pendekatan desain model semantik 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.

Diagram memperlihatkan tabel fakta tanpa fakta menjembatani dimensi Salesperson dan Region. Tabel fakta tanpa fakta terdiri dari dua kolom, yang merupakan kunci dimensi.

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).

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