Aracılığıyla paylaş

Etkin ve etkin olmayan ilişki kılavuzu

  • Makale

Bu makalede Power BI Desktop ile çalışan bir veri modelleyicisi olarak hedefleniyorsunuz. 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. Etkin olmayan ilişki, ancak bir DAX ifadesi ilişkiyi etkinleştirip kullandığında filtreleri uygular.

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 Modeli 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ı anlama ve Power BI’nın önemini anlama.

Etkin ilişkiler

Genel olarak, mümkün olduğunda etkin ilişkiler tanımlamanızı öneririz. Modelinizin rapor yazarları ve Q&A ile çalışan kullanıcılar tarafından nasıl kullanılabileceğinin kapsamını ve potansiyelini genişletiyorlar.

Havayolu uçuşlarının zamanında performansını (OTP) analiz etmek için tasarlanmış İçe Aktarma modeli örneğini düşünün. Modelde, uçuş başına bir satır depolayan olgu tablosu olan bir tablosu vardır. Her satır, uçuş tarihini, uçuş numarasını, kalkış ve varış havalimanlarını ve gecikme süresini (dakika cinsinden) kaydeder. Ayrıca, her havaalanı için bir satır depolayan bir boyut tablosu olan bir 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.

İki tablo içeren modeli gösteren Diyagramı: Uçuş ve Havaalanı. İlişki tasarımı aşağıdaki paragrafta açıklanmıştır.

Flight ile 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 oynama boyutuolarak tanımlanır. Bu modelde, iki rol kalkış havaalanı ve varış havaalanı'tür.

Bu tasarım ilişkisel yıldız şeması tasarımlarına uygun olsa da Power BI modellerinde iyi çalışmaz. 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 gösterildiği gibi, bir ilişki etkinken diğeri etkin değil (kesikli çizgiyle gösterilir). Özel olarak, etkin olan ArrivalAirport sütunuyla olan ilişkidir; bu da Airport tablosuna uygulanan filtrelerin otomatik olarak Flight tablosunun ArrivalAirport sütununa yayıldığı 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 Airport tablosunu filtrelemek mümkün değildir. Raporlarınaynı anda kalkış ve varış havalimanlarına göre filtrelemesi (veya grup etmesi) gerektiğinden, iki etkin ilişki gereklidir. 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.

Dört tablo içeren modeli gösteren Diyagramı: Date, Flight, Departure Airport ve Arrival Airport.

Modelde artık iki havaalanı tablosu vardır: Departure Airport ve Arrival Airport. Bu tablolar ile Flight tablo arasındaki her model ilişkisi etkindir. Ayrıca, Departure Airport ve Arrival Airport tablolarındaki sütun adlarının başında Departure veya Arrivalsözcüğünün bulunduğuna dikkat edin.

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

Bir rapor sayfasının iki dilimleyiciye ve bir tablo görseline sahip olduğunu gösteren diyagram. Dilimleyiciler Ay ve Kalkış Havaalanı'dır.

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

Not

İçeri aktarma modelleri için başka bir boyut tablosunun eklenmesi model boyutunun artmasına ve daha uzun yenileme sürelerine 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 tablolarının olgu tablosu satır sayılarına göre düşük satır sayılarını depolaması 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 yürütme boyut tablosundan bir rolbaşına bir tablo bir tasarıma yeniden düzenleme yöntemi yer alır.

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

  2. Rolünü daha iyi tanımlamak için rol yapma boyut tablosunun adını değiştirmeyi düşünün. Bu makaledeki örnekte, Airport tablosu Flight tablosunun ArrivalAirport sütunuyla ilişkilidir, bu nedenle Arrival Airportolarak yeniden adlandırılır.

  3. Rol yapma tablosunun bir kopyasını oluşturun ve ona rolünü yansıtan bir ad verin. İçeri Aktarma tablosuysa, hesaplanmış bir tablo oluşturmanı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. Bu makaledeki örnekte, tüm sütunlara Departure veya Arrivalsözcüğü eklenmiştir. Bu adlar rapor görsellerinin varsayılan olarak kendini açıklayan ve belirsiz olmayan etiketlere sahip olmasını sağlar. Ayrıca Q&A deneyimini geliştirerek kullanıcıların kolayca doğru sorular yazabilmesini sağlar.

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

Etkin olmayan ilişkiler

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

Farklı model ve raporlama gereksinimlerini göz önünde bulundurun:

  • Satış modeli, iki tarih sütunu içeren bir Sales tablosu içerir: OrderDate ve ShipDate.
  • Sales tablosundaki her satır tek bir sıra kaydeder.
  • Tarih filtreleri, her zaman geçerli bir tarihi depolayan OrderDate sütununa hemen her zaman uygulanır.
  • Yalnızca bir ölçü, ShipDate sütununa tarih filtresinin uygulanmasını gerektirir ve bu sütunda boşluklar bulunabilir (sipariş gönderilene kadar).
  • Sipariş ve sevk tarihi dönemlerini aynı anda filtrelemek (veya gruplandırmak) gerekmez.

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

İki tablo içeren bir modeli gösteren Diyagramı: Satış ve Tarih. Sales tablosu altı ölçü içerir.

Sales ile 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 tarihi. Etkin olan OrderDate sütunuyla olan ilişkidir.

Biri hariç altı ölçü de OrderDate sütununa göre filtrelenmelidir. Ancak Orders Shipped ölçüsünün ShipDate sütununa göre filtrelemesi gerekir.

İşte Orders ölçü tanımı. Filtre bağlamı içindeki Sales tablosunun satırlarını sayar. Date tablosuna uygulanan filtreler OrderDate sütununa yayılır.

Orders = COUNTROWS(Sales)

İşte Orders Shipped ölçüm tanımı. USERELATIONSHIP DAX işlevini kullanır, bu işlev yalnızca ifadenin değerlendirilmesi sırasında belirli bir ilişki için filtre yayılımını etkinleştirir. Bu örnekte, ShipDate sütunuyla ilişki kullanılı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.

Bir dilimleyici ve tablo görseli içeren bir rapor sayfasını gösteren diyagram. Dilimleyici Üç Aylık Dönem'dir ve tablo görselinde aylık satış istatistikleri listelenir.

Rapor sayfası 2019 Q4için çeyrek bazında filtrelenir. Tablo görseli aya göre gruplandırır ve çeşitli satış istatistiklerini görüntüler. Orders ve Orders Shipped ölçüleri farklı sonuçlar üretir. Her biri aynı özetleme mantığını (Sales tablosunun satırlarını sayma) ama farklı Date tablo filtresi yayma kullanır.

Çeyrek dilimleyicinin BLANK seçeneği içerdiğine dikkat edin. Bu dilimleyici seçeneği, tablo genişletmesi'nin bir sonucu olarak görüntülenir. Her Sales tablo satırının geçerli 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şkiye ait çokluk tarafındaki BLANK'lardan (veya veri bütünlüğü sorunlarından) kaynaklanan BLANK'lar ortaya çıkabilir.

Not

Satır düzeyi güvenlik (RLS) filtreleri yalnızca etkin ilişkiler aracılığıyla yayılır. USERELATIONSHIP DAX işlevi ölçü tanımı tarafından kullanıldığında bile RLS filtreleri hiçbir zaman etkin olmayan ilişkiler için yayılmaz.

Öneri

Mümkün olduğunda, özellikle de veri modeliniz için RLS rolleri tanımlandığında etkin ilişkiler tanımlamanızı öneririz. Modelinizin rapor yazarları ve Q&A ile çalışan kullanıcılar tarafından nasıl kullanılabileceğinin kapsamını ve potansiyelini genişletiyorlar. Bu, rol yapma boyut tablolarının modelinizde çoğaltılması gerektiği anlamına gelir.

Ancak belirli durumlarda, rol oynayan bir boyut tablosu için bir veya daha fazla pasif ilişki tanımlayabilirsiniz. Aşağıdaki durumlarda bu yaklaşımı göz önünde bulundurabilirsiniz:

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

İlgili içerik

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