Panduan model DirectQuery di Power BI Desktop

  • Artikel

Artikel ini menargetkan pemodel data yang mengembangkan model Power BI DirectQuery, yang dikembangkan dengan menggunakan Power BI Desktop atau layanan Power BI. Ini menjelaskan kasus penggunaan, batasan, dan panduan DirectQuery. Secara khusus, panduan ini dirancang untuk membantu Anda menentukan apakah DirectQuery adalah mode yang sesuai untuk model Anda, dan untuk meningkatkan performa laporan Anda berdasarkan model DirectQuery. Artikel ini berlaku untuk model DirectQuery yang di-hosting di layanan Power BI atau Power BI Report Server.

Artikel ini tidak dimaksudkan untuk memberikan diskusi lengkap tentang desain model DirectQuery. Untuk pengenalan, lihat artikel model DirectQuery di Power BI Desktop. Untuk diskusi yang lebih mendalam, lihat langsung DirectQuery di dokumen Analysis Services SQL Server 2016. Perlu diingat bahwa laporan resmi menggambarkan penggunaan DirectQuery di SQL Server Analysis Services. Namun, sebagian besar konten masih berlaku untuk Power BI model DirectQuery.

Catatan

Untuk pertimbangan saat menggunakan mode penyimpanan DirectQuery untuk Dataverse, lihat Panduan pemodelan Power BI untuk Power Platform.

Artikel ini tidak secara langsung membahas model komposit. Model Komposit terdiri dari setidaknya satu sumber DirectQuery, dan mungkin lebih. Panduan yang dijelaskan dalam artikel ini masih relevan—setidaknya sebagian—untuk Desain model gabungan. Namun, implikasi menggabungkan tabel Impor dengan tabel DirectQuery tidak berada dalam cakupan untuk artikel ini. Untuk informasi selengkapnya, lihat Menggunakan model komposit di Power BI Desktop.

Penting untuk dipahami bahwa model DirectQuery memberlakukan beban kerja yang berbeda pada lingkungan Power BI (layanan Power BI atau Server Laporan Power BI) dan juga pada sumber data yang mendasar. Jika Anda menentukan bahwa DirectQuery adalah pendekatan desain yang sesuai, kami sarankan Anda melibatkan orang yang tepat dalam proyek. Kita sering melihat bahwa penyebaran model DirectQuery yang sukses adalah hasil dari tim profesional IT yang bekerja sama secara erat. Tim biasanya terdiri dari pengembang model dan administrator database sumber. Ini juga dapat melibatkan arsitek data, dan gudang data dan pengembang ETL. Seringkali, pengoptimalan perlu diterapkan langsung ke sumber data untuk mencapai hasil performa yang baik.

Mengoptimalkan performa sumber data

Sumber database relasional dapat dioptimalkan dalam beberapa cara, seperti yang dijelaskan dalam daftar berpoin berikut ini.

Catatan

Kami memahami bahwa tidak semua pemodel memiliki izin atau keterampilan untuk mengoptimalkan database relasional. Meskipun ini adalah lapisan yang disukai untuk menyiapkan data untuk model DirectQuery, beberapa pengoptimalan juga dapat dicapai dalam desain model, tanpa memodifikasi database sumber. Namun, hasil pengoptimalan terbaik sering dicapai dengan menerapkan pengoptimalan ke database sumber.

  • Pastikan integritas data selesai: Sangat penting bahwa tabel jenis dimensi berisi kolom nilai unik (kunci dimensi) yang memetakan ke tabel jenis fakta. Penting juga bahwa kolom dimensi jenis fakta berisi nilai kunci dimensi yang valid. Mereka akan memungkinkan konfigurasi hubungan model yang lebih efisien yang mengharapkan nilai yang cocok di kedua sisi hubungan. Ketika data sumber tidak memiliki integritas, disarankan agar rekaman dimensi "tidak diketahui" ditambahkan untuk memperbaiki data secara efektif. Misalnya, Anda dapat menambahkan baris ke tabel Produk untuk mewakili produk yang tidak diketahui, lalu menetapkannya kunci di luar rentang, seperti -1. Jika baris dalam tabel Penjualan berisi nilai kunci produk yang hilang, ganti dengan -1. Ini memastikan setiap nilai kunci produk Penjualan memiliki baris yang sesuai dalam tabel Produk .

  • Tambahkan indeks: Tentukan indeks yang sesuai—pada tabel atau tampilan—untuk mendukung pengambilan data yang efisien untuk pemfilteran dan pengelompokan visual laporan yang diharapkan. Untuk sumber SQL Server, Azure SQL Database, atau Azure Synapse Analytics (sebelumnya SQL Gudang Data), lihat Panduan Arsitektur dan Desain Indeks SQL Server untuk informasi bermanfaat tentang panduan desain indeks. Untuk sumber SQL Server atau Azure SQL Database volatil, lihat Mulai menggunakan Columnstore untuk analitik operasional real time.

  • Mendesain tabel terdistribusi: Untuk sumber Azure Synapse Analytics (sebelumnya Gudang Data SQL), yang menggunakan arsitektur Pemrosesan Paralel Masif (MPP), pertimbangkan untuk mengonfigurasi tabel jenis fakta besar sebagai tabel hash terdistribusi, dan jenis dimensi untuk mereplikasi di semua simpul komputasi. Untuk informasi selengkapnya, lihat Panduan untuk mendesain tabel terdistribusi di Azure Synapse Analytics (sebelumnya SQL Gudang Data).

  • Pastikan transformasi data yang diperlukan terwujud: Untuk SQL Server sumber database relasional (dan sumber database hubungan lainnya), kolom komputasi dapat ditambahkan ke tabel. Kolom ini didasarkan pada ekspresi, seperti Kuantitas dikalikan dengan UnitPrice. Kolom komputasi dapat dipertahankan (terwujud) dan, seperti kolom biasa, terkadang kolom tersebut dapat diindeks. Untuk informasi selengkapnya, lihat Indeks pada Kolom Komputasi.

    Pertimbangkan juga tampilan terindeks yang dapat melakukan pra-agregat data tabel fakta pada butir yang lebih tinggi. Misalnya, jika tabel Penjualan menyimpan data pada tingkat baris pesanan, Anda dapat membuat tampilan untuk meringkas data ini. Tampilan dapat didasarkan pada pernyataan SELECT yang mengelompokkan data tabel Penjualan berdasarkan tanggal (pada tingkat bulan), pelanggan, produk, dan meringkas nilai pengukuran seperti penjualan, kuantitas, dll. Tampilan kemudian dapat diindeks. Untuk sumber SQL Server atau Azure SQL Database, lihat Membuat Tampilan Terindeks.

  • Mewujudkan tabel tanggal: Persyaratan pemodelan umum melibatkan penambahan tabel tanggal untuk mendukung pemfilteran berbasis waktu. Untuk mendukung filter berbasis waktu yang diketahui di organisasi Anda, buat tabel di database sumber, dan pastikan filter tersebut dimuat dengan rentang tanggal yang mencakup tanggal tabel fakta. Pastikan juga bahwa itu termasuk kolom untuk periode waktu yang berguna, seperti tahun, triwulan, bulan, minggu, dll.

Mengoptimalkan desain model

Model DirectQuery dapat dioptimalkan dalam banyak cara, seperti yang dijelaskan dalam daftar berpoin berikut.

  • Hindari kueri Power Query kompleks: Desain model yang efisien dapat dicapai dengan menghapus kebutuhan kueri Power Query untuk menerapkan transformasi apa pun. Ini berarti bahwa setiap kueri memetakan ke tabel atau tampilan sumber database relasional tunggal. Anda bisa mempratinjau representasi pernyataan kueri SQL aktual untuk langkah Power Query diterapkan, dengan memilih opsi Tampilkan Kueri Asli.

    Cuplikan layar Power BI Desktop memperlihatkan opsi

    Cuplikan layar Power BI Desktop memperlihatkan jendela Kueri Asli. Pernyataan kueri menggabungkan dua tabel sumber.

  • Periksa penggunaan kolom terhitung dan perubahan tipe data: Model DirectQuery mendukung penambahan perhitungan dan langkah-langkah Power Query untuk mengonversi jenis data. Namun, performa yang lebih baik sering dicapai dengan mewujudkan transformasi menghasilkan sumber database relasional, jika memungkinkan.

  • Jangan gunakan pemfilteran tanggal relatif Power Query: Anda dapat menentukan pemfilteran tanggal relatif dalam kueri Power Query. Misalnya, untuk mengambil pesanan penjualan yang dibuat pada tahun lalu (relatif terhadap tanggal hari ini). Jenis filter ini diterjemahkan ke kueri asli yang tidak efisien, sebagai berikut:

    …
from [dbo].[Sales] as [_]
where [_].[OrderDate] >= convert(datetime2, '2018-01-01 00:00:00') and [_].[OrderDate] < convert(datetime2, '2019-01-01 00:00:00'))

    Pendekatan desain yang lebih baik adalah menyertakan kolom waktu relatif dalam tabel tanggal. Kolom ini menyimpan nilai offset relatif terhadap tanggal saat ini. Misalnya, dalam kolom RelativeYear, nilai nol mewakili tahun ini, -1 mewakili tahun sebelumnya, dll. Sebaiknya, kolom RelativeYear terwujud dalam tabel tanggal. Meskipun kurang efisien, ini juga dapat ditambahkan sebagai kolom terhitung model, berdasarkan ekspresi menggunakan fungsi TODAY dan DATE DAX.

  • Jaga agar langkah-langkah tetap sederhana: Setidaknya awalnya, disarankan untuk membatasi langkah-langkah untuk agregat sederhana. Fungsi agregat termasuk SUM, COUNT, MIN, MAX, dan AVERAGE. Kemudian, jika langkah-langkahnya cukup responsif, Anda dapat bereksperimen dengan langkah-langkah yang lebih kompleks, tetapi memperhatikan performa untuk masing-masing. Meskipun fungsi CALCULATE DAX dapat digunakan untuk menghasilkan ekspresi pengukuran canggih yang memanipulasi konteks filter, mereka dapat menghasilkan kueri asli mahal yang tidak berkinerja baik.

  • Hindari hubungan pada kolom terhitung: Hubungan model hanya dapat menghubungkan satu kolom dalam satu tabel ke satu kolom dalam tabel yang berbeda. Namun, terkadang, perlu untuk menghubungkan tabel dengan menggunakan beberapa kolom. Misalnya, tabel Penjualan dan Geografi terkait dengan dua kolom: CountryRegion dan City. Untuk membuat hubungan antara tabel, kolom tunggal diperlukan, dan dalam tabel Geografi, kolom harus berisi nilai unik. Menggabungkan negara/wilayah dan kota dengan pemisah tanda hubung dapat mencapai hasil ini.

    Kolom gabungan dapat dibuat dengan kolom khusus Power Query, atau dalam model sebagai kolom terhitung. Namun, itu harus dihindari karena ekspresi perhitungan akan disematkan ke dalam kueri sumber. Tidak hanya tidak efisien, biasanya mencegah penggunaan indeks. Sebagai gantinya, tambahkan kolom yang diwujudkan di sumber database relasional, dan pertimbangkan untuk mengindeksnya. Anda juga dapat mempertimbangkan untuk menambahkan kolom kunci pengganti ke tabel jenis dimensi, yang merupakan praktik umum dalam desain gudang data relasional.

    Ada satu pengecualian untuk panduan ini, dan ini menyangkut penggunaan fungsi COMBINEVALUES DAX. Tujuan dari fungsi ini adalah untuk mendukung hubungan model multikolom. Daripada menghasilkan ekspresi yang digunakan hubungan, itu menghasilkan predikat gabungan SQL multikolom.

  • Hindari hubungan pada kolom "Pengidentifikasi Unik": Power BI tidak secara asli mendukung tipe data pengidentifikasi unik (GUID). Saat menentukan hubungan antara kolom jenis ini, Power BI menghasilkan kueri sumber dengan gabungan yang melibatkan pemeran. Konversi data waktu kueri ini biasanya menghasilkan performa yang buruk. Sampai kasus ini dioptimalkan, satu-satunya solusinya adalah mewujudkan kolom dari jenis data alternatif dalam database yang mendasar.

  • Sembunyikan kolom hubungan satu sisi: Kolom satu sisi hubungan harus disembunyikan. (Biasanya kolom kunci utama dari tabel jenis dimensi.) Saat disembunyikan, tidak tersedia di panel Bidang sehingga tidak dapat digunakan untuk mengonfigurasi visual. Kolom banyak sisi dapat tetap terlihat jika berguna untuk mengelompokkan atau memfilter laporan menurut nilai kolom. Misalnya, pertimbangkan model di mana hubungan ada antara tabel Penjualan dan Produk. Kolom hubungan berisi nilai SKU produk (Stock-Keeping Unit). Jika SKU produk harus ditambahkan ke visual, SKU produk harus terlihat hanya dalam tabel Penjualan. Saat kolom ini digunakan untuk memfilter atau mengelompokkan dalam visual, Power BI menghasilkan kueri yang tidak perlu bergabung dengan tabel Penjualan dan Produk .

  • Mengatur hubungan untuk menerapkan integritas:Properti Asumsikan Integritas Referensial dari hubungan DirectQuery menentukan apakah Power BI menghasilkan kueri sumber menggunakan gabungan dalam daripada gabungan luar. Ini umumnya meningkatkan performa kueri, meskipun bergantung pada spesifikasi sumber database relasional. Untuk informasi selengkapnya, lihat Pengaturan Asumsikan integritas referensial di Power BI Desktop.

  • Hindari penggunaan pemfilteran hubungan dua arah: Penggunaan pemfilteran hubungan dua arah dapat menyebabkan pernyataan kueri yang tidak berkinerja baik. Hanya gunakan fitur hubungan ini jika perlu, dan biasanya terjadi saat menerapkan hubungan banyak ke banyak di seluruh tabel bridging. Untuk informasi selengkapnya, lihat Hubungan dengan banyak kardinalitas dalam Power BI Desktop.

  • Batasi kueri paralel: Anda dapat mengatur jumlah maksimum koneksi yang dibuka DirectQuery untuk setiap sumber data yang mendasar. Ini mengontrol jumlah kueri yang dikirim secara bersamaan ke sumber data.

    • Pengaturan hanya diaktifkan ketika setidaknya ada satu sumber DirectQuery dalam model. Nilai berlaku untuk semua sumber DirectQuery, dan untuk sumber DirectQuery baru yang ditambahkan ke model.
    • Meningkatkan nilai Koneksi Maksimum per Sumber Data memastikan lebih banyak kueri (hingga jumlah maksimum yang ditentukan) dapat dikirim ke sumber data dasar, yang berguna ketika banyak visual berada di satu halaman, atau banyak pengguna mengakses laporan secara bersamaan. Setelah jumlah maksimum koneksi tercapai, kueri lebih lanjut diantrekan hingga koneksi tersedia. Meningkatkan batas ini memang menghasilkan lebih banyak beban pada sumber data yang mendasar, sehingga pengaturan tidak dijamin untuk meningkatkan performa keseluruhan.
    • Ketika model diterbitkan ke Power BI, jumlah maksimum kueri bersamaan yang dikirim ke sumber data dasar juga bergantung pada lingkungan. Lingkungan yang berbeda (seperti Power BI, Power BI Premium, atau Power BI Report Server) masing-masing dapat memberlakukan batasan throughput yang berbeda. Untuk informasi selengkapnya tentang batasan sumber daya kapasitas, lihat Lisensi kapasitas Microsoft Fabric dan Mengonfigurasi dan mengelola kapasitas di Power BI Premium.

Penting

Terkadang artikel ini mengacu pada Power BI Premium atau langganan kapasitasnya (SKU P). Ketahuilah bahwa Microsoft saat ini mengonsolidasikan opsi pembelian dan menghentikan SKU Power BI Premium per kapasitas. Pelanggan baru dan yang sudah ada harus mempertimbangkan untuk membeli langganan kapasitas Fabric (F SKU) sebagai gantinya.

Untuk informasi selengkapnya, lihat Pembaruan penting yang masuk ke lisensi Power BI Premium dan Tanya Jawab Umum Power BI Premium.

Mengoptimalkan desain laporan

Laporan berdasarkan model semantik DirectQuery (sebelumnya dikenal sebagai himpunan data) dapat dioptimalkan dalam banyak cara, seperti yang dijelaskan dalam daftar berpoin berikut.

  • Aktifkan teknik pengurangan kueri:Opsi Power BI Desktop dan Pengaturan menyertakan halaman Pengurangan Kueri. Halaman ini memiliki tiga opsi bermanfaat. Dimungkinkan untuk menonaktifkan penyorotan silang dan pemfilteran silang secara default, meskipun dapat ditimpa dengan mengedit interaksi. Dimungkinkan juga untuk menampilkan tombol Terapkan pada pemotong dan filter. Opsi pemotong atau filter tidak akan diterapkan hingga pengguna laporan mengklik tombol . Jika Anda mengaktifkan opsi ini, kami sarankan Anda melakukannya saat pertama kali membuat laporan.
  • Terapkan filter terlebih dahulu: Saat pertama kali mendesain laporan, sebaiknya terapkan filter yang berlaku—di tingkat laporan, halaman, atau visual—sebelum memetakan bidang ke bidang visual. Misalnya, daripada menyeret di pengukuran CountryRegion dan Sales , lalu memfilter menurut tahun tertentu, terapkan filter pada bidang Tahun terlebih dahulu. Ini karena setiap langkah membangun visual akan mengirim kueri, dan meskipun dimungkinkan untuk kemudian membuat perubahan lain sebelum kueri pertama selesai, itu masih menempatkan beban yang tidak perlu pada sumber data yang mendasarinya. Dengan menerapkan filter lebih awal, umumnya membuat kueri perantara tersebut lebih murah dan lebih cepat. Selain itu, gagal menerapkan filter lebih awal dapat mengakibatkan melebihi batas 1 juta baris, seperti yang dijelaskan dalam tentang DirectQuery.
  • Batasi jumlah visual pada halaman: Saat halaman laporan dibuka (dan kapan filter halaman diterapkan) semua visual pada halaman disegarkan. Namun, ada batasan jumlah kueri yang dapat dikirim secara paralel, diberlakukan oleh lingkungan Power BI dan pengaturan Maksimum Koneksi per model Sumber Data, seperti yang dijelaskan di atas. Jadi, ketika jumlah visual halaman meningkat, ada kemungkinan lebih tinggi bahwa mereka akan di-refresh secara serial. Ini meningkatkan waktu yang diperlukan untuk menyegarkan seluruh halaman, dan juga meningkatkan kemungkinan visual dapat menampilkan hasil yang tidak konsisten (untuk sumber data yang volatil). Untuk alasan ini, disarankan untuk membatasi jumlah visual di halaman mana pun, dan sebaliknya memiliki halaman yang lebih sederhana. Mengganti beberapa visual kartu dengan visual kartu multibaris tunggal dapat mencapai tata letak halaman yang sama.
  • Matikan interaksi antar visual: Interaksi penyorotan silang dan pemfilteran silang mengharuskan kueri dikirimkan ke sumber yang mendasarinya. Kecuali interaksi ini diperlukan, disarankan agar mereka dinonaktifkan jika waktu yang diperlukan untuk merespons pilihan pengguna tidak akan lama. Interaksi ini dapat dinonaktifkan, baik untuk seluruh laporan (seperti yang dijelaskan di atas untuk opsi Pengurangan Kueri), atau berdasarkan kasus per kasus. Untuk informasi selengkapnya, lihat Bagaimana visual saling memfilter silang dalam laporan Power BI.

Selain daftar teknik pengoptimalan di atas, masing-masing kemampuan pelaporan berikut dapat berkontribusi pada masalah performa:

  • Mengukur filter: Visual yang berisi pengukuran (atau agregat kolom) dapat memiliki filter yang diterapkan pada langkah-langkah tersebut. Misalnya, visual di bawah ini menunjukkan Penjualan menurut Kategori, tetapi hanya untuk kategori dengan lebih dari $15 juta penjualan.

    Cuplikan layar Power BI Desktop memperlihatkan data tabular dengan filter yang diterapkan.

    Ini dapat mengakibatkan dua kueri dikirim ke sumber yang mendasarinya:

    • Kueri pertama akan mengambil kategori yang memenuhi kondisi (Penjualan > $15 juta)
    • Kueri kedua kemudian akan mengambil data yang diperlukan untuk visual, menambahkan kategori yang memenuhi kondisi ke klausa WHERE

    Umumnya berkinerja baik jika ada ratusan atau ribuan kategori, seperti dalam contoh ini. Performa dapat menurun, namun, jika jumlah kategori jauh lebih besar (dan memang, kueri akan gagal jika ada lebih dari 1 juta kategori yang memenuhi kondisi, karena batas 1 juta baris yang dibahas di atas).

  • Filter TopN: Filter tingkat lanjut dapat ditentukan untuk memfilter hanya pada nilai N atas (atau bawah) yang diberi peringkat berdasarkan ukuran. Misalnya, untuk hanya menampilkan lima kategori teratas dalam visual di atas. Seperti filter pengukuran, itu juga akan mengakibatkan dua kueri dikirim ke sumber data dasar. Namun, kueri pertama akan mengembalikan semua kategori dari sumber yang mendasar, lalu N teratas ditentukan berdasarkan hasil yang dikembalikan. Tergantung pada kardinalitas kolom yang terlibat, itu dapat menyebabkan masalah performa (atau kegagalan kueri karena batas 1 juta baris).

  • Median: Umumnya, agregasi apa pun (Jumlah, Jumlah Berbeda, dll.) didorong ke sumber yang mendasar. Namun, itu tidak berlaku untuk Median, karena agregat ini tidak didukung oleh sumber yang mendasar. Dalam kasus seperti itu, data detail diambil dari sumber yang mendasar, dan Power BI mengevaluasi median dari hasil yang dikembalikan. Tidak masalah ketika median akan dihitung atas jumlah hasil yang relatif kecil, tetapi masalah performa (atau kegagalan kueri karena batas 1 juta baris) akan terjadi jika kardinalitas besar. Misalnya, populasi negara/wilayah median mungkin wajar, tetapi harga penjualan median mungkin tidak.

  • Pemotong multipilih: Mengizinkan multipilihan dalam pemotong dan filter dapat menyebabkan masalah performa. Ini karena karena pengguna memilih item pemotong tambahan (misalnya, membangun hingga 10 produk yang mereka minati), setiap pilihan baru menghasilkan kueri baru yang dikirim ke sumber yang mendasar. Meskipun pengguna dapat memilih item berikutnya sebelum kueri selesai, hal ini menghasilkan beban tambahan pada sumber yang mendasar. Situasi ini dapat dihindari dengan memperlihatkan tombol Terapkan, seperti yang dijelaskan di atas dalam teknik pengurangan kueri.

  • Total visual: Secara default, tabel dan matriks menampilkan total dan subtotal. Dalam banyak kasus, kueri tambahan harus dikirim ke sumber yang mendasarinya untuk mendapatkan nilai untuk total. Ini berlaku setiap kali menggunakan agregat Count Distinct atau Median, dan dalam semua kasus saat menggunakan DirectQuery melalui SAP Hana atau SAP Business Warehouse. Total tersebut harus dinonaktifkan (dengan menggunakan panel Format) jika tidak perlu.

Mengonversi ke Model Gabungan

Manfaat model Impor dan DirectQuery dapat digabungkan ke dalam satu model dengan mengonfigurasi mode penyimpanan tabel model. Mode penyimpanan tabel dapat berupa Impor atau DirectQuery, atau keduanya, yang dikenal sebagai Dual. Saat model berisi tabel dengan mode penyimpanan yang berbeda, model tersebut dikenal sebagai model Komposit. Untuk informasi selengkapnya, lihat Menggunakan model komposit di Power BI Desktop.

Ada banyak peningkatan fungsional dan performa yang dapat dicapai dengan mengonversi model DirectQuery menjadi model Gabungan. Model Gabungan dapat mengintegrasikan lebih dari satu sumber DirectQuery, dan juga dapat menyertakan agregasi. Tabel agregasi dapat ditambahkan ke tabel DirectQuery untuk mengimpor representasi tabel yang dirangkum. Mereka dapat mencapai peningkatan performa dramatis saat visual mengkueri agregat tingkat yang lebih tinggi. Untuk informasi selengkapnya, lihat Agregasi di Power BI Desktop.

Mendidik pengguna

Penting untuk mendidik pengguna Anda tentang cara bekerja dengan laporan secara efisien berdasarkan model semantik DirectQuery. Penulis laporan Anda harus dididik tentang konten yang dijelaskan di bagian Optimalkan desain laporan.

Sebaiknya Anda mendidik konsumen laporan tentang laporan Anda yang didasarkan pada model semantik DirectQuery. Sangat membantu bagi mereka untuk memahami arsitektur data umum, termasuk batasan yang relevan yang dijelaskan dalam artikel ini. Beri tahu mereka untuk mengharapkan bahwa respons refresh dan pemfilteran interaktif mungkin kadang-kadang lambat. Saat melaporkan pengguna memahami mengapa penurunan performa terjadi, mereka cenderung tidak kehilangan kepercayaan pada laporan dan data.

Saat mengirimkan laporan tentang sumber data yang volatil, pastikan untuk mendidik pengguna laporan tentang penggunaan tombol Refresh. Beri tahu mereka juga bahwa mungkin untuk melihat hasil yang tidak konsisten, dan bahwa refresh laporan dapat mengatasi inkonsistensi apa pun di halaman laporan.

Konten terkait

Untuk informasi selengkapnya tentang DirectQuery, lihat sumber daya berikut ini: