Aracılığıyla paylaş

Etkin ve etkin olmayan ilişki kılavuzu

  • Makale

Bu makale, Power BI Desktop ile çalışan bir veri modelleyicisi olarak sizi hedefler. Etkin veya etkin olmayan model ilişkilerinin ne zaman oluşturulacağı konusunda size rehberlik sağlar. Varsayılan olarak, etkin ilişkiler filtreleri diğer tablolara yayılır. Ancak etkin olmayan ilişki, yalnızca bir DAX ifadesi ilişkiyi etkinleştirdiğinde (kullandığında) filtreleri yayılır.

Not

Model ilişkilerine giriş bu makalede ele alınmamıştır. İlişkiler, özellikleri veya bunların nasıl yapılandırıldığını tam olarak bilmiyorsanız, önce Power BI Desktop'ta Model ilişkileri makalesini okumanızı öneririz.

Yıldız şeması tasarımını anlamanız da önemlidir. Daha fazla bilgi için bkz . Yıldız şemasını ve Power BI'ın önemini anlama.

Etkin ilişkiler

Genellikle mümkün olduğunda etkin ilişkileri tanımlamanızı öneririz. Modelinizin rapor yazarları ve Soru-Cevap ile çalışan kullanıcılar tarafından nasıl kullanılabileceğinin kapsamını ve potansiyelini genişletiyorlar.

Havayolu uçuşunun zamanında performansını (OTP) analiz etmek için tasarlanmış bir İçeri Aktarma modeli örneğini düşünün. Model, uçuş başına bir satır depolayan olgu türündeki bir tablo olan Flight tablosuna sahiptir. Her satır, uçuş tarihini, uçuş numarasını, kalkış ve varış havalimanlarını ve gecikme süresini (dakika cinsinden) kaydeder. Ayrıca havaalanı başına bir satır depolayan boyut türündeki bir tablo olan Airport tablosu da vardır. Her satırda havaalanı kodu, havaalanı adı ve ülke veya bölge açıklanır.

burada iki tablonun kısmi model diyagramı yer alır.

Diagram showing a model containing two tables: Flight and Airport. The relationship design is described in the following paragraph.

Flight ve Airport tabloları arasında iki model ilişkisi vardır. Flight tablosunda, DepartureAirport ve ArrivalAirport sütunları Airport tablosunun Airport sütunuyla ilgilidir. Yıldız şeması tasarımında Airport tablosu rol yapma boyutu olarak tanımlanır. Bu modelde iki rol kalkış havaalanı ve varış havaalanıdır.

Bu tasarım ilişkisel yıldız şeması tasarımlarına uygun olsa da Power BI modellerinde işe yaramaz. Bunun nedeni, model ilişkilerinin filtre yayma yolları olması ve bu yolların belirleyici olması gerekir. Filtre yayma yollarının belirlenimci olduğundan emin olunması hakkında daha fazla bilgi için bkz . ilişki yolu belirsizliğini çözme. Bu nedenle, bu örnekte açıklandığı gibi, bir ilişki etkinken diğeri etkin değil (kesikli çizgiyle gösterilir). Özellikle, etkin olan ArrivalAirport sütunuyla olan ilişkidir. Bu, Airport tablosuna uygulanan filtrelerin Flight tablosunun ArrivalAirport sütununa otomatik olarak yayılacağı anlamına gelir.

Bu model tasarımı, verilerin nasıl rapor edilebileceği konusunda ciddi sınırlamalar getirir. Özellikle, kalkış havaalanının uçuş ayrıntılarını otomatik olarak yalıtmak için Havaalanı tablosunu filtrelemek mümkün değildir. Raporlama gereksinimleri aynı anda kalkış ve varış havalimanlarına göre filtreleme (veya gruplandırma) gerektirdiğinden, iki etkin ilişki gerekir. Bu gereksinimi bir Power BI modeli tasarımına çevirmek, modelin iki havaalanı tablosu olması gerektiği anlamına gelir.

Geliştirilmiş model tasarımı aşağıdadır.

Diagram showing a model containing four tables: Date, Flight, Departure Airport, and Arrival Airport.

Modelde artık iki havaalanı tablosu vardır: Departure Havaalanı ve Varış Havaalanı. Bu tablolar ile Flight tablosu arasındaki model ilişkileri etkindir. Ayrıca Departure Airport ve Arrival Airport tablolarındaki sütun adlarının önüne Departure veya Arrival sözcüğünün eklendiğine dikkat edin.

Geliştirilmiş model tasarımı aşağıdaki rapor tasarımının üretilmesine destek sunar.

Diagram showing a report page has two slicers and a table visual. The slicers are Month and Departure Airport.

Rapor sayfası Melbourne'e göre kalkış havaalanı olarak filtrelenir ve tablo görseli varış havalimanlarına göre gruplandırır.

Not

İçeri aktarma modelleri için ek tablo model boyutunun artmasına ve yenileme sürelerinin daha uzun sürmesine neden olmuştur. Bu nedenle, İçeri Aktarma modellemesi için veri azaltma teknikleri makalesinde açıklanan önerilerle çelişmektedir . Ancak örnekte, yalnızca etkin ilişkilere sahip olma gereksinimi bu önerileri geçersiz kılar.

Ayrıca, boyut türündeki tabloların olgu türündeki tablo satır sayılarına göre düşük satır sayıları içermesi yaygın bir durumdur. Bu nedenle, model boyutunun ve yenileme sürelerinin artması büyük olasılıkla aşırı büyük değildir.

Yeniden düzenleme metodolojisi

Aşağıda, bir modeli tek bir rol oynayan boyut türündeki tablodan, rol başına bir tablo içeren bir tasarıma yeniden düzenleme yöntemi yer alır.

  1. Etkin olmayan ilişkileri kaldırın.

  2. Rolünü daha iyi açıklamak için rol oynayan boyut türündeki tabloyu yeniden adlandırmayı göz önünde bulundurun. Örnekte, Airport tablosu Flight tablosunun ArrivalAirport sütunuyla ilişkilidir, bu nedenle Arrival Airport olarak yeniden adlandırılır.

  3. Rol yapma tablosunun bir kopyasını oluşturarak rolünü yansıtan bir ad sağlayın. Bu bir İçeri Aktarma tablosuysa, hesaplanan tablo tanımlamanızı öneririz. Bu bir DirectQuery tablosuysa, Power Query sorgusunu çoğaltabilirsiniz.

    Örnekte Departure Airport tablosu aşağıdaki hesaplanmış tablo tanımı kullanılarak oluşturulmuştur.

    Departure Airport = 'Arrival Airport'

  4. Yeni tabloyu ilişkilendirmek için etkin bir ilişki oluşturun.

  5. Tablolardaki sütunları yeniden adlandırarak rollerini doğru yansıtmalarını sağlamayı göz önünde bulundurun. Örnekte, tüm sütunlara Departure veya Arrival sözcüğü ön eklenmiştir. Bu adlar rapor görsellerinin varsayılan olarak kendini açıklayan ve belirsiz olmayan etiketlere sahip olmasını sağlar. Ayrıca Soru-Cevap deneyimini geliştirerek kullanıcıların sorularını kolayca yazabilmesini sağlar.

  6. Rol yapma tablolarına açıklama eklemeyi göz önünde bulundurun. (Alanlar bölmesi, rapor yazarı imlecini tablonun üzerine getirdiğinde araç ipucunda bir açıklama görüntülenir.) Bu şekilde, ek filtre yayma ayrıntılarını rapor yazarlarınıza iletebilirsiniz.

Etkin olmayan ilişkiler

Belirli durumlarda, etkin olmayan ilişkiler özel raporlama gereksinimlerini karşılayabilir.

Şimdi farklı model ve raporlama gereksinimlerini ele alalım:

  • Satış modeli, iki tarih sütunu içeren bir Sales tablosu içerir: OrderDate ve ShipDate
  • Sales tablosundaki her satır tek bir sipariş kaydeder
  • Tarih filtreleri, her zaman geçerli bir tarihi depolayan OrderDate sütununa neredeyse her zaman uygulanır
  • Yalnızca bir ölçü ShipDate sütununa tarih filtresi yayma gerektirir ve bu sütunDA BOŞLUKlar bulunabilir (sipariş gönderilene kadar)
  • Sipariş ve sevk tarihi dönemlerini aynı anda filtreleme (veya gruplandırma) gereksinimi yoktur

burada iki tablonun kısmi model diyagramı yer alır.

Diagram showing a model containing two tables: Sales and Date. The Sales table includes six measures.

Sales ve Date tabloları arasında iki model ilişkisi vardır. Sales tablosunda, OrderDate ve ShipDate sütunları Date tablosunun Date sütunuyla ilgilidir. Bu modelde Date tablosunun iki rolü sipariş tarihi ve sevk tarihidir. Etkin olan OrderDate sütunuyla olan ilişkidir.

Altı ölçüden (biri hariç) tümü OrderDate sütununa göre filtrelenmelidir. Bununla birlikte, Sevk Edilen Siparişler ölçüsünün ShipDate sütununa göre filtrelemesi gerekir.

Siparişler ölçü tanımı aşağıdadır. Yalnızca Sales tablosunun filtre bağlamındaki satırlarını sayar. Date tablosuna uygulanan tüm filtreler OrderDate sütununa yayılır.

Orders = COUNTROWS(Sales)

Siparişler Sevk Edilen ölçü tanımı aşağıdadır . Yalnızca ifadenin değerlendirilmesi sırasında belirli bir ilişki için filtre yayma özelliğini etkinleştiren USERELATIONSHIP DAX işlevini kullanır. Bu örnekte ShipDate sütunuyla ilişki kullanılmıştır.

Orders Shipped =
CALCULATE(
    COUNTROWS(Sales)
    ,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)

Bu model tasarımı aşağıdaki rapor tasarımının üretilmesine destek sunar.

Diagram showing a report page with one slicer and a table visual. The slicer is Quarter, and the table visual lists monthly sales statistics.

Rapor sayfası 2019 Q4 çeyreğine göre filtrelenir. Tablo görseli aya göre gruplandırır ve çeşitli satış istatistiklerini görüntüler. Siparişler ve Sevk Edilen Siparişler ölçüleri farklı sonuçlar üretir. Her biri aynı özetleme mantığını (Sales tablosunun satırlarını sayma) ama farklı Tarih tablosu filtresi yayma kullanır.

Çeyrek dilimleyicinin BLANK öğesi içerdiğine dikkat edin. Bu dilimleyici öğesi tablo genişletmesinin bir sonucu olarak görünür. Her Satış tablosu satırının bir sipariş tarihi olsa da, bazı satırların bir BLANK sevk tarihi vardır; bu siparişler henüz gönderilmemiştir. Tablo genişletme, etkin olmayan ilişkileri de dikkate alır ve bu nedenle ilişkinin çok tarafındaki BLANK'lardan veya veri bütünlüğü sorunlarından dolayı BLANK'ler görünebilir.

Not

Satır düzeyi güvenlik filtreleri yalnızca etkin ilişkiler aracılığıyla yayılır. UseRelationship bir ölçü tanımına açıkça eklense bile satır düzeyi güvenlik filtreleri etkin olmayan ilişkiler için yayılmaz.

Öneriler

Özetle, özellikle veri modeliniz için satır düzeyi güvenlik rolleri tanımlandığında mümkün olduğunda etkin ilişkileri tanımlamanızı öneririz. Modelinizin rapor yazarları ve Soru-Cevap ile çalışan kullanıcılar tarafından nasıl kullanılabileceğinin kapsamını ve potansiyelini genişletiyorlar. Bu, rol oynayan boyut türündeki tabloların modelinizde çoğaltılması gerektiği anlamına gelir.

Ancak belirli durumlarda rol oynayan boyut türündeki bir tablo için bir veya daha fazla etkin olmayan ilişki tanımlayabilirsiniz. Aşağıdaki durumlarda bu tasarımı göz önünde bulundurabilirsiniz:

  • Rapor görsellerinin aynı anda farklı rollere göre filtrelemesi gerekmez
  • USERELATIONSHIP DAX işlevini, ilgili model hesaplamaları için belirli bir ilişkiyi etkinleştirmek için kullanırsınız

İlgili içerik

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