Sayfalandırılmış raporlar için veri alma kılavuzu

  • Makale

Bu makale, Power BI sayfalandırılmış raporları tasarlayan bir rapor yazarı olarak sizi hedefler. Etkili ve verimli veri alımı tasarlamanıza yardımcı olacak öneriler sağlar.

Veri kaynağı türleri

Sayfalandırılmış raporlar hem ilişkisel hem de analitik veri kaynaklarını yerel olarak destekler. Bu kaynaklar bulut tabanlı veya şirket içi olarak daha fazla kategorilere ayrılmıştır. Şirket içinde veya sanal makinede barındırılan şirket içi veri kaynakları, Power BI'ın bağlanabilmesi için bir veri ağ geçidi gerektirir. Bulut tabanlı, Power BI'ın İnternet bağlantısı kullanarak doğrudan bağlanabileceği anlamına gelir.

Veri kaynağı türünü (büyük olasılıkla yeni bir projede) seçebiliyorsanız bulut tabanlı veri kaynaklarını kullanmanızı öneririz. Sayfalandırılmış raporlar, özellikle veri kaynakları Power BI kiracınızla aynı bölgede bulunduğunda daha düşük ağ gecikme süresiyle bağlanabilir. Ayrıca, Çoklu Oturum Açma (SSO) kullanarak bu kaynaklara bağlanmak da mümkündür. Bu, rapor kullanıcısının kimliğinin veri kaynağına akabileceği ve kullanıcı başına satır düzeyi izinlerin uygulanmasına izin verebileceği anlamına gelir. Şu anda SSO yalnızca şirket içi veri kaynakları SQL Server ve Oracle için desteklenmektedir (bkz . Power BI sayfalandırılmış raporları için desteklenen veri kaynakları).

Not

Şu anda SSO kullanarak şirket içi veritabanlarına bağlanmak mümkün olmasa da, satır düzeyi izinleri zorunlu tutabilirsiniz. UserID yerleşik alanını bir veri kümesi sorgu parametresine geçirerek yapılır. Veri kaynağının Kullanıcı Asıl Adı (UPN) değerlerini sorgu sonuçlarını doğru filtreleyecek şekilde depolaması gerekir.

Örneğin, her satış temsilcisinin Salesperson a tablosunda satır olarak depolandığını düşünün. Tabloda UPN sütunları ve ayrıca satış temsilcisinin satış bölgesi bulunur. Sorgu zamanında tablo, rapor kullanıcısının UPN'sine göre filtrelenmiş ve iç birleşim kullanan satış olguları ile de ilişkilidir. Bu şekilde sorgu, satış olgu satırlarını rapor kullanıcısının satış bölgesine göre etkili bir şekilde filtreler.

İlişkisel veri kaynakları

Genel olarak ilişkisel veri kaynakları, satış faturaları gibi işlem stili raporlara çok uygundur. Ayrıca, çok büyük veri kümelerini (10.000 satırdan fazla) alması gereken raporlar için de uygundur. İlişkisel veri kaynakları, rapor veri kümeleri tarafından yürütülebilen saklı yordamları da tanımlayabilir. Saklı yordamlar çeşitli avantajlar sunar:

  • Parameterization
  • Programlama mantığının kapsüllenmesi, daha karmaşık veri hazırlamaya olanak tanır (örneğin, geçici tablolar, imleçler veya skaler kullanıcı tanımlı işlevler)
  • Saklı yordam mantığının kolayca güncelleştirilmesini sağlayan geliştirilmiş bakım. Bazı durumlarda, sayfalandırılmış raporları değiştirmek ve yeniden yayımlamak zorunda kalmadan yapılabilir (sütun adları ve veri türleri değişmeden kalır).
  • Yürütme planları yeniden kullanılmak üzere önbelleğe alındıkça daha iyi performans
  • Birden çok raporda saklı yordamların yeniden kullanılması

Power BI Rapor Oluşturucusu,ilişkisel sorgu tasarımcısını kullanarak yalnızca Microsoft veri kaynakları için bir sorgu deyimini grafik olarak oluşturabilirsiniz.

Analitik veri kaynakları

Veri modelleri veya yalnızca modeller olarak da bilinen analitik veri kaynakları hem operasyonel hem de analitik raporlar için uygundur ve çok büyük veri hacimlerinde bile hızlı özetlenmiş sorgu sonuçları sunabilir. Model ölçüleri ve KPI'ler, verilerin özetlenmesi için karmaşık iş kurallarını kapsülleyebilir. Ancak bu veri kaynakları, çok büyük hacimli verileri (10.000 satırdan fazla) alması gereken raporlar için uygun değildir.

Power BI Rapor Oluşturucusu iki sorgu tasarımcısına sahipsiniz: Analysis Services DAX sorgu tasarımcısı ve Analysis Services MDX sorgu tasarımcısı. Bu tasarımcılar, Power BI anlam modeli (daha önce veri kümesi olarak bilinirdi) veri kaynakları ya da tablosal veya çok boyutlu herhangi bir SQL Server Analysis Services veya Azure Analysis Services modeli için kullanılabilir.

DAX sorgu tasarımcısını kullanmanızı ve sorgu gereksinimlerinizi tamamen karşılamanızı öneririz. Model ihtiyacınız olan ölçüleri tanımlamıyorsa sorgu moduna geçmeniz gerekir. Bu modda, ifadeler ekleyerek sorgu deyimini özelleştirebilirsiniz (özetleme elde etmek için).

MDX sorgu tasarımcısı modelinizin ölçüler içermesini gerektirir. Tasarımcı, DAX sorgu tasarımcısı tarafından desteklenmeyen iki özelliğe sahiptir. Özellikle şunları yapmanızı sağlar:

  • Sorgu düzeyi hesaplanan üyeleri tanımlama (MDX'te).
  • Ayrıntılı olmayan gruplarda sunucu toplamları istemek için veri bölgelerini yapılandırın. Raporunuzun yarı veya eklemesiz ölçülerin özetlerini (akıllı zaman gösterimi hesaplamaları veya ayrı sayımlar gibi) sunması gerekiyorsa, sunucu toplamalarını kullanmak, düşük düzey ayrıntı satırları almak ve rapor işlem özetlerini almaktan daha verimli olacaktır.

Sorgu sonucu boyutu

Genel olarak, yalnızca raporunuzun gerektirdiği verileri almak en iyi yöntemdir. Bu nedenle, rapor için gerekli olmayan sütunları veya satırları almayın.

Satırları sınırlamak için her zaman en kısıtlayıcı filtreleri uygulamanız ve toplu sorgular tanımlamanız gerekir. Daha ayrıntılı sonuçlar almak için sorguları gruplandırma ve kaynak verileri özetleme. Örneğin, raporunuzun satış temsilcisi satışlarının özetini sunması gerektiğini düşünün. Tüm satış siparişi satırlarını almak yerine, satış temsilcisine göre gruplandıran ve her grup için satışları özetleyen bir veri kümesi sorgusu oluşturun.

İfade tabanlı alanlar

İfadeleri temel alan bir rapor veri kümesini genişletmek mümkündür. Örneğin, veri kümeniz müşteri adını ve soyadını kaynak olarak kullanırsa, müşterinin tam adını oluşturmak için iki alanı birleştirir bir alan isteyebilirsiniz. Bu hesaplamayı yapmak için iki seçeneğiniz vardır. Şunları yapabilirsiniz:

  • bir ifadeyi temel alan bir veri kümesi alanı olan bir hesaplanan alan oluşturun.
  • Bir ifadeyi doğrudan veri kümesi sorgusuna (veri kaynağınızın yerel dilini kullanarak) ekleyin ve bu da normal bir veri kümesi alanına neden olur.

Mümkün olduğunda ikinci seçeneği öneririz. İfadeleri doğrudan veri kümesi sorgunuza eklemenin daha iyi olmasının iki iyi nedeni vardır:

  • Veri kaynağınız, ifadeyi Power BI'dan daha verimli bir şekilde değerlendirecek şekilde iyileştirilmiş olabilir (özellikle ilişkisel veritabanları için geçerlidir).
  • Rapor işlemeden önce Power BI'ın hesaplanan alanları gerçekleştirmesine gerek olmadığından rapor performansı iyileştirildi. Hesaplanan alanlar, veri kümeleri çok sayıda satır aldığında rapor işleme süresini belirgin şekilde uzatabilir.

Alan adları

Bir veri kümesi oluşturduğunuzda, bu veri kümesinin alanları otomatik olarak sorgu sütunlarından sonra adlandırılır. Bu adların kolay veya sezgisel olması mümkün değildir. Kaynak sorgu sütun adlarının Rapor Tanım Dili (RDL) nesne tanımlayıcılarında (boşluklar ve simgeler gibi) yasaklanmış karakterler içermesi de mümkündür. Bu durumda, yasaklanmış karakterler bir alt çizgi karakteri (_) ile değiştirilir.

Öncelikle tüm alan adlarının kolay, kısa ama yine de anlamlı olduğunu doğrulamanızı öneririz. Aksi takdirde, rapor düzenine başlamadan önce bunları yeniden adlandırmanızı öneririz. Bunun nedeni, yeniden adlandırılan alanların değişiklikleri rapor düzeninizde kullanılan ifadelere yaymadığındandır. Rapor düzenine geçtikten sonra alanları yeniden adlandırmaya karar verirseniz, tüm bozuk ifadeleri bulup güncelleştirmeniz gerekir.

Filtre ve parametre karşılaştırması

Sayfalandırılmış rapor tasarımlarınızın rapor parametreleri olması muhtemeldir. Rapor parametreleri genellikle rapor kullanıcınızdan raporu filtrelemesini istemde bulunur. Sayfalandırılmış rapor yazarı olarak rapor filtrelemeyi başarmanın iki yolu vardır. Bir rapor parametresini şu şekilde eşleyebilirsiniz:

  • Bir veri kümesi filtresi; bu durumda rapor parametresi değerleri, veri kümesi tarafından zaten alınan verileri filtrelemek için kullanılır.
  • Bir veri kümesi parametresi; bu durumda rapor parametresi değerleri veri kaynağına gönderilen yerel sorguya eklenir.

Not

Tüm rapor veri kümeleri, son kullanımlarından 10 dakika sonrasına kadar oturum başına önbelleğe alınır. Veri kümesi, yeni parametre değerleri gönderirken (filtreleme), raporu farklı bir biçimde işlerken veya görünürlüğü azaltma veya sıralama gibi bir şekilde rapor tasarımıyla etkileşim kurarken yeniden kullanılabilir.

Ardından, raporu tek bir yıla göre filtrelemek için tek bir rapor parametresine sahip bir satış raporu örneği düşünün. Veri kümesi tüm yılların satışlarını alır. Bunu yapar çünkü rapor parametresi veri kümesi filtreleri ile eşlenir. Rapor, veri kümesi verilerinin bir alt kümesi olan istenen yıla ait verileri görüntüler. Rapor kullanıcısı rapor parametresini farklı bir yıla değiştirip raporu görüntülediğinde Power BI'ın herhangi bir kaynak veri alması gerekmez. Bunun yerine, zaten önbelleğe alınmış veri kümesine farklı bir filtre uygular. Veri kümesi önbelleğe alındıktan sonra filtreleme çok hızlı olabilir.

Şimdi farklı bir rapor tasarımı düşünün. Bu kez rapor tasarımı satış yılı rapor parametresini bir veri kümesi parametresiyle eşler. Bu şekilde Power BI, yerel sorguya yıl değerini ekler ve veri kümesi yalnızca o yıla ilişkin verileri alır. Rapor kullanıcısı yıl raporu parametre değerini değiştirip raporu her görüntüleyişinde veri kümesi yalnızca o yıl için yeni bir sorgu sonucu alır.

Her iki tasarım yaklaşımı da rapor verilerini filtreleyebilir ve her iki tasarım da rapor tasarımlarınız için iyi çalışabilir. Ancak iyileştirilmiş bir tasarım, beklenen veri hacimlerine, veri volatilitesine ve rapor kullanıcılarınızın beklenen davranışlarına bağlıdır.

Veri kümesi satırlarının farklı bir alt kümesinin birçok kez yeniden kullanılacağını tahmin ettiğinizde veri kümesi filtrelemesini öneririz (böylece yeni verilerin alınması gerekmeyen işleme süresinden tasarruf edilir). Bu senaryoda, daha büyük bir veri kümesini alma maliyetinin yeniden kullanım sayısına göre dengelendiğini fark edebilirsiniz. Bu nedenle, oluşturulması zaman alan sorgular için yararlıdır. Ancak dikkatli olun; büyük veri kümelerini kullanıcı başına önbelleğe almak performansı ve kapasite aktarım hızını olumsuz etkileyebilir.

Veri kümesi satırlarının farklı bir alt kümesinin istenme olasılığının düşük olduğunu veya filtrelenecek veri kümesi satırlarının sayısının çok büyük (ve önbelleğe verimsiz) olacağını tahmin ettiğinizde veri kümesi parametreleştirmesini öneririz. Bu tasarım yaklaşımı, veri deponuz geçici olduğunda da düzgün çalışır. Bu durumda, her rapor parametresi değer değişikliği güncel verilerin alınmasına neden olur.

Yerel olmayan veri kaynakları

Sayfalandırılmış raporlar tarafından yerel olarak desteklenmeyen veri kaynaklarını temel alan sayfalandırılmış raporlar geliştirmeniz gerekiyorsa, önce Power BI Desktop'ta bir veri modeli geliştirmeniz gerekir. Bu şekilde, Power BI tarafından desteklenen yüzlerce veri kaynağına bağlanabilirsiniz. Power BI hizmeti yayımlandıktan sonra Power BI anlam modeline bağlanan sayfalandırılmış bir rapor geliştirebilirsiniz.

Veri tümleştirmesi

Birden çok veri kaynağındaki verileri birleştirmeniz gerekiyorsa iki seçeneğiniz vardır:

  • Rapor veri kümelerini birleştirme: Veri kaynakları sayfalandırılmış raporlar tarafından yerel olarak destekleniyorsa, Lookup veya LookupSet Rapor Oluşturucusu işlevlerini kullanan hesaplanan alanlar oluşturmayı düşünebilirsiniz.
  • Power BI Desktop modeli geliştirme: Power BI Desktop'ta veri modeli geliştirmeniz büyük olasılıkla daha verimlidir. Desteklenen herhangi bir veri kaynağına göre sorguları birleştirmek için Power Query'yi kullanabilirsiniz. Power BI hizmeti yayımlandıktan sonra Power BI anlam modeline bağlanan sayfalandırılmış bir rapor geliştirebilirsiniz.

Ağ gecikmesi

Ağ gecikmesi, isteklerin Power BI hizmeti ulaşması ve yanıtların teslim edilmesi için gereken süreyi artırarak rapor performansını etkileyebilir. Power BI'daki kiracılar belirli bir bölgeye atanır.

İpucu

Kiracınızın nerede olduğunu belirlemek için bkz . Power BI kiracım nerede bulunur?

Kiracıdaki kullanıcılar Power BI hizmeti eriştiğinde istekleri her zaman bu bölgeye yönlendirilir. İstekler Power BI hizmeti ulaştığında, hizmet temel alınan veri kaynağına veya bir veri ağ geçidine ağ gecikmesine de tabi olan ek istekler gönderebilir. Genel olarak, ağ gecikme süresinin etkisini en aza indirmek için veri kaynaklarını, ağ geçitlerini ve Power BI kapasitenizi mümkün olduğunca yakın tutmaya çalışın. Tercihen, aynı bölgede bulunurlar. Ağ gecikmesi bir sorunsa ağ geçitlerini ve veri kaynaklarını bulutta barındırılan sanal makinelerin içine yerleştirerek Power BI kapasitenize daha yakın bir şekilde konumlandırmayı deneyin.

SQL Server karmaşık veri türleri

SQL Server şirket içi veri kaynağı olduğundan Power BI'ın bir ağ geçidi üzerinden bağlanması gerekir. Ancak ağ geçidi, karmaşık veri türleri için verilerin alınmasını desteklemez. Karmaşık veri türleri, GEOMETRY ve GEOGRAPHY uzamsal veri türleri ve hierarchyid gibi yerleşik türleri içerir. Ayrıca, Microsoft.NET Framework ortak dil çalışma zamanındaki (CLR) bir derleme sınıfı aracılığıyla uygulanan kullanıcı tanımlı türleri de içerebilir.

Harita görselleştirmesinde uzamsal veri ve analiz çizmek için SQL Server uzamsal verileri gerekir. Bu nedenle, SQL Server veri kaynağınız olduğunda harita görselleştirmesi ile çalışmak mümkün değildir. Açık olmak gerekirse, Power BI ağ geçidi üzerinden bağlanmadığından veri kaynağınız Azure SQL Veritabanı çalışır.

Resimler, rapor düzeninize logo veya resim eklemek için kullanılabilir. Görüntüler bir rapor veri kümesi tarafından alınan satırlar ile ilişkilendirildiğinde iki seçeneğiniz vardır:

  • Görüntü verileri veri kaynağınızdan da alınabilir (zaten bir tabloda depolanmışsa).
  • Görüntüler bir web sunucusunda depolandığında, görüntü URL'si yolunu oluşturmak için dinamik bir ifade kullanabilirsiniz.

Daha fazla bilgi ve öneri için bkz . Sayfalandırılmış raporlar için görüntü kılavuzu.

Yedekli veri alma

Raporunuz yedekli verileri alabilir. Veri kümesi sorgu alanlarını sildiğinizde veya raporda kullanılmayan veri kümeleri olduğunda bu durum oluşabilir. Veri kaynaklarınıza, ağınıza ve Power BI kapasite kaynaklarınıza gereksiz bir yük getirdiğinden bu durumlardan kaçının.

Silinen sorgu alanları

Veri Kümesi Özellikleri penceresinin Alanlar sayfasında, veri kümesi sorgu alanlarını silmek mümkündür (sorgu alanları veri kümesi sorgusu tarafından alınan sütunlarla eşleştirilebilir). Ancak Rapor Oluşturucusu ilgili sütunları veri kümesi sorgusundan kaldırmaz.

Sorgu alanlarını veri kümenizden silmeniz gerekiyorsa, ilgili sütunları veri kümesi sorgusundan kaldırmanızı öneririz. Rapor Oluşturucusu tüm yedekli sorgu alanlarını otomatik olarak kaldırır. Sorgu alanlarını silerseniz, sütunları kaldırmak için veri kümesi sorgu deyimini de değiştirdiğinizden emin olun.

Kullanılmayan veri kümeleri

Bir rapor çalıştırıldığında, rapor nesnelerine bağlı olmasalar bile tüm veri kümeleri değerlendirilir. Bu nedenle, bir rapor yayımlamadan önce tüm test veya geliştirme veri kümelerini kaldırdığınızdan emin olun.

İlgili içerik

Bu makaleyle ilgili daha fazla bilgi için aşağıdaki kaynaklara göz atın: