Etkin ve etkin olmayan ilişki karşılaştırması kılavuzuActive vs inactive relationship guidance

Bu makale, Power BI Desktop'la çalışan veri modelleyicilerine yöneliktir.This article targets you as a data modeler working with Power BI Desktop. Ne zaman etkin, ne zaman etkin olmayan model ilişkileri oluşturacağınız konusunda size yol gösterir.It provides you with guidance on when to create active or inactive model relationships. Varsayılan olarak etkin ilişkiler filtreleri diğer tablolara yayar.By default, active relationships propagate filters to other tables. Öte yandan etkin olmayan ilişkiler yalnızca bir DAX ifadesi ilişkiyi etkinleştirdiğinde (kullandığında) filtreleri yayar.Inactive relationship, however, only propagate filters when a DAX expression activates (uses) the relationship.

Not

Model ilişkilerine giriş konusu bu makalenin kapsamı dışındadır.An introduction to model relationships is not covered in this article. İlişkileri, onların özelliklerini ve nasıl yapılandırılacağını tam olarak bilmiyorsanız, önce Power BI Desktop'ta model ilişkileri makalesini okumanızı öneririz.If you're not completely familiar with relationships, their properties or how to configure them, we recommend that you first read the Model relationships in Power BI Desktop article.

Ayrıca yıldız şeması tasarımını anlamış olmanız da önemlidir.It's also important that you have an understanding of star schema design. Daha fazla bilgi için bkz. Yıldız şemasını ve Power BI için önemini anlama.For more information, see Understand star schema and the importance for Power BI.

Etkin ilişkilerActive relationships

Genel olarak mümkün olduğunca etkin ilişkiler tanımlamanızı öneririz.Generally, we recommend defining active relationships whenever possible. Bunlar modelinizin rapor yazarları ve Soru-Cevap özelliğiyle çalışan kullanıcılar tarafından kullanılma kapsamını genişletir ve potansiyelini artırır.They widen the scope and potential of how your model can be used by report authors, and users working with Q&A.

Hava yolları uçuşlarının zamanlamaya uyma performansını (OTP) analiz etmek için tasarlanmış örnek bir İçeri Aktarma modeli düşünün.Consider an example of an Import model designed to analyze airline flight on-time performance (OTP). Modelin, uçuş başına bir satırın depolandığı olgu türünde bir tablo olan Flight tablosu vardır.The model has a Flight table, which is a fact-type table storing one row per flight. Her satırda uçuş tarihi, uçuş numarası, kalkış ve variş havaalanları ve gecikme süresi (dakika cinsinden) kaydedilir.Each row records the flight date, flight number, departure and arrival airports, and any delay time (in minutes). Ayrıca, havaalanı başına bir satırın depolandığı boyut türünde bir Airport tablosu da vardır.There's also an Airport table, which is a dimension-type table storing one row per airport. Her satırda havaalanı kodu, havaalanı adı ve ülke belirtilir.Each row describes the airport code, airport name, and the country.

Burada iki tablonun kısmi bir model diyagramı verilmiştir.Here's a partial model diagram of the two tables.

İki tablo içeren bir modeli gösteren diyagram: Flight ve Airport.

Flight ile Airport tabloları arasında iki model ilişkisi vardır.There are two model relationships between the Flight and Airport tables. Flight tablosundaki DepartureAirport ve ArrivalAirport sütunları Airport tablosunun Airport sütunuyla ilişkilendirilir.In the Flight table, the DepartureAirport and ArrivalAirport columns relate to the Airport column of the Airport table. Yıldız şema tasarımında Airport tablosu rol yapan boyut olarak açıklanır.In star schema design, the Airport table is described as a role-playing dimension. Bu modelde, iki rol kalkış havaalanı ve varış havaalanı rolleridir.In this model, the two roles are departure airport and arrival airport.

Bu tasarım ilişkili yıldız şeması tasarımlarında düzgün çalışsa da Power BI modellerinde çalışmaz.While this design works well for relational star schema designs, it doesn't for Power BI models. Çünkü model ilişkileri filtreyi yayma yollarıdır ve bu yolların kararlı olması gerekir.It's because model relationships are paths for filter propagation, and these paths must be deterministic. Bu nedenle modelde iki tablo arasında birden çok etkin ilişki olamaz.For this reason, a model cannot have multiple active relationships between two tables. Dolayısıyla bu örnekte açıklandığı gibi bir ilişki etkin olduğunda diğer ilişki etkin değildir (kesikli çizgiyle gösterilir).Therefore—as described in this example—one relationship is active while the other is inactive (represented by the dashed line). Özel olarak belirtmek gerekirse, etkin olan ilişki ArrivalAirport sütunuyla arasındaki ilişkidir.Specifically, it's the relationship to the ArrivalAirport column that's active. Diğer bir deyişle Airport tablosuna uygulanan filtreler Flight tablosunun ArrivalAirport sütununa otomatik olarak yayılır.This means filters applied to the Airport table automatically propagate to the ArrivalAirport column of the Flight table.

Bu model tasarımı verilerin bildirilme şekline sıkı sınırlamalar getirir.This model design imposes severe limitations on how the data can be reported. Özel olarak belirtmek gerekirse, bir varış havaalanının uçuş ayrıntılarını otomatik olarak yalıtmak için Airport tablosunu filtrelemek mümkün değildir.Specifically, it's not possible to filter the Airport table to automatically isolate flight details for a departure airport. Raporlama gereksinimleri arasında aynı anda kalkış ve varış havaalanlarına göre filtreleme (veya gruplandırma) olduğundan, iki etkin ilişki gerekir.As reporting requirements involve filtering (or grouping) by departure and arrival airports at the same time, two active relationships are needed. Bu gereksinim bir Power BI model tasarımına çevrildiğinde, modelin iki havaalanı tablosu olması gerektiği anlaşılır.Translating this requirement into a Power BI model design means the model must have two airport tables.

İşte geliştirilmiş bir model tasarımı.Here's the improved model design.

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

Şimdi modelin iki havaalanı tablosu vardır: Departure Airport ve Arrival Airport.The model now has two airport tables: Departure Airport and Arrival Airport. Bu tablolarla Flight tablosu arasındaki model ilişkileri etkin ilişkilerdir.The model relationships between these tables and the Flight table are active. Ayrıca Departure Airport ve Arrival Airport tablolarındaki sütun adlarının başına Departure veya Arrival sözcüğünün eklendiğine de dikkat edin.Notice also that the column names in the Departure Airport and Arrival Airport tables are prefixed with the word Departure or Arrival.

Geliştirilmiş model tasarımı aşağıdaki rapor tasarımını destekler.The improved model design supports producing the following report design.

İki dilimleyici ve bir tablo görselinin bulunduğu rapor sayfasını gösteren diyagram.

Rapor sayfası kalkış havaalanı olarak Melbourne’e göre filtrelenir ve tablo görseli varış havaalanlarına göre gruplandırılır.The report page filters by Melbourne as the departure airport, and the table visual groups by arrival airports.

Not

İçeri Aktarma modellerinde, ek tablo model boyutunu artırmış ve yenileme sürelerini uzatmıştır.For Import models, the additional table has resulted in an increased model size, and longer refresh times. Dolayısıyla İçeri Aktarma modellemesinde veri azaltma teknikleri makalesinde açıklanan önerilerle çelişmektedir.As such, it contradicts the recommendations described in the Data reduction techniques for Import modeling article. Öte yandan, örnekte yalnızca etkin ilişkiler bulunması gereksinimi söz konusu önerileri geçersiz kılar.However, in the example, the requirement to have only active relationships overrides these recommendations.

Üstelik boyut türünde tablolarda satır sayısının olgu türündeki tablolara göre daha az olması yaygın bir durumdur.Further, it's common that dimension-type tables contain low row counts relative to fact-type table row counts. Dolayısıyla model boyutundaki ve yenileme sürelerindeki artış büyük olasılıkla aşırı fazla olmayacaktır.So, the increased model size and refresh times aren't likely to be excessively large.

Yeniden düzenleme yöntemiRefactoring methodology

Burada bir modeli, rol yapan boyut türünde tek tablodan rol başına bir tablo içeren bir tasarıma göre yeniden düzenleme yöntemi gösterilir.Here's a methodology to refactor a model from a single role-playing dimension-type table, to a design with one table per role.

  1. Etkin olmayan tüm ilişkileri kaldırın.Remove any inactive relationships.

  2. Rolünü daha iyi açıklamak için rol yapan boyut türünde tablonun adını değiştirmeyi göz önünde bulundurun.Consider renaming the role-playing dimension-type table to better describe its role. Örnekte Airport tablosu Flight tablosunun ArrivalAirport sütunuyla ilişkilidir, bu nedenle Arrival Airport olarak yeniden adlandırılır.In the example, the Airport table is related to the ArrivalAirport column of the Flight table, so it's renamed as Arrival Airport.

  3. Rol yapan tablonun bir kopyasını oluşturun ve buna rolünü yansıtan bir ad verin.Create a copy of the role-playing table, providing it with a name that reflects its role. Bu bir İçeri Aktarma tablosuysa, hesaplanan tablo tanımlamanızı öneririz.If it's an Import table, we recommend defining a calculated table. Bu bir DirectQuery tablosuysa, Power Query sorgusunu çoğaltabilirsiniz.If it's a DirectQuery table, you can duplicate the Power Query query.

    Örnekte Departure Airport tablosu aşağıdaki hesaplanan tablo tanımı kullanılarak oluşturulmuştur.In the example, the Departure Airport table was created by using the following calculated table definition.

    Departure Airport = 'Arrival Airport'
    
  4. Yeni tabloyu ilişkilendirmek için etkin ilişki oluşturun.Create an active relationship to relate the new table.

  5. Rollerini doğru yansıtacak şekilde tablolardaki sütunları yeniden adlandırmayı göz önünde bulundurun.Consider renaming the columns in the tables so they accurately reflect their role. Örnekte tüm sütunların önüne Departure veya Arrival sözcüğü eklenmiştir.In the example, all columns are prefixed with the word Departure or Arrival. Bu adlar rapor görsellerinin varsayılan olarak açıklayıcı ve belirgin etiketlere sahip olmasını sağlar.These names ensure report visuals, by default, will have self-describing and non-ambiguous labels. Ayrıca Soru-Cevap deneyimini de geliştirerek kullanıcıların sorularını kolayca yazabilmesini sağlar.It also improves the Q&A experience, allowing users to easily write their questions.

  6. Rol yapan tablolara açıklamalar eklemeyi göz önünde bulundurun.Consider adding descriptions to role-playing tables. (Alanlar bölmesinde, rapor yazarı imlecini tablonun üzerine getirdiğinde bu açıklama bir araç ipucunda görüntülenir.) Bu yolla ek filtre yayma ayrıntılarını rapor yazarlarınıza iletebilirsiniz.(In the Fields pane, a description appears in a tooltip when a report author hovers their cursor over the table.) This way, you can communicate any additional filter propagation details to your report authors.

Etkin olmayan ilişkilerInactive relationships

Belirli durumlarda etkin olmayan ilişkiler özel raporlama gereksinimlerini karşılayabilir.In specific circumstances, inactive relationships can address special reporting needs.

Şimdi farklı model ve raporlama gereksinimlerini düşünelim:Let's now consider different model and reporting requirements:

  • Bir satış modelinin iki tarih sütunu içeren bir Sales tablosu vardır: OrderDate ve ShipDateA sales model contains a Sales table that has two date columns: OrderDate and ShipDate
  • Sales tablosundaki her satırda tek bir sipariş kaydedilirEach row in the Sales table records a single order
  • Her zaman geçerli bir tarihin depolandığı OrderDate sütununa neredeyse her zaman tarih filtreleri uygulanırDate filters are almost always applied to the OrderDate column, which always stores a valid date
  • Yalnızca bir ölçü, BOŞLUKLAR içerebilen ShipDate sütununa tarih filtresi yaymayı gerektirir (sipariş gönderilene kadar BOŞLUK içerir)Only one measure requires date filter propagation to the ShipDate column, which can contain BLANKs (until the order is shipped)
  • Sipariş ve gönderme tarihi dönemlerini eşzamanlı olarak filtreleme gereksinimi yokturThere's no requirement to simultaneously filter (or group by) order and ship date periods

Burada iki tablonun kısmi bir model diyagramı verilmiştir.Here's a partial model diagram of the two tables.

İki tablo içeren bir modeli gösteren diyagram: Sales ve Date.

Sales ile Date tabloları arasında iki model ilişkisi vardır.There are two model relationships between the Sales and Date tables. Sales tablosundaki OrderDate ve ShipDate sütunları Date tablosunun Date sütunuyla ilişkilidir.In the Sales table, the OrderDate and ShipDate columns relate to the Date column of the Date table. Bu modelde Date tablosuna yönelik iki rol sipariş tarihi ve gönderme tarihi rolleridir.In this model, the two roles for the Date table are order date and ship date. Bu, OrderDate sütunuyla etkin ilişkidir.It's the relationship to the OrderDate column that's active.

Alt ölçünün biri dışında tümü OrderDate sütununa göre filtreleme yapabilmelidir.All of the six measures—except one—must filter by the OrderDate column. Öte yandan Orders Shipped ölçüsünün ShipDate sütununa göre filtreleme yapması gerekir.The Orders Shipped measure, however, must filter by the ShipDate column.

Orders ölçüsünün tanımı şöyledir.Here's the Orders measure definition. Basitçe Sales tablosunun filtre bağlamı içindeki satırlarını sayar.It simply counts the rows of the Sales table within the filter context. Date tablosuna uygulanan tüm filtreler OrderDate sütununa yayılır.Any filters applied to the Date table will propagate to the OrderDate column.

Orders = COUNTROWS(Sales)

Orders Shipped ölçüsünün tanımı şöyledir.Here's the Orders Shipped measure definition. USERELATIONSHIP DAX işlevini kullanır. Bu işlev yalnızca ifade hesaplandığı sırada belirli bir ilişki için filtre yayma işlemini etkinleştirir.It uses the USERELATIONSHIP DAX function, which activates filter propagation for a specific relationship only during the evaluation of the expression. Bu örnekte ShipDate sütunuyla ilişki kullanılmıştır.In this example, the relationship to the ShipDate column is used.

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

Model tasarımı aşağıdaki rapor tasarımını destekler.This model design supports producing the following report design.

Bir dilimleyici ve bir tablo görselinin bulunduğu rapor sayfasını gösteren diyagram.

Rapor sayfası 2019 Q4 çeyreğine göre filtrelenir.The report page filters by quarter 2019 Q4. Tablo görseli aya göre gruplandırılır ve çeşitli satış istatistiklerini görüntüler.The table visual groups by month and displays various sales statistics. Orders ve Orders Shipped ölçüleri farklı sonuçlar üretir.The Orders and Orders Shipped measures produce different results. Bunların ikisi de aynı özetleme mantığını (Sales tablosunun satırlarını sayma) ama farklı Date tablosu filtre yaymasını kullanır.They each use the same summarization logic (count rows of the Sales table), but different Date table filter propagation.

Çeyrek dilimleyicisinin BOŞ öğe içerdiğine dikkat edin.Notice that the quarter slicer includes a BLANK item. Bu dilimleyici öğesi, tablo genişletme işleminin sonucu olarak görüntülenir.This slicer item appears as a result of table expansion. Sales tablosundaki her satırın bir sipariş tarihi olmasına karşın bazı satırların gönderme tarihi BOŞTUR çünkü bu siparişler henüz gönderilmemiştir.While each Sales table row has an order date, some rows have a BLANK ship date—these orders are yet to be shipped. Tablo genişletme işleminde etkin olmayan ilişkiler de dikkate alınır ve dolayısıyla ilişkinin çok tarafındaki BOŞLUKLAR veya veri bütünlüğü sorunları nedeniyle BOŞLUKLAR görülebilir.Table expansion considers inactive relationships too, and so BLANKs can appear due to BLANKs on the many-side of the relationship, or due to data integrity issues.

ÖnerilerRecommendations

Özetle, mümkün olduğunca etkin ilişkiler tanımlamanızı öneririz.In summary, we recommend defining active relationships whenever possible. Bunlar modelinizin rapor yazarları ve Soru-Cevap özelliğiyle çalışan kullanıcılar tarafından kullanılma kapsamını genişletir ve potansiyelini artırır.They widen the scope and potential of how your model can be used by report authors, and users working with Q&A. Diğer bir deyişle rol yapan boyut türündeki tabloların modelinizde çoğaltılması gerekir.It means that role-playing dimension-type tables should be duplicated in your model.

Bununla birlikte belirli koşullarda rol yapan boyut türündeki bir tablo için bir veya birden fazla etkin olmayan ilişki tanımlayabilirsiniz.In specific circumstances, however, you can define one or more inactive relationships for a role-playing dimension-type table. Aşağıdaki durumlarda bu tasarımı göz önünde bulundurun:You can consider this design when:

  • Rapor görsellerinin farklı rollere göre eşzamanlı filtreleme gereksinimi yokThere's no requirement for report visuals to simultaneously filter by different roles
  • Uygun model hesaplamalarında belirli bir ilişkiyi etkinleştirmek için USERELATIONSHIP DAX işlevini kullanıyorsunuzYou use the USERELATIONSHIP DAX function to activate a specific relationship for relevant model calculations

Sonraki adımlarNext steps

Bu makaleyle ilgili daha fazla bilgi için aşağıdaki kaynaklara bakın:For more information related to this article, check out the following resources: