Bagikan melalui

Menggunakan model komposit di Power BI Desktop

  • Artikel

Sebelumnya di Power BI Desktop, saat Anda menggunakan DirectQuery dalam laporan, tidak ada koneksi data lain, baik DirectQuery atau impor, yang diizinkan untuk laporan tersebut. Dengan model komposit, pembatasan tersebut dihapus. Laporan dapat dengan mulus menyertakan koneksi data dari lebih dari satu DirectQuery atau mengimpor koneksi data, dalam kombinasi apa pun yang Anda pilih.

Kemampuan model komposit di Power BI Desktop terdiri dari tiga fitur terkait:

  • Model komposit: Memungkinkan laporan memiliki dua atau beberapa koneksi data dari grup sumber yang berbeda. Grup sumber ini dapat berupa satu atau beberapa koneksi DirectQuery dan koneksi impor, dua atau beberapa koneksi DirectQuery, atau kombinasi apa pun darinya. Artikel ini menjelaskan model komposit secara rinci.

  • Hubungan banyak ke banyak: Dengan model komposit, Anda dapat membuat hubungan banyak ke banyak antar tabel. Pendekatan ini menghapus persyaratan untuk nilai unik dalam tabel. Pendekatan tersebut juga menghapus solusi sebelumnya, seperti memperkenalkan tabel baru hanya untuk membangun hubungan. Untuk informasi selengkapnya, lihat Menerapkan relasi banyak ke banyak di Power BI Desktop.

  • Mode penyimpanan: Anda sekarang dapat menentukan visual mana yang mengkueri sumber data back-end. Fitur ini membantu meningkatkan performa dan mengurangi beban back-end. Sebelumnya, bahkan visual sederhana, seperti pemotong, memulai kueri ke sumber back-end. Untuk informasi selengkapnya, lihat Mengelola mode penyimpanan di Power BI Desktop.

Menggunakan model komposit

Dengan model komposit, Anda dapat terhubung ke berbagai jenis sumber data saat menggunakan Power BI Desktop atau layanan Power BI. Anda dapat membuat koneksi data tersebut dalam beberapa cara:

  • Dengan mengimpor data ke Power BI, yang merupakan cara paling umum untuk mendapatkan data.
  • Dengan menyambungkan langsung ke data di repositori sumber aslinya menggunakan DirectQuery. Untuk mempelajari selengkapnya tentang DirectQuery, lihat DirectQuery di Power BI.

Saat Anda menggunakan DirectQuery, model komposit memungkinkan untuk membuat model Power BI, seperti satu file .pbix Power BI Desktop yang melakukan salah satu atau kedua tindakan berikut:

  • Menggabungkan data dari satu atau beberapa sumber DirectQuery.
  • Menggabungkan data dari sumber DirectQuery dan mengimpor data.

Misalnya, dengan menggunakan model komposit, Anda dapat membuat model yang menggabungkan jenis data berikut:

  • Data penjualan dari gudang data perusahaan.
  • Data target penjualan dari database SQL Server departemen.
  • Data yang diimpor dari spreadsheet.

Model yang menggabungkan data dari lebih dari satu sumber DirectQuery atau yang menggabungkan DirectQuery dengan data impor disebut model komposit.

Anda dapat membuat hubungan antar tabel seperti biasa, bahkan ketika tabel tersebut berasal dari sumber yang berbeda. Setiap hubungan yang lintas sumber dibuat dengan kardinalitas banyak-ke-banyak, terlepas dari kardinalitas yang sebenarnya. Anda dapat mengubahnya menjadi satu-ke-banyak, banyak-ke-satu, atau satu-ke-satu. Kardinalitas apa pun yang Anda tetapkan, hubungan lintas sumber memiliki perilaku yang berbeda. Anda tidak dapat menggunakan fungsi Data Analysis Expressions (DAX) untuk mengambil nilai di sisi one dari sisi many. Anda mungkin juga melihat dampak performa versus hubungan banyak-ke-banyak dalam sumber yang sama.

Catatan

Dalam konteks model komposit, semua tabel yang diimpor secara efektif adalah satu sumber, terlepas dari sumber data dasar yang sebenarnya.

Contoh model komposit

Untuk contoh model komposit, pertimbangkan laporan yang terhubung ke gudang data perusahaan di SQL Server dengan menggunakan DirectQuery. Dalam hal ini, gudang data berisi data Penjualan menurut Negara, Kuartal, dan Sepeda (Produk), seperti yang ditunjukkan pada gambar berikut:

Cuplikan layar contoh dengan model komposit dalam tampilan Hubungan.

Pada titik ini, Anda dapat membangun visual sederhana dengan menggunakan bidang dari sumber ini. Gambar berikut menunjukkan total penjualan menurut ProductName, untuk kuartal yang dipilih.

Cuplikan layar visual berdasarkan data dari contoh sebelumnya.

Tetapi bagaimana jika Anda memiliki data dalam lembar bentang Excel tentang manajer produk yang ditetapkan untuk setiap produk, bersama dengan prioritas pemasaran? Jika Anda ingin melihat Jumlah Penjualan menurut Manajer Produk, mungkin tidak dapat menambahkan data lokal ini ke gudang data perusahaan. Atau mungkin butuh waktu berbulan-bulan.

Dimungkinkan untuk mengimpor data penjualan tersebut dari gudang data, alih-alih menggunakan DirectQuery. Dan data penjualan kemudian dapat dikombinasikan dengan data yang Anda impor dari spreadsheet. Namun, pendekatan itu tidak masuk akal, karena alasan yang menyebabkan penggunaan DirectQuery di tempat pertama. Alasannya bisa jadi:

  • Beberapa kombinasi aturan keamanan yang diberlakukan di sumber dasar.
  • Kebutuhan untuk dapat melihat data terbaru.
  • Skala data yang sangat besar.

Di sinilah peran model komposit. Model komposit memungkinkan Anda terhubung ke gudang data dengan menggunakan DirectQuery lalu menggunakan Dapatkan data untuk sumber lainnya. Dalam contoh ini, pertama-tama kami membuat koneksi DirectQuery ke gudang data perusahaan. Kami menggunakan Dapatkan data, pilih Excel, lalu membuka spreadsheet yang berisi data lokal kami. Terakhir, kami mengimpor spreadsheet yang berisi Nama Produk, Manajer Penjualan yang ditetapkan, dan Prioritas.

Cuplikan layar jendela navigator setelah memilih file excel sebagai sumber.

Di daftar Bidang, Anda dapat melihat dua tabel: tabel Sepeda asli dari SQL Server dan tabel ProductManagers baru. Tabel baru berisi data yang diimpor dari Excel.

Cuplikan layar panel Bidang dengan bidang Sepeda dan ProductManagers dipilih.

Demikian pula, dalam tampilan Hubungan di Power BI Desktop, kita sekarang melihat tabel lain yang disebut ProductManagers.

Cuplikan layar tabel dalam tampilan Hubungan.

Sekarang kita perlu menghubungkan tabel ini dengan tabel lain dalam model. Seperti biasa, kita membuat hubungan antara tabel Sepeda dari SQL Server dan tabel ProductManagers yang diimpor. Artinya, hubungannya antara Bike[ProductName] dan ProductManagers[ProductName]. Seperti yang dibahas sebelumnya, semua hubungan yang melintasi sumber default ke kardinalitas banyak-ke-banyak.

Cuplikan layar jendela Buat hubungan.

Sekarang setelah dibuat, hubungan ini ditampilkan dalam tampilan Hubungan di Power BI Desktop, seperti yang diharapkan.

Cuplikan layar jendela Buat hubungan setelah hubungan baru dibuat.

Sekarang kita dapat membuat visual dengan menggunakan salah satu bidang di daftar Bidang. Pendekatan ini memadukan data dengan mulus dari berbagai sumber. Misalnya, total SalesAmount untuk setiap Manajer Produk ditampilkan pada gambar berikut:

Cuplikan layar panel Bidang dengan SalesAmount disorot dan visual ditampilkan.

Contoh berikut menampilkan kasus umum tabel dimensi, seperti Produk atau Pelanggan, yang diperluas dengan beberapa data tambahan yang diimpor dari tempat lain. Tabel juga dapat menggunakan DirectQuery untuk terhubung ke berbagai sumber. Untuk melanjutkan contoh kami, bayangkan bahwa Target Penjualan per Negara dan Periode disimpan dalam database departemen terpisah. Seperti biasa, Anda dapat menggunakan Dapatkan data untuk menyambungkan ke data tersebut, seperti yang ditunjukkan pada gambar berikut:

Cuplikan layar jendela Navigator dengan target penjualan dipilih.

Seperti yang kita lakukan sebelumnya, kita dapat membuat hubungan antara tabel baru dan tabel lain dalam model. Kemudian kita dapat membuat visual yang menggabungkan data tabel. Mari kita lihat lagi tampilan Hubungan, tempat kita telah membuat hubungan baru:

Cuplikan layar tampilan Hubungan dengan banyak tabel.

Gambar berikutnya didasarkan pada data dan hubungan baru yang kita buat. Visual di kiri bawah menunjukkan total Jumlah Penjualan versus Target, dan perhitungan varians menunjukkan perbedaannya. Data Jumlah Penjualan dan Target berasal dari dua database SQL Server yang berbeda.

Cuplikan layar tampilan Laporan dengan lebih banyak data.

Mengatur mode penyimpanan

Setiap tabel dalam model komposit memiliki mode penyimpanan yang menunjukkan apakah tabel didasarkan pada DirectQuery atau impor. Mode penyimpanan dapat dilihat dan dimodifikasi di panel Properti. Untuk menampilkan mode penyimpanan, klik kanan tabel di daftar Bidang, lalu pilih Properti. Gambar berikut menunjukkan mode penyimpanan untuk tabel SalesTargets.

Mode penyimpanan juga dapat dilihat di tooltip untuk setiap tabel.

Cuplikan layar tipsalat yang menampilkan mode penyimpanan.

Untuk file Power BI Desktop apa pun (file .pbix) yang berisi beberapa tabel dari DirectQuery dan beberapa tabel impor, bilah status menampilkan mode penyimpanan yang disebut Campuran. Anda dapat memilih istilah tersebut di bilah status dan dengan mudah mengalihkan semua tabel untuk diimpor.

Untuk informasi selengkapnya tentang mode penyimpanan, lihat Mengelola mode penyimpanan di Power BI Desktop.

Catatan

Anda dapat menggunakan mode penyimpanan Campuran di Power BI Desktop dan di layanan Power BI.

Tabel terhitung

Anda bisa menambahkan tabel terhitung ke model di Power BI Desktop yang menggunakan DirectQuery. Data Analysis Expressions (DAX) yang menentukan tabel terhitung dapat mereferensikan tabel impor atau DirectQuery atau kombinasi keduanya.

Tabel terhitung selalu diimpor, dan datanya di-refresh saat Anda me-refresh tabel. Jika tabel terhitung mengacu pada tabel DirectQuery, visual yang merujuk ke tabel DirectQuery selalu menampilkan nilai terbaru di sumber dasar. Atau, visual yang merujuk ke tabel terhitung menampilkan nilai pada saat tabel terhitung terakhir di-refresh.

Penting

Tabel terhitung tidak didukung di layanan Power BI menggunakan fitur ini kecuali Anda memenuhi persyaratan tertentu. Untuk informasi selengkapnya tentang ini, lihat bagian Bekerja dengan model komposit berdasarkan model semantik di artikel ini.

Implikasi keamanan

Model komposit memiliki beberapa implikasi keamanan. Kueri yang dikirim ke satu sumber data dapat disertai nilai data yang telah diambil dari sumber lain. Dalam contoh sebelumnya, visual yang menampilkan (Jumlah Penjualan) oleh Manajer Produk mengirimkan kueri SQL ke database relasional Penjualan. Kueri SQL tersebut mungkin berisi nama Manajer Produk dan Produk terkait.

Cuplikan layar skrip yang memperlihatkan implikasi keamanan.

Jadi, informasi yang disimpan dalam spreadsheet sekarang disertakan dalam kueri yang dikirim ke database relasional. Jika informasi ini bersifat rahasia, Anda harus mempertimbangkan implikasi keamanan. Khususnya, pertimbangkan poin-poin berikut:

  • Setiap administrator database yang dapat melihat jejak atau log audit dapat melihat informasi ini, bahkan tanpa izin ke data di sumber aslinya. Dalam contoh ini, administrator akan memerlukan izin ke file Excel.

  • Pengaturan enkripsi untuk setiap sumber harus dipertimbangkan. Anda ingin menghindari pengambilan informasi dari satu sumber oleh koneksi terenkripsi lalu secara tidak sengaja menyertakannya dalam kueri yang dikirim ke sumber lain oleh koneksi yang tidak terenkripsi.

Untuk mengonfirmasi bahwa Anda telah mempertimbangkan implikasi keamanan apa pun, Power BI Desktop menampilkan pesan peringatan saat Anda membuat model komposit.

Selain itu, jika penulis menambahkan Table1 dari Model A ke Model Komposit (sebut saja Model C untuk referensi), pengguna yang melihat laporan yang dibangun di Model C dapat mengkueri tabel apa pun di Model A yang tidak dilindungi oleh RLS keamanan tingkat baris.

Untuk alasan serupa, berhati-hatilah saat Anda membuka file Power BI Desktop yang dikirim dari sumber yang tidak tepercaya. Jika file berisi model komposit, informasi yang diambil seseorang dari satu sumber, dengan menggunakan kredensial pengguna yang membuka file, akan dikirim ke sumber data lain sebagai bagian dari kueri. Informasi tersebut dapat dilihat oleh penulis berbahaya dari file Power BI Desktop. Saat Anda awalnya membuka file Power BI Desktop yang berisi beberapa sumber, Power BI Desktop menampilkan peringatan. Peringatan mirip dengan yang ditampilkan saat Anda membuka file yang berisi kueri SQL asli.

Implikasi kinerja

Saat Anda menggunakan DirectQuery, Anda harus selalu mempertimbangkan performa, terutama untuk memastikan bahwa sumber back-end memiliki sumber daya yang memadai untuk memberikan pengalaman yang baik bagi pengguna. Pengalaman yang baik berarti visual di-refresh dalam lima detik atau kurang. Untuk saran performa selengkapnya, lihat DirectQuery di Power BI.

Menggunakan model komposit menambahkan pertimbangan performa lainnya. Satu visual dapat mengakibatkan pengiriman kueri ke beberapa sumber, yang sering meneruskan hasil dari satu kueri ke sumber kedua. Situasi ini dapat mengakibatkan bentuk eksekusi berikut:

  • Kueri sumber yang menyertakan sejumlah besar nilai harfiah: Misalnya, visual yang meminta total Jumlah Penjualan untuk sekumpulan Manajer Produk yang dipilih terlebih dahulu perlu menemukan Produk mana yang dikelola oleh manajer produk tersebut. Urutan ini harus terjadi sebelum visual mengirim kueri SQL yang menyertakan semua ID produk dalam klausa WHERE.

  • Kueri sumber yang mengkueri pada tingkat granularitas yang lebih rendah, dengan data kemudian dikumpulkan secara lokal: Karena jumlah Produk yang memenuhi kriteria filter pada Manajer Produk tumbuh besar, itu bisa menjadi tidak efisien atau tidak layak untuk menyertakan semua produk dalam klausul WHERE . Sebagai gantinya, Anda dapat mengkueri sumber relasional pada tingkat Produk yang lebih rendah. lalu mengumpulkan hasilnya secara lokal. Jika kardinalitas Produk melebihi batas 1 juta, kueri gagal.

  • Beberapa kueri sumber, satu per grup menurut nilai: Saat agregasi menggunakan DistinctCount dan dikelompokkan menurut kolom dari sumber lain, dan jika sumber eksternal tidak mendukung pengeluaran yang efisien dari banyak nilai harfiah yang menentukan pengelompokan, perlu untuk mengirim satu kueri SQL per grup menurut nilai.

    Visual yang meminta jumlah CustomerAccountNumber yang berbeda dari tabel SQL Server oleh Manajer Produk yang diimpor dari spreadsheet perlu meneruskan detail dari tabel Manajer Produk dalam kueri yang dikirim ke SQL Server. Di atas sumber lain, Redshift, misalnya, tindakan ini tidak memungkinkan. Sebaliknya, akan ada satu kueri SQL yang dikirim per Manajer Penjualan, hingga beberapa batas praktis, di mana kueri akan gagal.

Masing-masing kasus ini memiliki implikasinya sendiri pada performa, dan detail tepatnya bervariasi untuk setiap sumber data. Meskipun kardinalitas kolom yang digunakan dalam hubungan yang menggabungkan kedua sumber tetap rendah, beberapa ribu, performa tidak boleh terpengaruh. Seiring pertumbuhan kardinalitas ini, Anda harus lebih memperhatikan dampak pada performa yang dihasilkan.

Selain itu, penggunaan hubungan banyak ke banyak berarti bahwa kueri terpisah harus dikirim ke sumber dasar untuk setiap tingkat total atau subtotal, daripada menggabungkan nilai terperinci secara lokal. Visual tabel sederhana dengan total akan mengirim dua kueri sumber, bukan satu.

Grup sumber

Grup sumber adalah kumpulan item, seperti tabel dan hubungan, dari sumber DirectQuery atau semua sumber impor yang terlibat dalam model data. Model komposit terbuat dari satu atau beberapa grup sumber. Perhatikan contoh berikut:

  • Model komposit yang tersambung ke model semantik Power BI yang disebut Penjualan dan memperkaya model semantik dengan menambahkan pengukuran Sales YTD , yang tidak tersedia dalam model semantik asli. Model ini terdiri dari satu grup sumber.
  • Model komposit yang menggabungkan data dengan mengimpor tabel dari lembar Excel yang disebut Target dan file CSV yang disebut Wilayah, dan membuat koneksi DirectQuery ke model semantik Power BI yang disebut Penjualan. Dalam hal ini, ada dua grup sumber seperti yang ditunjukkan pada gambar berikut:
    • Grup sumber pertama berisi tabel dari lembar Target Excel, dan file CSV Wilayah .
    • Grup sumber kedua berisi item dari model semantik Sales Power BI.

Diagram memperlihatkan grup sumber Impor dan Penjualan yang berisi tabel dari sumber masing-masing.

Jika Anda menambahkan koneksi DirectQuery lain ke sumber lain, seperti koneksi DirectQuery ke database SQL Server yang disebut Inventory, item dari sumber tersebut ditambahkan grup sumber lain:

Diagram memperlihatkan grup sumber Impor, Penjualan, dan Inventori yang berisi tabel dari sumber masing-masing.

Catatan

Mengimpor data dari sumber lain tidak akan menambahkan grup sumber lain, karena semua item dari semua sumber yang diimpor berada dalam satu grup sumber.

Grup sumber dan hubungan

Ada dua jenis hubungan dalam model komposit:

  • Hubungan grup sumber intra. Hubungan ini menghubungkan item dalam grup sumber bersama-sama. Hubungan ini selalu merupakan hubungan reguler kecuali mereka banyak ke banyak, dalam hal ini mereka terbatas.
  • Hubungan grup lintas sumber. Hubungan ini dimulai dalam satu grup sumber dan berakhir di grup sumber yang berbeda. Hubungan ini selalu merupakan hubungan yang terbatas.

Baca selengkapnya tentang perbedaan antara hubungan reguler dan terbatas dan dampaknya.

Misalnya, dalam gambar berikut kami menambahkan tiga hubungan grup sumber silang, yang berkaitan dengan tabel di berbagai grup sumber bersama-sama:

Diagram memperlihatkan grup sumber Impor, Penjualan, dan Inventori yang berisi tabel dari masing-masing sumber dan hubungan antara grup sumber seperti yang dijelaskan sebelumnya.

Lokal dan jarak jauh

Item apa pun yang berada dalam grup sumber yang merupakan grup sumber DirectQuery dianggap jarak jauh, kecuali item didefinisikan secara lokal sebagai bagian dari ekstensi atau pengayaan ke sumber DirectQuery dan bukan bagian dari sumber jarak jauh, seperti ukuran atau tabel terhitung. Tabel terhitung berdasarkan tabel dari grup sumber DirectQuery milik grup sumber "Impor" dan dianggap lokal. Item apa pun yang berada dalam grup sumber "Impor" dianggap lokal. Misalnya, jika Anda menentukan ukuran berikut dalam model komposit yang menggunakan koneksi DirectQuery ke sumber Inventori, ukuran dianggap lokal:

[Average Inventory Count] = Average(Inventory[Inventory Count])

Grup penghitungan, kueri, dan evaluasi pengukuran

Grup penghitungan menyediakan cara untuk mengurangi jumlah pengukuran redundan dan mengelompokkan ekspresi pengukuran umum bersama-sama. Kasus penggunaan umum adalah perhitungan inteligensi waktu di mana Anda ingin dapat beralih dari perhitungan aktual ke bulan ke tanggal, kuartal ke tanggal, atau tahun ke tanggal. Saat bekerja dengan model komposit, penting untuk mengetahui interaksi antara grup perhitungan dan apakah ukuran hanya mengacu pada item dari satu grup sumber jarak jauh. Jika ukuran hanya mengacu pada item dari satu grup sumber jarak jauh dan model jarak jauh menentukan grup perhitungan yang memengaruhi ukuran, grup penghitungan tersebut diterapkan, bahkan jika ukuran ditentukan dalam model jarak jauh atau dalam model lokal. Namun, jika ukuran tidak merujuk ke item dari satu grup sumber jarak jauh secara eksklusif tetapi mengacu pada item dari grup sumber jarak jauh tempat grup penghitungan jarak jauh diterapkan, hasil pengukuran mungkin masih terpengaruh oleh grup penghitungan jarak jauh. Pertimbangkan contoh berikut:

  • Penjualan Penjual adalah ukuran yang ditentukan dalam model jarak jauh.
  • Model jarak jauh berisi grup perhitungan yang mengubah hasil Penjualan Penjual
  • Internet Sales adalah ukuran yang ditentukan dalam model lokal.
  • Total Penjualan adalah ukuran yang ditentukan dalam model lokal, dan memiliki definisi berikut:
[Total Sales] = [Internet Sales] + [Reseller Sales]

Dalam skenario ini, ukuran Penjualan Internet tidak terpengaruh oleh grup perhitungan yang ditentukan dalam model jarak jauh karena mereka bukan bagian dari model yang sama. Namun, grup perhitungan dapat mengubah hasil pengukuran Penjualan Penjual, karena berada dalam model yang sama. Fakta ini berarti bahwa hasil yang dikembalikan oleh ukuran Total Penjualan harus dievaluasi dengan hati-hati. Bayangkan kita menggunakan grup perhitungan dalam model jarak jauh untuk mengembalikan hasil tahun ke tanggal. Hasil yang dikembalikan oleh Penjualan Penjual sekarang menjadi nilai tahunan hingga saat ini, sementara hasil yang dikembalikan oleh Internet Sales masih aktual. Hasil dari Total Penjualan sekarang kemungkinan tidak terduga, karena menambahkan aktual ke hasil tahun ke tanggal.

Model komposit pada model semantik Power BI dan Analysis Services

Menggunakan model komposit dengan model semantik Power BI dan Analysis Services, Anda dapat membuat model komposit menggunakan koneksi DirectQuery untuk menyambungkan ke model semantik Power BI, Azure Analysis Services (AAS), dan SQL Server 2022 Analysis Services. Dengan menggunakan model komposit, Anda dapat menggabungkan data di sumber ini dengan DirectQuery lain dan data yang diimpor. Penulis laporan yang ingin menggabungkan data dari model semantik perusahaan mereka dengan data lain yang mereka miliki, seperti lembar bentang Excel, atau ingin mempersonalisasi atau memperkaya metadata dari model semantik perusahaan mereka, akan menemukan fungsionalitas ini sangat berguna.

Mengelola model komposit pada model semantik Power BI

Untuk mengaktifkan pembuatan dan konsumsi model komposit pada model semantik Power BI, penyewa Anda harus mengaktifkan sakelar berikut:

Selain itu, untuk kapasitas Premium dan Premium Per Pengguna pengaturan "titik akhir XMLA" harus diaktifkan dan diatur ke "Baca Saja" atau "Baca/Tulis".

Administrator penyewa dapat mengaktifkan atau menonaktifkan koneksi DirectQuery ke model semantik Power BI di portal admin. Meskipun diaktifkan secara default, menonaktifkannya akan menghentikan pengguna menerbitkan model komposit baru pada model semantik Power BI ke layanan.

Pengaturan admin untuk mengaktifkan atau menonaktifkan koneksi DirectQuery ke model semantik Power BI.

Laporan yang sudah ada yang menggunakan model komposit pada model semantik Power BI terus berfungsi dan pengguna masih dapat membuat model komposit dalam menggunakan Desktop tetapi tidak dapat menerbitkan ke layanan. Sebagai gantinya, saat Anda membuat koneksi DirectQuery ke model semantik Power BI dengan memilih Buat perubahan pada model ini, Anda akan melihat pesan peringatan berikut:

Cuplikan layar memperlihatkan pesan Peringatan yang memberi tahu pengguna bahwa publikasi model komposit yang menggunakan model semantik Power BI tidak diizinkan, karena koneksi DirectQuery tidak diizinkan oleh admin. Pengguna masih dapat membuat model menggunakan Desktop.

Dengan cara ini Anda masih dapat menjelajahi model semantik di lingkungan Power BI Desktop lokal Anda dan membuat model komposit. Namun, Anda tidak dapat menerbitkan laporan ke Layanan. Saat menerbitkan laporan dan model, Anda akan melihat pesan kesalahan dan publikasi berikut diblokir:

Cuplikan layar memperlihatkan pesan Kesalahan yang memblokir publikasi model komposit yang menggunakan model semantik Power BI karena koneksi DirectQuery tidak diizinkan oleh admin.

Koneksi langsung ke model semantik Power BI tidak dipengaruhi oleh sakelar, atau koneksi langsung atau DirectQuery ke Analysis Services. Ini terus berfungsi terlepas dari apakah sakelar telah dimatikan. Selain itu, setiap laporan yang diterbitkan yang menggunakan model komposit pada model semantik Power BI akan terus berfungsi meskipun sakelar telah dinonaktifkan setelah diterbitkan.

Membangun model komposit pada model atau model semantik

Membangun model komposit pada model semantik Power BI atau model Analysis Services mengharuskan laporan Anda memiliki model lokal. Anda dapat memulai dari koneksi langsung dan menambahkan atau meningkatkan ke model lokal, atau memulai dengan koneksi DirectQuery atau data yang diimpor, yang otomatis membuat model lokal dalam laporan.

Untuk melihat koneksi mana yang digunakan dalam model Anda, periksa bilah status di pojok kanan bawah Power BI Desktop. Jika hanya tersambung ke sumber Azure Analysis Services, Anda akan melihat pesan seperti gambar berikut:

Cuplikan layar memperlihatkan koneksi hanya Analysis Services.

Jika Anda tersambung ke model semantik Power BI, Anda akan melihat pesan yang memberi tahu Anda model semantik Power BI mana yang tersambung dengan Anda:

Cuplikan layar memperlihatkan koneksi model semantik Power BI.

Jika Anda ingin menyesuaikan metadata bidang dalam model semantik terhubung langsung Anda, pilih Buat perubahan pada model ini di bilah status. Atau, Anda dapat memilih tombol Buat perubahan pada model ini di pita, seperti yang ditunjukkan dalam gambar berikut. Di Tampilan Laporan, tombol Buat perubahan pada model ini berada di tab Pemodelan. Di Tampilan Model, tombol tersebut berada di tab Beranda.

Cuplikan layar memperlihatkan tombol Buat perubahan pada model ini.

Memilih tombol menampilkan dialog yang mengonfirmasi penambahan model lokal. Pilih Tambahkan model lokal untuk mengaktifkan pembuatan kolom baru atau memodifikasi metadata, untuk bidang dari model semantik Power BI atau Analysis Services. Gambar berikut menunjukkan dialog yang diperlihatkan.

Cuplikan layar memperlihatkan dialog Buat model lokal.

Saat Anda tersambung langsung ke sumber Analysis Services, tidak ada model lokal. Untuk menggunakan DirectQuery untuk sumber tersambung langsung, seperti model semantik Power BI dan Analysis Services, Anda harus menambahkan model lokal ke laporan Anda. Saat Anda menerbitkan laporan dengan model lokal ke layanan Power BI, model semantik untuk model lokal tersebut diterbitkan dengan baik.

Penautan

Model semantik dan model semantik di mana model tersebut didasarkan pada bentuk rantai. Proses ini, yang disebut penautan, memungkinkan Anda menerbitkan laporan dan model semantik berdasarkan model semantik Power BI lainnya, fitur yang sebelumnya tidak dimungkinkan.

Misalnya, bayangkan kolega Anda menerbitkan model semantik Power BI yang disebut Penjualan dan Anggaran berdasarkan model Analysis Services yang disebut Penjualan, dan menggabungkannya dengan lembar Excel yang disebut Anggaran.

Saat Anda menerbitkan laporan baru (dan model semantik) yang disebut Penjualan dan Anggaran Eropa berdasarkan model semantik Power BI Penjualan dan Anggaran yang diterbitkan oleh kolega Anda, membuat beberapa modifikasi atau ekstensi lebih lanjut saat Anda melakukannya, Anda secara efektif menambahkan laporan dan model semantik ke rantai panjang tiga, yang dimulai dengan model Sales Analysis Services, dan diakhir dengan model semantik Power BI Penjualan dan Anggaran Eropa Anda. Gambar berikut menggambarkan proses penautan ini.

Cuplikan layar memperlihatkan Proses penautan model semantik.

Rantai dalam gambar sebelumnya memiliki panjang tiga, yang merupakan panjang maksimum. Memperluas melebihi panjang rantai tiga tidak didukung dan menyebabkan kesalahan.

Izin dan lisensi

Pengguna yang mengakses laporan menggunakan model komposit harus memiliki izin yang tepat untuk semua model dan model semantik dalam rantai.

Pemilik model komposit memerlukan izin Build pada model semantik yang digunakan sebagai sumber sehingga pengguna lain dapat mengakses model tersebut atas nama pemilik. Akibatnya, membuat koneksi model komposit di Power BI Desktop atau menulis laporan di Power BI memerlukan izin Build pada model semantik yang digunakan sebagai sumber.

Pengguna yang melihat laporan menggunakan model komposit umumnya akan memerlukan izin Baca pada model komposit itu sendiri dan model semantik yang digunakan sebagai sumber. Izin build mungkin diperlukan jika laporan berada di ruang kerja Pro. Sakelar penyewa ini harus diaktifkan untuk pengguna.

Izin yang diperlukan dapat diilustrasikan dengan contoh berikut:

  • Model Komposit A (dimiliki oleh Pemilik A)

    • Sumber data A1: Model Semantik B.
      Pemilik A harus memiliki izin Build pada Semantic Model B agar pengguna dapat melihat laporan menggunakan Model Komposit A.

  • Model Komposit C (dimiliki oleh Pemilik C)

    • Sumber data C1: Model Semantik D
      Pemilik C harus memiliki izin Build pada Semantic Model D agar pengguna dapat melihat laporan menggunakan Model Komposit C.
    • Sumber data C2: Model Komposit A
      Pemilik C harus memiliki izin Build pada Izin Model Komposit A dan Baca pada Model Semantik B.

Pengguna yang melihat laporan menggunakan Model Komposit A harus memiliki izin Baca untuk Model Komposit A dan Model Semantik B, sementara pengguna yang melihat laporan menggunakan Model Komposit C harus memiliki izin Baca pada Model Komposit C, Model Semantik D, Model Komposit A , dan Model Semantik B.

Catatan

Lihat blogpost ini untuk informasi penting tentang izin yang diperlukan untuk model komposit pada model semantik Power BI dan model Analysis Services.

Jika ada himpunan data dalam rantai berada di ruang kerja Premium Per Pengguna, pengguna yang mengaksesnya memerlukan lisensi Premium Per Pengguna. Jika ada himpunan data dalam rantai yang berada di ruang kerja Pro, pengguna yang mengaksesnya memerlukan lisensi Pro. Jika semua himpunan data dalam rantai berada pada kapasitas Premium atau Fabric F64 atau kapasitas yang lebih besar, pengguna dapat mengaksesnya menggunakan lisensi Gratis.

Peringatan keamanan

Menggunakan model Komposit pada model semantik Power BI dan fitur model Analysis Services memberi Anda dialog peringatan keamanan, yang diperlihatkan dalam gambar berikut.

Cuplikan layar memperlihatkan peringatan Keamanan.

Data dapat didorong dari satu sumber data ke sumber data lainnya, yang merupakan peringatan keamanan yang sama untuk menggabungkan DirectQuery dan mengimpor sumber dalam model data. Untuk mempelajari selengkapnya tentang perilaku ini, lihat menggunakan model komposit di Power BI Desktop.

Skenario yang didukung

Anda dapat membuat model komposit menggunakan data dari model semantik Power BI atau model Analysis Services untuk melayani skenario berikut:

  • Menyambungkan ke data dari berbagai sumber: Impor (seperti file), model semantik Power BI, model Analysis Services
  • Membuat hubungan antara sumber data yang berbeda
  • Menulis pengukuran yang menggunakan bidang dari sumber data yang berbeda
  • Membuat kolom baru untuk tabel dari model semantik Power BI atau model Analysis Services
  • Membuat visual yang menggunakan kolom dari sumber data yang berbeda
  • Anda dapat menghapus tabel dari model Anda menggunakan daftar bidang, untuk menjaga model tetap ringkas, dan condong sesingkat mungkin (jika Anda tersambung ke perspektif, Anda tidak dapat menghapus tabel dari model)
  • Anda dapat menentukan tabel mana yang akan dimuat, daripada harus memuat semua tabel saat Anda hanya menginginkan subset tabel tertentu. Lihat Memuat subset tabel nanti dalam dokumen ini.
  • Anda dapat menentukan apakah akan menambahkan tabel apa pun yang nantinya ditambahkan ke model semantik setelah Anda membuat koneksi dalam model Anda.

Bekerja dengan model komposit berdasarkan model semantik

Saat bekerja dengan DirectQuery untuk model semantik Power BI dan Analysis Services, pertimbangkan informasi berikut:

  • Jika Anda me-refresh sumber data, dan ada kesalahan dengan nama bidang atau tabel yang berkonflik, Power BI menyelesaikan kesalahan untuk Anda.

  • Anda tidak dapat mengedit, menghapus, atau membuat hubungan baru di model semantik Power BI yang sama atau sumber Analysis Services. Jika Anda memiliki akses edit ke sumber ini, Anda dapat membuat perubahan langsung di sumber data sebagai gantinya.

  • Anda tidak dapat mengubah tipe data kolom yang dimuat dari model semantik Power BI atau sumber Analysis Services. Jika Anda perlu mengubah jenis data, ubah di sumber atau gunakan kolom terhitung.

  • Untuk membuat laporan di layanan Power BI pada model komposit berdasarkan model semantik lain, semua kredensial harus diatur.

  • Koneksi ke SQL Server 2022 dan yang lebih baru server Azure Analysis Services lokal atau IAAS memerlukan gateway data lokal (mode Standar).

  • Semua koneksi ke model semantik Power BI jarak jauh dibuat menggunakan akses menyeluruh. Mengautentikasi dengan perwakilan layanan saat ini tidak didukung.

  • Aturan RLS diterapkan pada sumber yang didefinisikan, tetapi tidak diterapkan ke model semantik lain dalam model. RLS yang ditentukan dalam laporan tidak diterapkan ke sumber jarak jauh, dan RLS yang diatur pada sumber jarak jauh tidak diterapkan ke sumber data lain. Selain itu, Anda tidak dapat menentukan RLS pada tabel yang dimuat dari sumber jarak jauh, dan RLS yang ditentukan pada tabel lokal tidak memfilter tabel apa pun yang dimuat dari sumber jarak jauh.

  • KPI, keamanan tingkat baris, dan terjemahan tidak diimpor dari sumbernya.

  • Anda mungkin melihat beberapa perilaku tak terduga saat menggunakan hierarki tanggal. Untuk mengatasi masalah ini, gunakan kolom tanggal sebagai gantinya. Setelah menambahkan hierarki tanggal ke visual, Anda dapat beralih ke kolom tanggal dengan mengeklik panah bawah dalam nama bidang, lalu mengeklik nama bidang tersebut alih-alih menggunakan Hierarki Tanggal:

    Cuplikan layar pengaturan hierarki tanggal.

    Untuk informasi selengkapnya tentang menggunakan kolom tanggal versus hierarki tanggal, lihat menerapkan tanggal atau waktu otomatis di Power BI Desktop.

  • Panjang maksimum rantai model adalah tiga. Memperluas melebihi panjang rantai tiga tidak didukung dan menyebabkan kesalahan.

  • Bendera penautan yang tidak disarankan dapat diatur pada model untuk mencegah rantai dibuat atau diperluas. Untuk informasi selengkapnya, lihat Mengelola koneksi DirectQuery ke model semantik yang diterbitkan.

  • Koneksi ke model semantik Power BI atau model Analysis Services tidak diperlihatkan di Power Query.

Batasan berikut berlaku saat bekerja dengan DirectQuery untuk model semantik Power BI dan Analysis Services:

  • Parameter untuk database dan nama server saat ini dinonaktifkan.
  • Menentukan RLS pada tabel dari sumber jarak jauh tidak didukung.
  • Menggunakan salah satu sumber berikut sebagai sumber DirectQuery tidak didukung:
    • Model Tabular SQL Server Analysis Services (SSAS) sebelum versi 2022
    • Model multidireksional SSAS
    • SAP HANA
    • SAP Business Warehouse
    • Model semantik real time
    • Contoh model semantik
    • Refresh Excel Online
    • Data yang diimpor dari file Excel atau CSV pada Layanan
    • Metrik penggunaan
    • Model semantik disimpan di "Ruang kerja saya"
  • Menggunakan Power BI Embedded dengan model semantik yang menyertakan koneksi DirectQuery ke model Analysis Services saat ini tidak didukung.
  • Menerbitkan laporan ke web menggunakan fitur terbitkan ke web tidak didukung.
  • Grup penghitungan pada sumber jarak jauh tidak didukung, dengan hasil kueri yang tidak ditentukan.
  • Tabel terhitung dan kolom terhitung yang mereferensikan tabel DirectQuery dari sumber data dengan autentikasi akses menyeluruh (SSO) didukung di layanan Power BI dengan koneksi cloud yang dapat dibagikan dan/atau kontrol akses terperinci yang ditetapkan.
  • Jika Anda mengganti nama ruang kerja setelah koneksi DirectQuery disiapkan, Anda perlu memperbarui sumber data di Power BI Desktop agar laporan terus berfungsi.
  • Refresh halaman otomatis (APR) hanya didukung untuk beberapa skenario, tergantung pada jenis sumber data. Untuk informasi selengkapnya, lihat Refresh halaman otomatis di Power BI.
  • Mengambil alih model semantik yang menggunakan DirectQuery ke fitur model semantik lainnya saat ini tidak didukung.
  • Seperti halnya sumber data DirectQuery apa pun, hierarki yang ditentukan dalam model Analysis Services atau model semantik Power BI tidak ditampilkan saat menyambungkan ke model atau model semantik dalam mode DirectQuery menggunakan Excel.

Ada beberapa hal lain yang perlu dipertimbangkan saat bekerja dengan DirectQuery untuk model semantik Power BI dan Analysis Services:

  • Gunakan kolom kardinalitas rendah dalam hubungan grup lintas sumber: Saat Anda membuat hubungan di dua grup sumber yang berbeda, kolom yang berpartisipasi dalam hubungan (juga disebut kolom gabungan) harus memiliki kardinalitas rendah, idealnya 50.000 atau kurang. Pertimbangan ini berlaku untuk kolom kunci nonstring; untuk kolom kunci string, lihat pertimbangan berikut.
  • Hindari menggunakan kolom kunci string besar dalam hubungan grup lintas sumber: Saat membuat hubungan grup lintas sumber, hindari menggunakan kolom string besar sebagai kolom hubungan, terutama untuk kolom yang memiliki kardinalitas yang lebih besar. Saat Anda harus menggunakan kolom string sebagai kolom hubungan, hitung panjang string yang diharapkan untuk filter dengan mengalikan kardinalitas (C) dengan panjang rata-rata kolom string (A). Pastikan panjang string yang diharapkan di bawah 250.000, sehingga A ∗ C < 250.000.

Untuk pertimbangan dan panduan selengkapnya, lihat panduan model komposit.

Pertimbangan penyewa

Model apa pun dengan koneksi DirectQuery ke model semantik Power BI atau ke Analysis Services harus diterbitkan di penyewa yang sama, yang sangat penting saat mengakses model semantik Power BI atau model Analysis Services menggunakan identitas tamu B2B, seperti yang digambarkan dalam diagram berikut. Lihat Pengguna tamu yang dapat mengedit dan mengelola konten untuk menemukan URL penyewa untuk penerbitan.

Pertimbangkan diagram berikut. Langkah-langkah bernomor dalam diagram dijelaskan dalam paragraf berikut.

Diagram langkah bernomor untuk pertimbangan penyewa.

Dalam diagram, Ash bekerja dengan Contoso dan mengakses data yang disediakan oleh Fabrikam. Dengan Power BI Desktop, Ash membuat koneksi DirectQuery ke model Analysis Services yang dihosting di penyewa Fabrikam.

Untuk mengautentikasi, Ash menggunakan identitas pengguna Tamu B2B (langkah 1 dalam diagram).

Jika laporan diterbitkan ke layanan Power BI Contoso (langkah 2), model semantik yang diterbitkan di penyewa Contoso tidak dapat berhasil mengautentikasi terhadap model Analysis Services Fabrikam (langkah 3). Akibatnya, laporan tidak berfungsi.

Dalam skenario ini, karena model Azure Analysis Services yang digunakan dihosting di penyewa Fabrikam, laporan juga harus diterbitkan di penyewa Fabrikam. Setelah publikasi berhasil di penyewa Fabrikam (langkah 4), model semantik dapat berhasil mengakses model Analysis Services (langkah 5) dan laporan berfungsi dengan baik.

Bekerja dengan keamanan tingkat objek

Saat model komposit mendapatkan data dari model semantik Power BI atau Analysis Services melalui DirectQuery, dan model sumber tersebut diamankan oleh keamanan tingkat objek, konsumen model komposit mungkin melihat hasil yang tidak terduga. Bagian berikut menjelaskan cara hasil ini mungkin muncul.

Keamanan tingkat objek (OLS) memungkinkan penulis model menyembunyikan objek yang membentuk skema model (yaitu, tabel, kolom, metadata, dll.) dari konsumen model (misalnya, pembuat laporan atau penulis model komposit). Dalam mengonfigurasi OLS untuk objek, pembuat model membuat peran, lalu menghapus akses ke objek untuk pengguna yang ditetapkan ke peran tersebut. Dari sudut depan pengguna tersebut, objek tersembunyi tidak ada.

OLS didefinisikan untuk dan diterapkan di model sumber. Ini tidak dapat didefinisikan untuk model komposit yang dibangun pada model sumber.

Saat model komposit dibangun di atas model semantik Power BI yang dilindungi OLS atau model Analysis Services melalui koneksi DirectQuery, skema model dari model sumber disalin ke dalam model komposit. Apa yang akan disalin tergantung pada apa yang diizinkan untuk dilihat oleh penulis model komposit dalam model sumber sesuai dengan aturan OLS yang berlaku di sana. Data tidak disalin ke model komposit - melainkan, data selalu diambil melalui DirectQuery dari model sumber saat diperlukan. Dengan kata lain, pengambilan data selalu kembali ke model sumber, saat aturan OLS berlaku.

Karena model komposit tidak diamankan oleh aturan OLS, objek yang dilihat oleh konsumen model komposit adalah yang dapat dilihat oleh penulis model komposit dalam model sumber daripada apa yang mungkin dapat mereka akses. Ini dapat mengakibatkan situasi berikut:

  • Seseorang yang melihat model komposit mungkin melihat objek yang disembunyikan darinya di model sumber oleh OLS.
  • Sebaliknya, mereka mungkin TIDAK melihat objek dalam model komposit yang DAPAT mereka lihat di model sumber, karena objek itu disembunyikan dari penulis model komposit oleh aturan OLS yang mengontrol akses ke model sumber.

Poin penting adalah bahwa terlepas dari kasus yang dijelaskan dalam poin pertama, konsumen model komposit tidak pernah melihat data aktual yang tidak seharusnya mereka lihat, karena data tidak terletak dalam model komposit. Sebaliknya, karena DirectQuery, itu diambil sesuai kebutuhan dari model semantik sumber, di mana OLS memblokir akses yang tidak sah.

Dengan mengingat latar belakang ini, pertimbangkan skenario berikut:

Diagram memperlihatkan apa yang terjadi ketika model komposit tersambung ke model sumber yang dilindungi oleh keamanan tingkat objek.

  1. Admin_user menerbitkan model semantik perusahaan menggunakan model semantik Power BI atau model Analysis Services yang memiliki tabel Pelanggan dan tabel Wilayah. Admin_user menerbitkan model semantik ke layanan Power BI dan menetapkan aturan OLS yang memiliki efek berikut:

    • Pengguna Keuangan tidak dapat melihat tabel Pelanggan
    • Pengguna Pemasaran tidak dapat melihat tabel Wilayah

  2. Finance_user menerbitkan model semantik yang disebut "Model semantik keuangan" dan laporan yang disebut "Laporan keuangan" yang terhubung melalui DirectQuery ke model semantik perusahaan yang diterbitkan pada langkah 1. Laporan Keuangan menyertakan visual yang menggunakan kolom dari tabel Wilayah.

  3. Marketing_user membuka laporan Keuangan. Visual yang menggunakan tabel Wilayah ditampilkan, tetapi menampilkan kesalahan, karena saat laporan dibuka, DirectQuery mencoba mengambil data dari model sumber menggunakan info masuk Marketing_user, yang diblokir agar tidak melihat tabel Wilayah sesuai aturan OLS yang ditetapkan pada model semantik perusahaan.

  4. Marketing_user membuat laporan baru yang disebut "Laporan Pemasaran" yang menggunakan model semantik Keuangan sebagai sumbernya. Daftar bidang menampilkan tabel dan kolom yang dapat diakses oleh Finance_user. Oleh karena itu, tabel Wilayah diperlihatkan dalam daftar bidang, tetapi tabel Pelanggan tidak. Namun, ketika Marketing_user mencoba membuat visual yang menggunakan kolom dari tabel Wilayah, kesalahan dikembalikan, karena pada saat itu DirectQuery mencoba mengambil data dari model sumber menggunakan kredensial Marketing_user, dan aturan OLS sekali lagi menendang dan memblokir akses. Hal yang sama terjadi ketika Marketing_user membuat model semantik baru dan melaporkan yang terhubung ke model semantik Keuangan dengan koneksi DirectQuery - mereka melihat tabel Wilayah dalam daftar bidang, karena itulah yang dapat dilihat Finance_user, tetapi ketika mereka mencoba membuat visual yang menggunakan tabel itu, mereka diblokir oleh aturan OLS pada model semantik perusahaan.

  5. Sekarang, katakanlah Admin_user memperbarui aturan OLS pada model semantik perusahaan untuk menghentikan Keuangan agar tidak melihat tabel Wilayah.

  6. Aturan OLS yang diperbarui hanya tercermin dalam model semantik Keuangan saat di-refresh. Dengan demikian, ketika Finance_user me-refresh model semantik Keuangan, tabel Wilayah tidak lagi ditampilkan dalam daftar bidang, dan visual dalam laporan Keuangan yang menggunakan kolom dari tabel Wilayah mengembalikan kesalahan untuk Finance_user, karena sekarang tidak diizinkan untuk mengakses tabel Wilayah.

Untuk meringkas:

  • Konsumen model komposit melihat hasil aturan OLS yang berlaku untuk penulis model komposit saat mereka membuat model. Dengan demikian, ketika laporan baru dibuat berdasarkan model komposit, daftar bidang menunjukkan tabel yang dapat diakses penulis model komposit saat membuat model, terlepas dari apa yang dapat diakses pengguna saat ini dalam model sumber.
  • Aturan OLS tidak dapat ditentukan di model komposit itu sendiri.
  • Konsumen model komposit tidak akan pernah melihat data aktual yang seharusnya tidak mereka lihat, karena aturan OLS yang relevan pada model sumber memblokirnya saat DirectQuery mencoba mengambil data menggunakan kredensial mereka.
  • Jika model sumber memperbarui aturan OLS-nya, perubahan tersebut hanya memengaruhi model komposit saat di-refresh.

Memuat subset tabel dari model semantik Power BI atau model Analysis Services

Saat menyambungkan ke model semantik Power BI atau model Analysis Services menggunakan koneksi DirectQuery, Anda bisa memutuskan tabel mana yang akan disambungkan. Anda juga dapat memilih untuk secara otomatis menambahkan tabel apa pun yang mungkin ditambahkan ke model atau model semantik setelah Anda membuat koneksi ke model Anda. Saat Anda tersambung ke perspektif, model Anda berisi semua tabel dalam model semantik dan tabel apa pun yang tidak disertakan dalam perspektif disembunyikan. Selain itu, tabel apa pun yang mungkin ditambahkan ke perspektif ditambahkan secara otomatis. Di menu Pengaturan, Anda dapat memutuskan untuk secara otomatis tersambung ke tabel yang ditambahkan ke model semantik setelah Anda pertama kali menyiapkan koneksi.

Dialog ini tidak ditampilkan untuk koneksi langsung.

Catatan

Dialog ini hanya akan ditampilkan jika Anda menambahkan koneksi DirectQuery ke model semantik Power BI atau model Analysis Services ke model yang sudah ada. Anda juga dapat membuka dialog ini dengan mengubah koneksi DirectQuery ke model semantik Power BI atau model Analysis Services di pengaturan Sumber data setelah Anda membuatnya.

Dialog yang memungkinkan menentukan tabel apa yang akan dimuat dari model semantik Power BI atau model Analysis Services.

Menyiapkan aturan deduplikasi

Anda dapat menentukan aturan deduplikasi untuk menjaga ukuran dan nama tabel tetap unik dalam model komposit dengan menggunakan opsi Pengaturan dalam dialog yang diperlihatkan sebelumnya:

Dialog yang memungkinkan menentukan aturan deduplikasi diterapkan saat memuat dari model semantik.

Dalam contoh sebelumnya, kami menambahkan ' (pemasaran)' sebagai akhiran ke tabel apa pun atau mengukur nama yang bertentangan dengan sumber lain dalam model komposit. Anda dapat:

  • masukkan teks yang akan ditambahkan ke nama tabel atau pengukuran yang bertentangan
  • tentukan apakah Anda ingin teks ditambahkan ke tabel atau mengukur nama sebagai awalan atau akhiran
  • menerapkan aturan deduplikasi ke tabel, pengukuran, atau keduanya
  • Pilih untuk menerapkan aturan deduplikasi hanya ketika konflik nama terjadi atau menerapkannya sepanjang waktu. Defaultnya adalah menerapkan aturan hanya ketika duplikasi terjadi. Dalam contoh kami, tabel atau ukuran apa pun dari sumber pemasaran yang tidak memiliki duplikat di sumber penjualan tidak akan mendapatkan perubahan nama.

Setelah Anda membuat koneksi dan menyiapkan aturan deduplikasi, daftar bidang Anda akan menampilkan 'Pelanggan' dan 'Pelanggan (pemasaran)' sesuai dengan aturan deduplikasi yang disiapkan dalam contoh kami:

Dialog yang memungkinkan penentuan aturan deduplikasi diterapkan saat memuat dari model semantik Power BI atau model Analysis Services.

Jika Anda tidak menentukan aturan deduplikasi, atau aturan deduplikasi yang Anda tentukan tidak mengatasi konflik nama, aturan deduplikasi standar masih diterapkan. Aturan deduplikasi standar menambahkan angka ke nama item yang bertentangan. Jika ada konflik nama pada tabel 'Pelanggan' salah satu tabel 'Pelanggan' diganti namanya menjadi 'Pelanggan 2'.

Modifikasi XMLA dan model komposit

Saat mengubah model semantik menggunakan XMLA, Anda harus memperbarui koleksi ChangedProperties dan PBI_RemovedChildren untuk objek yang diubah untuk menyertakan properti yang dimodifikasi atau dihapus. Jika Anda tidak melakukan pembaruan tersebut, alat pemodelan Power BI mungkin menimpa perubahan apa pun saat berikutnya skema disinkronkan dengan Lakehouse terkait.

Model yang didukung untuk mengubah model semantik menggunakan XMLA adalah sebagai berikut:

  • Ganti nama Tabel/Kolom (ChangeProperty = name)
  • Hapus tabel (tambahkan tabel ke anotasi PBI_RemovedChildren dalam ekspresi kueri)

Pertimbangan dan batasan

Model komposit menyajikan beberapa pertimbangan dan batasan:

Koneksi mode campuran - Saat menggunakan koneksi mode campuran yang berisi data online (seperti model semantik Power BI) dan model semantik lokal (seperti buku kerja Excel), Anda harus memiliki pemetaan gateway yang dibuat agar visual muncul dengan benar.

Saat ini, refresh bertahap didukung untuk model komposit yang terhubung ke sumber data SQL, Oracle, dan Teradata saja.

Sumber tabular Live Connect berikut tidak dapat digunakan dengan model komposit:

Menggunakan model semantik streaming dalam model komposit tidak didukung.

Batasan penggunaan DirectQuery yang ada masih berlaku saat Anda menggunakan model komposit. Banyak dari batasan tersebut sekarang menjadi per tabel, tergantung pada mode penyimpanan tabel. Misalnya, kolom terhitung pada tabel impor dapat merujuk ke tabel lain yang tidak ada di DirectQuery, tetapi kolom terhitung pada tabel DirectQuery masih dapat merujuk hanya ke kolom pada tabel yang sama. Batasan lain berlaku untuk model secara keseluruhan, jika salah satu tabel dalam model adalah DirectQuery. Misalnya, fitur QuickInsights tidak tersedia dalam model jika salah satu tabel di dalamnya memiliki mode penyimpanan DirectQuery.

Jika Anda menggunakan keamanan tingkat baris dalam model komposit dengan beberapa tabel dalam mode DirectQuery, Anda harus menyegarkan model untuk menerapkan pembaruan baru dari tabel DirectQuery. Misalnya, jika tabel Pengguna dalam mode DirectQuery memiliki rekaman pengguna baru di sumbernya, rekaman baru hanya akan disertakan setelah refresh model berikutnya. Layanan Power BI menyimpan kueri Pengguna untuk meningkatkan performa dan tidak memuat ulang data dari sumber hingga refresh manual atau terjadwal berikutnya.

Konten terkait

Untuk informasi selengkapnya tentang model komposit dan DirectQuery, lihat artikel berikut ini: