Power BI Desktop’ta DirectQuery modeli rehberi
Bu makale, Power BI Desktop veya Power BI hizmeti kullanılarak geliştirilen Power BI DirectQuery modelleri geliştiren veri modelleyicileri hedefler. DirectQuery kullanım örneklerini, sınırlamalarını ve yönergelerini açıklar. Bu kılavuz özellikle DirectQuery'nin modeliniz için uygun mod olup olmadığını belirlemenize ve DirectQuery modellerini temel alarak raporlarınızın performansını artırmanıza yardımcı olmak için tasarlanmıştır. Bu makale, Power BI hizmeti veya Power BI Rapor Sunucusu barındırılan DirectQuery modelleri için geçerlidir.
Bu makale DirectQuery model tasarımı hakkında eksiksiz bir tartışma sağlamak için tasarlanmamıştır. Giriş için Power BI Desktop'ta DirectQuery modelleri makalesine bakın. Daha ayrıntılı bir tartışma için doğrudan SQL Server 2016 Analysis Services'da DirectQuery teknik incelemesine bakın. Teknik incelemenin SQL Server Analysis Services'da DirectQuery'yi kullanmayı açıklandığını unutmayın. Ancak içeriğin büyük bir kısmı Power BI DirectQuery modelleri için hala geçerlidir.
Not
Dataverse için DirectQuery depolama modunu kullanırken dikkat edilmesi gerekenler için bkz . Power Platform için Power BI modelleme kılavuzu.
Bu makale bileşik modelleri doğrudan kapsamaz. Bileşik model en az bir DirectQuery kaynağından ve muhtemelen daha fazladan oluşur. Bu makalede açıklanan kılavuz, bileşik model tasarımıyla ilgili olmaya devam etmektedir.en azından kısmen. Ancak, İçeri Aktarma tablolarını DirectQuery tablolarıyla birleştirmenin etkileri bu makalenin kapsamında değildir. Daha fazla bilgi için bkz . Power BI Desktop'ta bileşik modelleri kullanma.
DirectQuery modellerinin Power BI ortamına (Power BI hizmeti veya Power BI Rapor Sunucusu) ve ayrıca temel alınan veri kaynaklarına farklı bir iş yükü uyguladığını anlamak önemlidir. DirectQuery'nin uygun tasarım yaklaşımı olduğunu belirlerseniz, projede doğru kişilerle etkileşim kurmanızı öneririz. Genellikle başarılı bir DirectQuery modeli dağıtımının, BT uzmanlarından oluşan bir ekibin birlikte çalışmasının sonucu olduğunu görürüz. Ekip genellikle model geliştiricilerinden ve kaynak veritabanı yöneticilerinden oluşur. Ayrıca veri mimarları, veri ambarı ve ETL geliştiricileri de içerebilir. İyi performans sonuçları elde etmek için genellikle iyileştirmelerin doğrudan veri kaynağına uygulanması gerekir.
Veri kaynağı performansını iyileştirme
İlişkisel veritabanı kaynağı, aşağıdaki madde işaretli listede açıklandığı gibi çeşitli yollarla iyileştirilebilir.
Not
Tüm modelleyicilerin ilişkisel veritabanını iyileştirme izinlerine veya becerilerine sahip olmadığını anlıyoruz. DirectQuery modeli için verileri hazırlamak tercih edilen katman olsa da, kaynak veritabanını değiştirmeden model tasarımında da bazı iyileştirmeler yapılabilir. Ancak, en iyi iyileştirme sonuçları genellikle kaynak veritabanına iyileştirmeler uygulanarak elde edilir.
Veri bütünlüğünün tamamlandığından emin olun: Boyut türündeki tabloların olgu türündeki tablolarla eşleyen benzersiz değerlerden oluşan bir sütun (boyut anahtarı) içermesi özellikle önemlidir. Olgu türündeki boyut sütunlarının geçerli boyut anahtarı değerleri içermesi de önemlidir. Bunlar, ilişkilerin her iki tarafında da eşleşen değerler bekleyen daha verimli model ilişkileri yapılandırmaya olanak sağlar. Kaynak verilerde bütünlük olmadığında, verileri etkili bir şekilde onarmak için "bilinmeyen" bir boyut kaydının eklenmesi önerilir. Örneğin, bilinmeyen bir ürünü temsil etmek için Product tablosuna bir satır ekleyebilir ve ardından -1 gibi aralık dışı bir anahtar atayabilirsiniz. Sales tablosundaki satırlarda eksik bir ürün anahtarı değeri varsa, bunları -1 ile değiştirin. Her Sales ürün anahtarı değerinin Product tablosunda karşılık gelen bir satırı olmasını sağlar.
Dizin ekleme: Beklenen rapor görseli filtreleme ve gruplandırma için verilerin verimli bir şekilde alınmasını desteklemek için tablolar veya görünümler üzerinde uygun dizinleri tanımlayın. SQL Server, Azure SQL Veritabanı veya Azure Synapse Analytics (eski adıyla SQL Veri Ambarı) kaynakları için dizin tasarımı kılavuzu hakkında yararlı bilgiler için bkz. SQL Server Dizin Mimarisi ve Tasarım Kılavuzu. SQL Server veya Azure SQL Veritabanı geçici kaynaklar için bkz. Gerçek zamanlı operasyonel analiz için Columnstore ile çalışmaya başlama.
Dağıtılmış tablolar tasarlama: Yüksek Düzeyde Paralel İşleme (MPP) mimarisi kullanan Azure Synapse Analytics (eski adıYLA SQL Veri Ambarı) kaynakları için, büyük olgu türündeki tabloları karma dağıtılmış olarak ve boyut türündeki tabloları tüm işlem düğümlerinde çoğaltacak şekilde yapılandırmayı göz önünde bulundurun. Daha fazla bilgi için bkz . Azure Synapse Analytics'te (eski adı SQL Veri Ambarı) dağıtılmış tablolar tasarlama kılavuzu.
Gerekli veri dönüştürmelerinin gerçekleştirildiğinden emin olun: SQL Server ilişkisel veritabanı kaynakları (ve diğer ilişkisel veritabanı kaynakları) için hesaplanan sütunlar tablolara eklenebilir. Bu sütunlar, Quantity değerinin UnitPrice ile çarpılması gibi bir ifadeyi temel alır. Hesaplanan sütunlar kalıcı hale getirilebilir (gerçekleştirilebilir) ve normal sütunlar gibi bazen dizine eklenebilirler. Daha fazla bilgi için bkz . Hesaplanan Sütunlardaki Dizinler.
Ayrıca olgu tablosu verilerini daha yüksek bir dilimde önceden toplayan dizinlenmiş görünümleri de göz önünde bulundurun. Örneğin, Sales tablosu verileri sipariş satırı düzeyinde depolarsa, bu verileri özetlemek için bir görünüm oluşturabilirsiniz. Görünüm, Sales tablosu verilerini tarihe (ay düzeyinde), müşteriye, ürüne göre gruplandıran ve satış, miktar gibi ölçü değerlerini özetleyen bir SELECT deyimine dayalı olabilir. Görünüm daha sonra dizine eklenebilir. SQL Server veya Azure SQL Veritabanı kaynakları için bkz. Dizinli Görünümler Oluşturma.
Tarih tablosunu gerçekleştirme: Genel bir modelleme gereksinimi, zamana dayalı filtrelemeyi desteklemek için tarih tablosu eklemeyi içerir. Kuruluşunuzda bilinen zamana dayalı filtreleri desteklemek için kaynak veritabanında bir tablo oluşturun ve olgu tablosu tarihlerini kapsayan bir dizi tarih yüklendiğinden emin olun. Ayrıca yıl, çeyrek, ay, hafta gibi yararlı zaman aralıkları için sütunlar içerdiğini de unutmayın.
Model tasarımını iyileştirme
DirectQuery modeli, aşağıdaki madde işaretli listede açıklandığı gibi birçok şekilde iyileştirilebilir.
Karmaşık Power Query sorgularından kaçının: Power Query sorgularının herhangi bir dönüştürmeyi uygulama gereksinimi ortadan kaldırılarak verimli bir model tasarımı elde edilebilir. Bu, her sorgu tek bir ilişkisel veritabanı kaynak tablosuna veya görünümüne eşlendiğini gösterir. Yerel Sorguyu Görüntüle seçeneğini belirleyerek power query uygulanmış bir adım için gerçek SQL sorgu deyiminin gösterimini önizleyebilirsiniz.
Hesaplanmış sütunların ve veri türü değişikliklerinin kullanımını inceleyin: DirectQuery modelleri, veri türlerini dönüştürmek için hesaplama eklemeyi ve Power Query adımlarını destekler. Ancak, mümkün olduğunda ilişkisel veritabanı kaynağında dönüştürme sonuçları gerçekleştirilmesiyle genellikle daha iyi performans elde edilir.
Power Query göreli tarih filtrelemesini kullanmayın: Power Query sorgusunda göreli tarih filtreleme tanımlamak mümkündür. Örneğin, geçen yıl oluşturulan satış siparişlerini almak için (bugünün tarihine göre). Bu filtre türü aşağıdaki gibi verimsiz bir yerel sorguya çevrilir:
… from [dbo].[Sales] as [_] where [_].[OrderDate] >= convert(datetime2, '2018-01-01 00:00:00') and [_].[OrderDate] < convert(datetime2, '2019-01-01 00:00:00'))Daha iyi bir tasarım yaklaşımı, tarih tablosuna göreli saat sütunları eklemektir. Bu sütunlar, geçerli tarihe göre uzaklık değerlerini depolar. Örneğin, RelativeYear sütununda sıfır değeri geçerli yılı, -1 önceki yılı vb. temsil eder. Tercihen, RelativeYear sütunu tarih tablosunda gerçekleştirilir. Daha az verimli olsa da, BUGÜN ve TARİh DAX işlevlerini kullanan ifadeye göre model hesaplanmış sütunu olarak da eklenebilir.
Ölçüleri basit tutun: En azından başlangıçta ölçüleri basit toplamalarla sınırlamak önerilir. Toplama işlevleri SUM, COUNT, MIN, MAX ve AVERAGE işlevlerini içerir. Ardından ölçüler yeterince hızlı yanıt veriyorsa, her birinin performansına dikkat ederek daha karmaşık ölçülerle denemeler yapabilirsiniz. CALCULATE DAX işlevi, filtre bağlamını işleyen gelişmiş ölçü ifadeleri üretmek için kullanılabilse de, iyi performans göstermeyen pahalı yerel sorgular oluşturabilir.
Hesaplanmış sütunlarda ilişkilerden kaçının: Model ilişkileri, tek bir tablodaki tek bir sütunu farklı bir tablodaki tek bir sütunla ilişkilendirebilir. Ancak bazen tabloları birden çok sütun kullanarak ilişkilendirmek gerekir. Örneğin, Satış ve Coğrafya tabloları iki sütunla ilişkilidir: CountryRegion ve City. Tablolar arasında ilişki oluşturmak için tek bir sütun gerekir ve Coğrafya tablosunda sütunun benzersiz değerler içermesi gerekir. Ülke/bölge ve şehri kısa çizgi ayırıcısıyla birleştirmek bu sonuca ulaşabilir.
Birleştirilmiş sütun, Power Query özel sütunuyla veya modelde hesaplanmış sütun olarak oluşturulabilir. Ancak, hesaplama ifadesi kaynak sorgulara eklendiği için bundan kaçınılmalıdır. Hem verimsiz hem de genellikle dizin kullanımını engeller. Bunun yerine, ilişkisel veritabanı kaynağına gerçekleştirilmiş sütunlar ekleyin ve bunları dizine eklemeyi göz önünde bulundurun. İlişkisel veri ambarı tasarımlarında yaygın bir uygulama olan boyut türündeki tablolara vekil anahtar sütunları eklemeyi de düşünebilirsiniz.
Bu kılavuzda bir özel durum vardır ve COMBINEVALUES DAX işlevinin kullanımıyla ilgilidir. Bu işlevin amacı çok sütunlu model ilişkilerini desteklemektir. İlişkinin kullandığı bir ifade oluşturmak yerine çok sütunlu bir SQL birleştirme koşulu oluşturur.
"Benzersiz Tanımlayıcı" sütunlarında ilişkilerden kaçının: Power BI, benzersiz tanımlayıcı (GUID) veri türünü yerel olarak desteklemez. Power BI, bu tür sütunlar arasında bir ilişki tanımlarken, atama içeren bir birleştirme ile bir kaynak sorgu oluşturur. Bu sorgu zamanı veri dönüştürmesi genellikle düşük performansa neden olur. Bu durum iyileştirilene kadar tek geçici çözüm, temel alınan veritabanında alternatif bir veri türündeki sütunların gerçekleştirilmesidir.
İlişkilerin tek taraflı sütununu gizleme: bir ilişkinin tek taraflı sütunu gizlenmelidir. (Genellikle boyut türündeki tabloların birincil anahtar sütunu olur.) Gizlendiğinde, Alanlar bölmesinde kullanılamaz ve bu nedenle görseli yapılandırmak için kullanılamaz. Raporları sütun değerlerine göre gruplandırmak veya filtrelemek yararlıysa, çok taraflı sütun görünür durumda kalabilir. Örneğin, Satış ve Ürün tabloları arasında bir ilişkinin bulunduğu bir model düşünün. İlişki sütunları ürün SKU'su (Stok Tutma Birimi) değerlerini içerir. Ürün SKU'sunun görsellere eklenmesi gerekiyorsa, yalnızca Sales tablosunda görünür olmalıdır. Bu sütun görselde filtrelemek veya gruplandırmak için kullanıldığında Power BI, Satış ve Ürün tablolarını birleştirmesi gerekmeyen bir sorgu oluşturur.
Bütünlüğü zorunlu kılmak için ilişkileri ayarlayın:DirectQuery ilişkilerinin Bilgi Tutarlılığını Varsay özelliği, Power BI'ın dış birleşim yerine iç birleşim kullanarak kaynak sorgular oluşturup oluşturmadığını belirler. Genellikle sorgu performansını geliştirir, ancak ilişkisel veritabanı kaynağının özelliklerine bağlıdır. Daha fazla bilgi için bkz . Power BI Desktop'ta bilgi tutarlılığı ayarlarını varsay.
çift yönlü ilişki filtrelemesi kullanmaktan kaçının: çift yönlü ilişki filtrelemenin kullanılması, iyi performans göstermeyen sorgu deyimlerine yol açabilir. Bu ilişki özelliğini yalnızca gerektiğinde kullanın ve genellikle köprü oluşturma tablosunda çoka çok ilişki uygularken bu durum geçerlidir. Daha fazla bilgi için bkz . Power BI Desktop'ta çoka çok kardinalitesi olan ilişkiler.
Paralel sorguları sınırla: DirectQuery'nin temel alınan her veri kaynağı için açtığı en fazla bağlantı sayısını ayarlayabilirsiniz. Veri kaynağına eşzamanlı olarak gönderilen sorguların sayısını denetler.
- Ayar yalnızca modelde en az bir DirectQuery kaynağı olduğunda etkinleştirilir. Bu değer tüm DirectQuery kaynaklarına ve modele eklenen tüm yeni DirectQuery kaynaklarına uygulanır.
- Veri Kaynağı Başına En Fazla Bağlan Sayısı değerinin artırılması, temel alınan veri kaynağına daha fazla sorgu (belirtilen en fazla sayıya kadar) gönderilmesini sağlar. Bu, tek bir sayfada çok sayıda görsel bulunduğunda veya birçok kullanıcı aynı anda bir rapora eriştiğinde yararlıdır. Bağlantı sayısı üst sınırına ulaşıldığında, bağlantı kullanılabilir duruma gelene kadar başka sorgular kuyruğa alınır. Bu sınırın artırılması temel alınan veri kaynağında daha fazla yüke neden olur, bu nedenle ayarın genel performansı iyileştirmesi garanti değildir.
- Model Power BI'da yayımlandığında, temel alınan veri kaynağına gönderilen en fazla eşzamanlı sorgu sayısı da ortama bağlıdır. Farklı ortamlar (Power BI, Power BI Premium veya Power BI Rapor Sunucusu gibi) farklı aktarım hızı kısıtlamaları uygulayabilir. Kapasite kaynağı sınırlamaları hakkında daha fazla bilgi için bkz . Microsoft Fabric kapasite lisansları ve Power BI Premium'da kapasiteleri yapılandırma ve yönetme.
Önemli
Bazen bu makale Power BI Premium'a veya kapasite aboneliklerine (P SKU'ları) başvurur. Microsoft'un şu anda satın alma seçeneklerini birleştirdiğini ve kapasite başına Power BI Premium SKU'larını kullanımdan kaldırdığını unutmayın. Yeni ve mevcut müşteriler bunun yerine Doku kapasitesi abonelikleri (F SKU'ları) satın almayı düşünmelidir.
Daha fazla bilgi için bkz . Power BI Premium lisansına gelen önemli güncelleştirmeler ve Power BI Premium hakkında SSS.
Rapor tasarımlarını iyileştirme
DirectQuery semantik modeline (daha önce veri kümesi olarak bilinirdi) dayalı raporlar, aşağıdaki madde işaretli listede açıklandığı gibi birçok şekilde iyileştirilebilir.
- Sorgu azaltma tekniklerini etkinleştirme: Power BI Desktop Seçenekleri ve Ayarlar bir Sorgu Azaltma sayfası içerir. Bu sayfada üç yararlı seçenek vardır. Çapraz vurgulama ve çapraz filtrelemeyi varsayılan olarak devre dışı bırakmak mümkündür, ancak etkileşimler düzenlenerek geçersiz kılınabilir. Dilimleyicilerde ve filtrelerde Uygula düğmesi de gösterebilirsiniz. Rapor kullanıcısı düğmeye tıklayana kadar dilimleyici veya filtre seçenekleri uygulanmaz. Bu seçenekleri etkinleştirirseniz, raporu ilk oluştururken bunu yapmanızı öneririz.
- Önce filtreleri uygulama: Raporları ilk tasarlarken, alanları görsel alanlarla eşlemeden önce rapor, sayfa veya görsel düzeyinde geçerli filtreleri uygulamanızı öneririz. Örneğin, CountryRegion ve Sales ölçülerini sürükleyip belirli bir yıla göre filtrelemek yerine, önce Yıl alanına filtreyi uygulayın. Bunun nedeni, görsel oluşturma işleminin her adımında bir sorgu gönderilmesi ve ilk sorgu tamamlanmadan önce başka bir değişiklik yapmak mümkün olsa da, temel alınan veri kaynağına yine de gereksiz yük yerleştirebilmesidir. Filtreleri erken uygulayarak genellikle bu ara sorguları daha az maliyetli ve daha hızlı hale getirir. Ayrıca, filtrelerin erken uygulanamaması, DirectQuery hakkında açıklandığı gibi 1 milyon satır sınırının aşılmasıyla sonuçlanabilir.
- Sayfadaki görsel sayısını sınırlayın: Rapor sayfası açıldığında (ve sayfa filtreleri uygulandığında) sayfadaki tüm görseller yenilenir. Ancak, yukarıda açıklandığı gibi, Power BI ortamı tarafından uygulanan paralel olarak gönderilebilen sorgu sayısı ve Veri Kaynağı başına en fazla Bağlan sayısı ayarında bir sınır vardır. Bu nedenle, sayfa görsellerinin sayısı arttıkça bunların seri bir şekilde yenilenme olasılığı daha yüksektir. Sayfanın tamamını yenilemek için geçen süreyi artırır ve görsellerin tutarsız sonuçlar görüntüleme olasılığını da artırır (geçici veri kaynakları için). Bu nedenlerden dolayı, herhangi bir sayfadaki görsellerin sayısını sınırlamanız ve bunun yerine daha basit sayfalara sahip olmanız önerilir. Birden çok kart görselini tek bir çok satırlı kart görseliyle değiştirmek benzer bir sayfa düzeni elde edebilir.
- Görseller arasındaki etkileşimi kapatma: Çapraz vurgulama ve çapraz filtreleme etkileşimleri, temel alınan kaynağa sorgu gönderilmesini gerektirir. Bu etkileşimler gerekli olmadığı sürece, kullanıcıların seçimlerine yanıt verme süresi makul olmayan bir şekilde uzun olacaksa bunların kapatılması önerilir. Bu etkileşimler, raporun tamamı için (yukarıda Sorgu Azaltma seçenekleri için açıklandığı gibi) veya büyük/küçük harf temelinde kapatılabilir. Daha fazla bilgi için bkz . Power BI raporunda görsellerin birbirine çapraz filtre uygulama şekli.
Yukarıdaki iyileştirme teknikleri listesine ek olarak, aşağıdaki raporlama özelliklerinin her biri performans sorunlarına katkıda bulunabilir:
Ölçü filtreleri: Ölçüler (veya sütun toplamları) içeren görsellerde bu ölçülere filtre uygulanabilir. Örneğin, aşağıdaki görselde Kategoriye Göre Satışlar gösterilir, ancak yalnızca 15 milyon ABD dolarından fazla satışa sahip kategoriler için gösterilir.
Temel alınan kaynağa iki sorgu gönderilmesine neden olabilir:
- İlk sorgu koşulu karşılayan kategorileri alır (Satış > 15 milyon ABD doları)
- İkinci sorgu daha sonra koşula uygun kategorileri WHERE yan tümcesine ekleyerek görsel için gerekli verileri alır
Bu örnekte olduğu gibi yüzlerce veya binlerce kategori varsa genellikle iyi performans gösterir. Ancak, kategori sayısı çok daha büyükse performans düşebilir (ve yukarıda açıklanan 1 milyon satır sınırı nedeniyle koşulu karşılayan 1 milyondan fazla kategori varsa sorgu başarısız olur).
TopN filtreleri: Gelişmiş filtreler, yalnızca bir ölçüye göre derecelenen üst (veya alt) N değerlerine filtre uygulamak için tanımlanabilir. Örneğin, yukarıdaki görselde yalnızca ilk beş kategoriyi görüntülemek için. Ölçü filtreleri gibi, temel alınan veri kaynağına iki sorgu gönderilmesine de neden olur. Ancak, ilk sorgu temel alınan kaynaktan tüm kategorileri döndürür ve sonra döndürülen sonuçlara göre ilk N belirlenir. İlgili sütunun kardinalitesine bağlı olarak performans sorunlarına (veya 1 milyon satır sınırından kaynaklanan sorgu hatalarına) yol açabilir.
Ortanca: Genel olarak, tüm toplamalar (Toplam, Ayrı Say vb.) temel alınan kaynağa gönderilir. Ancak, bu toplama temel alınan kaynak tarafından desteklenmediğinden Ortanca için bu doğru değildir. Böyle durumlarda, ayrıntı verileri temel alınan kaynaktan alınır ve Power BI döndürülen sonuçlardan ortanca değeri değerlendirir. Ortanca değerin görece az sayıda sonuç üzerinden hesaplanması normaldir, ancak kardinalite büyükse performans sorunları (veya 1 milyon satır sınırından kaynaklanan sorgu hataları) oluşur. Örneğin ortanca ülke/bölge nüfusu makul olabilir, ancak ortanca satış fiyatı makul olmayabilir.
Çoklu seçim dilimleyicileri: Dilimleyicilerde ve filtrelerde çoklu seçime izin vermek performans sorunlarına neden olabilir. Bunun nedeni, kullanıcı ek dilimleyici öğeleri seçtiğinde (örneğin, ilgilendiği 10 ürüne kadar derleme), her yeni seçimin temel alınan kaynağa yeni bir sorgu gönderilmesine neden olmasıdır. Kullanıcı sorgu tamamlanmadan önce bir sonraki öğeyi seçebilir ancak temel alınan kaynakta ek yüke neden olur. Bu durum, yukarıda sorgu azaltma tekniklerinde açıklandığı gibi Uygula düğmesi gösterilerek önlenebilir.
Görsel toplamlar: Tablolar ve matrisler varsayılan olarak toplamları ve alt toplamları görüntüler. Çoğu durumda, toplamların değerlerini almak için temel alınan kaynağa ek sorgular gönderilmelidir. Ayrı Say veya Ortanca toplamalar kullanıldığında ve SAP HANA veya SAP Business Warehouse üzerinden DirectQuery kullanıldığında her durumda geçerlidir. Gerekli değilse, bu tür toplamlar kapatılmalıdır (Biçim bölmesi kullanılarak).
Bileşik Modele Dönüştürme
İçeri Aktarma ve DirectQuery modellerinin avantajları, model tablolarının depolama modu yapılandırılarak tek bir modelde birleştirilebilir. Tablo depolama modu İçeri Aktarma veya DirectQuery ya da her ikisi de İkili olarak bilinir. Bir model farklı depolama modlarına sahip tablolar içerdiğinde Bileşik model olarak bilinir. Daha fazla bilgi için bkz . Power BI Desktop'ta bileşik modelleri kullanma.
DirectQuery modelini Bileşik modele dönüştürerek elde edilebilecek birçok işlev ve performans geliştirmesi vardır. Bileşik model birden fazla DirectQuery kaynağını tümleştirebilir ve toplamalar da içerebilir. Toplama tabloları, tablonun özetlenmiş bir gösterimini içeri aktarmak için DirectQuery tablolarına eklenebilir. Görseller daha üst düzey toplamaları sorguladığında önemli performans geliştirmeleri elde edebilir. Daha fazla bilgi için bkz . Power BI Desktop'ta toplamalar.
Kullanıcıları eğitme
Kullanıcılarınızı DirectQuery anlam modellerini temel alan raporlarla verimli bir şekilde çalışma konusunda eğitmeniz önemlidir. Rapor yazarlarınız, Rapor tasarımlarını iyileştirme bölümünde açıklanan içerik üzerinde eğitilmelidir.
Rapor tüketicilerinizi DirectQuery anlam modellerini temel alan raporlarınız hakkında eğitmeniz önerilir. Bu makalede açıklanan tüm ilgili sınırlamalar dahil olmak üzere genel veri mimarisini anlamaları yararlı olabilir. Yenileme yanıtlarının ve etkileşimli filtrelemenin bazen yavaş olabileceğini beklemelerini sağlayın. Rapor kullanıcıları performans düşüşü neden olduğunu anladığında raporlara ve verilere olan güvenlerini kaybetme olasılıkları daha düşüktür.
Geçici veri kaynaklarıyla ilgili raporlar teslim ederken, rapor kullanıcılarını Yenile düğmesinin kullanımı konusunda eğittiğinizden emin olun. Tutarsız sonuçları görmenin mümkün olabileceğini ve raporun yenilenmesinin rapor sayfasındaki tutarsızlıkları çözebileceğini de bildirin.
İlgili içerik
DirectQuery hakkında daha fazla bilgi için aşağıdaki kaynaklara göz atın:
Geri Bildirim
Çok yakında: 2024 boyunca, içerik için geri bildirim mekanizması olarak GitHub Sorunları’nı kullanımdan kaldıracak ve yeni bir geri bildirim sistemiyle değiştireceğiz. Daha fazla bilgi için bkz. https://aka.ms/ContentUserFeedback.
Gönderin ve geri bildirimi görüntüleyin