Rancang skema bintang untuk model semantik

  • 7 menit

Anda memilih bagaimana data mengalir ke model semantik Anda. Sekarang desain skema bintang yang mengorganisasikannya untuk kueri yang jelas dan berperforma baik. Skema bintang menghubungkan tabel fakta ke tabel dimensi melalui hubungan, menciptakan jalur filter yang menjadi dasar laporan dan konsumsi AI. Jika Anda terbiasa membangun skema bintang di Power BI Desktop, unit ini berfokus pada keputusan desain hubungan yang penting saat model tumbuh dalam kompleksitas dan skala.

Skema bintang dalam model semantik

Dalam skema bintang, tabel fakta menyimpan peristiwa bisnis terukur (seperti transaksi penjualan, baris pesanan, dan kunjungan web), dan tabel dimensi menyediakan konteks deskriptif (seperti detail produk, informasi pelanggan, dan atribut tanggal). Tabel dimensi memfilter tabel fakta melalui hubungan, yang memungkinkan pengguna untuk mengpotong metrik oleh atribut deskriptif apa pun.

Diagram memperlihatkan tabel fakta di tengah dan beberapa tabel dimensi yang disambungkan oleh hubungan yang diatur dalam bentuk seperti bintang.

Dalam model semantik Fabric, pola ini menyediakan penyebaran filter yang efisien untuk laporan dan konsumsi AI. Saat Copilot atau agen data menghasilkan kueri bahasa alami, skema bintang yang terorganisir dengan baik memberi AI jalur yang jelas ke data yang tepat. Hubungan ambigu atau melingkar membingungkan pengguna laporan dan perkakas AI.

Bagaimana mode penyimpanan memengaruhi hubungan

Hubungan dalam model semantik bersifat berbeda tergantung pada mode penyimpanan. Memahami perbedaan ini sangat penting untuk merancang skema bintang yang berkinerja baik di berbagai skenario.

Hubungan Danau Langsung

Dalam mode Direct Lake, mesin membaca hubungan langsung dari metadata tabel Delta. Hubungan berkinerja terbaik ketika:

  • Kolom kunci dimensi memiliki kardinalitas rendah relatif terhadap baris tabel fakta.
  • Integritas referensial dipertahankan dalam data sumber. Saat integritas referensial dipertahankan, mesin menggunakan INNER join daripada LEFT OUTER join, yang meningkatkan performa kueri.
  • Kolom yang digunakan dalam relasi diindeks dalam tabel Delta yang mendasar.

Note

Jika kueri melibatkan hubungan yang menyebabkan model melebihi batas memori atau menggunakan operasi yang tidak didukung, Direct Lake kembali ke DirectQuery, dan perilaku hubungan berubah agar sesuai dengan semantik DirectQuery.

Hubungan lintas sumber

Fabric model semantik dapat menyambungkan tabel dari repositori data yang berbeda. Tabel fakta dari lakehouse dapat memiliki hubungan dengan tabel dimensi dari gudang, atau dengan tabel yang diakses melalui endpoint analitik SQL. Koneksi lintas sumber ini menggunakan kemampuan model komposit.

Saat tabel berasal dari sumber yang berbeda, mode penyimpanan untuk setiap tabel menentukan cara kerja hubungan pada waktu kueri. Mesin menyelesaikan setiap sisi secara independen dan menggabungkan hasilnya.

Jenis hubungan

Hubungan satu ke banyak

Satu-ke-banyak adalah jenis hubungan yang paling umum dalam skema bintang. Satu nilai unik dalam tabel dimensi berkaitan dengan banyak baris dalam tabel fakta. Misalnya, satu baris produk dalam dimensi Produk cocok dengan ribuan baris pesanan dalam tabel Fakta penjualan.

Konfigurasikan hubungan satu ke banyak dengan arah filter yang mengalir dari dimensi (sisi "satu") ke tabel fakta (sisi "banyak"). Ini adalah pola filter skema bintang standar.

Hubungan banyak-ke-banyak

Hubungan banyak ke banyak diperlukan ketika tidak ada tabel yang memiliki nilai unik untuk kolom hubungan. Gunakan tabel jembatan untuk mengatasi hubungan ini. Tabel jembatan berada di antara dua tabel dan menyimpan kombinasi kunci unik dari kedua sisi.

Misalnya, jika pelanggan dapat memiliki beberapa akun dan akun dapat menjadi milik beberapa pelanggan, tabel jembatan Customer-Account menyelesaikan hubungan. Tabel jembatan memiliki relasi satu-ke-banyak dengan tabel Pelanggan dan Akun.

Orientasi filter

Di sebagian besar implementasi skema bintang, gunakan pemfilteran satu arah dari dimensi ke fakta. Ini menyediakan penyebaran filter yang dapat diprediksi dan menghindari ambiguitas dalam hasil kueri.

Pemfilteran dua arah terkadang diperlukan untuk hubungan banyak-ke-banyak atau ketika tabel dimensi perlu difilter berdasarkan nilai dalam tabel fakta. Gunakan filter dua arah dengan hemat karena dapat menurunkan performa kueri dan membuat perilaku filter yang tidak terduga dalam laporan.

Integritas referensial

Pengaturan Asumsikan integritas referensial memberi tahu mesin untuk menggunakan gabungan INNER daripada gabungan LEFT OUTER saat mengkueri dalam suatu hubungan. Dalam mode Direct Lake dan DirectQuery, pengaturan ini dapat secara signifikan meningkatkan performa karena mengurangi jumlah baris yang diproses mesin.

Aktifkan pengaturan ini saat Anda yakin bahwa setiap nilai kunci asing dalam tabel fakta memiliki nilai yang cocok dalam tabel dimensi. Jika integritas referensial dilanggar, baris dengan kunci yang tidak cocok menghilang secara diam-diam dari hasil kueri.

Hubungan tidak aktif dan USERELATIONSHIP

Hanya satu hubungan aktif yang dapat ada di antara dua tabel pada satu waktu. Saat Anda memerlukan beberapa jalur hubungan (seperti tanggal pesanan dan tanggal pengiriman yang keduanya berkaitan dengan dimensi Tanggal yang sama), buat satu hubungan aktif dan yang lain tidak aktif.

USERELATIONSHIP Gunakan fungsi di DAX untuk mengaktifkan hubungan yang tidak aktif dalam perhitungan:

Shipped Amount =
CALCULATE(
    SUM(Sales[Amount]),
    USERELATIONSHIP(Sales[ShipDate], 'Date'[Date])
)

Pola ini menjaga model tetap bersih sambil mendukung beberapa perspektif analitis pada data yang sama.

Menangani skema snowflake dalam model semantik

Data sumber sering tiba dalam skema snowflake yang dinormalisasi, di mana tabel dimensi dibagi menjadi beberapa tabel terkait. Misalnya, dimensi Produk mungkin dipisahkan menjadi tabel Produk, Subkategori, dan Kategori, masing-masing ditautkan melalui kunci asing.

Dalam model semantik, Anda memiliki dua opsi: meratakan kepingan salju menjadi skema bintang, atau mempertahankan struktur yang dinormalisasi.

Meratakan ke dalam skema bintang

Meratakan berarti menggabungkan tabel dimensi yang dinormalisasi ke dalam satu tabel dimensi denormalisasi. Tabel Produk akan menyertakan kolom Subkategori dan Kategori secara langsung, menghilangkan tabel dan hubungan tambahan.

Lakukan perataan ketika:

  • Tabel dimensi gabungan masih kecil relatif terhadap tabel fakta (yang hampir selalu terjadi untuk dimensi).
  • Anda ingin jalur filter yang lebih sederhana dari dimensi ke fakta. Setiap filter bergerak melalui satu hubungan alih-alih rantai.
  • Konsumsi AI adalah prioritas. Lebih sedikit tabel dan hubungan yang lebih sederhana memberi Copilot dan agen data jalur yang lebih jelas ke data yang tepat.

Meratakan tabel dimensi selama persiapan data di lakehouse atau alur data, sebelum data mencapai model semantik. Gunakan gabungan Power Query, gabungan SQL, atau transformasi buku catatan untuk menggabungkan tabel yang dinormalisasi ke dalam satu dimensi.

Pertahankan struktur keping salju

Dalam beberapa kasus, menjaga struktur yang dinormalisasi masuk akal:

  • Hierarki dimensi memiliki beberapa tingkat, dan meratakan akan membuat puluhan kolom redundan.
  • Beberapa tabel fakta berbagi tabel subdimensi (seperti tabel Kategori yang digunakan bersama dalam fakta Penjualan dan Inventaris), dan denormalisasi akan menciptakan salinan yang tidak konsisten.
  • Keamanan tingkat baris perlu diterapkan pada tingkat tertentu dalam hierarki.

Saat Anda mempertahankan struktur snowflake, konfigurasikan hubungan dengan hati-hati. Setiap hubungan dalam rantai harus menggunakan pemfilteran satu arah dari tabel terluar menuju tabel fakta sehingga filter menyebar dengan benar. Filter pada Kategori perlu mengalir melalui Subkategori, lalu melalui Produk, dan ke dalam tabel fakta.

Note

Dalam sebagian besar skenario model semantik, meratakan dimensi menjadi skema bintang adalah pilihan yang lebih baik. Lebih sedikit tabel berarti lebih sedikit hubungan, DAX yang lebih sederhana, kueri yang lebih cepat, dan konsumsi AI yang lebih baik. Pertahankan struktur kepingan salju hanya ketika ada alasan kuat untuk menyimpannya.

Kapan menggunakan model komposit untuk skenario lintas sumber

Gunakan model komposit saat skema bintang Anda mencakup beberapa penyimpanan data Fabric atau menyertakan sumber eksternal. Skenario umum meliputi:

  • Tabel fakta di lakehouse dengan tabel dimensi dipertahankan di gudang.
  • Streaming data real-time dari pusat acara dikombinasikan dengan data historis di lakehouse.
  • Data referensi dari sumber eksternal (Impor) dikombinasikan dengan tabel fakta asli Fabric (Direct Lake).

Dalam skenario ini, konfigurasikan mode penyimpanan untuk setiap tabel secara independen dan verifikasi bahwa hubungan lintas sumber berfungsi dengan baik pada volume data yang Diharapkan.