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

  • Makale
  • Okumak için 8 dakika

Bu makale Power BI sayfalandırılmış raporları tasarlayan rapor yazarlarına yöneliktir. Etkili ve verimli veri alımı tasarlamanıza yardımcı olacak öneriler sağlar.

Veri kaynağı türleri

Sayfalara alınan raporlar hem ilişkisel hem de analitik veri kaynaklarını yerel olarak destekler. Bu kaynaklar bulut tabanlı veya şirket içi olarak kategorilere ayrılmıştır. Şirket içi veri kaynakları (ister şirket içinde barındırılan ister bir sanal makinede olsun) veri ağ geçidine ihtiyaç Power BI gerektirir. Bulut tabanlı, Power BI İnternet bağlantısı kullanarak doğrudan bağlanabilirsiniz.

Veri kaynağı türünü (yeni bir projede büyük olasılıkla bu durum) seçe biliyorsanız, bulut tabanlı veri kaynaklarını kullanmanız önerilir. Sayfa sayfalı raporlar, özellikle de veri kaynakları kiracınız ile aynı bölgede yer alan daha düşük ağ gecikme süresiyle Power BI olabilir. Ayrıca, Tek Sunucu (SSO) kullanarak bu kaynaklara Sign-On mümkündür. Bu, rapor kullanıcı kimliğinin veri kaynağına akarak kullanıcı başına satır düzeyi izinlerin zorunlu kılınmalarına olanak sağlar. Şu anda SSO, şirket içi veri kaynakları için destek SQL Server Analysis Services kullanıcı başına satır düzeyi izinleri zorunlu tutulamaz.

Not

Şu anda SSO kullanarak şirket içi veritabanlarına bağlanmak mümkün değildir ancak yine de satır düzeyi izinleri zorunlu abilirsiniz. UserID yerleşik alanı bir veri kümesi sorgu parametresine göndererek 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 bir satış temsilcisinin bir tablodaki Satış Temsilcisinde satır olarak depolanmış olduğunu göz önünde bulundurabilirsiniz. Tabloda UPN sütunları ve satış temsilcisinin satış bölgesi bulunur. Sorgu zamanında tablo rapor kullanıcılarının UPN'leri tarafından filtrelenmiş ve iç birleşim kullanan satış olguları ile de ilgili. Bu şekilde sorgu, satış bilgileri satırlarını rapor kullanıcılarının satış bölgesiyle etkili bir şekilde filtreler.

İlişkisel veri kaynakları

Genellikle ilişkisel veri kaynakları, satış faturaları gibi operasyonel stil raporlara çok uygun olur. Bunlar, çok büyük veri kümelerini (10.000 satırdan fazla) almaları gereken raporlar için de uygun olur. İlişkisel veri kaynakları, rapor veri kümeleri tarafından yürütülebilecek saklı yordamlar da tanımlayabilir. Saklı yordamlar çeşitli avantajlar sunar:

  • Parameterization
  • Programlama mantığının kapsüllemesi, daha karmaşık veri hazırlamaya olanak sağlar (örneğin, geçici tablolar, imleçler veya skaler kullanıcı tanımlı işlevler)
  • Geliştirilmiş bakım, saklı yordam mantığının kolayca güncelleştirilerek korunmasını sağlar. Bazı durumlarda, sayfalandırılan 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ım için önbelleğe alınarak daha iyi performans
  • Saklı yordamları birden çok rapor arasında yeniden kullanma

Bu Power BI Report Builder, ilişkisel sorgu tasarımcısını kullanarak bir sorgu deyimini grafiksel olarak oluşturabilirsiniz, ancak yalnızca Microsoft veri kaynakları için kullanabilirsiniz.

Analitik veri kaynakları

Analiz veri kaynakları hem işletimsel hem de analiz raporları için çok uygun ve çok büyük veri hacimleri üzerinde bile hızlı özetlenmiş sorgu sonuçları sunabilirsiniz. Model ölçüleri ve KIP'ler, verilerin özetini elde etmek için karmaşık iş kurallarını kapsüller. Ancak bu veri kaynakları, çok büyük veri kümelerini (10.000 satırdan fazla) almaları gereken raporlara uygun değildir.

Bu Power BI Report Builder 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 veri kümesi veri Power BI veya tablosal veya çok boyutlu SQL Server Analysis Services veya Azure Analysis Services model için kullanılabilir.

DaX sorgu tasarımcısını kullanmanızı öneririz; bu da sorgunun tamamen sorgu ihtiyaçlarına uygun olması şartıyla. Model ihtiyacınız olan ölçüleri tanımlayamazsa sorgu moduna geçmelisiniz. Bu modda, ifade ekleyerek sorgu deyimini özelleştirebilirsiniz (özetleme elde etmek için).

MDX sorgu tasarımcısı, modelinizin ölçüler içermesini gerektirir. Tasarımcının DAX sorgu tasarımcısı tarafından desteklemez iki özelliği vardır. Özellikle şunları sağlar:

  • Sorgu düzeyinde hesaplanan üyeleri tanımlayın (MDX'te).
  • Ayrıntı olmayan gruplarda sunucu toplamlarını talep etmek için veri bölgelerini yapılandırma. Raporunuz yarı veya eklenebilir olmayan ölçülerin özetlerini (akıllı zaman zekası hesaplamaları veya ayrı sayımlar gibi) sunması gerekirse, düşük düzeyli ayrıntı satırlarını almak ve rapor işlem özetlemelerini elde etmek yerine sunucu toplamlarını kullanmak büyük olasılıkla daha verimli olur.

Sorgu sonucu boyutu

Genel olarak, yalnızca raporunuz için gereken verileri almak en iyi yöntemdir. Bu nedenle rapor için gerekli olmayan sütunları veya satırları almayabilirsiniz.

Satırları sınırlamak için her zaman en kısıtlayıcı filtreleri uygulamalı ve toplam sorguları tanımlayabilirsiniz. Daha yüksek ayrıntılı sonuçlar almak için sorguları grupla ve özetle kaynak verileri. Örneğin, rapor özetini satış temsilcisi satışlarının özetini sunarak değerlendirmeniz gerekir. Tüm satış siparişi satırlarını almak yerine satış temsilcisine göre gruplama ve her grup için satışları özetleyen bir veri kümesi sorgusu oluşturun.

İfade tabanlı alanlar

Bir rapor veri kümesi, ifadeleri temel alan alan alanlarla genişletebilirsiniz. Örneğin, veri kümeniz müşteri adı ve soyadı kaynaklarınız için müşteri tam adını üretmek için iki alanı bir alan birletir. Bu hesaplamayı gerçekleştirmek için iki seçeneğiniz vardır. Seçenekleriniz şunlardır:

  • Bir ifadeyi temel alan bir veri kümesi alanı olan hesaplanan bir alan oluşturun.
  • Bir ifadeyi doğrudan veri kümesi sorgusuna (veri kaynağınızı yerel dilini kullanarak) ekleme, 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 iki iyi nedeni vardır:

  • Veri kaynağınız, ifadeyi veri kaynağından daha verimli bir şekilde Power BI iyileştirilmiş olabilir (özellikle ilişkisel veritabanları için geçerlidir).
  • Rapor işlemeden önce hesaplanan alanları gerçekleştirmek Power BI rapor performansı iyileştirildi. Hesaplanmış alanlar, veri kümeleri çok sayıda satır geldiğinde rapor işleme süresini önemli ölçüde uzatabilirsiniz.

Alan adları

Bir veri kümesi ekleyebilirsiniz; alanları otomatik olarak sorgu sütunlarına göre adlandırılmıştır. Bu adlar kolay veya sezgisel değildir. Kaynak sorgu sütunu adlarının, Rapor Tanımlama Dili (RDL) nesne tanımlayıcılarında (boşluklar ve semboller gibi) yasaklanmış karakterler içermesi de mümkündür. Bu durumda yasaklanan karakterler bir alt çizgi karakteri (_) ile değiştirilir.

Öncelikle tüm alan adlarının kolay, kısa ancak yine de anlamlı olduğunu doğrulamanız önerilir. Yoksa, rapor düzenine başlamadan önce bunları yeniden adlandırmanızı öneririz. Bunun nedeni, yeniden adlandırılan alanların rapor düzeninde kullanılan ifadelerde değişiklik yapmak zorunda olmadığınızdır. Rapor düzenine başladıktan sonra alanları yeniden adlandırmaya karar verdiyebilirsiniz. Tüm bozuk ifadeleri bulup güncelleştirmeniz gerekir.

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

Sayfa sayfalı rapor tasarımlarınızı büyük olasılıkla rapor parametrelerine sahip olur. Rapor parametreleri genellikle rapor kullanıcınıza raporu filtrelemesini isteminde kullanılır. Sayfalı rapor yazarı olarak rapor filtrelemeyi başarmanın iki yolu vardır. Rapor parametresini şu şekilde eşebilirsiniz:

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

Not

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

Ardından, raporu tek bir yıla göre filtrelemek için tek bir rapor parametresine sahip olan bir satış raporu örneğini düşünün. Veri kümesi tüm yıllara göre satışları almaktadır. Bunu yapar çünkü rapor parametresi veri kümesi filtrelerini eşler. Rapor, veri kümesi verilerinin bir alt kümesi olan istenen yıla göre verileri görüntüler. Rapor kullanıcısı rapor parametresini farklı bir yıl olarak değiştirse ve raporu Power BI herhangi bir kaynak verisi almak zorunda değildir. Bunun yerine, önceden önbelleğe alınmış veri kümesine farklı bir filtre uygular. Veri kümesi önbelleğe alınarak filtreleme çok hızlı olabilir.

Şimdi farklı bir rapor tasarımı düşünün. Bu kez rapor tasarımı sales year rapor parametresini bir veri kümesi parametresiyle eşler. Bu şekilde Power BI yerel sorguya yıl değerini eklemesi ve veri kümesi yalnızca o yılın verilerini almalarını sağlar. Rapor kullanıcısı yıl raporu parametre değerini her değiştirse ve raporu her görüntülerse, veri kümesi yalnızca o yıl için yeni bir sorgu sonucu verir.

Her iki tasarım yaklaşımı da rapor verilerini filtreleyenin ve her iki tasarım da rapor tasarımlarınızı iyi bir şekilde kullanabilir. Ancak iyileştirilmiş bir tasarım beklenen veri hacimleri, veri dalgalanmaları ve rapor kullanıcılarının tahmin edilen davranışlarına bağlıdır.

Veri kümesi satırlarının farklı bir alt kümesinin birçok kez yeniden kullan olacağını tahmin ediyorken veri kümesi filtrelemesini öneririz (bu nedenle yeni verilerin alınmayacak olması nedeniyle işleme süresi tasarrufu sağlar). Bu senaryoda, daha büyük bir veri kümesini alma maliyetinin kaç kez yeniden kullanılabilir hale uğrayacağını tanıırın. Bu nedenle, bir zaman üreten sorgular için yararlıdır. Ancak, büyük veri kümelerini Kullanıcı bazında önbelleğe almak performansı olumsuz yönde etkileyebilir ve kapasite performansı olumsuz etkileyebilir.

Veri kümesi satırlarının farklı bir alt kümesinin istenmesini veya filtre uygulanacak veri kümesi satırlarının sayısının çok büyük (ve önbelleğe alma için verimsiz) olma olasılığını tahmin ettiğinizde veri kümesi Parametreleştirme önerilir. Veri depoluyseniz, bu tasarım yaklaşımı iyi çalışır. Bu durumda, her rapor parametre değeri değişikliği güncel verilerin alınmasına neden olur.

Yerel olmayan veri kaynakları

sayfalandırılmış raporlar tarafından yerel olarak desteklenmeyenveri kaynaklarını temel alan sayfalandırılmış raporlar geliştirmeniz gerekiyorsa, önce Power BI Desktop bir veri modeli geliştirebilirsiniz. bu şekilde, 100 Power BI veri kaynağınabağlanabilirsiniz. Power BI hizmetine yayımlandıktan sonra, Power BI veri kümesine bağlanan bir sayfalandırılmış rapor geliştirebilirsiniz.

Veri tümleştirmesi

Birden çok veri kaynağından 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, arama veya lookupset Report Builder işlevlerini kullanan hesaplanmış alanlar oluşturmayı deneyebilirsiniz.
  • Power BI Desktop modeli geliştirin: Power BI Desktop ' de bir veri modeli geliştirmeniz büyük olasılıkla daha etkilidir. Sorguları, desteklenen herhangi bir veri kaynağınagöre birleştirmek için Power Query kullanabilirsiniz. Power BI hizmetine yayımlandıktan sonra, Power BI veri kümesine bağlanan bir sayfalandırılmış rapor geliştirebilirsiniz.

SQL Server karmaşık veri türleri

SQL Server, bir şirket içi veri kaynağı olduğundan, Power BI bir ağ geçidi üzerinden bağlanmalıdır. Ancak ağ geçidi, karmaşık veri türleri için veri almayı desteklemez. Karmaşık veri türleri, geometrı ve Coğrafya uzamsal veri türlerive HierarchyIdgibi yerleşik türler içerir. Ayrıca, Microsoft.NET Framework ortak dil çalışma zamanı (CLR) içindeki 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 veri gerekir. bu nedenle, veri kaynağınız SQL Server, harita görselleştirmesi ile çalışmanız mümkün değildir. açık olması için, Power BI bir ağ geçidi aracılığıyla bağlanamadığı için veri kaynağınız Azure SQL Veritabanı, bu işlem çalışacaktır.

Görüntüler, 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ırlarla ilişkilendiriliyorsa iki seçeneğiniz vardır:

  • Görüntü verilerinin veri kaynağınızdan de alınması mümkündür (zaten bir tabloda depolanıyorsa).
  • 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.

Gereksiz veri alımı

Raporunuzun gereksiz verileri almasına olanak mümkündür. Bu, veri kümesi sorgu alanlarını sildiğinizde veya raporun kullanılmayan veri kümelerine sahip olması durumunda gerçekleşebilir. veri kaynaklarınızda, ağda ve Power BI kapasite kaynaklarında gereksiz bir yük oluşmasına neden olduğundan 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 sorgusunun aldığı sütunlara eşlenir). ancak Report Builder, veri kümesi sorgusundan ilgili sütunları kaldırmaz.

Veri kümenizdeki sorgu alanlarını silmeniz gerekiyorsa, karşılık gelen sütunları veri kümesi sorgusundan kaldırmanızı öneririz. Report Builder, tüm gereksiz sorgu alanlarını otomatik olarak kaldırır. Sorgu alanlarını silme durumunda sütunları kaldırmak için DataSet sorgu ifadesini de değiştirdiğinizden emin olun.

Kullanılmayan veri kümeleri

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

Sonraki adımlar

Bu makaleyle ilgili daha fazla bilgi için aşağıdaki kaynaklara bakın: